Re: issue 077

[Pete Wenzel <pete.wenzel@Sun.COM>]

Thus spoke Jacques Durand (JDurand@us.fujitsu.com) on Mon, Sep 25, 2006 at 06:45:09PM -0700:
> 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.

> 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.

This is a good addition, but I would propose replacing the title and
first paragraph with something like this instead, to emphasize that
ebMS is itself a Web Service (removing any semblance of an "us versus
them" mentality):

1.3 Web Services and Their Role in an eBusiness Messaging Framework

A major design choice in V3, is the specification of the MSH and its
associated processing rules as a Web Service.  The intent is to make
use of other relevant Web Services specifications that fulfill certain
messaging requirements, and build upon that base by adding what is
necessary for a complete eBusiness messaging service.  For example,
the message security and reliability requirements are met through the
use of other Web Services standards and their implementations; and
[something about what eb:Messaging adds in terms of business value].
ebMS 3 brings this all together into a single, coherent framework.

The remainder looks fine, subject to the corrections you already
provided in your subsequent message.

> 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. 

--Pete
Pete Wenzel <pete.wenzel@sun.com>
Sun Microsystems, SOA & Business Integration
Standards & Product Strategy
+1 (626)471-6311, Sun x61311, US-Pacific TZ