Rupp Peter - prupp
2008-11-06 21:48:24 UTC
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-***@omniorb-support.com [mailto:omniorb-list-***@omniorb-support.com] On Behalf Of omniorb-list-***@omniorb-support.com
Sent: Wednesday, November 05, 2008 5:29 PM
To: omniorb-***@omniorb-support.com
Subject: omniORB-list Digest, Vol 67, Issue 4
Send omniORB-list mailing list submissions to
omniorb-***@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-***@omniorb-support.com
You can reach the person managing the list at
omniorb-list-***@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" <***@acxiom.com>
Subject: [omniORB] A beginners question...
To: <omniorb-***@omniorb-support.com>, "Rupp Peter - prupp"
<***@acxiom.com>
Message-ID:
<***@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-***@retriever.dyndns.org>
Subject: Re: [omniORB] A beginners question...
To: omniorb-***@omniorb-support.com
Message-ID: <***@retriever.dyndns.org>
Content-Type: text/plain; charset=us-ascii
does more easily than other RPC technologies.
Not sure, but does DCOP or dbus or whatever its called
have this built-in ?
can be passed anywhere, and pulled out by any code
that knows about the original type.
Also look-up DynAny.
receiver can peek inside the Any ? I assume the former.
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.
------------------------------
Message: 3
Date: Thu, 06 Nov 2008 00:28:20 +0100
From: Michael <***@bindone.de>
Subject: Re: [omniORB] A beginners question...
To: Rupp Peter - prupp <***@acxiom.com>
Cc: omniorb-***@omniorb-support.com
Message-ID: <***@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)
people :)
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
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).
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.
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).
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.
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
_______________________________________________
omniORB-list mailing list
omniORB-***@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
End of omniORB-list Digest, Vol 67, Issue 4
*******************************************
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-***@omniorb-support.com [mailto:omniorb-list-***@omniorb-support.com] On Behalf Of omniorb-list-***@omniorb-support.com
Sent: Wednesday, November 05, 2008 5:29 PM
To: omniorb-***@omniorb-support.com
Subject: omniORB-list Digest, Vol 67, Issue 4
Send omniORB-list mailing list submissions to
omniorb-***@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-***@omniorb-support.com
You can reach the person managing the list at
omniorb-list-***@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" <***@acxiom.com>
Subject: [omniORB] A beginners question...
To: <omniorb-***@omniorb-support.com>, "Rupp Peter - prupp"
<***@acxiom.com>
Message-ID:
<***@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-***@retriever.dyndns.org>
Subject: Re: [omniORB] A beginners question...
To: omniorb-***@omniorb-support.com
Message-ID: <***@retriever.dyndns.org>
Content-Type: text/plain; charset=us-ascii
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.is ?ok? to ask some very basic conceptual questions?.ones that are not usually
found easily in books?
* 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 CORBAinstance 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
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".client can learn of the methods (and argument types) available in the new
object reference? (called introspection?)
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" whichspecific 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?)
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 theclient can learn of the methods (and argument types) available in the new
object reference? (called introspection?)
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 lifespanimplementations) 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 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.help keep the network secure a little? I don?t hear much talk on this
subject either.
------------------------------
Message: 3
Date: Thu, 06 Nov 2008 00:28:20 +0100
From: Michael <***@bindone.de>
Subject: Re: [omniORB] A beginners question...
To: Rupp Peter - prupp <***@acxiom.com>
Cc: omniorb-***@omniorb-support.com
Message-ID: <***@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)
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 helpfulI'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...
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. Fromadvertise 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
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 pythonthe client can learn of the methods (and argument types) available in
the new object reference? (called introspection?)
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 theof 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?)
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? :)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.
In general yes. Read about the portable object adaptor (POA). It(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.
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 butTLS/SSL to help keep the network secure a little? I don't hear much
talk on this subject either.
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.
NPdue to my inexperience with the technology.
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
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
------------------------------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
_______________________________________________
omniORB-list mailing list
omniORB-***@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
End of omniORB-list Digest, Vol 67, Issue 4
*******************************************