[omniORB] A beginners question...
Michael
omniorb at bindone.de
Thu Nov 6 00:28:20 GMT 2008
Hi Peter,
("The" CORBA book means
http://www.amazon.com/Advanced-Programming-Addison-Wesley-Professional-Computing/dp/0201379279)
Rupp Peter - prupp wrote:
> Hello,
>
> I'm entering the world of Corba programming and wanted to ask your group
> if it is "ok" to ask some very basic conceptual questions....ones that
> are not usually found easily in books?
>
> Thank you in advance! Here goes...
IMHO this list is omniORB specific, but in the end we're all helpful
people :)
>
>
>
> * Can Corba accommodate the following? I have a need to
> advertise an object instance via CORBA, whereby (depending upon which
> method and arguments are invoked), may return simple primitives
> (strings, ints, arrays, etc), or sometimes act like an object factory,
> that is...to dynamically create various object instances (of possibly
> differing types), that are also referenced remotely by the CORBA client.
> I've read a lot of how a corba object is defined via IDL, then client
> and server stubs are created, (that is, statically at compile time), but
> I am unaware if the CORBA specification allows for corba object
> instances to act as a factory, creating objects, then returning a
> reference to them. Right now, I want to keep the object on the
> server, but return a reference
Actually the factory pattern is the most important for using CORBA. From
a design perspective I would always prefer to have distinct methods to
factor different kinds of objects (if possible). But if you want to
accomplish what you've been asking for, Any is the way to go. You can
read a lot online about any and in "the" CORBA book.
Example IDL:
module Peter
{
interface MyFirstFactory
{
any createAnything(in string what);
};
};
Keywords: Any, TypeCode, narrow
>
>
>
> * If the above concepts possible, are there standard/defined ways
> the client can learn of the methods (and argument types) available in
> the new object reference? (called introspection?)
This is pretty hard in CORBA, especially if you're using C++ (in python
e.g. that is simpler). The OMG way of doing this is using an interface
repository that holds all the interfaces combined with what is called
dynamic CORBA. You would first have to figure out if you're dealing with
a primitive/data construct or an object reference. structs and the like
you can inspect directly, for objects there is a method
CORBA::Object::_get_interface. AFAIK in omniORB this again results to a
call to the interface repository.
In practice all of this is very complicated (especially for a beginner)
and you only want to do this if you're writing generic components like
XML/CORBA gateways (I wrote my own interface repository last year - more
as a practice to understand really every bit about CORBA's objects - but
I figured using it in real world applications is unneccessary 99% of all
times. So it is possible but not simple at all - and you're losing a lot
of the compile time safety that static IDL mappings supply. Maybe you
can tell us what you actually want to accomplish, so we could give you
our 2 cents about the design.
If you're interested in this, try google and read the following series
on dr dobbs:
http://www.ddj.com/cpp/184403833
There are also new mechanisms in CORBA 3.x that make introspection
easier (as asked for by IONA), but I don't know much about them and they
are IMHO not part of omniORB (and many other ORBs).
>
>
>
>
>
> * I'm fairly certain that data returned from corba objects must be
> of specific types defined in the IDL, that is primitives (strings, ints,
> floats, etc), and some collection types (arrays, lists, etc)......but no
> serialized objects. In other words, I don't think CORBA has a notion
> of a generic object type that is movable (via serialization) from ORB to
> ORB. Is this correct? (or am I horribly mistaken?)
Traditionally primitives (including structs) and transmitted over the
CORBA bus while objects are always passed as references (so they reside
on the server side). There is also object by value (so you can handle
objects in a local implementation and they're constructed based on their
serialized form), but this is also pretty hard to handle and at least
for me barely useful (unless you incorporate a more sophisticated
infrastructrue around it). It is IMHO most interesting if you have a
homogeneous environment, where you can also send the actual
implementation over the CORBA bus (like you could do in Python or Java
or as loadable modules for C++). But in this case you'll lose a lot of
the interlanguage advantages of CORBA - or end up implementing
everything multiple times for different languages or at least twice (one
ObV "local" version and a remote version that is usaböe by everyone).
Also note that object by value support is not 100% mature in all ORBs.
>
>
>
> * If the above concepts possible, are there standard/defined ways
> the client can learn of the methods (and argument types) available in
> the new object reference? (called introspection?)
Dejavu? :)
>
>
>
> * Again, if this is all possible, does the CORBA-specifications
> (or even implementations) provide a means to specify and identify the
> life-span of objects (dynamic or otherwise). In other words, can an
> objects lifespan be defined by some set of rules or parameters? For
> instance, if an object was created dynamically, would it be possible to
> set it's lifetime to 1) the lifetime of the TCP connection between
> client/server? 2) lifetime due to inactivity, 3) lifetime due to
> infrequent use, or any other constraint? I do not hear much about how
> objects are retired or collected on the server.
In general yes. Read about the portable object adaptor (POA). It
provides different sets of persistence and lifespan policies and
different ways to etherialize objects (standard active object map,
servant activators, servant locators and default servants. In detail:
1) No, because CORBA object references are not connection based
2) Yes, but this is something you'll have to implement on your own (or
might be a feature of your ORB). 3) is much more common if you're not
using persistent objects
3) This is e.g. done through servant locators in combination with the
eviction pattern (basically a cache). "The" CORBA book provides an
example implementation of it (even so the last time I checked it
had a multi-threading problem).
>
>
>
> * Is it normal for Corba clients and ORBS to communicate on top of
> TLS/SSL to help keep the network secure a little? I don't hear much
> talk on this subject either.
It is specified. We normally use CORBA on top of a VPN structure but
ommniORB e.g. supports SSL/(TLS) with client certificates. I actually
never did that, but this is also one of the advantages of CORBA that the
giop mechanism is very flexible and powerful. If you have more serious
and complex interfaces after many years of using CORBA I came to the
conclusion that you do not want to use it over unreliable connections
(like the internet) but limit to intranet/VPNs and use so-called
Webservices (XML or god-forbid SOAP) for outside world interfaces.
>
>
>
> Thank you for taking the time to read this long description - largely
> due to my inexperience with the technology.
NP
My personal resume after using CORBA for more than 5 years is that IDL
is your friend and CORBA's biggest strength - having a place where you
can statically define all interfaces and data structures, have compilers
create all the skeletons and have a really strong contract between
modules and developers. "Any" is also a very powerful concept that is
used everywhere successfully - especially if the end-user of an
interface actually knows about it through an IDL and can narrow it to a
known type. Pure dynamic CORBA is good in very specialized components
(e.g. we run a service that can queue whatever CORBA call and issue it N
times in the future). Building a complete system end-to-end on top of
dynamic corba (meaning everything is using it and relying heavily on
introspection) will create a lot of trouble, especially because the
learning curve for using these features is extremely steep and debugging
will be a nightmare. If you're planing to implement such a system, CORBA
is not the way to go, because you'll lose many of its strengths and
focus on its weak spots. These kind of challenges are much easier solved
using a different technology.
br
michael
>
> Knd regards,
>
> PEter
>
>
>
>
>
>
>
>
>
> \
>
>
>
>
>
> a reference to new object instances (of possibly different types).
> I'm not sure if a corba object implementation is permitted (in existing
> CORBA technology) to create )
>
> *************************************************************************
> The information contained in this communication is confidential, is
> intended only for the use of the recipient named above, and may be
> legally privileged.
>
> If the reader of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited.
>
> If you have received this communication in error, please resend this
> communication to the sender and delete the original message or any copy
> of it from your computer system.
>
> Thank you.
> *************************************************************************
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
More information about the omniORB-list
mailing list