3012673 Understanding and Using the Web Services Architecture

8/14/2019 3012673 Understanding and Using the Web Services Architecture

http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 1/8

1

Understanding and Using The Web Services

ArchitectureIsık Barıs Fidaner,

Bogazici University

Abstract— This is a study about Web Services, what thistechnology is, how it is used, what problems and possibilitiesdoes it bring, and how its problems are solved.

In the first part, basic concepts and standards about WebServices are described. These are XML file format, message

format SOAP, the HTTP, service description standard WSDL,the registry of services UDDI, workflow standard BPEL, and theREST principles.

Second part is about understanding what Web Services are,and main design points for Web Service programming. It startsby a description and a simple core model of Web Services. Theroles and layers of the conceptual Web Services programmingstack are explained. Some common misconceptions about WebServices are considered.

Third and last part is about the problems of using WebServices. Possible business requirements about Web Servicesare listed, and standards solving them are considered. Thensecurity problems and different solutions such as SSL, TLS,SAML are explained. Then comes the problems concerningapplication integration. There are both non-technical integration

problems about business strategy, and technical problems for theverification of asynchronous interactions in Web Services. Thereare recent papers proposing solutions to both types of problems.

Index Terms— web services, http, xml, soap, wsdl, uddi, bpel,rest.

I. INTRODUCTION

THE INTERNET has become something it never has been.

We are connected to every other in a way that has

never been in human history. This is a web of information,

interaction, but at the same time it is a web of possibilities.

Possibilities of friends, collaboration, learning and also a

possibility of service providing and consuming. Business-to-business (B2B) relations through computer networks have a

comparably long history, but a history with a separation of

protocols, languages, standards. But The Web is one. With

its user and producer-friendliness, HTML became universal,

as well as XML that is similar. And a technology of a more

connected world is being developed: Web Services.

Web Services are simple in theory. Simply put, they are

service requesting and providing, by sending and receiving

messages of some format. The messages are commonly XML

formatted. Most desired features of Web Services are inter-

operability between different systems, perfect security and

quality (as it is for business use), easy interpretation and

implementation.

II. BASIC CONCEPTS

Before focusing on details of Web Services, let us look at

some basic concepts concerning this technology.

A. A human friendly format: XML

In Web Services, many message formats are based on

Extensible Markup Language (XML). XML is a very general-

purpose markup language that is used in variety of applica-

tions. In every XML file, there are entities that are structuredas a tree. It is a method of representing information that is both

human readable and machine readable. Positive attributes of

XML are:

• Being both human and machine-readable

• Unicode support, thus supporting nearly every human

language

• The tree structure is very appropriate for computer sci-

ence abstractions

• Names and values are openly written, making it a self-

documenting format

• The format allows efficient parsing

And its weaknesses:• Its redundant, unnecessarily long format is a problem for

efficient storage and transmission

• With the same reason, every XML parser must check a

file’s format thoroughly to prevent errors

• In XML there is no data type such as int or float,

everything must be expressed through strings

• The hierarchical model of XML is limited, compared to

relational models such as databases. Representing non-

hierarchical data in XML is difficult.

B. Message format: SOAP

Web Services generally use SOAP as a message envelopeformat. Simple Object Access Protocol (SOAP) is a messaging

protocol that is based on Extensible Markup Language (XML)

used usually with Hypertext Transfer Protocol (HTTP). The

original acronym was dropped with version 1.2 as it was

misleading, it became only SOAP. [1]

SOAP forms the second layer of Web services protocol

stack, more abstract layers build on it. These are, “service

description” protocols such as WSDL, and “service discovery

protocols” such as UDDI.

Most widely used messaging pattern of SOAP is Remote

Procedure Call (RPC). In fact, SOAP evolved from XML-RPC

that was only capable of RPC messaging.

SOAP was designed by Dave Winer, Don Box, Bob Atkin-son, and Mohsen Al-Ghosein in 1998. Its specifications are

currently maintained by XML Protocol Working Group of

W3C. It was intended to be a protocol to allow software

applications to interact on the internet or any network.



2

Let us look at an example SOAP request and response:

<soap:Envelope xmlns:soap="http://schemas

.xmlsoap.org/soap/envelope/">

<soap:Body>

<getProductDetails xmlns="http://ware

house.example.com/ws">

<productID>827635</productID>

</getProductDetails>

</soap:Body>

</soap:Envelope>

Above is a SOAP formatted request example. It uses the

operation “getProductDetails” to get information about the

product with ID 827635. This message is independent of the

operating system or any inner structure of the server.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<getProductDetailsResponse xmlns="http

://warehouse.example.com/ws">

<getProductDetailsResult>

<productName>Toptimate 3-Piece Set

</productName>

<productID>827635</productID>

<description>3-Piece luggage set.

Black Polyester.</description>

<price>96.50</price>

<inStock>true</inStock></getProductDetailsResult>

</getProductDetailsResponse>

</soap:Body>

</soap:Envelope>

This is the response of the server. The operation is realized,

and product details are returned to the client. SOAP messages

are text based and very easy to read. This is also a weakness as

a limitation to transfer speed, because the messages are very

long and this may affect network performance. Some other

technologies such as CORBA use binary format and do not

bear this weakness. This is a general problem of XML-based

protocols.

C. Transferring messages: HTTP

SOAP messages are transferred using Hypertext Transfer

Protocol (HTTP). HTTP is a method used to transfer or convey

information on the World Wide Web. Its original purpose was

to provide a way to publish and retrieve HTML pages. It is

also used to transfer XML files and XML-based file formats

such as SOAP.

HTTP is used between clients and servers as a re-

quest/response protocol. The connecting agent, a client, a

web browser, or any other end-user application, is described

as the “user agent”. The destination server, is called theorigin server. Resources such as HTML files and images are

stored or created in the server. In between the user agent and

origin server may be several intermediaries, such as proxies,

gateways, and tunnels.

D. Service description: WSDL

Web Services Description Language (WSDL) is an XML-

based language for communicating descriptions of Web Ser-

vices. WSDL defines services as a collection of “ports” thatreceive and send “messages”. But these are taken as abstract

concepts and separated from their concrete use or instance.

A “port” is a network address that can be reused through

binding. A “port type” is an abstract collection of supported

operations. A “service” is a collection of ports. “Message”

is defined as abstract definitions of data that is transferred.

WSDL describes the public interface for a particular Web

Service by using these concepts.

WSDL is generally used with SOAP. If a client program

connects to a Web Service, it can get the WSDL to understand

what operations are available on the server. Special data types

are written in WSDL in XML Schema format. Then SOAPmessages are used for calling the functions on the server.

Although a WSDL specification defines the public interface

of a Web Service, it does not provide any information about

its behavior. Behavioral descriptions of Web Services are

defined using higher level standards such as Business Process

Execution Language for Web Services (BPEL). The Web

Service Choreography Description Language (WS-CDL) is

used to specify the interactions among multiple Web Services.

E. A universal registry: UDDI

There is a standard registry for Web Services. It is Universal

Description, Discovery, and Integration (UDDI). UDDI is anXML-based list of businesses. It was written in August 2000,

and it is sponsored by OASIS. It is like a platform or market

that different businesses find each other’s services and interact

over the Internet. Every business registers on the following:

• White Pages that include addresses, contact information

• Yellow Pages that include sectoral categorizations based

on standard classifications

• Green Pages that include technical information about the

services proposed

UDDI is queried by SOAP messages. Clients send SOAP

messages to the UDDI to get service descriptions in WSDL.

And then, using the protocol bindings and message formats

described in WSDL documents, the client can use any service

that is offered in UDDI by several businesses.

F. Programming in the large with BPEL

Being grown out of WSFL and XLANG, Business Process

Execution Language (BPEL) is a XML-based business pro-

cess language that aims to enable programming in the large.

“Programming in the large” generally refers to the high-level

state transitions and interactions between sides of a business

process. This concept is given as an “abstract process”. Every

abstract process provides information about the system states

to wait for messages, send messages, or to compensate for

failed transactions. In contrast, “programming in the small”is about short-lived programmatic behavior, often ran as a

single transaction that involves access to resources such as files

and databases. An important motivation behind BPEL is that

programming in large and small require different approaches.



3

G. The logic of the design of Web: REST

REST is a set of architectural design principles formulated

by Roy Fielding. It is best summed up in its designer’s

words (from his book, Architectural Styles and the Design

of Network-based Software Architectures).

“Representational State Transfer (REST) is intended to

evoke an image of how a well-designed Web application

behaves: a network of web pages (a virtual state-machine),

where the user progresses through an application by selecting

links (state transitions), resulting in the next page (representing

the next state of the application) being transferred to the user

and rendered for their use.”

The REST principles are:

1) Application state and functionality are divided into re-

sources

2) Every resource is uniquely addressable using a universalsyntax for use in hypermedia links

3) All resources share a uniform interface for the transfer

of state between client and resource, consisting of

• A constrained set of well-defined operations

• A constrained set of content types, optionally sup-

porting code-on-demand

4) A protocol that is:

• Client/Server

• Stateless

• Cacheable

• Layered

There is a fundamental difference between RPC and REST-

ful (a system that incorporates REST principles) systems. In

REST, there are mainly resources, such as web pages. Main

operations are GET, PUT, POST, and DELETE. In contrast,

object-oriented or RPC systems have functions and procedures

for calling. For example, in a RESTful system, we acquire

information about a certain user by “getting” the resource with

address “users/001”. Whereas in an RPC system, we have to

call a function like “getUser(id)”.

III . UNDERSTANDING WEB SERVICES

A. What Are Web ServicesWeb Service is defined by W3C as a software system

for making different computers interact. The computers may

have different operating systems, different inner structure, but

the logic of Web Service should make it possible for them

to interact and make operations. This is the most general

definition. But in practice, Web Services usually make use

of following:

• SOAP as messaging envelope format

• WDSL as service description format

• UDDI for defining metadata that is used for service

discovery

• WS-Security that defines standards for security issues• WS-ReliableMessaging as the protocol for reliable mes-

saging

These are the standards proposed by Organization for the

Advancement of Structured Information Standards (OASIS)

and W3C. Web Services Interoperability Organization (WS-

I) also creates some applications and tools to enhance Web

Services interoperability. Web Service development based on

these standards is supported by different implementation plat-forms such as .Net and J2EE (see [2] for Sun One Web

Services Framework).

In short, Web Services are a combination of a discovery

system (UDDI), a description system (WSDL) and the Web

Services themselves.

The discovery system (UDDI) is used by a hosting busi-

ness to enter information describing themselves, publishing

taxonomy along with the descriptions (WSDL) of services they

provide. This allows another business to find their service by

searching with some criteria. It also supports category-based

search options.

After an appropriate service is found, a description (WSDL)

is demanded. This description contains:

• Operations included in the service

• Input and output messages for each operation

The use of WSDL powers a service-oriented architecture

enabling enterprise application integration (EAI), business-to-

business application integration (B2B), and grid computing.[3]

The main benefits of the Web Services are:

• Decoupling of service interfaces from implementations

and platform considerations

• The enablement of dynamic service binding

• Increase in cross-language, cross platform interoperability

B. A Minimalist Model of A Web Service

In the core of Web Services, there are three basic elements:

• The Service. This is a software that is able to process an

XML document it receives through some combination of

transport and application protocols. The inner structure

of the service is irrelevant. It is only necessary that it

responds to a special format of XML files.

• For the service to interpret the information in XML

documents, there must be a shared description of an XML

request-response format. This is described in an XML

Schema. WSDL is commonly used but not necessary.

• The address of the service using a certain protocol. Thisis necessary to access the service. It can be an address

for TCP or HTTP protocol but not necessarily is.

The fourth element is an envelope for the XML document. It

is optional but very helpful, for example for putting additional

information such as security and routing. Soap envelopes are

commonly used standard. Soap has two parts: A header that

keeps all system information, and a body that contains the

XML document to be processed by the Web Service.[4] If we

look at this simplistic model of the Web Services technology,

it seen that this technology is very simple in its core.

C. The RolesIn Web Services, there are three roles and their operations.

A service registry keeps track of recorded services.

A service provider can create a Web Service and its service

definition; or publish the service with a service registry.



4

Fig. 1. The roles and operations in Web Services

A service requester can find the service from registry to get

WSDL service description and a service URL; or bind to the

service and invoke it.

D. Web Services programming stack

To understand the operations of Web Services, let us have a

look at The Web Services programming stack. This stack is a

collection of standardized protocols and application program-

ming interfaces (APIs) that lets individuals and applications

locate and utilize Web Services. Layers in the stack correspond

to operations made by one of three roles above. First three

layers are crucial to the system. The remaining layers are

optional and will be used as business needs require them.[5]

Below is a list of Web Services programming stack layers:

1) Network layer is at the bottom of the stack. It is the

place of the protocol to transfer messages. Most often

used such protocol is HTTP.2) Messaging layer comes after the network layer. It is

the communication platform between Web Services and

their clients. All operations, publishing, finding, bind-

ing, and invoking is accomplished by sending mes-

sages. Most widespread message protocol is XML-based

SOAP.

3) Service description layer. This is where service descrip-

tion rules are applied. WSDL is used for this purpose.

Service providers describe their available Web Services

to clients.

4) Service publication layer. This layer is about a service

provider making its WSDL document available. UDDI

can be used, but it is not necessary. Just sending an e-mail attaching your WSDL document is considered as

publishing.

5) Service discovery layer. This layer is where a service

requester gets someone’s WSDL document. UDDI is a

possible interface, but receiving an e-mail with a WSDL

document is also considered as discovery.

6) Service flow layer. This is the highest layer that facil-

itates the composition of Web Services into workflowsand the representation of this aggregation of Web Ser-

vices as a higher-level Web Service. Web Services Flow

Language (WSFL) was offered by IBM as a standard

to be used in service flow layer. Similarly XLANG

was offered by Microsoft. Then these were combined

to form Business Process Execution Language (BPEL)

that superseded WSFL and XLANG.

There are also higher level layers that are yet to be com-

monly used and standardized.[6]

• Policy description layer. Its purpose is to define service-

specific information beyond mechanics, such as own-

ing business, taxonomy, security requirements, timeouts,costs, and quality of service (QoS) parameters.

• Presentation layer. How a user interface is generated for

this service.

• Composition layer. Related services are expressed here.

Groupings, containment, dependencies, and parent-child

relationships between Web Services are determined.

• Orchestration layer. The ordering of operations, choreog-

raphy, workflows, and business processes.

• Service-level agreement layer. The specific performance,

usage, costs, metrics, and thresholds to which a service

is expected to adhere.

• Business-level agreement layer. A contractual agreement

between the two business partners who will be transacting

business using Web Services.

E. Common Misconceptions

As Web Services gained popularity, there appeared several

misunderstandings about the concept. We are going to focus

on main misconceptions about Web Services below.[4]

1) Web Services are message oriented: There are two main

middleware approaches in terms of interaction models. One

is message-oriented middleware (MOM), which includes Web

Services. The other is object-oriented middleware that is very

Fig. 2. Web Services programming stack



5

different in nature. Applications that are based on Corba or

Enterprise Java Beans belong to this category. The interaction

models determine most things about a system.[7]

Recently, there was a debate in W3C Web Services Archi-tecture working group forum about applying representational

state transfer (REST) principles to Web Services architectures.

Representational State Transfer (REST) is a term to describe

the Web’s architectural style. In contrast to objects and func-

tions, REST is based on resources and only four operations on

them: Put, Get, Post and Delete. As it is simple and platform-

neutral, it well suits to the field of Web Services and its

interoperability needs.[8]

2) Web Services are not distributed objects: Web Services

are very similar to distributed objects in the sense that they

both have a certain description language, they incorporate

well-defined network interactions, and they bear similar mech-

anisms for registering and discovering available components.

However, Web Services are not distributed objects.

In a distributed object system, every object, with the excep-

tion of singleton objects, go through the following life cycle:

• On demand, a factory creates the object instance

• The consumer who wanted the creation performs various

operations on the object instance

• Sometime later, either the consumer releases the instance

or the runtime system garbage collects it

Furthermore, another attribute of objects is being identified

through a reference. It also carries references to other objects.

Several reference handling techniques are developed for this

kind of (object-oriented) architecture. Web Services do notrequire any of these concepts.

In Web Services, there are no life cycles. Also no notion

of objects, object references or factories. There are no method

interfaces, no serialization of data-structures, or garbage col-

lection of references. Distributed object systems enable stateful

distributed computing, though Web Services cannot offer any

of the stateful distributed computing facilities. Web Services

are solely about sending and receiving XML documents and

document encapsulation.

The difference is obvious if we look at how information

flows between client and server or producer and consumer in

these systems. In distributed object systems, the informationtravels in the form of interfaces an object supports. Whereas,

in Web Services the design of the XML documents determine

everything. Of course there are also contexts of interactions

in Web Services. But these contexts are also identified as an

ongoing conversation in the form of document transfer rather

than any states at the services.

Distributed objects are mature and robust systems. But their

application is usually limited to the corporate intranets, which

are often characterized by platform homogeneity and pre-

dictable latencies. The strength of Web Services is in Internet-

style distributed computing, where interoperability and support

for platform and network heterogeneity are essential. In time,

Web Services are probably going to gain similar properties as

distributed object systems such as having guaranteed, in-order,

exactly-once message delivery.

3) Web Services are not RPC for the Internet: Remote

Procedure Calling is done through a network abstraction for

remotely executing procedure calls in a certain programming

language.

This low level operation requires the caller to identify the

remote procedure, to decide which state must be provided tothe procedure at invocation time, and what form to use to

present the results to the caller at completion time. The RPC

systems also include extensive mechanisms for handling errors

at both the runtime and programming levels.

In Web Services, there is no concept of procedure calling

and caller. There is the notion of actor or role that consumes

the service. But there are no predefined semantics with the

XML document’s content. We could implement a Web Service

that runs RPC, but it would be a very specific Web Service and

it would force a certain fixed rules for encoding the arguments

in an XML document and rules for returning the results to the

caller.

Internet-wide RPC was a failure. This has several reasons.

Synchronous interactions over wide-area networks are not

scalable, for example, and large-scale versioning of procedure

interfaces is extremely difficult. Web Services neither have the

functionalities of RPC nor bear these difficulties.

4) Web Services do not need HTTP: Web Services do not

depend on the transport protocol that is used. SOAP messages

may well be transported through plain TCP or UDP, or even

SMTP by e-mail. There are also alternatives such as MQ-

Series or Java messaging service (JMS) to name a few. These

technologies can also be combined. For example a SOAP

package that comes to the system through HTTP may be

automatically forwarded to a certain server through TCP orJMS.

Web Services are not specifically designed for HTTP,

though HTTP is most commonly used. It is easier for the de-

velopers to leave the request parsing and message dispatching

duties to the Web servers. These features were present in the

infrastructure offered by the major Web servers: Apache, IBM

WebSphere, and Microsoft IIS. Therefore, since first Web Ser-

vices, HTTP was used. These servers still provide best service

exercise tools, supporting WSDL and other standards. They

make very useful environments for Web Service development.

Nevertheless, they are not necessary.

5) Web Services does not need Web Servers: There wasa discussion whether to drop the “Web” from Web Services.

Terms such as service-oriented architectures, service-oriented

integration, or services bus do not mention “Web”, because

they are independent of Web Servers. Early Web Services

have exploited Web servers’ application-server functionality,

but now there are several toolkits that let you develop and

integrate Web Services without using Web server infrastruc-

tures. Examples are: Simon Fell’s Pocket-Soap, Systinet’s

Web Applications and Services Platform (WASP), IBM’s

Emerging Technologies Toolkit, Microsoft’s Web Services

Enhancements (WSE).

6) Web Services are not reliable because they use TCP:

Web Services are believed to be reliable, and capable of in-order message delivery, because TCP guarantees these fea-

tures. In fact, TCP itself does not completely guarantee these

features. In a few situations, the protocol cannot completely

deliver a message to a remote party, and if the local participant



6

disconnects, it won’t receive an error notification.

What is more, in Web Services, there are usually inter-

mediaries that makes things even more problematic. In the

condition of network, node, or component failures, it is verypossible that even the document reaches the first station, it

might not be delivered to the server and not processed. These

problems are to be solved by reliable messaging techniques,

WS-ReliableMessaging standard, to be precise.

7) Debugging Web Services is possible: It is believed that

it is impossible to debug Web Services. Traditional debugging

tools depend on a complete knowledge of a system, but as the

requester and provider of a Web Service are usually different

organizations, a different debugging paradigm is necessary.

Most difficult problems are cross-vendor interoperability and

WSDL versioning.

There are new diagnostic tools such as SOAPscope forissues of development and deployment of Web Services. As

development toolkits for Web Services are more commonly

used, interoperability problems between parties using dif-

ferent toolkits are appearing. SOAPscope has features for

trying “what if” scenarios against a server to isolate problem

requests. It has visualizing capabilities for viewing SOAP

messages more abstractly. It can also make WSDL analysis

and WSDL version checking for the detection of errors and for

helping to resolve potential interoperability problems before

service deployment.

IV. USING WEB SERVICES

In Web Services, enterprise-class infrastructure must be sup-

plied, including security, management, and quality-of-service

management to meet the stringent demands of today’s e-

businesses.[5]

The requirements of an e-commerce business would be:

• Exchanging information programmatically with users.

• Sharing common formats with users for data and mes-

sages.

• Users and business must understand the same thing from

the contents of the messages.

• An information mechanism for the merchants to bring

potential buyers• A discovery mechanism for potential buyers themselves

• A way of integrating in workflows its own service appli-

cations with those of its merchants

• Ensuring security in every transaction

Web Services use generally accepted standardized APIs to

communicate at each level of the programming stack

8) Networking standard: Internet and HTTP has greatly

extended the ability of companies to easily and automatically

communicate with its users, whether these users are computers

or human beings

Within the corporation itself, multiple networking protocols

may be used, but in this case adapters will convert betweenthese protocols and HTTP for messages that pass through the

enterprise boundary to and from users.

9) Messaging standard: Two main types of messages exist:

• Message of a document that is to be processed remotely

• Commands and parameters that are used to directly

invoke a remote procedure (RPC)

For a long time, there was no common protocol for handling

both types of messages. Multiple protocols were being used tohandle messages of each type. Now, SOAP is the standardized

mechanism for communicating document-centric messages

and remote procedure calls using XML.

10) Service description standard: Service requesters must

be able to know what services are available from the provider,

what message format is used to invoke them, and what

costs are involved. WSDL is the standard way of giving this

information.

11) Service publication and service discovery standards:

UDDI is the standard for publication and discovery. There are

public and private UDDI registries.

Public UDDI registries are located at http://www.uddi.organd are maintained and synchronized by companies such as

IBM and Microsoft.

There are also private registries maintained by individual

companies or industry consortiums that have controlled per-

mission for access. For example, an enterprise may create its

private registry to accept only merchants and users at some

quality standards to facilitate trust among its clients.

12) Service flow standards: This area is for defining com-

plex Web Services by combining simpler ones. For example,

a company may want to specify that when a client enters an

order over a certain amount of money, the system must get the

approval of a manager before proceeding. WS-BPEL is used

for this purposes.

A. Security Problems

For Web Services to be used securely, following issues must

be solved

• Authentication: Establishing identity for requesters and

providers.

• Authorization: Establishing permissions for users.

• Confidentiality: Making sure that only the intended re-

cipient reads the message. This is accomplished with

encryption.

• Integrity: Ensuring the message hasn’t been changed.

Generally accomplished with digital signatures.

1) SSL and TLS: For transporting security, Secure Sockets

Layer (SSL) is commonly used. SSL is a public-private key

security system that works with digital certificates and operates

between HTTP and TCP network layers. Transport Layer

Security (TLS) protocol was then developed and succeeded

SSL. The web browsers generally support these systems, but

they do not work well with complex, high-volume transactions

like Web Services. This is because these systems do decryption

followed by an encryption at every Web server.

There are also security problems introduced by SOAP.

World Wide Web Consortium’s original SOAP version pro-

vided no security.2) SAML: OASIS created Security Assertion Markup Lan-

guage (SAML) for solving the security problems in XML

transmission by defining security related schemas for structur-

ing documents. These schemas include information related to



7

user identity and access or authorization rights. The standard

transmission of these security information allows companies

using different inner security systems to communicate.[9]

SAML also tell which authentication method is to be used.For example, it may be a password, Kerberos authentication

ticket, hardware token, or X.509 digital certificate. Thus,

SAML can either work with a centralized certificate authority,

or directly between individual users. It can also be used to

share authentication of a requester between providers, so that

a single authentication (e.g. logging in) is adequate.

3) WS-Security: Web Services Security protocol (WS-

Security) was developed by IBM, Microsoft, and VeriSign.

It allows Web Services to run on different security models

by extending SOAP message format. Security data is attached

to the headers of SOAP messages. This information contains

metadata found in specifications of XML Encryption and XMLSignature. It also allows using digital signatures in SOAP

messages.

• XML Encryption provides ways to encrypt whole or

parts of an XML message using common encryption

algorithms.

• XML Signature defines processing rules and syntax for

representing digital signatures.

There are also other higher level standards that are on top

of WS-Security.

• WS-SecurityPolicy is a general framework for defining

security, privacy, and other policies on machines used for

Web Services• WS-Privacy lets providers and users state privacy prefer-

ences and practices

• WS-Trust is a framework of models for establishing both

direct and brokered trust relationships

• WS-SecureConversation establishes sessions in which

SOAP acts like a connection-based approach

• WS-Authorization define how to manage authorization

policies

• WS-Federation standardizes the way companies share

user and machine identities among their disparate authen-

tication and authorization systems.

B. Application Integration

1) Loose Coupling: For a robust and platform-neutral ap-

plication integration, loose coupling is very important. In the

particular area of Web Services, it is crucial to remember that

SOAP XML messages are documents, not remote procedure

calls. Loose coupling ensures that other applications relying

on your service does are not affected by your changes in im-

plementation. In the ideal model, every incoming and outgoing

message taken from the queue should be well-defined.

XML format is very appropriate for loosely coupled access.

For example, if you change the table structure of a database,

clients must change their queries respectively. Even in object-oriented techniques, changes to the implementations of objects

over time tend to break the clients. The Web is an exception to

this, eventhough publishers change web sites fundamentally,

users can always view HTML through their browsers. Because

browsers make no assumptions of a site’s implementation, it

only knows the “wire format” (HTML).

Like Web itself, Web Services also have this goal to be

totally independent to implementation. It only depends on a“public contract” about expected XML to be generated or

received. Object oriented approaches and remote procedure

calling do not work for services-based application integration,

because they are not loosely coupled. For establishing loose

coupling, a message-oriented, document-based approach and

XML model is necessary for Web Services. [10]

2) Application Service Strategies: There are several re-

search papers on the business implications of Web Services

technology. In a very recent paper by Cheng et al., [11], three

application service strategies were compared for providing

Web services of complementary functionalities. These are:

• Independent Service Vendors (ISVs): In this applicationservice strategy, there are two independent vendors and

two different services, but these services combine to make

a third service. Some of the customers demand only one

of two services, some need the third service and demand

the first two for this reason. In this scenario, combining

services is not by by vendors but the consumers. Price of

third service is not regulated.

• Joint venture (JV): In JV, these two vendors join into

a single company to sell the third service at the price

they determine. And the customers of the combined

product cannot divide the product/service to get the two

component services.• Strategic Alliance (SA): SA is the combination of ISV

and JV strategies. In this case, third service is both created

by consumers and sold by the company. Thus, the price

of third service cannot exceed the consumers’ cost of

forming it from first two services.

These events occur in product bundling in other sectors. But

software bundling have distinct features such as low integra-

tion cost and possibility of creating an integrated Web service

with new functionalities. The authors analysed three strategies

and obtained interesting conclusions. They found that optimal

application service strategy depends on several factors. These

factors include the integration cost, the valuations, and market

potentials of individual and integrated Web Services. Their

conclusions tell that SA is in general more profitable to ISV,

showing that interoperability between Web Service vendors is

benefitable. In most cases, SA is the best option. But in some

cases where the integrated Web Service is highly valuated and

the integration cost is small, JV becomes the best application

service strategy.

3) Web Service Interaction and Collaboration: In a 2005

study by Y. Baghdadi, [12], a business interactions per-

spective is conceptualized in terms of the business pro-

cesses among business functions and objects, and customer-to-

business (C2B) and business-to-business (B2B) requirements

for Web Services.He specifies and categorizes the business interactions into

enterprise, customers, suppliers, and partners’ interactions,

in terms of activities. Then he makes a crucial distinction

between “core business activities” and “interaction activities”.



Documents

3012673 Understanding and Using the Web Services Architecture