DynaComp: a Framework for dynamic composition of semantic web services *Hajar Elmaghraoui, th
Mohammed V University-Agdal Mohammadia High School of Engineers (EMI) Rabat, Morocco
[email protected]
Abstract Nowadays, e-government has emerged as a government policy to improve the quality and efficiency of public administrations. In order to improve government-citizen interactions, the government agencies are providing a wide spectrum of online services. However, a single service may not be able to serve citizens’ needs, but a combination of web services can serve the purpose. It is an important task to solve the problem of finding such a combination, called Web Service Composition. Building composite web services can save significant time and cost for developing new applications and enhancing the interoperability and collaboration among administrations. This paper proposes a Framework for dynamic composition of web services using an approach based on modeling the semantic relationship between the involved web services through a directed graph. It takes into consideration functional and nonfunctional attributes to enable the computation of relevant and most suitable service compositions for some service request. Keywords-component; web service; semantic; dynamic composition; floyd-warshall; e-government; dependency graph
I.
INTRODUCTION
Many countries around the world are attempting to strengthen and revitalize the quality and the efficiency of its government and make it more service oriented. In the last decade, electronic (e-) government has emerged as a solution to the problems of traditional public administrations such as high costs, poor quality services and corruption. E-government is the use of information technology to enable and improve the efficiency with which government services and information are provided to citizens, employees, businesses, and government agencies. By deploying public services via the Internet, communication is made easier for citizens and businesses, resources are federated, and finally are sped up substantially. Furthermore, adopting web services enables government agencies to provide value-added services through the service composition process. Web service composition allows flexible creation of new services by assembling independent and reusable service components. One of the big challenges in service composition is the provision of dynamic and personalized composition of web services.
Laila Benhlima, Dalila Chiadmi Mohammed Vth University-Agdal Mohammadia High School of Engineers (EMI) Rabat, Morocco
[email protected],
[email protected]
In this paper, we propose a Framework for personalized, automatic and dynamic composition of web services using an approach based on modeling the semantic relationship between all the available web services through a weighted directed graph built before the composition runtime. It takes into consideration not only functional attributes of services, but also nonfunctional attributes to enable the computation of relevant and most suitable service compositions. The rest of this paper is structured as follows. Section 2 gives an architectural overview of our approach. Section 3 defines the main components of DynaComp Framework. The last two sections present the related work and conclusions. II.
DYNACOMP FRAMEWORK
Existing systems for dynamic web service composition compose services at runtime which is time and resource consuming, and they don’t involve user preferences when requesting a service, so the results are usually unsatisfactory. DynaComp Framework is a global solution that involves both service providers (administrations) and users (citizens). Indeed, in the e-government context, each department has its own web service repositories and uses their own formalism to describe available services. This leads to interoperability problems when trying to compose services owned by different departments. To deal with this problem, DynaComp uses an interpreter to extract the needed information from services repositories independently of formalisms used by providers to publish their services. The second advantage of our Framework is optimization. Dynamic web service composition is known to be an expensive process. To reduce the cost, DynaComp performs the composition before runtime execution. By maintaining a repository of pre-computed service compositions, the platform optimizes time execution. Last but not least, DynaComp return more satisfying e-services since it involves user profiles during the request and execution phase. Interoperability, automation, optimization and personalization are the key issues to a successful e-government Framework. To present our Framework for dynamic web service composition, we first introduce the notion of service composition life-cycle for dynamic service composition.
A. Service Composition life cycle The service composition life-cycle can be divided into four phases: 1) Service Request Phase The service request phase consists of the definition of the desired service properties and goals. These parameters are then used during the discovery and the composition processes. 2) Service Discovery Phase The service discovery phase analyzes the service request of the consumer and finds involved services that fulfill the requirements specified by the user in the service request phase.
•
The graph representation allows creating mappings between the service composition representation and executable composition languages.
C. DynaComp architecture The architecture of DynaComp Framework (Figure 1) complies with the composition life cycle phases outlined in section A. Next, we explain the process flow.
3) Service Composition Phase If we fail to find services that meet all the requirements specified by the consumer during the discovery phase, we seek in the composition phase to automatically compose services that will help provide an answer to the user query. 4) Service Execution Phase During the Service Execution phase, the service composition representation is translated into an executable representation, and then deployed into a service composition execution engine. B. General Properties Before introducing DynaComp components, we first present some general properties and requirements of the Framework. To enable automatic reasoning, the processed information in DynaComp should be represented in a machine readable format. To accomplish this, we use semantic web services [1] and ontologies [2] for service creation description, service request description and also for service discovery and the construction of service compositions. Although the creation and publication of services are not directly part of the composition process, Public administrations when describing and publishing their services, have to comply with ontologies that define the conceptualizations of the application domains being supported (E-government). The components of the Framework are designed to be technology independent. Given that structural representations are a technology independent design, we represent a web service by a Tuple (an ordered list of elements) and web service composition by a dependency graph: • The Tuple representation allows creating mappings between the service description languages and the internal representation of services used by the Framework. Services can be created in different technologies and described in different service description formalisms; however, to allow their discovery and composition, they have to describe the same properties and parameters that comply with the service representation considered in the service registry and in the Framework components.
Figure 1. DynaComp Framework
Before Composition Runtime: We suppose that the creation and the publication of services in the Registry happen outside our Framework. However, to meet the DynaComp requirements, services have to use the concepts of the Framework Domain Ontologies in order to be semantically described in terms of functional properties (inputs, output, preconditions, post-condition and goals) and non-functional properties (quality of service parameters). Pre-computing Service Composition Paths: The elements surrounded by the dotted rectangle in Figure 1 are important components of our solution. They are responsible for precomputing all possible combinations between available services in the Registry and storing the best possible service combinations in the Dependency Graph Repository [3]. These operations are performed at the design time (before executing user queries). This leads to reduce the complexity and time needed to generate and execute a web service composition. During composition Runtime: After the receipt of the user request, it is converted into a Tuple containing a set of functional and non-functional properties that allow discovering services. Then the discovery process checks the Registry to see if any existing single web service matches the request parameters. If yes, then the service is executed and results will be returned to the Consumer. Otherwise, the Service Discovery checks the Composite service Repository, which stores previously created composite service plans and user requirements, to check if any of them can fulfill the user’s requirements. If yes, the identified composite service is
confirmed and executed, and results will be returned to the Service Consumer. Otherwise, the Service Composer queries the Dependency Graph Repository to check if any existing web service composition path matches the request. Once an optimal service composition path is extracted, it is passed on to the Composition Plan Builder. The generated plan is stored in the “Composite Service Repository” for future reuse. Finally, this plan is converted into an executable process and executed by the “Composite Service Executor”; the response will be returned to the Service Consumer. III.
DYNACOMP COMPONENTS
A. Service SpecificationEextractor This component contains an interpreter for the service description language (WSDL) that parses the WSDL document and collects the necessary information we need to generate web services dependency graphs. This makes the service representation in the DynaComp Framework language-neutral. In fact services can be described in different languages or formalisms, and we just need to add an interpreter for each supported service description language. The extracted information is then stored in the Service Specification Repository, which is a knowledge base that contains necessary information about available web services in the Service Registry. This operation is done automatically each time new services are published or existing services are changed or removed from the repository. The main information we are considering in this work are IOPEs (inputs, outputs, preconditions, and effects), goals and non-functional parameters. Thus, a service is represented as a nine tuple S=< ID, DESC, EP, I, O, P, E, G, NF > where: ID: The service identifier, DESC: A natural language description of the service, EP: The location for accessing a web service, I: The set of service inputs (what the web service requires to produce the expected output), O: The set of service outputs (what the web service supplies as an answer to a request), P: The set of service preconditions (what a web service expects in order to be able to provide its service), E: The set of service effects (describes the result of the web Service in relation to the input, and conditions on it), G: The set of goals the service realizes, NF: The set of service nonfunctional properties and constraint values. B. Dependency Graph Constructor There are three components in the Dependency Graph Constructor: 1) Dependency Graph Generator We model the service compositions using a weighted directed graph [3]. The modeling choice of using a graph relies on the fact that the topology of service compositions can easily be mapped into a graph structure. Services are represented as nodes, and the composition of services as edges. Graph theory is a mature area of research, which means that there are many techniques to handle and verify properties of graphs, which in our context is extremely relevant. For example, each time we add a new service to a service composition, or node to the
graph, we could verify if such an operation does not lead to deadlock situations. Furthermore, there are many existing programming libraries and tools to handle graphs, which facilitate the development of prototypes to validate our approach for dynamic service composition. Our focus is to identify explicit direct dependencies between services and construct Service Dependency Graph (SDG). In this work, we consider that a web service can be described by two sets of properties: (i) functional and (ii) nonfunctional properties. The functional properties (IOPE) describe what the service can do and the non-functional properties (QOS, context) depict how the service can do it. Thereafter we mean by Inputs, the service inputs and preconditions and we mean by Outputs, the service outputs and Effects. We start from services specifications stored in the Specification Repository. We use the semantic description of IOPE parameters to build the SDG. In fact, for a set of services, we need to check if two services S1 and S2 are to be invoked in sequence during the composition process (Figure 2). Thus, an explicit direct Inputs/Outputs dependency between the two services (S1 & S2) exists if at least one output of a service (S1) is equivalent, more or less general than the input of the other service (S2). Indeed the Output parameters of a service that does not match exactly the Input parameters of another service can be considered in web service composition. For more details on building the SDG, see [3].
Figure 2. Illustration of composability link
Having a composability link between S1 and S2 is similar to discovering syntactic and semantic similarity between an output parameter of S1 and an input parameter of S2. The edge weight is a key point of the model. It influences the choice of composition paths which directly affects the composition result. We associate to all the edges in the SDG a weight calculated using the syntactic and semantic similarity between Inputs and Outputs parameters, and a function of nonfunctional properties of services. Details of Composability and weight calculations are outside the purpose of this paper. They will be discussed in future work. 2) Dependency Graph Analyzer During this analysis phase, we try to find out all cyclic dependencies if there are any in the SDG, using the algorithm developed by [4] and then we regenerate the graph by making
each cyclic sub-graph as one compound node. In fact, the dependency graph shows either unidirectional or bidirectional communication between services. When all dependencies are unidirectional the dependency graph also will be direct acyclic graph. In cases of bidirectional communication, a service starts execution and gives partial output to another service and waits for reply to finish execution. Or service(s) may be required to be invoked and exchange data a number of times. In such cases the dependency graph will include cyclic dependency. The resulted acyclic dependency graph is stored in the Dependency Graph Repository and sent to the Shortest Graph Calculator. Other issues performed by this component will be detailed in future works. 3) Shortest Paths Calculator Discovering a composite service essentially is searching for a solution in the solution space represented by the SDG. Our service composition research aims at reducing the complexity and time needed to generate and execute a composition. We also improve its efficiency by selecting the best possible services available. To achieve these optimization goals, the Shortest Paths’ Calculator uses the Floyd-Warshall algorithm [5] to pre-compute, at the design time, all shortest paths between every pair of vertices in the acyclic dependency graph obtained from the previous step. We then store these paths in the Dependency Graph Repository for an eventual use at the time of composition. Thus, we avoid building the graph and applying the graph search algorithm when receiving a user’s request that requires services composition. When new services are published or existing services are changed or removed from the repository, the SDG is updated, the shortest paths are recalculated, and thus the Dependency Graph Repository will be also updated. C. Request Formalization The web service and the request must have the same modeling in order to facilitate the matching process. We developed our own service request meta-model. A service request consists of a set of parameters (Goals, Inputs, Outputs, Preconditions and Effects). Each parameter of the service request refers to concept of the ontology available in the Framework. In order to refine the description of the required services, DynaComp takes into account user interests, preferences and context. Thus, in this phase, the user profile (already stored) is used to enrich the service request, and to adapt the returned response to user preferences and context. D. Service Discovery Web service discovery is based on matching user’s requirements with semantic annotations of a set of web services (associated with the inputs, outputs, preconditions and effects of web services). In DynaComp, Service Discovery consists of two stages: (i) The process of querying the Registry to find the best services that semantically match the request. If yes, then the service is executed and the personalized results will be returned to Consumer. (ii) If we fail to respond to the user request (or a part of it), we query the Composite Service Repository, which stores
previously created composite service plans, and check if any existing plan can fulfill the user’s requirements. If yes, the identified composite service is confirmed and executed; the personalized results will be returned to Consumer. Otherwise, we use Service Composer. E. Service Composer There are two main components in the Service Composer: 1) Composition Paths Extractor When a matching service is not found during the Discovery, the Composition Paths Extractor queries the Dependency Graph Repository to check if any existing composition path matches user’s request. Given the directed graph SDG that models the available web services in the Repository, and when we receive a user request that requires service composition, we use semantic similarities to identify vertices which represent the Inputs and Outputs parameters provided by the requester and we update temporarily the SDG as follows: • A starting node (VSTART) is created and connected with all vertices (services) that contain at least one input provided by the requester; •
For each output demanded by the requester, create a goal node (VGOAL) and connect it with all services providing this output.
These additional nodes are used to guide the service composition, which is based on the computation of minimum cost paths which are the shortest paths from the start node (representing the request inputs) to the goal nodes (representing the request outputs). If we succeed in identifying the input and output vertices in the SDG, which are connected to VSTART and the set of VGOAL, we extract from the pre-computed paths (stored in the Dependency Graph Repository), all the shortest paths between VSTART and all VGOALS. Thus, we obtain the optimal sub-graph of services that meet the user’s needs. Otherwise, we should report the failure to the requester. In the latter case, the service consumer either can modify the request and go through the entire discovery process again or abort the effort to find a composite service. 2) Composition Plan Builder Once an optimal service composition path is extracted, it is passed on to the Composition Plan Builder, where the preparation and verification of composite service plan is performed. For all the services that are part of the service composition, the information about their inputs, outputs, preconditions and effects is checked automatically to assure that all needed input data are provided; that all operations can be executed; and that all links could be established. The generated composite service plan is stored in the “Composite Service Repository” for future reuse. F.
Composite Service Executor Once the planner comes up with a valid plan for the given request, the Composite Service Executor converts the plan into an executable process and executes it. The execution phase implements composite service bindings on the basis of the scheduled service composition specifications and executes the
services in question. For this, a coordination mechanism is required. It is responsible for invoking the participating services, receiving notifications of completion from each participating service, transferring and transforming (when required) the input/output parameters among the participating services, and evaluating preconditions that must be satisfied prior to the invocation of a participating service and postprocessing actions that must be performed after the execution of a participating service. Finally, the response is personalized based on the user profile parameters and then returned to Consumer. IV.
RELATED WORK
Many proposals of web service composition methods have been presented in recent years. For a detailed survey, we refer to [6, 7]. In this section, we present a brief overview of some techniques that deal with automatic web service composition. We consider only techniques that use service dependency information, graph models, and semantics. Hashemian et al. [8] store I/O dependencies between available Web services in their dependency graph, and then build composite services by applying a graph search algorithm. In their graph, each service and I/O parameter is represented as a vertex; service’s input and output are represented as incoming and outgoing edges, respectively. The authors consider only the matching and dependencies between input and output parameters without considering functional semantics, thus they cannot guarantee that the generated composite services provides the requested functionality correctly. Arpinar et al. [9] present an approach which not only use graphs for web service composition, but also use semantic similarity as we present in this work. They consider edges with weights and deploy a shortest-path dynamic programming algorithm based on Bellman-Ford’s algorithm for computing the shortest path. For cost, the authors consider the execution time of each service and input/output similarity but they don’t take into consideration the nonfunctional attributes of services. Gekas et al. [10] develop a service composition registry as a hyperlinked graph network with no size restrictions, and dynamically analyze its structure to derive useful heuristics to guide the composition process. Services are represented in a graph network and this graph is created and explored during the composition process to find a possible path from the initial state to a final state. In order to reduce the time of searching, a set of heuristics is used. But according to the authors, creating the graph at the time of composition is very costly in term of computation and limits the applicability of graph-based approaches to the problem of web service composition. Talantikite et al. [11] propose to pre-compute and store a network of services that are linked by their I/O parameters. The link is built by using semantic similarity functions based on ontology. They represent the service network using a graph structure. Their approach utilizes backward chaining and depth-first search algorithms to find sub-graphs that contain services to accomplish the requested task. They propose a way to select an optimal plan in case of finding more than one plan. However, they also create the graph at the time of composition which incurs substantial overhead.
Jianhua et al. [12] propose a new architecture of service composition based on cloud computing technology to achieve the mapping between the cloud service and abstract service, and the service parameter relationship graph based on semantic was put forward to achieve automatic composition. V.
CONCLUSIONS
In this paper, we propose a Framework to personalized and automated composition of web services. We have described its main components in detail and outlined their interactions. Our approach relies on representing the semantic relationship between services by a dependency graph. We take into consideration functional and non-functional properties of services. However, pre-computing the dependency graph between all available services in the Repository complicates and makes the graph size very big when there is high number of services. Thus we intend to investigate the clustering of web services available in the Registry, based on communities. The implementation and evaluation of the proposed Framework in the domain of e-government is the focus of our ongoing work. REFERENCES [1]
T.B. Lee, J. Hendler and O. Lassila, “The semantic web,” Scientific American, May 2001. [2] N. Guarino, “Formal ontology and information systems,” International Conference on Formal Ontologies in Information Systems, June 1998. [3] H. Elmaghraoui, I. Zaoui, D. Chiadmi and L. Benhlima, “Graph based E-Government web service composition,” IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, July 2011 [4] R. Tarjan, “Enumeration of the elementary circuits of a directed graph,” J.SIAM, vol. 2, pp. 211–216, 1973. [5] D. Wei, “An Optimized Floyd Algorithm for the Shortest Path Problem,” Journal Of Networks, 2010, Vol 5, No 12. [6] A. Alamri, M. Eid and A. Elsaddik, “Classification of the state-of-the-art dynamic web services composition,” International Journal of Web and Grid Services, 2006, Vol. 2, pp. 148-166. [7] J. Rao and X. Su, “A Survey of Automated Web Service Composition Methods,” Semantic Web Services and Web Process Composition (SWSWPC'04), 2004, pp. 43-54. [8] S. Hashemian and F. Mavaddat, “A graph-based framework for composition of stateless web services,” Proceedings of ECOWS’06, IEEE Computer Society, Washington, DC, 2006 [9] I.B. Arpinar, B.A. Meza, R. Zhang and A. Maduko, “Ontology-driven web services composition platform,” Inf. Syst. E-Business Management, 2005, 3(2):175–199. [10] J. Gekas and M. Fasli, “Automatic Web Service Composition Based on Graph Network Analysis Metrics,” International Conference on Ontology, Databases and Applications of Semantics (ODBASE). Agia Napa, Cyprus, 2005, pp. 1571-1587. [11] H.N. Talantikite, D. Aissani and N. Boudjlida “Semantic annotations for web services discovery and composition,” Computer Standards Interfaces, Elsevier, 2009. [12] J. Jianhua, S. Chen, Y. Li and Q. Zhang, “Semantic Web Service Automatic Composition Based on Service Parameter Relationship Graph”, IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications, 2011, pp.1773-1778.
