D-AG0017 [was Re: Reliable Messaging and Business Requirements - [Was DAG006]]

All,

We've had some interesting and spirited discussions on this thread that to
some extent start from confusion between distinct OASIS TC's and familiarity
with an older version of ebXML Messaging.  I would like to mention a few
potential clarifications:

    * ebXML Messaging makes no attempt to cover issues such as distributed
transactions.  While reliable messaging may be considered an all or nothing
distributed transaction, it's a very specific application of that concept
and doesn't extend beyond the messaging infrastructure.

    * Since ebXML Messaging is layered on top of SOAP and (especially in the
recent version 2.0, a new OASIS TC specification) takes great pains not to
invalidate any of the extensibility or other features inherent in SOAP, it
does not require multipart messages.  The "bindings" concept provided by
SOAP continues to resonate in ebXML Messaging, meaning those that explicitly
exclude attachments and those that require their use are also possible.  The
present binding recommends putting payloads into attachments but does not
require such an implementation.  Compliant implementations would have to
handle both.

    * ebXML Messaging fits into the larger ebXML architecture but was not
designed with that use case alone in mind.  Very early in the process, the
group began working on a generic messaging infrastructure including
security, reliability and (per message) descriptive features appropriate for
business documents of any form.  That's a pretty generic requirement set and
parts should fit into any business worthy web services architecture.

    * Should mention that points about ebXML Messaging covering more than
one "slot" in our architecture and possibly not being loosely coupled enough
may remain true even in the 2.0 version.  However, the bounds between
different parts of the specification exist primarily in the compliance
rules.  Our suggestions to the ebXML Messaging TC may result in finer
grained "profiles" of the features in this good specification.  In turn, we
may find some of those smaller pieces fit into our architecture quite well.

Separately, I would not like to see a particular W3C WG set up to consider
or design SOAP extensions in any generic sense.  Such a group would very
quickly be overloaded with "customers" requesting additions to the
prescribed SOAP extensions.  However, W3C has historically been focused on
the horizontal requirements and leaves vertical extensions  to other groups.
With respect to D-AG0017, we should similarly look at particular horizontal
business requirements such as reliability but not attempt to solve every one
possible.

thanx,
    doug

Received on Friday, 15 March 2002 02:02:10 UTC