> we were able to create a corba servant acting as an XA resource. We aren't able to enlist it in the current transaction beacuse for enlisting purposes we need an XAresource and we haven't found a way to "cast" the corba servant reference to this interface.
Well it may be acting as an XA resource, but it's clearly not acting as an XAResource. An XAResource implements javax.transaction.XAResource. It you want to use the JTA API you'll need to put in the effort to have your resource implement the XAResource Interface correctly, it's not something we provide. Or you can ignore JTA and have it implement CosTransactions:Resource instead. It really just depends if you are more comfortable with the CORBA way or the JavaEE way of living.
sorry for my imprecise post,
yes using the bank example we were able to instantiate a CosTransaction:Resource.
What we want to obtain is to be able to "see" this corba CosTransaction:Resource as an javax.transaction.XAResource so to be able to enlist it in JTA transaction.
I'm starting now to study the OTS specification but I have a gut feeling that this is not enough to obtain the transaction protocol propagation.
I try to explain better, this is the scenario I expect to have:
-------------------- |JBI environment | --------------------------------------------- | Jbi4corba | a ORB | <----> | another ORB| CosTransactions:Resource| | j2ee TM | <tx prpagation> | OTS TM (jbossts) | -------------------- ----------------------------------------------
The question is how the external (right) OTS server is notified by the j2ee TM of an existing transaction? is the enlist operation enough?
I think I'm even more confused now :-) The 'j2ee TM' must be actually be an OTS, otherwise it won't be able to do the IIOP <tx propagation> bit. In which case, why not just enlist the OTS:Resource with it directly? For that matter, why do you need a full TM on each end, or even why do you need two JVMs with tx propagation? What's the business method call that the tx is propagating on?
The j2ee TM is visible to us with the JTA API, anyway being a j2ee TM it must be able to interoperate with other TM using the OTS specification as required by the ejb/j2ee specification.
My jbi environment to be more clear will be Glassfish for testing purpose, but it could be also servicemix (which is not j2ee and so for now it's out of scope).
So basically my assumption is given that 2 application servers must be able to interoperate using the OTS specification, the interoperability should be possible even if on the one side there isn't a real application server but just an OTS implementation.
Going to your second question "why not just enlist the OTS:Resource with it directly?", here we are talking about an application integration scenario. So let's assume for a moment that there is a corba transactional application that is working. It will have its own OTS TM and its corba client (may be transactional clients). Then a new requirement shows for the IT to integrate this application with the ESB and so with other applications. The integration should touch the corba application as little as possible, theoretically it shouldn't touch it at all. So the integration should be seen by the corba application as just another client. These are my assumptions for having a realistic scenario are they wrong?, can one of the TM be put out of the equation?
This should also answer to your following questions, being jbi4corba a middleware development the business methods aren't important and we will use the simplest example that we find (for the sake of automated tests).
> anyway being a j2ee TM it must be able to interoperate with other TM using the OTS specification as required by the ejb/j2ee specification.
I think you misread the spec. tx interop is optional.
> So basically my assumption is given that 2 application servers must be able to interoperate using the OTS specification,
excuse me a moment...
...ahem. sorry about that. ok, where were we?
> there is a corba transactional application that is working. It will have its own OTS TM and its corba client (may be transactional clients).
Why do you assume the app has its own TM? It may simply rely on being able to communicate with an external TM. The number of products that actually embed a full OTS implementation is pretty small.
So you have an existing transaction aware business app, which exposes a CORBA API and expects business method calls to come with a OTS transaction context on. You don't want to change this app in any way. It may not even be written in Java.
You have some Java client that what wants to access this transactional application through JBI. It does not want to know anything about CORBA, only Java EE.
Your job is to provide the integration to make that possible.
Is that right?
>Why do you assume the app has its own TM? It may simply rely on being able to communicate with an external TM. The number of products that actually embed a full OTS implementation is pretty small.
This question is interesting for me because it underscore that i'm still not getting it well. I was assuming that an app server must have its own TM because if I try to use two app server of the same vendor they should be able to propagate the transactional contest. This is usually supported, so may be the appserves does have a TM but it's not a OTS implementation. Anyway I'm pretty sure that glassfish does have a OTS implementation because I've talked with sun people. The issue with glassfish OTS is that it's not runnable outside glassfish.
>So you have an existing transaction aware business app, which exposes a CORBA API and expects business method calls to come with a OTS transaction context on. You don't want to change this app in any way. It may not even be written in Java.
yes this is the scenario in which a transaction propagation feature does make sense in jbi4corba.
>You have some Java client that what wants to access this transactional application through JBI. It does not want to know anything about CORBA, only Java EE.
This is not fully right, the JBI protocol completely decouple the consumer from the provider. So my component act as provider of services inside the bus (and on behalf of the corba side it acts as a corba client). I don't need to care about the consumer implementation, what I need to know is that the consumer will have instantiated the transaction, and will send it to jbi4corba in a message. In jbi the transaction model is different from ejb where a transaction is usually attached to a thread, in jbi the transaction is attached to a message (exchange) and can be seen by different threads. After the execution of the message flow (that could involve other transactional resources), the TM inside the jbi environment will conclude the transaction with either rollback or commit. From jbi4corba point of view the transaction handle is available from the message it receive and is accessible through JTA API. Given that as a jbi component implementor you're on your own, meaning that no other support is available for transaction because the use of the transaction object is totally dependant on the technology/protocol of the implemented component.
Of course jbi4corba has a reference to the corba transactional resource it is configured to talk to. So conceptually I just want to enlist the corba resource in the transaction I get from the message.
>Your job is to provide the integration to make that possible.
>Is that right?
well the jbi4corba component is a container (like any jbi component) of deployment configurations. So I want to make the integration possible for all these class of integration scenario (corba transactional resource without touching it). But of course if I am able to see one instance of the solution then I can generalize it.
> JBI protocol completely decouple the consumer from the provider...the consumer will have instantiated the transaction, and will send it to jbi4corba in a message
What are the producer and provider here? What does the specification say about the structure of the message and in particular the transaction context? Does it have to be IIOP with an OTS context, or does JBI define its own format?
>What are the producer and provider here?
a jbi connector is a bridge between outside the bus and inside the bus.
a provider is an endpoint that provide a service inside the bus and consumes a service outside the bus (this is not completely correct but should give you the idea).
a consumer is an endpoint that consume a service provided inside the bus and provides a service to be called from outside the bus.
>What does the specification say about the structure of the message and in particular the transaction context?
the massage has a context and in the context there can be some additional data like the transaction handle. the specification says nothing expect that it is a javax.transaction.Transaction and that a TransactionManager is available from the component context.
>Does it have to be IIOP with an OTS context, or does JBI define its own format?
There is nothing about that in the specification. So it could be anything but it should also be possible to build some sort of bridge betwee two context isn't it?
OK, so it's not safe to assume the transaction manager provided by the JBI container is an OTS, nor that the transaction context provided is a CORBA tx context.
If you play by the rules, you need to implement an adaptor that can bridge between JTA and OTS. Does your code need to actually take any transaction aware action, or does it just pass the call along to the underlying service with an OTS tx context on? In the former case you'll need to implement XAResource and enlist with the TM, whereas in the latter case you just need to convert the JTA Transaction to an OTS one and place the context on the IIOP call. The external service will then create an OTS:Resource and try to register it. At which point you'll find you need to implement some of the other OTS interfaces as proxies to the existing non-OTS TM. In short, you wind up writing some parts of the JTS yourself, delegating most of the operations to the existing JTA.
Or you can cheat and assume the JTA the container provides is actually a JTS, in which case you can take a few highly non-portable shortcuts.
very well I'm starting to understand.
is it possible to use jbossts as a portable (over ORB) bridge between OTS and JTA? The architectural picture led me to think that this could be one of the possible uses.
What are the non portable shortcut that I could take?
> is it possible to use jbossts as a portable (over ORB) bridge between OTS and JTA?
If I understood the requirements right then what you are talking about here is essentially interposing a JTS subtransaction coordinator into a JTA parent transaction, where the latter may not even be a JBossTS native transaction. Interposing JTS into JTS is trivial, but what you need is a bit more involved. I'd have to dig into the code before I can give a definitive answer on how hard it's going to be. I suspect you'll wind up needing to extend or replace parts of the JTS implementation, but that may still be faster than starting from scratch.
> What are the non portable shortcut that I could take?
We if you assume that the container provides you a JTS then you can simply use the OTS interfaces rather than the JTA, so you don't need to bridge any more.
sorry for the silence but I've been busy. I studied a little the OTS specification.
Assuming that the JTA implementation is OTS and that I find a way to downcast it to OTS I've determined that I need to do the following:
1. at deply time call TSIdentification::identify_sender to let know the OTS implementation of the ORB I'm using. If the ORB is OTS aware this should be enough to have the two starting to talk each other. This API needs a sender object where do I get it? Should it be a pointer to the Transaction Portable Interceptor?
2. when a method has to be called I need to resume the transaction taken from the message so that it is attached to the current thread.
Please let me know if that seems correct to you and if jbossts portable interceptor could be used in this scenario.