Understanding and Using The Web Services Architecture

1

Understanding and Using The Web Services Architecture Is¸ık Barıs¸ Fidaner, Bo˘gazic¸i University

Abstract— This is a study about Web Services, what this technology is, how it is used, what problems and possibilities does it bring, and how its problems are solved.

In the first part, basic concepts and standards about Web Services 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 the REST principles.

Second part is about understanding what Web Services are, and main design points for Web Service programming. It starts by a description and a simple core model of Web Services. The roles and layers of the conceptual Web Services programming stack are explained. Some common misconceptions about Web Services are considered.

Third and last part is about the problems of using Web Services. Possible business requirements about Web Services are listed, and standards solving them are considered. Then security problems and different solutions such as SSL, TLS, SAML are explained. Then comes the problems concerning application integration. There are both non-technical integration problems about business strategy, and technical problems for the verification of asynchronous interactions in Web Services. There are recent papers proposing solutions to both types of problems.

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

I. I NTRODUCTION HE 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-tobusiness (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 interoperability between different systems, perfect security and quality (as it is for business use), easy interpretation and implementation.

T

II. BASIC C ONCEPTS 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 generalpurpose markup language that is used in variety of applications. In every XML file, there are entities that are structured as 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 science abstractions • Names and values are openly written, making it a selfdocumenting 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 nonhierarchical data in XML is difficult.

B. Message format: SOAP Web Services generally use SOAP as a message envelope format. 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 Atkinson, 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:

D. Service description: WSDL Web Services Description Language (WSDL) is an XML<soap:Envelope xmlns:soap="http://schemas based language for communicating descriptions of Web Ser.xmlsoap.org/soap/envelope/"> vices.

WSDL defines services as a collection of “ports” that <soap:Body> receive and send “messages”. But these are taken as abstract <getProductDetails xmlns="http://ware concepts and separated from their concrete use or instance. house.example.com/ws"> A “port” is a network address that can be reused through <productID>827635</productID> binding.

A “port type” is an abstract collection of supported </getProductDetails> operations.

A “service” is a collection of ports. “Message” </soap:Body> is defined as abstract definitions of data that is transferred. </soap:Envelope> WSDL describes the public interface for a particular Web Above is a SOAP formatted request example. It uses the Service by using these concepts. operation “getProductDetails” to get information about the WSDL is generally used with SOAP. If a client program product with ID 827635. This message is independent of the connects to a Web Service, it can get the WSDL to understand operating system or any inner structure of the server. what operations are available on the server. Special data types <soap:Envelope xmlns:soap="http://schemas are written in WSDL in XML Schema format. Then SOAP messages are used for calling the functions on the server. .xmlsoap.org/soap/envelope/"> Although a WSDL specification defines the public interface <soap:Body> of a Web Service, it does not provide any information about <getProductDetailsResponse xmlns="http its behavior. Behavioral descriptions of Web Services are ://warehouse.example.com/ws"> defined using higher level standards such as Business Process <getProductDetailsResult> Execution Language for Web Services (BPEL). The Web <productName>Toptimate 3-Piece Set Service Choreography Description Language (WS-CDL) is </productName> used to specify the interactions among multiple Web Services. <productID>827635</productID> <description>3-Piece luggage set.

E. A universal registry: UDDI Black Polyester.</description> There is a standard registry for Web Services. It is Universal <price>96.50</price> Description, Discovery, and Integration (UDDI). UDDI is an <inStock>true</inStock> XML-based list of businesses. It was written in August 2000, </getProductDetailsResult> and it is sponsored

by OASIS. It is like a platform or market </getProductDetailsResponse> that different businesses find each other’s services and interact </soap:Body> over the Internet.

Every business registers on the following: </soap:Envelope> • White Pages that include addresses, contact information This is the response of the server. The operation is realized, • Yellow Pages that include sectoral categorizations based and product details are returned to the client. SOAP messages on standard classifications are text based and very easy to read. This is also a weakness as • Green Pages that include technical information about the a limitation to transfer speed, because the messages are very services proposed long and this may affect network performance. Some other UDDI is queried by SOAP messages. Clients send SOAP technologies such as CORBA use binary format and do not messages to the UDDI to get service descriptions in WSDL. bear this weakness. This is a general problem of XML-based And then, using the protocol bindings and message formats protocols. described in WSDL documents, the client can use any service that is offered in UDDI by several businesses.

C. Transferring messages: HTTP SOAP messages are transferred using Hypertext Transfer F. Programming in the large with BPEL Protocol (HTTP). HTTP is a method used to transfer or convey Being grown out of WSFL and XLANG, Business Process information on the World Wide Web. Its original purpose was Execution Language (BPEL) is a XML-based business proto provide a way to publish and retrieve HTML pages. It is cess language that aims to enable programming in the large. also used to transfer XML files and XML-based file formats “Programming in the large” generally refers to the high-level such as SOAP. state transitions and interactions between sides of a business HTTP is used between clients and servers as a re- process. This concept is given as an “abstract process”. Every quest/response protocol. The connecting agent, a client, a abstract process provides information about the system states web browser, or any other end-user application, is described to wait for messages, send messages, or to compensate for as the “user agent”. The destination server, is called the failed transactions. In contrast, “programming in the small” origin server. Resources such as HTML files and images are is about short-lived programmatic behavior, often ran as a stored or created in the server. In between the user agent and single transaction that involves access to resources such as files origin server may be several intermediaries, such as proxies, and databases. An important motivation behind BPEL is that gateways, and tunnels. 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 resources 2) Every resource is uniquely addressable using a universal syntax 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 supporting code-on-demand 4) A protocol that is: • Client/Server • Stateless • Cacheable • Layered There is a fundamental difference between RPC and RESTful (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. U NDERSTANDING W EB S ERVICES A. What Are Web Services Web 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 messaging These are the standards proposed by Organization for the Advancement of Structured Information Standards (OASIS)

and W3C. Web Services Interoperability Organization (WSI) also creates some applications and tools to enhance Web Services interoperability. Web Service development based on these standards is supported by different implementation platforms 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 business 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-tobusiness 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. This is 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 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 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 programming 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, binding, and invoking is accomplished by sending messages. Most widespread message protocol is XML-based SOAP. 3) Service description layer. This is where service description 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 email 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 facilitates the composition of Web Services into workflows and the representation of this aggregation of Web Services 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 commonly used and standardized.[6] • Policy description layer. Its purpose is to define servicespecific information beyond mechanics, such as owning 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, choreography, 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 Architecture 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 functions, REST is based on resources and only four operations on them: Put, Get, Post and Delete. As it is simple and platformneutral, 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 mechanisms for registering and discovering available components.

However, Web Services are not distributed objects.

In a distributed object system, every object, with the exception 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 not require 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 collection 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 information travels 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 predictable latencies. The strength of Web Services is in Internetstyle 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 to the 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 MQSeries 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 or JMS. Web Services are not specifically designed for HTTP, though HTTP is most commonly used. It is easier for the developers 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 Services, 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 was a 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 infrastructures. 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 inorder message delivery, because TCP guarantees these features. 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 intermediaries that makes things even more problematic. In the condition of network, node, or component failures, it is very possible 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 for issues of development and deployment of Web Services. As development toolkits for Web Services are more commonly used, interoperability problems between parties using different 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. U SING W EB S ERVICES In Web Services, enterprise-class infrastructure must be supplied, including security, management, and quality-of-service management to meet the stringent demands of today’s ebusinesses.[5] The requirements of an e-commerce business would be: • Exchanging information programmatically with users.

• Sharing common formats with users for data and messages.

• 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 applications 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 between these 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 to handle 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.org and 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 permission 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 complex 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 recipient 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 provided no security.

2) SAML: OASIS created Security Assertion Markup Language (SAML) for solving the security problems in XML transmission by defining security related schemas for structuring 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 (WSSecurity) 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 XML Signature. 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.

•

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 research 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:

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 preferences 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 authentication and authorization systems.

B. Application Integration 1) Loose Coupling: For a robust and platform-neutral application 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 implementation. 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 objectoriented 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

•

•

Independent Service Vendors (ISVs): In this application service 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 integration 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 perspective is conceptualized in terms of the business processes among business functions and objects, and customer-tobusiness (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”.

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 WEBGOP and it aims to enhance the Web using Graph-Oriented Programming. It is claimed that the Web is limited to being a clientserver system, and it can be advanced to a structured multipoint system. WEBGOP is a program that creates a logical graph of a network and links collaborative Web Services to each other. Therefore Web Services can either individually or jointly be invoked by requesters. A joint invoke is done by a multicast message whereas a single invoke with a unicast message on the overlay network.

4) Verification of Web Services: Implementation of Web Services introduce several verification problems involving more than one parties. This is a security problem, as well as a debugging and verification problem. The interactions between requesters and providers are asynchronous, meaning that there is no ordered connection, but several messages that are queued and processed in time. Fu et al., in their paper, [14], propose a framework for analyzing this type of interactions among Web services. They modelled the interactions in the case of a composite Web Service as conversations. A conversation is the global sequence of messages exchanged among parties.

The conversation model brings a problem: Do the conversations satisfy a certain property? (The property is formulated in Linear Temporal Logic (LTL)) They show that asynchronous messaging is not decidable for unbounded message queues and even practically not checkable for bounded ones.

Therefore they use a new technique called Synchronizability Analysis, synchronizability meaning that replacability by a synchronous communication without changing the conversation itself. Conditions for this property are determined and statistically checked.

As the authors synchronize previously asynchronous communications, they see that large class of composite Web Services with unbounded message queues are in fact completely verifiable using a finite state model checker. This technique can also be used for checking against conversation specifications.

A previous verification technique was proposed by Foster et al. in 2003. [15] They introduced a Model-based verification technique for the same problem of verifying composite Web Services. This method is based on a UML model of specifications that are represented in the form of Message Sequence Charts (MSCs) and compiled into the Finite State Process notation (FSP). This paper is also based on Business Process Language for Web Services (BPEL4WS) which was an effort to standardize workflows of Web Services. It is now accepted standard, BPEL. V. C ONCLUSION Web Services make a transformation from eyeball web to transactional web. The eyeball web is dominated by programto-user business-to-consumer (B2C) interactions. The transactional web will be dominated by program-to-program businessto-business (B2B) interactions.

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

neutral and environment-neutral. This nature of Web Services help application integration inside and outside the enterprise.

Thus, allows the design of flexible loosely coupled business systems. Furthermore, it makes just-in-time application and business integration possible.[5] Of course, there are problems concerning verifiability and security issues. The problems seem huge, considering the state spaces created by asynchronous messaging, but there are new approaches like Synchronizability Analysis that help to reduce this problem to an easier one.

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

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

R EFERENCES [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 Internet Computing, vol. 7, no. 6, pp. 59–66, 2003.

[5] K. D. Gottschalk, S. Graham, H. Kreger, and J. Snell, “Introduction to 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-oriented application provisioning: An analytical study of application service strategies,” Engineering Management, IEEE Transactions on, vol. 53, no. 4, pp. 520–533, 2006.

[12] Y. Baghdadi, “A web services-based business interactions manager to support electronic commerce applications,” in ICEC ’05: Proceedings of 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 web services based on graph-oriented programming.” IEEE Transactions on Systems, Man, and Cybernetics, Part A, vol. 35, no. 6, pp. 811–830, 2005.

[14] X. Fu, “Synchronizability of conversations among web services,” IEEE Trans. Softw. Eng., vol. 31, no. 12, pp. 1042–1055, 2005, member-Tevfik Bultan and Senior Member-Jianwen Su. [15] H. Foster, S. Uchitel, J. Magee, and J. Kramer, “Model-based verification of web service compositions,” 2003. [Online]. Available: citeseer.ist.psu.edu/foster03modelbased.html