Andy:
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).
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.
Carlos.
--------------------------------------------------
stop me, stop me
stop me if you think that you've
heard this one before
nothing's changed
I still love you, oh I still love you
...only slightly less than I used to
Morrissey
----- Original Message -----
From: Andy Abate <[EMAIL PROTECTED]>
To: jBoss Developer <[EMAIL PROTECTED]>
Sent: Tuesday, August 01, 2000 7:27 PM
Subject: Re: [jBoss-Dev] rmi,transactions,orbs [was: TransactionImpl]
> Carlos,
> Stepping in on your disagreement here, but I think you are a little
> confused about the functionality CORBA services provide. Most orbs support
a
> framework in which implementations of persistence, events and security are
> embedded. The services they offer are extremely thin in the areas of true
> application functionality. So thin, that they are essentially useless for
an
> EJB container implementation.
> For example, most orbs do not support CORBA SecLevel II for security.
> This is because SecLevel II is a highly detailed framework which binds the
> implementation's ideas of security entities with application entities
> rights. This implies that the applications themselves are aware and fully
> cognizant of the security situation in which they execute. Instead, most
> orbs implement a SecLevel I service which provides for simple
> UserID/Password integration with Kerberos, Certificates or whatever other
> authentication mechanism you would like to use. The attraction to this
> particular specification is that SecLevel I is fairly transparent to the
> applications and thus simple to integrate.
> The event services provide transmitter and listener associations. The
> actual message topics themselves, what they mean in context and how they
are
> to be interpreted is left entirely to the applications.
> Persistence is the same way.
> While it is true that these frameworks can be utilized for creating
> "value add" services to jBoss, they do not present a strong enough case
for
> marrying the container to a given distribution technology.
>
> ----- Original Message -----
> From: "Carlos Pita" <[EMAIL PROTECTED]>
> To: "jBoss Developer" <[EMAIL PROTECTED]>
> Sent: Tuesday, August 01, 2000 12:22 PM
> Subject: RE: [jBoss-Dev] rmi,transactions,orbs [was: TransactionImpl]
>
>
> >
> > ----- Original Message -----
> > From: Rickard �berg <[EMAIL PROTECTED]>
> > To: jBoss Developer <[EMAIL PROTECTED]>
> > Sent: Tuesday, August 01, 2000 1:30 PM
> > Subject: Re: [jBoss-Dev] rmi,transactions,orbs [was: TransactionImpl]
> >
> > >> 6) Most orbs offer another services (persistence, events, security)
> which
> > >> are pertinent to ejb containers implementations.
> >
> > > I think we are better off by doing persistence and security ourselves.
> > > Events is provide by SpyderMQ.
> >
> > Altough I'm not completely sure about how tighly coupled are persistence
> and
> > security with jBoss but, if they are plug-able (which is the right
word?),
> I
> > could say that more choices don't hurt ()
> >
> > >> 7) The corba component model is a more robust ground for a ejb
> container
> > >> implementation
> >
> > > Hm.. more robust ground than.. what?
> >
> > Perhaps this is a matter of taste but I think about it this way:
> >
> > There are several orb implementations, so there are (some) experience in
> the
> > field and more choices.
> > The orb (and services, etc) design and standarization is a thoughtful
and
> > long process
> > Orb are cospicuous, so they are tested in more scenarios.
> >
> > >> and the way to align with it (not necessarily now and
> > >> possibly never!) is building it on top of a corba (2.3 or 3? we
surely
> > need
> > >> a POA) orb.
> >
> > > I don't mind plugging in a ORB for the distribution of the container,
> > > but does it have to be more tightly coupled than that?
> >
> > Right now, I think that plugging it using the JMX machinery should be
> > enough.
> >
> > Do you have another kind of solution in mind?
> >
> > >/Rickard
> > Carlos
> >
> > --
> > Rickard �berg
> >
> > Email: [EMAIL PROTECTED]
> > http://www.telkel.com
> > http://www.jboss.org
> > http://www.dreambean.com
> >
> >
> >
> >
> >
>
> -------------------------------------------------------------------------
> > This email server is running an evaluation copy of the MailShield anti-
> > spam software. Please contact your email administrator if you have any
> > questions about this message. MailShield product info:
www.mailshield.com
> >
>
>
> -------------------------------------------------------------------------
> This email server is running an evaluation copy of the MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: www.mailshield.com
>
>
>
