service centric systems (SCS) in which software systems are constructed based .... functionality of the system, assume that a software designer has produced a ...
UML-based Service Discovery Tool G. Spanoudakis A. Zisman Department of Computing, City University, Northampton Square, London EC1V 0HB, UK { gespan, a.zisman}@soi.city.ac.uk Abstract The development of service centric systems has been recognised as an important approach for software system development. In this paper we present a UML-based tool to identify services that can provide the functionality and satisfy properties and constraints of service centric systems specified during the design phase of the development of these systems and allows for the (re-)formulation of the design models based on the discovered services.
1. Introduction In the last few years we have seen the emergence of service centric systems (SCS) in which software systems are constructed based on the composition of web services. An important aspect of service centric systems is the ability to support the discovery and composition of services at different stages of the development life cycle of a system. Various standards and technologies have been proposed to enable the service centric vision. However, new processes, methods, and tools are necessary to assist with the engineering of complex and dependable SCS. In this paper we present a UML-based service discovery tool to support the engineering of SCS. Our tool adopts an iterative design-based service discovery process in which the discovery activity relies on the ongoing development of the design of the SCS and, therefore, the available services identified during this process can be used to amend and reformulate the design models of the system. The reformulation of these models may trigger new service discovery iterations. The result of this process is a complete specification of the SCS design models. The tool addresses important challenges and requirements that have been identified by industrial partners in an integrated European project focusing on service centric systems engineering (SeCSE – http://secse.eng.it).
2. Service Discovery Tool The interactive process adopted by the tool starts from the construction of initial system structural and behavioural models by the system designers. The behavioural model describes interactions between operations of an SCS that can be provided by web services, legacy systems or software components. The structural model specifies the types of the parameters of the operations in the behavioural models, and constraints for these operations and their
parameters. These models are specified and visualised as UML sequence and class diagrams, respectively. The interactions, classes and interfaces are used to specify queries. The queries are used to identify candidate services and operations that can fulfil parts of (or all) the functionality of the system. Designers may select some of the discovered services and operations and bind them to the design models. This binding results in a reformulation of both the behavioural and structural models. The new versions of these models may be used to specify further queries to discover other services that can satisfy more elaborated functionality, properties, and constraints of the system. Designers may terminate the process at any time or when they realise that further queries cannot discover services that match the models. The tool includes a UML 2.0 integration module and a query execution engine. The UML 2.0 integration module is combined with a UML Case tool (IBM Rational Software Modeler 6.0, in the current implementation) and is responsible for (i) extracting queries specifying the service functionality, properties, and constraints from the design models, based on the designer’s selections, and (ii) integrating the discovered candidate services back into the design models. The query engine searches for services in different service registries based on a similarity analysis algorithm. In the tool, a query is specified by the system designer who selects an interaction I from the behavioural design, creates a copy of I called query interaction (I’), selects the messages in I’ that should be realised by operations of the services to be discovered, and specifies various constraints on these operations (e.g. restrictions on the number of parameters) or on the interaction as a whole (e.g. service provider). A query is specified by using a UML 2.0 profile that we have developed which defines a set of stereotypes for different types of UML elements. The messages of the interaction may be stereotyped as: (i) query messages that indicate the service operations that should be discovered; (ii) context messages that imply additional constraints for the query messages (e.g. if a context message has a parameter p1 with the same name as a parameter p2 of a query message, then the type of p1 should be taken as the type of p2); (iii) bound messages that are bound to concrete operations that have been discovered by executing queries in previous iterations. All the messages in a query interaction which are not
stereotyped as above are treated as not directly related messages in I'. The constraints provide specific selection criteria for choosing services based on their various characteristics. The constraints include (a) the type hard, that must be satisfied by all the discovered services and operations or soft, that may not be satisfied by all the discovered services and operations, (b) the body as an OCL expression referring to concepts in the object models of service specification or UML metamodels, and (c) an optional weight for soft constraints (real value between 0.0 and 1.0). After the specification of a query interaction, the tool generates a query package that contains the context and query messages of the query, the classes that define the types of the parameters of these messages, as well as other classes that may be directly or indirectly referenced by these classes. The query package is submitted to the query execution engine to be processed. The execution of queries is performed in a two-stage process. In the first stage, referred to as filtering, the query execution engine searches service registries in order to identify services with operations that satisfy the hard constraints of a query and retrieves the specifications of such services. In the second stage, referred to as best operation matching, the query execution engine searches through the services identified in the filtering phase, to find the operations that have the best match with the soft constraints of the query. The detection of the best possible matching between the operations required by a query and the candidate service operations identified in the filtering stage is formulated as an instance of the assignment problem following the approach proposed in [9] based on distances between the signatures of two operations (names of operations and input and output parameters data types) . The result of a query identified by the query execution engine (i.e. best candidate services with smallest distances) is represented as results package containing a copy of the interaction used by the designer to create the query together with the structural model for the elements in the interaction, and various service packages, for each candidate service identified by the query execution engine. The operations in the service packages can be either bound (service operation with the best match to a query message), candidate (another possible result for the query message, but not necessarily the best match), or uncharacterized. The tool allows the designer to select candidate operations to become bound.
3. Related Work Several strands of research for service discovery have been proposed. Some of these approaches are concerned with the use of graph-transformation rules [6][7] or adopts a constraint-driven approach [1]. Other approaches advocate the use of behavioural models of service specifications [5][8] to improve service discovery. The use
of UML to support service centric systems has been supported in [2][3] [4]. Although the above approaches have contributed either to the problem of service discovery or design of SCS, none of them supports service discovery as part of the design process of service centric systems.
4. Conclusions We described a tool to support service discovery that is integrated with iterative UML-based system engineering design processes. The tool fulfils the lack of processes and tools to assist the engineering of complex and dependable service centric systems. It addresses two main challenges, namely (a) the need to incorporate service discovery as part of iterative service centric system design processes that uses well established industrial modelling standards, and (b) the provision of an efficient discovery process that can identify alternative candidate operations allowing the designer to accommodate the design based on what has been discovered. An evaluation of the tool with 72 query iterations against a service registry with 97 real services and 1028 operations has demonstrated 62% of precision on average. The results of this evaluation have been well accepted by the industrial partners. We are currently extending the tool to support service discovery based on behavioural service specifications.
5. Acknowledgment The work reported in this paper has been funded by the European Commission under the Information Society Technologies Programme as part of the project SeCSE (contract IST-511680).
6. References [1] Aggarwal R., Verma K., Miller J., Milnor W. “Constraint Driven Web Service Composition in METEOR-S”, IEEE Int. Conf. on Services Computing, 2004. [2] Baresi, L., Heckel, R., Thone, S., and Varro, D. "StyleBased Modelling and Refinement of Service-Oriented Architectures". Software and Systems Modelling Journal. [3] Deubler M., Meisinger M., and Kruger I. "Modelling Crosscutting Services with UML Sequence Diagrams", ACM/IEEE 8th International Conference on Model Driven Engineering Languages and Systems, MoDELS 2005. [4] Gardner T., “UML Modelling of Automated Business Processes with a Mapping to BPEL4WS”, 2nd European Workshop on OO and Web Services (ecoop), 2004. [5] Hall R.J. and Zisman A. “Behavioral Models as Service Descriptions”, 2nd Int. Conference on Service Oriented Computing, ICSOC 2004, New York, November 2004. [6] Hausmann, J. H., Heckel, R. and Lohmann, M., “Modelbased Discovery of Web Services”, IEEE International Conference on Web Services (ICWS’04), USA, 2004. [7] Hoschek W. “The Web Service Discovery Architecture”, IEEE/ACM Supercomputing Conf., Baltimore, USA, 2002.
[8] Shen, Z. and Su, J. “Web Service Discovery Based on Behavior Signature”. IEEE International Conference on Services Computing, SCC 2005, USA, July 2005. [9] Spanoudakis G, Constantopoulos P., “Elaborating Analogies from Conceptual Models”, International Journal of Intelligent Systems, Vol. 11, No 11, pp. 917-974, (ed) Yager R., J.Wiley and Sons, 1996
APPENDIX The demonstration of our tool will be based on the designing of a global positioning service centric system (GP_SCS) as a subsystem of a car-based Haptical device. The GP_SCS offers its users various functionalities including the identification of routes to get from one place to another, back-on-track re-routing, avoidance of specific areas, display of maps, and location of different points of interest in selected geographical areas. More specifically, our demonstration focuses on the design of an interaction of GP_SCS that can locate the closest point of interest of a certain type (e.g. restaurants, car parks, cinemas) given an address. Based on requirements related to this functionality of the system, assume that a software designer has produced a behavioural model of the above interaction and a structural model defining the types used in the interaction, as shown as screen dumps in Figures A1 and A2, respectively. During the demonstration we are going to show various functionalities of the tool including (a) query specification, (b) query execution, (c) results analysis, (d) results elaboration, (e) choose of other results, and (f) use of context message. Our demonstration will be based on the use of a service registry with 97 real services in different domains. In the following we briefly describe all these functionalities for the GPS_SCS example above. Query Specification. Suppose that the designer wants to identify services that can return the location of an address based on its geographical co-ordinates and services that can identify the position of a POI within a certain acceptable distance (operations FindAddress and Find_POI, respectively in the interaction shown in Figure A1). In order to specify the query, the designer selects the “Create Query” option from the pop-up menu, which displays a new window allowing the designer to specify the global parameters of the query and to select messages in the interaction that should be realised by operations of the services to be discovered. The selection of a message is executed by clicking on the message in the sequence diagram, and specifying its stereotype (query or context
message), by selecting the stereotype sub-panel in the Property editor. Suppose that for this iteration the designer wants to restrict the number of candidate services returned to be not greater than 10, the textual functional descriptions of the operations to contain the term “geocoding”, and the maximum number of services examined to be 100. The constraints are specified by using the Property editor. The constraint on the term “geocoding” is specified as an OCL expression assisted by the use of a combo box editor. Query Execution. After specifying a query, the designer executes it by selecting the “Run Query” option from the pop-up menu. Once the query execution is completed, the tool constructs the results package with the various services packages for the candidate services, and displays the sequence diagram with the results of the best matching for the query (bound service). In this example, the query message FindAddress is replaced by findAddresses() operation from service AddressManager from ArcWeb provider, and FindPoI is replaced by getLocationsList operation from service ReverseGeocodingService from ViaMichelin provider. The software designer can (a) accept the results of the query, (b) return to the previous query, modify it and execute it again, or (c) investigate the other results of the query execution (candidate services) and decide to bind any of the candidate services. It is also possible to visualise all operations (bound and candidate) that have been found for a certain query message. A service package also contains the class diagram of the data types and their relationships used in the service. This information can be used by the software designer to analyse the respective service. Results Analysis. For a more detailed analysis of the results, the software designer can view the calculated distances to all the operations found for the interaction. For a bound operation, the tool displays (a) the interface operation to which the service operation is bounded, (b) the type to which each parameter and nested data type in the query message has been mapped in the service operation together with the degree of similarity between these types, and (c) the computed normalised distances between the service operation and the query message calculated by the matching algorithm. For each bound operation, the tool also constructs and allows for the visualisation of data mapping associations between the data types in the original system model and data types in the bound services. This data mapping is based on the data distances computed for each bound operation in the service against the query message associated to the service.
Results Elaboration. After analysing and accepting the results for messages FindAddress and FindPOI from the query execution engine, the software designer needs to create a new query for operation Display Map and start a new iteration. For the discovery of a service that can return the URL of the map of a given location (Display Map), assume that the designer wants to investigate the operations that can be discovered for query message Display Map, when this query message is constrained by the bound operation getLocationsList(). In this case, operation getLocationsLists() is stereotyped as context message in the query. For the bound operation getLocationsList(), the tool has created data mapping associations between the data types used in query message FindPOI and those used in operation getLocationsList(). For this particular case, data type Coordinates used in FindPOI (see Figure A2) is mapped to data type GeoCoordinates in ReverseGeorcodingService service. The results of the query will likely prefer services from the same provider as that of the context message, since the best matching algorithm takes into consideration the minimal distances between operation names, parameters, and (nested) data types.
The query execution engine identifies operation getMapDefinition() from service GetBestMapDefinitionService (ViaMichelin provider) as the best match. However, if we consider another query for Display Map without any constraints on the provider or context message, the query execution engine returns getThematicGeographiesForExtent() from MapImage service (ArcWeb provider) as the best match for this query. Choosing other Results. As mentioned before, the tool allows the software designer to choose other results from the candidate services and not only accepting the best match as initially proposed by the tool. This is possible by selecting an operation from one of the candidate services in the result package and the “Bind” option from the pop-up menu. As an example, consider the operation getMap() from service MapManagementService that has been identified as one of the candidate operations for the query message Display Map. After analysing the results of this candidate operation, the designer decides to choose getMap() and MapManagementService to be bound to Display Map and mappingService:IMappingService, respectively.
Figure A1: GP_SCS System Behavioural Model
Figure A2: GP_SCS System Structural Model
