Hi,
Toby Allsopp wrote:
> On Wed, Feb 28, 2001 at 09:44:43PM +0100, Ole Husgaard wrote:
> > This way posted to jboss-user, and
> > Marc asked for a redirect to this
> > list.
>
> Yes, I saw that later.
>
> > Makes sense to me, as I think it is
> > time we start thinking about how to
> > support CORBA.
>
> Doesn't make any sense to me. What does wanting to be a CORBA client
> have to do with JBoss supporting CORBA?
It looks to me like quite a few people
have problems running CORBA clients
in JBoss.
And without some support from JBoss,
transaction and security contexts cannot
be propagated unless each IDL interface
is wrapped in a JCA resource.
> > A simple MBean (like the one Andreas
> > wrote) to support it it that first
> > step.
>
> Are you talking about having an MBean that binds the ORB into JNDI? I can
> see how that would be useful.
>
> > Later we can think about adding
> > support for propagating contexts (in
> > particular transaction and security
> > contexts) over IIOP. Even later we
> > can think about creating an IIOP
> > invocation layer for JBoss EJB calls.
>
> I have to admit that you lose me at this point. I will leave this part
> of the discussion to people who know about such things.
I never used CORBA security, so I'll
leave that to somebody who knows that.
But for transaction context
propagation, there are hooks that the
ORB will call to get the context.
These hooks will only be called if
someone registered them. IMHO, JBoss
should register these hooks when we
support a real DTM capable of
exporting transactions to the OTS
domain. And when we support importing
transactions from the OTS domain, we
can also register the hooks for
incoming CORBA invocations, so that
CORBA servers in JBoss can work
with transactions. Registering both
these hooks is needed is we should
ever support CORBA transports for
JBoss bean invocations.
> > I don't think that creating JCA
> > resources for every possible CORBA
> > service is the way to go. Instead
> > we should use the CORBA hooks
> > available for seemless integration.
>
> http://www.bath.ac.uk/~masjpf/maillists/rosegarden/msg00559.html :-)
> Or did you mean "seamless"?
Oops. I meant seamless, like fully
transparent (when hooks are in
place).
> Are you saying that we should propagate the transaction and security
> contexts directly over the IIOP invocation rather than going through
> the JCA interfaces? That makes sense for CORBA services that are aware
> of such things, in fact it makes a lot of sense.
>
> For CORBA services that are simply a way of exposing some external
> legacy system the JCA approach would make more sense.
IMHO, using JCA for this is overkill.
Look at what JCA does:
A) Connection pooling.
CORBA is not really connection-oriented.
Underlying TCP connections are
often pooled, but that is transparent
to the user, and handled by the CORBA
implementation.
B) Transaction handling. Package
org.omg.CosTSPortability has hooks that
can be registered to fetch transaction
contexts as needed.
C) Security handling. I am not sure,
but I guess something similar to
CosTSPortability exist here.
So by registering the right hooks with
the CORBA implementation, I guess we
can get all the functionality of JCA,
without having to create JCA resources
for any CORBA interfaces.
Best Regards,
Ole Husgaard.
