Ontology-based Composition of Web Services for Ubiquitous Computing * Yang-Seung Jeon1, Eun-Ha Song1, Minyi Guo2, Laurence T. Yang3, Young-Sik Jeong1, Sung-Kook Han1 ** 1
Department of Computer Engineering, Wonkwang University, 344-2 Shinyong-Dong, Iksan, 570-749, Korea {globaljeon, ehsong, ysjeong, skhan}@wku.ac.kr 2 School of Computer Science and Engineering, Aizu University Aizu-Wakamatsu, Fukushima-ken 965-8580 Japan
[email protected] 3 Department of Computer Science, St. Francis Xavier University, Antigonish, NS, B2G 2W5, Canada
[email protected]
Abstract. Current Web service environment provide connection to individual services but is still deficient in semantic processing technology for the interoperability of Web services. The semantic processing of Web services is a key technology for the dynamic discovery and composition of Web services. Thus, the present study established Web service ontology to support ubiquitous environment and proposed a method of describing Web services in consideration of their functional and semantic aspects. In addition, it implemented a service interlocking and composition system by including a mediator function, which enables the composition of heterogeneous Web services, in the system.
1. Introduction Current ubiquitous computing environments involve heterogeneous systems as well as various kinds of applications, protocols and formats[5] and, in order to integrate these components, we need standardized protocols and semantic description methods. Semantic description makes it possible to specify Web services using ontology technology and to deal with Web services semantically through knowledge processing rather than information processing. As the concept of the Web is growing broad, various types of new Web services are emerging, which have not been available in existing information infrastructure. Today’s standard Web service technologies [6,7,10] provide developers with connection to and use of individual services. However, they cannot interact with services and interpret them compositely, and cannot be used by ordinary people. That is, the current Web service structure has the limitation that syntactic extension is * This paper was supported by Wonkwang University in 2006. ** Corresponding author.
2
Y.S. Jeon et al.
possible but semantic components or semantic extension is almost impossible. To solve these problems, a number of technologies have been proposed including chorography and orchestration. Without semantic processing, however, Web services can hardly execute their functions properly. Thus, research on semantic Web service discovery and dynamic Web service composition is going on actively, and a solution is to ontology-based descriptions of Web Services. The present study proposes a method for describing Web services using ontologies, in order to support ubiquitous computing technology. Inside the system, D-Mediator (data mediator) and C-Mediator (control mediator) are used for the interoperation and composition of heterogeneous services. This paper explains the Web service description methods of OWL-S, WSMO and WSBPEL[4,7,8], and describes the requirements and construction of ontology for Web Services. Lastly, we present a Web service composition system based on ontology for Web Services.
2. Background This section introduces OWL-S, WSMO (Web Service Modeling Framework) and BPEL4WS (Business Process Execution Language for Web Services) [4,7,8], which are base technologies for Web service composition. OWL-S is a representative semantic Web service language that extended DAML-S based on OWL[1]. By integrating OWL-based ontology technology with existing Web service description. WSMO provides ontological specifications for the core elements of Semantic Web Services. In fact, Semantic Web Services aim at an integrated technology for the next generation of the Web by combining Semantic Web technologies and Web Services, thereby turning the Internet from a information repository for human consumption into a world-wide system for distributed web computing. Therefore, appropriate frameworks for Semantic Web Services need to integrate the basic Web design principles, those defined for the Semantic Web, as well as design principles for distributed, service-orientated computing of the Web. BPEL4WS provides a language for specifying business processes and business interaction protocols. It can create a composite process by integrating different operations such as Web service call, data manipulation, error report, and process termination. Business processes are described in two ways – implementing executable business processes and describing non-executable abstract processes.
3. Ontology for Web Services
3.1 Requirements WSDL (Web Service Description Language) [6], an existing Web service description
Ontology-based Composition of Web Services for Ubiquitous Computing
3
language, describes only the functional information of services such as input parameters, output parameters, service providers and service locations, and has limitations in supporting the discovery, execution, composition and interoperation of Web service. Because WSDL cannot describe semantic information of Web services, we need ontology-based Web service interface technology that can describe not only the syntax but also the semantics of services. Here, services include not only the provision of static information through Web sites but also actions such as selling products and driving physical equipment. To utilize Web services, we need to describe services semantically so that software agents can interpret and process them autonomously. 3.2 Ontology Construction Web services description ontology is established by extracting semantic information on the actions and objects of Web services opened and operated in Web service portal sites and UDDI Business Registry (UBR), which is run by IBM and Microsoft. Fig. 1 is the relational of established Web service ontology. Web service ontology is composed of semantic descriptions of Web services such as actions and objects, which are domains to which actions are applied, functional descriptions of Web services such as the precondition on input parameters and the post-condition of output parameters, and other information required for describing Web services. name
TableElement TableElement
Other pragmatics
code
tableElement
Functional Description
XMLSchema:string XMLSchema:string
XMLSchema:string XMLSchema:string
Table Table postCondition
homeAddress
preCondition paramType
Parameter Parameter
providerDescription
serviceAddress
serviceDescription
Role Role
roleType providerBusiness
inputRole
XMLSchema:integer XMLSchema:integer Provider Provider
provider
Pragmatics Pragmatics
outputRole
AtomicProcess AtomicProcess
sequence
serviceLocation
Location Location
atomicProcess
pragmatics
SequenceProcess SequenceProcess process
ServiceIdentifier ServiceIdentifier serviceIdentifier
WebService WebService
Atomic serviceType
Composite
ServiceType ServiceType
actionType
Action Action XMLSchema:string XMLSchema:string
capability
Object Object objectType
C-Mediator D-Mediator
cost
action
relatedDomain relatedAction
evaluation
domain
Capability Capability
Capability Description
Evaluation Evaluation
XMLSchema:float XMLSchema:float performance
Fig. 1. Relational composition of Web services description ontology.
As shown in Fig.1, if semantic annotation is provided for an email sending service using ontology, the action is ‘send’ and the object is ‘email’. The functional description includes also information on the location of the email transmission service (location of WSDL), service provider and input/output parameters for the execution of the service. The modeled Web service description ontology is described using OWL, and ontology input is described using Protégé-2000. In Fig. 1, rectangles are classes and arrows are properties. Extracted classes,
4
Y.S. Jeon et al.
properties and instances are entered as inputs. The instance of ServiceType class, which describes the type of service to be composed, should have Atomic, Composite, C-Mediator or D-Mediator as its value. The Atomic type means that the service is not a composite but a single service, and the Composite type means a composite service created from the composition of services. In addition, C-Mediator and D-Mediator are service types used in matching parameters. C-Mediator is a service that extracts what it needs from service output parameters, and D-Mediator is a service that converts the type of the output parameter of a specific service to the type of the input parameter of a service to be matched.
4. Composition of Ontology-based Web Services
4.1 Web Service Domain Ontology-based semantic modeling means to define terms used in the concerned domain, establish relations among the terms, and implement the process. The process includes the classification of concepts, the establishment of the hierarchical relation of the classes, the definition of class properties, the diversities and constraints of the properties, and the creation of instances. ……… Web service address with optional home address Fig 2. Web service described in ontology.
Based on common words and shared understandings obtained from the process, we can achieve the consistency of communication in interoperation. Fig. 2 is a part of an OWL document describing Web service ontology input on Protégé-2000. The Web
Ontology-based Composition of Web Services for Ubiquitous Computing
5
service ontology described in OWL enables semantic-based selection and composition of Web services, and information on input and output parameters; input and output conditions and service location is also extracted from the established ontology through the function description of Web services. Fig. 3 shows the screen of Web service ontology input on Protégé-2000.
Fig 3. Screen of Web service description ontology input.
4.2 C-Mediator and D-Mediator for Composition When two or more heterogeneous services are composed, two things should consider. One is the type collision in the matching of different data types. For example, type collision happens when a ‘float’ type output parameter of a service is matched with a ‘string’ type input parameter. The other thing to be considered is how to extract input parameters when a service has two or more output results. This problem does not need to be considered if all the results of the service match. However, if only some of returned output results match, a process to extract them is needed. This study implemented D-Mediator (Data-Mediator) for conversion between two different types to solve the type collision problem, and C-Mediator (Control-Mediator) for extracting necessary output parameters. Fig. 4 (a) shows the mechanism of converting ‘float’ type output parameter S1O1 of service S1 to ‘double’ type input parameter S2I1 of service S2 through D-Mediator in matching parameters between two different services. For example, when composing exchange service S2 that exchanges currencies by receiving the output parameters exchange rate (float type), exchange rate (double type) and exchange amount (double type) of service S1 that calculates exchange rate between two currencies, type collision happens as in Fig. 4 (a). Here, the problem is solved as D-Mediator converts S1O1 (float type) of S1 to S2I1 (double type) of S2. Conversion from general string type (not numeric string type) to int or float type is not allowed, so is processed as an exception. Fig. 4. (b) shows a mechanism of extracting only S1O1 and S1O4 out of output parameters S1O1, S1O2, S1O3 and S1O4 of service S1 and matching them with input parameter S2I1 and S2I3 of service S2. For example, when composing exchange service S2 that exchanges currencies by receiving exchange rate (double type) and exchange
6
Y.S. Jeon et al.
amount (double type) and Amazon book search service S1 that receives input parameters author name (string type) and book title (string type) and returns output parameters date of publishing (string type), publisher (string type) and price (float type). This process has not only type collision but also the parameter extraction problem. In this case, before the execution of D-Mediator, C-Mediator is executed first to extract parameters from the outputs of S1 to be matched with the input parameters of S2. In Fig. 4 (b), only S1O1 and S1O4 of Amazon book search service S1 are matched with S2I1 and S2I3 of exchange service (S2). Thus, C-Mediator is executed to extract S1O1 and S1O4 among the four output parameters. Because S1O1 and S2I3 are identical in type they do not need the execution of D-Mediator, but S1O4 (book price: float type) and S2I3 (exchange amount: double type) requires the execution of DMediator for their matching. As mentioned above, D-Mediator is executed after CMediator.
(a) D-Mediator.
(b) C-Mediator. Fig. 4 Mediator for interoperability of Web services.
D-Mediator and C-Mediator were implemented as Web services for consistency in composite service processing technology and easy reuse of composite services in the future. When D-Mediator and C-Mediator are described in Web service composition process, their values of property ‘serviceType’ are ‘D-Mediator’ and ‘C-Mediator’ respectively.
5. Implementation
5.1 Environment The present system used Protégé 2000[13] as an ontology editor for our ontology, and OWL (Web Ontology Language) as a language for describing ontology. In addition, we used Jena 2.1 Ontology API[14] of HP Research Institute for parsing constructed ontology. The scope of ontology was defined to include Web service classification, Web service parameters information in WSDL and service management domain in UDDI. Web services based on ontology allows for knowledge processing, service automatic discovery and composition, thus they can be applied to ubiquitous environment. In
Ontology-based Composition of Web Services for Ubiquitous Computing
7
composition, the function of mediator was inserted, which provides interoperability between heterogeneous services. Communication between a service requester and the composition system was defined using SOAP[15]. In particular, SOAP message supports terminal equipment and communication. 5.2 System Architecture Ontology-based Web service composition system is composed of three modules Service Ontology, Service Composer, and System Manager.- and the architecture of the system is presented in Fig. 5. Service Ontology provides semantic description for the data and the functionality of the Web services to be composed. The Repository supplies several types of meaningful information that Service Annotator needs in order to compose Web services in Service Composer. The Service Composer is where Service Annotator performs actual service composition based on the provided service information of parameter, type and composition information etc. Service Composer is composed of Execution Controller that controls service execution, Data Manager that manages service parameters and converts the types of parameters between services to be composed, Composite Service Generator for composing actual services based on information on service execution in Execution Controller, and Parameter Match Maker that matches parameters between actual services based on the compatibility of the parameters of the services to be composed in Data Manager.
Service Provider
Service Manager
SOAP Message
Service Invoker
Service Composer
Execution Controller
Data Manager Task/Domain Ontology
Ontology Processor System Interface
Service Requester
Web Services Ontology
Composite Services Generator
Parameter Match Maker
Services Annotator
SOAP Message Simulate
Simulation Result
Service Composition Simulator
Fig. 5. Architecture of Web service composition system.
In addition, there is Service Composition Simulator for efficient service composition before the composition of actual services if they can be composed. System Manager executes actual services using service location information from Service Annotator and service match information in Service Composer. This is composed of Service Invoker to call services, and System Interface to pass service input parameters to the service to be called.
8
Y.S. Jeon et al.
5.3 Example Select a Web service to be composed. To add services to be composed, click the ‘Continue’ button. If all services to be composed have been selected, click the ‘Composition’ button to execute service composition of the selected services.
Fig. 6. Screen to select services to be composed.
Fig. 6 shows an example that composes ‘Inform’ action and ‘AirportWeather’ object, ‘Search’ action and ‘Game’ object, and ‘Send’ action and ‘Email’ object. The combo box on the screen is a list of services extracted from Web service ontology. Fig. 7 is a screen that matches the input and output parameters of AirportHumidity service that provides information on airport humidity, AmazonGameSearch service that finds game products in the Amazon site, and EmailSend service that send emails. Here, input parameter ‘EmailBody’ of EmailSend service is matched with output parameter ‘Weather_Message’ of AirportHumidity service. Then, the result of output parameter ‘Weather_Message’ of AirportHumidity service is automatically entered into the text box for the input of ‘EmailBody’ on the top of the service input window. Whether the parameter matching information set above is adequate can be tested by clicking the ‘Simulate’ button. After parameter matching is completed, click the ‘Run’ button to execute the Web service in a remote site provided by the actual service provider.
Fig 7. Parameter matching screen.
Fig. 8 shows the actual parameter inputting for executing Web services. If data are entered, the input data are transmitted in the form of SOAP message to the remote site
Ontology-based Composition of Web Services for Ubiquitous Computing
9
where the service is located. The service host executes the requested service and returns the results to the client in the form of SOAP message. Fig. 9 is the final result from the execution of the service.
Fig 8. Parameter input screen showing parameter matching information.
Fig 9. Final results of service composition.
6. Conclusions Current Web services provide developers with connection to and use of individual services, but interaction with the services and composite interpretation are impossible and ordinary people can hardly interpret and use the services. Web service description languages such as WSMF and BPEL4WS express the functional aspects of Web services, and OWL-S still has limitations in expressing the conceptual and semantic functions of Web services. Because these description methods cannot do Web service discovery and dynamic Web service composition, which are the most important semantics in Web services, they cannot attain the ultimate goals of semantic Web services. The present study proposed a new method of describing Web services by designing Web service ontology for the integrated expression of the functional and semantic aspects of Web services. In addition, by supporting semantic interoperability among Web services, ontology-based Web service composition serves the natural integration of heterogeneous applications inside and outside of a company as well as automatic system integration between business partners. Moreover, it facilitates automatic software integration and enables efficient interoperation among Web services.
10
Y.S. Jeon et al.
References 1. Dean, M., Connolly, D., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D.L., Patel-Schneider, P. F. and Stein, L. A.: Web Ontology Language (OWL) Reference Version 1.0. Recent Trends and Developments. W3C Working Draft 12 November 2002, http://www.w3.org/TR/2002/WD-owl-ref-20021112/ 2. McIlraith, S., Son, T.: Adapting Golog for Composition of Semantic Web Services. Proceedings of the Eighth International Conference on Knowledge Representation and Reasoning, Toulouse, France, (2002) 3. Matskin, M., Rao, J.: Value-Added Web Services Composition Using Automatic Program Synthesis. Web Services, E-Business, and the Semantic Web, CAiSE 2002 International Workshop, WES 2002, Toronto, Canada, (2002) 4. W3C, OWL-S, http://www.w3.org/Submission/2004/SUBM-OWL-S-related-20041122/ 5. Shankar R. Ponnekanti, Brian Lee, Armando Fox, Pat Hanrahan, and Terry Winograd ICrafter: “A Service Framework for Ubiquitous Computing Environments” Proceedings of Ubicomp 2001, September 30-October 2, 2001 6. W3C, Web Service Description Language Specification, http://www.w3.org/TR/wsdl 7. F. Curbera et al., Business process execution language for web services (BPEL4WS) 1.0, July 2002, http://www-106.ibm.com/developerworks/webservices/library/ws-bpel 8. W3C, Web Service Modeling Ontology, http://www.wsmo.org/TR/ 9. N. Gibbins, S. Haris and N. Shadbolt. Agent-based Semantic Web Services. In Proceedings of the 12th Int. WWW Conf., WWW2003, Budapest, Hungary, 2003, ACM Press, 2003, pp. 710-717 10. L. Ardissono, A. Goy, and G. Petrone. Enabling conversations with web services. Proc. of the 2nd Int. Conf. on Autonomous Agents and Multiagent Systems, 2003, Melbourne, pp. 819-826. 11. J. Rao, P. Kungas and M. Matskin. "Logic-based Web Service Composition: from Service Description to Process Model". Proc. of the IEEE Int. Conf. on Web Services, ICWS 2004, San Diego, California, USA, July 6-9, 2004, IEEE Computer Society Press 12. Tim Berners-Lee, James Hendler, Ora Lassila, “The Semantic Web”, Scientific American, 2001.5 13. Standford Univ,. Protege, http://protege.stanford.edu/doc/users.html 14. HP Lab, Jena, http://jena.sourceforge.net/index.html 15. W3C, Simple Object Access Protocol, http://www.w3.org/TR/soap12-part0
