issue 077

Pete:

Here is a proposal for addition in the intro (propose to insert just after 1.2 section, before current 1.3 ), as we discussed the need for a little explanation on relationship with Web services specs.

I think it is addressing [part of] isue077.

-Jacques

1.3 Reusing Web services specifications, their role in a messaging middleware

A major design choice in V3 is the reuse of Web services specifications that concern the protocol level. The message security and reliability features are reusing WS standards and their implementations.

The message SOAP body has been freed for business payload. The ebMS header is just a SOAP extension among others. As a result, V3 is significantly more compliant than V2 with the SOAP processing model, and apt at composing Web services standards that are defined as SOAP extensions. Compliance of V3 with future WS-I profiles - in particular BP 1.2, BP 2.0 and RSP profiles - will be an objective in subsequent releases, as it is expected that these profiles will be natively supported by most SOAP platforms.

Compliance with Web services standards does not remove the rationale behind an internet-based messaging middleware. Often, document-centric eBusiness and eGovernment exchanges need to clearly dissociate messaging functions from the way these messages are consumed on the back-end. Such consumption may take place according to various models, as mentioned in 1.1. The use of [SOAP] message header elements that represent standard business metadata (user or company ID, business conversation, business service and action, etc.), is a key feature for supporting a decoupled binding with back-end business processes. At the same time, past experience has demonstrated that the messaging layer must be more supportive of business transactions: messages are parts of basic choreographies that map to higher-level business exchanges between partners. Monitoring and enforcing properties of such multi-message exchanges (timing, error handling, quality of service, binding to underlying transport, etc.) requires explicit support by the messaging layer, allowing a flexible, contract-based control by the message producer and consumer layers.

ebxml-msg message