This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights
Reserved. DERI liability, trademark,
document use, and software licensing rules apply.
This deliverable exemplifies the usage of the Web Service Modeling Ontology WSMO for modeling Web Service driven applications. In this document, we outline general usage of Semantic Web Service in different application fields, identifying the usage scenarios and the arising technical requirements. In additional documents, specific use cases are defined that showcase and test different aspects around WSMO.
WSMO Standard: D2 v1.0 Web Service Modeling Ontology (WSMO)
WSMO Primer: D3.1 v0.1 WSMO Primer
WSMO Reasoning: D5.1 v0.1 WSMO Discovery
WSMO Use Case: D3.3 v0.1 Virtual Travel Agency
WSMO Use Case: D3.4 v0.1 B2B - Business Document Exchange
WSMO Use Case: D3.5 v0.1 Semantic Web Fred - Agent Collaboration with Semantic Web Services
This document exemplifies the usage Semantic Web Services with special attention in usage and testing of the Web Service Modeling Ontology WSMO. We briefly replicate the objectives and the approach of WSMO and outline how specific use cases can be modeled in WSMO along with explanations on the modeling decisions. Then, we discuss several usage scenarios of Semantic Web Services, identifying the usage scenarios as well as the aims and challenges arising for Semantic Web Service technologies.
This Deliverable is intended to gather use cases for WSMO, and to evolve in accordance to the ongoing development of WSMO itself. The diferent use cases provided in subsequent documents serve as input and providing valuable insight for testing and adapting the modeling constructs provided in WSMO in real world scenarios for Web Services. So, besides demonstrating how to model Web Services in WSMO, the use cases also allow us to demonstrate the adequacy of our approach in terms of providing an exhaustive framework for covering all relevant aspects of semantic description of Web Services. In the long run, additional use cases will be added in order to widen possible solutions for Semantic Web Service technologies around WSMO.
This document is organized as follows: the remainder of Section 1 summarizes the objectives and approach of WSMO; Section 2 discusses possible application areas of Semantic Web Services. Section 3 gathers different defined for and around WSMO. Section 4 concludes the document. A Change Tracker in the Appendix explicitly list the major changes between different versions of this document in order to facilitate readers following the improvements.
A Web Service is a piece of software accessible via the Internet. Current Web Service technologies allow exchange of messages between Web Services [SOAP], describing the technical interface [WSDL], and advertising a Web Services in a registry [UDDI]. These technologies do not provide any information about the meaning of information used, neither do they explicitly describe the functionality of a services as needed for automated usage and interoperability of Web Services. Enhanced Web Service technologies aim at more sophisticated techniques to describe Web Services, emphasizing the concept of Semantic Web Services. In our understanding, a Semantic Web Service is defined as a “self-contained, self-describing, semantically marked-up software resource that can be published, discovered, composed and executed across the Web in a task driven automatic way” [Arroyo et al., 2004]. In the end, by machine-processable descriptions of the relevant information of Web Services, the following tasks shall be addressed:
The aim of the WSMO project is to define a coherent technology for Semantic Web Services (short: SWS). WSMO defines the modeling elements for describing several aspects of Semantic Web Services. The conceptual basis of WSMO is the Web Service Modeling Framework [WSMF], wherein four main components needed for a full coverage framework for Semantic Web Services are defined (see Figure 1):
Ontologies provide the formal semantics of the information used by all other components.
Goals specify objectives that a client may have when it consults a web service.
Web Services exposed descriptions of the functionality of a Web Service for supporting automated discovery, composition, and execution (called “Capabilities” in WSMO). For supporting automated usage, composition, and execution of Web Services, particular information on the external visible behavior of a Web Service are specified (called “Interface” in WSMO), including information on the technical accessibility and the actual message exchange of Services.
Mediators are used as connectors between particular components and include possibly required mediation facilities needed to make connected components interoperable. WSMO distinguishes different types of Mediators.
Further details on the components of WSMO along with exhaustive explanations are presented in the WSMO Primer [Arroyo and Stollberg, 2004].
 |
| Figure 1. WSMO Components |
Semantic Web Services can be used in manifold application fields. In accordance to the use cases defined in Web Services Architecture Usage Scenarios by the W3C Web Services Architecture Working Group (see [He et al., 2004]), we discuss two of the most commonly used scenarios to exemplify the usage of SWS technologies in this document:
For describing the use cases, we slightly modify the methodology of the W3C Use Case descriptions and extend them by the requirements arising for Semantic Web Services technologies. The aspects considered for our use case definitions are as follows:
In [He et al., 2004], the travel agency use case is separated into two use cases - one with static discovery and one with automated discovery. With Semantic Web Services we clearly want to support automated discovery. Thus, in the first WSMO use case we will describe a Virtual Travel Agency example that involves automated discovery of Web Services.
Imagine a “Virtual Traveling Agency”, called VTA for short, which is an end user platform providing eTourism services to customers. These services can cover all kinds of information services concerned with tourism information - from information about events and sights in an area to services that support booking of flights, hotels, rental cars, etc. online. Such VTAs are already existent, but at this point mostly comprise simple information portals along with some web-based customer services. By applying Semantic Web Services, a VTA will invoke Web Services provided by several eTourism suppliers and aggregate them into new customer services in a (semi-)automatic fashion. Such VTAs providing automated eTourism services to end users thus tremendously enhance the functionality of currently existing VTAs.
Our VTA use case that aggregates Web Services of different tourism service providers in a nutshell shall provide the following functionality: A customer uses the VTA service as the entry point for his requests. These requests must fit to end-user services that the VTA provides. These end-user services are aggregated by the VTA by invoking and combining Web Services offered by several tourism service providers. Therefore, there must be some kind of contract between the service providers and the VTA for regulating usage and allowance of the Web Services. Figure 2 gives an overview (modified and extended from W3C Travel Agent Use Case overview, as defined in [He et al., 2004]).
 |
| Figure 2. Use Case Overview: Virtual Travel Agency based on Semantic Web Services |
The scenario outlines a general structure for VTAs that can be extended to more complex scenarios wherein the customer can be a Web Service itself, thus creating a network of composed services that offer complex tourism services. For example, one VTA can provide flight booking services for an airline union, another VTA aggregates booking service for a worldwide hotel chain, and a third VTA provides booking services for rental cars by combining the services of several worldwide operating car rental agencies. Then, another VTA uses these services for providing an end-user service for booking complete holiday trips worldwide.
We provide the modeling of one such VTA use case in Section 3.1.VTA for International Online Train Ticket.
In the general use case there are 3 actors. The following defines why they participate in this use case (goal) and the particular interactions they are involved in (roles).
We identify the following usage scenarios
In this use case, the VTA is the central point of interaction between the Customer and other Web Services. Regarding the technological requirements, it is obvious from the usage scenario descriptions that (1) the Web Services offered by the Service Providers have to carry sufficient descriptive information to support automated Web Service usage, and (2) that the VTA has to provide all mechanisms to handle Semantic Web Services. The basic architecture of such a VTA as a central entity for Semantic Web Services handling is shown in Figure 3. The essential functionalities of Semantic Web Service enabled VTAs – with special regard to the requirements for Semantic Web Service technologies – are:
 |
| Figure 3. General Architecture of a SWS-enabled VTA |
Summarizing, the VTA is a SWS-enabled B2C application that provides an end-user service following a client/server model. In order to support coherent functionality of the VTA and to ensure that the descriptions of Web Services are compatible to this, an overall framework for SWS technologies is needed. This is provided by WSMO.
The second use case is concerned with the integration of possible heterogeneous resources in B2B settings which is considered as one of the most important application fields of the Web Service technology.
In the B2B use case, two enterprises called E1 and E2 want electronically
exchange business documents across the network. Assuming that partners may
not know each other before, contract negotiation and contract agreement are
essential aspects of this use case. The contract agreement defines roles of
enterprises in the conversation, for instance, one of the enterprise E1
becomes the seller and the second enterprise E2 becomes the buyer. An
agreement also predefines the order of the messages interchanged between the
parties, e.g.the buyer first sends purchase order (PO) and after that it
receives purchase order acknowledgement (POA). In constrats to the previous
B2C use case, where the client/server model of interactions has been adopted,
here partners are equal in the interaction, i.e. a peer-to-peer model is
assumed in this use case. Each of the companies has an own set of web
services for exchanging business documents electronically. The infrastructure
provided by SWS takes care for any necessary mediation between web services
(links web services), ontologies (resolves possible representation mismatches
between ontologies used by these two enterprises), goals (links goals), as
well as linking web services and goals. The infrastructure also supports the
execution of the contract to fulfill approved agreement.
 |
| Figure 4. B2B Integration with Semantic Web Services |
In this use case an ultimate goal of an enterprise E1 is to integrate its own back-end system with the back-end system of an enterprise E2. Once integrated, SWS software enables back-end systems of both companies to interact and to preserve the message, process and protocol semantic. The information systems used by enterprises E1 and E2 are autonomous, heterogonous and distributed. Semantic Web Services address each of these three properties and the software based on SWS enables companies to cooperate.
The use case assumes peer-to-peer relationships between two business partners carrying conversation about purchasing/selling of goods. The B2B use case focuses on the technical infrastructure based on the SWS technology, which enable any business company to automatically discover web services which are capable to fulfill its goals, compose simple web services into complex web services to achieve a given goal and to automatically execute given services in a particular order. This use case assumes that there may be no prior business relationships between two enterprises before the discovery. Enterprise E1 must find enterprise E2 and they must agree and enforce the contract in their companies. Agreement should define roles of each of them in the agreed business process – e.g. one of them would become a buyer and one of them would become a seller. The agreement can lead to only one time execution of the agreed business process (e.g. request purchase order) or to long time relationships based on the multiply execution of the agreed contract. Payments are sent through financial institutions and at this stage they are out of the scope of this use case. The same situation concerns the shipment of the goods. This use case consider sending documents as for example purchase orders or invoices, but the physical shipment of goods is out of the scope of this use case.
There are two actors in the B2B use case – actors, which represent two business entities. The size and the importance of companies are not predefined in this use case. They might differ in size but from the perspective of this use case it should not matter which one of them is a more dominant partner. Both of the enterprises undertake a predefined role in the use case. These are:
In this use case the following usage scenarios have been identified:
The Web Services Modeling Execution (WSMX) is the infrastructure is a WSMO-reference implementation that addresses this use case, see WSMX hompage at: http://www.wsmo.org/wsmx/. Therein, a WSMX-platform is hosted by each of the enterprises to support services following a peer-to-peer model. WSMX is software implementation of a web service execution environment supporting the development, management and execution of Semantic Web enabled Web Services. WSMX platform does not differentiate between calls coming from the back-end application systems (intra-company information systems) and from the information systems of other enterprises. WSMX can also communicate directly with other WSMX platforms hosted by other enterprises as shown on figure 5.
 |
| Figure 5. B2B Use Case System Architecture |
This section gatheres different use cases developed around WSMO, each with a different focus. We briefly introduce the use case here, while the use case modling is provided in a different document.
This use case models a B2C application scenario: a Virtual Travel Agency for purchasing train tickets provides a WSMO Web Service.
This is the first WSMO use case developed in previous versions of this document.
Link: http://www.wsmo.org/2004/d3/d3.3/
This use case models a B2B scenario for exchanging business documents, this scenario will be more elaborated in future, for know there is only a placeholder document:
Link: http://www.wsmo.org/2004/d3/d3.4/
This is the Use Case defined for Semantic Web Fred - an agent system for automated, cooperative goal resolution that realizes WSMO. More information on the SWF project can be found at the SWF project website at: http://www.deri.at/research/projects/swf/.
Link: http://www.wsmo.org/2004/d3/d3.5/
The aim of this document is to identify the challenges for Semantic Web Services by elaborating usage scenrios, and to gather use cases that cover specific aspects around Semantic Web Service modeling and technologies around WSMO, serving as a testbed for development of WSMO-based technologies. The most important outcomes of this deliverable are:
This deliverable is intended to evolve over time. The directions for future work in this deliverable are:
[Arroyo et al., 2004] Arroyo, S.; Lara, R.; Gómez, J.; Berka, D.; Ding, Y.; Fensel, D. (2004): Semantic Aspects of Web Services. In Munindar. P. Singh (Ed.), Practical Handbook of Internet Computing. Baton Rouge: Chapman Hall and CRC Press, Baton Rouge. 2004.
[Arroyo and Stollberg, 2004] Arroyo, S.; Stollberg, M.: WSMO Primer. WSMO Deliverable D3.1, available at: http://www.wsmo.org/2004/d3/d3.1/v0.1/
[ebXML] ebXML, avaliable at: http://www.ebxml.org.
[EDIFACT] UN/EDIFACT, avaliable at: http://www.unece.org/trade/untdid/welcome.htm.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[He et al., 2004] he, H.; Haas, H.; Orchard, D.: Web Services Architecture Usage Scenarios, W3C Working Group Note 11 February 2004. available at: http://www.w3.org/TR/ws-arch-scenarios/.
[Hayes (Ed.), 2004] P. Hayes: RDF Semantics, W3C Recommendation 10 February 2004, 2004.
[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), version 0.2 available at http://www.wsmo.org/2004/d2/v02/.
[SOAP] Mitra, N.: SOAP Version 1.2 Part 0: Primer. W3C Recommendation 24 June 2003. available at: http://www.w3.org/TR/soap12-part0/
[UDDI] Bellwood, T.; Clément, L.; von Riegen, C. (Ed.): UDDI Version 3.0.1. UDDI Spec Technical Committee Specification, Dated 20031014. available at: http://uddi.org/pubs/uddi_v3.htm
[WSDL] Chinnici, R.; Gudgin, M.; Moreaum, J.-J.; Weerawarana, S. (2003): Web Services Description Language (WSDL) Version 1.2. W3C Working Draft 3 March 2003. available at http://www.w3.org/TR/wsdl20/.
The work is funded by the European Commission under the projects DIP, Knowledge Web, SEKT, SWWS, Esperonto, and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.
The editors would like to thank to all the members of the WSMO working group for their advice and input into this document.
To facilitate retracing of changes inbetween different version of this deliverable, the following lists the essentail changes done in comparison to the preceding version.
The change tracking starts with the version of 28 June 2004.
$Date: 2004/10/08 14:11:42 $