• No results found

Java API for XML Web Services (JAX-WS)

In document Developing Java Web Services_INTL (Page 149-154)

5.2.1 ‘Big’ Web Services

5.3 Java API for XML Web Services (JAX-WS)

Web services support a few standards that help to develop interoperable applications. The key standards are as follows:

‡ WSDL – To define the service

‡ SOAP protocols – To exchange XML messages over different transport protocols (HTTP, SMTP, and JMS)

‡ Java API for XML-based Remote Procedure Call (JAX-RPC) – To invoke a Web service on Java platform

To invoke Java Web services, JAX-RPC has defined a few APIs based on its own data bindings.

These APIs support SOAP protocol over HTTP to exchange XML messages. To align with the support for new industry standards, JAX-RPC was modified and was renamed with JAX-WS.

Hence, JAX-WS is the successor of JAX-RPC 1.1 aligned with the new standards to develop Web services on Java EE platform.

JAX-WS supports annotations that make development of Web service applications simple and easy. It uses JAXB 2.0 for data binding and helps in customization to control generated Service Endpoint Interface (SEI). It reduces the size of runtime jar files. It assists the document-oriented Web services and Remote Procedure Call (RPC) Web services.

JAX-WS

Session 05

5.3.1 JAX-WS Standards

Table 5.3 shows the new standards of JAX-WS programming model.

Standard Description

SOAP 1.2 It is a lightweight protocol for structured information exchange of text and binary data.

XML/HTTP It assists in transforming XML messages over transport protocol, HTTP without SOAP.

Web Services Interoperability (WS-I)

It has WS-I Basic Profile document that has specifications for SOAP and WSDL. WS-I Basic Profile 2.0 has the specified encoding styles, proxy generations, and dynamic invocation of interfaces.

Data Mapping

Model It specifies the mapping of XML elements to Java classes. JAXB 2.0 promotes the mappings for all XML schemas. It is supported by JAX-WS for data mapping.

Interface

Mapping Model It is used to map service interfaces with service implementation classes.

Dynamic Programming Model

It is used for message-oriented invocations and asynchronous invocations.

Handler Model It processes the SOAP message before and after the messages are sent over the network in the Web service development.

Table 5.3: Standards for JAX-WS Programming Model

5.3.2 Features of JAX-WS

Following are the key features of JAX-WS programming model that help in developing the Web services on the JEE platform:

‡ Platform Independence: The development of Web services for server and client-side applications is simplified to achieve better platform independence. A proxy class called as delegate class is generated internally by JAX-WS. It is an improvement over vendor-specific stubs used in JAX-RPC implementation. This class has all the methods of the Web service and processed annotations to identify it as Web service.

‡ Annotations: JAXWS has a library of annotations that help to convert Plain Old Java Objects (POJO) to Web services. These annotations define the information obtained from the deployment descriptors. In the Web service class, additional metadata information can be added on method level or on the parameters of the methods.

Annotations help to expose Java artifacts as Web service.

‡ Invocation of Web Services: There are two types of client-side invocations supported by JAX-WS. They are synchronous and asynchronous invocation.

JAX-WS

Session 05

• Synchronous invocation – In this, a client sends a request for invocation of a service and waits till the response is received from the server.

If there is an immediate response, then synchronous communication has to be used. RPC-oriented Web services are based on synchronous invocation.

• Asynchronous invocation – In this, the client sends the request to the service endpoint. The client need not wait for the response to be returned from the Web service. Document-oriented Web services are based on asynchronous invocation. There are two types of asynchronous invocation approaches. They are:

Š Polling approach – In this, the client first sends a request to the Web service endpoint and gets an object as response. This response is polled to know whether the server has responded. When the server sends an actual response, it is received in the response object.

Š Callback approach – In this, a callback handler, provided by the client receives the response object and processes it.

‡ Data Binding with Java Architecture for XML Binding (JAXB 2.0): JAX-WS, the successor to JAX-RPC, does not define any Java/XML binding. JAX2.0, defines

standards for binding Java and XML schemas as part of JAX-WS deployment. JAXB2.0 abstracts the conversion of XML schema components and assists JAXB binding customization.

‡ Support for SOAP 1.2: JAX-WS supports SOAP 1.2. Binary attachments such as images or files are sent as Web service request using SOAP 1.2.

‡ Support for Message Transmission Optimized Mechanism (MTOM): MTOM is a mechanism supported by JAX-WS for optimized transmission of binary data in Web service.

‡ Dynamic and Static Clients: JAX-WS supports a dynamic client API called javax.ws.

Dispatch. Dispatch API is a low-level API, which requires construction of a XML based messages by the client. The data is sent in PAYLOAD mode or MESSAGE mode. These modes are defined as constants in the dispatch client. The constants are as follows:

javax.xml.ws.Service.Mode.PAYLOAD and javax.xml.ws.Service.Mode.MESSAGE.

• PAYLOAD mode – In this mode, the client provides only the contents of

soap:Body element. The soap:Envelope and soap:Header elements are added by the JAX-WS in the SOAP:Envelope element.

• MESSAGE mode – In this mode, the client provides the entire soap envelope.

The soap envelop has soap:Envelope, soap:Header, and soap:Body elements.

JAX-WS adds no extra information in the message. It supports static client programming model known as proxy client. In this model, proxies are created from the generated SEI at client. Then the methods are invoked on the proxies in the client application.

‡ Development Tools: JAX-WS supports two command tools for Web service

JAX-WS

Session 05

They are as follows:

• wsimport tool: This tool is used when Web service is developed with the WSDL file. It generates the Web services portable artifacts. The tool processes WSDL file to generate Web service implementation class, service interface, and the underlying JAXB2.0 Java classes from XML schema elements.

• wsgen tool: This tool is used when the Web service development is with

implementation class. It generates Web service artifacts such as Java interfaces and WSDL from Web service implementation class.

5.3.3 Web Service Stack

The JAX-RPC has its own data binding and parsing mechanism. However, JAX-WS data binding and parsing are based on the JAXB and StAX, the standards proposed by Sun.

Figure 5.3 shows the Web service stack for JAX-RPC and JAX-WS proposed by Sun. It shows the standards of JAX-WS and its comparison with JAX-RPC, which is the initial implementation of Web services.

Figure 5.3: Web Service Stack for JAX-RPC and JAX-WS

5.3.4 JAX-WS Architecture

The JAX-WS architecture is based on the generation of dynamic proxy class instance. This instance is responsible to send and receive the SOAP request and SOAP response to the client and server. Figure 5.4 shows JAX-WS architecture.

JAX-WS

Session 05

Figure 5.4: JAX-WS Architecture Following are the steps to invoke the Web:

1. At the server-side, the development of JAX-WS starts with an annotated Web service implementation class. This implementation class is deployed on an application server. Then, the wsgen tool generates the WSDL file, which has information on service methods and the SEI. While deploying, a server side proxy instance is generated to handle the request and response.

2. At the client-side, the Web service is invoked using a command tool called wsimport. This tool is a WSDL to Java mapping tool. It generates the SEI on the client-side. Then, the client code for accessing the Web service is compiled and executed.

3. After the execution of client application code, JAX-WS runtime generates a proxy class instance. This instance internally implements the generated SEI. The proxy class is invoked by the getPort() method from javax.xml.ws.Service class. The generated proxy instance is used for invoking the Web service method.

4. After invoking the method on Web service by the client, the JAX-WS runtime uses JAXB to marshal the parameters of the method. Then, these objects are

encapsulated in SOAP message in XML format. These are sent as a SOAP request across the network. The parameters are passed to proxy instance to be passed to the service present at the server.

JAX-WS

Session 05

Unmarshalling converts the SOAP message having XML schema elements into Java objects. The message is given to the server-side proxy to execute the Web service method.

6. At the server, the result of the Web service method is marshalled again using JAXB.

JAXB wraps the response in the SOAP message, to enable the server-side proxy to send it back to the client.

7. At the client-side, the JAX-WS runtime unmarshalls the SOAP response message using JAXB. Then it passes the unmarshalled Java object to the proxy. The proxy returns the result from the Java object to the client application.

In document Developing Java Web Services_INTL (Page 149-154)

Related documents