Hybrid Service Oriented-Architecture for e-Transactions
Asynchronous Web Service Oriented Approach for B2B
Jennifer R. Pan
Computing & Software Systems
Institute of Technology
University of Washington, Tacoma
Tacoma, WA 98402
Project Type: TCSS702 Design Project in Computing and Software Systems
Date of Submission: September 8, 2004
Primary: Sam Chung, PhD
Committee Member: Sergio Davalos, PhD
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.
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  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 . SCM
refers to the process of optimizing the delivery of goods, services, and information from
supplier to manufacturer to wholesaler to retailer to customer . 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.
Retailer Supplier Warehouse
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.
Retailer Intermediary Supplier
Figure 2: Asynchronous interaction between retailer and supplier
Purpose and Problems
This 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 . 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
- 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.
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 to host SMTP-based Web
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
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.
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
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 the asynchWSMH Server.
SMTP Server SMTP Server
SMTP Server SMTP Server
Service Requester Service Provider
Figure 3: Request and Response of SOAP Requests using SMTP
An Asynchronous Web Service Message Handling Server: asynchWSMH
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.
Web application server
Application Code Service Proxy Service Listener
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 HelloWorld Web Service can be deployed. Once this is
shown to work, we adapt a set of synchronous Web Services, used in
SoRetailXMLGen , 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 . Some services are used internally within an organization,
while others services are published externally to allow other organizations to utilize them.
Enter Purchasing «uses»
Retailer Purchasing Department «uses»
Submit PO Submit Order
Confirmation Supplier Sales Department
Retailer Inventory Department «uses» Enter Order
Supplier Shipping Department
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 . 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).
Traveler Agency Airline Lodging
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
- Kill service provider then bring service back up. Compare outcome for
asynchronous SMTP-based Web Services and synchronous HTTP-based Web
- 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
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 Synchronous Web Services Asynchronous Web Services
SOAP format SOAP v1 SOAP + WS-*
fault tolerance programmatic and HTTP 404 SMTP provided retry and
batch processing N/A yes
Interactive Shorter time span Longer time span
Table 1: Criteria and Expected Results
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 . 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 .
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. ”
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 , 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 . 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  – 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
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
specifications into the suite of Web Services that will be created to demonstrate B2B
application integration for retail SCM systems.
Technologies and Resources
For this project to be fully implemented specific technologies and resources will be
required. The following details the necessary technologies and resources.
This project will utilize the .NET platform and SQL Server 2000 for necessary databases.
It will use the Service-Oriented Architecture.
Primarily, 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
- 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
- http://msdn.microsoft.com/webservices/building/wse/default.aspx. Contains
information about the WSE.
The sections below detail written and oral deliverables necessary for project completion
in Winter Quarter 2005.
At 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
- 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
- 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
- A user manual for the asynchronous Web Service message handling server
- A tutorial for invoking service clients using the asynchronous protocol.
If 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.
How does this project draw upon your graduate coursework?
This project will utilize knowledge that I have acquired through the following courses of
- 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.
Timeline and Milestones
The following timeline details milestones to be completed during a timeframe of twenty
Weeks 1-2: Setup and Experiment with the synchronous Web Service
approach for B2B Application Integration
1. 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
1. 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
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
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 Colloquium
1. Demonstrate the asynchronous Web Service message handling server called
asynchWSMH server with two test cases:
a. Asynchronous HelloWorld Web Services
b. Asynchronous SoRetailXMLGen Web Services
Weeks 11-12: Research WSE Specifications
1. 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
1. 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
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
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
iii. Batch processing mode: a Web Service in invoked at a specific time setting.
Weeks 18-20: Testing and Documentation
1. Analyze the testing results and compare them.
2. Finish documenting the Capstone report.
 Olson, M., and Ogbuji, U. (March 4, 2003). Sending and Receiving SOAP Requests
over SMTP. Retrieved September 23, 2004 from
 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-
 Alonso, G., Casati, F., Kuno, H., and Machiraju, V. (2003). Web Services: Concepts,
Architectures and Applications. New York: Springer-Verlag.
 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.
 Januszewski, K. (March 2004). Writing Asynchronous, Bidirectional, Stateful,
Reliable Web Services with Indigo. Retrieved September 23, 2004 from
 Longhorn Developer Center Home: Indigo. Microsoft MSDN, Retrieved September
23, 2004 from http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/
 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-
 Bosworth, A., et al. Web Services Addressing (WS-Addressing). (March 2004).
Retrieved September 23, 2004 from
 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.
 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.
 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.
 Box D, and Ferguson F, ed. Web Services Addressing (WS-Addressing). (August
2004), Retrieved September 23, 2004 from
 Snell, J., Tidwell, D., and Kulchenko, P. (2002). Programming Web Services with
SOAP. Sebastopol, CA: O’Reilly and Associates.
 Web Reference, retrieved September 24, 2004. “Google: What is SCM”.
 Ferrara, A., MacDonald, M. (2002). Programming .NET Web Services. Sebastopol,
CA: O’Reilly and Associates.
 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
 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.