This paper provides an overview of the ebXML Transport Routing and Packaging and a description of the requirements that have been identified.

It describes:

• an overview and description of the scope of the group's work
• the objectives of the group
• a draft diagram that outlines the relationship of the group to other groups within ebXML
• the requirements for Transport, Routing and Packaging
• a definition of the terms used in the description of the requirements, and
• some examples of how the different sequences in which message can be exchanged

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This document is a draft for Public Comment. The document represents work in progress and no reliance should be made. It has been updated to reflect the results of the ebXML Transport, Routing and Packaging project team's meeting during the ebXML conference in Brussels in early May 2000. Most changes have been made to section 4. Requirements.

In outline the working group will develop deliverables that:

1. provide an envelope and header for routing of message content
2. define template sequences for the exchange of messages
3. provide support for payloads of any type of digital data
4. adopt security protocols that enable:

1. non repudiation of sending of messages and acknowledgements
2. privacy and integrity of communications between parties
3. authentication of senders of messages
4. control over access to services

1. support verifiable audit trails
2. provide mechanisms for reporting on errors or other problems
3. support a messaging protocol for reliable message delivery
4. define the information required that describes how to interact with a service
5. provide a default method of usage that enables bootstrapping of services

The objectives of the working group are:

This section contains a number of diagrams that explain the relationship between the Transport, Routing and Packaging Group and other activities within ebXML. Definitions of words or phrases in italics may be found in section 5 Definitions.

This diagram illustrates the relationship between the work of the Transport Routing and Packaging group (TR&P) and the other groups of ebXML. A more detailed description of the scope of the TR&P group is shown by the diagram below.

The scope of the Transport, Routing and Packaging group is defined by the items colored red in the diagram above. All specifications will be produced initially in a syntax neutral and/or language independent way.

The intention is that representations of this information in specific languages or syntax are then separately developed. For example the message wrapper, header, etc could be rendered in XML or perhaps as name-value pair extensions to MIME. Similarly the Service Interface could be rendered as Corba, Java, Com, etc.

Note that the definition of the XML or other documents that are transported using the Messaging System as specifically out of scope.

Enterprise Systems are applications such as accounting systems, ERP systems or other systems that contain data that needs to be communicated with other parties over the Internet.

Messaging Systems are applications that manage the exchange of messages between the two parties. It is agnostic as far as the content or payload within the message is concerned.

Messaging Systems use a Messaging Policy Repository to control the behavior of the Messaging System. This contains parameter and other information about how to send messages to the other parties that the need to be sent messages.

Integration Systems are applications that communicate with the Enterprise system and the Messaging System and effectively enables the Enterprise System to exchange data over the Internet. Integration Systems will be required in the short term to integrate existing Enterprise Systems to the Messaging System. Over time, it is probable that Enterprise Systems will be developed or enhanced that can talk natively to the Messaging and other systems such as the system that provides access to data held in the Repository.

Integration Systems use Integration System Repositories that contain information on how to format documents and generally communicate between the Messaging System and the Enterprise System

The diagram above illustrates the types of data flow required in order to keep the various repositories in step.

Each of the items marked with an asterisk in the diagram above need Business Processes defined that enable the data in the various repositories to be kept in step.

The Repository Management System is no more than just another "System that needs to send/receive data over the Internet" and uses the Messaging System to send receive messages in the same way.

The "Messaging System" provides a Service that reliably exchanges messages over the Internet between any two parties. It is completely independent of the content or the payload of the message

The "Repository Management System" provides a Service that can be used to read/update the content of the repository. It would:

• have a Service Interface so that the content of the data in a repository held locally could be maintained, and
• use the Service Interface of the Messaging Service to access the content of repositories held remotely.

Note that the Repository Management System for the Master Repository would also work in the same way.

The Repository Systems used to maintain each of the repositories (Integration, Messaging and Master) may be different from each other and be provided by different vendors. However they should all use the same basic set of documents and document choreography to enable interoperable communication.

The rationale is that the Repository Management Service is really nothing more than a distributed system that reads or updates data on local or remote repositories that has a Service Interface to manage/access the repository content.

This type of "layering" can be used to describe a number of other Service Interfaces that will use the basic messaging service interface, for example:

• a Publish & Subscribe Interface
• a Large Document Transfer Service, for example, to transport multi-MB files reliably by splitting them into several smaller parts that are each transported separately

This section describes the requirements that the working group aims to meet. They are divided into the following sections:

• Envelope and headers for business documents
• Reliable Messaging and Error Handling
• Messaging Routing
• Security Requirements
• Audit Trails
• Quality of Service
• Platform Independent Interoperability
• Restart and Recovery

1. delivery occurs at most once.
2. failure to deliver shall be reported, if the sending party requires it.
3. inability to send a document may be notified to the party that sent the document
4. if an application/business level response message is not received within expected timescales then there shall be mechanisms that support recovery
5. the correct sequence in which related messages are sent can be identified
6. recovery from failure to receive a response message should include:
1. how the "expected timescales" after which recovery starts are specified
2. descriptions of the messages sent to carry out the recovery

1. Error messages should be capable of reporting on:

1. errors associated with the underlying transport protocol, e.g. HTTP
2. errors in the message wrapper, message header or message routing information
3. errors with the way documents are wrapped inside their message envelopes
4. errors associated with failed attempts at reliable once-only delivery of messages
5. errors in the documents that are being transported
6. errors in the sequence in which messages are exchanged
7. abnormal errors with the services that processed the documents (e.g. the service crashed) and
8. business failures where the service completed but did not realize its hoped for outcome (e.g. out-of-stock)

1. Inquiries should be possible to determine why Message Sets failed, (see Message Set Status Inquiry below).

1. to a single party, e.g. by specifying a URL
2. to multiple parties, either by:
1. specifying a list of URIs in the Message Header, or
2. a distribution list held separately from the header
3. to an agent or intermediary for forwarding to the next party

1. Individual messages shall be capable of routing serially or in parallel with other related messages
2. Publish and Subscribe

1. Messages may be distributed to the members of a list of parties using a "Publish and Subscribe" mechanism
2. the anonymity of the subscriber may optionally be maintained

The Quality of Service of the interaction between two Services is defined in a Transport Service Level Agreement (TSLA). The parameters in a TSLA vary depending on the nature of the Service.

Parameters must be present in every TSLA that: .

1. support Session based and Long Term Transactions
2. enable recovery from failure to receive an anticipated response(s) to a message
3. enable a Receiving Service to inform a sender of a message of the Receiving Service's expected maximum Response Time(s)
4. enable a sender of a message to inform the recipient of a message, of the Response Time(s) that the sender expects
5. enable a sender of a message to discover if a Receiving Service is operational and therfore able to receive messages
6. enable a sender of a message to discover the hours of operation of a Receiving Service The hours of operation is the period of time that the service is available to process the message
7. enable a Receiving Service to indicate to the sender of a message that it is too busy to process a message within expected timeframes. This supports congestion management
8. enable a sender of a message to discover from a Receiving Service the current status of a Message Set. This is Message Set Status Inquiry.
9. enable the Sending and Receiving Parties to discover and agree:
1. the document choreographies that can support their processing requirements
2. the parameters that control how the parties will use cryptography
3. how they will achieve reliable messaging and error handling when required
4. the transport protocols to be used
10. TSLAs may be negotiated between two Parties that apply to:
1. an individual message
2. an individual message set
3. all messages associated with one or more services
4. all interactions between two parties

1. additional types of data in message headers and message routing information
2. new values for codes
3. new ways and methods of exchanging data

The following are a list of definitions of the terms associated with the transport of messages over the Internet. They are derived initially from work being done within the IETF.

It is split into two sections:

• Documents, Parties, Messages and Document Exchanges, and
• Services and Message Sets

Words or phrases that are defined elsewhere are highlighted in italics.

This section describes how Parties, such as buyers and suppliers, customers and merchants, can transmit Documents contained in Messages in order to request execution of Services.

All the Documents and other data in a Message are contained within an outermost Message Envelope.

A Message can optionally include Digital Signatures so that:

1. the identity of the Party sending the Message can be authenticated
2. any changes to the message and the documents they contain can be detected.

Services are requested by sending one or more Documents in a Request Message to a Party who then:

1. processes the Request Message by carrying out a Service and
2. optionally generates a Response Message indicateing result.

At a minimum a Document Exchange consists of a Request Message and an optional Response Message although there might be additional Exchange Messages between the Request Message and the Response Message.

Error Messages are used to report permanent or transient problems or errors in a Message.

More detail is provided below.

A Document is any data that can be represented in a digital form.

Examples of Documents include:

1. a set of XML Elements

1. an XML Document
2. an HTML Document
3. a word processing file
4. an Adobe Acrobat PDF file
5. a binary file
6. part of larger document.

A Party is a company, organization or individual or other entity that can generate, receive or relay Documents.

Examples of a Party include:

1. a Merchant
2. a Customer
3. a Lawyer
4. a Bank
5. a government department or agency
6. an intermediary or agent
7. a software agent

A Party is also used to refer to systems or servers that are carrying out Services or processes on behalf of a Party.

A Message is data that is sent from one Party to another. A Message consists of information such as:

1. a Message Header that indicates who sent, who should receive and the context for sending the message
2. Message Routing Information, that indicates how the message should be / was delivered
3. Digital Signatures to:

1. bind the data in the message, or elsewhere, together, and
2. ensure that changes to the data can be detected
3. enable authentication of the sender of the message

1. Documents which are the business data that actually needs to be sent

All the data in a Message is contained within a Message Envelope.

Examples of a Message include:

1. a Purchase Order that is sent by a buyer to a supplier
2. an Invoice that is sent by the supplier back to the buyer
3. a request to make a payment of $50 sent to a Credit Card acquirer
4. the authorization received from a Credit Card acquirer as a result of making a payment
5. Status Data indicating the success or failure of a Service

A Message Header is an XML construct that contains the additional data that needs to be associated with the Documents in a message so that they can be sent to and successfully processed by a Party. It can contain information such as:

1. Message Set Identity data to identify the set of Messages that are related to one another through one or more Document Exchanges
2. Message Identity data to enable the Message to be identified and referenced within the Message Set
3. a Message Manifest to identify the documents, other than the Message Header, that are contained within the same Message Envelope
4. Action Data to indicate the Service that is being sent the message and the reason for sending
5. Organization Data that describes one or more of:
1. the Sender organization that sent the Message
2. the Recipient organization(s) that ought to receive the Message
3. the Authorizing organization(s) that provide evidence that a requested Service should be carried out.
6. Status Data that describes the results of carrying out a Service.

The Message Manifest contains references to the other documents, apart from the Message Routing Information document, that are contained within the same Message Envelope.

The purpose of the Message Manifest is to facilitate locating and validating that all required Documents contained within the Message Envelope are present.

Examples of the types of documents that might be referenced by a Message Manifest include:

1. a Purchase Order
2. a Purchase Order and a picture of the requested goods
3. a Purchase Order and a digital signature

A Message Envelope is the outermost container for a Message. It can be such things as:

1. an XML Document, or
2. a multi-part MIME message

A Simple Document Exchange consists of:

1. a Request Message sent from one Party to a second Party, followed by
2. an optional Acknowledgement Message sent by the second party back to the first party, followed by
3. an optional Checked OK Message sent by the second party back to the first party followed by
4. an optional Response Message that is returned as a result of processing the Request Message.

Examples of instances of a Simple Document Exchange include:

1. a Purchase Order sent by a buyer to a seller and the acknowledgement from the seller of its receipt
2. a Purchase Order sent by a buyer to a seller and the Invoice that is sent back as a result of fulfilling the order
3. sending a document for review by a lawyer followed by the legal opinion that is sent back as a result

A Multiple Round Trip Document Exchange consists of:

1. a Request Message sent from one Party to a second Party, followed by
2. a series of Exchange Messages that are exchanged between the two Parties until finally
3. the second Party generates and sends a Response Message back to the first Party.

Examples of Multiple Round Trip Document Exchanges include:

4. the exchange of messages required to make a payment using payment method protocols such as [SET] or [Mondex]
5. the exchange of messages required to negotiate an agreement on terms and conditions.

An Exchange Message is a Message that is sent between one Party and another after the sending of the initial Request Message and before the sending of the final Response Message.

Examples of Exchange Messages include:

1. intermediate messages that are part of a Payment Protocol
2. a counter offer to an offer made as part of a negotiation.

An Error Message is a Message that reports on a problem in an earlier Message that prevents the earlier Message from being processed in a normal way.

Examples of an Error Message include:

1. an Error Message reporting that an XML document was invalid or did not conform to its XML schema
2. an Error Message reporting a Transient Error that the Server processing a Message is busy and therefore the original Message should be resent at a later point in time
3. an Error Message that reports on an error in the underlying transport protocol.

A Service Definition describes a process that can be carried out by a Party as a result of receiving a Request Message that requests the execution of that Service.

A Service Definition can consist of either:

1. a Document Exchange, or
2. a set of Sub-Services

Examples of Service Definitions include descriptions of:

1. a Purchasing Service that enables a customer to purchase goods on-line
2. an Order Processing Service that processes an Order and generates a response as a result
3. a Payment Service that accepts a payment and provides a receipt
4. a Fulfillment Service that fulfills an order at the request of a Merchant.

A Sub-Service is a Service that is executed at the request of and as part of another Service.

Examples of Sub-Services include:

1. a payment service that occurs as part of a purchase
2. a tax calculation service that calculates the tax due as part of an order processing service.

An example of how services, sub-services and document exchanges relate to one another is illustrated by the diagram below.

A Sub-Service Choreography is a description of the dependencies that control the sequence and choices that determine which Sub-Services are executed when carrying out a Message Set.

The Sub-Services in a Service will have dependencies between them. Dependencies can be:

1. Serial. One Sub-Service shall start only after the completion of another Sub-Service
2. Alternative. One Sub-Service may be executed as an alternative to another
3. Iterative Loop. A Sub-Service may be repeated a variable number of times
4. Conditional. The execution of a Sub-Service is conditional on the state of another Service. This may be used in conjunction with Serial, Alternative and Iterative Loop dependencies.
5. Parallel. A Sub-Service may execute in Parallel with another Service
6. Concurrent. A Sub-Service shall Execute at the same time as another Sub-Service.

An example of a simple Sub-Service Choreography is a Purchase Service that consists of three Sub-Services:

1. an Offer Service that conveys an Offer for sale of goods. This Sub-Service has no dependencies and therefore starts first
2. a Payment Service that carries out the Payment which has a Serial dependency on the Offer Service
3. a Delivery Service that delivers the Digital Goods, that has a Serial Dependency on the Payment Service

A Message Set is an instance of the execution of a Service.

Examples of a Message Set include:

1. a Purchase Message Set that buys a Company Report for $20. It consists of three Sub-Service instances:
1. an Offer Service instance to buy the Company Report for $20
2. a Payment Service instance that accepts a Payment for $20 using a credit card, and finally
3. a Delivery Service instance that delivers the Company Report as an HTML web page.
2. a Buying Service that consists of the following Sub-Services:
1. three Price Negotiation Service instances that negotiate the price of a Photocopier
2. a Purchase Order Service instance that places the order for the Photocopier.

Transport Service Level Agreement (TSLA) consists of information mutually agreed between two paties that manages and controls the ebXML "transport" software that sends and receives messages.

Transport software is software that is constructed according to the specifications produced by the ebXML Transport, Routing and Packaging Project Team.

Examples of information in a TSLA include:

1. timeout parameters
2. retry counts
3. security parameters
4. respponse addresses

This document is a collective development effort of all the members of the Transport, Routing and Packaging project team.