A loosely coupled architecture for automatic composition of web services applications
Juan Carlos Zuñiga* Electronic Systems Engineering Department, University of São Paulo, Av. Prof. Luciano Gualberto, S/N Trav.3, No. 158, CEP 05508-900, São Paulo, SP, Brazil Email: [email protected] *Corresponding author
José J. Pérez-Alcázar and Luciano A. Digiampietri School of Arts, Sciences and Humanities, University of São Paulo, Av. Arlindo Bettio 1000, CEP 03828-000, São Paulo, SP, Brazil Email: [email protected] Email: [email protected]
Silvio Ernesto Barbin Telecommunications and Control Engineering Department, University of São Paulo, Av. Prof. Luciano Gualberto, S/N Trav.3, No. 158, CEP 05508-900, São Paulo, SP, Brazil Email: [email protected]
Abstract: Semantic web research aims to provide mechanisms to combine several web services to offer a new value-added service that satisfies the user’s request. A number of methods and tools have been proposed for this purpose. However, none of these approaches offers a complete solution from the standpoint of a decoupled, inter-organisational, domain-independent and ready for use by end users who do not have an in-depth technical knowledge. To overcome these limitations, this paper provides a loosely coupled architecture to develop applications based on web services composition, in which architectural modules can be integrated in different ways, ranging from inter-organisational sources, which support different levels of automation and composition methods, to diverse application domains. We described the input and output requirements for each module and implemented the following decoupled modules: interface (for non-technical users), translator (using the ANTLR tool), composer (using a hierarchical planner) and executor (based on workflows).
Keywords: SOA; service-oriented architecture; web service composition system; semantic web services; web services applications.
Reference to this paper should be made as follows: Zuñiga, J.C., Pérez-Alcázar, J.J., Digiampietri, L.A. and Barbin, S.E. (2014) ‘A loosely coupled architecture for automatic composition of web services applications’, Int. J. Metadata, Semantics and Ontologies, Vol. 9, No. 3, pp.241–251.
Biographical notes: Juan Carlos Zuñiga received his PhD in Electrical Engineering from the University of São Paulo. His research interests are related to web services, service composition and semantic web.
José J. Pérez-Alcázar is a Professor at the School of Arts, Sciences and Humanities, University of São Paulo. He received his PhD in Computer Science from the Pontifical Catholic University of Rio de Janeiro. His research interests are related to artificial intelligence, databases, information systems and software engineering.
Luciano A. Digiampietri is a Professor at the School of Arts, Sciences and Humanities, University of São Paulo. He received his PhD in Computer Science from the University of Campinas. His research interests are related to semantic web, databases, social network analysis, scientometrics and scientific workflows.
242 J.C. Zuñiga et al.
Silvio Ernesto Barbin is a Professor at Polytechnic School of the University of São Paulo. He received his PhD in Electrical Engineering from the University of São Paulo. His current research interests are in cognitive radio, reconfigurable systems and antennas, and wireless systems protocols.
1 Introduction
In the past few years, a new phenomenon called Web 2.0 has become popular and there has been a huge expansion in websites such as Facebook, MySpace, YouTube and LinkedIn. With Web 2.0 technology, a wide range of web applications, web services and APIs for service creation, sharing and reuse of content have emerged. These tools have allowed specialists (such as IT programmers, service providers or sophisticated users) to create new services and mashup applications (a combination of existing web applications from different sources) (Daniel et al., 2011).
Nevertheless, Web 2.0 technologies still have serious limitations. The most obvious is the problem of finding relevant information or an application for a specific user (Medjahed and Bouguettaya, 2011). When it is taken into account that web services and web applications (mashups, workflows, etc.) are developed for a general purpose, the problem of finding relevant information for a specific user is more complex in terms of automation, because the user explores many services or applications manually to find one service that may fully or partially satisfy one’s requests. Another problem is volatility, because the user can spend a lot of time and effort looking for service that may not be available (in execution time).
The automatic composition of web services can be seen as an evolution of the traditional web service-based systems for information integration (Medjahed and Bouguettaya, 2011), because it provides many benefits in areas such as e-business, e-government, e-science and knowledge management (Medjahed and Bouguettaya, 2011). The goal of this kind of system is to compose several web services automatically and thus produce new services, with added value, that satisfy the user’s request (Medjahed and Bouguettaya, 2011).
Over the past few years, several studies have proposed methods and tools for the automatic composition of web services (Sycara et al., 2003; Kuzu and Cicekli, 2010; Digiampietri et al., 2007; Agarwal et al., 2005). However, none of these approaches offers complete solutions from the following standpoints: decoupling, because architectures, methods and tools are designed for a specific functionality; inter-organisational, because the use of different sources of web services or service applications is not supported; domain-independent, because proposed methods and tools have been developed for specific domains and it is very hard to create new applications for other domains based on them; and easy-to-use for non-technical users, because the current proposals offer interfaces that require a technical knowledge to handle the users’ request or to select and compose services. These issues are addressed by the design principles of service-oriented systems (Erl, 2009).
Owing to the absence of these characteristics in current approaches, this paper outlines the specific features of a loosely coupled architecture for the automatic composition of web service applications, in which the modules of the architecture can be integrated in different ways. This supports different levels of automated and composition methods, and domain-independent applications for various kinds of users. The proposed architecture describes the input and output requirements for each module and implemented the following decoupled modules: interface (which supports non-technical users); translator (using the ANTLR tool); composer (using a hierarchical planner); and executor (based on workflows).
The remainder of this paper is structured as follows: Section 2 presents basic concepts. Section 3 describes the implementation requirements for each of the modules of the architecture. Section 4 addresses the implementation issues and contains the details of the interface, translator, composer and executor modules. Section 5 describes the Bravo Air case study. Section 6 examines related work and Section 7 summarises the conclusions and makes recommendations for future work.
2 Basic concepts
Service-Oriented Architecture (SOA) is an effective way of building loosely coupled web service composition systems, because SOA is loosely coupled and able to reuse the existing services, incorporate new services into the system, and build new applications in a flexible way (Pei and Chen, 2011).
In software engineering, the basic design principle of modularity involves the decomposition of software architecture into modules characterised by high cohesion and low coupling (Pautasso and Wilde, 2009). Coupling measures the interdependencies between two modules and it can be assumed that a low degree of coupling can help aid the understanding and support the evolution of a system (Pautasso and Wilde, 2009). Thus, the architecture for automatic web service composition based on SOA must be composed of loosely coupled modules. Moreover, it should be possible to integrate these modules in ways that can be adapted to create different web service applications by means of different levels of automation and composition methods, which support a wide range of application domains and various kinds of users.
The level of automation in web service composition systems can be categorised as: manual, semi-automatic or automatic (design time), and static or dynamic (runtime) (Dustdar and Schreiner, 2005). In the manual composition, the process containing the description of the execution flow and logical reference to web services is designed by a human designer. One problem of manual composition is the
A loosely coupled architecture for automatic composition 243
size, dynamics and flexibility of the web, this process is especially complex and prone to errors. Hence, it should not be carried out by a human designer. The automatic approach replaces the manual process with algorithms (e.g. artificial intelligence planning algorithms) to handle the automatic generation of a web service composition plan. Web service composition can be regarded as a semi-automated approach, if one of the following cases is met: (a) automatic discovery and selection activities to assist in the implementation of the manual composition plan or (b) manual discovery and selection activities that constrain the automatic composition plan (Li et al., 2010).
In the literature, dynamic and automatic concepts usually are treated separately (Beek et al., 2006). Li et al. (2010) state that static and dynamic service composition classifications can be applied to automatic and manual composition approaches. Dynamic service composition represents the ability of the system (at runtime) to replace or replan the solution plan when any service is unavailable (e.g. an invalid URL); as a result, if the system does not have this ability or requires the intervention of a user, it is considered to be static.
Moreover, because the context of web services is volatile and uncertain, anything defined at design time can change at runtime, which makes the manual and static composition impractical for web service environments. To select between a semi-automatic and automatic composition approaches depends on the application domain that will be implemented. For example, in an enterprise application, the user’s request generally has well-defined inputs, outputs and objectives. In this case, the automatic approach takes advantage of the fact that the request is well defined. In e-commerce applications, the user’s request (concern) can be changed on the basis of the discovery or selected services; for this case, a semi-automatic approach is more appropriate. Thus, a dynamic approach is a desirable characteristic for any composition system.
In an automatic composition process, the flow is set automatically by means of the semantic web (an ontological model that allows the semantic description of the web services (Berners-Lee et al., 2001)) and inference mechanisms or techniques to reasoning over the semantic descriptions of the services (Rao and Su, 2004).
Ontological models, such as OWL-S (Web Ontology Language for Services) (Martin et al., 2004), WSMO (Web Services Modelling Ontology) (Fensel et al., 2007) and WSDL-S (Web Service Description Language for Services) (Akkiraju et al., 2005) provide a formal interpretation (abstract model) for the development, discovery and execution of semantic web services. OWL-S is an ontology based on Ontology Web Language (OWL) for the definition of web services. Among the inference mechanisms, we highlight those based on AI planning (Russel and Norvig, 2003) and workflows (Casati et al., 2001).
The most widely used inference mechanisms or techniques for reasoning that are linked to the automatic composition of web services research are those based on AI
planning (Ghallab et al., 2004). The planning area has evolved in terms of its efficiency, the sophistication of its algorithms and its potential use in real-world applications (Long and Fox, 2002). As a result, this kind of solution became popular, and several proposals can be found in the literature. Planning techniques are based on situational calculus (McIlraith and Son, 2002), on hierarchical planning (Hierarchical Task Networks-HTN) (Sirin and Parsia, 2004), on Symbolic Model Checking (SMC) (Traverso and Pistore, 2004; Cimatti et al., 2003), or in the Markov Decision Processes (MDP) (Doshi et al., 2004).
Proposals based on situational calculus and HTN can fit within the proposals for automatic composition but not for dynamic composition, because they do not take account of non-determinism in the web environment. On the other hand, proposals based on MDP and SMC generate plans with contingencies (by using conditionals and iterations) that allow a degree of adaptability to the environment at runtime. The proposal based on HTN has the advantage of its scalability because it can make use of the service taxonomies defined in the semantic web. Hence, mixing HTN techniques with SMC or MDP is a promising approach. With these types of proposals, it is possible to obtain a dynamic and automatic web services composition system. Proposals of this kind already exist in the literature, and as examples we can mention YoYo (Kuter et al., 2009), which mixes HTN planning with SMC, and Markov HTN which mixes HTN and MDP (Reiff-Marganiec et al., 2009).
The composition methods also can be classified into three categories (Digiampietri et al., 2011): the first is called syntactical which uses task-interface matching (matching the output of one task with the input of the next). It is appropriate for systems that implement data transformation flows but takes account only of the data types of inputs and outputs, without considering semantics in the matching.
The second category, called semantic composition, is an extension of the first and considers the semantics that are related to the services. In this approach, the interface matching uses the semantic concepts associated with each input and output. This is carried out by using domain ontologies to annotate the inputs and outputs of the services. The use of domain ontologies is also a useful means of handling services from different domains, because it avoids the production of composed services that are semantically incorrect. Oh et al. (2007) proposed a system that provides these two kinds of compositions.
The third kind of composition method is called functional which involves the use of pre-conditions and post-conditions. This allows a service to declare, in an explicit way, the state of the world and its changes. Shin et al. (2009) state that only with this characteristic a system can address the users’ requests in a suitable way. Although this approach is more complete and allows a wide range of representations and verifications, it involves two complex procedures: the specification of the services and sharing these services among different users and systems. This is because it needs a shared vocabulary and a shared
representation of state variables (Digiampietri et al., 2009). The functional composition method is appropriated for composition systems that use inter-organisational sources of web services.
Before starting the service composition, it is necessary to have a clear goal (user’s request) of what is to be performed so that the composition can be carried out. Constraints and preferences can serve as additional criteria to select services for the composition plan. The level of automation is closely linked to the level of detail used to specify the goal. A well-defined goal is more appropriate for an automatic approach. Users without knowledge of the domain generally need guidance with the system through a series of stages (in a semi-automatic approach) before they can finish a composition task. Moreover, the composition method is closely linked to a number of inter-organisational domains, i.e. workflows have been applied to a few domains that have a well-defined process. For multiple domains with diverse kinds of functionalities, AI planning algorithms are more appropriate.
3 Loosely coupled architecture for automatic composition of web services applications
The semantic web improves the current web by increasing automation and accuracy in various areas such as: search,
information extraction and information integration (Medjahed and Bouguettaya, 2011). Automatic composition of web services can be seen as an evolution of the traditional web-based systems for information integration (Rao and Su, 2004). The goal of this kind of system is to compose several web services automatically so that new services can be produced with added value, which satisfy the users’ requests (Medjahed and Bouguettaya, 2011).
The aim of this work is to develop a loosely coupled architecture for the automatic composition of web services applications, by following the design principles of service-oriented systems (Erl, 2009). In carrying this out, we improved the architecture presented in the work of Rao and Su (2004), to enable the modules of the architecture to be integrated in different ways, from inter-organisational sources. They then could support different levels of automation and different composition methods, for diverse application domains and different kinds of users.
The loosely coupled architecture (as shown in Figure 1) consists of seven modules and two repositories: end-user and administrative interface, discovery, translator, compositor, evaluator, and executor (modules), and ontology (domain and service) and invoked service repositories. Each decoupled module should describe its requirements (the input and output parameters), constraints and functionalities so that it can allow the modules of the architecture to be integrated in different ways.
Figure 1 Loosely coupled architecture for automatic composition of web services applications (see online version for colours)
A loosely coupled architecture for automatic composition 245
The end-user interface module functionalities are responsible for the interaction between the users and the composition system. This module allows the user to specify requests and provides the user with the results produced by the system. The input parameters are generated by the interaction between the user and the system. The input parameters specify the relevant domains that the users require as constraints and preferences. The input parameters must be translated (abstracted) so that they can create semantic specifications of the goals. The output parameter is the created goal for the user’s request. The goal can be implemented by using the WSMO goal specification (Fensel et al., 2007). The WSMO goal specification has a rich semantic description for specifying user’s objectives. The end-user interface module can be implemented by employing a user-friendly and dynamic graphical interface (i.e. it is able to adapt automatically to different application domains) for non-technical users.
The discovery module is searched by an appropriate service for achieve a specified goal (a user’s request). Searching services can be carried out by using matching techniques. In WSMO, the goal description is a subset of the web service description. We consider two descriptions that may or may not match when a set of relevant objects for a goal or web service description match at either a semantic or functional level. If a service is found, this module sends it to the executor module. Whenever it is found that no service satisfies the goal, the discovery module forwards the request to the translator module and asks for a composed task to enable it to fulfil the request. The input parameter is a goal. The output parameter can be the same goal or service (the name of the service that satisfies the user’s request).
The translator module allows a translation to be made from the semantic descriptions (which can use ontologies, goals, etc.) to the language understood by the compositor module. The input parameters are the goal, the ontology and the services associated with the selected application domain. The output parameter is the specification request (written in the language understood by the compositor module implementation). For example, if the compositor module uses an AI planning algorithm as its composition technique, the translation process creates a problem domain, an initial state, and a description of a planning domain.
The compositor module is the reasoning module of the system. It receives a request and produces one or more solution plans (solutions are composed of web services that satisfy the user’s request). A solution plan can be a workflow or a list of services. The solution plans are sent to the evaluator module which will choose the one that best suits the user’s request. The input parameters can be a specification request in a supported composition technique language. The output parameters can be either solution plans (one or more) or a failure message (when no solution plan can be produced).
The evaluator module takes into account the non-functional properties of the services that compose the solution plans and chooses the one that best suits the user’s request. A sophisticated evaluation and selection procedure
can be obtained by means of quality of services techniques (Agarwal et al., 2005). QoS techniques evaluate non-functional properties such as cost and reputation. The input parameters contain one or more solution plans. The output parameter is the best solution plan.
The executor module is responsible for executing the chosen services and returns the results to the user. A plan is an ordered list of activities that must be executed to achieve a given goal. The executor accepts two kinds of inputs: a workflow represented in specific workflow syntax or a plan drawn up by the planner. The output parameters are the information resulting from the execution of the workflow/ plan.
The administrative interface module is responsible for the interaction which involves authenticated users managing the system. The input parameters of this module are domain and service ontology files (created for third-party ontology modelling tools, such as Protégé or WSMO studio), and web services (invocation level) files. The output parameter is a confirmation message about the files stored in the respective repositories.
The domain and service ontology repository stores ontologies and semantic services within the system databases. Each element of ontology is stored as a field. The ontologies play two main roles in the system: they are used to annotate all of the inputs and outputs of each web service, and the users’ requests are defined as ontology concepts, i.e. the user selects a set of concepts that defines user’s goals.
The service repository stores the web services definition files (written in WSDL language) and the annotation of these services. Each service operation and its inputs and outputs are annotated semantically with the ontology concepts.
4 Implementation issues
The interface modules (end-user and administrative) and executor module were implemented in Java. The translator module uses the ANTLR plug-in (Edgar, 2011). The WSMO ontological model was used for the prototype implementation (which uses WSML). The compositor module uses SHOP2 (Nau et al., 2003), a hierarchical task network planner. The implementation of these modules will be described in the following subsections.
4.1 Administrative interface
The graphical interface allows the authorised user (e.g., administrator) to upload and store WSML (web service modelling language) documents (describing ontologies, services and mediators) in the repository of the composition system. Each of these documents is linked to some application domains, such as to travel or bioinformatics. An application domain is represented by one or more ontologies. From the user’s standpoint, an application domain represents a topic or subject of related activities in which a user can make a request to achieve a given goal.
To make it easier for non-technical users to employ the system, each ontology uploaded into the system must be linked to a representative graphic icon, so that the user’s requests can be expressed graphically in an intuitive way. Figure 2 represents the graphical management interface.
Figure 2 Graphical administrative interface (see online version for colours)
The WSML documents are stored as Java objects. These objects contain the descriptions of the concept types, variables and functional and non-functional properties from the original WSML documents. These objects are stored in databases, which assists the dynamic creation of the interface procedures for requesting goals and showing results.
4.2 End-user interface
The end-user interface module was designed to allow an easy and dynamic interaction with non-technical users. By means of this interaction, this module aims to abstract the functionality desired by the user and convert it into a formal
request (goal) that is specified in WSML. Other functionalities of this module include account access control and showing the results of the users’ requests. This module was developed by following the recommendations for Graphic User Interface (GUI).
4.2.1 Goals and requests graphical interface
This interface allows the user to specify a request. It is dynamically created and takes account of the application domain selected by the user. Moreover, the interface tries to keep the concepts and goals at a high level of abstraction to allow non-technical users to make their requests in a simple and clear way.
The first graphical formulary of this interface asks the user to select the category (application domain) in which the user wants to make requests. When a category is selected, the form is updated with a list of icons that represent the concepts and services linked to the domain ontology, as illustrated in Figure 3a. The selection of these icons represents iterative refinements in the user’s request. For example, if the user wants to travel, he/she must choose the corresponding category and, among the icons related to this category, he/she should refine this request. This will indicate the payment option (e.g. credit card), the type of transport (e.g. train) and how he/she wants to be sent the tickets (e.g. by post). An example is shown in Figure 3a.
After selecting the icons that represent concepts in the ontology, the user presses the ‘Next Step’ button, which leads to the second form of the interface. This form allows the user to specify certain values (instances of the ontology) that are linked to the icons previously chosen. For example, for the selected icons in the travelling application domain (train travel and delivery of tickets), the form will ask for information such as departure city, arrival city, date and time of departure, and the desired system for the delivery of the tickets. All of this information can be filled up in the form as shown in Figure 3b.
Figure 3 Goals and requests graphical interface (see online version for colours)
(a) (b)
A loosely coupled architecture for automatic composition 247
This second form is produced dynamically and includes the application domain and the icons previously selected by the user. Finally, when the user presses the ‘Next Step’ button again, the automatic composition process begins, and a goal (the user’s request) is formally specified in WSML (where a WSML goal document is produced). It should be noted that the complexity of the request refinement and, thus, the complexity of the composed service, are proportional to the number of icons selected by the user.
4.2.2 Results graphical interface
The results graphical interface is responsible for showing to the user the results produced by the executor module. The resulting form is constructed by following the same logic employed in the goal request form, i.e. Java objects are used in a way that corresponds to the web services executed (the web services selected by the automatic composition system), their post-conditions and effects.
In the example shown in Figure 3, the resulting from notifies the departure and arrival cities, the possible travel dates, the costs and payment options and the ticket delivery options (Figure 4). If the planner or executor modules are unable to produce or execute a plan, a message is sent to the user, and the execution reverts to the goals and request graphical interface.
Figure 4 Resulting graphical interface (see online version for colours)
4.3 Translator
The translator module was based on compilers by means of the ANTLR tool (Parr, 2007). To achieve this, grammars were constructed to represent the languages involved in the translation process.
In the current implementation of these modules, the languages used are WSML, which allows the semantic description of domains and users’ requests, and a Planning Domain Definition Language (PDDL), which is used as input to enable the planner to produce the desired composed services. Three grammars were developed: one to represent WSML, one to represent PDDL and one to describe the translation mechanism.
The grammar that represents the WSML language describes the lexical and syntactical analyser for WSML, after it had been interpreted for the ANTRL compiler of compilers. When a WSML document (ontology or goal) is submitted, the ANTLR IDE constructs the syntactical tree that corresponds to the input document and then validates this document.
The grammar that represents the translation mechanism carries out the mapping between WSML and PDDL. It considers the lexical and syntactical trees that are produced from the WSML (ontology and goals) and translates them to PDDL (domain definitions and planning problems). For each element or structure in WSML, this grammar contains the mapping description required to translate these elements to PDDL.
A PDDL grammar was developed to validate the produced PDDL documents. Thus, every PDDL is validated by the ANTLR IDE before it is sent to the executor module. The entire translation process flow chart is shown in Figure 5.
4.4 Composer
The composer module uses SHOP2 (Nau et al., 2003), a hierarchical task network planner. The input that this receives consists of the specifications of the domain and the problem described in PDDL (generated by the translator); as a result, it attempts to produce a plan (workflow) to solve the problem. The use of planning makes it possible to adopt the semantic and functional composition approaches described in Section 2.
4.5 Executor
The executor module is responsible for receiving and executing a workflow. A new thread is created to invoke and execute each of the workflow’s activities concurrently. The current version of the workflow engine allows the execution of three types of activities: web services, methods written in Java and local applications. In addition to the execution of workflows, this module allows the user to create, import, edit and export a workflow.
In our system, a workflow consists of activities; each activity contains a set of connectors (inputs and outputs). There are two possible types of flows between the activities: data flow, when the input of one activity receives the output of another activity; and control flow, when one activity can be executed only after another activity has completed its execution. An interface known as the activity executor enables the interface to carry out each kind of activity allowed in the system, and thus this module contains three implementations of the activity executor interface.
The executor module has a checking function, which is responsible for verifying three aspects of the workflow that are ready to be executed. These aspects: (a) syntactic and semantic compatibility of the data flows, which checks if each data flow is syntactically (i.e. compatible data types are used) and semantically (i.e. concepts that are ontologically compatible are used) compatible; (b) an absence of circular dependencies among the activities, to avoid infinite loops; and (c) the filling of all of the activities with input data (each one of the input connectors can be filled with the output of another activity or with the input information received from the interface module or by the user).
Figure 5 Translation mechanism (see online version for colours)
The workflow engine receives a workflow and executes each activity with a new thread. The activities, respecting the dependencies (data and control flows), are executed concurrently. Each kind of activity is invoked/executed dynamically, and to do this, the workflow engine uses reflection. Another functionality of the executor module is to receive a plan (an ordered set of tasks produced by the planner) and creating a workflow based on it. The creation of the workflow proceeds through the following stages: each task from the plan is converted to an activity in the workflow by maintain the same order in which they appear in the plan. The system seeks to find a compatible kind of data in the output of the previous activities for each input of the previously created activity. After this automated creation, the user is asked to fill the remaining inputs and to check if the flows have been created correctly.
As well as executing workflows inside the system, there are two ways of exporting the workflows as Java code. In the first, the code is exported together with the workflow engine. This functionality allows the user to share the executable code of the workflows without executing the entire workflow module (which includes a graphical environment). The workflow is executed in the same way it is carried out inside the system (i.e. concurrently). In the second way, the workflow is exported as a regular Java code without the workflow engine. The advantage of this is that the code is exported in a simpler and more efficient way (when memory use and execution time are taken into account). However, there are two restrictions on this approach: (a) the current version of the system does not allow workflows that use web services to be exported in this way, and (b) the produced code is executed sequentially.
On the basis of our loosely coupled architecture, we are able to design three web applications. With the aid of the end-user interface, it is possible to create well-defined user’s requests such as a WSMO goal. These goals can be used for recommended systems to analyse the user interests and thus to suggest products or services. The end-user interface and discovery module can be used and configured to function as an asynchronous ShopBot system where the discovery module search engine offers a unique service that matches the user’s requests. A web service composition system enables different domain applications to be combined (e.g. hotel, airport, travel, renting a car) so that a new web application can be created and executed to satisfy the user’s interests.
5 The Bravo Air case study
Bravo Air (Lara et al., 2003) is a fictitious airline website. It provides web services for the reservation of trips as a composite process and consists of the following stages: retrieval of the desired flight details, selection of available flights and booking of the selected flights. This includes the sub-stages: login and confirmation of reservation.
The Bravo Air process is a composed process, consisting of two atomic processes: GetDesiredFlightDetails and SelectAvailableFlight, and a composed process BookFlight. BookFlight is also a composed process consisting of two atomic procedures: Login and ConfirmReservation (Lara and Roman, 2004).
The GetDesiredFlightDetails collects information, for example about airports, preferred times and round trips. The SelectAvailableFlight obtains the user’s preferred flight choice from the available itineraries. Login obtains user details and carries out the authentication procedure, and the ConfirmReservation confirms the selected reservation.
Figure 6a shows the resulting flow chart for Bravo Air. The composer module draw up a plan with the following sequence of web services: getFlightInformation, selectFlight, login and confirmation. This plan meets the user’s request for a composed service with which the user can visualise available flights, make a selection and confirm the flight.
The plan is read by the executor and the workflow is produced (displayed in Figure 6a). In this diagram, each rectangle represents an activity (in this example, all the activities are web services), the grey arrows are control flows and the black arrows are data flows. The user is asked to fill the details to supply the workflow inputs so that some parameters can be defined, such as departure airport, arrival airport and departure date. If the user wants to change the values of the input parameters the user must double click on the activity and complete the corresponding form. The right-hand side of Figure 6b shows the form of the activity called getFlightInformation.
This workflow is carried out as follows: the getFlightInformation activity is executed when the input data have been filled in by the user in the interface module. After this, the user selects the desired flight from among those available (this selection is the input of selectFlight). The result of the execution of this last activity is used as an input of confirmation, but this activity can be carried out only after the user is logged into the system (using the login activity).
A loosely coupled architecture for automatic composition 249
Figure 6 Graphical visualisation of the bravo air workflow (see online version for colours)
(a) (b)
6 Related work
Several studies in the past few years have proposed methods and tools for the automatic composition of web services (Sycara et al., 2003; Kuzu and Cicekli, 2010; Digiampietri et al., 20007; Agarwal et al., 2005). These studies have focused on the development and optimisation of many different types of algorithms and procedures for handling the composition process. However, they have failed to take into account the importance of interacting with the end users (system interface).
Chahoud (2006) and Silva (2008) provide two tools for the automatic composition of web services with GUIs. These GUIs require users to have some technical knowledge, and this constrains the use of these tools by end users. Moreover, these GUIs were designed for a specific case study. Santos et al. (2011) offer a tool for supporting dynamic service provisioning. This tool was designed to target the non-technical service client. However, this tool does not solve the problem of the automatic composition process.
When comparing the related work with our proposed interface modules, we attempt to base our study on the level of abstraction of the GUI. This seeks to be more intuitive and simpler for users lacking technical skills, and to be more dynamic in the sense that our GUI can automatically build forms for different domain applications.
OWLS2PDDL stands out from the few tools that allow the translation of semantic languages (such as OWL-S and WSML) for languages used for the composition module (e.g. PDDL). This is a composition tool that implements a translator component called OWLS2PDDL (Gerber and Klusch, 2009) that translates from OWL-S to PDDL.
Sirin et al. (2004) present an algorithm that allows the translation of OWL-S syntax to a hierarchical planning language that is understood by the JSHOP2 planner (Ilghami, 2006). The Aimo translator (Tabatabaei et al., 2010) is a tool that allows the translation of WSML syntax to HTN. However, all of these tools implement algorithms for reading the syntax of semantic languages (OWL-S and WSML) and translate line by line, by using tables of equivalences, to an equivalent document in the specified planning language.
Our translator module is based on a compiler approach, which makes this implementation different and more sophisticated when compared with related studies. This compiler approach also allows the translation and validation of documents by means of lexical and syntactic analysis. Furthermore, the use of grammars allows their reuse and makes possible translation to other languages, such as PPDDL, which is the language for planning problems in non-deterministic domains.
The translator module was designed in a decoupled way and formed part of an undergraduate project (Pierin, 2011) that led to its subsequent integration into the proposed architecture of this paper. The decoupled translator module is available online.1
Karunamurthy (2009) presents an architecture for composition of web services based on three modules: a communication module, a composition module and a request processing module. The communication module is responsible for accessing the service repository. Zhang et al. (2009) provide a semantic SOA for enterprise application integration, using the WSMO ontological model and WSMX (Web Service Execution Environment). This architecture is composed of three services: the service user, service discovery and service provider. The service user allows the user’s request to be specified. The service discovery interacts with the domain ontology repository and the service provider is responsible for the services invocation.
Song (2010) outlines a framework for web service composition, which divides every composition process into two basic modules: the composition generation and the execution of web service composition. The composition generation module produces a composed web service. It is responsible for pre-processing the user’s request, setting out composition instructions, selecting the semantic web service from the web service repository and optimising it, as well as generating a composition web service to satisfy the user’s request. The execution module undertakes the second phase of the web service composition; its main task is to execute the composed web services.
Kuzu (2009) outlines an architecture for service composition adapted from the work of Rao and Su (2004). This architecture has five modules: translator, process generator, service repository, evaluation and execution engine. The translator module interacts with the service requester for an external specification. An AI planner (namely the Simplanner) is used in the composition process.
Our loosely coupled architecture has seven modules and two repositories. This number of modules, which is larger than what is considered in related work, represents the principles of SOA and decoupled systems. Thus, our approach is a complete solution from the standpoint of decoupled systems because the modules of the architecture can be integrated in different ways. For example, the architecture can disable the discovery and evaluator modules by simplifying the composition processes or by integrating the end-user interface and discovery and execution modules and thus create a system for search information. Alternatively, the automatic composition module can be removed and the user will be able either to compose workflows manually or in a semi-automatic way.
7 Conclusions and recommendations for future work
This paper has outlined a loosely coupled architecture for the automatic composition of web services. In terms of inter-organisational and domain-independent requirements, this architecture can be applied and adapted for use in different domain applications. The end-user interface module provides a user-friendly and dynamic graphic interface for non-technical users (who are able to adapt automatically to different domain applications). The users’ requests must be translated (abstracted) so that semantic specifications of goals can be created. The compositor and executor modules were designed to support implementations for different levels of automation and composition.
In future work, we intend to develop and compare different composition methods and algorithms for automatic composition, discovery and recommendation of semantic web services.
Acknowledgements
This work was partially supported by FAPESP, CAPES and CNPq.
References
Agarwal, V., Chafle, G., Dasgupta, K., Karnik, N., Kumar, A., Mittal, S. and Srivastava, B. (2005) ‘Synthy: a system for end to end composition of web services’, Web Semantics: Science, Services and Agents on the World Wide Web, Vol. 3, No. 4, pp.311–339.
Akkiraju, R., Farell, J., Miller, J., Nagarajan, M., Sheth, A. and Verma, K. (2005) WSDL-S: Web Service Semantics, Technical Report, World Wide Web Consortium – W3C.
Beek, M., Bucciarone, A. and Gnesi, S. (2006) A Survey on Service Composition Approaches: From Industrial Standards to Formal Methods, Technical Report, 2006-TR-15, Istituto di Scienza e Tecnologie dell’Informazione, Consiglio Nazionale delle Ricerche.
Berners-Lee, T., Hendler, J. and Lassila, O. (2001) ‘The semantic web’, Scientific American, Vol. 284, No. 5, pp.35–43.
Casati, F., Sayal, M. and Shan, M. (2001) ‘Developing e-services for composing e-services’, Proceedings of the 13th International Conference on Advanced Information Systems Engineering (CaiSE), Springer Verlag.
Chahoud, J.J. (2006) Planejamento para Serviços Web Semânticos, Master’s Thesis, Instituto de Matemática e Estatística da Universidade de São Paulo.
Cimatti, A., Pistore, M., Roveri, M. and Traverso, P. (2003) ‘Weak, strong, and strong cyclic planning via symbolic model checking’, Artificial Intelligence, Vol. 147, Nos. 1/2, pp.35–84.
Daniel, F., Matera, M. and Weiss, M. (2011) ‘Next in mashup development: user-created apps on the web’, IT Professional, Vol. 13, No. 5, pp.22–29.
Digiampietri, L.A., Pérez-Alcázar, J.J., Freitas, R.S., Araújo, J.C., Ostroski, É.H. and Santiago, C.R.N. (2011) Uso de Planejamento em Inteligência Artificial para o Desenvolvimento Automático de Software’, Autonomous Software Systems (AutoSoft, 2011), São Paulo, SP, Brazil.
Digiampietri, L.A., Pérez-Alcázar, J.J. and Medeiros, C.B. (2007) ‘AI planning in web services composition: a review of current approaches and a new solution’, VI Encontro Nacional de Inteligência Artificial, Anais do XXVII congresso da SBC, pp.983–992.
Doshi, P., Goodwin, R., Akkiraju, R. and Verma, K. (2004) ‘Dynamic workflow composition using Markov decision processes’, IEEE International Conference on Web Services, pp.576–582.
Dustdar, S. and Schreiner, W. (2005) ‘A survey on web services composition’, International Journal of Web and Grid Services, Vol. 1, pp.1–30.
Erl, T. (2009) SOA Design Patterns, Prentice Hall.
Edgar, E. (2011) ANTLR IDE. Available online at: http:// antlrv3 ide.sourceforge.net/ (accessed in February).
Fensel, D., Lausen, H., Polleres, A., Bruijn, J., Stollberg, M., Roman, D. and Domingue, J. (2007) Enabling Semantic Web Services: The Web Service Modeling Ontology, Springer-Verlag, New York, Inc., Secaucus, NJ, USA.
Gerber, A. and Klusch, M. (2009) OWLS2PDDL, Technical Report, Sem Web Central. Available online at: http://projects. semwebcentral.org/projects/owls2pddl/
Ghallab, M., Nau, D. and Traverso, P. (2004) ‘Planning based on Markov decision processes’, Automated Planning Theory and Practice, pp.379–403.
Ilghami, O. (2006) Documentation for JSHOP2, Technical Report, Department of Computer Science, University of Maryland.
Karunamurthy, R. (2009) Web Service Composition: Architecture, Frameworks, and Techniques, PhD Thesis, Concordia University, Canada.
Kuter, U., Nau, D., Pistore, M. and Traverso, P. (2009) ‘Task decomposition on abstract states, for planning under nondeterminism’, Artificial Intelligence, Vol. 173, Nos. 5/6, pp.669–695.
A loosely coupled architecture for automatic composition 251
Kuzu, M. (2009) Automatic Web Service Composition with AI Planning, Master’s Thesis, Middle East Technical University.
Kuzu, M. and Cicekli, N.K. (2010) ‘Dynamic planning approach to automated web service composition’, Applied Intelligence, pp.1–28.
Lara, R. and Roman, D. (2004) ‘A conceptual comparison of WSMO and OWL-S’, Proceedings of the 2004 European Conference on Web Services, Vol. 3250, pp.254–269.
Lara, R., Roman, D., Polleres, A. and Fensel, D. (2003) OWLS 1.0 Release – Examples Bravo Air Fictitious Airline Site, Technical Report. Available online at: http://www.daml.org/ services/owl-s/1.0/examples.html
Li, Z., O’Brien, L., Keung, J. and Xu, X. (2010) ‘Effort-oriented classification matrix of web service composition’, International Conference on Internet and Web Applications and Services, pp.357–362.
Long, D. and Fox, M. (2002) ‘Progress in AI planning research and applications’, Upgrade, Vol. 3, pp.10–25.
Martin, D., Burstein, M., Hobbs, J., Lassila, O., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N. and Sycara, K. (2004) OWL-S: Semantic Markup for Web Services, Technical Report, World Wide Web Consortium – W3C.
McIlraith, S.A. and Son, T.C. (2002) ‘Adapting Golog for composition of semantic web services’, 8th International Conference on Principles of Knowledge Representation and Reasoning, Toulouse, France.
Medjahed, B. and Bouguettaya, A. (2011) Service Composition for the Semantic Web, Springer, New York.
Nau, D., Au, T., Ilghami, O., Kuter, U., Murdock, W., Wu, D. and Yaman, F. (2003) ‘SHOP2: an HTN planning system’, Journal of Artificial Intelligence Research (JAIR), Vol. 20, pp.379–404.
Oh, S-C., Lee, D. and Kumara, S.R.T. (2007) ‘Web service planner (WSPR): an effective and scalable web service composition algorithm’, International Journal of Web Service Research, Vol. 4, No. 1, pp.1–22.
Parr, T. (2007) The Definitive ANTLR Reference: Building Domain-Specific Languages, Pragmatic Bookshelf Series, Pragmatic.
Pautasso, C. and Wilde, E. (2009) ‘Why is the web loosely coupled? A multi-faceted metric for service design’, 18th International World Wide Web Conference, pp.911–920.
Pei, S. and Chen, D. (2011) ‘Implementation of web services composition system based on SOA’, International Conference on Uncertainty Reasoning and Knowledge Engineering, Vol. 2, pp.82–85.
Pierin, F.L. (2011) Desenvolvimento de um tradutor WSML para PDDL no contexto de um sistema de composição automática de serviços web, Trabalho de Conclusão do Curso (Sistemas de Informação) – Escola de Artes, Ciências e Humanidades, Universidade de São Paulo.
Rao, J. and Su, X. (2004) ‘A survey of automated web service composition methods’, Proceedings of the 1st International Workshop on Semantic Web Services and Web Process Composition (SWSWPC), San Diego, USA.
Reiff-Marganiec, Chen, S. and Xu, J. (2009) ‘Markov-HTN planning approach to enhance flexibility of automatic web services composition’, IEEE International Conference on Web Services ICWS, pp.9–16.
Russel, S. and Norvig, P. (2003) Artificial Intelligence: A Modern Approach, 2nd ed., Prentice-Hall.
Santos, L., Sorathia, V., Pires, L. and Sinderen, M. (2011) ‘towards a conceptual framework to support dynamic service provisioning for non-technical service clients’, Journal of Software, pp.564–573.
Shin, D-H., Lee, K-H. and Suda, T. (2009) ‘Automated generation of composite web services based on functional semantics’, Web Semantic, Vol. 7, No. 4, pp.332–343.
Silva, M.V.A. (2008) TRANSPLAN: Uma Solução para Mapear e Planejar Serviços Web Semânticos, Master’s Thesis, Universidade Federal da Bahia, Laboratório de Sistemas Distribuídos.
Sirin, E. and Parsia, B. (2004) ‘Planning for semantic web services’, Semantic Web Services Workshop at 3rd International Semantic Web Conference, Sanibel, FL, USA, pp.33–40.
Sirin, E., Parsia, B., Wu, D., Hendler, J. and Nau, D. (2004) ‘HTN planning for web service composition using SHOP2’, Journal of Web Semantics, Vol. 1, No. 4, pp.377–396.
Song, G. (2010) ‘A new approach for web service composition based on semantic’, 2010 International Conference on Computational Intelligence and Software Engineering (CiSE), pp.1–4.
Sycara, K., Paolucci, M., Ankolekar, A. and Srinivasan, N. (2003) ‘Automated discovery, interaction and composition of semantic web services’, Web Semantics: Science, Services and Agents on the World Wide Web, Vol. 1, No. 1, pp.27–46.
Tabatabaei, S.G.H., Kadir, W.M.N.W., Ibrahim, S. and Dastjerdi, A.V. (2010) ‘AIMO translator: bridging the gap between semantic web service discovery and composition’, Proceedings of the 5h International Conference on Internet and Web Applications and Services, IEEE Computer Society, pp.268–273.
Traverso, P. and Pistore, M. (2004) ‘Automated composition of semantic web services into executable processes’, Lecture Notes in Computer Science, Vol. 3298, pp.380–394.
Zhang, L., Zhou, S. and Zhu, M. (2009) ‘A semantic service oriented architecture for enterprise application integration’, 2nd International Symposium on Electronic Commerce and Security (ISECS’09), pp.102–106.
