1

Understanding and Using The Web ServicesArchitecture

Isı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, messageformat 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 integrationproblems 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 apossibility of service providing and consuming. Business-to-business (B2B) relations through computer networks have acomparably long history, but a history with a separation ofprotocols, languages, standards. But The Web is one. Withits user and producer-friendliness, HTML became universal,as well as XML that is similar. And a technology of a moreconnected world is being developed: Web Services.

Web Services are simple in theory. Simply put, they areservice requesting and providing, by sending and receivingmessages of some format. The messages are commonly XMLformatted. Most desired features of Web Services are inter-operability between different systems, perfect security andquality (as it is for business use), easy interpretation andimplementation.

II. BASIC CONCEPTS

Before focusing on details of Web Services, let us look atsome basic concepts concerning this technology.

A. A human friendly format: XML

In Web Services, many message formats are based onExtensible 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 bothhuman readable and machine readable. Positive attributes ofXML 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 parsingAnd 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 messagingprotocol that is based on Extensible Markup Language (XML)used usually with Hypertext Transfer Protocol (HTTP). Theoriginal acronym was dropped with version 1.2 as it wasmisleading, it became only SOAP. [1]

SOAP forms the second layer of Web services protocolstack, more abstract layers build on it. These are, “servicedescription” protocols such as WSDL, and “service discoveryprotocols” such as UDDI.

Most widely used messaging pattern of SOAP is RemoteProcedure Call (RPC). In fact, SOAP evolved from XML-RPCthat 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 arecurrently maintained by XML Protocol Working Group ofW3C. It was intended to be a protocol to allow softwareapplications 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://warehouse.example.com/ws"><productID>827635</productID>

</getProductDetails></soap:Body>

</soap:Envelope>

Above is a SOAP formatted request example. It uses theoperation “getProductDetails” to get information about theproduct with ID 827635. This message is independent of theoperating 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 messagesare text based and very easy to read. This is also a weakness asa limitation to transfer speed, because the messages are verylong and this may affect network performance. Some othertechnologies such as CORBA use binary format and do notbear this weakness. This is a general problem of XML-basedprotocols.

C. Transferring messages: HTTP

SOAP messages are transferred using Hypertext TransferProtocol (HTTP). HTTP is a method used to transfer or conveyinformation on the World Wide Web. Its original purpose wasto provide a way to publish and retrieve HTML pages. It isalso used to transfer XML files and XML-based file formatssuch as SOAP.

HTTP is used between clients and servers as a re-quest/response protocol. The connecting agent, a client, aweb browser, or any other end-user application, is describedas the “user agent”. The destination server, is called theorigin server. Resources such as HTML files and images arestored or created in the server. In between the user agent andorigin 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 abstractconcepts and separated from their concrete use or instance.

A “port” is a network address that can be reused throughbinding. A “port type” is an abstract collection of supportedoperations. 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 WebService by using these concepts.

WSDL is generally used with SOAP. If a client programconnects to a Web Service, it can get the WSDL to understandwhat operations are available on the server. Special data typesare 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 interfaceof a Web Service, it does not provide any information aboutits behavior. Behavioral descriptions of Web Services aredefined using higher level standards such as Business ProcessExecution Language for Web Services (BPEL). The WebService Choreography Description Language (WS-CDL) isused to specify the interactions among multiple Web Services.

E. A universal registry: UDDI

There is a standard registry for Web Services. It is UniversalDescription, 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 marketthat different businesses find each other’s services and interactover 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 proposedUDDI 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 formatsdescribed in WSDL documents, the client can use any servicethat is offered in UDDI by several businesses.

F. Programming in the large with BPEL

Being grown out of WSFL and XLANG, Business ProcessExecution 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-levelstate transitions and interactions between sides of a businessprocess. This concept is given as an “abstract process”. Everyabstract process provides information about the system statesto wait for messages, send messages, or to compensate forfailed transactions. In contrast, “programming in the small”is about short-lived programmatic behavior, often ran as asingle transaction that involves access to resources such as filesand databases. An important motivation behind BPEL is thatprogramming 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 formulatedby Roy Fielding. It is best summed up in its designer’swords (from his book, Architectural Styles and the Designof Network-based Software Architectures).

“Representational State Transfer (REST) is intended toevoke an image of how a well-designed Web applicationbehaves: a network of web pages (a virtual state-machine),where the user progresses through an application by selectinglinks (state transitions), resulting in the next page (representingthe next state of the application) being transferred to the userand rendered for their use.”

The REST principles are:1) Application state and functionality are divided into re-

sources2) Every resource is uniquely addressable using a universal

syntax for use in hypermedia links3) 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-demand4) 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. InREST, there are mainly resources, such as web pages. Mainoperations are GET, PUT, POST, and DELETE. In contrast,object-oriented or RPC systems have functions and proceduresfor calling. For example, in a RESTful system, we acquireinformation about a certain user by “getting” the resource withaddress “users/001”. Whereas in an RPC system, we have tocall a function like “getUser(id)”.

III. UNDERSTANDING WEB SERVICES

A. What Are Web Services

Web Service is defined by W3C as a software systemfor making different computers interact. The computers mayhave different operating systems, different inner structure, butthe logic of Web Service should make it possible for themto interact and make operations. This is the most generaldefinition. But in practice, Web Services usually make useof 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-

sagingThese 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 WebServices interoperability. Web Service development based onthese standards is supported by different implementation plat-forms such as .Net and J2EE (see [2] for Sun One WebServices Framework).

In short, Web Services are a combination of a discoverysystem (UDDI), a description system (WSDL) and the WebServices themselves.

The discovery system (UDDI) is used by a hosting busi-ness to enter information describing themselves, publishingtaxonomy along with the descriptions (WSDL) of services theyprovide. This allows another business to find their service bysearching with some criteria. It also supports category-basedsearch 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 operationThe 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 oftransport and application protocols. The inner structureof the service is irrelevant. It is only necessary that itresponds to a special format of XML files.

• For the service to interpret the information in XMLdocuments, there must be a shared description of an XMLrequest-response format. This is described in an XMLSchema. 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 addressfor TCP or HTTP protocol but not necessarily is.

The fourth element is an envelope for the XML document. Itis optional but very helpful, for example for putting additionalinformation such as security and routing. Soap envelopes arecommonly used standard. Soap has two parts: A header thatkeeps all system information, and a body that contains theXML document to be processed by the Web Service.[4] If welook at this simplistic model of the Web Services technology,it seen that this technology is very simple in its core.

C. The Roles

In 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 getWSDL service description and a service URL; or bind to theservice and invoke it.

D. Web Services programming stack

To understand the operations of Web Services, let us have alook at The Web Services programming stack. This stack is acollection of standardized protocols and application program-ming interfaces (APIs) that lets individuals and applicationslocate and utilize Web Services. Layers in the stack correspondto operations made by one of three roles above. First threelayers are crucial to the system. The remaining layers areoptional 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 theplace of the protocol to transfer messages. Most oftenused such protocol is HTTP.

2) Messaging layer comes after the network layer. It isthe communication platform between Web Services andtheir clients. All operations, publishing, finding, bind-ing, and invoking is accomplished by sending mes-sages. Most widespread message protocol is XML-basedSOAP.

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 Servicesto clients.

4) Service publication layer. This layer is about a serviceprovider making its WSDL document available. UDDIcan be used, but it is not necessary. Just sending an e-mail attaching your WSDL document is considered aspublishing.

5) Service discovery layer. This layer is where a servicerequester gets someone’s WSDL document. UDDI is a

possible interface, but receiving an e-mail with a WSDLdocument 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 FlowLanguage (WSFL) was offered by IBM as a standardto be used in service flow layer. Similarly XLANGwas offered by Microsoft. Then these were combinedto 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 forthis service.

• Composition layer. Related services are expressed here.Groupings, containment, dependencies, and parent-childrelationships 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 serviceis expected to adhere.

• Business-level agreement layer. A contractual agreementbetween the two business partners who will be transactingbusiness using Web Services.

E. Common Misconceptions

As Web Services gained popularity, there appeared severalmisunderstandings about the concept. We are going to focuson main misconceptions about Web Services below.[4]

1) Web Services are message oriented: There are two mainmiddleware approaches in terms of interaction models. Oneis message-oriented middleware (MOM), which includes WebServices. 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 orEnterprise Java Beans belong to this category. The interactionmodels determine most things about a system.[7]

Recently, there was a debate in W3C Web Services Archi-tecture working group forum about applying representationalstate transfer (REST) principles to Web Services architectures.Representational State Transfer (REST) is a term to describethe Web’s architectural style. In contrast to objects and func-tions, REST is based on resources and only four operations onthem: Put, Get, Post and Delete. As it is simple and platform-neutral, it well suits to the field of Web Services and itsinteroperability needs.[8]

2) Web Services are not distributed objects: Web Servicesare very similar to distributed objects in the sense that theyboth have a certain description language, they incorporatewell-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 itFurthermore, another attribute of objects is being identified

through a reference. It also carries references to other objects.Several reference handling techniques are developed for thiskind of (object-oriented) architecture. Web Services do notrequire any of these concepts.

In Web Services, there are no life cycles. Also no notionof objects, object references or factories. There are no methodinterfaces, no serialization of data-structures, or garbage col-lection of references. Distributed object systems enable statefuldistributed computing, though Web Services cannot offer anyof the stateful distributed computing facilities. Web Servicesare solely about sending and receiving XML documents anddocument encapsulation.

The difference is obvious if we look at how informationflows between client and server or producer and consumer inthese 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 determineeverything. Of course there are also contexts of interactionsin Web Services. But these contexts are also identified as anongoing conversation in the form of document transfer ratherthan any states at the services.

Distributed objects are mature and robust systems. But theirapplication is usually limited to the corporate intranets, whichare often characterized by platform homogeneity and pre-dictable latencies. The strength of Web Services is in Internet-style distributed computing, where interoperability and supportfor platform and network heterogeneity are essential. In time,Web Services are probably going to gain similar properties asdistributed object systems such as having guaranteed, in-order,exactly-once message delivery.

3) Web Services are not RPC for the Internet: RemoteProcedure Calling is done through a network abstraction for

remotely executing procedure calls in a certain programminglanguage.

This low level operation requires the caller to identify theremote procedure, to decide which state must be provided tothe procedure at invocation time, and what form to use topresent the results to the caller at completion time. The RPCsystems also include extensive mechanisms for handling errorsat both the runtime and programming levels.

In Web Services, there is no concept of procedure callingand caller. There is the notion of actor or role that consumesthe service. But there are no predefined semantics with theXML document’s content. We could implement a Web Servicethat runs RPC, but it would be a very specific Web Service andit would force a certain fixed rules for encoding the argumentsin an XML document and rules for returning the results to thecaller.

Internet-wide RPC was a failure. This has several reasons.Synchronous interactions over wide-area networks are notscalable, for example, and large-scale versioning of procedureinterfaces is extremely difficult. Web Services neither have thefunctionalities of RPC nor bear these difficulties.

4) Web Services do not need HTTP: Web Services do notdepend on the transport protocol that is used. SOAP messagesmay well be transported through plain TCP or UDP, or evenSMTP by e-mail. There are also alternatives such as MQ-Series or Java messaging service (JMS) to name a few. Thesetechnologies can also be combined. For example a SOAPpackage that comes to the system through HTTP may beautomatically 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 dispatchingduties to the Web servers. These features were present in theinfrastructure offered by the major Web servers: Apache, IBMWebSphere, and Microsoft IIS. Therefore, since first Web Ser-vices, HTTP was used. These servers still provide best serviceexercise tools, supporting WSDL and other standards. Theymake 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-orientedintegration, or services bus do not mention “Web”, becausethey are independent of Web Servers. Early Web Serviceshave exploited Web servers’ application-server functionality,but now there are several toolkits that let you develop andintegrate Web Services without using Web server infrastruc-tures. Examples are: Simon Fell’s Pocket-Soap, Systinet’sWeb Applications and Services Platform (WASP), IBM’sEmerging Technologies Toolkit, Microsoft’s Web ServicesEnhancements (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 thesefeatures. In a few situations, the protocol cannot completelydeliver 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 thecondition of network, node, or component failures, it is verypossible that even the document reaches the first station, itmight not be delivered to the server and not processed. Theseproblems are to be solved by reliable messaging techniques,WS-ReliableMessaging standard, to be precise.

7) Debugging Web Services is possible: It is believed thatit is impossible to debug Web Services. Traditional debuggingtools depend on a complete knowledge of a system, but as therequester and provider of a Web Service are usually differentorganizations, a different debugging paradigm is necessary.Most difficult problems are cross-vendor interoperability andWSDL versioning.

There are new diagnostic tools such as SOAPscope forissues of development and deployment of Web Services. Asdevelopment toolkits for Web Services are more commonlyused, interoperability problems between parties using dif-ferent toolkits are appearing. SOAPscope has features fortrying “what if” scenarios against a server to isolate problemrequests. It has visualizing capabilities for viewing SOAPmessages more abstractly. It can also make WSDL analysisand WSDL version checking for the detection of errors and forhelping to resolve potential interoperability problems beforeservice deployment.

IV. USING WEB SERVICES

In Web Services, enterprise-class infrastructure must be sup-plied, including security, management, and quality-of-servicemanagement 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 transactionWeb Services use generally accepted standardized APIs to

communicate at each level of the programming stack8) Networking standard: Internet and HTTP has greatly

extended the ability of companies to easily and automaticallycommunicate with its users, whether these users are computersor human beings

Within the corporation itself, multiple networking protocolsmay be used, but in this case adapters will convert betweenthese protocols and HTTP for messages that pass through theenterprise 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 directlyinvoke a remote procedure (RPC)

For a long time, there was no common protocol for handlingboth types of messages. Multiple protocols were being used tohandle messages of each type. Now, SOAP is the standardizedmechanism for communicating document-centric messagesand remote procedure calls using XML.

10) Service description standard: Service requesters mustbe able to know what services are available from the provider,what message format is used to invoke them, and whatcosts are involved. WSDL is the standard way of giving thisinformation.

11) Service publication and service discovery standards:UDDI is the standard for publication and discovery. There arepublic and private UDDI registries.

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

There are also private registries maintained by individualcompanies or industry consortiums that have controlled per-mission for access. For example, an enterprise may create itsprivate registry to accept only merchants and users at somequality 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 anorder over a certain amount of money, the system must get theapproval of a manager before proceeding. WS-BPEL is usedfor this purposes.

A. Security Problems

For Web Services to be used securely, following issues mustbe solved

• Authentication: Establishing identity for requesters andproviders.

• Authorization: Establishing permissions for users.• Confidentiality: Making sure that only the intended re-

cipient reads the message. This is accomplished withencryption.

• Integrity: Ensuring the message hasn’t been changed.Generally accomplished with digital signatures.

1) SSL and TLS: For transporting security, Secure SocketsLayer (SSL) is commonly used. SSL is a public-private keysecurity system that works with digital certificates and operatesbetween HTTP and TCP network layers. Transport LayerSecurity (TLS) protocol was then developed and succeededSSL. The web browsers generally support these systems, butthey do not work well with complex, high-volume transactionslike Web Services. This is because these systems do decryptionfollowed 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 XMLtransmission by defining security related schemas for structur-ing documents. These schemas include information related to

7

user identity and access or authorization rights. The standardtransmission of these security information allows companiesusing 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 authenticationticket, 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 toshare authentication of a requester between providers, so thata 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 modelsby extending SOAP message format. Security data is attachedto the headers of SOAP messages. This information containsmetadata found in specifications of XML Encryption and XMLSignature. It also allows using digital signatures in SOAPmessages.

• XML Encryption provides ways to encrypt whole orparts of an XML message using common encryptionalgorithms.

• XML Signature defines processing rules and syntax forrepresenting digital signatures.

There are also other higher level standards that are on topof WS-Security.

• WS-SecurityPolicy is a general framework for definingsecurity, privacy, and other policies on machines used forWeb Services

• WS-Privacy lets providers and users state privacy prefer-ences and practices

• WS-Trust is a framework of models for establishing bothdirect and brokered trust relationships

• WS-SecureConversation establishes sessions in whichSOAP acts like a connection-based approach

• WS-Authorization define how to manage authorizationpolicies

• WS-Federation standardizes the way companies shareuser 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 theparticular area of Web Services, it is crucial to remember thatSOAP XML messages are documents, not remote procedurecalls. Loose coupling ensures that other applications relyingon your service does are not affected by your changes in im-plementation. In the ideal model, every incoming and outgoingmessage 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 objectsover time tend to break the clients. The Web is an exception tothis, eventhough publishers change web sites fundamentally,users can always view HTML through their browsers. Because

browsers make no assumptions of a site’s implementation, itonly knows the “wire format” (HTML).

Like Web itself, Web Services also have this goal to betotally independent to implementation. It only depends on a“public contract” about expected XML to be generated orreceived. Object oriented approaches and remote procedurecalling do not work for services-based application integration,because they are not loosely coupled. For establishing loosecoupling, a message-oriented, document-based approach andXML model is necessary for Web Services. [10]

2) Application Service Strategies: There are several re-search papers on the business implications of Web Servicestechnology. In a very recent paper by Cheng et al., [11], threeapplication service strategies were compared for providingWeb services of complementary functionalities. These are:

• Independent Service Vendors (ISVs): In this applicationservice strategy, there are two independent vendors andtwo different services, but these services combine to makea third service. Some of the customers demand only oneof two services, some need the third service and demandthe first two for this reason. In this scenario, combiningservices is not by by vendors but the consumers. Price ofthird service is not regulated.

• Joint venture (JV): In JV, these two vendors join intoa single company to sell the third service at the pricethey determine. And the customers of the combinedproduct cannot divide the product/service to get the twocomponent services.

• Strategic Alliance (SA): SA is the combination of ISVand JV strategies. In this case, third service is both createdby consumers and sold by the company. Thus, the priceof third service cannot exceed the consumers’ cost offorming it from first two services.

These events occur in product bundling in other sectors. Butsoftware bundling have distinct features such as low integra-tion cost and possibility of creating an integrated Web servicewith new functionalities. The authors analysed three strategiesand obtained interesting conclusions. They found that optimalapplication service strategy depends on several factors. Thesefactors include the integration cost, the valuations, and marketpotentials of individual and integrated Web Services. Theirconclusions tell that SA is in general more profitable to ISV,showing that interoperability between Web Service vendors isbenefitable. In most cases, SA is the best option. But in somecases where the integrated Web Service is highly valuated andthe integration cost is small, JV becomes the best applicationservice strategy.

3) Web Service Interaction and Collaboration: In a 2005study 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) requirementsfor Web Services.

He specifies and categorizes the business interactions intoenterprise, customers, suppliers, and partners’ interactions,in terms of activities. Then he makes a crucial distinctionbetween “core business activities” and “interaction activities”.

8

Lastly, he develops the Business Interactions Manager (BIM)that is dedicated to “interaction activities” of companies.

There is also another recent paper by Chan et al., [13],about collaborative Web Services. The project is called WE-BGOP and it aims to enhance the Web using Graph-OrientedProgramming. It is claimed that the Web is limited to beinga clientserver system, and it can be advanced to a structuredmultipoint system. WEBGOP is a program that creates a log-ical graph of a network and links collaborative Web Servicesto each other. Therefore Web Services can either individuallyor jointly be invoked by requesters. A joint invoke is done bya multicast message whereas a single invoke with a unicastmessage on the overlay network.

4) Verification of Web Services: Implementation of WebServices introduce several verification problems involvingmore than one parties. This is a security problem, as well as adebugging and verification problem. The interactions betweenrequesters and providers are asynchronous, meaning that thereis no ordered connection, but several messages that are queuedand processed in time. Fu et al., in their paper, [14], proposea framework for analyzing this type of interactions amongWeb services. They modelled the interactions in the case ofa composite Web Service as conversations. A conversation isthe global sequence of messages exchanged among parties.

The conversation model brings a problem: Do the conver-sations satisfy a certain property? (The property is formulatedin Linear Temporal Logic (LTL)) They show that asyn-chronous messaging is not decidable for unbounded messagequeues and even practically not checkable for bounded ones.Therefore they use a new technique called SynchronizabilityAnalysis, synchronizability meaning that replacability by asynchronous communication without changing the conversa-tion itself. Conditions for this property are determined andstatistically checked.

As the authors synchronize previously asynchronous com-munications, they see that large class of composite Web Ser-vices with unbounded message queues are in fact completelyverifiable using a finite state model checker. This technique canalso be used for checking against conversation specifications.

A previous verification technique was proposed by Foster etal. in 2003. [15] They introduced a Model-based verificationtechnique for the same problem of verifying composite WebServices. This method is based on a UML model of specifi-cations that are represented in the form of Message SequenceCharts (MSCs) and compiled into the Finite State Processnotation (FSP). This paper is also based on Business ProcessLanguage for Web Services (BPEL4WS) which was an effortto standardize workflows of Web Services. It is now acceptedstandard, BPEL.

V. CONCLUSION

Web Services make a transformation from eyeball web totransactional web. The eyeball web is dominated by program-to-user business-to-consumer (B2C) interactions. The transac-tional web will be dominated by program-to-program business-to-business (B2B) interactions.

A program-to-program communication model of Web Ser-vices is developed. This programming model is both language-

neutral and environment-neutral. This nature of Web Serviceshelp application integration inside and outside the enterprise.Thus, allows the design of flexible loosely coupled businesssystems. Furthermore, it makes just-in-time application andbusiness integration possible.[5]

Of course, there are problems concerning verifiability andsecurity issues. The problems seem huge, considering the statespaces created by asynchronous messaging, but there are newapproaches like Synchronizability Analysis that help to reducethis problem to an easier one.

There are also problems of business strategies. For example,is joining or not joining companies more profitable? There arealso research in this subject as we have discussed.

To conclude, Web Services are a unique technology thatcomes with misconceptions and several problems. However,the researchers are step by step overcoming them, openingthe future to new possibilities that Web Services is to bring.

REFERENCES

[1] P. Louridas, “Soap and web services,” IEEE Software, vol. 23, no. 6,pp. 62–67, 2006.

[2] S. Kleijnen and S. Raju, “An open web services architecture,” Queue,vol. 1, no. 1, pp. 38–46, 2003.

[3] C. Ferris and J. Farrell, “What are web services?” Commun. ACM,vol. 46, no. 6, p. 31, 2003.

[4] W. Vogels, “Web services are not distributed objects,” IEEE InternetComputing, vol. 7, no. 6, pp. 59–66, 2003.

[5] K. D. Gottschalk, S. Graham, H. Kreger, and J. Snell, “Introductionto web services architecture.” IBM Systems Journal, vol. 41, no. 2, pp.170–177, 2002.

[6] H. Kreger, “Fulfilling the web services promise,” Commun. ACM,vol. 46, no. 6, pp. 29–ff, 2003.

[7] S. Vinoski, “Web services interaction models, part 1: Current practice,”IEEE Internet Computing, vol. 6, no. 3, pp. 89–91, 2002.

[8] ——, “Putting the ”web” into web services: Interaction models, part 2,”IEEE Internet Computing, vol. 6, no. 4, pp. 90–92, 2002.

[9] D. Geer, “Taking steps to secure web services,” Computer, vol. 36,no. 10, pp. 14–16, 2003.

[10] A. Bosworth, “Loosely speaking,” XML and Web Services Magazine,vol. 3, no. 4, 2002.

[11] J. Z. H.K. Cheng, Q.C. Tang, “Web services and service-orientedapplication provisioning: An analytical study of application servicestrategies,” Engineering Management, IEEE Transactions on, vol. 53,no. 4, pp. 520–533, 2006.

[12] Y. Baghdadi, “A web services-based business interactions manager tosupport electronic commerce applications,” in ICEC ’05: Proceedingsof the 7th international conference on Electronic commerce. New York,NY, USA: ACM Press, 2005, pp. 435–445.

[13] A. T. S. Chan, J. Cao, and C. K. Chan, “Webgop: collaborative webservices based on graph-oriented programming.” IEEE Transactions onSystems, Man, and Cybernetics, Part A, vol. 35, no. 6, pp. 811–830,2005.

[14] X. Fu, “Synchronizability of conversations among web services,” IEEETrans. Softw. Eng., vol. 31, no. 12, pp. 1042–1055, 2005, member-TevfikBultan and Senior Member-Jianwen Su.

[15] H. Foster, S. Uchitel, J. Magee, and J. Kramer, “Model-basedverification of web service compositions,” 2003. [Online]. Available:citeseer.ist.psu.edu/foster03modelbased.html