Comments on Messaging Service Specification v0-1, Aug. 10, 2000

[Gordon van Huizen <gvanhuiz@progress.com>]

Line 105: Add something like the following, since the spec will be have
scope beyond the original envelope and header specifications: "This
specification also discusses messaging service behavior that the
recommended message structure is intended to support.". We need to make
it clear that there are normative semantics behind the message
structure, and that this document discussed them.

Lines 124-127: The list here needs to be expanded to include the items
in the note on lines 111-112.

2.2 Transport Envelope

Lines 180-189: Some degree of mapping to transport envelopes must be
addressed in the spec, at least in the form of a recommendation, for
interoperability.

3.1 Root Element

Lines 387-388: In San Jose we discussed rolling Acknowledgment and Error
message types (which are both messaging-service specific) into a generic
"System" message type, as the primary intent of these types is to
indicate whether the payload should be processed by the application or
by the messaging service. Employing the generic System type also has
other benefits:

- It allows for additional messaging-service specific messages beyond
acknowledgment and error (such as start of frame, heartbeat, etc.).

- There is no need for application programmers to be aware of
system-level messages and their types or subtypes. Enumerating them may
prove confusing to application developers.

I also have a concern about the use of the term "messaging-service
specific". Does this mean that the messages are specific to (a) a
particular messaging service implementation or (b) ebXML messaging
services in general? If (a), they shouldn't be enumerated in the spec at
all but my hair-trigger interoperability exception gets thrown. Either
way, the term could be more clear.

3.3.4 ReliableMessagingInfo

Line 517: <AsbestosSuitOn> A number of references in other ebXML
documents indicate that the purpose of reliable messaging is for
guaranteed delivery ("OnceAndOnlyOnce" semantics, which is even called
out specifically in some cases). It's fair to say that this is how ebXML
reliable messaging is being marketed, and a reasonable expectation to
many. Why, then, do we pull back here to "AtMostOnce"? Since we fully
anticipate that ebXML implementations can ride atop reliable messaging
infrastructures such as MQSeries and JMS implementations, why are we
reluctant to provide a value of OnceAndOnlyOnce within the enumeration
for the DeliverySemantics attribute? Presumably the ability to support
guaranteed delivery is negotiated at the TPA level. If a given provider
doesn't support guaranteed delivery, fine. But let's at least provide a
value in the message header for it.

If we are dead serious about NOT supporting OnceAndOnlyOnce in ebXML, 
we need to ensure that other ebXML documents make it clear that it is
not supported so that expectations are appropriately calibrated. My
opinion, though, is that we should support OnceAndOnlyOnce for providers
that are willing to offer it.

A further issue is that AtMostOnce should not imply reliability,
although in our specs it does. The literal role of AtMostOnce is limited
to dup elimination. The processing and performance impact for what we
currently specify above and beyond dup elimination is significant. If
the intention is to provide additional semantics beyond AtMostOnce ("I
don't guarantee that a message will arrive safely, but I will make my
best effort to be reliable by providing persistence for all reliable
messages at both sides of the link and I can tell you whether a message
did or did not make it to the receiving message service persistence
store"), there should at least be a way to specify whether or not a
given message requires this level of reliability. Simply indicating
"AtMostOnce" or "Unspecified" does not offer this distinction.  If we
continue to NOT support the notion of guaranteed messages
(OnceAndOnlyOnce), my recommendation would be to completely decouple
"persistent" messages from "at most once" messages--a decoupling for
which there is some precedence. If others feel that we should not
decouple these semantics for some reason, we need to find an alternative
to calling our reliable semantics "AtMostOnce".
</AsbestosSuitOn>

SIDE ISSUE: Another issue that springs to mind when contemplating
reliable messaging from TPA through to message header elements is this:
How do we handle discrepancies between what's negotiated in the TPA and
what is specified in a message header? For example, what do we do if the
TPA indicates that a party can't handle reliable messaging, but a
message comes through with reliable semantics set? Presumably this is an
error condition, but the error semantics need to be thought through
and captured. There are similar issues with security agreements. No
doubt all this will be thought through as we work through the error
handling, security, and other areas but I wanted to raise the issue.


-gvh-
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard