Article Preview
TopIntroduction
Service oriented architecture (SOA) has evolved to become a promising technology for the integration of disparate software components using Internet protocols. These components, called Web Services (WS), are available in the distributed environment of the Internet. Organizations attempt to provide their own services through complex tasks, which can be resolved using a combination of several web services. For automatically selecting and composing services in a well-behaved manner, information about the services has to be exposed. Usually, web services are published by giving their public description behavior in a repository, such as Universal Description, Discovery and Integration (UDDI), in order to make possible the collaboration with potential requesters. In particular, this information must be sufficient to decide whether the composition of two services is possible. However, organizations usually want to hide the trade secrets of their services. Thus, for a given service, they need to find a proper abstraction of the process of the service (a.k.a. abstract process) or of its behavior, which should be published instead of the service itself. Therefore, an abstraction should satisfy trade-off between two opposite requirements. On the one hand, it should respect the privacy of the underlying organization. On the other hand, it should enclose enough information to allow the collaboration and the communication with potential partners in a correct way. To compose Web services, in this paper, we address the checking of their compatibility using their abstractions. This mainly raises the following research questions:
- •
How to abstract the internal behavior of Web services while preserving necessary information for service composition and hiding private information?
- •
How to use abstractions for service composition such that correctness, regarding a given good property, of the composition of Web services (involving internal behavior) is detected from the analysis of the composition of their corresponding abstractions?
- •
What are the good properties preserved by abstraction we consider in this paper?
The compatibility of two or more Web services may consider compatibility of parameter (inputs/outputs) at the syntactical level as well as the semantic level. It may also consider the behavioral aspects with several possible behavioral properties. While we believe that the compatibility of parameters is an important issue, the behavioral compatibility discussed here is complex enough in itself to deserve separate treatment.
Different approaches have been proposed to describe the web services’ behavior by proposing an abstraction technique. Among other abstraction approaches, the Symbolic Observation Graph (SOG) approach, initially introduced for model checking of concurrent systems (Haddad, Ilié, & Klai 2004) and then applied to the verification of inter enterprise business (Klai & Ochi, 2012; Klai, Tata et al., 2009), is promising. A SOG is a graph whose construction is guided by a subset of observed actions. The nodes of a SOG are aggregates hiding a set of local states which are connected with non observed actions. The arcs of a SOG are exclusively labeled with observed actions. Thus, we propose to use SOGs as abstraction of web services. By observing the collaborative activities (or actions) of a web service, publishing a SOG as an abstraction allows to hide its internal behavior inside the aggregates. The strength of such an approach is that a SOG associated with a web service represents a reduced abstraction of its reachable state space while preserving its behavioral properties.
To check the compatibility of two web services, which is necessary for their composition, we propose to check the compatibility on the composition of their SOGs instead of the whole composite service (which is unavailable anyway). We formally represent a web services by an oWF-net (Massuthe, Reisig et al., 2005). We define two kinds of compatibility properties between Web services: generic and specific properties. Generic properties are dependent on neither the model of Web service nor the considered business domain. While specific properties are described in terms of precise elements (states, actions, events, etc.) of the Web service.