Ole Husgaard wrote:
> Hi,
>
> 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.
Ok, I agree that this is a worthwhile endeavour.
> 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.
This is true. Good point.
> 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.
I agree that this makes sense for CORBA servers that are written to take
advantage of the transaction and security features of CORBA. The point I
was trying to make was just that for some legacy systems that you happen
to want to interface to using CORBA you might not have control over
that. For these situations, where you essentially have a transactional
resource that has some proprietary method for controlling transactions,
the JCA approach is appropriate. This isn't a good use of CORBA, though.
I think we agree. I just have a specific case in mind that doesn't quite
fit (this is what we're doing at work).
Toby.
