See discussions, stats, and author profiles for this publication at: [Link]

net/publication/236860265

Introduction to Web Services

Chapter · January 2007

DOI: 10.4018/978-1-59904-045-5.ch007

CITATIONS READS

9 1,248

5 authors, including:

Jorge Cardoso John A Miller

University of Coimbra University of Georgia
259 PUBLICATIONS   5,853 CITATIONS    240 PUBLICATIONS   8,299 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Keystone View project

Service Design (Thinking) View project

All content following this page was uploaded by Jorge Cardoso on 16 May 2014.

The user has requested enhancement of the downloaded file.

 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Introduction to Web Services

Cary Pennington, Jorge Cardoso, John A. Miller*, Richard Scott Patterson, Ivan Vasquez

LSDIS Lab
Computer Science Department
University of Georgia
Athens, GA 30602
*contact jam@[Link]

Jorge Cardoso
Department of Mathematics and Engineering
University of Madeira
9000-390 - Funchal
jcardoso@[Link]

1
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Introduction to Web Services

ABSTRACT
This chapter introduces the theory and design principles behind Web Service

technology. It explains the models, specifications, and uses of this technology as a

means to allow heterogeneous systems to work together to achieve a task. Furthermore,

the authors hope that this chapter will provide sufficient background information along

with information about current areas of research in the area of Web Services that readers

will come away with an understanding of how this technology works and ways that it

could be implemented and used.

Introduction

As the World-Wide Web (WWW) exploded into the lives of the public in the 1990’s,

people suddenly had vast amounts of information placed at their fingertips. The system

was developed to allow information sharing within internationally dispersed working

groups. The original WWW consisted of documents (i.e., Web pages) and links between

documents. The initial idea of the WWW was to develop a universal information

database to publish information that could be accessed in a reliable and simple way by

consumers. The information would not only be accessible to users around the world, but

information would be linked so that it could be easily browsed and quickly found by

users. Organizations soon realized the importance of this technology to manage,

organize, and distribute their internal data and information to customers and partners.

2
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Figure 1. The evolution of business usage on the WWW

As organizations started to implement business-to-customer and e-commerce

solutions, they realized that the initial technologies associated with the WWW were not

sufficient to sell products over the Internet. Additional functionality was required to

guarantee that transactions were conducted in a secure way. To this end, SSL (Secure

Sockets Layer), a protocol defined by Netscape, was developed for transmitting private

documents via the Internet. Using SSL, organizations were able to implement a solution

to obtain confidential user information, such as credit card numbers.

With globalization, organizations were progressively undertaking mergers and

acquisitions. This has created organizations with an IT environment composed of

disparate legacy systems, applications, processes, and data sources. In order to meet

increasing customer and business partner expectations for real-time information,

organizations were required to link their heterogeneous, autonomous and distributed

systems to improve productivity and efficiency. This important requirement leaded to

the development and deployment of EAI (Enterprise Application Integration) solutions.

EAI platforms were used for integrating incompatible and distributed systems such as

ERP (Enterprise Resource Planning), CRM (Customer Relationship Management),

SCM (Supply Chain Management), databases, data sources, data warehouses, and other

important internal systems across the corporate enterprise. While useful, most EAI

3
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

frameworks required costly and proprietary protocols and formats, which presented

many technical difficulties when it was needed to integrate internal systems with

external systems running on partners’ computers.

The limitations of EAI solutions made most organizations realize that integrating

internal systems with external systems to business supply chain members was a key to

staying competitive, since the majority of business processes spanned across several

organizations. Internal and external systems needed to communicate over networks to

allow businesses to complete a transaction or part of a transaction. To achieve this level

of integration, business-to-business (B2B) solutions were developed. B2B

infrastructures were directed to help organizations to streamline their processes so they

could carry out business transactions more efficiently with their business partners (such

as resellers and suppliers). To reach a higher level of integration, most B2B solutions

have relied on the use of XML as the language to represent data. XML allows one to

model data at any level of complexity since it is extensible with the addition of new

tags. Data can be published in multiple formats. In contrast to the proprietary protocols

used by EAI platforms, XML is vendor and platform independent allowing standard

commercial software to process any conforming document.

Many organizations have already seen and experience the advantages in using XML

to represent data for Web-based information exchanges (such as B2B communications).

Nevertheless, organizations realized that their B2B strategies have lead the development

of architectural solutions that often exhibited a tight-coupling among interacting

software applications which limited the flexibility and dynamic adaptation of IT

systems. As a result and to overcome these limitations, the concept of Service-Oriented

Architecture (SOA) was introduced and defined a method of designing, developing,

deploying and managing discrete pieces of computer logic (i.e., services) within the

4
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

WWW. The SOA goals are to achieve structuring, loose coupling, and standardization

of business functionality among interacting software applications. Applications invoke a

series of discrete services in order to perform a certain task. A service is carried out by a

service provider in response to the request of a service consumer. The most prominent

implementation of the SOA principle uses XML and Web services as its technological

backbone.

Web services are based on distributed computing technology and provide a standard

means of interoperating between different software applications across, and within,

organizational boundaries, using XML protocols and formats. Web Services comply

with several WWW standards, such as Web Services Definition Language (WSDL) and

Simple Object Access Protocol (SOAP). These standards enable interoperability by

using XML-based communications protocols and service definitions. The use of

standard XML protocols makes Web services platform, language, and vendor

independent, and an ideal candidate for use in SOA implementations.

This chapter will introduce SOA (Service-Oriented Architecture), Web service

technology and its standards. It begins in section 2, with a brief history of distributed

computing, which serves as the backdrop for the development of today’s Web service

technology. The guiding principle behind the development of Web service technology is

SOA which is described in section 3. Section 4 gives an overview of the role of Web

services in the context of SOA. This section gives a description of today’s standards and

technologies for Web services. Section 5 introduces the second-generation of Web

Services Protocols. It looks in detail at the threats and standards relevant to the Web

Services Security landscape and examines problems and solutions in reliability and

transactions of Web Services. Clearly, these areas must be addressed before Web

service technology will be widely adopted. Section 6 explains how to develop Web

5
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Services starting from the initial design and continuing until deployment and

publication. A summary and conclusions can be found in section 7 of this chapter.

A Brief History of Distributed Computing

Once networking became widespread across academia and industry, it became

necessary to share data and resources. In the early years of distributed computing,

message passing (e.g., using for example sockets developed in the early 1980’s) was the

prevailing method for communication. This involved encoding the data into a message

format (i.e., how a structured piece of information is encoded prior to transmission) and

sending the encoded data over the wire. The socket interface allowed message passing

using send and receive primitives on Transmission Control Protocol (TCP) or User

Datagram Protocol (UDP) transport protocols for low-level messaging over Internet

Protocol (IP) networks. Applications communicated by sending and receiving text

messages. In most cases, the messages exchanged conformed to an application-level

protocol defined by programmers. This worked well but was cumbersome in the fact

that the data had to be coded and then decoded. Using this approach, two programmers

developing a distributed application must have knowledge of what the other is doing to

the data. Programmers had to spend a significant amount of time specifying a

messaging protocol and mapping the various data structures to and from the common

transmission format.

As the development of distributed computing applications increased, new

mechanisms and approaches became necessary to facilitate the construction of

distributed applications. The first distributed computing technology to gain widespread

use was Remote Procedure Call (RPC). RPC technology was made popular in the 1980s

by Sun Microsystems. RPC uses the client/server model and extends the capabilities of

6
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

traditional procedure calls across a network. Remote procedure calls are designed to be

similar to making local procedure calls. While in a traditional local procedure call

paradigm the code segments of an application and the procedure it calls are in the same

address space, in a remote procedure call the called procedure runs in another process

and address space across the network on another processor.

RPC (Birrell, 1995) proved to be an adequate solution for the development of two-

tier client/server architectures. As distributed computing became more widespread, the

need to develop, for example, N-tier applications emerged and RPC could not provide

the flexibility and functionality required.

With such applications, multiple machines may need to operate simultaneously on

the same set of data. Therefore, the state of that data became of great concern. Research

in the area of distributed objects allowed overcoming this problem with the

specification of two competing technologies: Common Object Request Broker

Architecture (CORBA) and Distributed Common Object Model (DCOM). Later, Java

Remote Method Invocation (RMI) was developed and also became a competitor.

The CORBA [4, 5] standard was developed by the Object Management Group

(OMG) starting in the 1990’s and defines an architecture that specifies interoperability

between distributed objects on a network. With CORBA, distributed objects can

communicate regardless of the operating system they are running on (for example,

Linux, Solaris, Microsoft Windows, or MacOS). Another primary feature of CORBA is

its interoperability between various programming languages. Distributed objects can be

written in various languages (such as Java, C++, C, Ada, etc.). The main component of

CORBA is the ORB (Object Request Broker). Objects residing in a client make remote

requests using an interface to the ORB running on the local machine. The local ORB

sends the request to the remote ORB, which locates the appropriate object residing in a

7
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

server and passes back an object reference to the requester. An object residing in a client

can then make the remote method invocation of a remote object. When this happens the

ORB marshals the arguments and sends the invocation over the network to the remote

object’s ORB which invokes the method locally and sends the results back to the client.

DCOM (Brown & Kindel, 1996) is a protocol, developed by Microsoft, which

enables communication between two applications running on distributed computers in a

reliable, secure, and efficient manner. DCOM is an extension of the Component Object

Model (COM). COM is an object-based programming model and defines how

components and their clients interact. COM allows the development of software

components using a variety of languages and platforms to be easily deployed and

integrated. The distributed COM protocol extends the programming model introduced

by COM to work across the network by using proxies and stubs. Proxies and stubs

allow remote objects to appear to be in the same address space as the requesting object.

When a client instantiates a component that resides outside its address space, DCOM

creates a proxy to marshal methods calls and route them across the network. On the

server-side, DCOM creates a stub, which unmarshals method calls and routes them to

an instance of the component.

Java RMI (Dwoning, 1998) is a package for writing and executing distributed Java

programs by facilitating object method calls between different Java Virtual Machines

(JVM) across a network. Java RMI hides most of the aspects of the distribution and

provides a conceptually uniform way by which local and distributed objects can be

accessed. An RMI application consists of a server interface, a server implementation, a

server skeleton and a client stub, and a client implementation. The server

implementation creates remote objects that conform to the server interface. These

objects are available for method invocation to clients. When a client wishes to make a

8
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

remote method invocation it invokes a method on the local stub, which is responsible

for carrying out the method call on the remote object. The stub acts as a local proxy. A

server skeleton exists for each remote object and is responsible to handle incoming

invocations from clients.

CORBA, DCOM, and Java RMI enjoyed considerable success, but they present a set

of shortcoming and limitations when used in Web environments. For example, they tend

to create tightly-coupled distributed systems, some are vendor and platform specific

(e.g., COM/DCOM only runs on Windows), the distributed systems developed run on

closely administered environment, some use complex and proprietary protocols, and

specific message formats and data representation. With the growth of the Web, the

search soon started for a Web compliant replacement for this technology. In the next

sections, we will see that Web services are currently the most natural solution to

develop distributed systems in the Web.

Service-Oriented Architecture

As we have seen, in the 1980’s distributed computing was introduced. This research led

to the development of distributed objects architectures through the 1990’s. The

distributed platforms developed, such as Java RMI and DCOM, had several restrictions.

For example, RMI was limited to Java, while DCOM was limited to Microsoft

platforms. Moreover, distributed applications developed using different platforms were

difficult to integrate. Integration was and is still one of the major concerns for Chief

Information Officers. Figure 2 gives us a very good indication that application

integration tops the priority list of high ranking business people.

9
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Top strategic softw are platform projects

Deregulation 3%
Other 4%

Manufacturing softw are 5%

Engineering softw are 7%

Building Internet Company 8%

Sys. Mgmt infrastructure 12%

e-procurement Web site 12%

Commerce Server 13%
Marketing apps on Web site 15%
Financial (Accounting) 16%
Intranet Improvements 19%
Database upgrade 21%
HR 23%
SCM/Logistics 24%
CRM 30%
e-business 33%
Application Integration 35%

0% 5% 10% 15% 20% 25% 30% 35% 40%

% of respondents

Figure 2. Priority list of CIOs (Channabasavaiah & Tuggle, 2003)

To cope with the restrictions of more traditional distributed objects architectures, in

the early 2000’s, the concept of Service-Oriented Architecture (SOA) was introduced

(or reintroduced, since in reality, the concept SOA was defined by Sun in the late

1990’s to describe Jini (Waldo, 1999)). SOA describes an approach which facilitates the

development and composition of modular services that can be easily integrated and

reused to create distributed applications. It promises the development of truly flexible

and adaptable IT infrastructures. According to the W3C, a Service-Oriented

Architecture is a set of components which can be invoked, and whose interface

descriptions can be published and discovered. Components are made available as

independent services that are accessed in a standardized way.

In order for SOA to enjoy greater success than it predecessors, it should consider the

following attributes:

• Scalable – The past solutions were not designed with the scale of the Web in

10
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

mind. SOA should work in a variety of settings, such as within an

organization, between business partners and across the world.

• Loosely-coupled – SOA is an evolution from tightly coupled systems to

loosely coupled ones. Senders and receivers of a SOA should be independent

of each other; the source can send the message independently of the target.

Tight coupling is not suitable for SOA since it leads to monolithic and brittle

distributed applications. Even trivial changes in one component lead to

catastrophic breaks in function. Small changes in one application require

matching changes in partner applications (Channabasavaiah & Tuggle, 2003).

• Interoperability – One party should be able to communicate with another

party regardless of the machine they are running on.

• Discovery – One party should be able to communicate with a second party

selected from a set of competent candidates. Services need to be dynamically

discoverable. This is accomplished through services such as a directory of

service descriptions.

• Abstraction – A SOA abstracts the underlying technology. Developers can

concentrate on building services for business users rather than connecting

systems and applications.

• Standards – Interaction protocols must be standardized to ensure the widest

interoperability among unrelated institutions. Contracts should also be

standardized. Explicit contracts define what may be changed in an application

without breaking the interaction. Furthermore, standards are the basis of

interoperable contract selection and execution.

11
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

When comparing SOA with previous approaches we can find the following major

differences. Traditional Middleware, such as distributed object systems, are based on

the client-server paradigm, have heavily asymmetric interaction model, are biased

towards synchronous protocols, assign public interfaces to network accessible objects,

and support “name-oriented” object discovery. On the other hand, Service-Oriented

Middleware are based on a peer-to-peer paradigm, have symmetric interaction models,

mixes synchronous and asynchronous protocols, assigns public contracts to network

accessible objects, and supports capability based service discovery (Cardoso, Curbera,

Sheth, 2004).

Service Oriented Architecture and Web Services

Most distributed computing technologies have the concept of services and are defined

by interfaces. While there are many different possibilities for developing an SOA (e.g.,

Web Services, Java RMI, DCOM, and CORBA), Web Services is currently the most

desirable solution since it eliminates many of the interoperability problems between

applications and services. Web Services provide many of the necessary standards that

are crucial for making a distributed system work. It should be noticed that using Web

Services does not necessarily mean that there is an SOA. Also, it is possible to have a

Service-Oriented Architecture without Web Services.

There are three common actions associated with a service in SOA - discovery,

request, and response. Discovery is the process of finding the service provides the

functionality that is required. A request provides the input to the service. The response

yields the output from the service. It follows easily that this architecture must have three

primary actors: requestor, provider, and registry.

12
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Figure 3 Process of Discovery (Booth, 2004)

The beginning of this figure (step 1) shows the process that two participants would

become aware of one another. This is accomplished as the service provider publishes

the Web Service Description (WSD) and Semantics (Sem.) to a registry after which the

service requestor would discover that service. In step 2, the semantics and description

are agreed upon so that there will be no misunderstanding about the data that is being

exchanged during this communication. Once the WSD and semantics are accepted by

and loaded into both the participants (step 3) then they can interact to carry out the

operation that was needed.

A service provider may develop and deploy one or more Web services. Each service

must contain at least one operation. Operations are also referred to as endpoints because

they are the part of the service that actually does the processing.

13
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

What are Web Services?

Web services are modular, self-describing, self-contained applications that are

accessible over the Internet (Curbera & Nagy, 2001). They are the most popular

realization of the Service-Oriented Architecture. A Web service is a software

component invokable over the Web via an XML (XML, 2005) message that follows the

SOAP (SOAP, 2003) standard. The component provides one or more operations for

performing useful actions on behalf of the invoking client. These operations and the

formats of the input and output messages are described using WSDL (Christensen &

Curbera, 2001). Being based on these Web standards makes Web services both

implementation language and platform independent. Description of services in a

language neutral manner is vital for the widespread use of Web services. For general

usability, a service must be described and advertised. WSDL takes care of the

description by providing a language to describe a service in enough detail to invoke any

of its operations. Service providers describe their Web services and advertise them in a

universal registry called UDDI (UDDI, 2002). This enables service requestors to search

the registry and find services, which match their requirements. UDDI allows for the

creation of registries that are accessible over the Web. A registry contains content from

the WSDL descriptions as well as additional information such as data about the

provider. Clients may use one or more registries to discover relevant services.

To describe Web services further, let us look at an example scenario. A company

called Moon Company is a product distributor. They keep track of their clients, goods,

and orders through a system that they have in-house. They do not want to provide

unlimited access to this system to their customers, but they would like their customers

to be able to place orders easier. Using Web services, the Moon Company can create an

interface to their interior system so that a customer can be looked up, and once

14
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

authenticated, order products. With these services in place, Moon needs only provide

the WSDL definitions of the services to their clients and the clients will be able to

compose any system on their side to handle ordering in any way they see fit. Since

Moon does not know what type of system their customers are using, other remote

technologies would be more difficult to implement.

SOA and Web Service Standards

The use of standard protocols is one of the aspects that allow SOA to deploy technically

compatible services. Currently, Web service standards are the preferred solution to

develop SOA-based products. Web services technology has gained a suitable degree of

maturity and is being used to easily publish business functions to an intranet or the

Internet for remote execution. Business functions can reside in popular applications

such as ERP (enterprise resource planning), CRM (customer relationship management),

and SCM (supply chain management) systems.

Some of the standards associated with Web services are indispensable to developing

SOA-based solutions as illustrated in Figure 4.

Figure 4 Web Services and List Standards (Cardoso, Curbera, Sheth, 2004)

15
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

The most well-known protocols will be presented and discussed in this section, while

the second-generation Web services standards, such as WS-Security, WS-Coordination,

WS-Transaction, and WS-Policy will be discussed in the next section.

Basic Web Service Standards

XML, SOAP, WSDL and UDDI (Graham & Simenov, 2002) are the fundamental

elements to deploy SOA infrastructures based on Web services (see Figure 3). XML is

the standard for data representation; SOAP specifies the transport layer to send

messages between consumers and providers; WSDL describes Web services; and UDDI

is used to register and lookup for Web services.

Figure 5 The relationship between XML/SOAP/WSDL/UDDI

XML. XML, the emerging standard for data representation, has been chosen as the

language for describing Web services. XML is accepted as a standard for data

interchange on the Web allowing the structuring of data on the Web. It is a language for

semi-structured data and has been proposed as a solution for data integration problems,

because it allows a flexible coding and display of data, by using metadata to describe

the structure of data (using DTD or XSD). A well-formed XML document creates a

16
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

balanced tree of nested sets of open and closed tags, each of which can include several

attribute-value pairs.

SOAP (Simple Object Access Protocol). This standard defines the types and formats of

XML messages that may be exchanged between peers in a decentralized, distributed

environment. One of the main objectives of SOAP is to be a communication protocol

that can be used by distinct applications developed using different programming

languages, operating systems, and platforms. Many software vendors are producing an

implementation of SOAP into their systems. Examples of major vendors include Sun,

Microsoft, and IBM. The latest version of the standard is SOAP 1.2

([Link] SOAP specification is not completed yet and as it goes

through the W3C standardization process some minor changes will certainly occur.

The current specification defines a skeleton that looks like the listing below. The

envelope defines the namespace of the SOAP specification and the encoding style that

was used to create this message. The Header section is optional and contains additional

information about the message. The Body section contains the data that is being

transferred.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="[Link]
soap:encodingStyle="[Link]
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
Figure 6 SOAP Skeleton Listing (SOAP, 2002)

17
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

WSDL (Web Service Description Language). WSDL is the major language that

provides a model and an XML format to describe the syntactical information about Web

services. It is a W3C standard XML language for specifying the interface of a Web

service. This standard enables the separation of the description of the abstract

functionality offered by a service from concrete details of a service implementation by

defining the interface that Web services provide to requesters. The definition of the

interface (called a port type in version 1.x and called interface in version 2.0) gives the

signatures for all the operations provided including operation name, inputs, outputs and

faults. Beyond the interface, information about the service itself and allowed bindings is

included in WSDL documents. The latest version of the standard is WSDL 1.1

([Link] although WSDL 2.0 has become a candidate

recommendation ([Link] WSDL 1.1 uses XML Schema

Definition (XSD) which provides constructs for creating complex types

([Link]

The following is brief and incomplete copy of a WSDL file. Notice how it defines the

type of data to be used, the operations that exist in the service and the type of inputs and

outputs that those operations require. With this information, a call to invoke any

operation in this service can be made and carried out successfully.

<wsdl:definitions
targetNamespace="mooncompany"
xmlns:wsdl="[Link]
xmlns:wsdlsoap="[Link]
xmlns:xsd="[Link]
<wsdl:message name="SearchCustomerResponseMessage">
<wsdl:part element="impl:SearchCustomerResponse"
name="SearchCustomerResponse"/>
</wsdl:message>
<wsdl:portType name="SearchCustomer">
<wsdl:operation name="search">
<wsdl:input message="impl:SearchCustomerRequestMessage"/>

18
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

<wsdl:output message="impl:SearchCustomerResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="CRMServiceSoapBinding"
type="impl: SearchCustomer ">
<wsdlsoap:binding style="document"
transport="[Link]
<wsdl:operation name="search">
<wsdlsoap:operation soapAction="search"/>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="CRMService">
<wsdl:port binding="impl:CRMServiceSoapBinding" name="CRMService">
<wsdlsoap:address
location="[Link]
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Figure 7 Partial WSDL Listing (Semantic Web Services Challenge, 2006)

UDDI (Universal Description, Discovery, and Integration). Currently, the industry

standards available to register and discover Web services are based on the UDDI

specification (UDDI, 2002). Once a Web service is developed, it has to be advertised to

enable discovery. The UDDI registry is supposed to open doors for the success of

service oriented computing, leveraging the power of the Internet. Hence the discovery

mechanism supported should be scaled to the magnitude of the Web by efficiently

discovering relevant services among tens and thousands (or millions according to

industry expectations) of Web services. UDDI standard defines a SOAP-based Web

service for locating WSDL descriptions of Web services. This standard defines the

information content and the type of access provided by service registries. These

registries provide the advertisement of the services that can be invoked by a client.

UDDI can store descriptions about internal Web services across an organization and

public Web services located in the Internet.

19
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Other Web Services Standards and Protocols: WS-*

Besides thecore standards discussed in section 4, there are several other standards

needed for Web services to be used in practice. This section gives a quick tour of some

of these standards.

Web Service Policy

In the process of discovering a service, there is an inherent problem. We might write a

query that yields ten services that match our keyword, or meet our input and output

specifications. Yet, at this point, we do not know what these services require of the

messages that will be exchanged. Policy in Web services adds this information to the

description. It allows the provider of the service to give all the information they see fit

about the service; requirements, capabilities, and quality. With this information, the best

service can be chosen from the discovered services based on much more complete

information than just functional requirements and keywords. (Verma, Akkiraju, &

Goodwin, 2005)

WS-Policy

WS-Policy is a specification of a framework for defining the requirements and

capabilities of a service. In this since, a policy is nothing more that a set of assertions

that express the capabilities and requirements of a service. The specification WS-Policy

([Link] defines

terms that can be used to organize a policy. Once a provider has a policy defined in

XML, then he must publish that information by referencing it in the description of the

service.

20
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

WS-PolicyAttachment

This defines the method for attaching a policy to a WSDL file so that it can be

published to the UDDI and thus used in deciding on services. There are several

mechanisms defined for accomplishing this task. The simplest method is to write the

policy directly into the WSDL file. A more complex, and more powerful method is to

construct the policy as a stand alone file that is referenced in the WSDL file as a URI.

These references can exist at any element of the WSDL. WS-Policy and WS-

PolicyAttachment together give us hierarchy based on to which element the policy is

attached and direction for merging policies together to create an effective policy for an

element. (WS-PolicyAttachment, 2005)

Both WS-Policy and WS-PolicyAttachment have recently been submitted to W3C for

standardization.

Web Service Security

In this section, we examine some of the concepts, theories, and practices in securing

Web services at an introductory level. Our aim is for you to become familiar with these

as well as the terms used. Security is a constantly changing arena driven by the changes

in associated technologies.

The World Wide Web, or Web, has in some way touched the lives of most people

living in an economically developed country. Unfortunately, it has not always been in a

positive way. This is because once a computer is connected to the Web; it becomes part

of a system that was not designed with security and privacy in mind. Computers hold

information, sometimes sensitive information, for much longer than most users realize.

Even during the simple event of entering information into a Web browser, information

is stored onto disk. This may take place in a temporary file. Although once the

information is sent to a Web server and the file is deleted, the information is still present

21
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

on the disk; even though the file reference is gone. Many unsavory characters have

learned how to glean this information off of remote systems through vulnerabilities of

the operating system.

A basic definition of security can be thought of as ‘keeping unauthorized access

minimal’. This is true not only on the Web but also in our daily lives. We lock our doors

when we leave our houses in an effort to keep unauthorized visitors out. This definition

is simple, but it is clear. A more complete definition may become too convoluted. Let us

consider a definition for privacy, ‘not making public what may be considered personal’.

Not a fancy definition, rather straight to the point. We all have different ideas of what is

personal to us, and what being made public means. However, I think we can all agree

that having our Social Security Number and checking account information sold to the

highest bidder is a violation of our privacy.

Now that security and privacy are defined, let us consider how this fits into the Web.

Suppose you would like to purchase a book online. Once you have found the book and

placed it in your “Cart” it is time to checkout. In order to checkout you must pass

through some security. Typically, you will be asked for your credit card information and

billing address. This is the first security checkpoint and this information is verified with

your bank; as well as making sure the card has not been reported stolen. The next

checkpoint is physical possession of the card, which is verified by a security code on the

back of your card. So, you the consumer trust this Web site to send the book, or you

would not have placed the order, and the Web site trusts you for payment since it has

verified all your information. Trust is a key component of security and privacy as we

shall see. As a consumer using sensitive personal information to make a purchase, have

you considered privacy of your information? Somewhere in the information exchange

between you and the Web site an agreement has been made; whereas, the Web site has

22
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

promised not to sell your personal information. However, how well is it protected? Your

credit card information, billing address, and security code are now stored in two places,

the Web sites server and on your PC. More than likely one of those unsavory characters

will not spend the time and effort to get one credit card number off a PC when with a

little more work they could have access to thousands of entries. So this brings us back to

security. This time that of the Web site server. As you can see, security and privacy go

hand and hand, with mutual trust holding them together.

The above scenario is a simple client-server process, much like those that currently

encompasses the Web. However, Web services extend the client-server model and are

distributed as discussed in earlier sections. Although this combination is what gives

Web services such promises in the SOA, it is also an area of concern for security and

privacy. The more doors and windows a home has, the more opportunities a thief has,

the more vigilant the home owner must be. This can be applied to Web services as well.

Web services increases the number of access points to data and ultimately machines.

Furthermore, because the access to data is increased, the sharing of information is

increased. This in itself is opens the possibility of privacy invasion.

Now that the stage has been set, let us look at the specific security and privacy

considerations. Web services are a distributed cross-domain environment. Therefore, it

is difficult to determine the identity of the actors; in this case who is the service

requester and who is the service provider. Message level security and privacy is

important since these invocations may cross un-trusted intermediaries. It is necessary

for the requester and provider to have a protocol for discovering each others policies

and negotiating constraints at run-time, prior to interaction. Privacy rights and

agreements should be explicitly described and agreed upon. We will look more closely

at these considerations in the following paragraphs.

23
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Message level security involves securing all aspects of the SOAP message.

Encryption plays a large role in providing integrity of messages between the requester

and the provider while traversing intermediaries. In addition, the requester and the

provider can not always be trusted.

Man-In-The-Middle attack is when an attacker is able to compromise a SOAP

message in transit. An attacker may gain access to confidential information contained in

the message or may alter the message.

Unauthorized Access attack takes place when an attacker is able to gain access to a

Web service which they do not have permissions to use. This can happen through brute-

force or by compromising a SOAP message thereby gaining a username and token. An

attacker may also pose as a legitimate Web Service in order to gain an authentication

mechanism, this is known as Spoofing.

The above threats can be alleviated using proper authentication and encryption

techniques. However, there are other attacks that can only be alleviated through good

programming habits and proper verification of parameters.

SQL injection attack is the insertion of malicious SQL statements. This requires

preprocessing of any parameters passed to an operation which queries a SQL database

to alleviate this threat. Command injection attacks are similar to SQL injection attacks

in that malicious system commands are injected into the SOAP in an effort to exploit

the systems vulnerabilities. This threat can be alleviated by proper configuration

permissions and preprocessing.

Proper authentication and encryption schemes can alleviate threats which

compromise message integrity. Point-to-Point schemes which are implemented at the

transport layer, such as VPN, SSL, or IPSec, provide a ‘secure tunnel’ for data to flow,

however, they can not guarantee the integrity of the message. End-to-End schemes,

24
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

which are implemented at the application layer, can guarantee the confidential integrity

of the message and that the message has not been altered. This is because the message is

encrypted and digitally signed with a key. End-to-End schemes also offer the

granularity necessary for Web services such that sections of the SOAP message may be

encrypted while other sections are not.

WS-Security Framework

The WS-Security specification provides a framework and vocabulary for requesters and

providers to secure messaging as well as communicate information regarding security

and privacy. There are other security related specifications worth mentioning. XML-

Encryption specifies the process of encrypting data and messages. XML-Signature

provides a mechanism for messages integrity and authentication, and signer

authentication. XACML is an XML representation of the Role Based Access Control

standard (RBAC). XACML will likely play an important function in Web services

authorization. Security Assertion Markup Language, or SAML, is an OASIS framework

for conveying user authentication and attribute information through XML assertions.

There are many specifications and standards for Web services security. We would like

to encourage you to investigate these on your own as an exercise.

WS-SecurityPolicy

Policies for Web services that describe the access permissions as well as actions which a

requester or provider are required to perform. For example, a policy may indicate that

requesters must have an active account with the service and that messages be encrypted

using a PKI scheme from a trusted Certificate Authority. A requester may also have a

policy indicating which encryption schemes it accepts.

25
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

WS-Trust

Before two parties are going to exchange sensitive information, they must establish a

secure communication. This can be done by the exchange of security credentials.

However, one problem remains, how one party can trust the credentials of the other.

The Web Service Trust Language (WS-Trust) was developed to deal with this problem.

It offers extensions to the WS-Security elements to exchange security tokens and

establishing trust relationships. (WS-Trust, 2005)

WS-SecureConversation

The Web Services protocol stack is designed to be a series of building blocks. WS-

Secure Conversation is one of those blocks. WS-Security provides message level

authentication, but is vulnerable to some types of attacks. WS-SecureConversation uses

SOAP extensions to define key exchange and key derivation from security context so

that a secure communication can be ensured. (WS-SecureConversation, 2005)

WS-Authorization

Authorization for Web services still remains an area of research at the time of this

publication. The difficulty of authorization is the inability to dynamically determine

authorization for a requester whom a Web service has just been introduced. Some

authorization frameworks being suggested include assertion based, role based, context

based and a hybrid approach.

Assertion based authorization uses assertions about the requester to decided on the

level of authorization. In a role based approach, requesters are given ‘user’ labels and

these labels are associated with roles, which in turn have permissions assigned to them.

Context based authorization examines the context in which a requester is acting. For

instance: proximity to the resource, on behalf of a partnership, or even the time of day.

Obviously a hybrid approach is some combination of two or more approaches.

26
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

WS-Privacy

Privacy is in the context of data and can be associated with the requester or the provider.

The requester may be concerned that the information given to a provider will be

propagated to other entities. Such information could be a credit card number, address, or

phone number. A provider may be concerned with the proliferation of information

which they have sold to a requester. In this case the provider does not want the requester

to resell this information without proper compensation.

Transaction Processing

The perceived success of composite applications in a Service-Oriented Architecture

depends on the reliability of participants that are often beyond corporate boundaries. In

addition to already frequent errors and glitches in application code, distributed

applications must cope with external factors such as network connectivity,

unavailability of participants and even mistakes in service configuration. Web services

transaction management enables participating services to have a greater degree of

confidence in that the actions among them will progress successfully, and that in the

worst case, such transactions can be cancelled or compensated as necessary.

WS-Transaction

To date, probably the most comprehensive effort to define transaction context

management resides in the WS-Coordination (WS-C) (Microsoft, BEA, IBM,`Web

Service Coodination’, 2005), WS-AtomicTransaction (WS-AT) (Microsoft, BEA,

IBM,`Web Service Atomic Transaction’, 2005) and WS-BusinessActivity (WS-BA)

(Microsoft, BEA, IBM,`Web Service Business Activity’, 2005) specifications. WS-C

defines a coordination context, which represents an instance of coordinated effort,

allowing participant services to share a common view. WS-AT targets existing

27
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

transactional systems with short interactions and full ACID properties. WS-BA, on the

other hand, is intended for applications involved in business processes of long duration,

whose relaxed properties increase concurrency and suit a wider range of applications.

Neither the Web services architecture nor any specifications prescribe explicit ways

to implement transactional capabilities, although it is clear that delivering such features

should minimally impact existing applications. Some propose approaching the problem

of transaction monitoring and support by means of intermediary (proxy) services

(Mikalsen, 2002), while others by providing a lightweight programming interface

requiring minimal application code changes (Vasquez, Miller, Verma, Sheth, 2005).

Whichever the case, protocol-specific messages should also be embedded in exchanged

messages and propagated though all participants.

WS-Composite Application Framework

Reliability and management are aspects highly dependent on particular Web service

implementations and therefore no specification mandates or comments on them.

However, just like the J2EE Enterprise JavaBeans (EBJ) technology has made available

Container-Managed Transactions (CMT) for some time, a way to procure increased

Web service reliability could be through their deployment in managed environments, in

which the hosting application server becomes responsible for support activities such as

event logging and system recovery. These additional guarantees could potentially

improve many aspects of Web services reliability, taking part of the burden away from

their creators with regards to security, auditing, reliable messaging, transactional

logging and fault-tolerance, to cite just a few. Some implementations leading this

direction are already available from enterprise software companies such as Arjuna

Transaction Service (Arjuna Transaction Service, 2005), IBM Transactional Attitudes

(IBM Transactional Attitudes, 2005), and from open source projects like Apache

28
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Kandula (Apache Kandula Project, 2005) and the academic community (Vasquez,

Miller, Verma, Sheth, 2005) (Trainotti, Pistore, Pistore, [Link]., 2005).

Messaging

WS-ReliableMessaging

Communication over a public network such as the Internet imposes physical limitations

to the reliability of exchanged messages. Even though failures are inevitable and

unpredictable, certain techniques increase message reliability and traceability even in

the worst cases.

At a minimum, senders are interested in determining whether the message has been

received by the partner, that it was received exactly once and in the correct order.

Additionally, it may be necessary to determine the validity of the received message: Has

the message been altered on its way to the receiver? Does it conform to standard

formats? Does it agree with the business rules expected by the receiver?

WS-Reliability and WS-ReliableMessaging have rules that dictate how and when

services must respond to other services concerning the receipt of a message and its

validity.

WS-Eventing

Web Services Eventing (WS-Eventing) is a specification that defines a list of operations

that should be in a Web service interface to allow for asynchronous messaging. WS-

Eventing is based on WS-Notification that was submitted to OASIS for standardization.

WS-Notification

Web Service Notification (WS-Notification) is a family of specifications that provide

several capabilities.

29
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

• Standard message exchanges for clients

• Standard message exchanges for a notification broker service provider

• Required operations for services that wish to participate in notifications

• An XML model that describes topics.

WS-Notification is a top layer for the following specifications : WS-BaseNotification,

WS-BrokeredNotification, and WS-Topics.

WS-BaseNotification defines the operations and message exchanges that must take

place between the two parties. WS-BrokeredNotification defines messages and

operations required of a Notification Broker Service and those that wish to use it. WS-

Topics define the “topics” that are used to organize the elements in a notification

message. It also defines XML to describe the metadata associated with different topics.

Developing Web Services

The starting point of using Web service technology is to create Web services. Although

it is similar to developing other software, there are some differences in that early focus

on interfaces and tool support is of even greater importance. One can start by creating a

WSDL specification, or alternatively, by creating, for example, a Java interface or

abstract class. Since tools such as Axis (Apache Axis Documentation , 2006) or Radiant

(Radiant , 2005) can convert one form to the other, it is a matter of preference where to

start. In this chapter we will give a guide to developing Web services starting by

designing the Java classes.

We will do this by following fundamental software engineering techniques to create

the Web services. Start by creating a UML Class Diagram to define the requirements of

the system. To illustrate the ideas in this section, we will use an example from the

30
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Semantic Web Services Challenge 2006 (Semantic Web Services Challenge, 2006). The

Challenge scenario is to create a process to create a purchase order. The first step in this

process is to confirm that a given business is a customer of the fictitious “Moon

Company”. Our example implements this service. Below are the eight steps to create

this service:

1. Create a UML Class Diagram. Following software engineering practices, the

initial step is to create a UML Class Diagram to define the classes that will be

needed for the service. UML provides a succinct representation of modeling

classes. The following is an example of a UML class diagram for a service that

will take as input the name of a business and search a database to return the

profile for this business if they are a partner of the Moon Company.

Figure 8 UML Class Diagram

2. Generate Java Code. Using a UML tool such as Poseidon, the UML Class

Diagram can easily converted into a Java class skeleton. It is important to note

that while you are developing objects to be used for Web services that you must

31
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

follow the Java bean programming conventions, for example, implementing

“getters” and “setters” for every member variable. Fortunately, this is exactly the

code that will be generated thanks to the UML tool based on the diagram that we

have created in step one. For simplicity, we have generated our Web Service as

an abstract class.

3. Adding in Web Services Annotations. Java 6 includes annotations so that the

compiler will know that the program code is a Web Service. A partial list of

available annotations is as follows:

• [Link]

• [Link]

• [Link]

• [Link]

• [Link]

• [Link]

The figure 9 illustrates an example of a Java service which has been annotated.

Note that in the example the @WebService and @WebMethod are the

annotations. The complier will recognize these tags and create the WSDL

document.

32
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Figure 9 – Annotated Java Example

Refer to the following link to see more information on annotations

([Link]

4. Generate WSDL. The annotations from the previous step indicate to the

Annotation Processing Tool or the Java compiler that a WSDL is to be generated

at compile-time. This description of the service is used in two ways. One, the

description acts as an advertisement when it is published on the Web. The

information gleaned from the WSDL file is published in UDDI registries so that

queries can be executed to discover the service that is needed. Second, it

provides all the information needed to invoke this service remotely.

5. Implement Methods. At this point in development, we want to create an

implementation class that extends our abstract class. The difference that the

developer must deal with is writing the code to the proper conventions. Any

class that is created must have getters and setters for all member variables. These

33
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

are used during invocation by the SOAP engine to serialize and deserialize the

data that is in the SOAP messages into Java objects and back to SOAP.

6. Deploy Service. Deploying a service is accomplished using a Web application

server and a SOAP engine, like Tomcat and Axis2 respectively. If using Axis2,

deploying a service is as simple as dropping the .aar files, which are .jar files

with a different extension, into the \WEB-INF\services directory. Directions on

deployment in Axis2 can be found on the Web at [Link] .

7. Test Service. A simple Java program can be sufficient to test a service. In others

it may require a more complex client. Either way the fundamentals for writing a

client are the End Point Reference, which is a URL to the service, a call setting

the target, and setting the transport information. All of this information is put

into a call object that exists in the [Link] package. The setup of this

object is below:

Call call = new Call();

[Link](smr);
[Link](“[Link]
[Link](“search”);
[Link](Constants.NS_URI_SOAP_ENC);
Vector params = new Vector();
SearchCustomerType sct = new SearchCustomerType();
[Link](name);
[Link](new Parameter(“request”, [Link], sct,
null));
[Link](params);
Figure 10 Partial Listing of Web Service Client

This code creates a call to a service named “CMRService” with an operation

name “search”. This operation takes a SearchCustomerType as input, thus you

34
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

see an instance of this class is created and added as a parameter to the call

object.

Response resp = [Link](url, "");

This calls the invoke method on the call object to execute the operation in the

service. The results of the service are put into the Response object and can be

accessed from there.

8. Publish Service. Publishing a service requires the use of UDDI registries.

Setting up a registry varies based on which registry is chosen. For our example,

we used the jUDDI registry on a Tomcat server. The action of publishing a

service is similar to advertising a business. After deployment and testing, the

service is open to the world and ready to accept request, but until it is published,

it is unlikely that anyone will know about your service. Tools that simplify this

process are Radiant and Lumina (Li, 2005), both from the METEOR-S tool

suite.

CONCLUSIONS

The Service Oriented Architecture (SOA) is currently a “hot” topic. It is an evolution of

the distributed systems technology of the 1990s, such as DCOM, CORBA, and Java

RMI. This type of architecture requires the existence of main components and concepts

such as services, service descriptions, service security parameters and constraints,

advertising and discovery, and service contracts in order to implement distributed

systems. In contrast to the Event-Driven Architecture, in which the services are

independent, the SOA-based approach requires services to be loosely coupled.

35
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

SOA are often associated with Web services and sometimes, SOA are even confused

with Web services, but, SOA does not specifically mean Web services. Instead, Web

services can be seen as a specialized SOA implementation that embodies the core

aspects of a service-oriented approach to architecture. Web service technology has come

a long way toward achieving the goal of the SOA. With Web services, developers do

not need to know how a remote program works, only the input that it requires, the

output it provides and how to invoke it for execution. Web services provide standards

and specifications that create an environment where services can be designed, executed,

and composed into processes to achieve very complicated tasks.

For some years now, Web services define a set of standards (such as WSDL, SOAP,

and UDDI) to allow the interoperation and interoperability of services on the Internet.

Recently, security and transactional stability have become priority areas of research to

make Web services more accepted in the world of industry. The work done has lead to

the development of a set of new specifications (such as WS-Security, WS-Policy, WS-

Trust, WS-Privacy, WS-Transaction, etc.) that describe how Web services can establish

secure communications, define policies services’ interactions, and define rules of trust

between services.

36
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

REFERENCES

Arjuna Transaction Service from

[Link]

Apache Axis Documentation from

[Link]

Apache Kandula Project from

[Link]

Birrell, Andrew D. and Bruce Jay Nelson, Implementing Remote Procedure Calls
ACM Trans. on Computer Systems, pp 39-54, 1984.

Booth, D. et al., Web Services Architecture, W3C Working Group Note”, 11 February
2004. from
[Link]

Brown, Nat and Charlie Kindel. Distributed Component Object Model Protocol,
DCOM/1.0. Microsoft Corporation, Redmond, WA, 1996.

Cardoso, J., Francisco Curbera, and Amit Sheth, Tutorial: Service Oriented
Archiectures and Semantic Web Processes, from
The Thirteenth International World Wide Web Conference (WWW2004), 17-22 May
2004, New York, USA.

Channabasavaiah, K. Holley, K. & Tuggle, E., Migrating to a service-oriented

architecture, Part 1, 2003 from
[Link]

Christensen, E., F. Curbera, et al. W3C Web Services Description Language (WSDL),
2001 from
[Link]

Curbera, F., W. Nagy, et al. (2001). Web Services: Why and How. Workshop on Object-
Oriented Web Services - OOPSLA 2001, Tampa, Florida, USA.

Dwoning, T.: Java RMI. IDG Books Worldwide. (1998).

Graham, S., S. Simenov, et al. (2002). Building Web Services with Java: Making Sense
of XML, SOAP, WSDL, and UDDI, SAMS.

IBM Transactional Attitudes from

[Link]

Li, Ke. (2005) Lumina: Using WSDL-S for Web Service Discovery Masters Thesis,
University of Georgia.

37
 Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

Microsoft, BEA & IBM, (2005). Web Services Atomic Transaction

Microsoft, BEA & IBM, (2005). Web Services Business Activity

Microsoft, BEA & IBM, (2005). Web Services Coordination.

Mikalsen, T., Tai, S., Rouvellou, I.: Transactional Attitudes, (2002). Reliable
Composition of Autonomous Web Services. International Conference on Dependable
Systems and Networks.

Object Management Group. CORBA: The Common Object Request: Architecture and
Specification, July 1995, Release 2.0.

Orfali, R., D. Herkey. Client/Server Programming with Java and CORBA. 2nd edition,
John Wiley & Sons, 1998.

Radiant: LSDIS lab University of Georgia (2005)

[Link]

Semantic Web Services Challenge (2006) from

[Link]

SOAP (2003). Simple Object Access Protocol 1.2, from [Link]

Trainotti, M., Pistore, M., Calabrese, G., Zacco, G., Lucchese, G., Barbon F., Bertoli,
P., Traverso P. ASTRO, (2005). Supporting Composition and Execution of Web
Services. International Conference on Service Oriented Computing.

UDDI (2002). Universal Description, Discovery, and Integration.

Vasquez, I., Miller, J., Verma, A., Sheth, A., (2005). OpenWS-Transaction: Enabling
Reliable Web Service Transactions. International Conference on Service Oriented
Computing.

Verma, K., Rama Akkiraju, Richard Goodwin, (2005) Semantic Matching of Web
Service Policies, Second International Workshop on Semantic and Dynamic Web
Processes (SDWP 2005), Part of the 3rd International Conference on Web Services
(ICWS'05)

Waldo, J.. The Jini architecture for network-centric computing. Communications of the
ACM, 42(10):76–82, Oct. 1999.

WS-PolicyAttachment Specification from

[Link]

WS-Trust Specification from

[Link]

WS-SecureConversation Specification from

[Link]

38
  Copyrights 2006,Authors, – DO NOT REDISTRIBUTE

XML (2005). Extensible Markup Language (XML) 1.0 (Third Edition), W3C
Recommendation 04 February 2004, from
[Link]

39

View publication stats