[omniORB] RE: omniORB-list Digest, Vol 67, Issue 4
Rupp Peter - prupp
Peter.Rupp at acxiom.com
Thu Nov 6 09:47:45 GMT 2008
Hello All,
I wanted to thank everyone, especially Kevin and Michael for their time and expertise in answering my various questions. It's a lot to digest for now, but most excellent comments and advice! Would it be ok if I provide what we are attempting to do, and ask you about design pointers? I plan to use omniorb (from Python) but it will need to communicate with java's built-in j2ee orb <sigh>.
-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of omniorb-list-request at omniorb-support.com
Sent: Wednesday, November 05, 2008 5:29 PM
To: omniorb-list at omniorb-support.com
Subject: omniORB-list Digest, Vol 67, Issue 4
Send omniORB-list mailing list submissions to
omniorb-list at omniorb-support.com
To subscribe or unsubscribe via the World Wide Web, visit
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
or, via email, send a message with subject or body 'help' to
omniorb-list-request at omniorb-support.com
You can reach the person managing the list at
omniorb-list-owner at omniorb-support.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of omniORB-list digest..."
Today's Topics:
1. A beginners question... (Rupp Peter - prupp)
2. Re: A beginners question... (Kevin Bailey)
3. Re: A beginners question... (Michael)
----------------------------------------------------------------------
Message: 1
Date: Wed, 5 Nov 2008 14:24:04 -0600
From: "Rupp Peter - prupp" <Peter.Rupp at acxiom.com>
Subject: [omniORB] A beginners question...
To: <omniorb-list at omniorb-support.com>, "Rupp Peter - prupp"
<Peter.Rupp at acxiom.com>
Message-ID:
<5A80174CDBD2004CB0A1A069083813C903D4DAFE at CWYMSX05.Corp.Acxiom.net>
Content-Type: text/plain; charset="us-ascii"
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...
* 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
* 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?)
* 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?)
* 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?)
* 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.
* 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.
Thank you for taking the time to read this long description - largely
due to my inexperience with the technology.
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.
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20081105/e2a0e8d7/attachment-0001.htm
------------------------------
Message: 2
Date: Wed, 5 Nov 2008 13:22:32 -0800
From: Kevin Bailey <ke-omniorb at retriever.dyndns.org>
Subject: Re: [omniORB] A beginners question...
To: omniorb-list at omniorb-support.com
Message-ID: <20081105212232.GA13800 at retriever.dyndns.org>
Content-Type: text/plain; charset=us-ascii
On Wed, Nov 05, 2008 at 02:24:04PM -0600, Rupp Peter - prupp wrote:
>
> 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?
comp.soft-sys.ace used to be another good place to ask CORBA questions.
> * 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
Absolutely, no problem. This is one of the things that CORBA
does more easily than other RPC technologies.
> * 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?)
I think you need what's called a "interface repository".
Not sure, but does DCOP or dbus or whatever its called
have this built-in ?
> * 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?)
Any described type can be put into an "Any" which
can be passed anywhere, and pulled out by any code
that knows about the original type.
Also look-up DynAny.
> * 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?)
Is this a duplicate question, or are you asking if the
receiver can peek inside the Any ? I assume the former.
> * 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.
Not exactly sure what you're asking. An object's lifespan
is completely controlled by the application, but the servant
backing it may live forever, or may only last for the
duration of the call, or ...
Advanced CORBA Programming in C++ will answer this as well
as lots of other questions.
> * 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.
Dunno.
------------------------------
Message: 3
Date: Thu, 06 Nov 2008 00:28:20 +0100
From: Michael <omniorb at bindone.de>
Subject: Re: [omniORB] A beginners question...
To: Rupp Peter - prupp <Peter.Rupp at acxiom.com>
Cc: omniorb-list at omniorb-support.com
Message-ID: <49122C14.2070404 at bindone.de>
Content-Type: text/plain; charset=ISO-8859-1
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
------------------------------
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
End of omniORB-list Digest, Vol 67, Issue 4
*******************************************
More information about the omniORB-list
mailing list