[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Implementation question for RM spec!
>>>I agree with Marty (does that mean I also agree with David?!?! ;-)<<<
If it does it's got to stop ... ;)
David
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, October 05, 2000 7: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]
Powered by eList eXpress LLC