wsmx logo

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

1. Introduction

1.1 Overview

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.

1.2. Purpose of this document

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.

1.3. Document Overview

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.

2. WSMX architecture components

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

WSMX Architecture diagram
Figure 1: WSMX Architecture (click to enlarge)

Figure needed

Simplified Operational Aspects of WSMX
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.

3. ANSI X12 EDI

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.

3.1. What is ANSI X12 EDI?

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.

3.2. EDI Messages

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.

3.3. EDI Message Format

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.

3.4. EDI Message Choreography

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.

4. X12 EDI Use Case

NOT YET WRITTEN

4.1. Use case foundation

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.

4.2. Actors, Roles, and Goals

NOT YET WRITTEN

4.3. How WSMX can be utilized

NOT YET WRITTEN

4.4. Advantages WSMX exposes for the EDI use case

NOT YET WRITTEN

5. Conclusions and Further Directions

NOT YET WRITTEN

References

[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.

Acknowledgement

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.


Valid XHTML 1.1!

webmaster