This document is also available in non-normative PDF
Copyright © 2004 DERI®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
2. Black Box Overview
2.1. WSMX Functionality
3. Architecture Components
3.1 User Interface
3.2 WSMX Management
3.2.1 Compilation Related Functionality
3.2.2 Execution Related Functionality
3.3 Compilation Engine
3.4 Integration Types Management
3.4.1 Compilation Related Functionality
3.4.2 Execution Related Functionality
3.5 WSMX WSDL
3.6 Events Management
3.7 Wire Event to clear Event Transformer
3.8 Discovery Engine
3.9 Mediation Engine
5. Architecture Execution Semantics
6. Conclusions and Future Work
Web Services Modeling Execution (WSMX – read 'wismix') is a Web Service, which is capable to process any integration definition instance defined as a type in the WSMX language. WSMX platform provides WSDL [W3C Note, 2001] interface of its externally available functionality, which allows any information system to use integration definition types compiled to WSMX platform. The concepts used in the definition of the WSDL interface as well as in the WSMX language are described using WSMO.
Figure 1 below, provides a simplified overview of the WSMX architecture. It includes the functional components of compiler, invoker, persistent storage, ontologies, and history component. Each of these components has its own interface defined in this document. Additionally two elements of this architecture are designed as web services – WSMX itself as the whole and the mediator component. This document defines WSDL interfaces for these two web services as well.
Figure 1: Informal WSMX Architecture - high level overview
Figure 1 illustrates the following example. An integration definition type is defined to support the handling of the purchase orders between two enterprises, which are having different internal purchase order structures. Both enterprises agrees that for inter-enterprise communication they should use the third party purchase order format as defined by the RosettaNet [RosettaNet] protocol. The integration definition type is defined separately by each of the enterprises, and compiled into their own WSMX platforms. The compilation component validates the integration definition type against WSMO. If validation is successful, it decomposes the task-type and stores it in the persistent storage. An identifier for this integration definition type is returned back to the task-type creator.
To actually send a purchase order instance between this two companies, an instance of the integration type must be created and executed. The instance of a purchase order is created in the first company back-end application using proprietary format and forwarded to WSMX platform. The execution environment of WSMX takes over and process the defined mediation and the web service invocation tasks, which send the purchase order in the RosettaNet format over the network to the second enterprise.
This document defines all the components of the WSMX architecture, which are necessary to achieve described scenario as well as any other possible integration scenario. The document has the following structure. Section 2 presents the high level, black box overview of the WSMX architecture. Section 3 discusses the particular architectural components of the WSMX platform. Section 4 (not yet included) aims to define formal interfaces for each of the WSMX components. Section 5 presents WSMX architecture execution semantic (not yet included). Section 6 summarises current version of this document and defines future work.
The purpose of this section is to present WSMX architecture from the very external, high level perspective (as a black box, which provides some inputs and some outputs) and to give an overview about what exactly WSMX 'can do'. This section defines how external entities such as intra-enterprise back-end applications or inter-enterprise information systems can interact with WSMX platform.
There are two main goals, which WSMX architecture has to achieve:
Compilation of the
Execution of the
The WSMX architecture components and this document are built around these two goals.
Web Services Modeling Execution (WSMX) is a web service, which communicates with the information systems using web services (to be more specific we should say that any entity can invoke web services provided by WSMX and WSMX has an invoker, which can invoke web services provided by other entities). WSDL interface is one of two entry points to WSMX platform. Except WSDL interface, the second entry point – user interface enables to compile integration definition types, which are going to be instantiated during execution time.
Taking the high level, black box overview of the WSMX platform, the WSMX is capable to:
Compile any integration type definition. For example (see figure 2)
the designer should be able to create
create_purchase_order_O1_O2.wsmx integration type
definition, which would specify (1) concepts and relations from the
purchase orders described in ontologies O1 and O2, (2) mediation from
ontology O1 to ontology O2, as well as (3) definitions of web services
and its capabilities.
Figure 2: Simplified example of the integration definition type
Execute the integration definition by instantiating the integration definition types. For example the information system IS1 should be able to call the WSDL operation exposed by WSMX platform and to give it a new instance of the create_purchase_order_O1_O2 integration type. After WSMX would receive the purchase order instance, it would carry out the mediation of the purchase order, as defined in the integration definition type, from the ontology O1 to ontology O2. WSMX invoker would take care to invoke the web service, which would provide the capability as requested by the information system IS1 in its goal description.
The high level, external overview example of the compilation and the execution of integration type and instances definitions with WSMX platform is presented in figure 3. In this example during compilation phase the user defines a new integration definition type and compiles it throughout communicating with WSMX user interface. During execution time, back-end application has a goal to create an instance of the purchase order, which should be sent in the format of ontology O2 (for example in RosettaNet format) to some endpoint. As an input the back-end application provides goal definition and the purchase order document in ontology O1. WSMX platform takes care to mediate given document and to find the appropriate web service, which is capable to fulfill the requested goal (which is able to accept purchase order in ontology O2 format). WSMX platform forwards the mediated purchase order to the right endpoint. There are many phases in the whole process where exceptions and errors could happened, but WSMX takes care for the whole process of error handling.
Figure 3: High external view of the WSMX platform
WSMX does not provide any predefined integration type definitions, so any new definition can be described and compiled. WSMX is able to handle instances of any correctly defines and compiled type. For example three of the RosettaNet PIPs: 3A4 (Request Purchase Order), 3A8 (Request Purchase Order Change) and 3A9 (Request Purchase Order Cancellation) could be defined as four integration type definitions:
Figure 4 shows how the back-end application can invoke operations, which handle three of the given integration type instances.
Figure 4: Invocation between back-end application and WSMX platform.
Integration definition types specifies which ontologies and which web services should be be used. WSMX takes care to mediate the business message (e.g. purchase order) to the appropriate ontology and forwards it to the right endpoint using web services defined in the integration definition (see figure 5).
Figure 5: Communication between two WSMX platforms.
From the perspective of usability of such a system, it would be desirable that WSMX should not differentiate between calls coming from the back-end applications (intra-company information systems) and from the network. We do not consider at this stage security concerns related to such a design, but we only focus on the simplification of the WSMX architecture. Figure 6 presents how instance of the purchase_order_acknowledgment_O2_O1 type could come through the network from the other business partner information system (in this case another WSMX platform). WSMX platform takes care for the mediation and forwarding of new mediated message to the back-end application system.
Figure 6: Invocation of WSMX from the other enterprises/back-end application systems
Figure 7: WSMX Architecture
[W3C Note, 2001] Web Services Description language (WSDL) 1.1, W3C Note 15 March 2001, http://www.w3c.org/TR/wsdl
[RosettaNet] The RosettaNet consortium for open eBusiness standards and services, http://www.RosettaNet.org
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, and SWWS; by Science Foundation Ireland under the DERI-Lion project; and by the Austrian government under the CoOperate programme.
The authors would like to thank to all the members of the WSMO working group for their advises and inputs to this document.