Application development using J2EE is perceived as very complex. Building Web Services using the J2EE platform is not a very good experience either. Unless you are using a good IDE like JDeveloper you have to take care of building/generation and packaging of several artifacts and deployment descriptors. Thus J2EE lacks to provide a good experience to developers intending to build SOA applications.
The primary goal for J2EE 5.0 is to simplify complexities of J2EE. Two key upcoming technologies EJB 3.0 (JSR-220) and Web services metadata (JSR-181) are trying to make development of applications easier by making use of metadata annotations and using a configuration by default approach.
I've been trying out with EJB 3.0 for a while and know for sure that it makes application development easier. I've been wondering for few months whether it is true that EJB 3.0 and Web Services metadata really make SOA development easy? Does use of metadata really make life of developers easier? There is a saying "Proof of pudding is in eating". So I thought I would try out myself. I decided to try migrating the J2EE 1.4 blueprint application- Java Adventure Builder to use EJB 3.0 and Web services metadata as an example for this exercise. This would be a good validation of these emerging technologies and opportunity for me to learn something new and try some fun things during my leisure.
From my past experience I know for sure that Adventure Builder is a very complex application with complicated build scripts that tied to Sun's RI. But certainly it is the most appropriate publicly available application that uses hosts of J2EE and Web services technologies. It’s an uphill task to migrate the application fully when specifications are not final and there are not any servers in the market that implements early releases of both of these specifications. Thankfully being a part of OC4J development team, I've access to development builds of OC4J that implements both EJB 3.0 and JSR 181 where I can deploy the migrated applications. It is worth mentioning that OC4J 10.1.3 will support both EJB 3.0 and Web Services metadata.
The Example - Java Adventure Builder
The Java Adventure Builder application has six modules. If you want to know more about the Adventure Builder look at my earlier blog. I took the simplest module (Bank) that has a SLSB with a web service end point to migrate to use EJB 3.0 and Web services metadata and here is the result.
I hacked the Sun's build scripts to include libraries from OC4J that include EJB 3.0 and Web service metadata classes.
The original Bank application has only two java sources required six XML descriptors including WSDL:
- application.xml
- ejb-jar.xml
- webservices.xml
- CreditCardService.wsdl
- CreditCardServiceMap.xml
- Oracle-webservices.xml
Here is the code for the endpoint interface and bean class of CreditCardService EJB after being migrated to EJB 3.0 and web services metadata.
end- point Interface
package com.sun.j2ee.blueprints.bank.creditcardservice;
import java.rmi.Remote;
import java.rmi.RemoteException;
import javax.jws.WebService;
import javax.jws.WebMethod;
@WebService(name="CreditCardIntfPort", targetNamespace = "urn:CreditCardService")
/**
* Interface for the credit card web service endpoint
* that receives credit card info
*/
public interface CreditCardIntf extends Remote {
@WebMethod public boolean validateCreditCard(String ccXMLString)
throws RemoteException;
}
Bean Class
package com.sun.j2ee.blueprints.bank.creditcardservice;
import javax.ejb.Stateless;
/**
* Web service end point for the Credit Card
* service that validates credit cards submitted
* by the OPC
*/
@Stateless(name="CreditCardIntfPort")
public class CreditCardEndpointBean implements CreditCardIntf {
/**
* Validate a credit card and return the status
*/
public boolean validateCreditCard(String xmlCreditCard)
{
//This is stubbed for now. Just returns true.
return true;
}
}
Migration Summary
After migrating to use metadata with EJB 3.0 and Web services metadata, I needed only one XML file i.e. application.xml. We no longer needed ejb-jar.xml with EJB 3.0 and rest of the web services descriptors can be generated during deployment or annotation processing tool.
So here is the summary:
|
Original |
After Migration |
|
Number of Java files |
2 |
2 |
|
Number of XML files |
6 |
1 |
|
Number of lines of Java
(Excludes Sun’s long copyright notice) |
58 |
46 |
|
Number of lines of XML
(Excludes Sun’s long copyright notice)
|
134
application.xml -14
ejb-jar.xml – 30
webservices.xml – 25
WSDL - 29
oracle-webservices.xml -18
Java-WSDL-Mapping file-18
|
14
application.xml
The others are either not required or generated during deployment |
Conclusion
After the migration I conclude that that use of metadata certainly makes development simpler. If you look at this simple exercise, using annotations Java code was reduced by almost 21%. Reduction in XML was a whopping 90% if default configurations are used. IDEs like JDeveloper or Web Services Assembly tools help generate these descriptors but still developers have to understand its relevance and package these with their application modules. Majority of J2EE’s complexities come from assembly and many developers wonder why they need these many descriptors to build a simple HelloWorld service. Taking these files away from developers view certainly reduces make developers life easy.
The Next Step
I will try to migrate another application module of Adventure Builder Application that uses most of the important technologies SLSB Web service, Entity Beans, MDB and invokes another web service.
So stay tuned!
Resources and References
EJB 3.0 Early release draft specification
Web Services metadata Proposed Final Draft specification
An Adventure with J2EE 1.4 Blueprints
Simplifying EJB development with EJB 3.0
EJB 3.0 Resource Center
Web Services Technology center
5:55:16 AM 
|
