For Peer Review: Web Services Technologies and Standards

Computing Surveys
Web Services Technologies and Standards
Manuscript ID: Paper: Date Submitted by the Author: Complete List of Authors: Computing Classification Systems:
r Fo
Journal: draft n/a
Computing Surveys
Information Systems
Papazoglou, Michael; Tilburg Univ., Information Systems H3 Information Storage & Retrieval, H3.5 Online Information Services, Web-based services, Service oriented computing
Pe
er
Re
vi ew
Page 1 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Web Services Technologies and Standards

Michael P. Papazoglou INFOLAB, Tilburg University, PO Box 90153, Tilburg 5000 LE, The Netherlands
mikep@uvt.nl
Abstract Web services are self-contained, Internet-enabled applications capable not only of performing business activities on their own, but also possessing the ability to engage other Web services in order to complete higher-order business transactions. The act of building applications and processes as sets of interoperating services is enabled by means of unified service-oriented architecture (SOA). SOA introduces a new philosophy for building distributed applications where elementary services can be published, discovered and bound together to create more complex valued-added services. This article aims at providing a comprehensive survey of Web service technologies, examining it usage, its relation with other technologies, the newest developments in the field, architectural models and standards. The article presents a Web services functionality stack on the basis of whose functional layers it taxonomizes service standards and current research activities. Categories and subject descriptors: H [Information Systems]: H3 [Information Storage & Retrieval]: H3.5 [Online Information Services]: Web-based services General terms: Design, Languages, Standards, Management. Additional keywords and phrases: Service Oriented Computing, Web services, process modeling and management, workflow systems, application integration, coordination and collaboration.
Fo
rP
ee
rR
ev
Introduction
Service-Oriented Computing (SOC) utilizes services as the constructs to support the development of rapid, low-cost and easy composition of distributed applications. Services are autonomous, platform-independent computational entities that can be used in a platform independent way. Services can be described, published, discovered, and dynamically assembled for developing massively distributed, interoperable, evolvable systems. Services perform functions that can range from answering simple requests to executing sophisticated business processes requiring peer-to-peer relationships between possibly multiple layers of service consumers and providers. Any piece of code and any application component deployed on a system can be reused and transformed into a network-available service. Services reflect a "service-oriented" approach to programming, based on the idea of composing applications by discovering and invoking network-available services rather than building new applications or by invoking available applications to accomplish some task [Papazoglou 2003]. This "service-oriented" approach is independent of specific programming languages or operating systems. Services are most often built in a way that is independent of the context in which they are used, i.e. service provider and consumers are loosely coupled. At the middleware level, loose coupling requires that the "service-oriented" approach be independent of specific technologies or operating systems. In particular, services and service composition does not rely on existing programming languages. It allows organizations to expose their core competencies programmatically over the Internet or a
iew
Copyright Michael P. Papazoglou
8 April 2006
Computing Surveys
Page 2 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
variety of networks, e.g., cable, UMTS, XDSL, Bluetooth, etc., using standard (XML-based) languages and protocols, and implementing a self-describing interface. The premise of SOCs foundation is that an application can no longer be thought of as a single process running within a single organization. The value of an application is actually no longer measured by its functionality but by its ability to integrate with its surrounding environment. For instance, services can help integrate applications that were not written with the intent to be easily integrated with other applications and define architectures and techniques to build new functionality leveraging existing application functionality. A new type of applications can be based solely on sets of interacting services offering well-defined interfaces to their potential users. These applications are often referred as: composite applications. In the business-to-business (e-Business) world, service orientation enables loosely coupled relationships between applications of transacting partners, the model does not even mandate any kind of pre-determined agreements before the use of an offered service is allowed [Papazoglou 2006a]. The service model allows for a clear distinction to be made between service providers (organizations that provide the service implementations, supply their service descriptions, and provide related technical and business support); service clients (end-user organizations that use some service); and service aggregators (organizations that consolidate multiple services into a new, single service offering). Services are offered by service providers which are organizations that procure the service implementations, supply their service descriptions, and provide related technical and business support. Clients of services can be other solutions or applications within an enterprise or clients outside the enterprise, whether these are external applications, processes or customers/users. This distinction between service providers and consumers is independent of the relationship between consumer and provider which can be either client / server or peer to peer. For the service-oriented paradigm to exist, services need to be: technology neutral (their invocation mechanisms, e.g., protocols, descriptions and discovery mechanisms, should comply with widely accepted standards), loosely coupled (they must not require knowledge or any internal structures or conventions, e.g., context at the client or service side), and they must support location transparency (they can have their definitions and location information stored in a repository and be accessible by a variety of clients that can locate and invoke the services irrespective of their location). Web Services are the current most promising technology based on the concept of Service Oriented Computing [Weerawarana 2005]. A Web service is a service available via a network such as the Internet that completes tasks, solves problems or conducts transactions. Web services provide the basis for the development and execution of business processes that are distributed over the network and available via standard interfaces and protocols. The eventual goal of Web services technology is to enable distributed applications that can be dynamically assembled according to changing business needs, and customized based on device and user access while enabling wide utilization of any given piece of business logic wherever it is needed. Web services form the building blocks for creating distributed applications. They rely on a set of open Internet standards, such as the Simple Object Access Protocol (SOAP) as transmission medium, the Web Services Description Language (WSDL) for service definition and the Business Process Execution Language (BPEL) [Andrews 2003] for orchestrating services. These standards allow developers to implement distributed applications using different tools provided by many different vendors to create corporate applications that join together software modules from systems in diverse organizational departments or from different enterprises. For example, an application that tracks the inventory level of parts within an enterprise can provide a useful Web service that performs simple requests, e.g., credit checking and authorization, or inventory status checking. But more importantly, Web services can also be combined and/or configured, behind the scenes and even on the fly, to perform virtually any kind of (business-related) task or transaction. In this way they can perform complete business applications that access and combine information from multiple
Fo
rP
ee
rR
2
ev
iew
8 April 2006
Page 3 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
sources, such as an insurance brokering system, a travel planner, an insurance liability computation or a package tracking system. Enterprises can thus use a single Web service to accomplish a specific business task, such as billing or inventory control or they may compose several Web services together to create a distributed e-Business application such as customized ordering, customer support, procurement, and logistical support.
Credit Service
ck it che Cred e pons it res Cred Reserve inventory
PO submission Invoice Inventory response
Inventory Service
Buyer
Billi ng n otifi catio Billi n ng s tate Shi men ppi t ng not ific Purchase Order Shipm atio ent n ack now led gem ent
Billing Service
Figure 1 A purchase order application involving interacting Web services. Figure 1 shows how a purchase order process can be developed in terms of interacting Web services involving purchase orders, credit checks, automated billing, stock updates and shipping originating from various service providers who can gradually package their offerings to create turnkey products. This purchase order involves a purchasing protocol wherein a buying organization initially creates a purchase order and sends a request for order fulfillment to a seller; the seller then after it receives a purchase order responds with either acceptance or rejection based on a number of criteria, including availability of the goods and the credit of the buyer. Submitting a purchase order using the Web can be represented as a complex set of interacting Web services. The product order example herein has been adapted from a similar example used for orchestrating Web services [Andrews 2003]. On receiving the purchase order from a buyer, the purchase order process initiates five tasks concurrently: checking the credit worthiness of the user, determining whether or not an ordered part is available in the product inventory, calculating the final price for the order and billing the customer, selecting a shipper, and scheduling the production and shipment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between these tasks. For instance, the customers creditworthiness must be ascertained before accepting the order, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfilment schedule. When these tasks are completed successfully, invoice processing can proceed and the invoice is sent to the customer. Tracking and adjusting purchase orders due to unexpected events such as the buyer initiating a purchase order change or cancellation involves a lot of coordination work. This calls for the use of reactive services. For instance, if a single event in the purchase order needs to change or is cancelled, the entire process can unravel instantly. Employing a collection of Web services that work together to adjust purchase orders for such situations creates an automated solution to this problem. In the case of a purchase order cancellation the purchase service can automatically reserve a suitable replacement product and notify the billing and inventory services of the changes. When all of these Web service interactions have been completed and the new adjusted schedule is available, the purchase order Web service notifies the customer sending her an updated invoice.
Fo
rP
Shipment Service
ee
rR
3
ev
iew
8 April 2006
Computing Surveys
Page 4 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Aim of this paper is to introduce concepts and technologies underlying the domain of Web services and to taxonomize Web services related standards and research activities in terms of their functional characteristics. For this purpose three interrelated functional layers are introduced in a conceptual architectural scheme: service foundations, service composition, and service management and monitoring. The paper is organized as follows. Section-1 introduces Web services, compares them with the concept of software-asaservice and discusses their types and broad characteristics. Section 3 introduces the concept of Service Oriented Architecture, while section-4 presents the layering of Web services technologies and standards in terms of a Web services functional stack that is founded on the layers of service foundations, service composition, and service management and monitoring. Sections 5, 6, and 7 present these layers in detail, standards that underlie them and characteristic research activities. Finally section-8 presents a summary of this paper.
Web Services Overview
As terminology is often used very loosely it is easy to confuse someone by describing a service as a Web service when it is in fact not. Consequently, it is useful to examine first the concept of software as-a-service on which Web services technology builds upon before we deconstruct its meaning.
2.1 Software-as-a-service
The concept of software-as-a-service appeared first with the ASP (Applications Service Provider) software model. Application Service Providers are companies that package software and infrastructure elements together with business and professional services to create a complete solution that they present to the end customer as a service on a subscription basis. An ASP is a third party entity that deploys, hosts and manages access to a packaged application and delivers software-based services and solutions across a network to multiple customers across a wide area network. Applications are delivered over networks on a subscription or rental basis. The basic idea behind an ASP is to rent applications to subscribers. The whole application is developed in terms of the user interface, workflow, business and data components that are all bound together to provide a working solution. An ASP hosts the entire application and the customer has little opportunity to customize it beyond set up tables, or perhaps the final appearance of the user interface (such as, for example, adding company logos). Access to the application for the customer is provided simply via browsing and manually initiated purchases and transactions occur by downloading reports. This activity can take place by means of a browser. This is not a very flexible solution but offers considerable benefits in terms of deployment providing the customer is willing to accept it as is. Although the ASP model introduced the concept of software-as-a-service first, it suffered from several inherent limitations such as the inability to develop highly interactive applications, inability to provide complete customizable applications and inability to integrate applications [Goepfert 2002]. This resulted in monolithic architectures, highly fragile, customer-specific, non-reusable integration of applications based on tight coupling principles. The Web services paradigm allows the software-as-a-service concept to expand to include the delivery of complex business processes and transactions as a service, while permitting that applications are constructed on the fly and services to be reused everywhere and by any kind of client application. The use of Web services provides a more flexible solution. The core of the application the business and data components remain on the ASPs machines, but are now accessed programmatically via Web service interfaces. The customers can therefore build their own custom business processes and user interfaces, and are also free
Fo
rP
ee
rR
4
ev
iew
8 April 2006
Page 5 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
to select from a variety of Web services that are available over the network and satisfy their needs.
2.2 Definition of Web Services

At this stage a more complete definition of a Web service can be given. A Web service is a platform-independent, loosely coupled, self-contained programmable Web-enabled application that can be described, published, discovered, coordinated and configured using XML artefacts for the purpose of developing distributed interoperable applications. Web services possess the ability to engage other services in a common computation in order to: complete a task, conduct a business transaction, or solve a complex problem, and expose their features programmatically over the Internet (or intra-net) using standard Internet languages and protocols like XML, and can be implemented via a self-describing interface based on open Internet standards.
Two important characteristics of Web services merit further discussion. These are loose coupling and the semantic encapsulation of discrete functionality. Web services interact with one another dynamically and use Internet standard technologies, making it possible to build bridges between systems that otherwise would require extensive development efforts. Traditional application design depends upon a tight interconnection of all subsidiary elements, often running in the same process. The complexity of these connections requires that developers thoroughly understand and have control over both ends of the connection; moreover, once established, it is exceedingly difficult to extract one element and replace it with another. As opposed to tight coupling principles that require agreement and shared context between communicating systems as well as sensitivity to change, loose coupling requires a much simpler level of coordination and allow for more flexible reconfiguration. A Web service is a self-contained software module that performs a single task. The module describes its own interface characteristics, i.e., the operations available, the parameters, data-typing and the access protocols, in a way that other software modules can determine what it does, how to invoke its functionality, and what result to expect in return. In this regard, Web services are contracted software modules as they provide publicly available descriptions of the interface characteristics used to access the service so that potential clients can bind to it. The service client uses a Web services interface description to bind to the service provider and invoke its services. Services are described in terms of a description language, e.g., WSDL, that provides functional as well as non-functional characteristics (see section-5.2). Functional characteristics include operational characteristics that define the overall behavior of the service while non-functional characteristics include service availability, reliability, scalability, security, authorization, authentication, (transactional) integrity, performance characteristics, e.g., speed or accuracy, timeliness information as well as payment schemes on a Finance it, Lease it, Pay for it or Pay per use basis.
Fo
rP
ee
rR
ev
iew
2.3
Types of Web services
Services can vary in function from simple requests (for example, currency conversion, credit checking and authorization, inventory status checking, or a weather report) to complex systems that access and combine information from multiple sources, such as an insurance brokering system, a travel planner, an insurance liability computation, or a package tracking
8 April 2006
Computing Surveys
Page 6 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
system. Topologically, Web services can come in two flavors: simple informational services and complex services. Informational, or type I, Web services support only inbound operations. As such they always wait for a request, process it and respond. This type is very common and is generally stateless. Complex, or type II Web services implement some form of coordination between inbound and outbound operations and are almost always statefull, see Figure 2.
Informational services are services of relatively simple nature, they either involve simple request/response sequences between interacting services thus providing access to content (content services) or they expose back-end business applications to other applications located outside the firewall (business process services). They can also provide a seamless aggregation of information across disparate systems and information sources, including back-end systems, giving programmatic access to a business service so that the requester can make the best decisions. Such service requests may have complicated realizations. Consider for example, pure business services, such as logistic services, where automated services are the actual front-ends to fairly complex physical organizational business processes. Generally, these services are offered by a third-party and run the whole range from commerce-enabling services, such as logistics, payment, fulfillment, and tracking services, to other value-added commerce services, such as rating services. The exposed programmatic services are discrete in nature, exhibit normally a request/reply mode of operation and are of fine granularity, i.e., they can be viewed as atomic (or singular) operations. The clients of these services can assemble them to build new applications. Informational services are singular in that they perform a complete unit of work that leaves its underlying data stores in a consistent state. However, they are not transactional in nature (although their back-end realizations may be). An informational service does not keep any memory of what happens to it between requests. In that respect this type of service is known as a stateless Web service. Informational and simple trading services require support by the three evolving standards: (i) Service description (WSDL), (ii) Service Publication and Discovery (UDDI) and (iii) Communication Protocol (SOAP), all described in section-5. The key limitations of informational services (including simple trading services) are that they do not define any standards for business collaboration, process definition or security over the Web. Enterprises can use a singular (discrete) service to accomplish a specific business task, such as billing or inventory control or they may compose several services together to create a complex service (typically a business process) such as customized ordering, customer support, procurement, and logistical support. Complex services are collaborative in nature and some of them may require transactional functionality. Consider for instance a secure
Fo
Figure 2 High-level view of informational and complex services.
rP
ee
rR
6
ev
iew
8 April 2006
Page 7 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
supply-chain marketplace application where buyers and suppliers collaborate and compete for orders and the fulfillment of those orders. Numerous document exchanges will occur in this process including requests for quotes, returned quotes, purchase order requests, purchase order confirmations, delivery information and so on. Long running transactions and asynchronous messaging will occur, and business conversation and even negotiations may occur before the final agreements are reached. Complex services exhibit coarse-grained functionality and are stateful. A stateful Web service maintains some state between different operation invocations issued by the same or different Web service clients. Typically, business processes specify stateful interactions involving the exchange of messages between partners, where the state of a business process includes the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners. Complex Web services, just like informational services, require the support of standards such as SOAP, WSDL and UDDI, however, they also require emergent standards for specifying business processes and associated XML messages and content and a standard business terminology. The complex Web services standards are still evolving and are converging on SOAP, WSDL, UDDI, WS-MetaDataExchange (flexible interface to allow service endpoints to provide meta-data information to requesters and support the boostraping of Web service interactions) for and the Web Services Business Process Execution Language (BPEL), see section-5. Both simple and complex Web services can also be categorized according to the way they are programmed in applications. Some Web services exhibit programmatic behavior whereas others exhibit mainly interactive behavior where input has to be supplied by the user. This makes it natural to distinguish between the following two types of Web services: 1. Programmatic Web services: Programmatic Web services encapsulate a programmatic business processes and expose the business logic functionality of the applications and components that underlie them. Programmatic business services expose function calls, typically written in programming languages such as Java/EJB, Visual Basic or C++. Applications access these function calls by executing a Web service through standard WSDL programmatic interface. The exposed programmatic services perform a requestresponse type of business task and return a concrete result, in this sense they can be viewed as atomic operations. An example typical of programmatic behavior could be an inventory checking function of an inventory management system, which is exposed as a Web service accessible to applications via the Internet. The inventory checking Web service can then be invoked by a create order service that also uses a create purchase order Web service from an order entry system to create orders, if the inventory is available. 2. Interactive Web services: these expose the functionality of a Web applications presentation (browser) layer. They expose a multi-step Web application behavior that combines a Web server, an application server and underlying database systems and typically deliver the application directly to a browser. Clients of these Web services can incorporate interactive business processes into their Web applications, presenting integrated (aggregated) applications from external service providers. Obviously these two types of Web services can be combined delivering, thus, business processes that combine typical business logic functionality with Web browser interactivity. We may distinguish between two programming styles for services: synchronous or remote procedure call (RPC)-style versus asynchronous or message (document)-style. Synchronous services: Clients of synchronous services express their request as a method call with a set of arguments, which returns a response containing a return value. This
Fo
rP
ee
rR
7
ev
iew
8 April 2006
Computing Surveys
Page 8 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
implies that when a client sends a request message, it expects a response message before continuing with its computation. Because of this type of bilateral communication between the client and service, RPC-style services require a tightly coupled model of communication between the client and service provider. RPC-style Web services are normally used when an application exhibits the following characteristics: The client invoking the service requires an immediate response. The client and service work in a back-and-forth conversational way. The service is typically data-oriented.
Examples of typical simple information services with an RPC-style include returning the current price for a given stock; providing the current weather conditions in a particular location; or checking the credit rating of a potential trading partner prior to the completion of a business transaction. Asynchronous services: Asynchronous services are document-style or message driven services. When a client invokes a message-style service, the client typically sends it an entire document, such as a purchase order, rather than a discrete set of parameters. The service accepts the entire document it processes it and may or may not return a result message. A client that invokes an asynchronous service does not need to wait for a response before it continues with the remainder of its application. The response from the service, if any, may arrive any time later. Asynchronous services promote a looser coupling between the client and service provider, as there is no requirement for a tightly coupled request-response model between the client and the Web service. Document-style Web services are normally used when an application exhibits the following characteristics: The client does not require (or expect) an immediate response. The service is process-oriented.
Examples of document-style Web services include processing a purchase order; responding to a request for quote order from a customer; or responding to an order placement by a particular customer. In all these cases, the client sends an entire document, such as a purchase order, to the Web service and assumes that the Web service is processing it in some way, but the client does not require an immediate answer.
2.4 Quality of Service
For a Web service to function properly it must include a description of both its operational characteristics, which determine its overall behavior, as well as well as a description of its non-functional characteristics. Non-functional characteristics of a service concentrate predominantly on describing the environment hosting the Web service. Each service hosting environment may offer various choices of qualities of service based on technical requirements regarding demands for around-the-clock levels of service availability, performance and scalability, security and privacy policies and so on, all of which must be described. It is thus obvious that the quality of service offered by a Web service is becoming the utmost priority for service providers and their customers. Improvements in network infrastructure and support, coupled with increasing internal performance expectations, have pushed organizations to more stringently tie financial benefit to the quality of service (QoS) delivered. In the Web services context, QoS can be viewed as providing assurance on a set of quantitative characteristics. These can defined on the basis of important functional and nonfunctional service quality properties that include implementation and deployment issues as well as other important service characteristics such as service metering and cost, performance metrics (e.g., response time), security requirements, (transactional) integrity, reliability, scalability, and availability. These characteristics are necessary requirements
Fo
rP
ee
rR
8
ev
iew
8 April 2006
Page 9 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
understand the overall behavior of a service so that other applications and services can bind to it and execute it as part of a business process. The key elements for supporting QoS in a Web services environment are partly based on [Mani 2002] and include availability (absence of service downtimes), accessibility (the degree with which a Web service request is served) conformance to standards, integrity (the degree with which a Web service performs its tasks according to its WSDL description as well as conformance with service-level agreement), performance (measured in terms of two factors: throughput and latency), reliability (expressed in terms of number of transactional failures per month or year), scalability, and security (authentication, authorisation, message integrity and confidentiality). There are several cases where Web services require transactional behavior and context propagation. The fact that a particular Web service requires transactional behavior is described in its accompanying Service Level Agreement, and service providers must maintain this property. As organizations depend on business units, partners, and external service providers, to furnish them with services, they rely on the use a service level agreements to ensure that the chosen service provider delivers a guaranteed level of service quality. A Service Level Agreement is a formal agreement (contract) between a provider and client, formalizing the details of a Web service (contents, price, delivery process, acceptance and quality criteria, penalties and so on, usually in measurable terms) in a way that meets the mutual understandings and expectations of both the service provider and the service requester. Both service providers and clients alike need to utilise SLAs in order to work well together. Thus, an SLA is an important and widely used instrument in the maintenance of service provision relationships. The metrics imposed by SLAs should correlate with the overall objectives of the services being provided. Thus an important function that an SLA accomplishes is addressing QoS at the source. This refers to the level of service that a particular service provides [Mani 2002]. To address such concerns, the evolving Web services suite of standards supports a standard policy framework that makes it possible for developers to express the policies of services and for Web services to understand policies and enforce them at runtime. The Web Services Framework (WS-Policy) [WS-Policy 2003] assists this undertaking by providing building blocks that may be used in conjunction with other Web service and application-specific protocols to assist in expressing, exchanging and processing the policies governing the interactions between Web services endpoints (see section-6.5).
2.5 Service Interfaces and Component Implementations

Services are intended to represent meaningful business functionality that can be assembled into a larger and new configurations depending on the need of particular kinds of users particular client channels. A business process can be composed of finer-grained services that need to be supported by infrastructure services and management services such as those providing technical utility such as logging, security, or authentication, and those that manage resources. To a service client is irrelevant whether the services are provided by a fine-grained suite of components, or a single monolithic ERP. However, it is important that the developer who implements the service still thinks about granularity so they can change parts of the implementation with the minimum of disruption to other components, applications and services. The granularity of components should be the prime concern of the developer responsible for providing component implementations for services, whereas service designers should be more interested in the process operations and assembly potential of the provided services. Service design and development is about identifying the right services, organizing them in a manageable hierarchy of composite services (smaller grained often supported larger grained), choreographing them together for supporting a business process.
Fo
rP
ee
rR
9
ev
iew
8 April 2006
Computing Surveys
Page 10 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Classifying business processes into logical service domains reduces the number of business processes and services that need to be addressed. This gives raise to the concept of a service domain, also referred to as business domain, which is a functional domain comprising a set of current and future business processes that share common capabilities and functionality and can collaborate with each other to accomplish a higher-level business objective, e.g., loans, insurance, banking, finance, manufacturing, human resources, etc. In this way a business can be partitioned into a set of disjoint domains. Such domains can be leveraged from multiple architectural reasons such as load balancing, access control, and vertical or horizontal partitioning of business logic. Figure-3, shows that a service domain such as distribution is subdivided into higher-level business processes (service aggregations) such as purchasing, order management and inventory. In this figure, an order management business process, which we shall use as a running example throughout the paper, performs order volume analysis, margin analysis, sales forecasting and demand forecasting across any region, product or period. It can also provide summary and transaction detail data on order fulfillment and shipment according to item, sales representative, customer, warehouse, order type, payment term, and period. Furthermore, it can track order quantities, payments, margins on past and upcoming shipments, and cancellations for each order. The order management process in Figure-3 is shown to provide business services (singular, i.e., discrete services) for creating, modifying, suspending, canceling, querying orders, and scheduling order activities. Business services can also create, modify, and delete bulk orders and order activities, while customers be informed of the progress of an order and its order activities. Business services in the order management process are used to create and track orders for a product, a service or a resource, and is used to capture the customer-selected service details. Information that is captured as part of an order may include customer account information, product offering and quality of service details, SLA details, access information, scheduling information, and so forth. Business services and business processes distinguish between an interface and implementation part. The interface part defines the visible service functionality, i.e., the operations available, the parameters, data-typing and the access protocols, in a way that other software modules can determine what the service does, how to invoke its functionality, and what result to expect in return. The implementation realizes the interface typically using component-based development. Service realization may be provided by a software package, e.g, an ERP package, a special purpose built component, a commercial off the shelf application (COTS), or a legacy application. The implementation details are hidden from the users of the service. Different service providers using any programming language of their choice may implement the same interface. One service implementation might provide the functionality itself directly, while another service implementation might use a combination of other services to provide the same functionality. Business services are supported by infrastructure, management and monitoring services. These services provide the infrastructure enabling the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often considered as part of the Enterprise Service Bus [Chappell 2004], [Papazoglou 2006b], see section-5.6. This layer also provides the capabilities required for enabling the development, delivery, maintenance and provisioning of services as well as capabilities that monitor, manage, and maintain QoS such as security, performance, and availability. It also provides services that monitor the health of SOA applications, giving insights into the health of systems and networks, and into the status and behavior patterns of applications making them thus more suitable for mission-critical computing environments. Monitoring services implement all important standards implementations of WS-Management (see section-7) and other relevant protocols and standards such as WS-Policy (see section-6.5).
Fo
rP
ee
rR
10
ev
iew
8 April 2006
Page 11 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Figure 3 Processes, service interfaces and componentg realizations. All service domains, business processes and services are automatically populated with financial and operational functions and data available from resources such as Enterprise Resource Planning systems, databases, Customer Resource Management and other enterprise systems, which lie at the bottom of the service lifecycle development hierarchy and which implement the business services. We may collectively think of the service domain, business processes and business services sections as comprising the logical part of the Web services development life cycle, while we may think of the infrastructure services, the component-based realizations, and the operational systems sections as comprising the physical part of the Web services development life cycle [Papazoglou 2006c]. The physical part involves a realization strategy that needs to choose from an increasing diversity of different options for implementing services, which may be mixed in various combinations including [Papazoglou 2006c]: in house service design and implementation, purchasing/leasing/paying for services, outsourcing service design and implementation, using wrappers and/or adapters to access non-component implementations for services, which may include database functionality or legacy software accessed.
Fo rP ee rR ev iew
3 The Service-Oriented Architecture
Key to the concept of using Web services as the constructs to support the development of rapid, low-cost and easy composition of distributed applications is the Service-Oriented Architecture (SOA). SOA is a logical way of designing a software system to provide services to either end-user applications or other services distributed in a network through published and discoverable interfaces. An SOA builds on the Web services baseline specifications of Copyright Michael P. Papazoglou 11 8 April 2006
Computing Surveys
Page 12 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
SOAP, WSDL, and UDDI that are examined in section-5. The main building blocks of the Web services architecture are determined on the basis of the roles of service providers, service registries and the service requesters (or clients). The basic SOA defines an interaction between software agents as an exchange of messages between service requesters (clients) and service providers. Clients as usual request the execution of a service while providers are software agents that provide the service and are responsible for publishing a description of the service(s) they provide. From an architectural perspective the provider is the platform that hosts and controls access to the service. The Web services provider is responsible for publishing the Web services it provides in a service registry hosted by a service broker. This involves describing the business, service and technical information of the Web service and registering that information with the Web service registry in the format prescribed by the discovery agency. The Web service requester searches the service registry for the desired Web services. This effectively means discovering the Web service description in a registry provided by a discovery agency and using the information in the description to bind to the service. Agents can be simultaneously both service clients and providers. This approach is particularly applicable when multiple applications running on varied technologies and platforms need to communicate with each other. In this way, enterprises can mix and match services to perform business transactions with minimal programming effort.
Discovering Web services involves querying the registry of the discovery agency for Web services matching the needs of a Web service requester. A query consists of search criteria such as type of service, preferred price range, what products are associated with this service, with which categories in company and product taxonomies is this Web service associated as well as other technical characteristics and is executed against the Web service information in the registry entered by the Web service provider. The find operation can be involved in two different instances by the requester. Statically at design time to retrieve a services interface description for program development. Dynamically (at run-time) to retrieve a services binding and location description for invocation. For an application to take advantage of the Web service interactions between the three roles in the SOA three primary operations must take place. These are publication of the service descriptions, finding the service descriptions and binding or invocation of services based on their service description. These three basic operations can occur singly or iteratively and are shown in Figure 4, which represents logical view of the service-oriented architecture. This figure illustrates the relationship between the three roles and the three operations. First, the Web service provider publishes its Web service(s) with the discovery agency. Next, the Web service requester searches for desired Web services using the registry of the discovery agency. Finally, the Web service requester, using the information obtained from
Fo
rP
Figure 4 Web service roles and operations.
ee rR ev iew
12 8 April 2006
Page 13 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
the discovery agency, invokes (binds to) the Web service provided by the Web service provider [Boubez 2000]. The final operation in the Web service architecture is the actual invocation of the Web service. During the binding operation the service requester invokes or initiates an interaction at run-time using the binding details in the service description to locate and contract to the service. The technical information entered in the registry by the Web service provider is used here.
Web Services Technology Stack
The minimum infrastructure required by the Web services paradigm is purposefully low to help ensure that Web services can be implemented on and accessed from any platform using any technology and programming language. By intent, Web services are not implemented in a monolithic manner, but rather represent a collection of several related technologies. Web services lean on a functionality stack containing technologies and standards that can be layered in accordance with the planes of the extended Service Oriented Architecture (xSOA) [Papazoglou 2003], [Papazoglou 2005a]). Objective of these functional layers is to provide facilities for ensuring consistency across the organization, high availability of services, security of non-public services and information, orchestration of multiple services as part of mission-critical composite applications all essential requirements for businessquality services.
The architectural layers in the Web services functionality stack, depicted in Figure 5, describe a logical separation of functionality in such a way that each layer defines its own a set of constructs, roles and responsibilities and leans on the constructs of its preceding layer to accomplish its mission. The logical separation of functionality is based on the need to separate basic service capabilities provided by a services middleware infrastructure and SOA from more advanced service functionality needed for dynamically composing (integrating)
Fo
rP
Figure 5 The Web services functionality stack.
ee rR ev iew
13 8 April 2006
Computing Surveys
Page 14 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
services and the need to distinguish between the functionality for composing services from that of the management of services and their underlying infrastructure. As shown in Figure 5, the Web services functionality stack has three planes the foundational, the composition and the management and monitoring layer. The foundational layer defines basic Web services communication and utilizes the basic service middleware and architectural constructs and functionality for describing, publishing discovering services, which are widely accepted and are implemented quite uniformly. Higher-level layers are layered on top of the foundational layer and define strategic aspects of business processes and the management and monitoring of Web services based processes and applications. The perpendicular axis in Figure-5 designates service characteristics that cut across all three planes. These include semantics, non-functional service properties and QoS. The Web services functionality stack is shown to define several roles. In addition to the classical roles of service client and provider it also defines the roles of service aggregator and service operator, which will be explained later in this paper. In the remainder of this paper we shall introduced each plane from a technology, state of the art and scientific challenges standpoint. From the technology standpoint a comprehensive review of state of the art, standards, and current research activities in each key area will be provided.
Fo
rP
Web Services Foundation Layer
The service foundations plane provides a service oriented middleware backbone that realizes the runtime SOA infrastructure that connects heterogeneous components and systems, and provides multiple-channel access to services, e.g., via mobile devices, palm tops, hand held devices, over variety of networks including the Internet, cable, UMTS, XDSL, Bluetooth, and so on. This runtime infrastructure allows to define the classical SOA functions involving communication, the description, publishing, finding and binding of services. Four sets of standards implement the basic service functions. These are SOAP, WSDL, UDDI and WS-MetaDataExchange. We shall first examine the basic service interactions followed by the Enterprise Service Bus, a services backbone that realizes the services runtime environment and infrastructure.
ee
rR
ev
5.1
Web Services Communication
To address the problem of overcoming proprietary systems running on heterogeneous infrastructures, Web services rely on SOAP, an XML-based communication protocol for exchanging information between computers regardless of their operating systems, programming environment, or object model framework. SOAP is defined as lightweight protocol for exchange of structured and typed information between computers and systems in decentralized and distributed environment such as the Internet or even a LAN [Cauldwell 2001]. SOAP provides a wire protocol that specifies how service-related messages are structured when exchanged across the Internet. SOAP is a lightweight protocol that allows applications to pass messages and data back and forth between disparate systems in a distributed environment enabling remote method invocation. By lightweight we mean that the SOAP protocol possesses only two fundamental properties: sending and receiving HTTP (or other) transport protocol packets, and processing XML messages. Although SOAP may use different protocols such as HTTP, FTP or RMI to transport messages and locate the remote system and initiate communications, its natural transport protocol is HTTP. Layering SOAP over HTTP means that a SOAP message is sent as part of an HTTP request or response, which makes it easy to communicate over any network that permits
iew
14
8 April 2006
Page 15 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
HTTP traffic. SOAP uses the HTTP protocol to transport XML-encoded serialized method argument data from system to system. Serialization is the process of converting application data to XML. XML is then a serialized representation of the application data. The process of generating application data from XML is called deserialization. SOAPs serialization mechanism converts method calls to a form suitable for transportation over the network, using special XML tags and semantics. The serialized argument data is used on the remote end to execute the clients method call on that systems, rather than on the clients local system. The basic requirement for an Internet node to play the role of requester or provider in XML massaging-based distributed computing is the ability to construct and parse a SOAP message and the ability to communicate over the network by sending and receiving messages. Any SOAP runtime system executing in a Web application server performs these functions. The current SOAP specification describes how the data types defined in associated XML schemas are serialized over HTTP or other transport protocols. Both the provider and requester of SOAP messages must have access to the same XML schemas in order to exchange information correctly. The schemas are normally posted on the Internet, and may be downloaded by any party in an exchange of messages. A SOAP message contains a payload, the application specific information it delivers. Every SOAP message is essentially an XML document. SOAP messages consist of three basic parts: an envelope that defines a structure for describing the content and processing of a message; a header, which allows defining a set of encoding rules for expressing instances of application-defined data types; and a body, which is a structure for representing remote procedure calls and responces. The SOAP envelope serves to wrap any XML document interchange and provide a mechanism to augment the payload with additional information that is required to route it to its ultimate destination. The SOAP envelope contains a header and a body. The header contains processing or control information on how a message recipient should process the message. In this way an XML document can express meaningful information about a service, such as authentication or transaction control-related information, as well as quality of service, billing or accounting information regarding an application. The SOAP body is the area of the SOAP message where the application specific XML data (payload) being exchanged in the message is placed. The SOAP <body> is where the method call in formation and its related arguments are encoded. It is where the response to a method call is placed, and where error information can be stored. The Web services communication model describes how to invoke Web services and relies on SOAP. SOAP supports two possible communication styles: remote procedure call (RPC) and document (or message), described in section 2.4.
Fo
rP
ee
rR
ev
iew
5.2
Web Services Description
A SOAP service would require some documentation explaining the operations exposed along with their parameters in a machine-understandable standard format. In the Web services context, this is provided by employing a document expressed in Web Services Description Language (WSDL). WSDL is the service representation language used to describe the details of the complete interfaces exposed by Web services and thus is the means to accessing a Web service. It is through this service description that the service provider can communicate all the specifications for invoking a particular Web service to the service requester. WSDL provides a mechanism by which service providers can describe the basic format of Web requests over different protocols (e.g., SOAP) or encoding (e.g., Multipurpose Internet Messaging Extensions or MIME). WSDL is an XML based specification schema for describing
15
8 April 2006
Computing Surveys
Page 16 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
the public interface of a Web service. This public interface can include operational information relating to a Web service such as all publicly available operations, the XML message protocols supported by the Web service, data type information for messages, binding information about the specific transport protocol to be used, and address information for locating the Web service. WSDL allows the specification of services in terms of XML documents for transmission under SOAP. A WSDL document describes how to invoke a service and provides information on the data being exchanged, the sequence of messages for an operation, protocol bindings, and the location of the service. WSDL represents a contract between the service requester and the service provider. The WSDL specification can be conveniently divided into two parts: the service interface definition (abstract interface) and the service implementation (concrete endpoint): The service-interface definition describes the general Web service interface structure. This contains all the operations supported by the service, the operation parameters and abstract data types. The service implementation part binds the abstract interface to a concrete network address, to a specific protocol and to concrete data structures. A Web service client may bind to such an implementation and invoke the service in question.
Fo
This distinction enables each part to be defined separately and independently, and reused by other parts. The Web service interface definition describes messages and operations in a platform and language independent manner. It describes exactly what types of messages need to be sent and how the various Internet standard messaging protocols and encoding schemes can be employed in order to format the message in a manner compatible with the service providers specifications. A service interface definition is an abstract service description that can be instantiated and referenced by multiple concrete service implementations. The service interface contains the WSDL elements that comprise the reusable portion of the service description, these include: the <types>, <message>, <part>, < operation> and < portType> elements. These are briefly summarized below. Any complex data type that the service uses must be defined in an optional <types> section immediately before the <message> section. The <types> section describes the data types for exchange between the client and the service. Messages in WSDL are abstract collections of typed information cast upon one or more logical units, used to communicate information between systems. A <message> element corresponds to a single piece of information moving between the invoker and the service. A regular round trip method call is modeled as two messages, one for the request and one for the response. A message can consist of one or more <part> elements with each part representing an instance of a particular type (typed parameter). When WSDL describes a software module, each part maps to an argument of a method call. The WSDL <portType> element describes the interface of a Web service. It is simply a logical grouping of operations. The <portType> is used to bind the collection of logical operations to an actual transport protocol such as SOAP, providing thus the linkage between the abstract and concrete portions of a WSDL document. In WDL <portType>s contain <operation>, which represent the various methods being exposed by the service. An operation defines a method on a Web service, including the name of the method and the input and output parameters. A typical operation defines the input and output parameters or exceptions (faults) of an operation. Figure 6 shows an excerpt of a WSDL interface definition describing a purchase order service. This service takes a purchase order number, a date and customer details as input and returns an associated invoice. The WSDL example in Figure 6 defines a Web service
rP
ee
rR
16
ev
iew
8 April 2006
Page 17 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
that contains a <portType> named PurchaseOrderPortType that supports a single <operation>, which is called SendPurchase. The example assumes that the service is deployed using the SOAP 1.1 protocol as its encoding style, and is bound to HTTP.
The <operation> element SendPurchase in the listing above will be called using the message POMessage and will return its results using the message Inv(oice)Message. Operations can be used in a Web service in four fundamentals patterns: request/response, solicit/response, one-way and notification. The operation SendPurchase is a typical example of a request/response style of operation as it contains an input and an output message. The service implementation part of WSDL contains the elements <binding> (although sometimes this element is considered as part of the service definition) <port> and <service> and describes how a particular service interface is implemented by a given service provider. The service implementation describes where the service is located, or more precisely, to which network address the message must be sent in order to invoke the Web service. In WSDL a <binding> element contains information of how the elements in an abstract service interface (<portType> element) are converted into concrete network protocol such as SOAP or HTTP. The WSDL <binding> element defines how a given operation is formatted and bound to a specific protocol. If there are many operations then they will be multiple bindings. A <port> specifies the address for a binding, thus defining the location of a service, or service endpoint. If there are multiple bindings, there will be multiple endpoints. A <service> element contains a collection of WSDL <port> elements. Simple services with only one operation, will have only one endpoint. Each <service> element is named, and each name must be unique among all services in a WSDL document.
Fo rP
Figure 6 Simple WSDL interface definition.
ee rR ev iew
17 8 April 2006
Computing Surveys
Page 18 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
5.3
UDDI: Universal Description, Discovery, and Integration
The Universal Description, Discovery and Integration (UDDI) specification was created to identify potential trading partners and cataloguing their business functions and characteristics. UDDI offers a standard infrastructure to classify, catalogue and manage Web services to enable Web services discovery and consumption. UDDI is designed for use by developer tools and applications that use Web services standards such as SOAP/XML and WSDL. Through UDDI, enterprises can publish and discover information about other businesses and the services they provide. This information can be classified using standard taxonomies so that information can be discovered on the basis of categorization. UDDI contains also information about the technical interfaces of an enterprises services. The UDDI XML schema defines five core types of information that provide the white/yellow/green page functionality. The UDDI data model hierarchy and the key XML element names that are used to describe and discover information about Web services are shown in Figure 7. The entity types in the UDDI data model are as follows: businessEntity: describes a business or any other organization that provides Web services. The <businessEntity> construct is a top-level structure that corresponds to white page description of a company. businessService: describes a collection of related Web services offered by an organization described by a <businessEntity> construct. The <businessService> structure is used to group a series of related Web services related to either a business process or category of services. The kind of information contained in a <businessService> element maps to the yellow pages information about a company. bindingTemplate: The access information required to actually invoke a service is described in the information element named <bindingTemplate> which exposes a service endpoint address required for accessing a service from a technical point of view. Technical descriptions of Web services the green pages data -- reside within sub-structures of the <businessService> element. tModel: Each <bindingTemplate> data type contains a special <tModel> data structure that provides information about a Web service interface specification. The <tModel> data structure describes a technology model representing a reusable concept, such as a Web service type, a protocol used by Web services, or a category system. publisherAssertion: defines relationships between pairs of <businessEntity> structures. Two (or more) related enterprises may use the <publisherAssertion> structure to publish assertions of business relationships. The UDDI, just like WSDL, draws a sharp distinction between abstraction and implementation. In fact, the primary role that a <tModel> plays is to represent technical information about an abstract interface specification. Due to the fact that both the UDDI and WSDL schema have been architected to delineate clearly between interface and implementation, these two constructs are quite complementary work together naturally. The WSDL-to-UDDI mapping model is designed to help users find services that implement standard definitions. The WSDL-to-UDDI mapping model describes how WSDL <portType> and <binding> element specifications can become <tModel>s; how the <port>s of WSDL become UDDI <bindingTemplate>s; and how each WSDL service is registered as a <businessService> [Manes 2003].
Fo
rP
ee
rR
18
ev
iew
8 April 2006
Page 19 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
UDDI uses SOAP as its transport layer, thus enterprises can interact with UDDI registries through SOAP-based XML API calls in order to discover technical data about an enterprises services. In this way enterprises can link up with service providers and invoke and use their services. The UDDI specifications allow enquiries and publishing APIs to interact with UDDI registered sites. Enquiries enable parties to find business businesses, services, or bindings (technical characteristics) meeting certain criteria. UDDI sites use publishing functions to manage the information provided to requestors. The publishing API essentially allows applications to save and delete the five data structures supported by UDDI and described earlier. These calls are used by service providers and enterprises to publish and un-publish information about themselves in the UDDI registry.
businessEntity: Information about the businessEntity: Information about the party who publishes information about a party who publishes information about a family of services. family of services.
tModel: Descriptions of specifications tModel: Descriptions of specifications for services or taxonomies. Basis for for services or taxonomies. Basis for technical fingerprints. technical fingerprints.
businessService: Descriptive businessService: Descriptive information about a particular information about a particular service. service. bindingTemplate data contains references to tModels. These references designate the interface specifications for a service.
PublisherInsertion: Information PublisherInsertion: Information about a relationship between two about a relationship between two parties, asserted by one or both. parties, asserted by one or both.
5.4 Web Services Meta-data and Semantics

For Web services to interact properly with each other as part of composite applications that perform more complex functions by orchestrating numerous services and pieces of information, the requester and provider entities must agree both on the service description (WSDL definition) and semantics that will govern the interaction between them. To surmount semantic interoperability problems Web services make use of resource-based metadata to describe what service endpoints need to know to interact with each other. This kind of metadata is used to associate specific properties and their values with whatever the metadata is about. For example, a meta-data record for a manufactured product, giving its name, serial number, weight, production date and so on. Metadata describing a service typically contain descriptions of the interfaces of a service the kinds of data entities expected and the names of the operations supported - such items as vendor identifier, narrative description of the service, Internet address for messages, format of request and response messages, and may also contain choreographic descriptions of the order of interactions. Metadata for a service should also include QoS as well as policy descriptions. Service policy metadata describe the assertions that govern the intent on the part of a participant when a service is invoked. Policies apply to many aspects of services: to security, to privacy, manageability, QoS and so forth. Such descriptions may range from simple identifiers implying a mutually understood protocol to a complete description of the vocabularies, expected behaviors and so on. Such meta-data gives high-level semantic details regarding the structure and contents of the messages received and sent by Web services, message operations, concrete network protocols, and endpoint addresses used by Web services. It also describes abstractly the capabilities, requirements, and general characteristics of Web services and how they can interoperate with other services. Web services use the Resource Description Framework (RDF) as an infrastructure that enables the encoding, exchange, and reuse of structured metadata. This infrastructure has
Fo
bindingTemplate: Technical bindingTemplate: Technical information about a service entry information about a service entry point and construction point and construction specifications. specifications.
rP
Figure 7 Overview of UDDI data structures.
ee
rR
19
ev
iew
8 April 2006
Computing Surveys
Page 20 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
been advanced as the primary enabling infrastructure of the Semantic Web activity in the W3C and enables metadata interoperability through the design of mechanisms that support common conventions of semantics, syntax, and structure. RDF uses XML as a common syntax for the exchange and processing of metadata. RDF [Klyne 2004] has provided the basis for a common approach to declaring schemas in use. RDF provides a model for describing resources on the Web. The basic RDF data model consists of three fundamental concepts: resource, properties and statements. Resources are the central concept of RDF and are used to describe individual objects of any kind, for example an entire Web service, a part of a Web service, or a whole collection of Web services. A resource may also be an object that is not directly accessible via the Web, for example, a printed book or a travel brochure. RDF defines a resource as any object that is uniquely identifiable by a Uniform Resource Identifier [Klyne 2004], [Manola 2004], which can be a Web address or some other kind of unique identifier. Resources map conceptually to entities or parts of entities. RDF Schema is used to declare vocabularies, the sets of semantics property-types defined by a particular community. RDF Schema defines the valid properties in a given RDF description, as well as any characteristics or restrictions of the property-type values themselves. The XML namespace mechanism serves to identify RDF Schemas. To understand a particular RDF schema is to understand the semantics of each of the properties in that description. RDF schemas are structured based on the RDF data model. RDF Schema refers to the metadata entities it describes as classes. A class in RDF Schema corresponds to the generic concept of a type or category, somewhat like the notion of a class in object-oriented programming languages such as Java [Manola 2004]. Figure 8 depicts such a class hierarchy for publications. This figure illustrates that there are several other classes such as ex:Article, ex:WhitePaper, ex:NewsItem which are all specializations of class ex:Publication. To indicate that these classes are also specialized classes of the class ex:Publication, the predefined <dfs:subClassOf> property is used to associate the specialized classes with ex:Publication. This is denoted by dotted lines in Figure 8. Note that the resource <rdfs:Class> itself has an <rdf:type> of <rdfs:Class>. Moreover, RDF makes use of multiple inheritance to allow a resource to be an instance of more than one class, e.g., the class NewsArticle in Figure 8. The expressivity of RDF and RDF Schema is deliberately restricted. RDF is limited to binary ground predicates, and RDF Schema is limited to a subclass hierarchy and a property hierarchy, with domain and range definitions of these properties. The Web Ontology Working Group (http://www.w3.org/2001/sw/WebOnt) identified a number of characteristic use-cases for the Semantic Web, which would require much more expressiveness than RDF and RDF Schema. Some of the richer schema capabilities that have been identified as useful (but that are not provided by RDF Schema) include [Manola 2004]: specifying cardinality constraints on properties, specifying that a given property (such as ex:hasAncestor) is transitive, specifying that a given property is a unique identifier (or key) for instances of a particular class, specifying that two different classes (having different URIrefs) actually represent the same class, specifying that two different instances (having different URIrefs) actually represent the same individual. Moreover, specifying cardinality restrictions of a property that depend on the class of resource to which a property is applied, and the ability to describe new classes in terms of combinations (e.g., unions and intersections) of other classes, or to say that two classes are disjoint (i.e., that no resource is an instance of both classes). These capabilities, in addition to other semantic constructs, are the targets of ontology languages such as the Ontology Working Language (OWL) [Antoniou 2004], [McGuiness 2004] and the Darpa Agent Markup Language (DAML) [DAML].
Fo
rP
ee
rR
20
ev
iew
8 April 2006
Page 21 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
The OWL ontology language is based on RDF and RDF Schema and provides all the additional capabilities mentioned above. The intent of languages such as OWL is to provide additional machine-processable semantics for resources, to provide semantic foundations for situations involving dynamic discovery of businesses and services by relying on knowledge representation and reasoning techniques to represent business concepts, relationships between them and a set of rules, that is, to make representations of resources more closely mirror the semantics of their intended real world counterparts. While such capabilities are not necessarily needed to build useful applications using RDF, the development of such languages is a very active subject of work as part of the development of the Semantic Web [Manola 2004].
5.5 Web Services Meta-data Exchange
Normally, Web services are invoked by the service endpoint information that is provided by WSDL. For instance, a WSDL service port has a location address, which identifies the endpoint. This information is suitable in most cases, with the exception of stateful Web services and cases that add more dynamic information to the address (instance information, policy, complex binding, and so on) [Joseph 2004]. This requires a client or runtime system to uniquely identify a service at runtime, based on this runtime information. This bindingspecific information could include a unique identifier. Currently, there is no standard way by which this information can be exchanged and then mapped to the runtime engine while the service is accessed. The Web Services Addressing (WS-Addressing) specification tackles this problem by providing a lightweight mechanism for identifying and describing the endpoint information and mapping that information into the SOAP message headers. WS-Addressing provides transport-neutral mechanisms to address Web services and messages. WS-Addressing was introduced in order to standardize the notion of a pointer to a Web service [Graham 2004a]. It defines how message headers direct messages to a service, provides an XML format for exchanging endpoint references, and defines mechanisms to direct replies or faults to a specific location. WS-Addressing enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner. Web services use metadata to describe what other endpoints need to know to interact with them. More specifically, WS-Policy describes the capabilities, requirements, and general
Fo
Figure 8 Sample RDF schema for a hierarchy of publications.
rP
ee
rR
21
ev
iew
8 April 2006
Computing Surveys
Page 22 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
characteristics of Web services; WSDL 1.1 describes abstract message operations, concrete network protocols, and endpoint addresses used by Web services; W3C XML Schema describes the structure and contents of XML-based messages received and sent by Web services. Using WS-Addressing, WSMetadataExchange [Balinger 2004] defines a bootstrap mechanism for metadata-driven message exchange, supporting especially XML Schema, WSDL, and WS-Policy. This enables metadata message exchange through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner and makes normative use of WS-Policy [Bajaj 2004]. To bootstrap communication with Web services and to retrieve these and other types of metadata, the WS-MetadataExchange specification defines two request-response interactions. When the type of metadata sought is clearly known, e.g., WS-Policy, a requester may indicate that only that type should be returned; where additional types of metadata are being used, or are expected, or when a requester needs to retrieve all of the metadata relevant to subsequent interactions with an endpoint, a requester may indicate that all available metadata, regardless of their types, are expected. The interactions defined in WS-MetadataExchange are intended for the retrieval of metadata (i.e., service description information) only. They are not intended to provide a general purpose query or retrieval mechanism for other types of data associated with a service, such as state data, properties and attribute values, etc.
5.6 Services Run-time Environment

The requirements to provide an appropriately capable and manageable integration infrastructure for Web services and SOA are coalescing into the concept of the Enterprise Service Bus (ESB). There are two key ideas behind this approach [Graham 2005]: loosely couple the systems taking part in the integration and break up the integration logic into distinct easily manageable pieces. The Enterprise Service Bus is an open-standards based message backbone designed to enable the implementation, deployment, and management of SOA-based solutions. An ESB is a set of infrastructure capabilities implemented by middleware technology that enable an SOA and alleviate disparity problems between applications running on heterogeneous platforms and using diverse data formats. It supports service, message, and event-based interactions with appropriate service levels and manageability. In other words, the ESB provides the distributed processing, standards-based integration, and enterprise-class backbone required by the extended enterprise. The ESB is designed to provide interoperability between larger grained applications and other components via standardsbased adapters and interfaces. It functions as both transport and transformation facilitator to allow distribution of these services over disparate systems and computing environments. Conceptually, the ESB has evolved from the store-and-forward mechanism found in middleware products and now is a combination of Enterprise Application Integration, e.g., application servers and integration brokers, Web services, XSLT, and orchestration technologies [Papazoglou 2006b]. An ESB provides an implementation backbone for an SOA that treats applications as services. The ESB is about configuring applications rather than coding and hardwiring applications together. It is a lightweight infrastructure that provides plug and play enterprise functionality. The ESB is responsible for the proper control, flow and even translations of all messages between services, using any number of possible messaging protocols. An ESB pulls together applications and discrete integration components to create assemblies of services to form composite business processes, which in turn automate business functions in an enterprise. It establishes proper control of messaging as well as applies the needs of security, policy, reliability and accounting, in an SOA.
Fo
rP
ee
rR
22
ev
iew
8 April 2006
Page 23 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Once a service is deployed into a service container it becomes an integral part of the ESB and can be used by any application or service connected to it. A service container is a managed environment that hosts, manages, dynamically deploys services and binds them to external resources, e.g., data sources, enterprise and multi-platform applications, such as shown in Figure 9. Figure 9 shows a simplified view of an ESB that integrates a J2EE application using JMS, a .NET application using a C# client, an MQ application that interfaces with legacy applications, as well as external applications and data sources using Web services. An ESB, as represented in Figure 9, enables more efficient value-added integration of a number of different application components, by positioning them behind a service-oriented faade and by applying Web services technology to the problem. In Figure 9 a distributed query engine, which is normally based on XQuery or SQL, enables the creation of data services to abstract the complexity of underlying data sources. As shown in Figure 9, a primary use case for ESB is to act as the intermediary layer between a portal server and the backend data sources that the portal server needs to interact with. A portal in Figure 9 is a user-facing aggregation point of a variety resources represented as services, e.g., retail, divisional, corporate employee, and business partner portals.
Figure 9 Enterprise service bus connecting diverse applications and technologies. Endpoints in the ESB depicted in Figure 9 provide abstraction of physical destination and connection information (like TCP/IP hostname and port number) that limit the integration capabilities of traditional, tightly-coupled, distributed software components. Endpoints allow services to communicate using logical connection names, which an ESB will map to actual physical network destinations at runtime. This destination independence gives the services that are part of the ESB the ability to be upgraded, moved, or replaced without having to modify code and disrupt existing ESB applications. For instance, an existing ESB invoicing service could be easily upgraded or replaced with a new service without disrupting other applications. Additionally, duplicate processes can be set up to handle fail-over if a service is not available. Endpoints also provide the asynchronous and highly reliable communication between service containers. The endpoints can be configured to use several levels of quality of service, which guarantee communication despite network failures and outages [Chappell 2004]. To accomplish its mission, the ESB employs an event-driven approach to distributed computing whereby events trigger asynchronous messages that are then sent between
Fo
rP ee rR ev iew
23 8 April 2006
Computing Surveys
Page 24 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
independent software components that need not have any information about each other. In an ESB-enabled event-driven SOA, applications and services are treated as abstract service endpoints, which can readily respond to asynchronous events [Chappell 2005]. To achieve its functionality, the ESB must support both the established Web services technologies, e.g., SOAP, WSDL, and BPEL, as well as emerging standards such as WSReliableMessaging and WS-Notification [Graham 2004]. The Web Services Notification family of specifications brings the publish/subscribe functionality to ESB-focused current incarnations of Web services standards. The ESB draws from traditional EAI broker functionality and provides integration services such as connectivity and routing of messages based on business rules, data transformation, and adapters to applications [Chappell 2005]. These capabilities are themselves SOA based in that they are spread out across the bus in a highly distributed fashion and hosted in separately deployable service containers. This is crucial difference from traditional integration brokers which are usually heavy-weight, highly centralized and monolithic in nature [Papazoglou 2006b]. The ESB approach allows for the selective deployment of integration broker functionality exactly where it is needed with no additional over-bloating where it is not required. A successful ESB implementation relies on the ESB providing several key capabilities [Papazoglou 2006b]: Leveraging Existing Assets: the ESB allows for selective reuse of legacy systems and applications. Service Communication Capabilities: the ESB has the ability to route service interactions through a variety of protocols, and to transform from one protocol to another where necessary. Dynamic Connectivity Capabilities: the ESB has the ability to connect to Web services dynamically without using a separate static API or proxy for each service. The dynamic connectivity API is the same regardless of the service implementation protocol (Web services, JMS, EJB/RMI, etc.). Topic and content-based Routing Capabilities: the ESB facilitates not only topicbased routing but also, more sophisticated, content-based routing. Topic-based routing assumes that messages can be grouped into fixed, topical classes, so that subscribers can explicate interest in a topic and as a consequence receive messages associated to that topic. Content-based routing on the other hand, allows subscriptions on constraints of actual properties (attributes) of business events. Content based routing forwards messages to their destination based on the context or content of the service. Endpoint Discovery with Multiple Quality of Service Capabilities: the ESB is capable of supporting various qualities of service. Clients can query a Web service, such as an organizational UDDI service, to discover the best instance with which to interact based on QoS properties. Ideally, these capabilities should be controlled by declarative policies associated with the services involved using a policy standard such as the WS-PolicyFramework. Integration Capabilities: To support SOA in a heterogeneous environment, the ESB needs to integrate with a variety of systems that do not directly support service-style interactions. These may include legacy systems, packaged applications, or other enterprise application integration technologies. Transformation Capabilities: The ESB transformation services make it possible to ensure that messages and data received by any component is in the format it expects, thereby removing the need to make changes. Reliable Messaging Capabilities: the ESB supports asynchronous store-and-forward delivery as well as guaranteed delivery capabilities by means of to queuing service request messages and ensuring guaranteed delivery of these messages to their destination. Security Capabilities: the ESB requires both point-to-point (e.g., SSL encryption) and end-to-end security capabilities are required. These end-to-end security capabilities
Fo
rP
ee
rR
ev
iew
24
8 April 2006
Page 25 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
include federated authentication, validation of each service request and authorization to make sure that the sender has the appropriate privilege to access the service, and, lastly, encryption/decryption of XML content at the element level for both message requests and responses. Long Running Process and Transaction Capabilities: The ESB should provide the ability to support business processes and long running services. In addition, in order to be successful in business environments it is extremely important that the ESB should provide transactional guarantees for long running activities. Management and Monitoring Capabilities: Effective systems and application management in an ESB requires a management framework that is consistent across an increasingly heterogeneous set of participating component systems, while supporting complex aggregate (cross-component) management use cases, an additional requirement for a successful ESB implementation is the ability to monitor the health, capacity and performance of services (see section-7). Scalability Capabilities: With a widely distributed SOA, there will be the need to scale some of the services or the entire infrastructure to meet integration demands. For example, transformation services are typically very resource intensive and may require multiple instances across two or more computing nodes. At the same time, it is necessary to create an infrastructure that can support the large nodes present in a global service network.
5.7 Research Activities
To design effective SOA solutions it is desirable that service developers build selfconfiguring service architectures that can use distributed components to dynamically create an optimal service-based architectural run-time style according to particular application requirements and existing system characteristics. The grid services community has attempted to address the support of dynamically reconfigurable service architectures by directing research efforts into two categories of problems. Service specific architectures that are designed for particular classes of services/applications [Lopez 2001], [Liu 2002], [Poladian 2004]. Examples include resource selection for resource-intensive applications and resource allocation for services consisting of a set of multi-fidelity applications. Others proposed generic architectures that can compose different services using type-based architectural composition [Ivan 2002], [Ponnekanti 2002] . Components have well-defined input/output (requires/provides) interfaces, so a service composition module can automatically generate a service configuration providing the requested interface(s) all in all, the overall direction to compose applications from services is accepted in this domain too [Leymann 2005c]. Other research activities in the services foundation layer to date have targeted mostly formal service description language(s) for enhanced service definitions addressing, besides functional aspects, also behavioral as well as non-functional aspects associated with services [Deora 2003], [Ran 2003], [Deora 2004]. They have also concentrated on providing an open, modular, extensible framework for service discovery, publication and notification mechanisms across distributed, heterogeneous, dynamic (virtual) organizations as well as unified discovery interfaces and query languages for multiple pathways [Wang 2003], [Jaeger 2004], [Ding 2004], [Sahin 2005]. The AI and semantic Web community has concentrated their efforts in giving richer semantic descriptions of Web services that describe the properties and capabilities of Web services in an computer-interpretable form. Such activities target the use of formal languages for semantically describing all relevant aspects of Web services in order to facilitate the automated discovery, combination and invocation of services over the Web [Patil 2004], [Roman 2005].
Fo
rP
ee
rR
25
ev
iew
8 April 2006
Computing Surveys
Page 26 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
6 Web Services Composition Layer

The full potential of Web services as a means of developing dynamic e-Business solutions can only be realized when applications and business processes are able to integrate their complex interactions into composite added value services. Services technologies offer a viable solution to this problem since they support coordination and offer an asynchronous and message oriented way to communicate and interact with application logic. However, it is important to differentiate between the baseline specifications of SOAP, UDDI and WSDL that provide the infrastructure that supports publishing, finding and binding operations in the service-oriented architecture and higher-level specifications, which are required for Web services integration. These higher-level specifications provide functionality that supports and leverages services and enables specifications for integrating automated business processes and reside in the service composition plane. The service composition plane encompasses roles and functionality that are necessary for the aggregation of multiple services into a single composite service. Resulting composite services may be used as discrete services in further service compositions or may be offered as complete applications/solutions to service clients. Service aggregators accomplish this task. Service aggregators thus become service providers by publishing the service descriptions of the composite service they create. Service aggregators develop specifications and/or code that permit the composite service to perform functions that are based on features such as meta-data descriptions, standard terminology and reference models and service conformance. In the following we shall examine several higher-level specifications required for integrating Web services. These include business process execution languages, coordination and transactional support languages for Web services as well as facilities for expressing end-toend security requirements and policies.
6.1 Services Orchestration versus Choreography

Currently, there are competing initiatives for developing business process definition specifications, which aim to define and manage business process activities and business interaction protocols comprising collaborating services. The terms orchestration and choreography have been widely used to describe business interaction protocols comprising collaborating services. Orchestration describes how services can interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under control of a single endpoint. Orchestration refers to an executable business process that may result in a long-lived, transactional, multi-step process model. With orchestration, the business process interactions are always controlled from the (private) perspective of one of the business parties involved in the process. Currently, orchestration is targeted by a family of XML-based process standard definition languages most representative of which is the Business Process Execution Language for Web Services [Andrews 2003]. Service choreography is targeted by Web Services Choreography Description Language (WS-CDL) [Kavantzas 2004], which specifies the common observable behavior of all participants engaged in business collaboration. Choreography is typically associated with the public (globally visible) message exchanges, rules of interaction and agreements that occur between multiple business process endpoints, rather than a specific business process that is executed by a single party. Choreography is more collaborative in nature than orchestration. It is described from the perspectives of all parties (common view), and defines the complementary observable behavior between participants in business process collaboration. Choreography tracks the sequence of messages that may involve multiple parties and multiple sources, including
Fo
rP
ee
rR
26
ev
iew
8 April 2006
Page 27 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
customers, suppliers, and partners, where each party involved in the process describes the part they play in the interaction and no party owns the conversation. The sharp distinction between orchestration and choreography is rather artificial and it widely believed that they should both coalesce in the confines of a single language and environment.
6.2 Services Orchestration

Business Process Execution Language for Web Services is an XML-based flow language for the formal specification of business processes and business interaction protocols. BPEL is a language for orchestrating Web services. It describes how Web services can interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under control of a single endpoint. Service orchestrations typically require specifying sequences of peer-to-peer message exchanges between a collection of Web services within stateful, long-running interactions involving two or more parties. BPEL provides support for both executable and abstract business processes. An executable process models the actual behavior of participants in the overall business process, essentially modeling a private workflow. This can be perceived as a control meta-process that is laid on top of Webs services controlling their invocations and behavior. Abstract processes are modeled as business protocols in BPEL. Their purpose is to specify the public message exchanges of each of the parties leveraging the protocol. Unlike executable business processes, business protocols are not executable and do not reveal the internal details of a process flow. Abstract business processes link Web service interface definitions with behavioral specifications that can be used to control the business roles and define the behavior that each party is expected to perform within the overall business process. A BPEL process is a flow-chart-like expression specifying process steps and entry-points into the process that is layered on top of WSDL, with WSDL defining the specific operations allowed and BPEL defining how the operations can be sequenced [Curbera 2003]. The role of BPEL is to define a new Web service by composing a set of existing services thought a process-integration type mechanism with control language control. The entry-points correspond to external clients invoking either input-only (request) or input-output (requestresponse) operations on the interface of the composite service. In particular, a BPEL process represents parties and interactions between these parties in terms of abstract WSDL interfaces (<portTypes> and <operation>s), while no references are made to the actual services (binding and address information) used by a process instance. Both the interacting process as well as its counterparts are modeled in the form of WSDL services. Actual implementations of the services themselves may be dynamically bound to the partners of a BPEL composition, without affecting the compositions definition. Business processes specified in BPEL are fully executable portable scripts that can be interpreted by business process engines in BPEL-conformant environments. BPEL processes are exposed as a Web service using WSDL where WSDL describes the public entry and exit points for the process. In addition, WSDL data types are used within a BPEL process to describe the information that passes between requests. We distinguish five main sections in BPEL: the message flow, the control flow, the data flow, and the process orchestration sections. The message flow section of BPEL is handled by primitive activities that include invoking an operation on some Web service (<invoke>), waiting for a process operation to be invoked by some external client (<receive>), and generating the response of an inputoutput operation (<reply>).
Fo
rP
ee
rR
27
ev
iew
8 April 2006
Computing Surveys
Page 28 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
The control flow section of BPEL includes the ability to define an ordered sequence of activities (<sequence>), to have branching (<switch>), to define a loop (<while>), and to execute one of several alternative paths (<pick>). It main structured activity is the <flow> statement that allows defining sets of activities (including other flow activities) that are connected via <links>. A flow activity in BPEL may create a set of concurrent activities and enables expressing synchronization dependencies between these activities. The state of a business process includes the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners. The data flow section of BPEL requires that information is passed between the different activities in an implicit way through the sharing of globally visible data. The process orchestration section of BPEL uses service links to establish peer-to-peer partner relationships. A <partner> could be any service that the process invokes or any service that invokes the process. Each <partner> is mapped to a specific role that it fills within a process.
<process name="purchaseOrderProcess" ...> <variables> <variable name="PO" messageType="lns:POMessage"/> <variable name="Invoice" messageType="lns:InvMessage"/> ... </variables> ... <partners> <partner name="customer" serviceLinkType="lns:purchaseLT" myRole="purchaseService"/> <partner name="invoiceProvider" serviceLinkType="lns:invoiceLT" myRole="invoiceRequester" partnerRole="invoiceService"/> ... </partners>
state
Interaction points
behaviour
Figure 10 is a code snippet that shows the process flow for an abbreviated PurchaseOrder process which employs WSDL interface definitions for the purchase order service described in Figure 6. The <variables> section in Figure 10 defines the data variables used by the process, providing their definitions in terms of WSDL message types. The <partners> section defines the different parties that interact with the business process in the course of processing the order. The partners in this section correspond to the sender of the order (customer), as well as the providers of price (invoiceProvider), shipment (shippingProvider), and manufacturing scheduling services (schedulingProvider). The latter two are not shown in this figure for reasons of brevity. Each partner is characterized by a service link type and a role name. This information identifies the functionality that must be provided by the business process and by the partner for the relationship to succeed, that is, the <portType>s that the purchase order process and the partner need to implement. The structure of the main processing section is defined by the outer <sequence> element, which states that the three activities contained inside are performed in order. The customer request is received (<receive> element), then processed (inside a <flow> section not
Fo
<sequence> <receive partner="customer" portType="lns:purchaseOrderPortType" operation="sendPurchaseOrder" variable="PO"> </receive> ... <reply partner="customer" portType="lns:purchaseOrderPortType" operation="sendPurchaseOrder" variable="Invoice"/> </sequence>
</process>
Figure 10 BPEL process flow for a PurchaseOrder process.
rP
ee
rR
28
ev iew
8 April 2006
Page 29 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
shown in this figure- that enables concurrent behavior), and a reply message with the final approval status of the request is sent back to the customer (<reply>). Note that the <receive> and <reply> elements are matched respectively to the <input> and <output> messages of the sendPurchaseOrder operation1 invoked by the customer, while the activities performed by the process between these elements represent the actions taken in response to the customer request, from the time the request is received to the time the response is sent back (reply).
6.3 The Choreography Definition Language

The primary goals of a choreography definition are to verify at run time that all message interchanges are proceeding according to plan and to guaranty that changes in the implementations of services are still in compliance with the message interchange definition. As such choreography is not executed but rather monitored and validated (or invalidated). Choreography definitions can involve two (binary) or more (multiparty) participants. The Web Services Choreography Description Language (WS-CDL) [Kavantzas 2004] describes a global view of the message interchange participants engaged in business collaboration without taking any participants point of view, unlike the BPEL global model which takes the point of view of one participant. Message interchanges take place in a jointly agreed set of ordering and constraint rules. A choreography definition in WS-CDL is always defined abstractly between roles which are later bound to participants. Roles are related to each other via relationships. A relationship is always between exactly two roles. A participant may implement any number of nonopposite roles in the choreography. A distributor may implement the buyer-to-manufacturer and seller-to-customer roles, which is yet different from the seller-to-distributor role. Roles in WS-CDL are some what similar to <partnerLink>s in BPEL. Choreographies are composed of activities. The main activity is called an interaction and is the basic building block of a choreography, which results in exchange of messages between participants and possible synchronization of their states and the actual values of the exchanged information. Interactions specify the unit of message exchange between roles. An interaction corresponds to the invocation of a Web service operation on a role. An interaction definition is bound to an operation definition (which requires at least an abstract WSDL definition). Other activities are used to create meaningful combinations of interactions. For instance ordering activities (sequence, parallel, choice) or a perform activity which composes another choreography in the parent choreography. The WS-CDL represents an important new layer of the Web services stack. As it is early in the W3C specification process, it is difficult to picture exactly what the final recommendation will be and whether or not the OASIS BEPL and W3C WS-CDL working group will come to an agreement on how the two standards would work together.
6.4 Web Services Coordination and Transactions

A Web services environment requires the same coordination behavior provided by traditional transaction mechanisms to control the operations and outcome of an application. It also requires the capability to handle the coordination of processing outcomes or results from multiple services, in a more flexible manner. However, traditional transactions are synchronous and depend upon tightly coupled protocols, therefore are often not well suited to more loosely-coupled Web services based applications, although they are likely to be used in some of the constituent technologies. Strict ACIDity and isolation, in particular, is
1
This operation is part of the PurchaseOrder <PortType> defined in Figure 6.
Fo
rP
ee
rR
29
ev
iew
8 April 2006
Computing Surveys
Page 30 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
not appropriate to a loosely coupled world of autonomous trading partners, where security and inventory control issues prevent hard locking of local resources that is impractical in the business world. This requires more relaxed forms of transactions -- those that do not strictly have to abide to the ACID properties --such as collaborations, workflow, real-time processing, etc. Additionally, there is a need to group Web services into applications that require some form of correlation, but do not necessarily require transactional behavior. In the loosely coupled environment represented by Web services, long running applications will require support for coordination, recovery and compensation, because machines may fail, processes may be cancelled, or services may be moved or withdrawn. A trio of standards tackles the problem of choreographing Web services. The standards that support business process orchestration while providing Web services transactional functionality are: Business Process Execution Language for Web Services, WS-Coordination [Cabrera 2002a] and WS-Transaction [Cabrera 2002b]. WS-Coordination and WSTransaction complement BPEL to provide mechanisms for defining specific standard protocols for use by transaction processing systems, workflow systems, or other applications that wish to coordinate multiple Web services. These three specifications work in tandem to address the business workflow issues implicated in connecting and executing a number of Web services that may run on disparate platforms across organizations involved in e-Business scenarios. The WS-Coordination specification describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed transactions. WS-Coordination provides developers with a way to manage the operations related to a business activity. A business process may involve a number of Web services working together to provide a common solution. Each service needs to be able to coordinate its activities with those of the other services for the process to succeed. WS-Coordination sequences operations in a process that spans interoperable Web services to reach an agreement on the overall outcome of the business process. The specification supplies standard mechanisms to create an activity via an activation service and register via a registration service with transaction protocols that coordinate the execution of distributed operations in a Web services environment. WSCoordination provides a definition of the structure of coordination context and the requirements for propagating this context between cooperating services via its coordination context. WS-Transaction provides transactional coordination mechanisms for Web services. An important aspect of WS-Transaction that differentiates it from traditional transaction protocols is that it does not assume a synchronous request/response model. This derives from the fact that WS-Transaction is layered upon the WS-Coordination protocol whose own communication patterns are asynchronous. WS-Coordination provides a generic framework for specific coordination protocols, like WS-Transaction, to be plugged in. The WSTransaction specification leverages WS-Coordination by extending it to define specific protocols for transaction processing. WS-Transaction defines two transaction types: atomic transaction and business activity. Atomic transactions are suggested for transactions that are short-lived atomic units of work within a trust domain, while business activities are suggested for transactions that are longlived units of work comprising activities of potentially different trust domains. Atomic transactions compare to the traditional distributed database transaction model (short-lived atomic transactions). The coordination type correspondingly comprises protocols common to atomic transactions, where resource participants register for the two-phase commit protocol. The business activity coordination type supports transactional coordination of potentially long-lived activities. These differ from atomic transactions in that they take much longer time to complete and do not require resources to be held. The WS-Transaction specification monitors the success of specific, coordinated activities in a business process.
Fo
rP
ee
rR
30
ev
iew
8 April 2006
Page 31 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
WS-Transaction uses the structure that WS-Coordination provides to make sure the participating Web services end the business process with a shared understanding of its outcome. For example, a purchase process contains various activities that have to complete successfully but might run simultaneously, (at least to some extend), such as credit check, inventory control, billing and shipment. The combination of WS-Transaction and WSCoordination makes sure that these tasks succeed or fail as a unit.
6.5 Web Services Security and Policies

To secure Web services, enterprises focus on authentication, authorization, confidentiality, and data integrity, as well as threat detection and defense. Web services security is an endto-end process where creator of the message may write the payload, but intermediaries may inspect or rewrite the message afterwards. Therefore, there must be a way for the intermediary to read the part of the message that instructs it what to do, without compromising the confidential payload of the message. This process becomes even more compound when one considers long-running choreographed Web services conversations involving multiple requests, responses, and forks, and their ensuing security requirements. All of these scenarios rely on the ability for message processing intermediaries to forward messages. To address end-to-end security concerns, a set of Web service security standard specifications and technologies that are meant to create a unifying approach for dealing with protection for messages exchanged in a Web services environment are being developed [WS-Rodamap 2002]. This security framework comprises a foundational standard called WS-Security [Rosenberg 2004] (which in turn is built on XML Signature, XML Encryption, SAML and various other security standards) followed by other standards, such as WS(Security)-Policy, WS-Trust, WS-Privacy, WS-Federation and WS-Authorization, that rely on it. Most of the sespecifications are still very much under development with the exception of WS-Security, which is fairly well defined. WS-Security specifies an abstraction layer on top of any companys particular application security technology (PKI, Kerberos, etc.) that allows such dissimilar infrastructures to participate in a common trust relationship. WS-Security provides a set of SOAP extensions that can be used to implement message integrity, confidentiality and authentication. It is designed to provide support for multiple security tokens, trust domains, signature formats and encryption technologies. No specific type of security token is required by WS-Security. It is designed to be extensible (e.g. support multiple security token formats). For example, a requester might provide proof of identity and proof that they have a particular business certification. Message integrity is provided by leveraging XML Signature in conjunction with security tokens (which may contain or imply key data) to ensure that messages are transmitted without modifications. Similarly, message confidentiality is provided by leveraging XML Encryption in conjunction with security tokens to keep portions of SOAP messages confidential. While current technologies enable an enterprise to authenticate users and manage user access privileges, it takes considerable effort and cost to extend these capabilities across an enterprise or share them among trading partners. Security Assertions Markup Language (SAML) [SAML 2003] addresses this challenge. SAML is an XML-based framework that enables Web services to readily exchange information relating to authentication and authorization. SAML defines a protocol by which clients can request assertions from SAML authorities and receive responses from them (exchange of security information). This protocol, consisting of XML-based request/response message formats, can be bound to many different underlying communications and transport protocols. The security information is expressed in the form of assertions about subjects. A subject is an entity that has an identity in some security domain. Assertions can convey information about authentication
Fo
rP
ee
rR
31
ev
iew
8 April 2006
Computing Surveys
Page 32 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. The two specifications WS-Security and SAML, which are closely related, ensure the integrity and confidentiality of XML documents. They differ from existing capabilities in that they provide mechanisms for handling whole or partial documents, making it possible to address varying requirements for access authority, confidentiality and data integrity within one document. In order to successfully compose Web services, one must fully understand the service's WSDL contract along with any additional Quality of Service capabilities and requirements. The QoS for Web services description publishes important functional and non-functional service quality attributes, such as service metering and cost, performance metrics (e.g., response time), security attributes, (transactional) integrity, reliability, scalability, and availability. These Web services capabilities and requirements can be expressed in terms of policies. For example, knowing that a service supports a Web services security standard such as WS-Security is not enough information to enable successful composition. The client needs to know if the service actually requires WS-Security, what kind of security tokens it is capable of processing, and which one it prefers, and so on. WS-Policy [WS-Policy 2003] fills this gap by providing building blocks that may be used in conjunction with other Web services and application-specific protocols to accommodate a wide variety of policy exchange models. The Web Services Policy Framework provides a general purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities. WS-Policy defines a policy to be a collection of one or more policy assertions. A policy assertion represents an individual preference, requirement, capability, or other general characteristic.
On the research front, activities have mainly concentrated on dynamic compositions [Yang 2004], on modularizing compositions [Charfi 2004], [Yang 2004], on enhancing service descriptions (with, for instance, compositional assertions) so that compositions can be assessed and formally verified [Solanki 2004] and on providing context aware services to enable compositions and service conversations [Benatallah 2003]. In the AI field there has been some work in the area of applying AI planning techniques to automate the retrieval and composition of Web services ([Paoloucci 2002], [Ambite 2004], [Lazovik 2004], [Traverso 2004], [Pistore 2005]), verification [Kazhamiakin 2006], and monitoring of service oriented applications [Barbon 2006], and so forth, but these efforts are still either at the specification-level or at very preliminary stage of development. Many of the existing approaches towards service composition largely neglect the context in which composition takes place. It is only recently that research approaches have focussed on developing context-aware methodologies that take into account the business and social context of service compositions as the basis for process specification and verification [Colombo 2005].
Fo
rP
ee
rR
ev
iew
Web Services Management and Monitoring
Composite service developments necessitate the use of mechanisms that provide them insights into the health of systems that implement Web services and into the status and behavior patterns of loosely coupled applications. A consistent management and monitoring infrastructure is thus essential for production-quality Web services and applications and
32
8 April 2006
Page 33 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
provided by the management and monitoring plane in the corresponding layer of the Web services functionality stack in Figure 5. The rationale is very similar to the situation in traditional distributed computing environments, where systems administrators rely on programs/tools/utilities to make certain that a distributed computing environment operates reliably and efficiently.
7.1 Requirements and Architecture

Managing loosely coupled applications in an SOA is an absolute requirement. Failure or change of a single application component can bring down numerous interdependent enterprise applications. The addition of new applications or components can overload existing components, causing unexpected degradation or failure of seemingly unrelated systems. Application performance depends on the combined performance of cooperating components and their interactions. To counter such situations, enterprises need to constantly monitor the health of their applications. Performance should be in tune, at all times and under all load conditions. The management and monitoring plane in Figure 5 requires that a critical characteristic be realized: that services be managed and monitored. Service management encompasses the control and monitoring of SOA-based applications throughout their life cycle. Service management spans a range of activities from installation and configuration to collecting metrics and tuning to ensure responsive service execution. It includes many interrelated functions such as Service-Level Agreement negotiation, management, auditing, monitoring, and troubleshooting, service lifecycle/state management, performance management, services and resources provisioning, and includes aspects like scalability, availability and extensibility and others. The operations management level allows business managers to check the correctness, consistency and adequacy of the mappings between the input and output service operations and aggregate services in a service composition. It is also aimed at supporting critical applications that require enterprises to manage the service platform, the deployment of services and the applications. Operations management typically gathers information about the managed service platform, services and business processes and managed resource status and performance, and supporting specific management tasks (e.g., root cause failure analysis, SLA monitoring and reporting, service deployment, and life cycle management and capacity planning). Operations management functionality may provide detailed application performance statistics that support assessment of the application effectiveness, permit complete visibility into individual business processes and transactions, guarantee consistency of service compositions, and deliver application status notifications when a particular activity is completed or when a decision condition is reached. Considerations need also be made for modelling the scope in which a given service is being leveraged individual, composite, part of a long-running business process, and so on. Service monitoring allows monitoring events or information produced by the services/processes, monitoring instances of business processes, viewing process instance statistics, including the number of instances in each state (running, suspended, aborted or completed), viewing the status, or summary for selected process instances, suspend, and resume or terminate selected process instances. Of particular significance is the ability to be able to spot problems and exceptions in the business processes and move toward resolving them as soon as they occur. We refer to the role responsible for performing such operation management functions as the service operator (see Figure 5). Depending on the application requirements a service operator could be a service client or service aggregator. It is increasingly important for service operators to define and support active capabilities versus traditional passive capabilities. For example, rather than merely raising an alert
Fo
rP
ee
rR
33
ev
iew
8 April 2006
Computing Surveys
Page 34 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
when a given service is unable to meet the performance requirements of a given servicelevel agreement, the management framework should be able to take corrective action itself. This action could take the form of rerouting requests to a backup service that is less heavily loaded, or automatically provisioning a new application server with an instance of the software providing the service if no backup is currently running and available. Finally, service operations management should also provide global visibility of running processes, comparable to that provided by Business Process Management tools. Management visibility is expressed in the form of real-time and historical reports, and in triggered actions. For example, deviations from key performance indicator target values, such as the percent of requests fulfilled within the limits specified by a service level agreement, might trigger an alert and an escalation procedure, or might propose changes to affected process models enabling them to achieve their goals. Figure 11 highlights the components of a conceptual architecture that combines a service management and an application channel developed in accordance to SOA principles [Papazoglou 2005b]. This architecture provides a continuous connection between the Web services application channel and directs it into the management channel. Example management applications include availability and performance management, configuration management, capacity planning, asset protection, job control, and problem determination.
Service management in this conceptual architecture involves a collection of services that communicate with each otherpassing data to each other or coordinating some activity togetherall with the aim of facilitating the delivery of one or more business services. This architecture supports a variety of management protocols, such as Simple Network Management Protocol (SNMP), Java Management Extensions (JMX), and WBEM. In Figure 11, manageable resources are as usual hardware and software resources, both physical and logical, e.g., software applications, hardware devices, servers, and so on, whose management capabilities are exposed as Web services that implement various management interfaces, such as those defined in the the Web Services Distributed Management specification or WSDM. A management interface of a resource is described by a WSDL document, resource properties schema, meta-data documents, and potentially a set
Fo
Figure 11 Web services management architecture.
rP ee rR ev iew
34 8 April 2006
Page 35 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
of management related policies. Manageable resources can be accessed directly by resource managers, as part of a business processes and/or a management processes. In Figure 11, a business process is composed of integrating basic services such as credit validation, shipping, order processing, and inventory services originating from two collaborating enterprises. Resource managers in the architecture are management applications, e.g., performance management, capacity planning, asset protection, job control, etc, that manage resources through the use of their management interfaces or management infrastructure services [Kreger 2005a]. Resource managers provide a range of functions that range from simple monitoring, to control, to autonomic tuning and recovery, to sophisticated quality management, to end-to-end business processes management, and policy-driven provisioning of systems and services. They generally provide interfaces and content for management consoles that are capable of displaying management related information. Managers interact with manageable resources and management infrastructure services to accomplish their mission using the Web services interfaces described earlier in this section. In addition, service managers leverage Web services technologies, such as BPEL, to describe and execute management processes that perform a scripted management function.
7.2 Web Services Distributed Management Specification

Consistent end-to-end Web services management is not possible without industry-wide standard development. To address this issue, OASIS is actively involved in the development of a new management standard, the Web Services Distributed Management specification, in an attempt to bring about interoperability for the management of distributed computing environments. WSDM essentially defines a protocol for interoperability of management information and capabilities via Web services. WSDM focuses on two distinct tasks in its attempt to solve distributed system management problems [Kreger 2005a], [Kreger 2005b]. The first activity area, called Management Using Web Services (MUWS) addresses the use of Web services technologies as the foundation of a modern distributed systems management framework. This includes using Web services to facilitate interactions between managed resources and management applications. In particular, MUWS defines how to describe the manageability capabilities of managed resources using WSDL documents. Expressing capabilities enables more efficient discovery of and introspection of resources since managers, typically focus on a particular management task or domain, and therefore need to be able to easily and efficiently determine the relevant capabilities of a manageable resource. In addition, WSDM addresses the specific requirements for managing Web services themselves just like any other resource. This activity is called Management of Web Services (MOWS). WSDM uses Web services as a platform to provide essential distributed computing functionality, interoperability, loose coupling, and implementation independence. The MOWS specification is based on the concepts and definitions expressed in the Management Using Web Services specification. Like MUWS activities, MOWS aims to build on existing model frameworks in its definition of the management model of a Web service, rather than reinventing a general managed resource object model scheme.

The most recent wave of management product categories does not have the businessawareness that services management will require. The finer grained nature of services (as opposed to applications) requires evaluating processes and transactions at a more
Fo
rP
ee
rR
35
ev
iew
8 April 2006
Computing Surveys
Page 36 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
magnified rate and in a more contextually aware manner. Research activities have concentrated on assessing the impact of service execution from a business perspective and, conversely, to adjust and optimize service executions based on stated business objectives [Casati 2003]. This is a crucial issue as corporations strive to align service functionality with business goals. One crucial aspect of management entails monitoring. Here research activities traditionally focus on dynamic monitoring techniques that are capable of employing monitoring rules governing the control of composite services [Baresi 2005], e.g., such as those generated using BPEL processes. Other approaches concentrate on capturing and monitoring negotiations that incorporate security policies and policy models that facilitate service lifecycle management [Skogsrud 2004]. The ability to gauge the quality of a service is critical if we are to achieve the Service Oriented Computing paradigm. Many techniques have been proposed and most of them attempt to calculate the quality of a service by collecting quality ratings from the users of the service, and then combining them in one way or another. Collecting quality ratings alone from the users is not sufficient for deriving a reliable or accurate quality measure for a service. Research activities have concentrated on using QoS metrics for selecting Webservices and for establishing trust between trading partners [Maximilien 2004]. Ideally, services are collaborating in highly distributed environments, naturally cutting across various enterprise boundaries. This environment demands that contracts are set up, stipulating agreements between services regarding their collaboration, both at the functional and non-functional level, in a concise manner. These contracts may serve as the basis for process monitoring and adaptation. Research activities in this front concentrate on standardizing on agreements between enterprise domains offering agreement templates, and facilities to dynamically check the state of an agreement [Ludwig 2004].
Fo
rP
ee
rR
Concluding Remarks
Web services are lightweight constructs that enable the development of rapid, low-cost and easy composition of distributed applications. Web services are self-describing, platformagnostic computational modules that support rapid, low-cost and easy composition of loosely coupled distributed applications. Key to developing Web service-based applications is the service-oriented architecture (SOA). SOA is a logical way of designing software solutions to provide services to either end-user applications or to other services distributed in a network, via published and discoverable interfaces. Currently, the SOA provides the basic operations necessary to describe, publish, find and invoke services. However, those basic operationswhile they help services to be ubiquitous and universalare not a complete solution. For services to be used widely, there is additional functionality that must be considered for service composability including specifications regarding the dynamic composition of services, transactional context and coordination, adaptability to varying circumstances, security and so on as well as for service management. Such concerns are addressed by the Web services functionality stack that layers Web services technologies and standards in terms of three layers: service foundations, service composition, and service management and monitoring. The service foundations plane provides a service oriented middleware backbone that realizes the runtime SOA infrastructure that connects heterogeneous components and systems, and provides multiple-channel access to services via different kinds of devices and networks. This runtime infrastructure allows to define the classical SOA functions involving communication, the description, publishing, finding and binding of services. There are quite a few challenging problems for the near future as regards the service foundation layer.
ev
iew
36
8 April 2006
Page 37 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Some of the most notable challenge include dynamic connectivity and dynamically (re-) configurable run-time architectures, advanced infrastructure support for application, data and process integration, and improved service discovery. The service composition plane encompasses functionality that is necessary for the aggregation of multiple services into a single composite service. Resulting composite services may be used as discrete services in further service compositions or may be offered as complete applications/solutions to service clients. Some of the most notable research challenges for the near future for the services composition layer include composability analysis for replaceability, compatibility, and conformance for dynamic and adaptive processes, adaptive service compositions, autonomic composition of services, and QoSaware service compositions. The management and monitoring plane requires that a critical characteristic be realized: that services be managed and monitored. Service management encompasses the control and monitoring of SOA-based applications throughout their life cycle and spans a range of activities from installation and configuration to collecting metrics and tuning to ensure responsive service execution. Some of the most notable research challenges for the near future for the services management layer include seeding autonomic capabilities for service level management and monitoring. Such autonomic capabilities can be naturally divided into five categories: self-configuring, self-adapting, self-healing, self-optimizing and selfprotecting, each of which represents a major research challenge.
Fo
rP
9 References
[Ambite 2004] J. L. Ambite, et. al Argos: An Ontology and Web Service Composition Infrastructure for Goods Movement Analysis, National Conference on Digital Government Research, Seattle, Washington, May 2004. [Andrews 2003] T. Andrews et. al. Business Process Execution Language for Web Services, Version 1.1, March 2003. [Antoniou 2004] G. Antoniou, F. van Harmelen A Semantic Web Primer, MIT Press 2004. [Bajaj 2004] S. Bajaj at al., Web Services Policy Framework (WS-Policy), September 2004, available at: http://www.ibm.com/developerworks/library/specification/ws-polfram/. [Balinger 2004] K. Balinger et al. Web Services Metadata Exchange (WSMetadataExchange), September 2004, available at: http://msdn.microsoft.com/library/enus/dnglobspec/html/ws-metadataexchange.pdf [Barbon 2006] F.Barbon, P.Traverso, M.Pistore, M.Trainotti. Run-Time Monitoring the Execution of Web Service Compositions. The International Conference on Planning and Scheduling (ICAPS) 2006. [Baresi 2005] L. Baresi, S. Guinea Towards Dynamic Monitoring of WS-BPEL Processes, Proceedings of the 3rd International Conference on Service Oriented Computing (ICSOC 2005), Springer, Amsterdam, December 2005. [Benatallah 2003] B. Benatallah, F. Casati, F. Toumani, R. Hamadi Conceptual Modeling of Web Service Conversations, Proc. of 15th International Conference on Advanced Information Systems Engineering (CAiSE'03), Springer Verlag, Velden, Austria, June 2003. [Boubez 2000] T.Boubez, Web Services architecture overview: The next stage of evolution for e-business, IBM DeveloperWorks Web Architecture Library, October 20th 2000.
ee
rR
37
ev
iew
8 April 2006
Computing Surveys
Page 38 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
[Cabrera 2002a] F. Cabrera et al., Web Services Coordination (WS-Coordination), August 2002, http://www.ibm.com/developerworks/library/ws-coor/ [Cabrera 2002b] F. Cabrera et al., Web Services Transaction (WS-Transaction), August 2002, http://www.ibm.com/developerworks/library/ws-transpec/ [Casati 2003] F. Casati et al. Business-Oriented Communincations of the ACM, vol. 46, no. 10, 2003. Management of Web Services,
[Cauldwell 2001] P. Cauldwell, et. al., XML Web Services, Wrox Press Ltd., 2001. [Chappell 2004] D.A. Chappell Enterprise Service Bus, OReilley & Associates Inc., 2004. [Chappell 2005] D. Chappell ESB Myth Busters: Clarity of definition for a growing phenomenon, Web Services Journal, February 2005, pp. 22- 26. [Charfi 2004] A. Charfi, M. Mezini Hybrid Web service composition: business processes meet business rules, Intl Conf. on Service Oriented Computing (ICSOC 2004), New York, Dec 2004. [Colombo 2005] E. Colobo, J. Mylopoulos, P. Spoletini Modeling and Analyzing ContextAware Composition of Services, 3rd International Conference on Service Oriented Computing, Springer, Amsterdam, December 2005. [Curbera 2003] P. Curbera, R. Khalaf, N. Mukhi, S. Tai, S. Weerawarana, Web services, the next step: A framework for robust service composition, Communications of ACM, Special Section on Service-Oriented Computing, M.P. Papazoglou and D. Georgakopoulos (eds), October 2003. [DAML] Darpa Agent Markup Language, available at: http://www.daml.org. [Deora 2003] V. Deora, J. Shao, W. A. Gray ,N.J Fiddian, Rating Based Quality of Service Management on Expectations, Proc. Of 1st International Conference on Service Oriented Computing, Springer Verlag, Trento, Italy, Dec. 2003. [Deora 2004] V. Deora et al. Incorporating QoS specifications in service discovery, WISE Workshops, Lecture Notes of Springer Verlag, 2004. [Ding 2004] X. Ding et al Similarity Search for Web services, 30th VLDB Conference, September 2004. [Goepfert 2002] J. Goepfert, M. Whalen An Evolutionary View of Software as a Service, IDC White paper, www.idc.com, 2002. [Graham 2004] S. Graham, P. Niblett (eds) Publish-Subscribe Notification for Web Services, March 2004, available at: http://docs.oasisopen.org/committes/dowload.php/6661/WSNpubsub-1-0.pdf [Graham 2004. 2005] S. Graham et. al., Building Web Services with Java, SAMS Publishing,
[Ivan 2002] A.-A. Ivan, J. Harman, M. Allen, V. Karamcheti. Partitionable Services: A Framework for Seamlessly Adapting Distributed Applications to Heterogeneous Environments, Proceedings of the 11th IEEE International Symposium on High Performance Distributed Computing, 2002.
Fo
rP
ee
rR
38
ev
iew
8 April 2006
Page 39 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
[Jaeger 2004] M. C. Jaeger, S. Tang Ranked Matching for Service Descriptions using DAMLS, Proceedings of CAiSE'04 Workshops, Riga, Latvia, June 2004. [Kavantzas 2004] Web Services Choreography Description Language 1.0, Editor's Draft, April 3 2004, http://lists.w3.org/Archives/Public/www-archive/2004Apr/att-0004/cdl_v1editors-apr03-2004-pdf.pdf. [Kephart 2003] J. O. Kephart, D. M. Chess The Vision of Autonomic Computing, IEEE Computer, January 2003. [Klyne 2004] F. Klyne, J.J. Carroll Resource Description Framework (RDF): Concepts and Abstract Syntax, W3C Recommendation, February 2004, available at http://www.w3.org/TR/rdf-concepts/. [Kreger 2005a] H. Kreger A Little Wisdom about WSDM, IBM developerWorks, available at: http://www-128.ibm.com/developerworks/library/ws-wisdom. [Kreger 2005b] H. Kreger, et. al Management Using Web Services: A Proposed Architecture and Roadmap, IBM, HP and Computer Associates, June 2005, available at: www128.ibm.com/developerworks/library/specification/ws-mroadmap. [Lazovik 2004] Lazovik, A, M. Aiello, M.P. Papazoglou Associating Assertions with Business Processes and Monitoring their Execution Intl Conf. on Service Oriented Computing (ICSOC 2004), New York, Dec 2004. [Leymann 2005a] F. Leymann The (Service) Bus: Services Penetrate Everyday Life, 3rd Intl. Conf. on Service Oriented Computing ICSOC2005, (Amsterdam, The Netherlands, December 13 16, 2005), LNCS 3826 Springer-Verlag Berlin Heidelberg 2005. [Leymann 2005b] F. Leymann Combining Web Services and the Grid: Towards Adaptive Enterprise Applications, Proc. CAiSE/ASMEA05 (Porto, Portugal, June 2005). [Lopez 2001] J. Lopez and D. OHallaron. Evaluation of a Resource Selection Mechanism For Complex Network Services, Proceedings of the Tenth IEEE International Symposium on High Performance Distributed Computing, Aug. 2001. [Liu 2002] C. Liu, L. Yang, I. Foster, D. Angulo. Design and Evaluation of a Resource Selection Framework for Grid Applications, IEEE International Symposium on High Performance Distributed Computing (HPDC-11), July 2002. [Ludwig 2004] H. Ludwig, A. Dan, R. Kearney Cremona: an Architecture and Library for Creation and Monitoring of WS-Agreements, Intl Conf. on Service Oriented Computing (ICSOC 2004), New York, Dec 2004. [Manes 2003] A.T. Manes, Registering a Web service in UDDI, Web Services Journal, vol. 3, issue 10, October 2003, pp. 6-10. [Mani 2002] A. Mani, A. Nagarajian Web services : Understanding quality of service for Web services IBM Developer Works January 2002, http://www106.ibm.com/developerworks/library/ws-quality.html [Manola 2004] F. Manola, E. Miller (editors), RDF Primer, W3C Recommendation, February 2004, available at http://www.w3.org/TR/rdf-primer/. [Maximilien 2004] E. M. Maximilien, M.P. Singh Toward Autonomic Web Services Trust and Selection, Intl Conf. on Service Oriented Computing (ICSOC 2004), New York, Dec 2004.
Fo
rP
ee
rR
39
ev
iew
8 April 2006
Computing Surveys
Page 40 of 41
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
[McGuiness 2004] D. McGuiness, F. van Harmelen OWL Web Ontology Language Overview, W3C Recommendation, February 2004, available at http://www.w3.org/TR/owlfeatures. [Papazoglou 2003] M. Papazoglou, D. Georgakopoulos, Service Oriented Computing, Communications of the ACM, vol. 46, no. 10, October 2003, pp. 25-28. [Papazoglou 2005a] M.P. Papazoglou Extending the Service Oriented Architecture, Business Integration Journal, February 2005. [Papazoglou 2005b] M.P. Papazoglou , W.J. van den Heuvel Web Services Management: A Survey, IEEE Internet Computing, November/December 2005. [Papazoglou 2006a] M.P. Papazoglou Principles and Foundations of Web Services: A Holistic View, Addison-Wesley, forthcoming: summer 2006. [Papazoglou 2006b] M.P. Papazoglou and W.J. van den Heuvel Service-Oriented Architectures: Approaches, Technologies and Research Issues, VLDB Journal, to appear in 2006. [Papazoglou 2006c] M. P. Papazoglou, W. van den Heuvel Business Process Development Lifecycle Methodology to appear in Communications of ACM, 2006. [Patil 2004] A. A. Patil et al. Meteor-S: Web Service Annotation Framework, WWW'04: Proceedings of the 13th international conference on World Wide Web, pp. 553-562, ACM Press, 2004 [Poladian 2004] V. Poladian, D. Garlan, M. Shaw, J. P. Sousa Dynamic Configuration of Resource-Aware Services, Proceedings of the 26th International Conference on Software Engineering, May 2004. [Paolucci 2002] M. Paolucci, et al. Semantic Matching of Web Services Capabilities, 1st International Semantic Web Conference, 2002. [Ponnekanti 2002] S. R. Ponnekanti, A. Fox. SWORD: A Developer Toolkit for Web Service Composition, 11th World Wide Web Conference (Web Engineering Track), May 2002. [Pistore 2005] M. Pistore, P. Traverso, P. Bertoli, A. Marconi Automated Synthesis of Executable Web Serivce Compositions from BPEL4WS Processes Special Track at the International World Wide Web Conference (WWW) 2005. [Ran 2003] S. Ran A Model for Web Services Discovery with QoS, SIGecom Exchange, vol. 4, no. 1, 2003. [Roman 2005] D. Roman, Web Service Modeling Ontology, Applied Ontology, IOS Press, vol. 1, no. 1, 2005. [Rosenberg 2004] J. Rosenberg, D. Remy Securing Web Services with WS-Security, Sams Publishing, 2004. [SAML 2003] Security Assertions Markup xml.coverpages.org/saml.html, December 2003. Language SAML: Overview
[Sahin 2005] O.D. Sahin et al. SPiDeR: P2P-Based Web Service Discovery 3rd International Conference on Service Oriented Computing, Springer Verlag, Amsterdam, December 2005.
Fo
rP
ee
rR
40
ev
iew
8 April 2006
Page 41 of 41
Computing Surveys
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
[Skogsrud 2004] H. Skogsrud, B. Benatallah, F. Casati Trust-serv: Model-Driven Lifecycle Management of Trust Negotiation Policies for Web services, WWW '04: Proceedings of the 13th international conference on World Wide Web, pages 53{62, New York, NY, USA, 2004. ACM Press. [Solanki 2004] M. Solanki, A. Cau, H. Zedan Augmenting Semantic Web Service Descriptions with Compositional Specification, WWW '04: 13th international conference on World Wide Web,New York, NY, USA, 2004. ACM Press. [Traverso 2004] P. Traverso, M. Pistore Automatic Composition of Semantic Web Services into Executable Processes International Semantic Web Conference (ISWC) 2004. [Wang 2003] Y. Wang, E. Stroulia Semantic Structure Matching for Assessing WebService Similarity 1st International Conference on Service Oriented Computing (ICSOC03), Springer-Verlag, 2003. [Weerawarana 2005] S. Weerawarana, F. Curbera, F. Leymann, T. Storey, D.F. Ferguson. Web Services Platform Architecture, Prentice Hall, 2005. [WS-Rodamap 2002] "Security in a Web Services World: A Proposed Architecture and Roadmap", IBM Developer Works, April 2002. [Yang 2004] J. Yang and M.P.Papazoglou Service Components for Managing the Life-Cycle of Service Compositions, Information Systems, vol. 28, no. 1, 2004.
Fo
rP
ee rR ev iew
41 8 April 2006

For Peer Review: Web Services Technologies and Standards

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

For Peer Review: Web Services Technologies and Standards

Загружено:

Авторское право:

Доступные форматы

Computing Surveys

Web Services Technologies and Standards

Web Services Technologies and Standards

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Web Services Overview

Copyright Michael P. Papazoglou

2.2 Definition of Web Services

Types of Web services

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

2.4 Quality of Service

Copyright Michael P. Papazoglou

2.5 Service Interfaces and Component Implementations

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Web Services Technology Stack

Copyright Michael P. Papazoglou

Figure 5 The Web services functionality stack.

Web Services Foundation Layer

Web Services Communication

Copyright Michael P. Papazoglou

Web Services Description

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

UDDI: Universal Description, Discovery, and Integration

Copyright Michael P. Papazoglou

5.4 Web Services Meta-data and Semantics

Copyright Michael P. Papazoglou

Figure 7 Overview of UDDI data structures.

Copyright Michael P. Papazoglou

5.5 Web Services Meta-data Exchange

Copyright Michael P. Papazoglou

Figure 8 Sample RDF schema for a hierarchy of publications.

5.6 Services Run-time Environment

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

5.7 Research Activities

Copyright Michael P. Papazoglou

6 Web Services Composition Layer

6.1 Services Orchestration versus Choreography

Copyright Michael P. Papazoglou

6.2 Services Orchestration

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

Figure 10 BPEL process flow for a PurchaseOrder process.

6.3 The Choreography Definition Language

6.4 Web Services Coordination and Transactions

This operation is part of the PurchaseOrder <PortType> defined in Figure 6.

Copyright Michael P. Papazoglou

Copyright Michael P. Papazoglou

6.5 Web Services Security and Policies

Copyright Michael P. Papazoglou

6.6 Research Activities

Web Services Management and Monitoring

Copyright Michael P. Papazoglou

7.1 Requirements and Architecture