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.