End-User Programming Language for Service- Oriented Integration

Transcription

1 1 End-User Programming Language for Service- Oriented Integration Ivan Gavran Faculty of Electrical Engineering and Computing, University of Zagreb, Croatia Abstract The paper presents a new approach to End User Development of large-scale distributed applications based on the Service Oriented Computing. We have designed Simple Service Composition Language (SSCL), a simple programming language for Web Service composition. SSCL is a statementbased language designed for process-oriented Web Service composition based on Service Oriented Programming Model (SOPM). SSCL language has been developed as part of Programmable Internet Environment 1 (PIE), an end-user framework for design, development, and execution of distributed applications in Internet environment. In addition, we have designed and implemented distributed translator for translating the SSCL language into CL language, which is an extension of Business Process Execution Language For Web Services (BPEL4WS). The process logic description of the generated CL code is ready for execution in any BPEL4WS compliant environment. Keywords: service-oriented computing, end-user programming, service composition I. INTRODUCTION Large-scale Internet-based distributed systems are one of the most popular forms of computing systems adopted by end-users. However, there are no available tools that can be used by end-users in order to tailor the systems to their own personal requirements and expectations. End-users need the support to build new systems easily by incorporating functionalities of available systems and services. The End User Development (EUD) is one of the fields in computing that researches new techniques in software development that will promote end-users from software users to software developers. One of research aspects of EUD is development of new end-user programming languages. End-user languages should be easy to adopt and give prominence to design with reusable computing. Service-Oriented Computing (SOC) is the paradigm for distributed computing that utilizes services as fundamental elements for application development. It represents a new approach in application development moving away from tightly coupled monolithic systems towards systems of 1 The Service-Oriented Programming Model, Coopetition Distributed Architecture, Simple Service Composition Language, and Programmable Internet Environment are developed at the School of Electrical Engineering and Computing at the University of Zagreb, Croatia, in cooperation with Ericsson Nikola Tesla d.d., Zagreb, Croatia, and cosponsored by Ministry of Science, Education, and Sports through the national Cro-Grid project. More information is available at: and loosely coupled, dynamically bound components. Systems built using SOC are expected to dominate the next generation of enterprise business systems, grid systems, sensor and actuator networks, and other ubiquitous computing systems. In addition, we believe that SOC paradigm is well-suited for end-user programming. SOC is based on Web Services, which are autonomous, selfdescribing, and platform-independent computational elements. For the purpose of developing massively distributed interoperable applications, Web Services are described, published, discovered, composed, and programmed using a standard set of programming languages and protocols. In Service-Oriented Computing, a distributed application is built as an interconnected collection of existing Web Services. In order to describe the service collections and their interconnections, a wide range of Web Service composition languages have been developed [3]. The goal of the service composition languages is to glue Web Services together and describe coordination logic of service invocations. Service-Oriented Programming Model (SOPM) [18] is a new methodology for design, development, and execution of large-scale service-oriented applications. SOPM introduces three-tiered coordination architecture that enables integration of distributed applications through cooperation and competition without the use of centralized control mechanisms. In order to support design, development, and execution of distributed applications in Internet environment we have developed the end-user development framework called Programmable Internet Environment (PIE). The execution of distributed applications in the PIE framework is based on the platform independent language CL (Coopetition Language) [16]. CL is an extension of BPEL4WS [5,7] language that integrates the BPEL4WS process description and WSDL descriptions of invoked services within a single compact document. Since the CL language is derived from BPEL4WS and WSDL languages that are based on XML, programs developed using the CL language have complex and extensively large structure. Thus, the CL language is not suitable for use by end-users. In this paper, we present SSCL (Simple Service Composition Language) programming language that is also a part of PIE framework. SSCL is an end-user programming language for service composition based on SOPM. In addition to developing the language, we have also designed and implemented distributed SSCL Program Translator.

2 2 SSCL Program Translator translates SSCL program code into the CL code. Following the overview of service composition languages presented in Section II, the Section III presents the SSCL language and its features. Section IV describes the SSCL Program Translator. Finally, Section V concludes the paper and outlines the main directions of future work. II. BACKGROUND Composition of services is described in terms of service orchestration and service choreography. Orchestration defines composite application logic by describing services message level interaction and execution order of the interactions within a single application process. Choreography tracks the sequence of messages that may involve multiple parties and multiple sources, including customers, suppliers, and partners. Compared to the orchestration, choreography is concerned with the public message exchanges that occur between multiple services, rather than a specific application process that is executed by a single party. As SOC developed, a number of languages for service orchestration and choreography have been introduced: BPEL4WS, BPML, WSFL, XLANG, BPSS, WSCI, and WSCL [4]. One of the wider accepted languages for service choreography is Web Services Choreography Interface (WSCI). The WSCI is an extension of Web Service Description Language (WSDL) [6]. It defines the message exchange between Web Services, but does not describe the controlling process that manages their interaction. The WSCI specification defines message correlation, sequencing rules, exception handling, transactions, and dynamic collaboration. BPEL4WS is a widely adopted and standardized language for service orchestration. It is a process description language suitable for defining workflows consisting of Web Service invocations. Professional programmers use BPEL4WS to define a collection of Web Services and to describe the coordination of their activities. BPEL4WS is built as a layer on top of the WSDL. WSDL is used to define the specific operations that are allowed, while BPEL4WS defines how the operations are sequenced. Language CL [16] is a lightweight process description language used for development of distributed applications based on SOPM. It is a compact combination of BPEL4WS and WSDL. The program written in CL language is structured as an XML document consisting of three separate sections. The first section of CL language includes the description of program's process logic. The description is written using a subset of the BPEL4WS language. The second section of CL program is the WSDL description of its interface. The third section of a CL program consists of a set of WSDL documents that describe the interfaces of external services invoked by the distributed program. In order to make programming with the service composition languages easier, a number of graphical programming environments have been developed, including WebSphere Studio [10], Oracle BPEL Process Manager [11], WebMantra [12], and Triana [13]. However, these tools do not successfully hide all complexity of underlying Web Services technologies from end-users. In order to create composite services using the graphical tools, the endusers still need to be familiar with standard Web Services technologies like BPEL4WS, SOAP [14], and WSDL. III. SERVICE ORIENTED PROGRAMMING MODEL Service-Oriented Programming Model (SOPM) is a new methodology for development of SOA applications. Services comprising a distributed application perform local actions without the use of centralized control and mutually cooperate and compete in order to reach the global goals of the application. Distributed applications based on SOPM principles are implemented using the tree-tiered distributed coordination architecture that consists of Application services, Coopetition services and Distributed programs. Example of a distributed application built using the threetiered coordination architecture is presented in Figure 1. The example in Figure 1 consists of three distributed programs that invoke five application services and use two coopetition services. Figure 1 Example of three-tiered distributed coordination architecture Application services implement coarse fragments of computational logic. The application services are usually delivered on-demand through globally accessible network. Alternatively, Application services can be custom developed for specific application in order to provide necessary functionalities. Coopetition services [17] are pre-built services of the SOPM environment that are used for coordination and communication of the Application services. The developed coopetition services consist of Semaphore, MailBox and EventChannel. For instance, MailBox provides the mechanism for persistent asynchronous communication between services using the message-oriented communication model. Distributed programs [16] handle cooperation and competition between Application services. They use Coopetition services in order to bind individual activities performed by Application services into a distributed application. Distributed programs are specified in a process description language CL (Coopetition Language) [16]. The Programmable Internet Environment (PIE) is an enduser development framework for building and running SOPM applications over Internet infrastructure. PIE provides facilities that enable installation and uninstallation

3 3 of Application and Coopetition services, as well as interpretation of Distributed programs in the Internet environment. PIE offers simple Web-based tools for creation and deployment of SOPM applications. The composition of services is based on the end-user language SSCL (Simple Service Composition Language). conditional expression, the control-flow primitives reference the decision service name and a set of program variables. IV. SIMPLE SERVICE COMPOSITION LANGUAGE Since the BPEL4WS is a comprehensive XML-based language with a complex syntax rules, developing distributed systems using CL is a time-consuming and errorprone process. Therefore, we have designed a new programming language for service composition, called Simple Service Composition Language (SSCL). As SSCL is primarily intended for end-users, its syntax is simple but expressive enough to enable process modeling through Web Service composition. In contrast to majority of WS orchestration and choreography languages that are XML based, the SSCL is a statement-based textual language with simple syntax rules. Each SSCL primitive abstracts multiple BPEL4WS instruction blocks. Thus, SSCL programs hide all complexity of XML data handling, partner link definitions and initialization, SOAP message initialization, and other BPEL4WS programming constructs barely understandable to the end-user programmers. An SSCL program consists of a simple sequence of SSCL primitives. Three types of primitives are supported: service invocation, control-flow, and inter-service synchronization and communication A. Service Invocation and Control-Flow Primitives Since the purpose of SSCL is to describe the service composition as a set of service invocations, its basic primitive is invoke. Figure 2 presents the format of an invoke primitive and the equivalent code written in BPEL4WS. Parameters of the invoke primitive include service identifier and its IP address, operation identifier, input variable, and output variable. The equivalent BPEL4WS code consists of three parts. First part is used to initialize the partner link that corresponds to the invoked service. Second part is used to construct the SOAP request message by using a set of assignment blocks. Finally, third part is used to invoke the service and store the returned value. As shown in this example, SSCL significantly reduces the complexity and size of service composition programs, and improves their expressiveness and readability. Although BPEL4WS supports advanced data handling and variable manipulation by use of special instruction blocks and XPath expressions [15], the SSCL does not provide the equivalent support. All data handling and variable manipulations are out of scope of SSCL and need to be implemented as specialized Web Services. Example of specialized Web Services are decision services invoked as part of a control-flow construct in order to calculate the value of a conditional expression. SSCL provides two control-flow constructs: if-then-else conditional branching and while conditional looping. As a substitution for the Figure 2 Comparison of Service Invocation in SSCL and WS-BPEL Described approach simplifies the adoption of SSCL, because the end-user does not need to learn and use the XPath language. Simplified data handling in SSCL is based on two variable types, textual and Boolean variables. The textual variables contain any textual data including XML. They are primarily used to store constants and the output of a service and provide the input to another service. The Boolean variables store the values that are calculated by a decision service and are used in control-flow primitives. B. Synchronization and Communication Primitives In addition to the basic subset of BPEL4WS functionalities, SSCL contains an additional set of primitives for describing the decoupled inter-service communication and synchronization. Communication and synchronization primitives include the primitives for handling semaphores, mailboxes, and event-channels. Semaphore, mailbox, and event-channel are implemented as part of PIE framework [17]. Semaphore is used for service synchronization and resource protection. Mailbox is used for decoupled, asynchronous messageoriented communication between services. Finally, eventchannel is an advanced communication mechanism that supports event-driven inter-service communication based on publish-subscribe model. Since their implementation is based on the standard Web Services protocol stack, they can be easily integrated in other service-oriented systems. TABLE 1INTER-SERVICE SYNCHRONIZATION AND COMMUNICATION PRIMITIVES Table I presents the set of implemented SSCL primitives. All primitives include at least two parameters, which specify

4 4 the service IP address and service instance identifier. For each synchronization and communication service there are two primitives used to create and destroy individual instances of the related service. Two primitives are used for interaction with semaphore. ObtainSemaphore is a blocking primitive that suspends the SSCL program execution until the semaphore is obtained. ReleaseSemaphore is a non-blocking primitive that releases the semaphore without suspending the SSCL program execution. Mailbox communication is based on two primitives, PutMessage and GetMessage. Parameter message_body of the PutMessage primitive defines a SSCL variable that contains the body of the message. Similarly, parameter in_var of the GetMessage primitive defines the SSCL variable that stores the received message. All messages are text-based and enable exchange of any XML-based data. Event-channel is accessed using three primitives for handling events and two primitives for handling subscriptions. Publish, RePublish, and UnPublish primitives are used to publish, update, and remove events respectively. These primitives include parameter event that references the variable containing the text-based description of an event. Subscribe and UnSubscribe primitives are used to subscribe and unsubscribe to and from a specific set of events. These primitives include two parameters that reference the resource ID and IP address of external event interpreter that performs advanced contentbased analysis of events. Figure 3 presents an example of inter-service communication and coordination. The example consists of three SSCL programs that use mailbox and semaphore services for communication and synchronization. Three SSCL programs, A, B, and C, are executed in parallel on nodes 1, 3, and 5. Mailbox service is hosted by Node 2, while semaphore service is hosted by Node 4. Web Services X and Y, which implement custom application logic, are hosted by nodes 6 and 7. SSCL programs A, B, and C describe the way in which Web Services X and Y are invoked in order to achieve the overall goal of the distributed application. SSCL program A executed on Node 1 and SSCL program B executed on Node 3 communicate through the mailbox hosted by Node 2. SSCL program A uses the PutMessage primitive to send messages to the mailbox at Node 2. Node 3 reads the messages by using the GetMessage primitive. Service X, SSCL programs A and C need to obtain the semaphore by using the ObtainSemaphore primitive. After the service X is invoked, the semaphore is released by using the ReleaseSemaphore primitive. V. SSCL PROGRAM TRANSLATOR In order to leverage the wide adoption of BPEL4WS language and ensure the open-ended integration, we have built the distributed program translator that translates SSCL code to CL code. SSCL Program Translator has been designed and implemented as a distributed service-oriented application in order to provide the scalable and fault-tolerant environment for SSCL translation. The translated programs generated by SSCL Program Translator are scheduled for execution on the distributed CL Interpreter that is part of PIE framework. Distributed CL Interpreter is implemented as a loosely coupled collection of Web Services that translate and execute programs written in Coopetition Language, which is derived from BPEL4WS language. A. SSCL Program Translator Architecture SSCL Program Translator architecture consists of two main components, Program Queue and Translator Pool. Program Queue is used to buffer SSCL programs, while the Translator Pool consists of a set of SSCL translators. Program Queue is the entry point to Program Translator implemented as a system-wide queue that stores SSCL programs. SSCL programs are scheduled for compilation by simple insertion into the Program Queue. SSCL translators register with the Program Queue, acquire the SSCL programs, and translate them to CL programs. Thus, the Program Queue provides a simple FIFO scheduling mechanism that schedules SSCL programs to the first available SSCL translator. Figure 3 Inter-service Communication and Synchronization Example Semaphore hosted by Node 4 ensures synchronized access to Web Service X. In order to invoke the Web Figure 4 Distributed Program Translator SSCL Translator Pool consists of a set of loosely coupled instances of SSCL translators. Figure 4 presents an example of a Translator Pool consisting of three SSCL translators

5 5 that are installed on distinct nodes. SSCL translators continuously execute the three-step process in which an SSCL Program is read from the Program Queue, translated to CL program, and scheduled for execution on distributed CL Interpreter. SSCL Program Translator provides the scalable and loadbalanced environment for translation of SSCL programs. Scalability and load balancing are achieved by use of the Translator Pool, which enables dynamical changes to the number of translators. Scalability is achieved by adding new translators to the Translator Pool. Translators automatically achieve load balancing by competing to fetch programs stored in Program Queue. Furthermore, Translator Pool provides basic fault-tolerance. If a fault occurs on one of the translators, the other translators continue the program translation process. SSCL Translator and Program Queue are implemented using the Web Services set of standards. Therefore, they can be used in interaction with any distributed system based on SOC. B. SSCL Translation Process The SSCL translation process is presented in Figure 5. It consists of source SSCL program analysis and generation of target CL program. SSCL code analysis verifies the lexical, syntax, and semantic correctness of the program. While performing semantic analysis, WSDL descriptions of all invoked Web Services are fetched from service registry. WSDL descriptions are necessary for semantic analysis and verification of source program. Furthermore, fetched WSDL documents are used during CL program generation. program interface contains callback methods necessary for asynchronous invocation of Web Services operations. Finally, generated BPEL4WS process description, CL program interface description, and collected Web Services interface descriptions are stored in XML document structured by CL language rules. The generated CL program can be directly executed by the distributed CL Interpreter that is part of PIE framework. Moreover, the BPEL4WS process description of generated CL program can be executed by any other BPEL4WS execution environment. VI. CONCLUSION In this paper, we present a new end-user service composition language named Simple Service Composition Language. SSCL is used as a foundation of PIE that provides tools for fast and simple design and implementation of SOPM applications. SSCL is a statementbased language with simple lexical and syntax rules, which ensure higher readability than XML based service composition languages. SSCL provides a small set of primitives used to invoke services, define the process workflow, and describe the decoupled inter-service communication and synchronization. We have designed, developed, and tested SSCL Program Translator that translates the SSCL code into CL code. Program Translator is implemented as a distributed and loosely coupled system that supports scalability and faulttolerance. In addition to improving SSCL programming language and SSCL Program Translator, our future work will focus on design and development of a browser-centric programming environment that will provide the comprehensive support for service-oriented end-user programming. REFERENCES Figure 5 SSCL Translation Process Three stages of CL program generation are BPEL4WS process description generation, generation of CL program interface description, and integration of WSDL descriptions of all Web Services invoked in source program. BPEL4WS process description is generated from analyzed SSCL code. All additional information necessary for BPEL4WS process definitions are available in WSDL documents collected during the source code analysis. Description of CL program interface is generated as a WSDL document. The CL [1] B.W. Boehm, B. Clark, E. Horowitz, C. Westland, R. Madachy, and R. Selby: "Cost models for future software life cycle processes: COCOMO 2.0.", Annals of Software Engineering, Special Volume on Software Process and Product Measurement, Volume 1, Number 1, J.C. Baltzer AG Science Publishers, Amsterdam, Netherlands, 1995, pp [2] "Web Services architecture overview the next stage of evaluation for e-business", IBM Research 2000, ibm.com/developerworks/webservices/library/w-ovr/?dwzone =webservices [3] W.M.P. van der Aalst, M. Dumas i A.H.M. ter Hofstede: "Web Service Composition Languages: Old Wine in New Bottles?", Proceeding of the 29th EUROMICRO Conference, Belek near Antalya, Turkey, September 2003, pp [4] C. Peltz: "Web Services Orchestration and Choreography", Computer, Vol. 36, No. 10, October 2003, pp [5] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic i S. Weerawarana. "Business Process Execution Language for Web Services (BEPL4WS) 1.1", May 2003, ( 106.ibm.com/developerworks/webservices/library/ws-bpel). [6] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana: "Web Services Decription Language (WSDL) 1.1", World Wide Web Consortium (W3C) Note, February 2001, ( [7] A. Arkin, S. Askary, B. Bloch, F. Curbera, Y. Goland, N. Kartha, C. K. Liu, S. Thatte, P. Yendluri, and A. Yiu: "Web Services Business Process Execution Language Version 2.0", Working Draft, December 2004,

6 open.org/committees/download.php/10347/wsbpel-specificationdraft htm [8] G. Fischer, E. Giaccardi, Y. Ye, A. G. Sutcliffe, and N. Mehandijev: "Meta-design: A Manifesto for End-User Development", Communications of ACM, Vol. 47, No. 9, September 2004, pp [9] I. Morch, G. Stevens, M. Won, M. Klann, Y. Dittrich, and V. Wulf: "Component-based Technologies for End-User Development", Communications of ACM, Vol. 47, No. 9, September 2004, pp [10] W. Butt: "Programmatic control of a long-running BPEL process with WebSphere Studio", websphere/library/techarticles/0410_butt/0410_butt.html [11] Oracle BPEL Process Manager, bpel_home.html [12] WebMantra, webmantra.html [13] S. Majithia, M. Shields, I. Taylor and I. Wang: "Triana: A Graphical Web Service Composition and Execution Toolkit", Proceedings of ICWS'04, San Diego, California, June 2004, pp [14] D. Box and others: "SOAP 1.1", World Wide Web Consortium (W3C) Note, February 2000., ( [15] J.Clark and S. DeRosso: "XML Path Language (XPath) Version 1.0", World Wide Web Consortium (W3C) Recommendation, November 1999, [16] D. Skrobo, A. Milanović, and S. Srbljić: "Distributed Program Interpretation in Service-Oriented Architectures", Proceedings of the 9th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI'05), Orlando, Florida, USA, 2005, Vol. 4, pp [17] A. Milanović, S. Srbljić, D. Skrobo, D. Čapalija, and S. Rešković: Coopetition Mechanisms for Service-Oriented Distributed Systems, Proceedings of the CCCT 2005 (The 3rd International Conference on Computing, Communications and Control Technologies), Austin, Texas, USA, July 2005, Vol. 1, pp [18] A. Milanović: "Service-Oriented Programming Model", Ph.D. thesis in Croatian, Original title "Programski model zasnovan na uslugama", School of Electrical Engineering and Computing, University of Zagreb, Croatia, [19] Programmable Internet Environment, 6