RE: Reliable Messaging Spec v0-078

[Ajay K Sanghi <sanghi@giasdl01.vsnl.net.in>]

Gordon,


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

Do they provide resynchronisation and recovery of lost sessions?

>
> - Why do this specifically for ebXML?

I am in 100% agreement with you. A layer like BX.25 (providing resync and
recovery) should be independent of the application.

Regards,

Ajay

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