Asynchronous Web Service Oriented Approach for B2B Integration

rangesatanskingdomΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

92 εμφανίσεις


Asynchronous Web Service Oriented Approach for B2B
Integration







Jennifer R. Pan






A project submitted in partial fulfillment of the requirements for the degree of

Master of Science










University of Washington

2005








Program Authorized t
o Offer Degree:

Computing and Software Systems
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 Pr
otocol (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 a
pplication 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
was

developed.
This approach was selected over using more reliable queing mechanisms,
such as IBM’s WebSphere MQ or Microsoft’s MSMQ as SMTP and the use of emails are
ubiquitous.
Creating such a ser
ver 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 SMT
P, 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 syn
chronous Web Service oriented approaches w
ere
compared in terms of SOAP message formats, error handling mechanisms for fault
occurrences, and interactive processing. Based upon the results, the strengths and
weaknesses of asynchronous and synchronous Web
Services
are

discussed.


ii



Table of Contents

1

Introduction

................................
................................
................................
.................

1

2

Service
-
Oriented Architecture Background

................................
................................

3

2.1

Web Services Background

................................
................................
..................

3

2.2

Service
-
Oriented Architecture

................................
................................
............

3

2.3

Current

HTTP
-
based Web Service Components

................................
................

4

2.4

Web Service Standards

................................
................................
.......................

5

3

Related Works

................................
................................
................................
.............

7

3.1

HTTP with Method Callbacks or Polling

................................
...........................

7

3.2

SMTP
-
based Web Services
................................
................................
.................

8

3.3

Message Oriented Middleware

................................
................................
...........

9

3.4

WSE

................................
................................
................................
....................

9

3.5

Comparative Summary

................................
................................
.....................

10

4

Asynchronous Programming D
efined
................................
................................
.......

12

5

Approach

................................
................................
................................
...................

14

5.1

An Asynchronous Web Service Message Handling Server

..............................

14

5.2

Email2WS Server Architecture

................................
................................
.........

15

5.3

Client
-
side Aids

................................
................................
................................

19

5.4

Web Applications
................................
................................
..............................

20

6

Results

................................
................................
................................
.......................

23

6.1

SOAP and WSDL

................................
................................
.............................

23

6.2

Fault Tolerance

................................
................................
................................
.

24

6.3

Interactive Processing Support

................................
................................
.........

25

7

Discussion and Conclusion

................................
................................
.......................

26

7.1

Similarities using HTTP

and SMTP based Web Services

................................

26

7.2

Differences using HTTP and SMTP based Web Services

................................

27

7.3

Significance
................................
................................
................................
.......

28

7.4

Future Work

................................
................................
................................
......

29

8

Bibliography

................................
................................
................................
.............

30


iii



List of Figures

Fig
ure 1: Retailer
-
Supplier
-
Warehouse Interaction Sequence

................................
...........

1

Figure 2: Asynchronous Interaction between Retailer and Supplier

................................
..

2

Fig
ure 3: Request and Response of SOAP Messages

................................
.........................

3

Figure 4: Service Oriented Architecture

................................
................................
.............

4

Figure 5: Structure of SOAP Message

................................
................................
................

5

Figure 6: Client
-
Server interaction

................................
................................
...................

12

Figure 7: Message Flow using Email2WS Server

................................
............................

15

Figure 8: SOAP Request and Response using Email2WS

................................
...............

16

Figure 9: Pop3Client Namespace
................................
................................
......................

17

Figure 10: Soap Na
mespace
................................
................................
..............................

18

Figure 11: Internet Namespace

................................
................................
.........................

18

Figure 12: proxyGen Namespace

................................
................................
......................

19

Figure 13: ServiceInvoker Namespace

................................
................................
.............

20

Figure 14: SCM System Use Case Diagram for Retailer
-
Supplier
................................
...

21

Figure 15: E
AI and B2B with private and shared service registries

................................
.

21



iv



List of Tables

Table 1: Comparison of Approaches

................................
................................
................

10

Table 2: Information needed to register a Web Service with Email2WS

.........................

16

Table 3: Criteria and Expected Results

................................
................................
.............

22



v



Acknowledgements

The author wishes to e
xpress her appreciation to the Department of Computing and
Software Systems for their extended long
-
term support and especially to Professor Sam
Chung for
being a constant source of motivation and for patience,
knowledge
, and
assistance throughout the dura
tion of this project
. This project would never have been
completed without the encouragement a
nd devotion of: my parents, Syiku and
Shwu
shenn Pan; Spencer Pan; and Daniel Longley.

The author also wishes to thank Lai
Tang for developing the
SoRetailXMLGen

suite of Web Services that were used for
testing this project.

1



1


Introduction

Businesses are starting to expend more energy to integrate with applications of other
businesses. This move to cross
-
organizational integration is commonly referred to as
Busine
ss
-
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
[
8
,
9
]. Currently available Web Services use a synchronous interacti
on 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. F
or 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 [
12
]. 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
requestOrder
requestSupplies
supplyInfo
orderConfirm

Figure
1
: Retailer
-
Supplier
-
Warehouse Interaction Sequence

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 h
ours. As illustrated in
Figure 2
, this allows
the retailer to submit an order to an intermediary even if the supplier is not there to receive the
request. In turn, once the supplier receives an order from the intermediary and processes the
order, the sup
plier 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.

Given that it is beneficial for B
2B application integration to utilize an asynchronous interaction
model, we want to provide a mechanism to easily deploy Web Services. That raises the
question of how to provide a model and mechanism for facilitating asynchronous B2B
application integrati
on. Among the proposed approaches to allowing for longer transactions
are: using method callbacks over HyperText Transfer Protocol (HTTP) [
20
]; using a Message
-
Oriented Middleware (MOM) system [3]; and using alternate transport protocols, such as

2



Simple M
ail Transport Protocol (SMTP), which naturally support asynchronous interactions
[1, 3].

Another concern is the deployment of such services. In order for a solution to be widely
adopted, it must be easy to use with minimum overhead. Part of the reason fo
r the success of
.NET Web Services is the built in tools that are integrated with their development environment.
These tools handle the generating of Web Service Description Language (WSDL) files and
proxy classes, and provide a mechanism for serializing
and deserializing Simple Object Access
Protocol (SOAP) messages. This along with Microsoft’s decision to use Internet Information
Services (IIS) as the default transport layer means that it is very easy to deploy HTTP
-
based
synchronous Web Services using
Microsoft technologies [
13
]. The solution presented by this
project needs to provide some of the same tools to facilitate the creation and consumption of
Web Services.

The objective of this project is to implement a solution which combines ideas found fro
m two
previously proposed approaches to provide and demonstrate the capability of easily deploying
.NET Web Services with Simple Mail Transport Protocol (SMTP) binding for use in
supporting asynchronous B2B applications.

Retailer
Intermediary
Supplier
submitOrder()
confirmOrder
submitOrder
confirmOrder

Figure
2
: Asynchronous Interaction between Retailer and Supplier

There are several proposed solutions, such as MOM, for handling asynchronous interactions as
required by B2B applications. Some have proposed the use of message queues as a method of
handling asynch
ronous Web Services interaction. Others have proposed writing an SMTP
Server, which listens for SOAP requests on a port and processes the requests as they are
received to handle the same issue as a solution. In the approach in this paper, by using email
mailboxes as endpoints, we are able to provide a message queuing mechanism using a pre
-
existing and well understood transport protocol while allowing service developers and their
companies the flexibility of not having to manage their own mail or web serve
rs.

This report provides the results of the implemented system. The developed
Email2WS

system
provides the ability to support Web
Service interactions

that last longer. Additionally, it is
shown that the developed
Email2WS

system allows service develop
ers an easy method of
deploying their services as SMTP
-
based Web Services and is a more robust system in that it
allows for service downtimes to exist while still being able to receive requests.

The paper provides a brief background for Service Oriented Ar
chitecture (SOA) and Web
Services. The shortcomings of the current synchronous Web Services are discussed. Lastly,
the approach taken to address the discussed shortcomings is described and analyzed.


3



2

Service
-
Oriented Architecture Background

2.1

Web Service
s B
ackground

W3C defines
a
Web S
ervice

as


a software system designed to support interoperable machine
-
to
-
machine interacti
on over a network.
It has an interface described in a machine
-
processa
ble
f
ormat, specifically Web Service

Description Language (WSDL)
.

Other systems interact with
the Web service in a manner prescribed by its description using SOAP
-
messages, typically
conveyed using HTTP with an XML serialization in conjunction with other Web
-
related
standards.


SOAP
message
XML
SOAP
message
XML
SOAP
message
XML
SOAP
message
XML
XML Web
Service Object
Serialize
SOAP
request
Deserialize
Serialize
SOAP
response
Deserialize
Proxy
object
Web Server
Client
Network

Figure
3
: Request and Response of SOAP
M
essages

As depicted in
Figure 3
,
there are the client and server entities. They communicate through the
exchange of SOAP messages which are serialized and deserialized, on the client side by the
proxy o
bject and on the

server side by the Web Server,
or a component of the Web Server

which is capable of serializing and deserializing SOAP messages
.

The messages are
transferred through the internet typically through the use of HTTP.

Web Services created usi
ng Microsoft’s .NET framework
are

geared specifically towards using
HTTP

although other transport protocols such as SMTP, FTP, and Jabber can also be used

[
11
]
.

With their .NET assemblies and Internet Information Services (IIS), Microsoft has
created a qu
ick and effective way for developers to create applications which use Web
Services.
Once

a developer adds a Web Reference, a proxy class is generated automatically by
the Visual Studio .NET Integrated Development Environment (IDE) which is capable of
invo
king the exposed
Web Service
methods.
The
System.Web.Services

assembly
provides the capability to serialize and deserialize SOAP messages.

2.2

Service
-
Oriented Architecture

Web Services are based on the Service Oriented Architecture (SOA). In such a system,
there
are three primary roles: service broker, service provider, and service client as depicted in
Figure 4
.


4



The beauty of this architecture is that it provides client application (i.e., Service
Requester
)
developers with
a service directory

in the form of

a Universal Description, Discovery and
Integration (UDDI) server
s. The service requester

can use

the UDDI server

to find services,
which allows them to cut down on the amount of development work needed and incorporate
these services into their applicatio
n (i.e., binding). There are two types of binding: compile
-
time and run
-
time binding [
11
]. With compile
-
time binding, the server is hard
-
coded into
the
client program. If instead

the client program
performs a search

for a suitable server then binds
to i
t, then binding occurs at run
-
time.

Service Broker
(UDDI)
Service Provider
Service Requester
publish
<< WSDL >>
bind
<< SOAP>>
find
<< WSDL >>

Figure
4
: Service Oriented Architecture

The
service provider

provides services with exposed public interfaces that can be invoked by
service requesters
.
With the vie
w that each role is hosted on a machine, the service provider
machine hosts both the services as well as descriptive information about the services that are
hosted in the form of a WSDL file.

Typically, the
service provider

will publish its service interfa
ce description with a
service
broker
. A
service broker

is the means by which Web Service descriptions are published and
made discoverable [
22
].

A UDDI Server is generally used for this purpose. Microsoft’s
Enterprise UDDI Services component of Windows S
erver 2003 is an example of a UDDI
server. These servers offer
service requesters

a centralized location to search for
service
providers

and bind to them.

A
se
rvice requester

is typically an application which looks for services (
i.e.,
find
s
) and then
uses

them (
i.e.,
bind
s
).

In a client
-
server paradigm, the service requester is the client.

A client
can take the form of a Web application, a windowed application, or a software program
without a User Interface (UI).

2.3

Current HTTP
-
based Web Service Components

A

Web Service

is comprised of application code, service proxy and service listener
. The
application code

contains all the business logic and code, the
s
ervice
l
istener

utilizes the
transport protocol (HTTP, etc.) and receives incoming requests, and the
s
ervice
p
roxy

decodes
those requests into calls into the application code.
Web Service
s all have toolkits which
provide the proxy component, which parses and interprets the SOAP message to invoke
application code [
11
]. The tasks of the proxy component w
he
n handed a SOAP message by a
l
istener
are

to:

-

Deserialize message if necessary from XML into some native format suitable for
passing off to the code.

-

Invoke the code.


5



-

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 [
11
].

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. [
13
]”

2.4

Web Service Standards

The core of what makes Web Services such a good thing is that there are defined standards
acting as guidelines. Among them

are

SOAP and WSDL.

SOAP stands for Simple Object Access Pro
tocol. According to W3C, SOAP
is a

lightweight
protocol intended for exchanging structured information in a decentralized, di
stributed
environment”
,

which uses eXtensible Markup Language (XML).


In a distributed environment,
it is important for there to be a common method of representing data. For this reason, SOAP
being built upon XML is good.
For a distributed service to be considered a Web Service, it
must use and understand SOAP messages.

A

SOAP message consists of an envelope with an optional header and a required body, as
illustrated in
Figure
5
. The header provides information which is useful in determining how
the message is to be processed, such as routing and delivery settings, authen
tication or
authorization assertions, and transaction contexts [
11
].

The body of the SOAP message
contains the actual Web Service request or response message which is to be delivered and
processed.

SOAP envelope
SOAP header
SOAP body
Header block
Message body
Header block

Figure
5
: Structure of SOAP
M
essage

Microsoft and other major contributors to Web Services specification have realized the need
for a standardized approach for providing features such as the ability to add attachments,
provide security model, enable descripti
on of complex message paths, and so on, which are not
defined by the W3C SOAP Specification. A recent development is the addition of Web
Services Enhancements (WSE). WSE version 2.0 from Microsoft has the following system
requirements

[
17
]:

-

Operating Sys
tem:


6



-

Microsoft Windows 2000 Server with Service Pack 3 or later

-

Microsoft Windows XP Professional with Service Pack1 or later

-

Microsoft Windows Server 2003

-

Microsoft Internet Information Services (IIS) 5.0 or later

-

And one of:

-

Microsoft Visual Studio .NET
2003

-

Microsoft Windows .NET framework version 1.1

Another key element for Web Services to be successful is the presence of service description
information found in WSDL files.

W3C states that WSDL provides a way for

describing
network services as collect
ions of communication endpoints

capable of exchanging messages”
using XML and

provides documentation for distributed systems which allows for automating
details involved in applications communication [
19
].

Since SOAP and WSDL are core components of Web Ser
vices, having tools which are capable
of serializing and deserializing these files are crucial for the success of a system wishing to
create and/or consume Web Services.


7



3

R
elated Works

There are several proposed ways of handling asynchronous requests and re
sponses.

-

HTTP with method callbacks

or polling
,

-

SOAP over SMTP
,

-

Message Oriented
Middleware
, and

-

WSE.

The following subsections discuss each of

these topics in further detail and provide a summary
table comparing the different approaches at the end of this

section.

3.1

HTTP with Method Callbacks

or Polling

An approach to writing asynchronous Web Services using the .NET framework is to utilize
asynchronous calls [
20
]. Typical .NET Web Services written with the Visual Studio IDE
utilizes

the
Invoke

method of the

generated proxy class. This method calls the Web method
synchronously and returns the result of the call and is the default behavior.

The proxy class generator actually also generates two additional methods for each Web method
a
BeginMethod

and
EndMethod
, where Method is the name of the method.

These provide
thin wrappers for
BeginInvoke

and
EndInvoke
.
Through this
approach,

there are three
options for making an asynchronous request and det
ermining when it is completed
.
The
example which demonstrates a

function which takes a needlessly long time to return a result is
provided here as found at [
20
]:

Public Function DelayedResponse(ByVal waitPeriod As Integer) _


As String


Dim results() As Object _


= Me.Invoke("DelayedResponse", _



New Object() {waitPeriod})


Return CType(results(0),String)

End Function

Code Sample
1
: DelayedResponse function [
20
]

The first of these approaches is to poll for completion.
This approach is not efficient a
s it has
the potential of
tying

up the processor
.

The function loops until it receives the signal that the
process is completed. For the
DelayedResponse

function provided above, the solution
which uses polling to allow making an asynchronous request look
s like this:

' Polling code that could tie up your processor

Dim proxy as New localhost.Service1()

Dim result as IAsyncResult

Result = proxy.BeginDelayedResponse(2000, _


Nothing, _


Not
hing)

While (result.IsCompleted = False)


' Do some processing


...

Wend

Dim response as String

response = proxy.EndDelayedResponse(result)

Code Sample
2
: DelayedResponse using polling [
20
]


8



The second appr
oach uses a

WaitHandle object

and is the approach to take if you do not want
to release the thread you are currently executing in. Using this approach is particularly useful
if you are making multiple Web Service
s

within an ASP.NET page [
20
]. Since it is less likel
y
that a B2B application will be browser based in support of longer transaction times, we are not
as interested in this approach.

The last approach utilizes callbacks.

This is a very efficient approach for making many
simultaneous Web service calls and is

more complicated than the previous two approaches.

Dim proxy as localhost.Service1

Private Delegate Sub MyDelegate(ByVal response As String)


Private Sub Button1_Click(ByVal sender As System.Object, _


ByVal e As System.EventArgs) Handles Button1.C
lick


proxy = New localhost.Service1()


proxy.BeginDelayedResponse(2000, _


New AsyncCallback(AddressOf Me.ServiceCallback), _


Nothing)

End Sub


Private Sub ServiceCallback(ByVal result As IAsyncResult)


Dim response As Stri
ng


response = proxy.EndDelayedResponse(result)


Label1.Invoke( _


New MyDelegate(AddressOf Me.DisplayResponse), _


New Object() {response})

End Sub


Private Sub DisplayResponse(ByVal response As String)


Label1.Text = response

End S
ub

Code Sample
3
:
DelayedResponse using callback

[
20
]

Superficially, the
Begin

and
End

methods appear to address the problem of synchronicity.
However, this is not really the case since the
BeginInvoke

and
EndInvoke

exist to
provide a programmatic interface between the client proxy (i.e., HTTP client) and the client
application. The Web Service itself in combination with the transport protocols it uses is the
unit to be considered when talking about asynchronous Web Service i
nteraction.
In the case of
using HTTP for transporting Web Service messages, providing the
Begin

and
End

methods
still does not address scenarios where the Web Service

encounters timeouts or long delays
in
generating a response,
whether this

is because it

was not immediately available at the time the
request was made or because the time it requires to process the request is longer than the
timeout duration for HTTP.

Consequently
, although it allows client application developers to
write asynchronous progr
ams easily, it does not address the issue of handling cross
-
organizational interactions typically lasting longer than can be supported reasonably by
synchronous exchanges.

3.2

SMTP
-
based Web Services

The most common approach for transporting SOAP messages is o
ver HTTP. This is because
HTTP is ubiquitous, firewall
-
friendly, and easily secured [
21
]. SMTP is a great alternative to
HTTP in that it is as prevalent as HTTP and is asynchronous.
W
ith SMTP and emails a caller

9



can “
send the request via e
-
mail, and if
the destination server is down, any intermediate servers
will retry several times in order to ensure delivery of the e
-
mail.


HTTP on the other hand, will
fail if the target server is unavailable at the time of the request

[
21
]
.”

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 Service
s is through the use of SMTP. Some work has
been done allowing SOA
P requests to be sent and received over SMTP [1, 2, 3, and
5
].

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 SOA
P 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 a
s
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 ap
proach 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 use
d

for this project

because this
appears to be the best approach given implementation e
ffort and future
maintenance

resources
required
.

Since SMTP Servers are large projects involving the efforts of large development
teams, modifying or creating an SMTP Server to support SOAP messaging for Web Service
interaction is impractical.

3.3

Message Ori
ented Middleware

Message
-
Oriented Middleware (MOM) has been suggested as a way to tackle B2B application
integration [3].
Message
-
Oriented Middleware is a specific class of middleware that supports
the exchange of messages in a distributed application env
ironment [
16
]. In a MOM world,
there is less of a distinction between client and server as all objects it encounters are messages
from a sender to a receiver [3]. Organizations with MOM projects include IBM Corporation’s
WebSphere MQ (formerly MQSeries),

Sun’s Java Message Service (JMS) and ONE
Middleware (formerly iPlanet Message Queue for Java), Microsoft’s Microsoft Message
Queue Server (MSMQ), and BEA System’s MessageQ, to give a few examples.

We will take
a look at Microsoft’s

Message Queue
Server
(
MSMQ).

According to Microsoft

[
15
]
, MSMQ “enables applications running at different times to
communicate across heterogeneous networks and systems that may be temporarily offline.


Applications send messages to queues and read messages from queues.


MSMQ p
rovides
guaranteed message delivery, efficient routing, security, and priority
-
based messaging.


It can
be used to implement solutions for both asynchronous and synchronous messaging scenarios”.

3.4

WSE

In Section 2,
it was

mentioned that WSE provides a mechan
ism for uniformly defining SOAP
header information for things such as security model to use, description of complex message
paths, and so on. Microsoft, in conjunction with BEA and IBM have headed this effort.
Together they have written the
Web Service
s
Addressing (WS
-
Addressing) specifications [2,
5
,
6
, and 10
]. Using the WS
-
Addressing specification enables, among other things:


10



-

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

(Net
work Address Translation)
-
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 pr
ovided 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
.
The WS
-
Addressing specification is part of a suite of
specifications (including WS
-
Reli
ability, WS
-
Security, WS
-
Transaction, WS
-
Policy, etc.)
being worked on to enhance support of
Web Services.

Because these specifications are still being defined, deployed Web Services have not yet
integrated these features into their system. This project s
eeks to incorporate pertinent
specifications into the suite of Web Services that will be created to demonstrate B2B
application integration for retail SCM systems.

3.5

Comparative Summary

The previously discussed approaches which were proposed to address the n
eed for supporting
asynchronous Web Service interactions are compared in this section.

Approach
Pros
Cons
HTTP Polling or
Callbacks
Provides a programmatic interface for
allowing asynchronous programming.
Still does not address the issue of
HTTP timeouts.
WSE v2.0
Provides a mechanism for describing
policies and such to follow, which may
facilitate asynchronous interactions.
As of yet, not widely adopted.
Additionally, is used to describe
certain properties of Web Services,
and does not actually implement
anything.
Create SMTP
Server
Servers already exist and requires
excessive effort for something that
could be solved in an easier fashion.
Configure SMTP
Server
Requires access to SMTP server and
the know-how to effectively administer
the SMTP server.
scan mailbox for
SOAP requests
Is effective approach. Lacks details
and framework to promote adoption in
Web Services community because of
nonexistent tools.
Message
Oriented
Middleware
Provides a queueing mechanism which
allows greater flexibility in terms of
timing between provider and requester.
Requires proprietary MOM software to
be running on service provider
machine as well as, ideally the client
side. Requires developers to be
knowledgable about MOM
programming interface.
Readily available and easy to use.
Supports asynchronous interaction
because it is an asynchronous
transport protocol.

Table
1
: Comparison of Approaches


11



The approach selected for this project is to scan mailboxes for SOAP requests. As e
mail
systems are an implementation of message queues, this approach has the added benefit of
displaying some MOM
-
like features provided through a platform
-
neutral and ubiquitous
technology.



12



4

Asynchronous Programming Defined

Before discussing our approach a
nd results, it would be good to address what we mean when
we use the word
asynchronous
.
An interaction is considered asynchronous if
“a sender and
receiver do not need to coordinate before data can be transmitted [
23
].”


For program
interactions that are

lengthy,
as is often the case with

distributed

network applications,
it is
oftentimes useful to counteract this by using an asy
nchronous programming paradigm.

Interactions between two programs can be asynchronous at several different levels.
To
simplify
the analysis, we will first examine only the client
-
side

using a synchronous protocol as
illustrat
ed in
Figure 6
.

For a
HTTP
Web Service client, we have the application, a proxy
which is used by the application to interact with the HTTP client,
the TCP ne
twork layer, and
the IP network layer.

Typically, each layer has its own independent timeout value; if it is
unable to retain a response within its timeout, that layer reports back to the layer above it that it
was unsuccessful. Because of this, if the T
CP layer has a timeout value of 30 seconds and an
HTTP client has a timeout value of 90 seconds, the 60 additional seconds that the HTTP client
has is meaningless since it is constrained by the 30 second value of the TCP layer.

Common
request timeout for
HTTP is 300 seconds [
24
].

Client
application
proxy
HTTP
TCP/IP
TCP/IP
HTTP
proxy
Server
application

Figure
6
:
Client
-
Server interaction

Timeouts are generally useful when there are two or more distinctly separate entities, none of
which has control of others. For a HTTP serv
er receiving a HTTP request, having a specified
timeout allows it to become disinterested in the request if the requester is taking too long or is
too slow.
It is also able to determine “failure” to transmit reply to the requester if the requester
is slow

to acknowledge received packets or if somehow the requester is unexpected
disconnected.
Essentially, network timeouts are a somewhat lax means for a bit of
communication integrity.
SMTP also
utilizes

timeouts, but the
re are several key

difference
s

in
us
ing SMTP
.

For one, there
is a built in retry mechanism and a standard way of handling
reasonable delays

and notifying the client of delays and failures through Delivery Status
Notifications (DSN)
.

Additionally, because POP3 mailboxes are used as the end
points, entities
which use email as the method to send and receive Web requests
are given more flexibility; a
message is allowed to sit in an inbox indefinitely until such a time as the end
-
user decides to
check the message.


13



For the sake of this project, w
e say that the client and server applications interact
asynchronously because they are using a transport that is asynchronous. However, through the
use of the
Email2WS

s
erver
application
that was developed,
the client applications can
actually use a synch
ronous programming approach because synchronization is handled for it by
the server and corresponding polling mechanism provided to the client to obtain responses.


14



5

Approach

The goal of this project
is
to create a mechanism for creating and using Web Servic
es using
SMTP binding in as easy a manner as is available with HTTP binding to allow entities wishing
to deploy and use asynchronous Web Services, particularly businesses wishing to provide
integrated B2B application solutions, to do so easily.
In order t
o facilitate the development and
deployment of asynchronous Web Services for B2B application integration, a message
handling server, which we call Email2WS is developed. This server uses a SOAP engine and
is integrated with existing SMTP servers to allow
us to easily deploy a suite of Web Services
that use SMTP for transporting service requests and responses. This server will allow Web
Service providers with the ability to configure their server to host SMTP
-
based Web Services.
Beyond the server applicat
ion, several tools were also developed to facilitate this. The
architecture of the system is described in the following section, followed by an overview of the
supporting
client
-
side
tools. The last portion of this section details the Web Services used t
o
demonstrate the applicability of the proposed approach to deploying and successfully
consuming SMTP
-
based Web Services.

The approach taken reflects several assumptions that were made.
One assumption we operated
under is that the publishing and discovery

phases have already occurred. The problem this
project sought to address was more the interaction between provider and requester once they
are bound
,

not how the service publication and discovery occur
. Another assumption that was
made is that
the clien
t application runs sequentially because the underlying layers provide
synchronization.
T
he
Email2WS

application handles requests as they are received and the
client proxy waits until it obtains a response from the service provider per request before it
co
ntinues executing whatever logic follows the request invocation in the client application.

There are two main deliverables to this project: 1) an asynchronous
Web Service

message
handling server,

referred to as

Email2WS

S
erver, and 2) a set of
Web Service
s

for
demonstrating

business
-
to
-
business
application
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.

5.1

An Async
hronous Web Service Message Handling 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 c
reated 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

is comprised of a Service Listener
and a Proxy
. In our case, a SOAP req
uest is sent via SMTP that the Service L
istener
(
MailboxPoller

class of the
Pop3Client

namepace described in the following section
)
receive
s.

The L
istener extracts the SOAP request and passes it on to the Proxy, which is the
SOAP engine that invokes the
Web Service
.


The
Email2WS

server developed provides several functions for the service provider and is
located at
the service

provider’s si
te. The service requester writes a service client that invokes

15



a Web Service. The request is
encoded as a SOAP message and is

delivered to the service
provider’s email server
by the client proxy class
. The provider’s
Email2WS

server scans the
mailbox of

the given email server
s

to check whether SOAP
requests

have arrived or not. If
there are SOAP messages, the messages are
deserialized by the

SOAP engine. The SOAP
engine binds the requested services with the given services. SOAP response messages are
r
eturned to the requester’s email server by the
Email2WS

server.
When the mailbox polling
mechanism which exists on the requester’s side detects the response SOAP message in its
mailbox, the message is deserialized and the result returned to the calling co
de.

Figure
7

shows the message flow of this asynchronous Web Service approach using the
Email2WS

Server
.

Service Requester
Service Provider
SMTP Server
SMTP Server
mailbox
scanner
Web Service
SMTP Server
SMTP Server
mailbox
scanner
Internet

Figure
7
: Message Flow using Email2WS Server

5.2

Email2WS
Server
Architecture

Using currently existi
ng tools, IIS is used to host .NET Web Services. This allows users to
publish several services, and offers an intuitive approach to server administration and
configuration. Our comparable tool is the
Email2W
S

application. This tool registers services
th
rough a text file by the name of
services.txt
. It periodically checks the email accounts
that are associated with the registered services for incoming SOAP requests. If a request is
received, it invokes the proper service and sends a SOAP response using
email to the service
requester.

To register the service with the
Email2W
S

application, information regarding email endpoint
and the Web Service need to be provided.
services.txt

is
a CSV file with the
fields as
indicated in Table
2
. The first four fields

represent the email address of the
<email
address, subject>

tuple. The subject
-
prefix specified allows

an association between the
email account and the Web service as described by the tuple
<assembly
-
name, type
-
name, namespace
-
uri>
, w
hich are the last th
ree fields required by the
Email2WS

server
.


Once the server application is started, there are three basic commands that can be issued to it.
The command
start
, starts all the registered Web Services. Issuing a
kick

command forces the
server to poll for
requests immediately, and the
stop

command stops all the registered Web
Services.


16



description
server-name
Email server that is used. E.g. mail.domain-name.com
email-address
Email address to be checked for incoming requests. E.g.
something@domain-name.com
username
User name with which to log into email account. E.g.
something, or something@domain-name.com
password
Password for the email account.
subject-prefix
Identifies Web service (should be unique per Email2WS server).
assembly name
Name of Web Service assembly (fully qualified).
type name
Namespace and Class of Web Service.
namespace uri
URI of namespace.

Table
2
: Information needed to register a Web Service with Email2WS

Using
Email2WS
,
the overall structure and paradigm of .
NET HTTP Web Service
programming is retained. As
Figure 8

depicts, the client
and server using this server
application is as unaware of the underlying layers
mimicking

the client and server of current
.NET Web Services
using HTTP. The client application
makes a service request through
which is handled by the client proxy. This proxy object serializes the request as a SOAP
message. Since the system uses emails as the means of transporting SOAP messages, the
SOAP message is “serialized” as a email message

then sent using SMTP. The service provider
retrieves service requests by checking its inbox using POP3. The SOAP message is extracted
from the email message, which is then deserialized so that the Web method can be invoked.
Once results are obtained, t
he result is serialized as a SOAP response message, which is then
inserted as the body of an email message, then sent using SMTP back to the client. Back on
the client side, the response is obtained through POP3 as an email message with a SOAP
response me
ssage as its body. This SOAP message is extracted and deserialized, and the result
returned to the client application.

Email servers
CLIENT
Service Requester
1) Email SOAP request
4) Email SOAP response
SERVER
Service Provider
2) Email SOAP request
3) Email SOAP response
proxy
Email engine
SOAP engine
SMTP
POP3
proxy
Email engine
SOAP engine
SMTP
POP3

Figure
8
:

SOAP Request and R
esponse using Email2WS

The following section describes

the
namespaces used
in the project

which provide functionality
for both Service Providers as well as Service Requesters
.


17



5.2.1

Pop3Client Namespace

The
Pop3Client

namespace is where the
MailboxPoller

and
Pop3Client

classes
reside. The
Pop3Client

class is respo
nsible for issuing POP3 commands for tasks, as
described in RFC1939, such as logging in to the POP3 server, retrieving messages, and
deleting messages. The
MailboxPoller

class uses the Pop3Client class to poll mailboxes
by specifying a time interval. It
also defines a
Kick

method, which allows users of the
MailboxPoller

to poll on demand.
Figure 9

shows the inter
-
relationship between the
classes which form the Pop3Client Dynamic Link Library (DLL).

+Pop3Client()
+Pop3Client()
+Login()
+GetStats()
+Uidl()
+GetHeaders()
+Messages()
+GetMessage()
+Delete()
+Quit()
-uidl : UidlEntry[] = null
-connection : Pop3Connection
+Pop3Port : int = 110
-messages : Pop3MessageCollection
Pop3Client::
Pop3Client
-UidlEntry()
+Parse()
+Uid()
+MsgId()
-msgId : int
-uid : string
Pop3Client::
UidlEntry
+Pop3Connection()
-SendLine()
+Connect()
+SendCommand()
+Close()
-writer : StreamWriter
-stream : NetworkStream
-parser : LineParser
Pop3Client::
Pop3Connection
+LineParser()
+GetLine()
-s : Stream
-encoding : Encoding = Encoding.ASCII
-buffer : byte[]
-maxLineLength : int
-remnant : string = ""
-previousOverflow : bool
Pop3Client::
LineParser
+MailboxAccessDeniedException()
Pop3Client::
MailboxAccessDeniedException
+MailboxPoller()
+Kick()
-LoadKnownUids()
-WriteUidList()
+Poll()
+Quit()
-timer : Timer
-hostname : string
-port : int
-username : string
-password : string
-knownUidFilePath : string
-pollingInterval : TimeSpan
-handler : MessageHandler
-stopped : bool
Pop3Client::
MailboxPoller
«uses»
«uses»
«uses»
+Pop3MessageEnumerator()
+Reset()
+MoveNext()
+Current()
-pos : int
-messages : Pop3MessageCollection
-current : string[]
Pop3Client::
Pop3MessageEnumerator
«uses»
-Pop3Response()
+Parse()
+Success()
+Information()
+Lines()
+ToString()
-success : bool
-info : string
-lines : string[]
Pop3Client::
Pop3Response
«uses»
«uses»
«uses»
«uses»

Figure
9
: Pop3Client Namespace

5.2.2

Soap Namespace

The
Soap

namespace provides the capability to serialize and deserialize SOAP messages. It
also contains the class
Operation

which actually invokes the function of the Web Service.
It is able to return the resul
ts by deserializing the SOAP request, calling the correct operation
(function in the appropriate class), and then serializing the result back into a SOAP message.

The
Encoder

classes are used by virtually all applications in this project (the
Email2WS

appl
ication and the Web Service client applications through use of the
ServiceInvoker
).
The
Operation

and
Envelope

classes are only used by the
Email2WS

application.


18



-Encoder()
+Deserialize(in parameter : XmlElement, in type : Type) : object
+Serialize(in element : XmlElement, in type : Type, in data : object)
+Deserialize(in data : XmlElement) : object
+Serialize(in element : XmlElement, in data : object)
-DeserializeComplexType(in parameter : XmlElement, in type : Type) : object
-SerializeComplexType(in element : XmlElement, in type : Type, in data : object)
-encoders : Hashtable
Soap::
Encoder
+Deserialize(in data : XmlElement) : object
+Serialize(in element : XmlElement, in data : object)
Soap::
DoubleEncoder
+Deserialize(in data : XmlElement) : object
+Serialize(in element : XmlElement, in data : object)
Soap::
BoolEncoder
+Deserialize(in data : XmlElement) : object
+Serialize(in element : XmlElement, in data : object)
Soap::
Int32Encoder
+Deserialize(in data : XmlElement) : object
+Serialize(in element : XmlElement, in data : object)
Soap::
StringEncoder
+Envelope()
+Envelope(in element : XmlElement)
-MatchElement(in element : XmlElement, in localName : string, in namespaceUri : string, in strict : bool) : bool
+Document() : XmlDocument
-FindBody(in element : XmlElement) : XmlElement
+Body() : XmlElement
-document : XmlDocument
-body : XmlElement
Soap::
Envelope
+Operation(in mi : MethodInfo, in namespaceUri : string)
-Deserialize(in parameters : XmlElement) : object[]
+Invoke(in parameters : XmlElement, in instance : object, in responseBody : XmlElement)
-namespaceUri : string
-methodInfo : MethodInfo
-encoders : Hashtable
Soap::
Operation

Figure
10
: Soap Namespace

5.2.3

Internet Name
space

The
Internet

namespace
, as depicted in Figure 11,

includes classes which allow users to
create Internet messages per RFC2822. Specific to this project, this is used to create email
messages where the Rfc2822Header indicates information regarding: wh
ere the message
originated from; where it is designated to go; and other useful descriptive information. For the
purpose of this project, the Rfc2822Body contains the SOAP message as text and not as an
attached file.

+Rfc2822Body()
-DecodeBody()
+Count()
+this()
+ToString()
-msg : string[]
-eoh : int
Internet::
Rfc2822Body
+Rfc2822Header(in msg : string[])
-Unfold(in line : int) : string
-SkipWSP(in s : string, in start : int) : string
-IsWSP(in c : char) : bool
+this(in fieldName : string) : string
+Eoh() : int
-cache
-message : string[]
-eoh : int
Internet::
Rfc2822Header
+Rfc2822Message(in msg : string[])
+Header() : <unspecified>
+Body() : <unspecified>
-header
-body
Internet::
Rfc2822Message
«uses»
«uses»

Figure
11
:
Internet
Namespace


19



5.3

Client
-
side Aids

There are additional pieces needed for client
-
side developers. The following subsections
describe the
proxyGen

application as well as the
ServiceInvoker

class.

5.3.1

proxyGen

With Visual Studio .NET
, any developer wishing to create an application which uses a Web
Service can easily do so through use of an auto
-
generated proxy class file. This is done by the
IDE through a program called
Wsdl.exe
. This application generates code “using ASP.NET
from W
SDL contract files, XSD schemas and .discomap discovery documents. This tool can
be used in conjunction with disco.exe.”

The
proxyGen

application generates a proxy class
code file
which is used by client
-
application developers to interact with the Web Se
rvices using
SMTP.
The generated proxy classes inherit from
the
ServiceInvoker

class, which is
pared down version of the
SoapHttpClientProtocol

class that is used by HTTP based
.NET Web Services.

-GetInputParameters(in node : XmlNode, in xman : XmlNamespaceManager, in func : string) : string
-GetOutputType(in node : XmlNode, in xman : XmlNamespaceManager, in func : string) : string
-WriteClass(in def : XmlNode, in xman : XmlNamespaceManager, in output : IndentWriter)
-IsArray(in typeName : string, in node : XmlNode, in xman : XmlNamespaceManager, out arrayType : string) : bool
-WriteOperation(in operation : XmlNode, in xman : XmlNamespaceManager, in output : IndentWriter)
-WriteService(in service : XmlNode, in xman : XmlNamespaceManager, in output : IndentWriter)
-WriteServices(in input : XmlDocument, in xman : XmlNamespaceManager, in output : IndentWriter)
-GetNamesOfFunctions(in input : XmlDocument)
+Main(in args : string[])
-names : string[] = null
proxyGen::
Generator
+IndentWriter(in writer : TextWriter)
+Level() : int
+WriteLine(in format : string, in args : params object[])
+WriteLine()
+WriteLine(in s : string)
+WriteLine(in o : object)
-writer : TextWriter
-level : int
-spaces : string
proxyGen::
IndentWriter
«uses»

Figure
12
: proxyGen Namespace

5.3.2

ServiceInvoker

On the client
-
side, the
ServiceInvoker

provides some of the same features as the
Email2WS

application. The
ServiceInvoker

class has one public method,
Invoke
,
which returns an object.
This exposed method does two c
rucial things: it creates a SOAP
request message which it sends to the email address specified as the service endpoint, and it
polls its own mailbox for the reply and deserializes the SOAP response it obtains from the
Service provider
using the SOAP librar
y
.

This is the class that serves as the base class for all
generated proxy classes.


20



+ServiceInvoker()
+Invoke(in func : string, in vals : object[], in namesOfVariables : string[], in returnType : Type) : object
-GetSoapResponse(in requestId : string, in mailServer : string, in username : string, in password : string) : SoapEnvelope
#To : string
#SubjectPrefix : string
#Username : string
#Password : string
#MailServer : string
#From : string
ServiceInvoker::
ServiceInvoker
+configForm()
#Dispose(in disposing : bool)
-InitializeComponent()
-btnOK_Click(in sender : object, in e : EventArgs)
-label1 : Label
+From : TextBox
-label2 : Label
+MailServer : TextBox
-label3 : Label
-btnOK : Button
+Username : TextBox
-label4 : Label
+Password : TextBox
-components : Container = null
ServiceInvoker::
configForm
«uses»

Figure
13
: ServiceInvoker Namespace

5.4

Web Applications

To address the problem of B2B application integration, Web Servi
ces 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.

The second product of this project is a suite of
Web Service
s that

can be used for B2B
application
integration. Once the scannin
g and configuration application,
Email2WS

Server,
has been developed, we utilize three test cases to demonstrate how the server works and
compare
the

strengths and weaknesses
inherent to
asynch
ronous
Web Service
s
to those of
synchronous Web Services.
In the first instance, we demonstrate how a simple service such as
a
Calculator

Web Service

can be deployed. Once this is shown to work, we adapt a set of
synchronous
Web Service
s, used in
SoRetai
lXMLGen

[7]
, to use SMTP and deploy it using
the server developed
.
The objective of these
Web Service
s is to allow retailers and suppliers to
utilize a set of
Web Service
s allowing access to each others’ data in an asynchronous manner.
This is shown in
F
igure
14

and assumes

that the services are developed
using

a service
-
oriented architecture [
14
]. Some services are used internally within an organization,
while
other
s

services are published externally to allow other organizations to utilize them.


21



Retailer Purchasing Department
Retailer Inventory Department
Supplier Sales Department
Supplier Shipping Department
Enter Purchasing
Order Info
Submit PO
Submit Order
Confirmation
Enter Order
Fulfillment Info
Retailer
Supplier
Retailer DB
Supplier DB
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»

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

Such a scenario demonstrates the application of mixing B2B and
Enterprise Application
Integration (EAI)

approaches for business entities
.
With EAI
, the Web Services are locally
deployed and are more likely to be synchronous in nature. As a proposed solution to mixing
B2B and EAI application integration, we suggest one of two approaches: 1) use an
asynchronous approach for the B2B application integr
ation, but leave the EAI application
integration synchronous; or 2) use an asynchronous approach for both if time is not an issue.

Private UDDI
Service Provider
Service Requester
publish
bind
discover
Private UDDI
Service Provider
Service Requester
publish
bind
discover
EAI
Public UDDI
EAI

Figure
15
: EAI and B2B with private and shared service registries

These

Web Service
s for
retail

SCM will be compared to

corresponding sets of HTTP
-
based
Web Service
s based on
:

1)
similarity and/or difference in
SOAP format, 2) error handling
mechanisms, and 3) interactive processing
support
.
The first criterion will naturall
y 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 Service
s and synchronous HTTP
-
based
Web Service
s.

-

Once the request has been sent by service requester, have requester non
-
available (i.e.,
off) during the p
eriod 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 Service
s and synchronous HTTP
-
based
Web Service
s.


22



-

Both reques
ter 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 Service
s and synchronous HTTP
-
based
Web Service
s.

To determine the results of the l
ast criter
ia

will simply be to see how similar services,
asynchronous SMTP
-
based vs. synchronous HTTP
-
based,
support

interactive processing
requests. Expected results are detailed in Table
3
.

Criteria
Synchronous Web Services
Asynchronous Web Services
SOAP format
SOAP v1
SOAP + WS-* like constructs
fault tolerance
programmatic and HTTP 404
SMTP provided retry and
queuing mechanism
interactive
processing support
Shorter time span
Longer time span

Table
3
:
Cri
teria and Expected Results


23



6

Results

To determine the merits of asynchronous Web Services for B2B application integration
compared to synchronous ones,
a

test scenario
of retail SCM System was

examined
, which
exemplifies both EAI as well as B2B
.

The

scenari
o
was

selected to represent cases where B2B
application integration is useful

and to demonstrate that the Email2WS system is capable of
supporting both B2B as well as EAI
.
The
set of asynchronous Web Services was compared
against a set of synchronous Web
Services based upon message format, error handling, and
processing modes.

By developing an asynchronous Web Service message handling server built upon existing
SMTP servers and SOAP engines, this project brings significant benefits to both Web Service
prov
iders 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, businesse
s are
more likely to deploy asynchronous Web Services that are better suited for B2B interaction.
Secondly, a set of asynchronous Web Services
were

developed. These Web Services provide
working examples of how SMTP
-
based Web Services might be developed a
nd used to address
synchronicity issu
es inherent in B2B interactions
, and also demonstrate some elements of the
proposed W
eb Service extension mechanisms
. Lastly, it is shown that asynchronous SMTP
-
based Web Services are more fault
-
tolerant and allow long
er interaction time than synchronous
HTTP
-
based ones through a side
-
by
-
side comparison of asynchronous and synchronous Web
Services suites.

6.1

SOAP and WSDL

Through this project, we were able to see that the underlying structure of the SOAP messages
and WSDL
files remain
relatively
unchanged publishing the Web Service as an SMTP
-
based
service
instead of as a HTTP
-
based service. For generating the WSDL file used for
describing

SMTP
-
based

Web Services

the
Wsdl.exe

application
,

which is part of the .NET Framewor
k
SDK
,

can be

used.
This can be done either directly through invoking the tool or indirectly by
publishing the Web Services using IIS,

which was the approach taken.


With this latter
approach, only

an attribute from the original WSDL
, as seen in Code Samp
le 4
,
needed to be
edited to accurately reflect the deployment scenario.


<?
xml version="1.0" encoding="utf
-
8"
?>


-
<
wsdl:definitions

xmlns:http
="
http://schemas.xmlsoap.org/wsdl/http/
"

xmlns:soap
="
http://schemas.xmlsoap.org/wsdl/soap/
"

xmlns:s
="
http://www.
w3.org/2001/XMLSchema
"

xmlns:soapenc
="
http://schemas.xmlsoap.org/soap/encoding/
"

xmlns:tns
="
http://tempuri.org/
"

xmlns:tm
="
http://microsoft.com/wsdl/mime/textMatching/
"

xmlns:mime
="
http://schemas.xmlsoap.org/wsdl/mime/
"

targetNamespace
="
http://tempuri.org/
"

xmlns:wsdl
="
http://schemas.xmlsoap.org/wsdl/
">

.
..

Code Sample
4
: Original unedited WSDL


24



Taking the WSDL file which results from publishing the Web Service using IIS, we modify the
value of the
targetNameSpace

attribute of t
he
wsdl:definitions

node to be in the
form of
[email
-
address].[prefix]

where the email address is the address the
Email2Ws application will poll for Web requests with a subject line starting with the
prefix

prefix.

If the Wsdl.exe tool is directly invok
ed, there is no need to modify the WSDL file
after it is generated as the tool provides a command
-
line switch for specifying the namespace
for the generated proxy.

<?
xml version="1.0" encoding="utf
-
8"
?>


-
<
wsdl:definitions

xmlns:http
="
http://schemas.xmlso
ap.org/wsdl/http/
"

xmlns:soap
="
http://schemas.xmlsoap.org/wsdl/soap/
"

xmlns:s
="
http://www.w3.org/2001/XMLSchema
"

xmlns:soapenc
="
http://schemas.xmlsoap.org/soap/encoding/
"

xmlns:tns
="
http://tempuri.org/
"

xmlns:tm
="
http://microsoft.com/wsdl/mime/textMatching
/
"

xmlns:mime
="
http://schemas.xmlsoap.org/wsdl/mime/
"

targetNamespace
="
something@somewhere.com/my
-
prefix
"

xmlns:wsdl
="
http://schemas.xmlsoap.org/wsdl/
">

...

Code Sample
5
: Modified WSDL for SMTP deployment

The SOAP re
quest mes
sages remain unchanged because we incorporated endpoint information
in the email messages instead of the SOAP envelope header
s. This is not the approach
recommended by the WS Enhancements, but we chose this approach because we wanted to
retain the same pa
radigm for creating and consuming Web Services using SMTP as with HTTP
that is commonly used now.

6.2

Fault Tolerance

As stated in earlier portions of this paper, a motivating point behind the decision to provide
asynchronous communication between a Web Servic
e provid
er and requester using SMTP is
due to some of the inherent characteristics of SMTP. With HTTP,
one of the problems that is
frequently enc
ountered is reaching timeouts. A quick review of network concepts reveals that
this can occur at several diff
erent levels with HTTP, as shown

previously

in
Figure 6
.

This means that with HTTP, you can have timeouts occurring at N different layers. Using
email (SMTP and POP3) circumvents this issue because it is a one
-
way communication
protocol. The layers at wh
ich you have

timeouts are more controllable;
at the application or
proxy la
yers. This means that instead of having many levels where you may need to account
for timeouts, only two levels really need to be accounted for using email as the mechanism for
exc
hanging SOAP messages.

Using the
Email2WS

application and email to transport SOAP messages, the client
application is the only real point where a timeout is specified.
In the case of our test client
applications, we did not specify a timeout.

We were abl
e to make the service provider
unavailable for hours at a time after the initial request was made by the service requester and
still have the client application behave normally and receive the response after the service was
restarted and a response was gen
erated and sent by the service provider.

This is because the
SOAP request is sent via email to an email inbox which has the built in capability to queue
messages. Doing so provides flexibility to the service provider to receive requests even when

25



it is n
ot present, and still allows the request to be processed later on when the service becomes
available.

6.3

Interactive Processing Support

Through the use of email as the means of transporting SOAP messages between service
requester and provider, the time span

between communications is allowed to increase.

In the
specific example of the Web Services used in
SoRetailXMLGen
, we observed that the client
application is able to support longer transaction times without modification
to its code. This is
because we a
re now reliant on an
asynchronous transport protocol and have provided endpoints
for storing messages in the event that the end applications (specifically, the service provider)
are unavailable to service requests immediately for whatever reason.


26



7

Discussio
n and Conclusion

We compare the deployment of a suite of Web Services written in .NET for a SCM system to
gain some insight as to the benefits and shortcomings of using SMTP instead of HTTP. The
significance of these results
is

discussed and future work p
roposed.

7.1

Similarities using

HTTP and SMTP based Web Services

As we initially expected, there is a great amount of similarity between using HTTP and SMTP
as underlying transport protocols in the use of Web Services.

We wanted to design the system
in such
a

way that creating the client or server applications would remain unchanged. To this
end, we were successful. As demonstrated through the use of a pre
-
existing suite of Web
Services designed for SCM, there were only slight changes that needed to be made
so that they
could communicate with client applications using SMTP.

Using the designed system, service providers can create their Web Services as before. Using
C#, code for a simple calculator web method looks the same regardless of whether HTTP or
SMTP i
s used to transport SOAP messages between service requester and provider.

There is
nothing additional that needs to be done in order to make the Web Services use SMTP.

The
following code listing demonstrates that a Web Method originally written for use w
ith HTTP
and IIS remains unchanged: the code is the same as that when SMTP is used by the Web
Service to transport SOAP messages.

/// <summary>

/// This method deletes a supplier by the Supplier ID.

/// </summary>

[WebMethod]

public

void

deleteSupplier(
int

intSupplierID)

{


SqlConnection myConn =
new

SqlConnection(STRCONNECTION);


SqlDataReader myReader =
null
;


try


{



myConn.Open();


}


catch

(Exception s)

{



Console.WriteLine(s.ToString());

}




// get supplier information.


try


{




SqlCommand myCo
mmand =
new






SqlCo
mmand("usp_deleteSupplierInfo",




myConn);



myCommand.CommandType = CommandType.StoredProcedure;




SqlParameter sqlParam2 =






myCommand.Parameters.Add("@supplierID" ,





SqlDbType.Int);



sqlParam2.Value = intSupplierID;



myReader = myCommand.ExecuteReader();



myReader.Close();





27




}


catch

(Exception f)


{




C
onsole.WriteLine(f.ToString());


}

}

Code Sample
6
: deleteSupplier Web method from RetailerWS

The way in which the Web services are

deployed mimics that of Web Service deployment
when using HTTP.

With .NET Web Services which use HTTP,
once the Web Service is
developed, the service provider generates a WSDL file through the use of Microsoft’s
Wsdl

application. That same WSDL file can

be used for Web Services using SMTP by changing the
targetNamespace

value to reflect the email endpoint for the service as opposed to a
Uniform Reference Link (URL). The Web Service is registered
with
Email2WS

as opposed
to IIS, both of which can be star
ted and stopped.

Once a Web Service is deployed,
the client can use the exposed Web Metho
ds in pretty much
the same way as before. A proxy class is generated by a tool, which in our case is the
proxyGen

application.

Having auto
-
generated pro
xy classes al
lows implementation details
about the transport protocols to be hidden from the client application developers in both cases.
This being the case, the client application code which uses a Web Service which transfers
SOAP messages using SMTP utilizes the sa
me code as that of where the Web Service transfers
SOAP messages using HTTP.

7.2

Differences
using

HTTP and SMTP based Web Services

One thing to be aware of when creating Web Services for deployment in both environments is
to only use functions that
can be sup
ported
without using classes which are transport dependent
such as the
HttpContext

class found in the
System.Web

namespace
. Unless

Web
Service developers pay close attention to details such as this one in creating services, where
messages can be relayed u
sing SMTP or HTTP, issues may crop up which will render it
unusable in one or the other environment.

Perhaps the most crucial difference between the use of
SMTP and HTTP to transport Web
Service requests and responses is that it is readily apparent that a
client using the
Email2WS

server takes longer. In the case of the Enterprise Application Integration (EAI) example use in
the
SoRetailXMLGen
, the Windows client appeared to be unresponsive while the proxies
worked at obtaining the results, which demonstra
ted two things: 1) clients using the SMTP
approach allow the service provider longer, in fact indefinite, period of time to calculate result;
and 2) though SMTP is an asynchronous transport protocol, the underlying support provided
through the Email2WS ser
ver architecture allow a synchronous programming approach to be
adopted.

Another important difference is that client applications of Web Services which use SMTP to
transport SOAP messages should not be created as Web applications using technologies such
as

Microsoft’s ASP.NET.
Web applications are often picked as the method of deploying
applications for service requesters because the requesting entity does not have to maintain or
download a client application and also because web applications perform the b
ulk of its
calculations and logic on the server
-
side. For HTTP
-
based Web Services, this is an acceptable
approach because it is assumed that the requests will generally be handled bef
ore the

28



connection times out. However, o
ne of the primary reasons for

o
riginally

wanting to
implement the Email2WS system was because of
the perceived need to support longer
transaction times between s
ervice providers and requesters
. I
f we provide an SMTP approach
only to provide a user interface for such a transaction throu
gh HTTP which has a shorter
timeout value, everything provided to it by the use of SMTP is immediately negated.

Additionally, although the
Email2WS

application is considered to be a server application,
it is
not a SMTP server. The endpoint of requests and

responses using SMTP are POP3 mailboxes
which the
Emai
l2WS

application server checks: t
his is unlike the case where IIS hosts the
Web Services as endpoints.

The
Email2WS

server utilizes SMTP and POP3 servers but is not
itself either a SMTP or POP3 server
.

This means that it is likely to be more cost
-
efficient to
deploy Web Services using SMTP to transport SOAP messages because the service provider is
not required to maintain its own domain or email servers and the use of email provides a more
forgiving e
nvironment as regards system up
-
time.

7.3

Significance

There are several significant results that are demonstrated through the implementation of
Email2WS

and the accompanying tools.

Naturally, in and of itself, the suite of client and
server side tools provid
ed as the result of this project addresses the lack of readily available
tools for deploying SMTP
-
based Web Services. This allows developers of Web Services an
easy mechanism to deploy their formerly HTTP
-
based Web Services as email
-
based Web
Services sho
uld they choose to, with little or no modification of code.

The
proxyGen

application automates the generation of proxy classes for client application developers and
hides transport details through the
ServiceInvoker

class from which all proxy classes are
derived.
And from the perspective of the service provider,
the
Email2WS

server application
provides an easy mechanism for deploying services.

This is beneficial
all around
because it
now provides developers with a method to deploy
and consume
asynchronou
s Web Services.

This approach also
demonstrates
that the service provider does not need to be present all the
time. This is very useful for addressing the need of when services need to be maintained and
made temporarily unavailable. Through the use of
Em
ail2WS
, the service can respond to
requests as it becomes available to do so and does not necessarily need to be responsive to
request at the time at which the service requester submits a request.

Ideally speaking, the
service requester should be provided

with the same capability so that a client application can be
restarted after a request has already been made.

While MOM may

be able to

provide some of the same functionality of storing requests while
the service is unable to immediately respond to them th
rough the use of message queues, the
use of the developed
Email2WS

provides additional benefits over that of using a MOM
system. For one, as mentioned in Section 3 when we compared some proposed approaches, the
use of MOM requires that the developer becom
es knowledgeable about the use and possibly
administration of such a system. In using the
Email2WS

system, there is no server
application to maintain or understand as the only requi
rement

i
s the existence of an available
an
d

usable email address.

Also, al
though we did not make mention of batch process capabilities, that is a common mode
of operation with B2B applications. With this SMTP
-
based approach, batch processing would
be easy to support. We have already made mention of the ability for SMTP
-
based W
eb

29



Services to support longer interaction times, so batch processing would be a natural extension
of that supported feature.

7.4

Future Work

One interesting concept for future exploration is to combine the use of Business Process
Execution Language (BPEL) with

the use of the developed
Email2WS

to use as a solution for
B2B integration.
As the name implies, BPEL is an XML language used to describe business
processes which aims to enable long
-
running asynchronous processes that one typically sees in
business proc
esses, sometimes referred to as programming in the large [
25
]. Programming in
the large refers to “programming code that represents the high
-
level state transition logic of a
system” which “

encodes infor
mation such as when to wait for messages
, when to s
end
messages”
, etc. [
25
].

Additionally, as the WS
-
* become more universally adopted,
the
Email2WS

server should be
adapted to handle SOAP messages using WS Enhancements. We chose to not address this in
our implementation because the WS
-
* did not seem to b
e an industry standard wit
h many
adopters at the time this project was implemented.

As we pointed out in the previous section, the use of an email system allows for both client and
server side applications to be sporadically on. In our implementation, we
only provided this
capability to the service provider. An area of future work would be to engineer an approach
which will allow the service requester to maintain state
. This would allow the user of such a
client application to submit a request, turn off
the computer, then return at some later point and
restart the application to obtain the results.

The aim of this project was to implement a system which would enable businesses wishing to
deploy Web Services requiring longer processing time
by providing
a
mechanism for
deploying services using SMTP as transport. This project did not account for reliability or the
importance of message ordering, which is somewhat of a requirement if it is to considered
industrial strength. For that reason, future work coul
d also involve providing a mechanism for
handling message ordering. As an example of where this is significant, consider the case
where a bank customer wants to transfer money out of an account before closing it. They first
submit a request to transfer t
he funds, followed by a request to close the account. On the
server side, the sequence of requests may be received out of order and pose
s a problem. In
conjunction with handling message ordering, it would also be a good idea to implement some
reliability

framework.


30



8

Bibliography

[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 Applicati
ons
.
New York: Springer
-
Verlag.

[4] Staab, S., Aalst, W., Benhamins, V.R., Bussler, C., Maedche, A., Fensel, D., and Gannon,
D.
(2003).

Web

Service
s: Been There, Done That?
IEEE Intelligent Systems
,
18(
1
)
,

pp72
-
85.

[5
] 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
.

[6
] Bosworth
,

A
.
, et al.
Web Service
s Addressing (WS
-
Addressing). (March 2
004).
Retrieved
September 23, 2004

from
http://msdn.microsoft.com/library/default.asp?url=/library/en
-
us/dnglobspec/html/ws
-
addressing.asp
.

[7
] 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.

[
8
] 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.

[
9
] Hogg, K., Chilcott, P., Nolan, M., and Crinivasan, B. (2004). An Evaluation of Web
Service
s in the Design of a B2B Application.
Proceedings of the 27
th

Conference on
Australasian Computer Science
, 26, pp331
-
340.

[10
] 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

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


31



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

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

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

(WISE04).

[
15
] Message Queuing in Windows XP: New Features. White Paper retrieved February

26,
2005 from
http://www.microsoft.com/windows2000/technologies/communications/msmq/default.a
sp

[
16
]

Message Oriented Middleware. April 20, 2005 from
http://www.sims.berkeley.edu/courses/is206/f97/GroupB/mom/what_is_mom.html

[
17
]
Gailey, J.H. (2004).
Understanding Web Services Specification and the WSE
. Redmond,
WA
: Microsoft Press.

[
18
]
Haas, H. and Brown, A. (ed).
Web Services Glossary
. W3C Working Group Note
, (Feb
11, 2004). Retrieved May 10, 2005 from
http://www.w3.org/TR/2004/NOTE
-
ws
-
gloss
-
2004
0211/
.

[
19
]
Christensen, E. et al. Web Services Description Language (WSDL) 1.1
. W3C Note,
(March 15, 2001). Retrieved May 10, 2005 from
http://www.w3.org/TR/wsdl
.

[
20
] Powell, M. (2002). Asynchronous Web Se
rvice Calls over HTTP with the .NET
Framework. Retrieved April30, 2005 from
http://msdn.microsoft.com/library/default.asp?url=/library/en
-
u
s/dnservice/html/service09032002.asp
.

[
21
] Hygh, K. (2002).
Web Services using SMTP and WebSphere Studio: Part 1


Introduction and Design
. Retrieved April 30,

2005 from
http://www
-
106.ibm.com/developerworks/websphere/library/techarticles/0212_hygh/hygh.html

[
22
]
Champion, M
, et al.
Web Services Architecture
. W3C
Working Draft
,
(Nov 14, 2002
)
.
Retrieved May 23, 2005 from
http://www.w3.
org/TR/2002/W
D
-
ws
-
arch
-
20021114
.

[
23
] Comer, D.E. (2001).
Computer Networks and Internets with Internet Applications
. Upper
Saddle River, New Jersey: Prentice
-
Hall.

[
24
] Olson, M., Obbuji, U., “The Python Web services developer: SOA
P over SMTP”, (2003,
March 4),

http://www
-
106.ibm.com/developerworks/webservices/library/ws
-
pyth12.html
.

[
25
]
BPEL. Retrieved May 28, 2005 from
http:
//en.wikipedia.org/wiki/BPEL
.