Web service integration mode for Java applications using open source code frameworks. Part 1: Implementation of the call mode

Level: Intermediate

Sukriti Goel (sukriti_goel@infosys.com), Technical architect, Infosys Technologies Limited
Parameswaran seshan (parameswaran_seshan@infosys.com), Technical architect, Infosys Technologies Limited

August 28, 2006

This series discusses the Web service integration mode, which consists of two parts. This article describes how to integrate the requirement-response and notification web service client endpoint mode with the application. In request-response and notification modes, an application acts as a web service and is deployed on a Web server, allowing external participants to call the application as a web service. The steps in this article use document-style Web service calls.

Introduction

In section 1st, we discuss how to apply request-response and one-way mode to Web service endpoints. In part 2, you will learn how to apply the other two modes (requirement-response and notification) to the Web service client (caller) endpoint. Let's consider an example of application integration scenario: assume there is an application, such as the travel booking application ("app1"), which contains various components. As a reference for our discussion, this application receives input from customers, such as outgoing location, destination, and credit card information for travel. The application is then integrated with other applications (such as the Credit verification system ("app2") to book tickets. In addition, a payment application ("app3") is required "). App2 discloses a web service to verify the credit card, while app3 deducts the corresponding amount from the credit card to process the payment. App1 exposes two web services. One Web Service receives messages from app3 (used to process payment confirmation requests) as input, and then sends a confirmation ("continue") message, another Web Service receives the "Payment completed notification" Message from app3.

In request-response mode, an endpoint is a client that sends messages to the service endpoint that is expected to return a response and receives the relevant messages returned from the service endpoint. In our example, when app3 is ready to process the payment request and app1 returns a confirmation ("continue payment") message, app3 calls the "payment request confirmation" Web Service published by app1. For the app app3 discussed here, this is the requirement-response operation.

In notification mode, the endpoint of the role of the client that sends a message to the service endpoint does not expect a response from the service endpoint. In this example, the "Notification payment completed" Web Service is published by app1 and called by app3 after the payment is processed. For app3, This is a notification operation.

On the other hand, for app2's Credit verification Web Service (app2 accepts credit card information as input, verifies the credit card, and sends a response message informing the credit card that it has been approved or rejected ), this is the request-response operation when the ticket booking application app1 calls this service. Similarly, for the "Payment" Web Service published by the payment application app3, this is one-way operation when app1 calls the service, because app1 can continue to execute some other tasks after sending the message.

From the perspective of APP app1, we regard integration with external app app3 based on the requirement-response mode as a "synchronous service" activity, the notification is regarded as an "Asynchronous receipt" activity. That is to say, in request-response and notification, our reference point application app1 becomes a service provider (service endpoint) and receives messages from the client.

In this article, you will learn how to implement these two modes in such applications (assuming that they are based on Java) to receive Web Services.

Back to Top

Open source code framework for Web service implementation

Web services and clients can be implemented using various open source code frameworks. For this article, we will use the Apache axis open-source framework to implement web services, and also use Java architecture for XML binding [SG3] (jaxb [I2]) and Java Message Service (JMS ).

Requests sent from application client endpoints

In this section, you will learn how to implement synchronous services and asynchronous receiving modes for Web service operations based on Simple Object Access Protocol (SOAP) in applications. For this discussion, we will assume that a document-style Web service call is used. If an external client sends messages to an application for processing, synchronous service and asynchronous receiving are particularly useful.

Synchronization Service

For synchronous services, an application acts as the service implementation endpoint, while an external participant calls the client of the public service. An example of the synchronization service is an external monitoring system. The external monitoring system can send requests to understand the status of application processing, and the application can provide status information.

As defined in the Web Service Description Language (WSDL) syntax, the request-response operation contains the input and output elements, first output, and then input, as shown in Listing 1.

Listing 1. Request-response operation WSDL

<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType ></wsdl:definitions>

In this example, the application exposes a Web Service (SOAP) for each application requirement ). The service needs to receive input parameters from the external client and return the output parameters to it, which are also defined in WSDL. These output parameters are usually related to the application status. The Client Connecting to the application from the outside needs to obtain the status from the application. This WSDL will be provided to the client that wishes to call this service to provide details about the input message, Output Message, and http port or JMS port that provides the service. This Web Service supports using soap over HTTP or JMS as the transmission protocol.

Applications can use the Apache axis server to implement this asynchronous service type of activity. The Web service runs once on the axis server (during application installation ). The service implementation class is also part of the application.

When an external client calls this service, the Axis server engine receives the SOAP request message and uses the parameter received in the request message as element (Org. w3C. dom. element) object array provides methods for service implementation classes. This method must be bound to a Java object using XML, so jaxb is actually used for it. By using jaxb, construct the Java object corresponding to the input XML Element and put it into hashmap. Then, the application's API method is called and the hashmap is provided as the input. This API method obtains the information required by the caller from the application, constructs a hashmap, and places this information as an output parameter object to hashmap. This hashmap will return to the service implementation method. At the same time, the application will continue to process. To better understand this, see the sample code in Listing 2.

The service implementation method uses jaxb to bind Java to XML in hashmap, so that it can be converted to XML elements in the form of an array of org. W3C. Dom. element. This element array is the caller's output parameter set and will be returned to the axis server. Next, the Axis server constructs a response to the SOAP message using the output parameter elements and sends the response message back to the external client.

List 2. Service implementation method getactivitystate exposed as a Web Service

public Element[] getActivityState(Element[] inElements){Element[] retElements;String activityName = null;String requestOperation = null;if ((inElements[0].getChildNodes().getLength() == 1) && inElements[0].getFirstChild().getNodeType() == Node.TEXT_NODE){activityName = inElements[0].getFirstChild().getNodeValue();};if ((inElements[1].getChildNodes().getLength() == 1) && inElements[1].getFirstChild().getNodeType() == Node.TEXT_NODE){requestOperation = inElements[1].getFirstChild().getNodeValue();};ApplicationAPI appAPI = ApplicationAPIFactory.getInstance().getApplicationAPI();if (requestOperation.equalsIgnoreCase("getActivityData")){HashMap retData = appAPI.getDataFromActivity(activityName);}// use JAXB to convert each object value in the HashMap to // its corresponding Element object. Populate the // array of Element objects retElements with these Element objects.return retElements;}

In the preceding scenario, the service implementation method can also view the input XML element array and determine which API method in the application needs to be called (depending on the information type requested by the external client ). For example, even if different types of monitoring requests are supported, a class with a unique method can support different types of requests. However, multiple services can be deployed on the axis server. One Service corresponds to one request type, all the details of these services and input and output messages can be defined in a WSDL published to an external client.

For JMS transmission, the application can use the openjms server (JMS implementation) to process JMS messages (including soap messages as content ). A single queue is opened for each Web Service exposed by the application on the openjms server, and a message listener is created for this queue (this operation will be performed once when the application starts ). As discussed in the previous section, if an application exposes multiple services and only one service implementation method and class is used for all these services, the message listener of each queue is bound to a service published by the application. When any message is received in the queue, the message listener calls the axis engine, then, set the service name (that is, the same service name as the HTTP service defined above) in the engine of the bound service, and then provide the SOAP request message to it. The engine then calls this service method (that is, the same method described in the previous section ).

Asynchronous receiving

In this example, the application acts as the service implementation endpoint, and the external client sends the message used by the application. No response is sent back to the external client. After the external client sends the SOAP request message to the Web service, it does not wait for any response. It will proceed with subsequent processing. Asynchronous receiving is especially useful if the external client needs to control the processing of some applications. For example, an external client can trigger a process in an application; it can also end or stop the application, as shown in listing 3.

As defined in the WSDL syntax, notification operations only have output elements.

Listing 3. Notification operation WSDL

<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:portType ></wsdl:definitions>

An external client can send a SOAP request to the Web service through JMS transmission. This request is a one-way message. The Web Service is published on the axis server. The JMS receiving queue is set on the openjms server during application startup. The implementation of this mode is the same as the implementation of the synchronization service involving JMS described by the Synchronization Service Department. after calling the application's API method, the service implementation method does not receive any output parameters (a notification) from the API method ). The API method performs related operations on the application status according to the request in the input parameters received from the external client.

Conclusion

In this article, we discuss the requirements for Web service client endpoints-response mode and notification mode, it also learned how to use the corresponding web services related to the open source framework to support integration of applications with clients based on these two modes.

By using the corresponding frameworks (such as axis and jaxb) and transmission protocols (such as HTTP or jmsweb), you can implement four service endpoint modes of web services in the context of a single Java application.

The methods you learned in this series come from our experience implementing these four web service models in the context of the process engine. We hope to share with you the challenges we encounter when implementing these web service models and provide you with the solutions we have obtained.

Source: developerworks China