Billy Newport (of IBM) has written about where J2EE CA is going (with 1.5), and how he feels there could be Another Way. Instead of making a lot of changes to J2EE CA (adding more info in the spec to do with threading and managed transactions) how about defining a mapping between connectors and Session Beans? In this case J2EE CA doesn't get tied to other J2EE apis, but allows users to implement connectors via the Session Bean bridge mapping if they desire.

"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."

This is important stuff. These are things that an Enterprise API should have. With all the talk on making EJB 3.0 simple, I hope they don't forego the fact that this is an ENTERPRISE API, and think about what is lacking in that arena.

Read Billy Newport: JCA, a thread too far

What do you think of Billy's thoughts?

Generally I agree the author's idea. But the real problem IMO is not JCA itself, it's EJB. Even JCA 1.0 adapter is not easy to implement if you never have a chance to read JCA spec.

EJB makes things worse. There are too many limitations, such as threading, singleton, lifecycle management, file IO, callback. For example, if I want to develop a component which acts as a socket server, but inside this socket server component I also want to use EJB and transaction. It's almost mission impossible to have a portable way to achieve this. We have to use proprietary way, i.e. startup class(WebLogic, WebSphere) or service(in JOnAS) to implement such feature.

IMO, We really need to revise EJB spec, whenever we get benfits from EJB, we always get the same amount trouble.

EJB technology, and J2EE in general, is aimed at a modal architecture (something like PetStore for example). It is a solution that catches maybe 90% of enterprise architecture requirements in its net.

The problem, as I see it, is that chasing the remaining 10% or so might lead to a geometric increase in bloat.

I'd rather have a skinny J2EE that does *most* of the stuff we expect from an enterprise framework, and leave things like plain RMI on the back shelf for developers to roll their own special case solutions where necessary.

jm2c...

Please note that JCA connector can be used in non managed environment (i.e. outside of J2EE container). So, even if that idea may look interesting in general, it will broke the general contract between connector and allication using that connector, so it will be even more difficult to use it standalone.

I somehow agree that it can be difficult to write a connector. Buf from other hand, it is much easier to reuse existing connector, so the whole idea is to have enough 3rd party connector providers or even better ask vendors to provide connectors for their EIS.

Yes, that's why the author advocates to NOT mess with the JCA spec. He suggests the the JCA spec should be left as it is now. However, since many people want to take advantage of a managed environment (J2EE), he suggests a standard and simple way to do that, using an existing framework (Session Beans).

This sounds fair to me. If you don't want J2EE, you can simply stick to the standard JCA specification. However, if you need interaction with a J2EE server, there would be a simple way to do that, using Session Beans.

Like in our EAI suite, we are basically wrapping "custom app" in JCA and session beans looks up for the required JCA.
Session beans as a facade.

ETLEngine is a JCA, BusinessProcessEngine (Webservice) is JCA,
Connectors to Enterprise APP is a RAR.
so its kind of cool and works.

Thanks
Sudhi

One of the great advances with JCA 1.5 is that it allows your legacy software to drive the processing of data through your J2EE application.

One problem with the current J2EE model is that it is assumed that processing is driven by either web interaction or MDBs. What if you are connecting to legacy systems that prompt your business processes, but do not use JMS or webservices? With JCA 1.5 you can poll your legacy system and drive the processing that way. Otherwise you have to write a client external to the managed containers, which kind of defeats a lot of the purpose of having a managed environment.

Is there a proposed change to the EJB spec that would allow you to use Session Beans to drive the business processing unprompted? If not, we still need the changes to JCA.

Well,
That was the idea. Enhance J2EE so that applications can do the things you describe. So 'fix' J2EE rather than JCA. Either way, we need changes, I'm just suggesting make the changes to J2EE rather than JCA.

Billy
(All opinions are my own and may not reflect those of my employer, IBM)

Can u plz put light on...how to deploy/change Application that follows JCA 1.5 architecture on App servers (Websphere ,WebLogic etc) which are compatible with JCA 1.0 till date......