Discrete Event Models for Web Service Processes

Discrete Event Models for Web Service Processes

Yuhong Yan (Concordia University, Canada) and May Haydar (Université de Montréal, Canada)
DOI: 10.4018/978-1-4666-0249-6.ch006
OnDemand PDF Download:
No Current Special Offers


Web service processes are business processes composed of individual Web services. Web service process description languages, used in both choreography and orchestration, are influenced by techniques from workflow modeling, formal methods and software engineering. Since such languages are based on software scripts to be executed by a process engine, their expressive power indeed is beyond classic discrete event system models, such as process algebra and Petri nets. This chapter analyzes and compares different Web service process description languages, discusses the issues in using discrete event system models to model Web service processes, and also compares Web service processes with workflow processes. The chapter also discusses the suitable methods based on the formal models for various computing tasks, such as verification and validation.
Chapter Preview

1. Introduction

Service computing views business entities as service providers and models business processes as compositions of multiple services. Service-Oriented Architecture (SOA) and Web services are two related concepts in Service computing. In W3C documents, SOA typically refers to Web services (Booth, Haas, McCabe, Newcomer, Champion, Ferris, & Orchard, 2004) and the two terms are interchangeable. Some practitioners tend to regard SOA as a more abstract concept that is not bound to any specific technology, while Web services are an instantiation of SOA bound with W3C specifications (Gudgin, Hadley, Mendelsohn, Moreau, Nielsen, Karmarkar, & Lafon, 2004; Booth & Liu, 2007). What is agreed on is the roles and operations in the SOA/WS triangle (Figure 1). The SOA/WS triangle represents the common principle of SOA and Web services. The service providers first publish their service descriptions into a registration server. The service requestors can look up the registration to choose suitable services. Then the service requestors can directly interact with the service providers by sending messages to them. The service description can also be stored by the service providers rather than stored in a registration server.

Figure 1.

The SOA/WS triangle


Indeed Web services are the only available implementation of SOA. The discussion in this paper is based on the current Web service techniques. A Web service is defined by the W3C as a software system designed to support interoperable machine-to-machine interaction over a network (Haas, & Brown, 2004). It has an interface described in a machine-processable format (mainly WSDL). Other systems (including similar services) interact with the Web service in a manner prescribed in its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards1. The W3C Web service technical stack in Figure 2 lists some of the supporting techniques and specifications for Web services. The communication layer normally uses Internet protocols, such as HTTP, SMTP, FTP. Some other transportation methods like JMS and IIOP can also be used. However, this lowers interoperability. A given message may even involve multiple kinds of message transport. However, since all messages are structured according to SOAP, we can incorporate overall message reliability within the SOAP message structure. Message reliability is most often achieved via an acknowledgement infrastructure, which is a set of rules defining how the parties to a message should communicate with each other concerning the receipt of that message and its validity. WS-Reliability and WS-ReliableMessaging are examples of specifications for an acknowledgement infrastructure that leverage the SOAP Extensibility Model. WSDL is exploited at the interface layer to indicate the end point of a service and to describe the operations of a service and the types and number of parameters for invoking an operation. UDDI (OASIS, 2005) is a service discovery protocol that supports service registration and look-up. Many more specifications are generated to regulate a specific aspect of Web services, e.g., security, Qo, transaction, etc. These specifications are not a concern in this chapter. The process description layer contains several languages for describing the process of how the services interact with each other for a task. Process description languages are investigated in this chapter.

Figure 2.

The technical stack for Web services


Complete Chapter List

Search this Book: