(newbie) Accessing objects from an in proc server?

[Philip Dawes]

Can corba be used to allow a program to create and access objects in its
own address space (i.e. from a dynamically linked shared library)? (Like
in-proc servers in COM)

I'm looking for a technique to provide a generic way of implementing
'plug-in' behaviour in an application for linux. I want to allow other
binary plugins to be written as shared libraries, then loaded and
accessed at run-time using corba.

Thanks in advance,

Phil.
--
_______________________________________________________________________
Phil Dawes | My opinions are my own
WWW: http://www.cs.bham.ac.uk/~pld | and nothing to do with
Email: phi...@parallax.co.uk | my employer.
_______________________________________________________________________

[Michi Henning]

On Wed, 1 Oct 1997, Philip Dawes wrote:

> Can corba be used to allow a program to create and access objects in its
> own address space (i.e. from a dynamically linked shared library)? (Like
> in-proc servers in COM)
>
> I'm looking for a technique to provide a generic way of implementing
> 'plug-in' behaviour in an application for linux. I want to allow other
> binary plugins to be written as shared libraries, then loaded and
> accessed at run-time using corba.

Yes. Every ORB I know of supports this. Simply link the server code
into the client and you are done. That's what CORBA's location transparency
is all about. The server code can of course be placed into a library
(obviously, for co-located servers, you won't have a main function
and you won't have an event loop, at least not if the client is
single-threaded).

Cheers,

Michi.

Copyright 1997 Michi Henning. All rights reserved.

--
Michi Henning +61 7 33654310
DSTC Pty Ltd +61 7 33654311 (fax)
University of Qld 4072 mi...@dstc.edu.au
AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html

[rak...@gmail.com]

> Yes. Every ORB I know of supports this. Simply link the server code
> into the client and you are done. That's what CORBA's location transparency
> is all about.

Please see http://pdf.aminer.org/000/535/970/performance_comparison_of_dcom_corba_and_web_service.pdf

COM object has the 3 types such as an inproc, a local, and a service type. An inproc type takes the form of a Dynamic Linking Library (DLL). An inproc type is the fastest type because it is loaded directly into a client
process when activated.

CORBA has the 2 server types such as a Basic Object Adapter (BOA) and a Portable Object Adapter (POA).

An inproc server type of COM is the fastest. At a local machine, the inproc server type is directly loaded into the executing process, thus this type has no overhead of Inter Process Communication (IPC) and is operated as a general method call.

I do not know CORBA implementation that can create inproc-like objects without IPC-overhead and supports direct method call (via vtable).

[Volker Birk]

rak...@gmail.com wrote:
> I do not know CORBA implementation that can create inproc-like objects
> without IPC-overhead and supports direct method call (via vtable).

CORBA is for distributed objects. It's not a component model for local
applications. Some use it like that, but it obviously is not designed
for that case.

But COM is a desaster: the main problem with COM is that there is no
sensible concept for object management – and no, the "Registry" as
manually replicated object repository is a real mess and not a solution.

Before some people are reminding me of the posibilities in COM+ or DCOM:
Yes, I know. The difference between theory and practice remains, that in
theory theory and practice are identical. The bad design mentioned above
led to all the mess I came across all those years in all those projects.

Yours,
VB.
--
Wenn Steinbrück „Urwahl“ hört, ruft der „Rolex!“

(Friedrich Küppersbusch)

[Johnny Willemsen]

Hi,

> I do not know CORBA implementation that can create inproc-like
objects without IPC-overhead and supports direct method call (via vtable).

TAO as C++ ORB has collocation optimizations (through POA and direct).
When enabled a client and server in the same process can communicate
directly through a virtual method call. No runtime overhead for IPC.

Regards,

Johnny
http://www.orbzone.org
http://www.theaceorb.nl

[Martin B.]

On 12.12.2012 13:04, Volker Birk wrote:
> rak...@gmail.com wrote:
>> I do not know CORBA implementation that can create inproc-like objects
>> without IPC-overhead and supports direct method call (via vtable).
>
> CORBA is for distributed objects. It's not a component model for local
> applications. Some use it like that, but it obviously is not designed
> for that case.
>
> But COM is a desaster: the main problem with COM is that there is no
> sensible concept for object management – and no, the "Registry" as
> manually replicated object repository is a real mess and not a solution.
>
> Before some people are reminding me of the posibilities in COM+ or DCOM:
> Yes, I know. The difference between theory and practice remains, that in
> theory theory and practice are identical. The bad design mentioned above
> led to all the mess I came across all those years in all those projects.
>

I never got what the difference btw. COM and COM+ is supposed to be and
*D*COM is indeed a disaster, but mainly because MS totally messed up
security-management. (Ever tried to get DCOM running in a complicated
network?)

COM on the other hand often is the best practical solution on Windows,
although it has a lot of crappy edges.

cheers,
Martin


--
Good C++ code is better than good C code, but
bad C++ can be much, much worse than bad C code.