Asynchronous Web Service Oriented Approach for B2B Integration

Jennifer R. Pan

Computing & Software Systems

Institute of Technology

University of Washington, Tacoma

Tacoma, WA 98402

jpan@jenniferpan.com

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.

1

Project Overview

MotivationBusinesses 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 processes the 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.

2

Retailer Intermediary Supplier

submitOrder()

confirmOrder

submitOrder

confirmOrder

Figure 2: Asynchronous interaction between retailer and supplier

Purpose and ProblemsThis project proposes an asynchronous Web Service oriented approach for B2B application 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.

ApproachTo 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.

3

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 to host SMTP-based Web Services.

Expected ResultsTo 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 ContributionsBy 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.

4

Project Specifications

There are two main deliverables to this project: 1) an asynchronous Web Service message handling server, referred to as asynchWSMH Server, 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 Service oriented approach for B2B application integration will work.

Proposed Asynchronous Web Service Approach for B2B Application IntegrationThe 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 the asynchWSMH Server.

Figure 3: Request and Response of SOAP Requests using SMTP

An Asynchronous Web Service Message Handling Server: asynchWSMH ServerThe 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

5

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 IntegrationThe 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 HelloWorld Web 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

6

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.

7

Criteria Synchronous Web Services Asynchronous Web ServicesSOAP format SOAP v1 SOAP + WS-*fault tolerance programmatic and HTTP 404 SMTP provided retry and

queuing mechanismbatch processing support

N/A yes

Interactive processing support

Shorter time span Longer time span

Table 1: Criteria and Expected Results

8

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 ComponentsAs 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 ModelsOne 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].

9

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.

Web Service Extension Version 2 (WSE2) Specifications Another effort has been undertaken by Microsoft, in conjunction with BEA, and IBM. Together they have written the Web Services Addressing (WS-Addressing) specifications [2, 7, and 8]. Using the WS-Addressing specification enables, among other things:

- Secure Web Service-based communications that is end-to-end even in the presence of intermediaries such as firewalls or NAT-based routers,

- Support for broader range of transport protocols, including SMTP,- Fully asynchronous communication in support of intermittent connectivity and

long-running communications.The sample SoapMail application provided by Microsoft demonstrates the use of WS-Addressing to make support transport-neutral. Currently, to send a Web Service request via HTTP results in both the target address and SOAP action being encoded as HTTP headers. Additionally, there is no mechanism provided by HTTP to specify a return address. WS-Addressing specifies that host, SOAP action, and return address be contained in the SOAP message as part of the header. I will likely make use of the WS-Addressing specifications for my project.

The WS-Addressing specification is part of a suite of specifications (including WS-Reliability, WS-Security, WS-Transaction, WS-Policy, etc.) being worked on to enhance support of Web Services. This will serve as a springboard for my own efforts to define a mechanism for providing SOAP support utilizing mailboxes.

Because these specifications are still being defined, deployed Web Services have not yet integrated these features into their system. This project seeks to incorporate pertinent

10

specifications into the suite of Web Services that will be created to demonstrate B2B application integration for retail SCM systems.

Technologies and ResourcesFor this project to be fully implemented specific technologies and resources will be required. The following details the necessary technologies and resources.

TechnologyThis project will utilize the .NET platform and SQL Server 2000 for necessary databases. It will use the Service-Oriented Architecture.

ResourcesPrimarily, the resources that will be consulted include items listed below as well as sources cited in the References section of this proposal. Below are some useful resources:

- Intelligent Service Oriented Computing group (ISOC). This consists of a research group led by Dr. Sam Chung for students interested in different areas of research pertaining to service-oriented computing paradigms.

- http://www.w3c.org . Contains useful information about various aspects of Web Service technology.

- http://msdn.microsoft.com/webservices/building/wse/default.aspx . Contains information about the WSE.

11

Deliverables

The sections below detail written and oral deliverables necessary for project completion in Winter Quarter 2005.

Written DeliverablesAt the conclusion of this project, several written items will be delivered to the Committee for review and approval. This includes:

- An asynchronous Web Service message handling server. This server will allow users to associate Web Services with a <email address, subject> tuple. It will also allow users to set the time interval at which to recheck for new and unprocessed SOAP (Simple Object Access Protocol) requests. Additionally it is responsible for rendering SOAP responses and sending the responses using SMTP (Simple Mail Transfer Protocol). The messages will use SOAP v2, which is essentially SOAP v1 with WSE2 (Web Service Enhancement v2).

- Web Services for business-to-business applications that show the strengths and weaknesses of using SMTP-based asynchronous Web Services compared with HTTP-based synchronous Web Services for B2B application integration. One set is of an asynchronous retail supply chain management system that is developed by using Web Services between a retailer and a supplier. Another set is of a Travel Agency system that is developed by using Web Services between a traveler and a travel agent.

- Final Capstone report that shows the asynchronous Web Service approach for business-to-business integration using SMTP and the strengths and weaknesses, compared to the synchronous Web Service approach using HTTP (HyperText Transfer Protocol)

- Three visual models in UML (Unified Modeling Language) to describe:

- Asynchronous Web Service message handling server.- asynchronous retail Supply Chain Management System- Travel Agency system

- Others:

- A user manual for the asynchronous Web Service message handling server- A tutorial for invoking service clients using the asynchronous protocol.

Oral DeliverablesIf the proposed Timeline is followed, the progress of this Capstone project will be presented at the Autumn Quarter 2004 Colloquium. The finished project will be presented in the Winter Quarter 2005 Colloquium.

12

Educational Statement

How does this project draw upon your graduate coursework?This project will utilize knowledge that I have acquired through the following courses of my studies:

- TCSS 558 Applied Distributed Computing Systems- TCSS 559 Web Services- TCSS 598 Master's Seminar in Computing and Software Systems

I first became exposed to Web Services and creating Web Services using the .NET framework while taking TCSS559 Web Services. The foundation for this course was TCSS558 Applied Distributed Computing, where I learned about distributed computing environments. Both of these courses will play a significant role in the success of this project. The foundation of my research technique draws from what learned and experienced through taking TCSS598 Master’s Seminar.

What will be researched and/or learned to make this a successful project? A distributed computing paradigm using Web Services, called Service-Oriented Computing, must be first researched and learned to make this project successful. Service-oriented architecture is studied to build a distributed application using Web Services. The current standard interaction protocol for binding a client program and Web Services, the language for describing the Web Services, and the directory for publishing the services are studied. Secondly, the transport protocol mechanisms for synchronous and asynchronous interactions are thoroughly investigated for comparison purpose. Especially, different approaches to process a Web Service using an asynchronous interaction protocol are researched. Lastly, examples of business-to-business application integration, which will be implemented by using asynchronous and synchronous interaction protocols, are studied.

13

Timeline and Milestones

The following timeline details milestones to be completed during a timeframe of twenty weeks.

Weeks 1-2: Setup and Experiment with the synchronous Web Service approach for B2B Application Integration1. Understand the current synchronous interaction protocol of Web Services, SOAP

(Simple Object Access Protocol) using HTTP (HyperText Transfer Protocol).2. In order to compare the pros and cons of the synchronous Web Service integration

approach, first study an example system in retail SCM (Supply Chain Management) System using synchronous Web Services called SoRetailXMLGen.

3. Determine the pros and cons of the synchronous Web Service integration approach by using the example system.

Weeks 3-8: Write and test asynchWSMH Server to process SOAP Requests1. Develop the asynchWSMH server with the following functions:

a. Check mailboxes for SOAP requests by having the server iterate through a mailbox residing on an email SMTP Server.

b. Pass the discovered SOAP request message to the SOAP engine component to be parsed. The SOAP engine will invoke Web Services according to the given SOAP request.

c. Once the above two functions are done, the server is generalized so that it is able to handle multiple Web Services.

2. Test the asynchWSMH server a. Write a simple asynchronous Web Service, asynchHelloWorld, and

test the server to check whether it works correctly or not.b. Modify the existing synchronous Web Services integration approach in

retail SCM, SoRetailXMLGen, for allow deployment using the asynchWSMH Server.

c. Create a new set of Web Services for the existing synchronous Web Services integration approach in retail SCM that is able to interact asynchronously, which we call asynchSoRetailXMLGen Web Services.

d. Collect the results of SOAP messages and the processed results.e. Analyze the collected results in terms of the message formats.

Week 9-10: Present progress at Fall Quarter 2004 Colloquium1. Demonstrate the asynchronous Web Service message handling

server called asynchWSMH server with two test cases:a. Asynchronous HelloWorld Web Servicesb. Asynchronous SoRetailXMLGen Web Services

14

Weeks 11-12: Research WSE Specifications1. Study several Web Service extension mechanisms

such as WS-Addressing, WS-Security to determine whether they are useful and the extent to which they are useful for asynchronous Web Service integration.

2. If the extension mechanisms is useful for the asynchronous Web Service integration, incorporate the approaches into the test cases to se what results can be obtained.

Weeks 13-17: Test Asynchronous Web Service Approach Using More Test Cases1. Create a set of Web Services for a travel SCM that a traveler chooses a preferred

flight from a list of flights with lodging information: synchTravelAgency, and asynchTravelAgency services.

2. Test the previous Web Services in terms of fault tolerance and processing modes:a. Test cases:

i. asynchHelloWorld Web Service and an asynchHelloWorld Web Service.

ii. synchSoRetailXMLGen and asynchSoRetailXMLGen Web Services.

iii. synchTravelAgency and asynchTravelAgency Web Services.

b. Testing criteria:i. Fault tolerance: assume a Web Service is not available.

ii. Interactive processing mode: a Web Service needs to be done within a time limit.

iii. Batch processing mode: a Web Service in invoked at a specific time setting.

Weeks 18-20: Testing and Documentation1. Analyze the testing results and compare them.2. Finish documenting the Capstone report.

15

References

[1] Olson, M., and Ogbuji, U. (March 4, 2003). Sending and Receiving SOAP Requests over SMTP. Retrieved September 23, 2004 from http://www-106.ibm.com/developerworks/webservices/library/ws-pyth12.html.

[2] Shewchuk, J., Millet, S., Wilson, H., and Cole, D. (October 2003). Expanding the Communications Capabilities of Web Services with WS-Addressing. Retrieved September 23, 2004 from http://msdn.microsoft.com/library/en-us/dnwse/html/soapmail.asp.

[3] Alonso, G., Casati, F., Kuno, H., and Machiraju, V. (2003). Web Services: Concepts, Architectures and Applications. New York: Springer-Verlag.

[4] Staab, S., Aalst, W., Benhamins, V.R., Bussler, C., Maedche, A., Fensel, D., and Gannon, D. (2003). Web Services: Been There, Done That? IEEE Intelligent Systems, 18(1), pp72-85.

[5] Januszewski, K. (March 2004). Writing Asynchronous, Bidirectional, Stateful, Reliable Web Services with Indigo. Retrieved September 23, 2004 from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/indigoattrprog.asp.

[6] Longhorn Developer Center Home: Indigo. Microsoft MSDN, Retrieved September 23, 2004 from http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx.

[7] Highland Mary Mountain, et al. SOAP Version 1.2 Email Binding. W3C Note, (July 3, 2002). Retrieved September 23, 2004 from http://www.w3.org/TR/soap12-email.

[8] Bosworth, A., et al. Web Services Addressing (WS-Addressing). (March 2004). Retrieved September 23, 2004 from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-addressing.asp.

[9] Tang, L. (2004). Service-Oriented Extensible Markup Language Generator for Electronic Data Interchange in Retail Business. Tacoma, Washington: University of Washington, Department of Computing and Software Systems.

[10] Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A., and Elmagarmid, A. (2003). Business-to-Business Interactions: Issues and Enabling Technologies. The VLDB Journal, 12(1), pp59-85.

16

[11] Hogg, K., Chilcott, P., Nolan, M., and Crinivasan, B. (2004). An Evaluation of Web Services in the Design of a B2B Application. Proceedings of the 27th Conference on Australasian Computer Science, 26, pp331-340.

[12] Box D, and Ferguson F, ed. Web Services Addressing (WS-Addressing). (August 2004), Retrieved September 23, 2004 from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-addressing.asp

[13] Snell, J., Tidwell, D., and Kulchenko, P. (2002). Programming Web Services with SOAP. Sebastopol, CA: O’Reilly and Associates.

[14] Web Reference, retrieved September 24, 2004. “Google: What is SCM”. http://www.google.com/search?hl=en&lr=&ie=UTF-8&oi=defmore&q=define:SCM

[15] Ferrara, A., MacDonald, M. (2002). Programming .NET Web Services. Sebastopol, CA: O’Reilly and Associates.

[16] Chung, S., Tang, L.H., Davalos, S. (2004). A Web Service Oriented Integration Approach for Enterprise and Business-to-Business Applications. The Proceedings of the 2004 International Conference on Web Information Systems Engineering (WISE04).

[17] Haas, H. (ed). Web Service Use Case: Travel Reservation: W3C (May 5, 2002). Retrieved September 23, 2004 from http://www.w3c.org/2002/06/ws-example.

17