Today's IT organizations have tens of applications and services that perform some well-defined tasks such as inventory, billing, expense reporting, and order entry. With the evolution of Internet and e-business, enterprises have started to think about how different applications in a disconnected mode can work independently but at the same time be a part of an information workflow process.

This new demand brought us to the concept of building new applications and integrating them with existing ones. Integrating new and old applications becomes a very complex task, because of both the number of applications that enterprises have as well as the complex business workflow of the enterprise.

Service-oriented architecture (SOA) provides an architectural pattern that can help to address the integration problem in the enterprise. Web services constitute one of the most viable solutions, and could be used as an implementation vehicle for SOA to integrate old, existing, and new applications using synchronous and asynchronous communication and a loosely coupled transaction model.

Asynchronous Applications
Enterprise applications or business processes that have information or process workflow typically are long running and asynchronous in nature. For example, a portal or Web application can provide a user interface to submit a loan application(s) to a loan flow business process, where the business process is orchestrating a discrete set of Web services such as credit service and third-party loan brokerage services. This loan flow business process could be a long running one in order to cater to the workflow (automated or human) involved, collect the loan offers, and finally come up with a best loan offer.

Web Services can be used not only for integration among applications, data, and services, but they can also support an asynchronous communication model. Applications or services can communicate by exchanging messages in an independent fashion without having to wait or block resources on the service consumer side.

A service consumer (which can be a any kind of Web application, desktop application, or process) invokes a Web service or business process by sending a message/request, which is typically an XML document. The service consumer does not have to wait for the message/response or block the resources with continuous wait time or by polling mechanism, which can become very expensive in terms of processing overhead. For example, in case of the loan flow scenario described above, the client application, which in this case is a Web application, can keep polling the business process to find out the whether the loan has been processed or not by using polling mechanism. Figure 1 shows a client application submitting the loan application that keeps polling until it receives a loan offer.

Asynchronous Web Services
Instead of polling the enterprise application, business process, or Web service, we could adopt an asynchronous communication model between the client and the application, service, or business process. Asynchrony can be achieved by applying different architectural models to Web services. The key requirement for choosing asynchronous communication here is the service consumer or the client cannot wait for the response to come back. This could be due to many reasons that include holding up the system resources on the client side, the network connectivity, or that it just takes an unpredictable amount of time for the response to come back. Typical asynchronous Web services architectural models are:

• A service consumer can send a SOAP message without having to block any resources to receive a message back.
• A service consumer and service provider can go through a series of conversations by passing around a conversation ID. This type of usecase is known as conversational Web services.
• A service consumer invokes a service, and the provider will send a callback once the process is completed. In order to receive the callback response, the service consumer will have a Web service endpoint that the provider uses to send the message back. Figure 2 shows a service consumer that has an endpoint and submits a loan application and the service provider, which is a business process and sends a callback to the consumer callback endpoint once the process is complete.

In order for the service provider to send the message/response back, the consumer will have to provide callback information or the details about where the notification or reply has to be sent. The Web Services Addressing (WS-Addressing) specification, which has been developed under World Wide Web Consortium (W3C), provides a standard mechanism to provide the callback information in the SOAP header element.

WS-Addressing
WS-Addressing provides way to specify message addressing information independent of transport layer. WS-Addressing provides a way to specify delivery, reply-to, and fault-handler addressing information in a SOAP envelope. WS-Addressing can be used in conjunction with other specifications such as WS-Security to authenticate and WS-Policy to define policies for the service.

WS-Addressing has two key constructs or artifacts:

• Endpoint reference
• Message information headers

Endpoint references in the WS-Addressing specification contain the information needed to identify/reference a Web service endpoint. Endpoint references can also be used to provide addresses for individual messages sent to and from Web services.

The WS-Addressing specification defines a set of message information headers that allow uniform addressing of messages independent of underlying transport. These message information headers convey end-to-end message characteristics, including addressing for source and destination endpoints as well as message identity. The WS-Addressing specification comes with WS-Addressing schema, which has complex types defined for endpoint references and messaging properties.

The endpoint reference contains the properties shown in Table 1. Only the address property (URI) is mandatory. The rest are used to provide additional information, behavior, and requirements of the endpoint. Table 2 shows the message information header properties.

Listing 1 shows a SOAP message that is used to invoke the loan flow business process, and contains the WS-Addressing information in the header element. WS-Addressing, in simple terms, is very similar to how the "to" and "from" addresses are written in postal envelopes.

Implementing WS-Addressing Services
As discussed in earlier sections of this article, client applications or service consumers expecting a response back in asynchronous fashion need to provide an endpoint, which is capable of receiving message/response back from the other end or from the service provider. Web applications and desktop applications aren't really geared toward or designed to work as callback clients. In order to provide or mimic the asynchronous conversations, we can have an intermediate service layer or a Web service, which could act as a callback client to the service provider or business process invoked by the client applications. Once the callback Web service receives the response it can process the callback message and take further action that will complete the loop for the user who has invoked a service or business process from the client application.

In the next part of this article we will illustrate the aforementioned use case with a business process developed using Business Process Execution Language (BPEL), a callback Web service developed using JAX-RPC and a Web application developed with JSF that acts as a service consumer and invokes the BPEL business process. Oracle Fusion Middleware components (Oracle BPEL Process Manager, OC4J, Oracle JDeveloper) were used to develop the above use case.

To start, we have a loan flow business process developed using BPEL (see Figure 3). This loan flow process checks the credit worthiness of the loan applicant by invoking a credit rating service provided by a credit rating company. Once the applicant is determined to have a good credit history, the loan flow process interacts with services provided by mortgage brokers and gets multiple loan offers. Finally the loan flow process has orchestration logic that determines the best loan offer from the offers received.

Once the back-end business process is ready, we need a Web application that is built with JavaServer Faces (JSF), which the customer uses to submit loan applications. Figure 4 illustrates the JSF navigation model for the Web application. Once the customer submits a loan application, the JSF application invokes the loan flow BPEL process (which is a Web service) using the stubs generated by the utilities provided by Oracle Application Server.

Once the JSF application invokes the loan flow business process, the business process will determine the best loan offer. We would like to notify the customer who has submitted the application via e-mail or SMS message on the status of the loan application and the loan offer that comes out of the loan flow process.

To achieve this we will create an intermediate Web service, which we will call the loan flow callback service. This loan flow callback service will have an endpoint that the BPEL loan flow business process can use to send the callback or loan offer that will be further processed by callback service.

Once the loan flow callback service is in place, we need to process the incoming loan offers. To keep it simple we will just send an e-mail notification to the customer who has applied for the loan, and he will be able to pick the message from the JSF application and act upon it either to take the offer or reject it. Listing 2 shows the onResult() method, which is the operation that receives the callback from the loan flow business process and sends out an e-mail with the loan offer.

So far so good: one additional thing that needs to be taken care of during the invocation of loan flow business process is to make sure that the SOAP message header element is populated with WS-Addressing information. The source code in listing 3 constructs a SOAP message, which has the loan application and populates the header of this SOAP message with WS-Addressing information that will tell the BPEL business process to send a callback to loan flow callback Web service after the loan application has been processed and the best offer has been achieved. Figure 5 illustrates the completed use case with flow described above.

Summary
To summarize, Web services constitute one of the most viable options to implement standards-based integration in enterprises. The WS-Addressing specification provides a standard mechanism to send message information independent of the transport layer.

WS-Addressing provides number of benefits that include the transport layer not being restricted to HTTP, and working in conjunction with other WS-* specifications it can be used for different patterns such as request/response, one-way, or conversational Web services.

Acknowledgments
The author wishes to acknowledge Olivier Le Diouris (olivier.lediouris@oracle.com), solution architect in Oracle Fusion Middleware Group, for his assistance in completing the aforementioned use case and source code.