OASIS ebXML Messaging 3.0

Payload Services Proposal Draft 1

Document identifier:


Table of Contents

1. Payload Services
1.1. Introduction
1.2. Example Use Cases for Payload Services
1.3. Payload Service Invocation
1.4. Required Services

1. Payload Services

1.1. Introduction

Payload services refers to functionality implemented by the messaging server to automatically perform some manipulation on payload content either before envelope digital signing (if non repudiation is being used) and message transmission, or after digital signature verification (if non repudiation is being used) and before passing the payload(s) in question to the application.

1.2. Example Use Cases for Payload Services

1.2.1. Transparently converting XML content to ASN.1 and vice-versa

There are cases where it is desireable to use a more compact format, such as Abstract Syntax Notation to transmit data between partners, while still maintaining the easy-to-process and display qualities of XML. By using ASN.1's XML Encoding Rules (X ER), it is possible to convert between ASN.1 and XML.

Payload services could be used to automatically create ASN.1 representations of XML payloads prior to the message being transmitted. On the receiver's side, the same payload service could be used to convert back to XML. The net result being that th e application developers only see XML on both sides.

1.2.2. Compression

Sometimes, using a specialized compression algorithm can yield impressive reductions in a server's network utilization.

Payload services could be used to automatically compress and decompress payload content.

1.2.3. Encryption

Users often apply encryption at the payload level to ensure confidentiality of their payloads. Often, all that is needed to ensure confidentiality is to encrypt a single payload, as oposed to heavy weight approaches such as using S/MIME to encrypt an ent ire message.

Payload services could be used to encrypt and decrypt payloads.

1.2.4. XSL Transforms

As XML vocabularies evolve, business processes making use of XML messages will need to evolve with changes to their XML vocabularies. In cases where it would be too costly to modify the application(s) producing and consuming the XML, XSL can be used to p erform structural transformations.

Payload services could be used to automatically execute an XSL stylesheet prior to transmission, or before being delivered to the application.

1.3. Payload Service Invocation

Payload service invocation can be requested using two methods: MIME headers, or CPA entries.

In cases where invocation requests are specified in both the CPA and the attachment's MIME header, the CPA takes precedence. If the CPA entry explicitly forbids the use of payload services, then MIME headers MUST be ignored.

Payload services MAY NOT be invoked on the 0th attachment -- the SOAP envelope.

1.3.1. Invocation by MIME headers

Service Invocation by MIME headers placed in the payload attachments uses two MIME headers: X-PayloadServiceOnSend and X-PayloadServiceOnReceive. An additional header, X-PayloadServiceParams, MAY be used to specify extra attributes needed by the payload service to complete processing.

The value of the X-PayloadService* headers are composed of string(s) identifying the service(s) to be applied. Chaining of payload service is possible by separating services in the header value with a comma (','). Payload services MUST be exec uted in order from left to right. It is recommended that service values be valid URNs or URIs to reduce the likelihood of name clashes. Header values MUST not contain commas.

Figure 1. BNF of Headers

completeheaders ::= svcheadername (newline paramheader)?

svcheader ::= svcheadername ":" space ((",")? simpleheadervalue)*
paramheader ::= paramheadername ":" space ((",")? simpleheadervalue)*
svcheadername ::= "X-PayloadServiceOnSend" 
		| "X-PayloadServiceOnReceive"
paramheadername ::= "X-PayloadServiceParams"
simpleheadervalue ::= A string without commas
newline ::= "\r\n"
space ::= " "

1.3.2. Invocation by Collaborative Protocol Agreement


TODO: discuss with CPPA TC.

1.4. Required Services

This section defines services that every ebMS 3.0 compliant message handler must implement.

1.4.1. Encryption Service

This service, named urn:oasis-open:committees:ebxml-msg:ps:encrypt provides a way of encrypting payloads using a variety of algorithms. This specification does not define which algorithms should be implemented, but W3C XML Encryption is recommended.

Example 1. Sample header fields for XML Encryption

X-PayloadServiceOnSend: urn:oasis-open:committees:ebxml-msg:ps:encrypt
X-PayloadServiceParams: Path=/Invoice, KeyAlias=accountspayable

Example 2. Sample CPA entry