Re: Reliable Messaging Spec v0-078

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

While creating a new protocol specifically for ebXML sounds interesting,
the business questions to ask are:

- What benefits would it have over RM-over-HTTP? RM-over-SOAP? Reliable
W3C XP (should such a thing come to pass)? I'm assuming
performance--could this be quantified? What else?

- Why do this specifically for ebXML?

- What do we believe the adoption would be?

- How would it position ebXML?

-gvh-  

Ajay K Sanghi wrote:
> >i have been
> > thinking about it
> > work directly over tcp/ip, as we are now doing with smtp and
> > http... what do
> > you think of that? and are there any concerns?
> 
> I assume, you mean making ebXML as first class application (or application
> protocol) over TCP/IP, just like SMTP, HTTP and issues/concerns associated
> with the same.
> 
> Yes, I would like to see ebXML sit directly on top of TCP/IP (at later
> date), with SMTP as an excellent starter.
> 
> I noticed Martin using the term "logical channel" in response to Sanjay's
> email, which is a key point. In my earlier mail, I suggested going through
> BX.25 specs ("B" stands for Bell Labs), which are very comprehensively
> done - used by AT&T for their NEMOS and 800 DCS project (that was 1992).
> Basically, one LAPB link can contain multiple X.25 virtual circuits (logical
> channels) and each virtual circuit is dedicated to one BX.25 session (I
> think - it has been a while I worked on it). Over and above all the
> reliability that X.25 provides, BX.25 was mainly used for session recovery
> (if lost virtual circuit) and resynchronisation (continue from the point
> where it let off). Key thing leveraged from X.25 was "flow control" besides
> "reliability". ebXML should also leverage flow control and reliablity from
> TCP.
> 
> Following is just loud thinking-
> Assumption: well known port for ebXML is defined (say 1000).
> Context: <sender ip, reciever ip, sender port number, receiver port number>
> forms unique combination to connect to an instance of application
> Scenario:
> One ebXML receiver (server) is listening on port 1000
> One sender sending 2 ebXML messages concurrently,
> case 1: on 2 different sender port numbers
> case 2: on 1 (same) sender port number but the 2 ebXML messages are
> multiplexed
> 
> case 1 does not have the problem associated with flow control. i.e. one
> ebXML  session blocking the other
> 
> case 2 would involve building flow control in the ebXML RM layer so that the
> other ebXML message is not blocked - defining flow control would increase
> complexity, besides invloving negotiation at application protocl layer for
> the window size, etc.
> 
> more cases can also be introduced like the receiver re-connecting on a
> different port for each ebXML message once the ebXML listener identifies a
> ebXML message request...
> 
> Issues:-
> 1. should ebXML RM support auto resyncronisation and recovery after the
> session has been timed-out.
> 2. if yes, how to identify the resynchronisation point. resync should be
> supported for "best effort" cases also, once the decision is yes (may be as
> optional feature).
> 3. sequence number is ok for resync purpose but then a "session-id" (logical
> channel) should also get added. who allocates the session-id? sender or
> receiver? since it's going to be common to both. Also, some more resync
> protocol messages have to be added.
> 4. Who initiates the recovery and resync process (sender or receiver or
> combination of both)? for example,sender recovers but receiver resyncs. Note
> recovering has to do with only identification of the lost session, while
> resync has to identify the point within the session from where data transfer
> is to begin.
> 5. should ebXML RM assume window size of 1, or should a window be defined. I
> think, window complexity should not be added.
> 6. does session establishment involve any negotiation for QoS. Can receiver
> deny "at most once" effort to downgrade the session to "best effort".
> 7. Delivery confirmation can be achieved even without sequence numbering but
> for resynchronisation, sequence numbering  (or some identification) with
> every packet is required
> 8. I find timing-out at RM level quite dicy, without the knowledge of timers
> at lower level as mentioned in my earlier email. I think retrying to send
> the data at RM level should be replaced by re-establishing for resync and
> recovery in case that is to be supported.
> 9. arhcitecturally, it seems there would be one ebXML listener and each call
> reqquest would be handled by a different thread
> 
> these are some of the points that i can immediately think of...
> 
> Thanks and regards,
> 
> Ajay
> 
> > -----Original Message-----
> > From: Rik Drummond [mailto:rvd2@worldnet.att.net]
> > Sent: Wednesday, September 27, 2000 9:53 AM
> > To: Ajay K Sanghi; ebxml-transport@lists.ebxml.org
> > Subject: RE: Reliable Messaging Spec v0-078
> >
> >
> > Ajay. thanks for the nice comments on the draft everyone has been working
> > their butts off...
> >
> > we decide to make this transport independent. i have been
> > thinking about it
> > work directly over tcp/ip, as we are now doing with smtp and
> > http... what do
> > you think of that? and are there any concerns?
> >
> > best regards, rik
> >
> > -----Original Message-----
> > From: Ajay K Sanghi [mailto:sanghi@giasdl01.vsnl.net.in]
> > Sent: Monday, September 25, 2000 6:46 AM
> > To: Jim Hughes; ebxml-transport@lists.ebxml.org
> > Subject: RE: Reliable Messaging Spec v0-078
> >
> >
> >
> > Hi Jim,
> >
> > Since this is my first communication with the ebXML group, I take this
> > opportunity to congratulate ebXML team for excellent work being done. In a
> > very recent Bill Gates talk in New Delhi, I asked him the question of
> > Microsoft's position w.r.t ebXML, particularly in relation with Biztalk. I
> > don't hink he has heard of ebXML, unless he was unable to understand my
> > Indian accent ;-) All he said was that Interoperabilty is more important
> > (agreed) and that XML will facilitate that (he was speaking on Microsoft's
> > .NET strategy).
> >
> > I am reading Sep 22, 2000 spec for ebXML TRP Reliable Messaging.
> > I feel that
> > Sequence Numbering is NOT required for achieveing Reliablity at ebXML MSH
> > layer. We must leverage reliablilty provided by the protocol themselves.
> >
> > Assumption for Reliable Messaging should only be that it should use a
> > (reliable) connection oriented protocol (CONS like X.25, TCP - they are
> > reliable, meaning "ordering" is guaranteed). However, this reliablity does
> > not "guarantee" that the ebXML MSH has received the message, for which a
> > "delivery confirmation" element/attribute may be added instead of sequence
> > number. Whenever delivery confirmation element/attribute is set
> > to YES, the
> > receiving MSH will respond with ebXML message (just the ebXML header,
> > confirming receipt). Note (Key Point) - on account of this
> > message (delivery
> > confirmation request message) riding on top of CONS, a response to this
> > message would necessarily mean that all previously sent messages has been
> > received. Infact, if the recieving MSH is sending back some data, this
> > delivery confirmation response can be piggybacked. There is absolutely no
> > need for persisting packets as suggested in the specs. This delivery
> > request/response can be thought of as a ebXML-MSH-ping.
> >
> > Suggestion for Timeout/Retry is ok provided MSH-timeout is of greater
> > interval than what it is at the tranport level (tranport-retries*timeout),
> > otherwise it will cause grieve. If retires are to be done by MSH, then
> > sequence numbering "may" be required for checking duplicates (not for the
> > purpose of delivery confirmation), since for the sending transport layer,
> > it's fresh data. In first phase of ebXML specs, I'll be tempted
> > to drop this
> > idea too - the logic being that if it can't be delivered even with
> > transport's retries and timeout, then there is a good chance it won't be
> > delivered with ebXML-MSH-retries as well. Sending application
> > should simply
> > abort and send the message at some other time.
> >
> > I am in favor of ebXML-MSH, but it should only be used to enable certain
> > services (as glue) that CONS transport is supporting or to build something
> > on top of what reliable transports support, if absolutely required. For
> > example Q-ualified data (used for out of band signalling in X.25) can be
> > used for signalling End of File for file transfers. Alternate to
> > Q-data way
> > of sending End of File would be to first send the size of file.
> > The Delivery
> > confirmation (D-bit) logic in X.25 protocols should be looked
> > into. Also, of
> > interest may be some other attributes like fast-select (sender sends
> > connection request along with small data and the receiver sends back data
> > along with call termination - verifone (I think) used to use this
> > for credit
> > card verification)
> >
> > However, if the goal is to provide Relibility over Unrealible
> > connectionless
> > protocols (CLNS - like UDP) then use of sequence numbering is ok.
> > I suggest
> > that X.25 protocol is looked at to see the problems assoicated
> > with sequence
> > numbering, especailly in case MSH is queuing data and not sending
> > it to the
> > application (see how RNR is used). My suggestion is that ebXML should not
> > address reliability over unreliable protocols.
> >
> > Just a suggestion.
> >
> > Thank you and regards,
> >
> > Ajay
> >
> > Ajay K Sanghi
> > Managing Director
> >
> > ABO Software Private Limited
> > B102 Gulmohar Park, New Delhi 110049
> > Tel: +91 11 6512816, 6512822 Fax: 6518873
> > Website: http://www.abosoftware.com
> > email: ajay@abosoftware.com
> >
> > > -----Original Message-----
> > > From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> > > Sent: Sunday, September 24, 2000 4:30 AM
> > > To: ebxml-transport@lists.ebxml.org
> > > Subject: Reliable Messaging Spec v0-078
> > >
> > >
> > > Attached are Word and PDF copies of the latest version of the Reliable
> > > Messaging Spec, for discussion on Wednesday in the F2F.
> > Shimamura-san has
> > > added much more detail on reliability issues, and of course the
> > > earlier use
> > > of Message Groups is now deleted for simplicity. Since there were many
> > > changes, I deliberately did not mark changes in this document,
> > > but you can
> > > easily see them by using Word's compare utility against the
> > > previous version.
> > >
> > > [Ralph, could you have some copies of the document available on Tuesday,
> > > for those that might not have access to a printer before
> > > travelling to Dallas?]
> > >
> > > Jim
> > >
> >
> >
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