ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Constructing Services with J2EE

by Debu Panda
05/25/2005

Web services are now a popular technology for implementing service-oriented applications. J2EE has become a popular platform to deploy web services applications. And J2EE 1.4 standardized building and deploying web services applications for the Java platform.

In my last article, I provided an introduction to service-oriented architecture (SOA) from a Java developer's perspective. In this article, I will explain how you can use J2EE 1.4 to build services that are interoperable and portable across J2EE 1.4-compliant application servers such as Oracle Application Server 10g.

Web Services Architecture

Let's briefly examine the architecture of a web service before drilling down into the details of web services development and deployment on the J2EE platform.

There are many definitions for web services, but in simple terms, web services are self-contained and self-describing components that can be published, discovered, and invoked across the network. A web service, as shown in Figure 1, may perform a simple function, such as checking a credit history, or a complicated task that can span several business processes.

Figure 1
Figure 1. How a web service works

There are two methods of interaction with web services: RPC style and document style. RPC-style web services were initially popular in the industry, but in recent years have been eclipsed by document-style as the preferred means of message exchange with web services.

Related Reading

Java Web Services in a Nutshell
By Kim Topley

RPC-style web services represent exchanges that can be modeled as remote procedure calls (RPC). These are quite common in business applications, with the exchanged messages conforming to a well-defined signature for the remote call and its return. In contrast, document-style web services model XML document exchange, where the exchange patterns are defined by the sending and the receiving applications. Document-style services are more relevant for applications that need to exchange business or other types of documents and, unlike RPC-style web services, the sender may not expect or wait for an immediate response.

Most developers would agree that web services is an effective technology for implementing SOA because it provides interoperability between heterogeneous platforms and technologies relying upon portable technologies such as XML, SOAP, and HTTP.

This independence of platform and implementation technology is the primary reason for web services' popularity. The clients do not have to know the implementation technology involved and can simply invoke the service over the network. For example, even if you build a service using Java/J2EE technologies and deploy it on a J2EE server such as Oracle Application Server Containers for J2EE (OC4J), the clients can be built using Microsoft's .NET framework.

Now that we have a basic understanding of web services, let's take a look at the elements that make up a web service.

What Are Web Services Made of?

A Web Services Definition Language (WSDL; pronounced "wizdle") document is at the heart of a web service. The WSDL describes the service, and is the "contract" to which the web service guarantees it will conform. The WSDL provides a complete description of the web service, including the port, operations, and message types involved.

Here is a simple example of a WSDL document that describes a HelloWorld web service:


<definitions 
 name="HelloService" 
 targetNamespace="http://oracle.j2ee.ws/ejb/Hello"
 xmlns="http://schemas.xmlsoap.org/wsdl/" 
 xmlns:tns="http://oracle.j2ee.ws/ejb/Hello" 
 xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
 xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" 
 xmlns:ns1="http://oracle.j2ee.ws/ejb/Hello/types" 
 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> 
 <types> 
  <schema elementFormDefault="qualified" 
  targetNamespace="http://oracle.j2ee.ws/ejb/Hello/types" 
   xmlns="http://www.w3.org/2001/XMLSchema" 
   xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:tns="http://oracle.j2ee.ws/ejb/Hello/types" 
   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
  <complexType name="sayHello"> 
    <message name="HelloServiceInf_sayHello"> 
      <part name="parameters"
        element="ns1:sayHelloElement"/> 
    </message> 
    <message name="HelloServiceInf_sayHelloResponse"> 
      <part name="parameters" 
        element="ns1:sayHelloResponseElement"/> 
    </message> 
    <portType name="HelloServiceInf">
      <operation name="sayHello"> 
        <input message="tns:HelloServiceInf_sayHello"/> 
        <output message="tns:HelloServiceInf_sayHelloResponse"/>
      </operation> 
    </portType> 
    <sequence> 
      <element name="String_1" nillable="true" type="string"/> 
    </sequence> 
  </complexType> 
  <complexType name="sayHelloResponse"> 
    <sequence> 
    <element name="result" nillable="true" type="string"/> 
    </sequence> 
  </complexType> 
  <element name="sayHelloElement" type="tns:sayHello"/> 
  <element name="sayHelloResponseElement" 
    type="tns:sayHelloResponse"/> 
  </schema>
 </types> 
 <binding name="HttpSoap11Binding" type="tns:HelloServiceInf"> 
 <soap:binding style="document" 
      transport="http://schemas.xmlsoap.org/soap/http"/> 
 <operation name="sayHello">
   <soap:operation 
      soapAction="http://oracle.j2ee.ws/ejb/Hello:sayHello"/> 
   <input> 
     <soap:body use="literal" parts="parameters"/> 
   </input>
   <output> 
     <soap:body use="literal" parts="parameters"/> 
   </output> 
 </operation> 
 </binding> 
 <service name="HelloService"> 
   <port name="HttpSoap11" binding="tns:HttpSoap11Binding"> 
     <soap:address location="REPLACE_WITH_ACTUAL_URL"/> 
   </port>
</service>
</definitions> 

If you look at the WSDL, you'll note that it has a complete description of the HelloService web service, including the port, operations, and message types. The WSDL is the contract between the web service and its clients and it help automate the generation of client proxies.

The other two key technologies of the web services platform are SOAP, the protocol used to invoke a web service, and UDDI, which provides the registry where web services can be located.

Support for these technologies is fully integrated into the J2EE platform. Let's take a look at J2EE's web services support.

Using J2EE as a Web Services Platform

J2EE 1.4 provides a comprehensive platform for building and deploying web services applications using regular Java classes or Enterprise Java Beans. The following table provides the details of the web service APIs included in J2EE 1.4.

Java APIs Description

JAX-RPC /JSR 101

Java API for XML Remote Procedure Call: API for building web services and clients with remote procedure calls (RPC) and XML

Enterprise Web Services/ JSR 109

J2EE Deployment Model for Java Web Services

SAAJ

SOAP with Attachments API for Java: Enables developers to produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments

JAXP

Java API for XML Parsing: The reading, manipulating, and generating of XML documents through Java APIs in a standard way

JAXB

Java API for XML Binding: Automates the mapping between XML documents and Java objects

JAXR

Java API for XML Registries: Provides a standard way to access business registries, such as UDDI, and share information

EJB 2.1

Provides ability to expose Stateless Session EJB with web service end-point

JAX-RPC

JAX-RPC, defined under JSR 101 in the Java Community Process, provides the Java API for building and accessing web services and is thus the "heart and soul" of building and deploying web services with the J2EE platform. It provides a simple, robust platform for building web services applications by hiding from the application developer the complexity of mapping between XML types and Java types and the lower-level details of handling XML and SOAP messages. It introduces a method call paradigm by providing two programming models: a server-side model for developing web service endpoints using Java classes or stateless EJBs, and a client-side model for building Java clients that access web services as local objects. JAX-RPC 1.1 mandates the use of SOAP 1.1 and interoperability with web services built with other technologies such as Microsoft .NET. J2EE-1.4-compliant application servers, such as OC4J 10.1.3 and the Sun Java System Application Sever, provide support for JAX-RPC.

JAX-RPC is somewhat of a misnomer, since it supports both RPC-style and document-style web services.

Web Services Deployment Model

Prior to J2EE 1.4, all J2EE vendors supported web services using their proprietary deployment models. J2EE 1.4 defined the deployment model for Java web services. It standardized development, deployment, and service publication and consumption for web services for the J2EE platform.

I will discuss the deployment and consumption aspects of Java-based web services later in this article.

Given the J2EE 1.4 support for web services, let's examine the way in which a web service is constructed using the J2EE platform.

Pages: 1, 2

Next Pagearrow