J2EE 1.4 eases Web service development
Tutorial Details:
J2EE 1.4 eases Web service development
J2EE 1.4 eases Web service development
By: By Frank Sommers
Java's new Web service client and server programming models
t 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.
Web service-related J2EE extensions
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.
A J2EE-based service's client does not have to be aware of how a service is implemented. Rather, that client can use the service by relying entirely on the service's WSDL (Web Services Description Language) definition. (Previous JavaWorld Web Services columns explain how to discover services based on their WSDL definitions, and how to create and use WSDL definitions. See Resources for links.) While the J2EE specs do not spell out the exact mechanics of such interaction, J2EE 1.4's embrace of the WS-I Basic Profile, which Microsoft also claims to follow, will likely make J2EE-.Net interaction common.
To facilitate access to WSDL definitions, J2EE 1.4 adds support for the JAXR (Java API for XML Registries) standard. The JAXR libraries are now a required part of the J2EE application client, EJB (Enterprise JavaBeans), and Web containers (not the applet container, though). Since WS-I Basic Profile mandates support for UDDI (Universal Description, Discovery, and Integration) 2.0, J2EE clients, as well as EJB components and servlets, can interact with public Web service registries. (" Web Services Take Float with JAXR " ( JavaWorld, May 2002) offers a tutorial on JAXR.) Figure 1 illustrates the additional Web service-related libraries supported by J2EE 1.4.
Figure 1. Web service-related library support in J2EE 1.4
Indeed, J2EE takes the view that a Web service is an implementation of one or more interfaces defined by a WSDL document. The operations described in WSDL are first mapped to Java methods following the JAX-RPC specification's WSDL-to-Java mapping rules. Once a Java interface corresponding to a WSDL file is defined, you can implement that interface's methods in one of two ways: as a stateless session bean running in the EJB container or as a Java class running in the J2EE servlet container. Finally, you arrange for the respective container to listen for incoming SOAP requests and map those requests to the respective implementation (EJB or servlet). To process incoming SOAP invocations, J2EE 1.4 mandates the JAX-RPC runtime as an additional J2EE container service.
In keeping with the J2EE architecture, a service implementation's container mediates access to a Web service: if you expose either an EJB component or a servlet as a J2EE Web service, your service's clients can invoke that service only indirectly, via the container. That allows a service implementation to benefit from the container's security, thread management, and even quality-of-service guarantees. In addition, containers let you make important Web service decisions, such as security constraints, at deployment time. Finally, J2EE's container-based model makes Web service deployment portable: you can develop a Java-based Web service using any J2EE tool and expect that service to run in any other compliant container implementation.
A Web service client, on the other hand, remains unaware of a Web service container's presence. Instead, the client sees a port representing a network endpoint instance of a Web service. That endpoint follows the JAX-RPC service endpoint interface (SEI) model and provides an implementation of the service's interface. A client views each J2EE Web service as an SEI and port combination. A single J2EE container can host many such combinations, as Figure 2 illustrates. Each SEI/port combination is an instance of a Web service.
Figure 2. A client's view of a Web service
Note that the client in this architecture can be either a J2EE client, running inside the J2EE client container, or a non-J2EE client. Any WS-I Basic Profile-compliant client can use a J2EE Web service, but each client may follow different programming models. The J2EE Web services specification outlines a programming model for clients that run inside the J2EE application client container and another model?the server programming model?for Web service implementations that execute in the EJB or servlet containers.
The J2EE Web service client programming model
The essence of the Web service client programming model is to streamline the use of APIs defined in JSRs 67 (Java APIs for XML Messaging, JAXM), 93 (JAXR), and 101 (JAX-RPC), and to provide a comprehensive framework for using those APIs together in the J2EE client container.
In keeping with the J2EE client programming model, a Web service client is remotable and provides local/remote transparency. The Web service port provider and the container that the port runs in define how a client sees a Web service. The client always accesses the port and is never passed a direct reference to a Web service's implementation. A J2EE Web service client remains unaware of how a port operates and must concern itself only with the methods a port defines. Those methods constitute a Web service's public interface. In addition, a client must consider access to a Web service port as stateless across service invocations. As far as the client is concerned, a port lacks a unique identity?a client has no way of determining if it communicates with identical ports across service invocations.
The client gains access to a port based on the port's service interface. J2EE Web services rely on JAX-RPC to define the relationship between a port and its service interface. JAX-RPC creates that relationship based on WSDL processing rules. Thus, the Web service's WSDL definition ultimately governs the port's behavior. Based on the JAX-RPC definition, the service interface can either be a generic interface directly implementing the javax.xml.rpc.Service interface, or a "generated service," which is a subtype of that interface. The latter interface type is specific to a Web service's type.
In the J2EE programming model, the client obtains a reference to a Web service's Service object via a JNDI (Java Naming and Directory Interface) lookup operation. The JNDI lookup occurs by a logical name, or service reference, for the Web service. As with all directory-based resources, a client must declare what resources it needs in its deployment descriptor (more on that later).
The Java Web services specification (JSR 109) recommends that all Web services be subsumed under the JNDI service subcontext. The client container binds the service interface described by that reference under the java:comp/env client environment naming context. By declaring a service reference in the client's deployment descriptor, the client container ensures that the referenced service is available in JNDI-aware resources. The following code snippet shows how to obtain a reference to a J2EE-based Web service via JNDI lookup:
InitialContext ctx = new InitialContext();
Service myService = (Service)ctx.lookup("java:comp/en
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: J2EE 1.4 eases Web service development
View Tutorial: J2EE 1.4 eases Web service development
Related
Tutorials:
 Solid JRun serves
up Java on a budget - JavaWorld June 2000
Solid JRun serves
up Java on a budget - JavaWorld June 2000
|
Connect the
enterprise with the JCA, Part 1
Connect the
enterprise with the JCA, Part 1
|
Use Web services
to integrate Web applications with
EISs
Use Web services
to integrate Web applications with
EISs
|
Ilog JRules 4.0:
Working by the rules
Ilog JRules 4.0:
Working by the rules
|
Discover and publish Web services with JAXR
Discover and publish Web services with JAXR
|
Is the JCP adequately preparing Java for Web services?
Is the JCP adequately preparing Java for Web services?
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
All that JAAS
All that JAAS
|
Sun boosts
Sun boosts enterprise Java
|
Jump the hurdles
of Struts development
Jump the hurdles
of Struts development
|
J2EE 1.4 eases Web service development
J2EE 1.4 eases Web service development
|
The J2EE 1.4 Tutorial
The J2EE 1.4 Tutorial is a guide to developing enterprise applications for the Java 2 Platform, Enterprise Edition (J2EE) version 1.4. Here we cover all the things you need to know to make the best use of this tutorial.
|
SAAJ: No strings attached
SAAJ: No strings attached
|
Java Testing and Design
Java Testing and Java Test and Design is the companion to any book on Java software development practices, techniques, and testing. Software developers, QA analysts and IT managers working in large corporate IT groups, software development companies, and
|
Apache Geronimo
Apache Geronimo
Welcome to Apache Geronimo, the J2EE server project of the Apache Software Foundation. Please help us make this a world class, certified J2EE container!
|
Turn EJB components into Web services
Summary
Web services have become the de facto standard for communication among applications. J2EE 1.4 allows stateless Enterprise JavaBeans (EJB) components to be exposed as Web services via a JAX-RPC (Java API for XML Remote Procedure Call) endpoint, al
|
A first look at Apache Geronimo
Start developing and deploying J2EE apps on the first open source J2EE server. When released, Geronimo will be the first J2EE-certified open source server. This article will give you the basics you need for developing and deploying J2EE applications on Ge
|
Interoperability with Patterns and Strategies for Document-Based Web Services
In Part 2 of this article, we demonstrate interoperability for document-driven web services with Microsoft .NET (C#) using strategies discussed in Part 1.
|
NetBeans IDE 4.1
Out-of-the-box support for J2EE 1.4 and Web Services. Check out what early access release 2 can do for you!
|
|
|
|
