OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Implementation question for RM spec!


A mixture of points:

- I agree with Marty that we must be very careful about the terms "MSH" and 
"transport". Even though our direction is to be "transport agnostic", in 
fact there must some mapping between the MSH and transport defined for 
interoperability. Our position was for the most minimal mapping; when we 
get into implicit ACKs and similar topics, we're really adding functions to 
the transport layer... which may be acceptable to the team, but we should 
recognize this as more than minimal mappings.

- if we do propose logic for the transport layer, we should decide how to 
spec it...

- one of the main reasons for asking for blocking in phase 1 is because we 
stripped out all the specs for windows, etc. With blocking, it is 
relatively easy for the receiving MSH to detect duplicate or missing 
reliable messages. Without it, the receiving MSH must remember all reliable 
messages somehow  in order to check duplicates... which may be acceptable 
for some kind of implementation-defined limits (table size, etc.) in phase 
1 but clearly is not an acceptable solution in the long run. We need to 
solve this in phase 2.

- on the other hand, we've published the draft RM spec, so I hope we get 
some opinion/consensus among the POC implementors this week on the 
viability of implementations, given what has been written...

Jim

At 09:11 AM 10/10/2000 -0400, Martin W Sachs/Watson/IBM wrote:

>Rik,
>
>You do mean "focused on the messaging service, right?" ...and I agree with
>your comment if so.
>
>The point is, we keep tripping over ourselves when we use the word
>"transport" because many, if not most, of us believe that the transport
>layer is the layer below the messaging service and is the stuff that some
>people are trying to be "agnostic" about.
>
>I propose that we all try to limit "transport" to what is below the
>messaging service.
>
>Regards,
>Marty
>
>*************************************************************************************
>
>Martin W. Sachs
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>*************************************************************************************
>
>
>
>Rik Drummond <rvd2@worldnet.att.net> on 10/10/2000 08:01:32 AM
>
>To:
>cc:   ebxml-transport@lists.ebxml.org
>Subject:  RE: Implementation question for RM spec!
>
>
>
>we need to keep focused on the transport layer, and not the application
>interaction at the moment, otherwise we will never get this thing done....
>best regards, rik
>
>-----Original Message-----
>From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
>Sent: Thursday, October 05, 2000 9:40 AM
>To: Martin W Sachs/Watson/IBM
>Cc: Burdett, David; ebxml-transport@lists.ebxml.org
>Subject: Re: Implementation question for RM spec!
>
>
>I agree with Marty (does that mean I also agree with David?!?! ;-)
>
>Cheers,
>
>Chris
>
>Martin W Sachs/Watson/IBM wrote:
> >
> > I agree with David.  We need to develop the list of grey-area topics.
> >
> > The first thing to do with the list is to decide which topics are
> > messaging-service topics and which are for the application-services
>layer.
> >
> > I view the application-services layer as part of the run-time middleware.
> > It is really implementation but if there isn't some kind of run-time
> > interoperability specification, there will be serious interoperability
> > problems. I view the RosettaNet Implementation Framework document as an
> > example of an interoperability specification.
> >
> > Regarding David's example of checking that the sequence of messages
> > received agrees with the choreography, I view this as outside the scope
>of
> > the messaging service.  The sequence of messages is defined by the
>business
> > process definition and manifested in the TPA as the sequencing rules in
> > tpaML or whatever equivalent the TP and BP teams come up with.  Checking
> > the sequence of messages is a job for the run-time middleware
>(application
> > support services) since it can be done generically for all business
> > processes based on what is specified in the TPA.
> >
> > Regards,
> > Marty
> >
> >
>****************************************************************************
>
>*********
> >
> > Martin W. Sachs
> > IBM T. J. Watson Research Center
> > P. O. B. 704
> > Yorktown Hts, NY 10598
> > 914-784-7287;  IBM tie line 863-7287
> > Notes address:  Martin W Sachs/Watson/IBM
> > Internet address:  mwsachs @ us.ibm.com
> >
>****************************************************************************
>
>*********
> >
> > "Burdett, David" <david.burdett@commerceone.com> on 10/04/2000 08:56:32
>PM
> >
> > To:   Christopher Ferris <chris.ferris@east.sun.com>,
> >       ebxml-transport@lists.ebxml.org
> > cc:
> > Subject:  RE: Implementation question for RM spec!
> >
> > I agree with Chris (again!) that we should not enforce sequencing of
> > messages but keep it separate. However sometimes (often?) the sequencing
>in
> > which a services processes messages is the same as the sequnce in which
> > they
> > were sent. So it does indeed fall into the "fuzzy grey area" as Chris
> > describes it.
> >
> > Perhaps where Chris and I differ is that I think we (i.e. ebXML and
> > probably
> > TRP) need to address fuzzy grey area topics such as this as otherwise
>many
> > business processes will have to invent similar (but different and
> > non-interoperable) solutions to the problem.
> >
> > Other topics that fall into this area include:
> > * checking the sequence in which documents are sent/received agrees with
> > the
> > document choreography
> > * validating and authenticating the sender of a message
> >
> > So how about us developing a "grey list" then we can work out which items
> > on
> > the list we want (or don't want) to address in what priority.
> >
> > David
> >
> > -----Original Message-----
> > From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Wednesday, October 04, 2000 5:36 AM
> > To: ebxml-transport@lists.ebxml.org
> > Subject: Re: Implementation question for RM spec!
> >
> > Marty/All,
> >
> > I don't necessarily think that the issue is sequence of
> > delivery to the BPH (business process handler). Rather, it
> > is (IMHO) one of having the specification REQUIRE the sequencing
> > by a blocking protocol on the SENDING MSH. I just don't believe
> > that the specification should go there. I can think of any
> > number of creative ways in which sequence could be preserved
> > from the perspective of the receiving BPH without necessating a blocking
> > protocol on the part of the sending MSH.
> >
> > I think that this is clearly an implementation detail which
> > is out of scope for the MS specification. It might be something
> > which TP should consider (e.g. an attribute of the BP stipulating
> > that ordering/sequencing be preserved/enforced by XXX).
> > I do believe that this falls in the area of the "fuzzy grey area"
> > of application support though.
> >
> > Cheers,
> >
> > Chris
> >
> > Martin W Sachs/Watson/IBM wrote:
> > >
> > > If a logical channel is not blocked until the ACK is received, retries
> > will
> > > get messages out of order.  If every message has a business-level
> > response
> > > and ordering of messages is enforced by sequencing rules, then
>everything
> > > will stay in order. Of course, that only means that blocking is taking
> > > place at the business process level and it doesn't matter whether
> > blocking
> > > takes place at the MS level.
> > > Blocking is needed at the MS level to keep messages in order when the
> > > business process level doesn't force ordering.
> > >
> > > The questions are:
> > >    Do we want to restrict ourselves to scenarios where ordering is
> > >    preserved at the business process level?
> > >    If the business process level does not preserve ordering, do we care
> > >    whether the MS level gets things out of order?
> > >
> > > The conservative answer is not to let the MS level get messages out of
> > > order on a given logical channel.  That may or may not be the best
> > design.
> > >
> > > Note also that MS blocking is only within a single logical channel.
> > > Blocking in one channel does not cause other channels to stall
>(assuming
> > a
> > > good implementation).
> > >
> > > Regards,
> > > Marty
> > >
> > >
> >
>****************************************************************************
>
> >
> > *********
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287;  IBM tie line 863-7287
> > > Notes address:  Martin W Sachs/Watson/IBM
> > > Internet address:  mwsachs @ us.ibm.com
> > >
> >
>****************************************************************************
>
> >
> > *********
> > >
> > > christopher ferris <chris.ferris@east.sun.com> on 09/29/2000 11:24:06
>PM
> > >
> > > To:   ebxml-transport@lists.ebxml.org
> > > cc:
> > > Subject:  Re: Implementation question for RM spec!
> > >
> > > Jim/All,
> > >
> > > It isn't clear to me why it would be necessary to
> > > block until the previously sent message is ack'ed.
> > > That would be one manner of implementing, but not an
> > > approach I'd choose.
> > >
> > > Since each message is ack'ed individually, you can
> > > send as many messages as you like and process the
> > > acks or retry (in the case of a timeout) oob.
> > >
> > > The specification stipulates that one MAY use either
> > > the sequence number OR the messageId (refToMessageId)
> > > for the purposes of determining which message is being
> > > ack'ed.
> > >
> > > This is my understanding of what we have worked out for
> > > phase one. Possibly, it is misguided, but I for one would
> > > not advocate a (logically) blocking protocol.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > Jim Hughes wrote:
> > > >
> > > > Sanjay,
> > > >
> > > > Reliable Message grouping (sending one ACK for a group of messages)
>was
> > > > eliminated in phase 1 for a variety of reasons - error propagation
>not
> > > well
> > > > understood, how to handle partially sent groups, how to recover, etc.
> > The
> > > > result is a very simple solution that does enforce a single pipeline
>as
> > > you
> > > > point out, with each reliable message being acknowledged before the
> > next
> > > > one is sent (unreliable messages flow at any time). We will remove
>the
> > > > restriction after Phase 1, when there will be more normative
> > > specifications
> > > > for implementors. Simplicity rules for the moment...
> > > >
> > > > Jim Hughes
> > > > Fujitsu
> > > >
> > > > At 06:56 PM 9/29/2000 -0700, Patil, Sanjay wrote:
> > > >
> > > > >Jim,
> > > > >
> > > > >Could you please also comment on the third question in my original
> > mail.
> > > > >It's about parallelism between any given sender-receiver pair.
> > > > >Is this restriction of working on one message at a time between
> > > > >any given sender-receiver pair a result of some TRP
> > > > >decision to get rid of the windowing. I vaguely remember
> > > > >your initial RM spec talking about windowing.
> > > > >
> > > > >Please advise.
> > > > >
> > > > >thanks,
> > > > >Sanjay Patil
> > > > >
> > >
> >
>--------------------------------------------------------------------------
>--
> >
> > >
> > > > >------------------------------
> > > > >Work Phone: 408 350 9619
> > > > >http://www.netfish.com
> > > > >
> > > > >
> > > > >-----Original Message-----
> > > > >From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> > > > >Sent: Friday, September 29, 2000 6:37 PM
> > > > >To: ebxml-transport@lists.ebxml.org
> > > > >Subject: Re: Implementation question for RM spec!
> > > > >
> > > > >
> > > > >Marty's exactly right on the complexity issues.
> > > > >
> > > > >The current TRP resolution for RM requires each sending MSH to
> > generate
> > > > >sequence numbers for each sender-receiver pair (regardless of
> > > transport).
> > > > >Whether a receiving MSH actually uses the sequence number or the
> > > globally
> > > > >unique MessageID to detect duplications is implementation dependent.
> > > It's a
> > > > >lot easier to detect dups using sequence numbers...
> > > > >
> > > > >Jim
> > > > >
> > > > >At 06:10 PM 9/27/2000 -0400, Martin W Sachs/Watson/IBM wrote:
> > > > >
> > > > > >I believe that you correctly understand the intent of the RM
> > protocol
> > > and
> > > > > >its implementation requirements.  There indeed has to be a
>separate
> > > > > >"logical channel" for each pair of channels, if not for each
> > > conversation,
> > > > > >using reliable messaging, precisely to avoid the  blocking you
> > > mention.
> > > > > >That's what it takes to get the parallelism you mention.
> > > > > >
> > > > > >I believe that the implementation would be simplified and perform
> > > better if
> > > > > >the sequence numbers were eliminated as someone (yourself?) has
> > > already
> > > > > >suggested.  I assume that sequence numbers have been discussed at
> > this
> > > > > >week's TRP face to face.
> > > > > >
> > > > > >Except for the sequence number question, I believe that exactly
>the
> > > same
> > > > > >implementation considerations would be present if reliable
>messaging
> > > were
> > > > > >done in the transport layer instead of the message service.
> > > > > >
> > > > > >Regards,
> > > > > >Marty
> > > > > >
> > >
> >
>***************************************************************************
> > > > >**********
> > > > > >
> > > > > >Martin W. Sachs
> > > > > >IBM T. J. Watson Research Center
> > > > > >P. O. B. 704
> > > > > >Yorktown Hts, NY 10598
> > > > > >914-784-7287;  IBM tie line 863-7287
> > > > > >Notes address:  Martin W Sachs/Watson/IBM
> > > > > >Internet address:  mwsachs @ us.ibm.com
> > > > > >
> > >
> >
>***************************************************************************
> > > > >**********
> > > > > >
> > > > > >
> > > > > >
> > > > > >"Patil, Sanjay" <Spatil@netfish.com> on 09/27/2000 02:45:15 PM
> > > > > >
> > > > > >To:   "Ebxml-Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> > > > > >cc:   "Ebxml-Poc (E-mail)" <ebxml-poc@lists.ebxml.org>, "Askary,
> > Sid"
> > > > > >       <saskary@netfish.com>
> > > > > >Subject:  Implementation question for RM spec!
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >I was going through the Reliable Messaging spec for scoping the
>work
> > > > > >involved in implementing the spec for the upcoming Tokyo POC.
> > > > > >Questions about the same ...particularly in the context of the
> > > following
> > > > > >requirement posed by the RM spec ...
> > > > > >      A sender MSH should not send the next message till it
>receives
> > > > > >      an Acknowledgement Message from the Receiver.
> > > > > >
> > > > > >   1>This will necessitate instantiating a separate MSH instance
>for
> > > each
> > > > > >recipient
> > > > > >      party, as it will not be fair for blocking outgoing messages
> > to
> > > > > >Parties
> > > > > >having
> > > > > >      a clear messaging channel while Messages to Parties with
>poor
> > > links
> > > > > >are
> > > > > >
> > > > > >      successfully sent (tried to send).
> > > > > >
> > > > > >   2>This will also mean that separate outbound message queues are
> > to
> > > be
> > > > > >      maintained for each recipient. For each recipient Party, I
> > will
> > > have
> > > > > >to
> > > > > >manage
> > > > > >      the lifecycle of a dedicated SequenceCounter i.e.recycling
>the
> > > > > >SequenceCounter
> > > > > >      upon tripping over the max as well as when they get stale
> > after
> > > "long
> > > > > >time".
> > > > > >      In hub scenarios, this will amount to a lot of runtime
>objects
> > > > > >creation
> > > > > >and
> > > > > >      will also require an ongoing activity in the server to
>manage
> > > the
> > > > > >queues and
> > > > > >      lifecycles of the SequenceCounter objects.
> > > > > >
> > > > > >   3>With lots of outbound messages for the same recipient Party,
> > > there
> > > > > >      should be some provision for parallelism. Typically when
> > servers
> > > can
> > > > > >handle multiples
> > > > > >      of parallel message exchanges, the RM spec will necessitate
> > > using a
> > > > > >single
> > > > > >      pipeline resulting into underutilization of capacity and
> > slowing
> > > down
> > > > > >of the entire
> > > > > >      process. Critical messages requiring immediate transfer
>might
> > > get
> > > > > >stuck
> > > > > >in the
> > > > > >      queue for unreasonable amount of time.
> > > > > >
> > > > > >Or am I missing something very fundamental. It's been a while I
>have
> > > done
> > > > > >ebXML,
> > > > > >and with the Tokyo POC not very far, I got to catch up :-).
> > > > > >
> > > > > >thanks,
> > > > > >Sanjay Patil
> > > > > >
> > >
> >
>--------------------------------------------------------------------------
>-
> > > > >-
> > > > > >
> > > > > >------------------------------
> > > > > >Work Phone: 408 350 9619
> > > > > >http://www.netfish.com
> >
> > --
> >     _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
> >    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
> >   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
> >        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> > _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
>
>--
>     _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
>    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
>   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
>_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC