D13.6.2v0.1 WSMX X12 Use Cases
WSMX Working Draft 20 October 2005
- This version:
- http://www.wsmo.org/TR/d13/d13.6/d13.6.2/v0.1/20051020/
- Latest version:
- http://www.wsmo.org/TR/d13/d13.6/d13.6.2/
- Previous version:
- Editor:
- douglas foxvog
- Author:
- douglas foxvog
Table of contents
- 1. Introduction
- 1.1. Overview
- 1.2. Purpose of this document
- 1.3. Document Overview
- 2. WSMX architecture components
- 3. ANSI X12 EDI
- 3.1. What is ANSI X12 EDI
- 3.2. EDI Messages
- 3.3. EDI Message Format
- 3.4. EDI Message Choreography
4. X12 EDI Use Case
4.1. Use case foundation
4.2. Actors, Roles and Goals
4.3. How WSMX can be utilized
4.4. Advantages WSMX exposes for the EDI use case
5. Conclusions and Further Directions
References
Acknowledgement
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 describes one usage scenario of WSMX.
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., 2005]).
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 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 ANSI X12 EDI system. Section 4 describes a use case involving the creation and interpretation of X12 EDI messages. Section 5 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 [Zaremba/Moran, 2005].
Figure needed
Figure 1: WSMX Architecture (click to enlarge)
- Message Adapters: These components are in fact external to the WSMX architecture, but as long as back end applications do not offer a WSMO API they are essential for connecting any kind of back-end application to the WSMX server. The Message Adapters allow transforming from any message format (e.g. RosettaNet, UBL, EDIFACT, ANSI X12, xCBL etc.) to the expected WSML message format.
- User Interface (WSML Editor): This component
is used by the service provider to create the description of the Web Services, Ontologies, Mediators and Goals.
- Communication Manager: The Communication Manager has a twofold purpose. On the one hand it provides an interface to the Adapters to accept and send WSML messages and on the other hand it is responsible for translating the message into whatever data representation is required by the external entity to be invoked. This translation is often referred to as ‘lowering’. To do so the Communication Mamager interprets the interface part of the WSMO service description to determine which binding is necessary for the service. Where it is not fixed, the transport protocol and associated security required for communicating with the external entity may also be selected. After invocation the Communication Manager is responsible to translate the message received from an external entity using any data representation to WSML. This translation is often called ‘lifting’.
- WSMX Manager: This component is the coordinator within the architecture. Although it is not an essential component to describe the use cases, it is mentioned here because it denotes the Service Oriented Architecture (SOA) approach of WSMX. All data handled inside WSMX is internally represented as a notification with a type and state. The WSMX manager manages the processing of all notifications by passing them to other components as appropriate.
- Ontology Repository: WSMX will offer the management of capability descriptions stored in a repository. This repository could be centralized or decentralized, whereas this use case and the current architecture only scopes with a decentralized repository in each WSMX. These repositories are designed to store, search, retrieve and manage WSMO descriptions of Semantic Web Services. Within this document the name Capability Repository is synonymously used for Ontology Repository.
- Matchmaker: WSMX will offer a set of usable Semantic Web Services by matching capabilities stored in the repository with the goal provided by the user. In subsequent versions WSMX will even be capable to fulfill goals by a composition of the capabilities of several Semantic Web Services. In both cases the result of the Matchmaker can be zero, one or many Web Services.
- Mediator: WSMX will offer mediation of communicated data. The mediation component tries to determine a Mediator for a request in case this is necessary. This mediation can be between two or more ontologies in the matchmaking process and the opposite way after invocation to mediate between the instance data of a known ontology provided by the executed Web Service to the required data in the invoking application. Another application of Mediators would be the mapping between the data provided in the input of the goal to the actual required input of the Web Service.
- Choreography Engine: The choreography of a Web Service defines its communication pattern, that is, the way a requester can interact with it. The requestor of the service has its own communication pattern and only if the two of them match precisely, a direct communication between the requestor and the provider of a service may take place.
Since the clients communication pattern is in general different from the one used by the Web Service, the two of them will not be able to directly communicate, even if they are able to understand the same data formats. The role of the Choreography Engine is to mediate between the the requester's and the providers's communication patterns. This means to provide the necessary means for a runtime analyses of two given choreography instances and to use Mediators to compensate the possible mismatches that may appear, for instance, to generate dummy acknowledgement messages, to group several messages in a single one, to change their order or even to remove some of the messages in order to facilitate the communication between the two parties.
Figure needed
Figure 2: Simplified Operational Aspects of WSMX (click to enlarge)
WSMX has two functional aspects, Registration at design time and 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 assume 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.
Electronic document standards first appeared in the 1970's. These standards
define the structure of business messages, with the promise of making business
transactions more efficient. The first such standard was SWIFT designed for electronic banking documents. ANSI X12 was created in 1979 to cover a wide range of business document communication.
Over the years, ANSI has generalized the various message types to be able to cover the needs of every industry. As a result, no industry, much less company, uses the complete X12 EDI standard. Each user uses only a limited set of message types and only a subset of the permissible forms of those messages which it does use.
In recent years, ANSI has made a limited number of changes (less than a dozen per year) to formats of transaction sets or their components. New message types have been added to and old message types have been removed from the standard infrequently. ANSI is working on developing XML versions of a number of the most commonly used message types.
EDI messages cover requests for quotes or information, replies to requests, purchase orders, invoices, acknowledgements, debit authorizations, and many other message types that cover the range of WSMX messages.
EDI messages could be semantically encoded in or generated from WSML, allowing service providers or requesters which use X12 to interact with those which do not. These messages may also be merely transliterated into a form which WSMX can handle and from which the original message can be regenerated to be transmitted as a new EDI message when required.
The ANSI X12 EDI standard defines in detail the format for a specified set of business data messages. It describes the formats in terms of defined "transaction sets", representing complete messages; "data segments", representing formatted chunks of related information that may be used in different transaction sets; and "data elements" which contain single pieces of information such as a number or text string.
The formats for these all data elements, data segments, and the most commonly used transaction sets have been encoded in WSML [Foxvog, 2005]. This document should be referenced for details on X12 message format.
When a (non-acknowledgement) X12 message is received an acknowledgement message (of one of two types) is generally returned. Such a message is an acknowledgement of receipt of a message along with an indication of whether or not the message was syntactically valid according to the syntax of the transaction set in the subset of EDI being used.
The expected type(s) of response message for a number of message classes is also defined. For example, a Purchase Order (TS 850) can expect a Purchase Order Acknowledgment (TS 855) or a Purchase Order Change Acknowledgement/Request -- Seller Initiated (TS 865) in response. The response to a TS 865 used as a request is a TS 865 used as an acknowledgement.
NOT YET WRITTEN
A simple use case would a vendor with the following basic choreography. The vendor expects a customer to sent a Request for Quotation (TS 840) to the vendor. The vendor replies with a Response to Request for Quotation (TS 843), providing prices and shipping details for the item(s) requested. If the response is satisfactory, the customer sends a Purchase Order (TS 850) message, receiving either a Purchase Order Acknowledgment (TS 860) or Purchase Order Change Acknowledgment/Request - Seller Initiated (TS 865) message in response. The final message in this choreography would be a Payment Order/Remittance Advice (TS 820) message from the customer to the vendor.
The actual choreography is a little more complicated. A Functional Acknowledgement (TS 997) message must be sent in response to the receipt of each message.
NOT YET WRITTEN
NOT YET WRITTEN
NOT YET WRITTEN
NOT YET WRITTEN
[Bussler, 2003] C. Bussler: B2B Integration, Concepts and Architecture. Springer-Verlag, 2003, ISBN 3-540-43487-9.
[Foxvog, 2005] d. foxvog: EDI Ontology. WSMX Working Draft v0.1, 2005. Available from http://www.wsmo.org/TR/d27/v0.1/20050505/.
[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/TR/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/TR/d13/d13.4/v0.1/20040622/.
[Oren, 2004] E. Oren: WSMX Execution Semantics. WSMX Working Draft v01, 2004. Available from http://www.wsmo.org/TR/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/TR/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/TR/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/TR/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.
webmaster
