Payload Services Proposal Draft 1
- Document identifier:
p-ebms-3-payload-svc-01
Table of Contents
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.
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.
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.
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.
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.
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.
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 ::= " "
This section defines services that every ebMS 3.0 compliant message handler must implement.
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.