Hi!
I'm talking about orbs in the strict sense of the corba 2.3 spec. I know
that everything out there is an orb in a loose sense :). I think (and I'm
almost sure) a corba orb functionality shouldn't overlap with an EJB
container bussiness. But they do overlap with some of the current jBoss
modules. I see no problem with this (only more future choices). Take the
example of the ots: the best way to plug in it in some iiop infrastructure
is to plug in it into an orb (an ots is intended to be registered this way,
indeed jts spec comformance requires the portability interfaces). So you
could have a module which prepares the orb, then another which register the
ots with the orb in a standard way (well, perhaps at first you will be
stucked with some orb that hasn't this functionality so you will have to fix
it another way, but who laughs last laughs the best). Another example: you
could take adventage of the POA approach for servant management with a
servant manager which uses all the jBoss stuff (pooling, persistence, etc)
or could use rmi-iiop on top of the orb to export your
PortableRemoteObjectDelegate's. You could even change the orb implementation
with not very hard (and hopefully little) effort. This is not at all
intrusive. And jBoss is not an orb in the sense of a corba orb and it (IMHO
again) shouldn't (and if it were I think that all the orb functionality
should be really encapsulated in a corba orb, perhaps orBoss :)).
Carlos
----- Original Message -----
From: Rickard �berg <[EMAIL PROTECTED]>
To: jBoss Developer <[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 11:37 AM
Subject: Re: [jBoss-Dev] rmi,transactions,orbs [was: TransactionImpl]
Hi!
Carlos Pita wrote:
> I really disagree with you in this. Although at the current state of
the
> art most orbs could not have, for example, a security level 2 conformant
> security service, I have taken care of embedding all those
"eventually"-like
> words in my posts. My point is that orb bussiness are orb bussiness and
this
> should be more and more this way in the not so distant future so we should
> be aware of it (but using a modular approach, with pluggable software
pieces
> which eventually -and not necessarily now- take advantage of the
services).
> If you put an orb there, someday someone could write a nice plugin for
some
> of its services. And the more important part: you are solving the ots
> integration problem in the more standard way (IMHO).
Sounds like the jBoss container architecture is a perfect ORB then..
> Currently I know that JavaORB has a security service with SL2 and a
> persistence service that supports persistence via jdbc. They also have a
lot
> of other services working and a good CORBA 2.3 orb. They are also working
in
> a CCM implementation which will be first released by the last days of this
> month and in a CORBA 3 orb (www.openorb.org).
>
> Well, enough about this corba stuff! I think this should be a good
> solution which inspires some long-term solution feeling (I mean in the
areas
> that it covers). But perhaps you want to fix the current jBoss transaction
> module so you are not really interested in orbs right now. Please stop me:
I
> would help you with your current implementation.
Well, the thing is that the part that I usually think of when ORB's are
mentioned is the pure IIOP stuff. And as I've said, I don't mind if
someone adds IIOP support to jBoss; after all, distribtion *is*
pluggable. However, the other things are already taken care of thanks to
the modular architecture of jBoss. jBoss *is* an ORB in the sense that
you can plug in persistence and security and whatnot.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
