The Great EJB Refactoring
by Kevin Bedell
Related link: http://www.jcp.org/jsr/detail/153.jsp
Anyone using the latest releases of the major J2EE containers is aware that the container providers are trying to become the hosts of choice for the quiet Web Service revolution that is speeding across the corporate landscape.
I'm working with both WebLogic and JBoss currently and I can see the writing on the wall. Next year I'll spend all my time turning the EJB's I've developed into Web Services. And I won't mind - for many applications this approach is much better than traditional EJB development. At a minimum it opens up EJB's to be accessible by client software written in any language on any platform (as long as the client software can access a web service).
The writing isn't only on the wall; it's also in the Proposed Final Draft for EJB 2.1 that was published this month by the Expert Working Group that is developing the EJB 2.1 specification. Some nuggets from the spec:
- Java-based Web Service clients must be able to invoke methods on Stateless Beans using JAX-RPC.
- non-Java-based Web Service clients must be able to invoke methods on Stateless Beans using SOAP 1.1 over HTTP/HTTPS.
- In addition to Home and Remote Interfaces, Session Beans can now also have a "Web Service Endpoint Interface".
So now EJBs=Web Services. And I can access my EJB's from any client software.
How are the container providers going to provide these services? Both JBoss and JRun are taking the approach of embedding Apache Axis - the newest Soap Engine from the Apache Software Foundation. Axis will be growing in visibility and should be on your radar screen - I'd wager that a year from now you'll see Axis embedded as the SOAP engine driving the JAX-RPC requirement in a number of major J2EE-compliant containers.
So how do you get ready? I'd recommend picking up some books on Web Services, downloading a copy of Axis and diving in.
After all, you've got a lot of refactoring to prepare for.