ebxml-transport message

Subject: ebXML Message Header

From: john_ibbotson@uk.ibm.com
To: ebXML-Transport@lists.oasis-open.org
Date: Thu, 3 Feb 2000 21:34:14 +0000




Here's a piece of work-in-progress on message headers. It looks at a possible
header structure which is a superset of a number of existing protocols.
Expressed using XML Schema.
(See attached file: HeaderProposal-jan-14.htm)

John

MQSeries Technical Strategy & Planning,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: +44 (0)1962 815188
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com

Title: Business to Business (B2B) Message Header Proposal

Business to Business (B2B) Messaging Header

This Version:: http://obi.watson.com/HeaderProposal.html
Latest Version:: http://obi.watson.ibm.com/HeaderProposal.html
Previous version:: http://obi.watson.ibm.com/HeaderProposal.old.html

Editors: Carlos E. Perez ceperez@us.ibm.com, IBM Research

Status of this document

This document is a work in progress, the information contained within this document may change substantially between drafts.

Abstract

1. Introduction

1.1 Business to Business Messaging

1.2 Objectives

1.3 Design Requirements

1.4 Implementation Requirements

Abstract

This document specifies the syntax and processing rules for the encoding of Business to Business (B2B) headers using XML.
This specification intends to provide a generic and extensible mechanism for providing information concerning the transport, delivery and processing of B2B documents.

1. Introduction

1.1 Business to Business Messaging

Business to Business on the Internet is projected to grow at an extremely rapid pace. The W3 Consortium XML standard [XML] has been viewed as a catalyst to this growth. Unfortunately in recent months many XML proposals for standard Business to Business (B2B) documents have appeared, these competing proposals has dramatically increased the complexity of implementations in the B2B space. This proposal introduces a standard for B2B messaging header which is generic and extensible. Furthermore, it is the goal that this specification be a independent of business content and transport protocol concerns as reasonably feasible.

Messages in general can conceptually viewed as having an envelope which contains a letter. The envelope of a message is what we refer to as being the header and the letter being the body. The header contains information pertaining to the transport, delivery and processing of the contained body. For the sake of brevity and limits of time, this specification bounds its scope to that of specifying only delivery concerns.

1.2 Objectives

The objectives of this specification is to:

(1) Improve interoperability among various proposed XML based B2B protocols. The goal is that the header must be able to contain the header information of commonly used B2B standards, such as EDI, OAGIS, OBI and RosettaNet.

(2) Decouple message handling from transport mechanisms, such as HTTP, SMTP, Reliable Messaging Middleware, FTP etc. The goal is that this specification should be useful in contexts where different transport mechanisms are used.

(3) Facilitate reuse across different industry groups. This specification should be agnostic to the industry specific content of the message.

(4) Support future Business to Business intermediaries. This specification aims to provide sufficient header information so that an intermediary may perform its services without requiring the reading of the message body.

(5) Support both point-to-point and publish-and-subscribe messagging types.

1.3 Design Requirements

The design requirements are as follows:

(1) The Specification must be simple enough to be easily and quickly implemented by parties.

(2) The Specification must be extensible to accomodate future forms of business models and communications.

(3) The Specification attempts to be independent of transport protocols and business logic such that only information necessary for B2B delivery is expressed.

(4) The Specification needs to identify issues that cannot be resolved today in order to accomodate additions of open standard solutions in the future.

1.4 Implementation Requirement

The implementation strives to be:

(1) Composable. We should be able to choose the elements that we need and to exclude those we do not.

(2) Extensible. We use W3C namespaces [NAMESPACES] and XSchema [XSDL] as the primary extension mechanisms.

(3) Simple. Which XML features should we restrict?

(4) Decentralized. A mechanism for creating unique identifiers that is scalable. Identifiers need the property of being global unique at the same time it must be definable in a decentralized manner. The current proposal leverages the use of W3C URI [URI] convention to define uniqueness.

(5) Standard. We need should use only W3C recommendation or drafts that are currently in the working groups (i.e. XSL, XLINK, XPATH, XPointer).

(6) Agnostic. Should be useful independent of the the underlying protocol (i.e. push, pull, publish/subscribe, store/forward etc. ).

1.5 XML Guidelines

(1) Attributes are used to express "metadata" about an element (examples are xml:lang and xml:ns). This also restricts the metadata to be of single value. In addition to standard attributes we define 3 attributes "id", "idref" and "uri". The "uri" attribute is to be used to indicate an identifier, unlike the "idref" attribute which assumes that the value can be resolved.

(2) No abbreviations. XML is already verbose, you won't gain much by trying to save a few bytes here, furthermore one of
the intents of XML is that it be human readable.

(3) An element may either be embedded into the document or its referred to by using an idref.

(4) How are collections of documents going to be handled? RDF style or recursively?

2. Header Elements

2.1 The `Header` Element

2.1.1 Intent

The Header elements are very flexible and may be used to describe any type of business document. The business document being described may be included within the header, outside the header in the same document, or completely outside of the document. This is in similar spirit to the Description elements we find in [RDF] and the Signatures we find in [DSIG]. Conceptually we treat the Header as metadata for the business document.

The headers are represented by the Header element which has the following structure:

This is based on the [DSIG] structure, though we have chosen to omit the collections (i.e. Manifest or Package) since this may be the concern of a processing specification.

2.2 The ObjectReference Element

2.2.1 Intent

The ObjectReference element has the structure indicated below.

The URI/IDREF attribute of ObjectReference idenitifies the business document. The URI attribute is meant to define identifiers, in many cases these should be unique relative to some namespace. The IDREF attribute is meant to define the location of the target.

2.2.2 Also Known As
Message-id
2.2.3 Known Uses
[ROSETTA] [OAGIS][CXML][ICE][OTP]

2.3 The Object Element

The Object element is when the actual document is embedded within the header, this element may contain any data. The Object element may include ID and optional encoding attributes.

The Object's ID is referenced from the ObjectReference in Header. This element is used for embedded documents where the object being described is to be included in the header document.

2.4 The ContentType Element

2.4.1 Intent

This element describes the syntax and semantics of the document. New values may be included via name spaces. The recommended attributes shall be: Noun, Verb, Version, Ontology, Encoding, Private, Timestamp and Expiration.

2.4.2 Also Known As
Message Type, Message Description

2.4.3 Known Uses
[ROSETTA] [OAGIS] [BIZTALK]

2.5 The Sender and Receiver Elements

2.5.1 Intent
This element provides a logical identifier that is unique with respect to sender's domain or agreed upon by partners.

2.5.2 Also Known As

From and To, Source and Destination

2.5.3 Known Uses
[ROSETTA] [CXML][BIZTALK]

Note: Although it may seem that Authentication information may be required in this element, we consider it as being more of
a transport concern.
Example: for DUNS: urn:duns:45738927

2.6 The Agent Element

2.6.1 Intent
Identifies the software artifact that has sent this message. If this message was pulled from a service, the hosting service is the should be considered as the sender.

2.6.2 Also Known As
Sender
2.6.3 Known Uses
[CXML][ICE]

2.7 The Context Element

2.7.1 Intent
This information is provided by the sender as a means to provide a context for the message. The specification treats this information as semantically opaque. If a sender has included a Context element withing the Header, the responding party is required to return the same elements. This presence of this element implies that a Sender is requiring that a Responder reply with the Sender provided information. The Context element has a single URI attribute, which a is used by the originator of this message to lookup the element.

2.7.2 Also Known As
In-Reply-To, Conversation, Context, Transaction, ReplyWith, Correlation Id

2.7.3 Known Uses
[OAGIS][OTP][CXML][CBL2]

2.8 The ReplyTo Element

2.8.1 Intent
This includes identifiers of agents that where replies are to be sent. This is relative to the namespace of the sender or agreed upon by the parties involved. As an example of its use, a buyer may publish request for quotes using a third party marketplace, a seller may reply with a quote to the buyer and not the marketplace.

2.8.2 Also Known As

2.8.3 Known Uses

2.9 The Acknowledge Element

2.9.1 Defines if an acknowledment is required.

2.9.2 Also Known As

2.9.3 Known Uses

EDI X12 ISA14 Acknowledge Requested, [OAGIS]

3. Schema

The XML structure is greatly influenced by the current W3C Recommendation on expressing MetaData [RDF]
and the XML signature specification [DSIG]

3.1 XML Schema Definition [XSDL]

The following is an XML Schema that encodes the information describe above.

<?xml version ="1.0"?>
<schema name = "HeaderProposal.xsd"
xmlns = "http://www.w3.org/1999/05/06-xmlschema-1/structures.xsd">
<import schemaName = "http://www.w3.org/1999/05/06-xmlschema-1/structures.xsd"/>
<elementType name = "Header" model = "open">
<sequence>
   <elementTypeRef name = "ContentType"/>
   <choice>
    <elementTypeRef name = "Object"/>
    <elementTypeRef name = "ObjectReference"/>
   </choice>
   <elementTypeRef name = "Sender"/>
   <elementTypeRef name = "Receiver" minOccur = "0" maxOccur = "1"/>
   <elementTypeRef name = "Agent" minOccur = "0" maxOccur = "1"/>
   <elementTypeRef name = "Context" minOccur = "0" maxOccur = "*"/>
   <elementTypeRef name = "ReplyTo" minOccur = "0" maxOccur = "1"/>
   <elementTypeRef name = "Acknowledge" minOccur = "0" maxOccur = "1"/>
</sequence>
</elementType>

<elementType name = "ContentType" model = "open">
<sequence>
   <elementTypeRef name = "Noun"/>
   <elementTypeRef name = "Verb" minOccur = "0" maxOccur = "1"/>
   <elementTypeRef name = "Version"/>
   <elementTypeRef name = "Ontology"/>
   <elementTypeRef name = "Encoding"/>
   <elementTypeRef name = "Timestamp"/>
   <elementTypeRef name = "Expiration" minOccur = "0" maxOccur = "1"/>
</sequence>
</elementType>

<elementType name = "Object" model = "open">
<any/>
<attrDecl name = "id" required = "true">
<datatypeRef name = "string"/>
</attrDecl>
</elementType>

<elementType name = "ObjectReference" model = "open">
<sequence/>
<attrDecl name = "idref">
<datatypeRef name = "uri"/>
</attrDecl>
<attrDecl name = "uri">
<datatypeRef name = "uri"/>
</attrDecl>
</elementType>

<elementType name = "Sender" model = "open">
<sequence>
   <elementTypeRef name = "Role" minOccur = "0" maxOccur = "1"/>
   <elementTypeRef name = "Name" minOccur = "0" maxOccur = "1"/>
</sequence>
<attrDecl name = "uri" required = "true">
   <datatypeRef name = "uri"/>
</attrDecl>
</elementType>

<elementType name = "Receiver" model = "open">
<sequence>
   <elementTypeRef name = "Name" minOccur = "0" maxOccur = "1"/>
   <elementTypeRef name = "Role" minOccur = "0" maxOccur = "1"/>
</sequence>
<attrDecl name = "uri" required = "true">
   <datatypeRef name = "uri"/>
</attrDecl>
</elementType>

<elementType name = "Context" model = "open">
<any/>
<attrDecl name = "id">
<datatypeRef name = "string"/>
</attrDecl>
</elementType>

<elementType name = "ReplyTo" model = "open">
<sequence/>
<attrDecl name = "idref">
<datatypeRef name = "uri"/>
</attrDecl>
<attrDecl name = "uri">
<datatypeRef name = "uri"/>
</attrDecl>
</elementType>

<elementType name = "Agent" model = "open">
<empty/>
<attrDecl name = "idref">
<datatypeRef name = "uri"/>
</attrDecl>
<attrDecl name = "uri">
<datatypeRef name = "uri"/>
</attrDecl>
</elementType>

<elementType name = "Role" model = "open">
<empty/>
<attrDecl name = "uri">
<datatypeRef name = "uri"/>
</attrDecl>
</elementType>

<elementType name = "Name" model = "open">
<datatypeRef name = "string"/>
</elementType>

<elementType name = "Noun" model = "open">
<datatypeRef name = "string"/>
</elementType>

<elementType name = "Verb" model = "open">
<datatypeRef name = "string"/>
</elementType>

<elementType name = "Version" model = "open">
<datatypeRef name = "string"/>
</elementType>

<elementType name = "Ontology" model = "open">
<datatypeRef name = "string"/>
</elementType>

<elementType name = "Encoding" model = "open">
<datatypeRef name = "string"/>
</elementType>

<elementType name = "Timestamp" model = "open">
<datatypeRef name = "dateTime"/>
</elementType>

<elementType name = "Expiration" model = "open">
<datatypeRef name = "dateTime"/>
</elementType>

<elementType name = "Private" model = "open">
<datatypeRef name = "boolean"/>
</elementType>

<elementType name = "Acknowledge" model = "open">
<datatypeRef name = "boolean"/>
</elementType>

</schema>

3.2 Examples

The following is an example instantiation of the proposal.

    <Header>
        <Content-Type>
            <Noun>PurchaseOrder</Noun>
            <Verb>Process</Verb>
                        <Ontology>OAGIS</Ontology>
                        <Encoding>XML1.0</Encoding>
        </Content-Type>
        <Sender uri="http://www.source.com/Requisitioner123456">
            <Name>This is a human readable name for the source requistitioner</Name>
            <Role uri="urn:b2bprotocol:Requisitioner"></Role>
        </Sender>
        <Receiver idref="http://www.destination.com/"></Receiver>
        <Agent idref="http://www.source.com/agents/POSender"></Agent>
        <Context id="http://www.source.com/Requisitioner123456">
                Shopping
                <ReplyWith>
                    Invoice12345
                </ReplyWith>
        </Context>
        <ReplyTo>
        <Agent idref="http://www.A.com/Agents/ReceiveInvoice" >
        </ReplyTo>
        <ObjectReference idref="#1234567">
        </ObjectReference>
     </Header>
     <Body id="1234567">
        ...stuff here...
     </Body>

4. Summary

5. Acknowledgements

Rakesh Mohan, Shaikh Hidayatullah, Lev Mirlas, Doug Wright, Marty Sachs, Manoj Kumar

Notes:

(1) Use available W3 Consortium conventions for defining structure of XML documents. As an example we extensively use the W3C URI convention for attributes to define unique identifiers.

(2) Don't include a mechanism unless it has been used by at least two different B2B protocol standards.

(3) A majority of B2B protocol headers should be easily translate via the XSLT [XSLT] mechanism to this spec. To prove this we will need to show a few/extensive sample of XSLs.

(4) Minimal redundant information. Any concept that needs to be expressed must be expressed in only one place and in only one way.

(5) You can treat the header as Meta-Data of the body of the message. An example is [E5] where XML can describe messages that may be in EDI encoding.

(6) The following are requirements defined by ebXML. Those marked (y) have been addressed by this document.
        (y) How to envelope business documents related messages in a collection
        (y) Physical and/or logical addressing of destination for messages
        (n) Reliable Messaging - you need to know the document got there exactly once
        (n) Routing of messages to single or multiple destination, publish & subscribe (content and subject based), broadcast messages, streaming
        (n) Application level not transport level needed, wire format mapping, support for multiple transport protocols
        (n) Security and use of digital signatures for non-repudiation, and confidentiality/encryption
        (n) Audit trails and traceability/trackability of transactions/documents
        (n) Quality of service
                Processes/transactions complete within required time
                Non-transaction vs. transaction, exactly once behavior
                Level of service negotiation
                Service availability checking
                Transaction Status Inquiry
        (y) Session based & long term transactions
        (y) Platform Independent Interoperability
        (n) Restart and recovery - backup/rollback of business transactions
        (y) Workflow of business documents

Appendix A: XSLT examples

This section will show how to translate commonly used B2B protocols into this header.

References

[BIZTALK] Microsoft BizTalk Framework; http://www.biztalk.org

[CANONICAL] Canonical XML Version 1.0, http://www.w3.org/TR/xml-c14n

[CBL2] Common Business Language 2.0; http://www.marketsite.net/xml/cbl/

[CXML] Ariba cXML version 1.0; http://www.cxml.org

[DSIG] XML-Signature Core Syntax and Processing, http://www.w3.org/TR/xmldsig-core

[E5] The E-5 Guideline is available from the AIAG; http://www.aiag.org/pub/

[ICE] The Information and Content Exchange (ICE) Protocol
26 October 1998, Neil Webber, Conleth O'Connel, Bruce Hunt, Rick Levine, Laird Popkin, Gord Larose

[ISO-8601] ISO 8601 -- Date and Time. International Organization for Standardization

[MIME] RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, Borenstein N., Freed N., 1996/11/27

[MIME2] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two Media Types, http://www.oac.uci.edu/indiv/ehood/MIME/2046/rfc2046.html

[NAMESPACES] Namespaces in XML; Bray, Hollander, Layman eds, World Wide Web Consortium Recommendation;
http://www.w3.org/TR/1999/REC-xml-names-19990114.

[OTP] Open Trading Protocol; http://www.iotp.org/

[OAGIS] Open Applications Group XML Specification; http://www.openapplications.org/_vti_bin/shtml.exe/oagis/loadform.htm

[ROSETTA] RosettaNet Implementation Framework Specification; http://www.rosettanet.org

[RDF] Resource Description Framework, (RDF) Model and Syntax Specification. Lassila O., Swick R. W3C Working Draft.

[RDF-Schema] Resource Description Framework (RDF) Schema Specification. Brickley, D., Guha, R.V. , Layman, A., W3C Working Draft.

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels; S. Bradner, March 1997; RFC2119

[URI] ID, Uniform Resource Identifiers (URI): Generic Syntax and Semantics; http://www.ietf.org/rfc/rfc2396.txt

[XML] Extensible Markup Language (XML) 1.0, Tim Bray, et al. W3C, 10 February 1998; http://www.w3.org/TR/REC-xml

[XSLT] XSL Transformations (XSLT) Specification Version 1.0, 13 August 1999; http://www.w3.org/TR/xslt

[XSDL] XML Schema Part 1: Structures, David Beech et al.; http://www.w3.org/TR/xmlschema-1/

Graveyard

3.8 The Trace Element

3.8.1 Intent
    The Receiving software artifact annotates this element with its identifier and a timestamp.
3.8.2 Also Known As
    Received, Path, TA3, Audit Trail
3.8.3 Known Uses
    [BIZTALK]

ebxml-transport message

Business to Business (B2B) Messaging Header

Status of this document

Table of Contents

Abstract

1. Introduction

1.1 Business to Business Messaging

1.2 Objectives

1.3 Design Requirements

1.4 Implementation Requirement

1.5 XML Guidelines

2. Header Elements

2.1 The Header Element

2.2 The ObjectReference Element

2.3 The Object Element

2.4 The ContentType Element

2.5 The Sender and Receiver Elements

2.6 The Agent Element

2.7 The Context Element

2.8 The ReplyTo Element

2.9 The Acknowledge Element

3. Schema

3.1 XML Schema Definition [XSDL]

3.2 Examples

4. Summary

5. Acknowledgements

Notes:

References

3.8 The Trace Element

2.1 The `Header` Element