SERVICE ORIENTED COMPUTING AND COORDINATION MODELS Natallia Kokash University of Trento, Italy University of Trento, DIT, Via Sommarive, 14 38050 Povo (TN)
[email protected]
Vincenzo D'Andrea University of Trento, Italy University of Trento, DIT, Via Sommarive, 14 38050 Povo (TN)
[email protected]
Abstract. In this paper we briefly describe the challenges related to Serviceoriented computing (SOC). SOC is a novel architectural approach to building complex applications in terms of composition of simple services. A number of challenges arise from the need of coordinating the composed services. We describe approaches based on service orchestration and on service choreography. We also introduce coordination models used in the field of parallel and distributed systems, and we sketch the potential for application of these ideas in SOC. Finally we discuss the problems related to service discovery; i.e. how to find suitable parts for a composition.
1
Introduction
New organizational models and technology advancement are creating a fertile ground for a novel model of software, based on loosely coupled, distributed and independent services. Services have standardized interfaces that allow assembling elementary services into complex ones [1]. The most prominent realization of service oriented architectures is currently in the area of web services, that is services that operate via the web infrastructure. When several services are involved in pursuing a common goal, the issue of coordination of these independent entities becomes relevant. In the realm of web services there are two main approaches to service coordination: orchestration and choreography. Orchestration is characterized by the presence of a central role, the overall process is described from a single point of view and services actions are all relative to the central view. Choreography is characterized by the coexistence of a multiplicity of views, all active and equal. These two notions are connected to different languages and tools for approaching services coordination – two relevant initiatives in this field are BPEL4WS [5] and WS-CDL [7]. Besides a general introduction to service coordination, in this work we also discuss the application of coordination models to service collaboration. Our starting point is the classification of coordination models in terms of data- and control-driven models [14]. In data-driven coordination models the state of the overall process is characterized in terms of states of the individual processes and by the values being exchanged. In this case, coordination and computation are not necessarily separated. The opposite is the case of control-driven coordination models: in this case the separation between computation and
coordination is almost complete, and the state of individual participants is not involved in the description of the overall system state. Finally we discuss the implications of automating the discovery of services, possibly without the use of a central repository. Finding a service suitable with a specific goal is a complex task to automate, we describe in the last section some approaches to this issue.
2
Service Oriented Computing
Web services are platform-independent, loosely-coupled software modules with well defined functionality that are distributed over the Internet. Each of them performs some predetermined discrete task but their goal is to achieve high level of interoperability by using Web standards. Web services are commonly divided into information web services, which deliver solely the logic of applications they based on, and complex web services, which implement coordination between back-end information parts. The second group is currently the main sphere of interests for web services. The development of this promising area has gone far away from the simple exchange of information between services to the concept of the complete fusion of applied services. Service-Oriented Computing (SOC) is a generalization of web services: the main idea in SOC is the concept of services, bricks to construct complex distributed applications Services are self-describing manageable applications that can deliver resources to other applications. The advantage of this approach is the ability to rapidly and easily compose low-cost systems by discovering and binding complete network-available services. But many problems arise to accomplish this idea. Not all of them have been solved and as a consequence difficulties with conventional standards permitted to design unified full-scale systems currently exist. Not long ago the complex XML based web service standards have been evolved. They converged on Simple Object Access Protocol (SOAP) [2], Web Service Description Language (WSDL) [3], Universal Description and Discovery and Integration repository (UDDI) [4] and Business Process Execution Language (BPEL) [5]. The latter is comparatively new and unstable, therefore it is not recognized as full-fledged standard. Listed means define the way web services are described, advertise themselves, the way they are automatically discovered and used over the Internet. At present these standards offer the realization of Service Oriented Architecture (SOA) [1, 6] that is the logical way the software built on services is designed. SOA leans on three fundamental roles that the participants of business processes perform: provider who owns the web services, client who invokes the services and registry which is a searchable directory of available web services and their descriptions. Basic interactions between the roles include publication of the web service, finding the service description and actual invocation of service based on found service description. The interface that determines the functionality of web service is described with WSDL which defines the basic format of web requests. For information exchange in a distributed environment SOAP is used. Finding consists of discovering the required web service in repository and selection from search results. UDDI specification is a registry standard used to discover information about enterprises offering web services, obtain description of web services and extract technical information about their interfaces. After web service has been found it can be invoked directly or by the discovery agency mediation. The simple publishfind-use scheme is represented in Figure 1. A service provider publishes the service description by means of a service broker, a service consumer browse descriptions of published services in order to find a suitable service and finally the service consumer connects with the service provider in order to use the service.
Figure 1: Service Oriented Architecture.
By means of composition new services can be produced by means of the coherent combination of several individual services. The replication of this process produces a hierarchy of composed services. A relevant issue in service composition is the choice between design-time versus dynamic composition. The former is less agile and reactive to changes, while the latter is currently feasible only in simple domains, where the semantic of service description is not ambiguous. Service oriented architectures can be seen as an evolution from the concept of software component. Components are software modules that present lots of similarities with services, with the relevant difference that even when components are distributed, they are under control of a single organization. Services can go across organizational boundaries: the model allows the composition of services belonging to different organizations. A rather exhaustive view of web service technologies including service management, composition, transactions, security is presented in extended SOA [1].
3
Service coordination
In the following, the focus of our attention will move away from individual services, to web services that are expected to collaborate with each other. Web services can communicate obtaining necessary information about each partner by means of WSDL interface descriptions. But this scanty ability is insufficient to support complex business processes with message exchanges between multiple entities, longrunning transactions and non-comparable states. Proliferation of web services gave rise to the concept of web service coordination, which has been introduced to support the execution of composite schemes involving numerous web services with guarantee of reliability and confidentiality of the shared information. Despite the fact that various and competing coordination technologies have been developed this notion is still at the draft stage. Several proposals for rival candidates are currently in various stages of elaboration, attempting to became a reference for web service coordination. It is significant to mention the main approaches to this problem. The coordination concept is related with terms such as collaboration, orchestration, choreography, conversation, composition and so on. Conversation refers to the interchange of messages amid web services. Collaboration can be defined as the coherent work of web services having a common goal or tightly-coupled tasks to execute. This work may result in a long multi-step transactional process. The terms orchestration and choreography are also used to describe interaction protocols among collaborating web services but there is an
important distinction between them with respect to the structure of coordinated parts. Orchestration is associated with the business process which is controlled by one of the parties involved in the process whereas choreography refers to the case when there is no superior controller and the business process is defined by complementary behaviour of each of the participants. This approach is more scalable when the number of participants increases. This essential difference in terminology is underlined by the variety of languages and tools currently used or proposed in order to achieve the desirable collaboration model. The most relevant of them are the Business Process Execution Language for Web Services (BPEL4WS) and the Web Services Choreography Description Language (WS-CDL) [7]. Many others such as Business Process Specification Scheme (BPSS) [8], Business Process Modeling Language (BPML) [9], XLANG [10], Web Service Flow Language (WSFL) [11], Web Service Choreography Interface (WSCI) [12] and so forth, are also widely referred in the context of choreography.
4
Orchestration and choreography languages
The purpose of executable business process description languages such as XLANG, WSFL, BPEL4WS, BPML, XPDL (XML Process Definition Language) [13] and others is to specify the execution logic of an application. BPEL4WS is a standard XML-based industry specification that has been designed specially for web service orchestration and doesn’t adequately cover choreography. It took the best from merging of XLANG with its structural constructs and WSFL that supports graph oriented process. BPEL lies on top of WSDL and extends the interaction model enabling it to support transactions. Both executable and non-executable abstract business processes are provided. Executable process coordinates the behaviour of the participating web services in the overall business process by controlling their invocations. Internal and external aspects of business process are not separated. The purpose of abstract business process is to specify the public message exchange of each of the participants; the details of internal flows are not revealed. Four main sections in BPEL are distinguished: the message flow, the control flow, the data flow and the process orchestration section. Steps in the business process are described by primitive activities like invoking an operation, waiting for request, generating the response, faults throwing, waiting for some time, etc., that can be combined into more complex algorithms using structured activities. Structure activities give the ability to define the sequences of steps, define branches and loops, execute one of alternative paths and indicate steps for parallel execution. Finally the implementation of the service can be represented by recursive combination of structured activities that expresses the arbitrary complex algorithms. The primary goals of choreography are verification at run time that message interchanges are proceeding according to plan and that internal changes in the implementations of services don’t affect the message interchange. If the goal is a real webbased collaboration, there are other solutions that may have some advantages over BPEL4WS. One of them is WSCI that describes the observable behaviour of a Web Service in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. Both BPEL and WSCI are the languages for specifying the conditions under which a particular operation is invoked. But BPEL describes the business process from single point of view that a controlling service has while WSCI offers more collaborative approach. Each participant in the message exchange defines a WSCI interface in addition to global model that describes how these interfaces interact. BPML is used to orchestrate business processes. Unlike
BPEL WSCI is concentrated on visible behaviour of web-services and doesn’t concern the issue of orchestration, it is a choreography language. A number of standardization proposals in web service coordination has been put forward over the past years, leading to two ongoing standardization initiatives. One of them is above-mentioned BPEL4WS and another is WS-CDL. WS-CDL diverges from fundamental principles of WSCI and looks at the choreography problem from a new perspective. WS-CDL is a recent specification for choreography that describes a global view of message interchange, without taking any participants point of view. The language takes a descriptive approach, specifying the participating services and their dependencies. The specification is bound to the static description of participants (i.e. their WSDL files), A choreography can be binary or multiparty. In both cases, each party, adhering to a choreography language model representation, could be implemented using executable business process description languages as well as general purpose programming languages. Participants or roles are related to each other via relationships which are always between two roles. Long-lived peer-to-peer message interchanges (choreographies) are composed of activities. The main building block is an interaction activity which results in exchange of messages between participants and possible synchronization of their states. Activities to define sequences, choices or parallel executions, to compose choreography in the parent choreography as well as choreography neutral activities are provided. WS-CDL uses the notion of role states, which is relatively new in web service research. The major issue in the web service interactions is achievement of state alignment. WS-CDL is not settled yet and number of known issues remains open. Lack of separation between meta-model for service choreography and XML syntax, lack of direct support for certain categories of use cases and lack of comprehensive formal grounding are among them. The mapping between WS-CDL and mandatory WSDL is largely opened. Also there are no precise notions of conformance between WS-CDL choreographies and BPEL4WS abstract processes that will be necessary if both specifications are going to work together. The disorderly situation on the market doesn’t satisfy many companies urging the convergence of different standards. But currently it can’t be realized without elimination of drawbacks from existing specifications.
5
Coordination Models
Coordination models where defined for describing the pattern of interaction between heterogeneous components that collaborate towards a common goal. Beside the general models, a number of new programming languages, or extension to standard languages, were defined. These languages refers to the facilities added to, or complementing existing programming languages, in order to improve modularity, reuse and interoperability in parallel systems. The general goal is to support multilinguality and heterogeneity in the distributed, coordinated system. To this end, the first possibility is to define a new language, possibly a superset of existing one, while the second is to define an integrating interface to existing languages. Coordination and computation activities have different nature and purposes. This gives the choice between intermixing or separating these activities. Such a choice has generated two large families of approaches: data-driven or control-driven coordination, In the case of data-driven models and languages, the overall state of the system is defined by the data being exchanged and by the state of coordinated components. There is no need to separate coordination and computation. Common approaches to building the languages supporting this model are for instance based on a set of coordination primitives
added to host languages, or on a shared dataspace created to avoid extra coupling. These models rely on asynchronous communication between individual components. The main application for data-driven models is for computationally intensive parallel processing. The approach of control-driven languages and coordination models, assume a state of the overall system defined by the patterns describing the configuration of participants: the data and values being exchanged are not involved. In this case, there is a crisp separation between computation and coordination activities. This model focuses on the configuration of the communication patterns, for instance by provide channels for data exchange that could be one-to-one or one-to-many. The common approach in this case, is to define new languages for the coordination parts, that connect with computational parts treating the latter as black boxes. This approach is better suited for modelling distributed systems and processes. Between data-driven coordination languages, Laura is an especially interesting language [19]. Laura is a data-driven language, based on the concept of agents offering services, that are communicating by means of "forms" and exchanged via a shared dataspace. Forms are service-offer, service-request or service-result, and the language also includes a language to define service interfaces. The similarities with WSDL and the service approach are quite relevant, and we plan to explore this connection.
6
Conclusions
Given the experience in the field of coordination models and languages, it seems relevant also for service-oriented computing to underline the separation between service production and coordination as a relevant dimension. An immediate concern is that scalability of services is largely influenced by control-driven versus data-driven choices. However, when moving from a single machine or small group of machines, there are additional issues. For instance, data-driven approaches assume shared dataspace that is suitable only for local accesses. The provision of a shared dataspace creates also a strong correlation between individual services, that can be hardly combined with the fundamental loose coupling of services. Moreover, it is possible to explore control-driven approaches in order define models for service collaboration. One very interesting issue arises as concerns web service coordination, namely web service discovery, that is a problem of identification of potentially relevant web services for coordination. In spite of the fact that the UDDI registry seems to be the least critical point in the web service technology, it is not flexible, its category-based service discovery method is insufficient for automatic search. Interesting approaches [15] based on information retrieval and component matching methods [16], that do not use UDDI registry, were suggested to support programmatic service discovery for the web service composition. A suite of algorithms for the similarity assessment between two WSDL descriptions of web services were developed. Vector-space information retrieval, vectorspace information retrieval on service documentation and identifiers, WordNet-powered vector-space information retrieval on the service documentation, structure matching and semantic matching methods were examined. But the experimental results have shown that we are far from automatic web services discovery, the methods are neither precise nor robust and can be notably improved. Moreover, an essential limitation is that the matching of whole web services has been reviewed. If the goal is to perform some particular operations we do not need to search for the most appropriate web service. A formal approach to the problem of compatibility of operations constituting the service interfaces has been discussed in [17], but a number of problems, the most significant of which is mapping to the Web service platform, was not covered. Currently it does not allow to appreciate the quality of the method. So the issue of web service
discovery is still relevant. Some new approaches can be potentially applied to improve the existing solutions. The variety of modern document collection information retrieval techniques as well as ideas from the popular web information retrieval methods [18] might be useful for assessment of the matching score of compared web service operations. Information about UDDI taxonomy also can be exploited for automatic retrieval.
References [1] Papazoglou, M. P., Georgakopoulos, D.: Service-oriented computing. Communications of the ACM, Vol. 46, No. 10, 2003, pp. 25-28. [2] Mitra, N.: SOAP Version 1.2 Part 0: Primer, June 2003, http://www.w3.org/TR/2003/REC-soap12-part020030624/. [3] Christensen, E., Curbera, F., Meredith, Gr., Weerawarana, S.: Web Services Description Language(WSDL) 1.1, Mar. 2001, http://www.w3.org/TR/wsdl. [4] UDDI Executive Overview: Enabling Service-Oriented Architecture, Oct. 2004, http://uddi.org/pubs/uddiexec-wp.pdf. [5] Andrews, T., Curbera, T. et al.: Business Process Execution Language for Web Services Version 1.1, May 2003, ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf. [6] Web Services and Service-Oriented Architectures, http://www.service-architecture.com. [7] Kavantzas, N., Burdett, D., Ritzinger, G.: Web Services Choreography Description Language Version 1.0, Editor’s Draft, Apr. 2004, http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427. [8] Clark, J., Casanave, C. et al.: ebXML Business Process Specification Schema Version 1.01, May 2001, http://www.ebxml.org/specs/ebBPSS.pdf. [9] Arkin, A.: Business Process Modeling Language, Nov. 2002, http://www.bpmi.org/bpml-spec.htm. [10] Thatte, S.: XLANG, 2001, http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm. [11] Leymann, F.: Web Services Flow Language (WSFL 1.0), May 2001, http://www306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf. [12] Arkin, A., Askary, S. et al.: Web Service Choreography Interface (WSCI) 1.0, Aug. 2002, http://www.w3.org/TR/wsci. [13] Workflow Process Definition Interface – XML Process Definition Language, Final Draft, Oct. 2002, http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf. [14] Papadopoulos, G. A., Arbab, F.: Coordination Models and Languages. In: Selkowits, M. (Ed.): Advances in Computers, Vol. 46: The Engineering of Large Systems, Academic Press, 1998, pp. 329-400. [15] Stroulia, E., Wang, Y.: Structural and semantic matching for accessing web-service similarity. International Journal of Cooperative Information Systems, Oct. 30, 2004. [16] Zaremski, A. M., Wing, J. M.: Specification Matching Components, ACM Transactions on Software Engineering and Methodology, Vol. 6, No. 4, Oct. 1997, pp. 333-369. [17] Cherchago, A., Heckel, R.: Specification Matching of Web Services Using Conditional Graph Transformation Rules, 2004, pp. 304-318. [18] Langville, A. N., Meyer, C. D.: A Survey of Eigenvector Methods for Web Information Retrieval, Society for Industrial and Applied Mathematics, Vol. 47, No. 1, pp. 135-161. [19] R. Tolksdorf, “Coordinating Services in Open Distributed Systems With LAURA”, in P. Ciancarini and C. Hankin (eds), First International Conference on Coordination Models, Languages and Applications (Coordination’96), Cesena, Italy, 15-17 April, 1996, LNCS 1061, Springer Verlag. pp. 386-402
