Asynchronous Web Service Oriented Approach for B2B Integration

Jennifer R. Pan

Computing & Software Systems

Institute of Technology

University of Washington, Tacoma

Tacoma, WA98402

Project Type: TCSS702 Design Project in Computing and Software Systems

Date of Submission: September 8, 2004

Committee Members:

Primary: Sam Chung, PhD

Committee Member: Sergio Davalos, PhD

Abstract:

The purpose of this project is to propose an asynchronous Web Service oriented approach for Business-to-Business (B2B) application integration. Currently most Web Services use Simple Object Access Protocol (SOAP) as their interaction protocol based upon a synchronous transport protocol, HyperText Transport Protocol (HTTP). However, synchronous Web Services presents limitations for integrating B2B applications if one of the applications fails or the application needs longer interaction time due to its business requirements. In order to provide an asynchronous Web Services oriented approach for B2B transactions, an asynchronous Web Service message handling server that integrates with an existing Simple Mail Transfer Protocol (SMTP) server and a SOAP engine will be developed. Creating such a server to deploy asynchronous Web Services simplifies the process and allows corporations to deploy asynchronous SMTP-based Web Services with as much ease as deploying HTTP-based Web Services. When a Web Service request is sent to the mail server through SMTP, the request is stored in a mailbox of the email server. The mailbox is scanned and the received SOAP requests are sent to the SOAP engine for processing by the server. By applying this approach to B2B application integration, both asynchronous and synchronous Web Service oriented approaches will be compared in terms of SOAP message formats, error handling mechanisms for fault occurrences, and different processing modes such as batch and interactive processing. Based upon the results, the strengths and weaknesses of asynchronous and synchronous Web Services will be discussed.

Project Overview

Motivation

Businesses are now starting to expend more energy to integrate with applications of other businesses. This move to cross-organizational integration is commonly referred to as Business-to-Business integration (B2Bi). Web Services are being touted as the silver bullet for a wide array of integration issues [4] and as such, have been suggested as an approach for B2Bi [10, 11]. Currently available Web Services use a synchronous interaction model utilizing a synchronous transport protocol.

Using synchronous Web Services is restrictive for B2B application integration in that cross-organizational interactions typically last longer than can be supported reasonably by synchronous exchanges. For example, in Supply Chain Management (SCM) Systems, using a synchronous interaction model ignores an inherent characteristic of such systems; that is the need to support operations that last for extended periods of time [3]. SCM refers to the process of optimizing the delivery of goods, services, and information from supplier to manufacturer to wholesaler to retailer to customer [14]. In the case of a SCM System, a supplier might only be able to confirm an order from a retailer only after the requested items have been delivered from the warehouse as shown in Figure 1.

Figure 1: Retailer-Supplier-Warehouse Interaction Sequence

However, if we can utilize an asynchronous interaction model, it would be beneficial for B2B application integration. For instance, having an asynchronous interaction model for SCM Systems would allow for instances where retailers and suppliers reside in different time zones and need to interact with each other during their non-business hours. As illustrated in Figure 2, this allows the retailer to submit an order even if the supplier is not there to receive the request. In turn, once the supplier receives an order and processesthe order, the supplier does not need to wait for a connection to the retailer before it submits its order confirmation. For both these reasons, it is beneficial for B2B application integration to utilize an asynchronous interaction model.

Figure 2: Asynchronous interaction between retailer and supplier

Purpose and Problems

This project proposes an asynchronousWeb Serviceoriented approach for B2Bapplication integration. This raises several questions:

-How do we provide asynchronous mechanisms for B2B applications?

  1. What needs to be done differently to support SMTP-based Web Services as opposed to HTTP-based Web Services?
  2. Several companies such as IBM and Microsoft have been working on specifications that define a standard for including additional information not found in the current interaction protocol Simple Object Access Protocol (SOAP) v1.0. These are referred to as Web Services Enhancements (WSE). To support asynchronous communication for Web Services, it may be necessary to consider enhancements such as WS-Addressing that defines XML elements to identify Web Service endpoints, among other enhancements [12]. Which WSE will be needed and how will the WSE be incorporated with the asynchronous Web Services?

-How can asynchronous Web Services be deployed easily? What functionality is provided currently by existing Web application servers that need to be accounted for to allow for easy deployment? As will be discussed in the Related Works section, Web application servers such as Internet Information Server (IIS) appears to play the role of Web server as well as SOAP engine, but is there any other functionality that might be useful to include in our scanning and configuration server application?

-How does the asynchronous Web Services approach compare with the synchronous Web Services approach? Is a purely asynchronous interaction model the best approach? While typical cross-organizational interactions generally span hours or more, there may be instances where an organization may be able to respond more rapidly.

Approach

To address the problem of B2B application integration, Web Services written to use SMTP will be written to allow for asynchronous interaction. SMTP is chosen because it shifts the responsibility for retrying from the service requester to the transport.

In order to facilitate the development and deployment of asynchronous Web Services for B2B application integration, an asynchronous Web Service message handling server, which we call the asynchWSMH, will be developed. This server is integrated with an existing SMTP server and SOAP engine to allow us to easily deploy a suite of Web Services that use SMTP for transporting messages. In addition, this server will allow Web Service providers with the ability to configure their server tohost SMTP-based Web Services.

Expected Results

To determine the merits of asynchronous Web Services for B2B application integration compared to synchronous ones, two test scenarios will be examined. The first scenario is of a retail SCM System and the second is a Travel Agency System. These two scenarios are selected to represent cases where B2B application integration is useful. In both these scenarios, a set of asynchronous Web Services will be compared against a set of synchronous Web Services based upon message format, error handling, and processing modes.

Expected Contributions

By developing an asynchronous Web Service message handling server built upon existing SMTP servers and SOAP engines, this project will bring significant benefits to both Web Service providers wanting to deploy asynchronous Web Services and B2B application integration developers wanting to use asynchronous Web Services. First, by having an asynchronous Web Service message handling server for asynchronous SMTP-based Web Services, businesses are more likely to deploy asynchronous Web Services that are better suited for B2B interaction. Secondly, a set of asynchronous Web Services will be developed. These Web Services will provide working examples of how SMTP-based Web Services might be developed and used to address synchronicity issues inherent in B2B interactions, and will demonstrate some elements of the proposed Web Service extension mechanisms. Lastly, it will be shown that asynchronous SMTP-based Web Services are more fault-tolerant and allow longer interaction time than synchronous HTTP-based ones through a side-by-side comparison of asynchronous and synchronous Web Services suites.

Project Specifications

There are two main deliverables to this project: 1) an asynchronous Web Service message handling server, referred to asasynchWSMHServer, and 2) a set of Web Services for two applications requiring business-to-business integration. These will be described in the following sections after a brief description of how the proposed asynchronous Web Serviceoriented approach for B2B application integration will work.

Proposed Asynchronous Web Service Approach for B2B Application Integration

The asynchWSMH server that will be developed provides several functions for the service requester and the service provider and is located at both the service requester’s as well as the provider’s site. The service requester writes a service client that invokes a Web Service. The request is converted into a SOAP message by a given SOAP engine. The SOAP message is delivered to the service provider’s email server by the asynchWSMH server. The provider’s asynchWSMH server scans the mailbox of the given email server to check whether SOAP messages have arrived or not. If there are SOAP messages, the messages are sent to the provider’s SOAP engine. The SOAP engine binds the requested services with the given services. SOAP response messages are returned to the requester’s email server by the asynchWSMH server. When the requester’s asynchWSMH server finds the result message from its mailbox, the server contacts the service client. Figure 3 shows the message flow of this asynchronous Web Service approach using theasynchWSMH Server.

Figure 3: Request and Response of SOAP Requests using SMTP

An Asynchronous Web Service Message Handling Server: asynchWSMH Server

The first deliverable is a server application which allows users (e.g. service requesters or providers) to assign an <email address, subject> tuple to a service in much the same way that virtual directories are created for HTTP-based services by a web server such as Microsoft IIS. This application will also allow users to set the interval at which a mailbox is scanned for SOAP requests. Once a request is received by the server, it forwards the received request to the Web Service. The application server, as illustrated in Figure 4, is comprised of a Service Listener and a Proxy. In our case, a SOAP request is sent via SMTP that the Service Listener (scanner component of the asynchWSMH server) receives. The Listener extracts the SOAP request and passes it on to the Proxy, which is the SOAP engine that invokes the Web Service.

Figure 4: Request and Response of SOAP Requests using SMTP

Web Services for B2B Application Integration

The second product of this project is a suite of Web Services that can be used for B2B application integration. Once the scanning and configuration application, asynchWSMH Server, has been developed, we utilize three test cases to demonstrate how the server works and compare the strengths and weaknesses inherent to asynchronous Web Services to those of synchronous Web Services. In the first instance, we demonstrate how a simple service such as a HelloWorldWeb Service can be deployed. Once this is shown to work, we adapt a set of synchronous Web Services, used in SoRetailXMLGen [9], to use SMTP and deploy it using the server developed. The objective of these asynchronous Web Services is to allow retailers and suppliers to utilize a set of Web Services allowing access to each others’ data in an asynchronous manner. This is shown in Figure 5 and assumes that the services are developed using a service-oriented architecture [16]. Some services are used internally within an organization, while others services are published externally to allow other organizations to utilize them.

Figure 5: SCM System Use Case Diagram for Retailer-Supplier

Another set of Web Services to demonstrate B2B application integration will be a Travel Agency system. One use case is where a user chooses a preferred flight from a list of flights. The service puts the seats on hold by contacting the airline and then attempts to obtain lodging information for the user [17]. The sequence diagram for this scenario can be seen in Figure 6. In this example, the Travel Agency must wait until it has responses from both the airline and the lodging before replying to the traveler who is attempting to book a travel package (airfare and accommodations).

Figure 6: Sequence of Interaction in Travel Agency System

These two sets of Web Services for retail and travel SCM will be compared to corresponding sets of HTTP-based Web Services based on: 1) SOAP format, 2) error handling mechanisms, and 3) batch and interactive processing modes. The first criterion will naturally fall out due to design choices—this project will incorporate WSE specifications as needed. This will result in differences within the SOAP headers at the very least. As regards the second criterion, this will be determined through the following tests:

-Kill service provider then bring service back up. Compare outcome for asynchronous SMTP-based Web Services and synchronous HTTP-based Web Services.

-Once the request has been sent by service requester, have requester non-available (i.e., off) during the period of time that service provider generates and sends response to service requester. After some time, bring the requester up again (i.e., on). Compare outcome for asynchronous SMTP-based Web Services and synchronous HTTP-based Web Services.

-Both requester and provider are present, but provider is unable to obtain a response for the requester within a specified time window. Compare outcome for asynchronous SMTP-based Web Services and synchronous HTTP-based Web Services.

To determine the results of the last criterion will simply be to see how similar services, asynchronous SMTP-based vs. synchronous HTTP-based, respond to batch processing requests and interactive processing requests. Expected results are detailed in Table 1.

Criteria / SynchronousWeb Services / AsynchronousWeb Services
SOAP format / SOAP v1 / SOAP + WS-*
fault tolerance / programmatic and HTTP 404 / SMTP provided retry and queuing mechanism
batch processing support / N/A / yes
Interactive processing support / Shorter time span / Longer time span

Table 1: Criteria and Expected Results

Related Works

Several areas need to be more thoroughly investigated for this project to be completed successfully. This includes:

-Current HTTP-based Web Services components

-Asynchronous interaction models,

-WSE2 specifications,

-Technologies and related resources.

The following subsections discuss each of these topics in further detail.

Current HTTP-based Web Service Components

As mentioned before, Figure 4 shows the components of a Web Service. The application code contains all the business logic and code, the Service Listener utilizes the transport protocol (HTTP, etc.) and receives incoming requests, and the Service Proxy decodes those requests into calls into the application code. Web Services all have toolkits which provide the proxy component, which parses and interprets the SOAP message to invoke application code [13]. The tasks of the proxy component when handed a SOAP message by a listener is to:

  1. Deserialize message if necessary from XML into some native format suitable for passing off to the code.
  2. Invoke the code.
  3. Serialize response to the message (if one exists) back into XML and hand it back to the transport listener for delivery back to the requester [13].

Microsoft, seeing the benefits of using HTTP for Web Services chose IIS as the default transport layer. “This IIS integration allows you to leverage the scalability, performance, and security of Microsoft’s IIS web server rather than having to get involved with unpleasant socket programming or reinventing a higher-level communications server. This integration also means that if you want to use a web server other than IIS, you’re on your own. ASP.NET is designed to work in conjunction with IIS only and doesn’t provide support for other web servers. [15]”

Since we are going to be focusing on providing a viable solution for SMTP-based Web Services, we cannot use IIS’s HTTP Service to facilitate the deployment of Web Services where SOAP messages are transported through use of SMTP.

Asynchronous Interaction Models

One central issue that has been mentioned several times already is that of supporting asynchronous interaction between service consumer and provider. One of the methods suggested to support asynchronous Web Services is through the use of SMTP. Some work has been done allowing SOAP requests to be sent and received over SMTP [1, 2, 3, and 7]. There have also been several approaches taken to address asynchronous Web Services interaction [2, 5].

In a white-paper produced by Microsoft [5], they promote the use of Indigo for writing asynchronous, bidirectional, stateful, reliable Web Services. Indigo is “a set of .NET technologies for building and running connected systems” and is built around the Web Services architecture. Indigo will be an integral capability of the next version of Windows and will be supported on Windows XP and Windows Server 2003 [6]. This technology makes use of method callbacks. Both the consumer and provider have exposed methods which the other party can make calls to. On the producer side, these methods provide functionality; on the consumer side, methods exist for the producer to provide responses. While this addresses the need for supporting asynchronous communications, it requires that more code be written and maintained.

Similar to the SoapMail sample application provided by Microsoft, SOAP messages can be handled with the approach taken by Olson and Ogbuji [1] – by writing an SMTP Server, which listens for SOAP requests on a port and processes the requests as they are received. This approach requires that an SMTP stack be implemented by a developer each time—this is not taking advantage of existing technologies which already provides that functionality (such as MS Exchange). Olson and Ogbuji proposed two other approaches to handling SOAP messages over SMTP, which they did not implement. One was to configure an SMTP server to forward SOAP requests that it receives to a SOAP engine for processing. The other approach was to have an application scan a mailbox for SOAP requests and then send the request to a SOAP engine for processing. This latter approach is the one that we will use for this project.