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.
1. Introduction
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
3.10 Invoker
5. Architecture Execution Semantics
6. Conclusions and Future Work
References
Acknowledgment
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 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 (any new mediator can be plugged as Web Service into WSMX). 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 agree 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 these two companies, an instance of the integration type must be created and executed. Instance of a purchase order is created in the first company back-end application system using proprietary format and forwarded to WSMX platform. The execution environment of WSMX takes over and processes 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 particular architectural components of the WSMX platform and defines formal interfaces for each of these components (not yet complete). Section 4 presents WSMX architecture execution semantic (not yet included). Section 5 summarizes 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 integration definition
types
Execution of the integration
definition instances
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 other information systems using Web Services as well (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:
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
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 by giving it to 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 (message) 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 happen, 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 written and compiled. WSMX platform is able to handle instances of any correctly defined 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 definition types:
Figure 4 shows how the back-end application can invoke operations, which handle three of the given integration type instances.
Figure 4: An example of Invocation between back-end application and WSMX platform
An integration definition type specifies which ontologies should be used and indentify Web Services, which are able to handle operations (e.g. that Web Service X and Y are capable to sell books and receive purchase orders in RosettaNet format). WSMX takes care to mediate the business message (e.g. purchase order) to the appropriate ontology and forwards it to the right endpoint using one of the Web Service, which has capabilities matched with the goal of the requester. (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 platform should not differentiate between calls coming from the back-end application systems (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 from 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 a new mediated message to the back-end application system.
Figure 6: Invocation of WSMX from another enterprise back-end application
system
WSMX architecture consist of set of components (see figure 7) and each of these components is having its own public interface defined in this section(interface which can be accessed by other components or other systems) . This section aims to explain the functionality and the purpose of each of the WSMX architecture components.
Figure 7: WSMX Architecture
There are two types of components in WSMX architecture - components dedicated to compilation and components dedicated to execution of integration definitions. Two of the components are specifically dedicated to the compilation of the integration definition types and seven of them are dedicated to execution of integration definition instances. WSMX Management and Integration Types Management components are shared among compilation and execution functions of the WSMX platform. Components dedicated to compilation of integration definition types are: User Interface and Compilation Engine. Components dedicated to execution of the integration definition instances are: Events Management, Wire Event to Clear Event Transformer, Discovery Engine, Mediation Engine and Invoker.
User interface component is used to invoke compilation of new integration definition types for WSMX platform.
WSMX management is business logic component of WSMX platform.
Compilation engine checks correctnes of the syntax of compilation integration definitions, decomposes them and triggers operations of Integration Types Management, component to get them stored.
Persistent storage for integration definition types and for mediated instances of messages.
WSDL interface in WSMX is not a stand-alone component (as it does not provide
any functionality), but it is only an endpoint which describes externally exposed
functionality of the WSMX platform. This endpoint can be used by any external
entities (e.g. back-end applications or information systems from other enterprises),
which aim to instantiate integrations type definitions compiled into
WSMX platform. There is only one external function/operation provided by WSDL
interface to other information systems in WSMX platform called invokeOperation
(see table 1).
| Method Summary | |
WSMXMessage |
invokeOperation(WSMXMessage message)() This operation takes as an input an instance of WSMX message, and returns back another instance of WSMX message. Integration definition types define what input is expected and what output is returned, but in most of the cases input WSMX messages would carry payload (e.g. purchase orders), while output message would encapsulates unique identifiers, which would be assigned to new, instantiated events in WSMX platform. |
Table 1: WSMX WSDL interface method definition
Invoke operation takes as input an instance of WSMX message, and
returns back another instance of WSMX message. While input messages would usually
carry extensive information about the requirements of the invoking application
such as for example goals, payloads, signatures and various other elements neccesary
to instantiate integration type definition, output messages would, in most of
the cases, forward only the unique identifier generated by Events Management
component. We consider represent WSMX messages as subclass of an ebXML message,
which has been standardized in ebXML Messaging specification [ebMS, 2002]. It
would require providing of the implementation of ebXML message on top of SOAP
message, and next extending it to WSMX message to encapsulate properties not
handled by ebXML messages (e.g. Goals).
java.lang.Objectjavax.xml.soap.SOAPMessage
ebXML messaging specification designers recognized most of the requirements
for electronic business messaging allowing additionally flexible including new
elements in their messages. At this stage standard ebXML message header elements
are for example id, From, To, ConversationId,
etc., but WSMX requires also additional object to be included in the WSMX message
header. An example of such an additional element handled by ebXML message header
could be a Goal element, which would specify objectives that a client application
can has when it consults a Web Service.
ebXML messages allows carring any payload in any format as MIME attachments, so documents of any type (e.g. pure text, XML or EDI documents), could be handled as WSMX messages.
| Method Summary | |
Response |
saveWireEvent(WSMXMessage message)() Saves wire event |
Response |
saveClearTextEvent(Payload message, Goal goal, String from)()
Saves clear text event |
Response |
saveClearTextEvent(Payload message, Goal goal, String from, Signature
signature)() Saves clear text event |
Table 2: Events management component interface methods definition
Disovery engine consults Integration Types Managment component if payload of the event should be mediated before it can be dispatched by the invoker to its final destination endpoint.
Mediation engine is a Web Service so any new mediator can be plugged into WSMX instead of standard mediator provided with the platform. Mediator interface has been presented in table 3.
| Method Summary | |
Payload |
mediate(String sourceOntologyIdentifier,
String targetOntologyIdentifier, Payload message)() This operation takes as an input identifiers of ontologies and a payload message, and returnes back mediated Payload message |
Table 3: Mediation Engine interface
Invokes Web Services in other information systems.
Future work will include the detailed definiton of the interfaces, components functionality and architecture execution semantics.
[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
[ebMS, 2002] Message Service Specification, Version 2.0, OASIS ebXML Messaging Services Technical Committee, 1 April 2002, http://www.ebxml.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.