JCA, a thread too far.

JCA defines a contract between a connector implementation and a connector container, typically a J2EE server. In the beginning, code in the connector was hands off and could do anything. Slowly, with JCA 1.5, we're seeing this view slowly being modified as the specification tries to make connectors run in a managed environment.

JCA 1.5 adds a managed threading concept and a way to have callbacks to the container (read MDBs). But, there are still issues. Suppose the JCA connector wants to use a database in a transaction along with itself. No can do, this needs to be pushed up to the application and implemented using a callback (read in the MDB).

I think the defiencies will slowly push the JCP to make connectors a full fledged component and when they do that, connectors will end up like a local session bean. There will be extensions required of course, threading, importing XA trans, timer services, safe callbacks etc.

In WAS Enterprise 5.0, I added support for constructs to allow server components to be written. A server component for me is something which has a lifetime that isn't coupled to a client. Application Servers and databases are examples of server components. They have a lot of state, they use threading, timers etc and can respond to requests from their clients.

For me, a normal J2EE application is not a server application, it's like a bunch of stored procedures running in a database. They can do nothing except respond to requests and have no real lifetime outside of the 'respond to request world'. There are a lot of applications, obviously, that are like that, but importantly, there are also lots of applications that are not. If we want J2EE to be a virtual operating system then it needs to support these applications also. I'd like to be able to write a chat server that can deploy on your J2EE infrastructure and be very performant, be manageable, be highly available and scale because of servers provided from the J2EE infrastructure.

I'd like to see server components to be implementable using J2EE. Hence, the additions I pushed for in 5.0E. This added startup beans, threading (pooled and daemons), managed timers, safe callbacks/observer mechanism.

If we have this support then couldn't JCA connectors be implementable using a session bean? Rather than adding support to the JCA spec for threads, managed trans etc. Why not leave the JCA spec alone and instead define a mapping from the connector spec to the EJB session bean. This lets the JCA spec stay J2EE agnostic from an interface point of view and hence be implemented on any Java server product, not just J2EE. But, customers would be able to leverage their skills in J2EE to implement connectors if they choose using the JCA -> Session Bean bridge mapping.

Now, customers can use the normal tools to write connectors in a familiar programming model and toolset. The JCA spec stays simple and the managed stuff slowly making it's way in to JCA, instead comes as an enhancement to J2EE and makes that more useful.

What do you think? Reinvent the wheel or plugin a SB adapter and enhance J2EE.

Comments

[Andreas]

Billy, nice idea. Don't know if that is practical. At least it will take years to have that. When will WAS support JCA 1.5 adapters? Just curious, because I have finished mine in a couple of weeks.

[Billy]

WAS 6.0, J2EE 21.4 requires it, same as the other vendors. Wait for J2EE 1.4 CTS to go final and then certify.