This document is also available in a non-normative PDF version.
The Web Services Execution Environment (WSMX) [Oren et al., 2004a] is an execution environment for dynamic discovery, selection, mediation and invocation of semantic Web Services. WSMX is based on the Web Services Modeling Ontology (WSMO) [Roman et al., 2004] which describes all aspects related to this discovery, mediation, selection and invocation.
WSMX is a reference implementation for WSMO. The goal is to provide both a test bed for WSMO and to demonstrate the viability of using WSMO as a means to achieve dynamic inter-operation of semantic Web Services.
This document exemplifies several usage scenarios of WSMX. In the current version of this document we identify three possible use cases, namely a Business-to-Consumer (B2C), a Business-to-Business (B2B) and an Application-to-Application (A2A) scenario, and showcase how WSMX can be utilized for them. The process steps within these scenarios are only presented at a conceptual level, a more detailed description of already implemented parts of the execution semantics of WSMX is given in [Oren, 2004].
We briefly comprehend the architecture and the scope of WSMX and give a review on related knowledge necessary for exemplifying the specific use cases. The current architecture, represented in a preliminary framework, is aligned to WSMO Standard [Roman et al., 2004]). The first version of WSMX provides a complete architecture for dynamic discovery, mediation, selection and invocation and a simple but complete implementation of these components. In the current status it is not applicable to fulfill all aspects of the execution requirements described in these use cases. Subsequent versions of WSMX will incorporate the ongoing research of the WSMO and WMSL working group and will lead WSMX to a status where it fulfills all the Semantic Web Services support described in this document.
Hence this deliverable is intended to serve as an input for further improvements and providing valuable insight for adapting or including components to deal with real world scenarios for Web Services. On the other hand this deliverable will evolve in accordance to the ongoing development of WSMX itself and further use cases will be included in the future if necessary.
The use cases we will carry out are divided into two business domains. The B2C and the B2B use case are abstracted to Trading Partner integration. Both deal with the same purchasing process, but with different actors and roles. Application Integration contrariwise exemplifies a use case within a company which raises the demand for a so called intra-Enterprise integration [Bussler, 2003].
The document is organized as follows. Section 2 briefly describes the WSMX architecture components and in particular figures out which components will be addressed during the use cases. Section 3 describes the purchase of a bike, firstly in a B2C and secondly in a B2B collaboration. Both scenarios are first described in general, whereas the actors, roles and goals are defined, and then the overall system architecture is depicted and finally the execution flow of WSMX is outlined. Section 4 describes an Application Integration scenario by illustrating an A2A use case. It depicts an automatically invoked stock purchase by an application running in a banks divison and processed and executed by another division within the same bank. Section 5 finally concludes the document.
The following chapter gives only a very brief description of the components. This is solely indented to give the reader the chance to follow the process steps in the use cases without knowledge of other WSMX deliverables. Given the fact that some components are very specific and cover some technical requirements, they are not exemplified in the use case and therefore not specified in this chapter. For further information on all components we point the interested reader to the following deliverables [Oren et al., 2004] [Moran/Zaremba, 2004].
Figure 1: WSMX Architecture (click to enlarge)
Figure 2: Simplified Operational Aspects of WSMX (click to enlarge)
WSMX has two functional aspects, the Registration at design time and the Execution at run time. The Registration process (see Figure 2) is enabled mainly by the use of the WSMO Editor and the Compiler. In our use cases we imply that the Registration of Web Services to WSMX has already taken place.
The Execution process has two phases as depicted in Figure 2: the Discovery and the Invocation of Web Services. The first phase has the role of identifying those Web Services that suit the requester's goal, while the second phase makes the actual invocation of the selected Web Service. A detailed description of the execution flow is given in the respective use cases.
The following use cases are high level descriptions of business collaboration. Hence we currently ignore issues like communication security, transaction management, error handling and compensation. Furthermore we imply in these scenarios that all participants, exposing business functionality as a Web Service, agree to fulfill the real world interactions regardless of the respective business partner invoking them. Hence we imply that business partners trust each other, although they are maybe unknown to each other and do not have agreed on Service Level Agreements (SLA) beforehand. We will take this into consideration in further versions of this document as well as in improvements in the WSMX architecture. It is currently planned that SLAs between two partners will be taken into consideration in the non-functional properties of the goal and capability description.
The choice to describe the purchase of bicycles in the following use cases has been made deliberately, because they represent non-commodity goods.
A commodity good is traded primarily on the basis of price and not on differences in quality or features. Manufactured goods are said to be commodity goods if purchasing decisions are made almost solely on the price of the product. By choosing the bicycle as a non-commodity good we obviously have to deal with selection criterias beyond the price.
B2C stands for "business-to-consumer" and applies to any business or organization that sells its products or services to consumers. The most commonly known B2C E-Commerce market participant is the book retailer Amazon.com, which launched its website in 1995. However, in addition to solely online based retailers, also bricks-and-mortar companies have included many B2C services on their websites, such as online banking, travel services, auctions, betting and accommodation search.
Let us imagine a Bicycle retailer, further called BCR, which provides the disposal of several kind of bikes, including mountain-, racing-, city- and juvenile ones over internet. The following scenario is not depicted by using a traditional retailer with bricks-and-mortar branches, a fixed number of business relations with manufacturers and wholesalers and tightly coupled applications, but with one that tries to enhance its online business model by applying Semantic Web Services. By utilizing WSMX as the means to handle them, the BCR can enlarge its formerly limited number of bicycle types and brands offered for sale. In some respect the BCR migrates from a traditional retailer to a provider of a central knowledge repository for bicycle purchases. The operation of real world branches wouldn't have any influence on the use case itself. Naturally this kind of business model does not necessarily have to be offered by a bicycle retailer. It can be any company provideing a Web Service repository also covering the bicycle domain. To simplify matters and in respect to basic economic effects of specialization we assume that a retailer will offer this supplementary functionality prior to others.
Fundamentally we can differ between two service models the BCR can offer to its customer.
Excursus: In the latter service model the BCR could in fact become dispensable. WSMX will be able to connect to capability repositories of other WSMX's to search for their capability store. This means for our example, if all bicycle vendors utilize WSMX as their Web Service execution environment or at least provide a WSMO compliant description of their Web Service in any WSMX or central repository, the customer's client goal editor would be able to find this Web Service by connecting to any arbitrary WSMX. For further descriptions of our use cases we assume the existence of a BCR which hosts capability descriptions of several services from different manufacturers. This will be the most likely scenario in the near future, as far as a central repository of Semantic Web Services (like Google is for websites) or a central trading platform for semantic Web Services (like Ebay is for consumer goods) is not established so far.
Within the B2C view we focus on two different actors. The following listing defines in detail why they are interacting (goal), with whom and in what way (role) and what assumptions are essential.
Since the BCR can offer its service in at least one of the two above mentioned ways and the user's goal has to be described in WSML [Oren et al., 2004b], we have to differentiate between two system architectures reflecting the two service models described above. Figure 2 depicts both architecture types, whereas the manufacturer is not relevant for the B2C use case. The interaction between the BCR and the manufacturer is described in the B2B use case.
Figure 3: B2C architecture types (click to enlarge)
Three Tier Architecture: Client Browser - Web Server/Application Server - WSMX Server (see Figure 3)
This architecture type reflects the requirements of the first service model in 3.1.2. Within this architecture we can differ between two possible implementations of the portal site in the middle tier:
Two Tier Architecture: WSMX Client Editor - WSMX Server (see Figure 3)
This architecture type reflects the requirements of the second service model in 3.1.2. The users can define their goals by using a GUI based client side WSMX editor. This editor provides the means to graphically represent logical expressions in a way that the user only has to deal with some kind of symbols by changing their properties and relationships to each other.
The following paragraph describes the interactions between the user and the BCR retailer in more detail and specifies which specific component in WSMX is utilized to perform the required task. The way how the interaction between the BCR and the manufacturer take place are not presented in this use case, since they are discussed in detail in the following B2B scenario.
The above mentioned customer has a goal to buy a bicycle. Let us assume that this customer is an average skilled biker without any preference regarding the manufacturer of the bike. Their only conditions on the effects in the sense of WSMO are as follows:
Advantages for the customer:
The customer can abandon a protracted search through several on- or offline catalogues to find and then buy bicycles fulfilling their goal. WSMX installed, configured and maintained at the BCR will present them only Web Services exactly offering the possibility to order the desired bicycle.
If exactly the same bike is offered by different providers the user can choose the provider with the cheapest price. Hence the customer can be sure that there is no provider on the market (at least one who exposes their Web Service capability in a WSMX repository) who offers the bicycle at a cheaper price.
Another advantage is the one-step ordering made possible by WSMX. After the discovery of Web Services offering bikes matching their goal the customer can select the service to be invoked by WSMX. Traditional approaches would include the search in repositories (websites, offline catalogues, forums etc.) without the possibility to directly order the bike. By employing WSMX the customer would only find sources where an ordering is possible in the same step as the discovery.
Advantages for the BCR:
The advantages for the BCR are even more manifold. First the BCR could avoid a tight coupling of their end user shopping portal (either the web portal or the Capability Repository used by the WSMX client side editor) to specific manufacturers/wholesalers. Under the above mentioned assumption that the providers of business functionality via a Web Service fulfill the real world transactions independently who invokes it (without having a SLA), this can be even one, the BCR was not aware of before.
Furthermore the customer or in fact the BCR (as mentioned above they provide the means to describe a goal in logical terms) can use different ontologies for describing goals than the service providers use for describing the capability of their service. WSMX will even match the goal with capabilities using different ontologies as long as there is a Mediator registered in WSMX to map between the two ontologies. Again this allows a loose coupling and the BCR does not have to use predetermined ontologies impressed by a strong wholesaler or manufacturer.
Business-to-Business (B2B) Commerce and B2C Commerce fundamentally differ only in one thing. The customers are different - B2B customers are other companies while B2C customers are individuals. Overall, B2B transactions are more complex and have higher security needs. Beyond that, there are two major distinctions:
As mentioned above we ignore the negotiation between two business partners and imply that everyone can use the Web Service with the same conditions. But the second differential between B2C and B2B, "Integration", changes the execution flow between the participating parties, namely the BCR and the manufacturing companies, in comparison to the flow between the customer and the BCR fundamentally. Since applications are interacting with each other and any user interaction should be avoided, the matchmaking process and the selection and invocation have to comply to other requirements.
In this scenario we will change the role of the Bicycle retailer from the service oriented view in the B2C use case, where they only act as an intermediary party to the more common role of a Bicycle retailer as a dealer with warehousing. In contrast to the B2C use case it does not matter, if the BCR only sell their bikes traditionally offline or also offer them online, either as a Semantic Web Service or only via an ordinary online portal.
Within the B2B view we focus on the following two actors. The listing defines why they are interacting (goal), with whom and in what way (role) and what assumptions are essential.
For the fact that a bicycle retailer is at the far end of a supply chain their business relations are normally mainly based on pull interactions. This means they rather invoke services via interfaces at their closest business partner (e.g. wholesaler, manufacturer) than to expose services to them. Hence, except in sophisticated supply chain management (SCM) scenarios, bicycle retailers have not to offer these interfaces to their business applications e.g. for automatic purchase ordering, delivery inquiries etc. In excluding these SCM scenarios and assuming that the manufacturer has WSMX installed by any means (normally manufacturers expose several Web Services, hence it is easier to register them once in their own repository) we have to consider two architecture designs for our BCR.
Figure 4: B2B architecture types (click to enlarge)
Architecture with BCR not using WSMX: (see Figure 4)
If the retailer do not expose any Web Service (i.e. only uses services offered by wholesalers and manufacturers) and do not participate in any automated Supply Chain, there is no explicit need to have WSMX installed. By omitting WSMX they would obviously loose its benefits for internal integration as described in Section 4 and they would have to tightly couple their ERP-system with different WSMX Adapters of different manufacturers.
Architecture with BCR using WSMX: (see Figure 4)
If the BCR do offer their services as a Web Service to their end customers or business partners, act as an intermediary role like in the B2C use case or want to profit from the advantages WSMX provides in A2A scenarios they would have to run a WSMX server.
Since the two above mentioned system architectures differ fundamentally, we have to describe them separately. Starting with the first architecture (no WSMX installed at the BCR) the use case looks as follows.
In the second case - having WSMX installed in the BCR's and the manufacturer's system architecture - we can exploit the full potential of WSMX in B2B scenarios.
Again we have to break down the advantages regarding the chosen architecture model.
Starting with the first one the BCR obviously would not exploit the functionality of WSMX by coupling the BCR's SAP R3 system tightly with one WSMX. Hence there only arise advantages for the manufacturer:
In the second architecture model the advantages for both parties are manifold, but apparently for the manufacturer they are overlapping with the currently described ones. Hence we will only present the advantages now arising for the BCR:
Advantages for the BCR:
Application integration is a buzzword that has been widely used in the past several years, but what exactly does it describe? Enterprises use different back-end applications that need to exchange data. Since they are in most cases originally not designed to exchange data, the need to integrate them arises. To avoid manual intervention to transfer data into one system, which is stored in another one, software technology is needed in order to transfer this data automatically.
The following use cases should exemplify on a very high level how WSMX can be used as an integration tool. Technical issues like the particular implementation of Adapters, the type of message, which communication channels are used etc. are not in the scope of this document.
In contrast to the B2B integration above, application-to-application integration is a subset of B2B integration and therefore the foundation for successful interactions between two companies in a B2B scenario [Bussler, 2003].
Bussler defines A2A as an integration which refers to the integration of any number of back-end application systems that are hosted and require integration. This includes the integration of back-end application systems over a network that resides in a remote division of the enterprise. Therefore A2A is every integration of back-end applications where the boundaries of the company as a legal entity are not crossed.
WSMX will act in this scenario as a system commonly referred to as an Enterprise Application Integration system. Although WSMX will not offer business process management it still covers the two main functionalities which initially made up the foundation to be called an EAI tool [Stonebraker, 2002]:
As mentioned WSMX currently does not exploit the functionality of a business process engine, which is referred as compulsory to be called an EAI system by some authors [Linthicum, 1999] [Ruh et al., 2000]. WSMX will offer a Business Process Management (BPM) engine in further versions. Additionaly WSMX will offer goal decomposition. This means that the execution of a Web Service by matching an agents goal would also succeed if the capability is not matched by one singular Web Service, but has to be composed by the usage of several ones. For the agent there is no apparent difference if their goal is fulfilled by one or more Web Services (if it is a single action or a composed one).
Nevertheless the required orchestration and choreography will be part of future WSMX implementations. As soon as these issues are addressed in WSMO and in the architecture we will also inlcude it in this use case scenarios.
For our application integration use case we will exemplify the purchase of stocks within a bank operating in several countries with different departments dealing with investment funds. A division managing a global hedge fund, further called HFD (hedge fund division), wants to buy stocks. Typically purchases of stocks on different markets within a bank are managed by so called Settlement divisions. In large-scale banks there might be not only one Settlement, but several ones in different countries with overlapping functionality. Similarly the different funds are managed in different departments (e.g. pension funds in different departments than hedge funds), either by outsourced sub companies or independently entities within the bank.
Within the A2A integration we focus on the two following actors. The following listing defines the actors, why they are interacting (goal), with whom and in what way (role) and what assumptions are essential.
Figure 4: A2A architecture (click to enlarge)
Architecture: (see Figure 5)
To exploit the full potential of WSMX in A2A scenarios the company has two architecture options. Firstly it can implement WSMX on top of its system architecture in a global scale and introduce a policy that every division has to expose every Web Service capability in this central repository. Furthermore the adapters to back-end applications are built by the global IT department. Because this approach to introduce integration platforms on a strategic level requires a tightly cooperation between several IT departments and divisions in general, it proofed to be not successful in the past in several cases in EAI system implementations.
Since WSMX can act in a distributed manner, we assume for our use case that every single division operates its own WSMX.
As the term A2A implies, two applications have to communicate with each other. Additionally to these two applications, in our case a proprietary trading platform in the hedge fund division and a settlement system installed in the homonymous division, as mentioned WSMX runs in both divisions. Hence both divisions use WSMX as their mean to expose functionality either over the intranet or the extranet (internet). This assumption is solely made to utilize the repository of each WSMX. From the architectural point of view the use case would be nearly similar if only the HFD has WSMX installed and the settlement division only exposes the functionality of their back-end application as a Web Service. To be traceable this Web Service must be registered in at least one WSMX within the company. Since it is more likely that the division would do this registration in software installed in their own system architecture and as WSMX provides a central point of integration if they have to connect the settlement system to other systems within the division, we assume that WSMX is installed in the HFD as well as in the settlement division.
Let's assume that the above mentioned HFD (hedge fund division) wants to buy one million shares of the Bridgestone Corporation, listed on the NIKKEI index and traded at the Tokyo Stock Exchange (TSE).
In this use cases we described the execution flow of different invocation scenarios and we have shown how different entities can benefit from using WSMX as their mean for executing Semantic Web Services. WSMX makes optimal use of the semantic descriptions offered by WSMO to address the requirements from the B2C, B2B and A2A domain. WSMX can be used as the centerpiece of a robust and flexible Web Service architecture: customers can use the client side editor to search and invoke web services, service requesters can use it to achieve their business tasks and it can be used to interconnect applications.
In the first release of WSMX not every component can already perform all the tasks described in the use cases. So far we have not implemented a client side editor for designing and sending goals. The functionality of the Choreography Engine is based on a simple match without any Mediation Service if the communication pattern of the requester and provider are different. Hence communication can only be performed if the two communication patterns are perfectly symmetrical.
The composition of Web Services was omitted in these use cases so far. A composition component would be responsible for executing complex compositions of services in order to achieve a certain goal. Since this functionality is crucial for an applicability in B2B scenarios we are currently investigating different language for specifying these compositions in WSMX as well as in WSMO.
Another issue we haven't implemented so far is the selection of a specific Web Service out of the result set in the matchmaking phase. Currently the selection has to be performed by the respective user or the requesting application. A selection within WSMX would have to consider non-functional properties, preferences, Service Level Agreements etc.
Further developments have also to be done to provide an extensive adapter framework. This especially includes an adapter development kit to allow WSMX implementers to create adapters for their own proprietary back-end applications.
[Bussler, 2003] C. Bussler: B2B Integration, Concepts and Architecture. Springer-Verlag, 2003, ISBN 3-540-43487-9.
[Keller et al., 2004] U. Keller, R. Lara, A. Polleres, H. Lausen, M. Stollberg, M. Kifer: Inferencing Support for Semantic Web Services: Proof Obligations. WSML Working Draft v0.1, 2004. Available from http://www.wsmo.org/2004/d5/d5.1/v0.1/.
[Linthicum, 1999] D. S. Linthicum: Enterprise Application Integration. Addison-Wesley, 1999, ISBN 0-201-61583-5.
[Moran/Zaremba, 2004] M. Moran, M. Zaremba: WSMX Architecture. WSMX Working Draft v0.1, 2004. Available from http://www.wsmo.org/2004/d13/d13.4/v0.1/20040622/.
[Oren, 2004] E. Oren: WSMX Execution Semantics. WSMX Working Draft v01, 2004. Available from http://www.wsmo.org/2004/d13/d13.2/v0.1/.
[Oren et al., 2004] E. Oren, M. Zaremba, M. Moran: Overview and Scope of WSMX. WSMX Working Draft v0.1, 2004. Available from http://www.wsmo.org/2004/d13/d13.0/v0.1/20040611/.
[Oren et al., 2004b] E. Oren (Ed.): BNF grammar for WSML language. Working Draft v0.2, 2004. Avaliable from: http://www.wsmo.org/2004/d16/d16.1/v0.2/.
[Roman et al., 2004] D. Roman, H. Lausen, and U. Keller: Web Service Modeling Ontology Standard. WSMO Working Draft v02, 2004. Available from http://www.wsmo.org/2004/d2/v02/20040306/.
[Ruh et al., 2000] W. Ruh, F. X. Maginnis, W. J. Brown: Enterprise Application Integration: A Wiley Tech Brief. John Wiley and Sons, 2000, ISBN 0-471-37641-8.
[Stonebraker, 2002] M. Stonebraker: Too Much Middleware. ACM SIGMOD Record 31(1): 97-106, 2002.
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, 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 WSMX working group for their advice and input into this document.
