Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
At the conclusion of his J2EE (Java 2 Platform, Enterprise Edition) Web services presentation at last year's JavaOne, IBM architect Jim Knutson remarked that "every Web service needs a place to be a service." He then suggested that the most ideal place to be a Web service was inside the J2EE infrastructure. A little more than a year later, the final release of J2EE 1.4 is imminent, and its most significant promise is to deliver on the J2EE Web services vision.
The Web service features in J2EE 1.4 address both the server and client sides of Web services. The features extend J2EE to allow existing server-side enterprise Java components to become Web services and specify how a J2EE client container can invoke Web services. The technologies for both aims have existed for a while, and the new J2EE specs rely on those existing APIs for Web services support. The new specs add to the existing technologies a set of interoperability requirements, and a programming and deployment model for Web service integration.
There are two specifications that explicitly outline those added features: Java Specification Request 151, the umbrella JSR for J2EE 1.4, and JSR 109, Web Services for J2EE. At the time of this writing, JSR 109 has reached its final stage in the JCP (Java Community Process), while JSR 151 is in the last voting phase. Additionally, the JCP amended the final release of JSR 101, Java APIs for XML-based Remote Procedure Call (JAX-RPC), to support J2EE 1.4 interoperation requirements.
J2EE 1.3-level application servers can also implement many of the features prescribed by these JSRs. Indeed, many application server vendors have supported various Web service development and deployment features in their existing products for some time now. JSRs 109 and 151 codify some existing practices and describe new mechanisms with the hope of creating a universal J2EE-Web services integration model. Next-generation application servers will likely follow that unified, standardized model.
Following a brief survey of new Web service-related J2EE features, this article reviews the new client and server programming models, including new J2EE deployment and service management roles associated with Web services support.
Perhaps the most significant, and most consequential, additions to J2EE are the new interoperation requirements. The requirements prescribe support for SOAP (Simple Object Access Protocol) 1.1 in the J2EE presentation layer to facilitate XML message exchange. J2EE 1.4-compliant containers must also support the WS-I (Web Services Interoperability Consortium) Basic Profile. Since XML message exchange in J2EE depends on JAX-RPC, the JAX-RPC specifications now mandate WS-I Basic Profile support as well.
The result is that a J2EE 1.4-based application can be invoked as a Web service, even from applications not written in the Java programming language. While that is an evolutionary step for J2EE, since the platform has long embraced non-Java based systems, it is possibly the most direct way to facilitate interaction with Windows-based technologies that rely on .Net.
Archived Discussions (Read only)