Re: RM Group Definitions

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

Henry,

> If I'm wrong and there is multiplexing, you are right and
> there is a BIG problem.  If this is a problem, the best
> way to deal with would be to eliminate the muxing (rather
> than try to reinvent all the mechanisms found in transport
> protocols to deal with it -- this is a hard problem).

The issue of multiplexing is certainly interesting. We had a lot of
discussion around this--and the level at which the RM spec should
"play"--during the San Jose meetings. It would appear that we're
attempting to not tie the RM spec to the service interface layer (which
would need to consider things like application-based grouping of
messages), yet we're trying to disassociate the RM work from the
underlying transport.

The biggest problem that I see with focusing exclusively on some middle
ground is this: 

What the spec needs to ensure is that the headers contain the right
information--and support the right semantics--to guarantee over-the-wire
interoperability. The reality, as I see it, is that what will be
transported over the wire will effectively be a multiplexed message
stream in order to:

- Support multiple simultaneous conversations over the same link
- Support multiple simultaneous logical senders and receivers over the
same link
- Support varying QoS for said conversations and logical parties
- Manage this multiplexed stream in an efficient manner (implying
framing and acknowledgment)

I don't see that these real world issues are addressed, arguably to
simplify the initial spec. My feeling is that we are postponing the
headache by not dealing with them now. If we don't address these issues
prior to the 1.0 spec, I feel we risk either divergent implementations
that do not interoperate, or lack of adoption for ebXML transport
because it does not address real world requirements.

My feeling is that we should either move up and treat the RM work as
part of the service interface, or move down and address reliability
across various transports. Focusing on some nebulous middle layer
doesn't seem productive toward the end goal.

-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