[omniORB] A beginners question...

[Rupp Peter - prupp]

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.htm

[Kevin Bailey]

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.

[Michael]

Hi Peter,

("The" CORBA book means
http://www.amazon.com/Advanced-Programming-Addison-Wesley-Professional-Computing/dp/0201379279)

Post by Rupp Peter - prupp
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 :)

Post by Rupp Peter - prupp
* 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

Post by Rupp Peter - prupp
* 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).

Post by Rupp Peter - prupp
* 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.

Post by Rupp Peter - prupp
* 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? :)

Post by Rupp Peter - prupp
* 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).

Post by Rupp Peter - prupp
* 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.

Post by Rupp Peter - prupp
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

Post by Rupp Peter - prupp
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
http://www.omniorb-support.com/mailman/listinfo/omniorb-list