Creating an application server stub until the JCA is fully implemented

Question

Greetings,
          We have pretty much decided that the Java Connector Architecture is the
          way to go, when it comes down to integrating with EIS systems.
          However, the problem still remains that the JCA spec is not fully
          supported in the current beta release of the Connector implementation
          within WLS 6.0. In particular,
          I see that only non-transaction Resource Adapters can be deployed in
          this release (local transaction and XA transaction ones will have to
          wait until the full release in the summer).
          However, what our group wants to do is write XA-compliant Resource
          Adapters, even ahead of the actual support for them in the product. The
          issue for us is how to structyure our implementation so that we end up
          with a minimal re-write when the full implementation of the spec
          arrives.
          It seems to me that if I wanted to have support for XA-compliant
          Resource Adapters NOW, I would have to actually write some of the code,
          that would otherwise be part of the application server/container,
          myself. In particular, it is the code that "enlists" the XAResource
          object, which is associated with the ManagedConnection that an
          application bean asks for, with the Transaction Manager that is later
          going to coordinate things in the global XA transaction.
          Let me describe how I see things:
          when the application component calls into the Resource Adapter for a
          connection handle, the ConnectionFactory class according to the spec)
          delegates the call to the application server ConnectionManager (that it
          has been initialised with, typically at creation time), which in turn
          calls the createManagedConnection method of the ManagedConnectionFactory
          class inside the Resource Adapter.
          Now, I want to emulate the application server so that the
          ConnectionManager class is in fact implemented in my Resource Adapter.
          That I guess will not be a problem. However, the next thing IS (in the
          current BETA release): the application server code would normally
          retrieve the XAResource instance that is "hanging" off the
          ManagedConnection that has just been created and would "enlist" this
          with the Transaction Manager. Thereafter, everything would follow the
          normal XA transaction route, as the Transaction Manager would start
          calling back into the XAResource, notifying it on the status of the
          global XA transaction (start, end, prepare, commit, abort).
          Looking at the JTA specification, an in particular at what the
          application server code has to do, I see the following set of
          interactions:
          TransactionalResource res = ResourceFactory.getTransactionalResource();
          XAResource xaRes = res.getXAResource();
          (TransactionManager.getTransaction()).enlistResource(xaRes);
          <<<<<<<<<------------ how do/can I, in
          application code, within the Resource Adapter in fact, get hold of the
          TransactionManager instance? This is trivial when it is implemented
          within the app server code, but could I also do this?
          This will obviously be an interim solution for us: we will implement a
          very small part of the appliction server logic (you could call it a
          stub) around the registration of the XA resource with the global
          transaction manager. The aim is really to write something that will
          appear to our application beans as well as to the rest of the Resource
          Adapter as something that is behaving in the same way as the application
          server would (in the full implementation of the JCA spec), and would
          also ensure that neither our application component code nor our Adapter
          code would not have to be dramatically changed when that app server
          piece of the JCA-specified system contract implementation is in place.
          I realise that the APIs to the Transaction Manager implementation within
          WLS are "private" and that people may not want us to be using them. But
          it is the only way that I see for us to create something (Resource
          Adapters) which are a)XA compliant and b) will only have to change
          minimally, if at all, when the actual implementation is in place.
          I would appreciate any thoughts from BEA folks out there. Also, if you
          see another way of solving my problem (support global XA transaction
          within my Resource Adapters, AND minimal re-write) that I may be
          missing, I would appreciate your feeback around that.
          Many thanks in advance
          Kostas
          Kostas Karagianidis
          Technical Consultant
          PricewaterhouseCoopers
          Delta 602, Delta Business Park
          Swindon SN5 7XJ, Wiltshire
          United Kingdom
          Tel: [phone]
          Fax: [phone]
          Mobile: [phone]
          e-mail: [email protected]
          The information transmitted is intended only for the person or
          entity to which it is addressed and may contain confidential and/or
          privileged material. Any review, retransmission, dissemination or other
          use of, or taking of any action in reliance upon, this information by
          persons or entities other than the intended recipient is prohibited.
          If you received this in error, please contact the sender and delete the
          material from any computer.
          

Answer 1

Did you sign your jar file for JWS? I don't think the security manager will allow a filebrowser if the jar is not signed.
Edited by: Plee on Dec 29, 2008 6:54 AM