[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Expanding Reliable Messaging to meet the needs of IOTP
David,
This falls under the category of "anything is possible, it is just a simple
matter of programming". While I don't refute that this *could* be
done, I don't feel that we *should* adopt this scheme for the following
reasons.
The XML 1.0 spec was developed with the guiding principle that
"any competent software engineer could write an XML parser in a day"
or something to that effect (it may have been 2 days, but you get
my drift). I think that we (TR&P) should be guided by a similar
principle such as:
any compentent software engineer should be able to develop
a compliant and interoperable Messaging Service in less than
a week.
By adding in schemes such as the one you describe, the software complexity
increases to a point where this guiding principle cannot be applied.
Anytime you add in "IF this OR IF that ELSE something completely different"
you increase the complexity of the software.
How does one communicate what mechanism will be applied for communicating
Messaging Service level acknowledgements when sometimes it is done
by the messaging service and other times it is performed by the "application"?
The Messaging Service must make this determination on a per-message basis
(should I send an ACK or not?) which involves an "IF" test which must be
applied. This test will necessarily involve some compute cycles which
to my mind are invariably detrimental to performance. Your proposed scheme
also involves different approaches as to how the acknowledgment is processed
(sometimes it is payload, sometimes it is the RefToMessageId) which increases
the amount of code necessary to perform the function, which raises the
complexity.
The proposed scheme adds complexity to the development of the business
process choreography and the software which implements it because it
too must make some determination as to whether or not the Messaging Service
has already sent the acknowledgment and it must be aware of the proper
protocol for doing so itself if the Messaging Service has not. This increases
the complexity of the business process and "application" software and blurs
the distinction between the Messaging Service and the business process
functionality. As a business process designer, I should NOT have to worry
about the technical details of how reliable messaging is implemented nor
should I have to concern myself with trying to optimize the levels of traffic,
etc. I should be focused squarely on the business process alone and leave
the gory details of the infrastructure to the IT geeks.
So much for the complexity argument.
Now for some more practical arguments. Let us say that my Messaging Service
is running, but (one of) my "application" has been taken off-line for some extended
maintenance or because it crashed and won't be available until tomorrow.
Under your proposed scheme, there would be no acknowledgment sent (because
the source of that acknowledgment is unavailable) and the message would be
repeatedly sent by the initiating party's Messaging Service until such time
as the "application" was brought back online and the message were processed.
The Messaging Service would be incapable of responding to all of the duplicate
messages because it is not responsible for acknowledging the message in the
first place. All it could do would be to ignore/discard the repeated duplicate
deliveries of the same message. Ahhh, but you say "but the Messaging Service
could deliver a message to the other party's Messaging Service saying
hey, I got the message but can't send an acknowledgment because its not
my job..." However, that adds to the complexity because we must therefore
be capable of processing a pseudo-acknowledgment. Then of course, once the
application system is back up-and-running, you get the "real" acknowledgment
and now you wonder why there's nothing to acknowledge...
For reliable messaging (from Message Service to Message Service) the key
is to ensure that the recipient MS got the message and has assumed responsibility
for delivering it (internaly) to the "application" for processing. Your proposed
scheme distributes this responsibility to the "application" which makes it
more complicated to ensure that the responsibility is fulfilled. It would
seem to me a rather common error would be a case where neither MS nor "application"
fulfill the responsibility of acknowledging the message due to a simple
configuration error. This is not something I'd like to see happen under my watch,
yet some lowly SA could mistakenly update some configuration parameter
and all heck breaks loose.
Finally, regading your last sentence:
> I also know that we if we don't spec this now, I will have to write our own
> spec (that I would publish) to the list, that does it as we really, really
> need it.
Who really, really needs this? Why isn't a consistently applied
algorithm (receive message with AtMostOnce delivery semantics, send
an acknowledgement) adequate to enabling Reliable Messaging? Where
is the requirement that we provide this manner of optimization?
Cheers,
Chris
David Burdett wrote:
>
> Chris
>
> In the header we have "RefToMessageId" that identifies a message that is
> caused "this" message to be generated.
>
> On an Acknowledgement message, this will refer to the message that is being
> acknowledged.
>
> Why can't we simply say in the reliable messaging spec words along the lines
> of ...
>
> >>>
> Reliable delivery of a message to a destination is demonstrated by the
> receipt of the sender of either:
> 1. A message with a Message Type of "Acknowldgement" that refers to the
> message that was sent either:
> a) in the "RefToMessageId" field, or
> b) in the payload of the acknowledgement message (method TBD)
> 2. A message with a Message Type of "Normal" that refers in the
> "RefToMessageId" field to the original message that was sent
>
> The method of acknowledging a message is specified in the Trading Party
> Agreement or the Party Profile and is dependent on, for example:
> * the data communications protocol being used
> * the time taken to generate a "Normal" message in response to an earlier
> "Normal" message.
> <<<
>
> Note that the messaging service need not know *anything* about the business
> process that is being supported.
>
> I honestly don't see where the complexity is or how this sort of approach
> would violate the "layering".
>
> I also know that we if we don't spec this now, I will have to write our own
> spec (that I would publish) to the list, that does it as we really, really
> need it.
>
> David
>
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, August 29, 2000 7:03 AM
> To: David Burdett
> Cc: 'Henry Lowe'; 'mwsachs@us.ibm.com'; ebXML Transport (E-mail)
> Subject: Re: Expanding Reliable Messaging to meet the needs of IOTP
>
> All,
>
> I don't understand how this doesn't violate the layering.
> It means that the MS has to track the behavior of the BP
> which is IMHO out of the question.
>
> The MS shouldn't care where a given message originates
> and the BP shouldn't be involved in any MS-level optimizations.
>
> This is an example of early optimization which is IMHO
> a mistake, especially given that bandwidth is so much less
> of a concern than it has been in the past, and the situation
> is most definitely improving rapidly.
>
> This also violates the KISS principle and in my mind over
> complicates any implementation.
>
> Cheers,
>
> Chris
>
> David Burdett wrote:
> >
> > Henry
> >
> > You're suggesting just what I had in mind except that I think the "bit"
> you
> > mention could alternatively be held in a TPA.
> >
> > David
> >
> > -----Original Message-----
> > From: Henry Lowe [mailto:hlowe@omg.org]
> > Sent: Monday, August 28, 2000 9:43 AM
> > To: David Burdett
> > Cc: 'Christopher Ferris'; 'mwsachs@us.ibm.com'; ebXML Transport (E-mail)
> > Subject: RE: Expanding Reliable Messaging to meet the needs of IOTP
> >
> > I must agree with David Brudett on this.
> >
> > First, you must remember, that for the low level
> > "I got the message" ACK, you cannot rely on the
> > underlying transport -- in some cases, e.g., SMTP,
> > there just isn't an ACK with the underlying transport,
> > and in the multi-hop case, the underlying transport
> > ACK isn't end-to-end anyway. What this amounts to is,
> > if an "I got the message" MS level ACK is important,
> > the MS has to send it!!
> >
> > With this in mind, what David is proposing, piggy-
> > backing the low level and BP ACK (where it makes sense
> > and is within reasonable timing constraints) is not
> > only simple but also message efficient and it reduces
> > the number of messages sent by 33% -- GOODness as it's
> > messages, not bytes, which counts for efficiency.
> >
> > A simple (one bit) mechanism can be defined to implement
> > this in the MS protocol (well, if you use XML it will be
> > more than one bit). In the original message sent (request
> > of a request/response pair) set a flag (one bit?) whose
> > semantics is, if set, hold off on ACK until response from
> > the BP is to be sent and piggy-back the two -- in the
> > response header you will have a similar flag which says
> > this is a piggy-backed ACK. Done is 2 messages instead
> > of 3.
> >
> > This doesn't involve any layering violations (which I would
> > guess is what Chris was thinking about) and involves a
> > minimal increase of state preservation (one bit).
> >
> > Best regards,
> > Henry
> >
> > PS: Note I'm shamelessly promoting multi-hop AGAIN.
> > ----------------------------------------------------
> > At 09:41 AM 08/25/2000 -0700, David Burdett wrote:
> > >Chris
> > >
> > >Two main issues ...
> > >
> > >POINT ONE
> > >I fundamentally disagree with you when you say ...
> > >
> > >>>> The business level response is just another message. It cannot be
> > >interpreted as an ack without all kinds of kludgy whacked out code which
> > the
> > >MS must process to figure out which way is up.<<<
> > >
> > >This statement can ONLY be true IF THERE IS ONLY ONE WAY TO TECHNICALLY
> > >SOLVE A PROBLEM which clearly is not true. I also assert that you cannot
> > >PROVE that something can only be solved using "kludgy whacked out code"
> > >since what would stop someone from solving the problem simply and
> > elegantly.
> > >Unless you can prove it is impossible to write elegant code then your
> > >statement is fundamentally wrong.
> > >
> > >Anyway, to stop this getting in to a slanging match ;) What I will do
> (but
> > >folks please give me time - I have a day job) is write up a solution
> which
> > >solves the problem pretty elegantly based on a set of pseudo code that I
> > >wrote to solve exactly this problem for IOTP.
> > >
> > >So Chris, I think the jury's out on this one.
> > >
> > >POINT TWO
> > >Whilst I agree that we want to follow the KISS principle. We must support
> a
> > >reasonable set of use cases, that represent how eCommerce is actually
> being
> > >used today otherwise ebXML will not be adopted. Although synchronous
> > >responses are needed for IOTP, they aren't the only cases. Commerce One's
> > >"RoundTrip" and Ariba's "PunchOut" which both do similar things, both
> need
> > a
> > >synchronous messaging system.
> > >
> > >So, again, to stop this getting in to a slanging match, the solution is
> to
> > >develop an alternative that proves that this is pretty simple to do.
> Again
> > I
> > >will do this, but I need the time.
> > >
> > >David
> > >PS I am about to go into a day-long meeting and might not be able to
> > >continue this conversation until next week.
> > >
> > >-----Original Message-----
> > >From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> > >Sent: Friday, August 25, 2000 7:27 AM
> > >To: David Burdett
> > >Cc: 'mwsachs@us.ibm.com'; ebXML Transport (E-mail)
> > >Subject: Re: Expanding Reliable Messaging to meet the needs of IOTP
> > >
> > >
> > >I fundamentally disagree with this notion. The business level
> > >response is just another message. It cannot be interpreted as
> > >an ack without all kinds of kludgy whacked out code which the
> > >MS must process to figure out which way is up.
> > >
> > >The MS should have a minimal set of functionality:
> > > send/receive a mesage, match to conversation, route to service
> > >handler
> > > send/receive an MS-level ack or error, process accordingly
> > >
> > >which could be optimized with the windowing technique to:
> > > send/receive a window of messages, match to conversation, route to
> > >service handler
> > > send/receive an MS-level ack or error, process accordingly
> > >
> > >Suggesting that a business message could double as an ack
> > >would require all kinds of nasty logic at the
> > >MS level which would impede performance to no end because each
> > >receipt of a message would have to be analyzed to death.
> > >Not only that but the design of the choreography would be overly
> > complicated
> > >IMO.
> > >
> > >The MS should be lean and mean with a minimum of boolean logic.
> > >
> > >Chris
> > >
> > >David Burdett wrote:
> > >>
> > >> >>>However I am concerned about relying on the business-level response
> as
> > >> the confirmation of receipt of the message because business-level
> > timeouts
> > >> can be very long<<<
> > >>
> > >> I agree which is why I'm proposing that the business-level response is
> an
> > >> *alternative* as some business processes can be very short and a
> separate
> > >> acknowledgement unnecessary. We can easily include the way in which
> > >reliable
> > >> messaging receives its acknowledgements through in the TPA.
> > >>
> > >> I'm also not sure that if you are having a pseudo-real-time
> conversation
> > >> that occurs in IOTP, that using a separate acknowledgement actually
> works
> > >on
> > >> HTTP (can anyone advise).
> > >>
> > >> David
> > >> PS Sending to whole list since that is what I reckon Marty intended to
> > do.
> > >>
> > >> -----Original Message-----
> > >> From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> > >> Sent: Monday, August 21, 2000 10:45 AM
> > >> To: David Burdett
> > >> Subject: Re: Expanding Reliable Messaging to meet the needs of IOTP
> > >>
> > >> Dave,
> > >>
> > >> Your suggestion has merit. However I am concerned about relying on the
> > >> business-level response as the confirmation of receipt of the message
> > >> because business-level timeouts can be very long (consider a request
> > which
> > >> initiates a human workflow or requires the requestee to communicate
> with
> > a
> > >> subcontractor first). Waiting that long to discover than the request
> was
> > >> dropped by the network seems undesirable. However many of the
> transports
> > >> that will be used below the messaging service already have acks
> > prescribed
> > >> in their protocols. If the implementation persists the message before
> > >> sending the transport-level ACK, we should be covered without an extra
> > >> layer of function.
> > >>
> > >> One case where the existing proposal seems to make sense is with SMTP
> > >since
> > >> SMTP has no end to end acknowledgment on a multihop path.
> > >>
> > >> 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
> > >>
> >
> >***************************************************************************
> > *
> > >> *********
> > >>
> > >> David Burdett <david.burdett@commerceone.com> on 08/21/2000 11:30:37 AM
> > >>
> > >> To: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> > >> cc:
> > >> Subject: Expanding Reliable Messaging to meet the needs of IOTP
> > >>
> > >> Folks
> > >>
> > >> I suggest that reliable messaging should be expanded, so that, instead
> of
> > >> sending an ack, to imply that the message has been received, an
> > >alternative
> > >> would be to use the next "normal" message received instead.
> > >>
> > >> The reason I suggest this is because this is how the Internet Open
> > Trading
> > >> Protocol (RFC 2801) does it and I'm not sure that the current Reliable
> > >> Messaging spec will support this method of working. In outline what
> > >happens
> > >> is illustrated by the following:
> > >>
> > >> 1. Customer sends a "Payment Request" message to a Payment Handler
> (e.g.
> > a
> > >> bank) - using a HTTP Post
> > >> 2. The Payment Handler processes the Payment Request and sends a
> "Payment
> > >> Response" message on the HTTP Response
> > >> 3. If the Payment Response is not received in time, a timeout occurs
> and
> > >> the
> > >> Customer resends the Payment Request
> > >> 4. If the Payment Handler receives a duplicate Payment Request, then
> they
> > >> resend the Payment Response that they sent previously, but otherwise
> > >> ignores
> > >> it
> > >>
> > >> No separate acknowledgement message is needed since the receipt of the
> > >> Payment Response by the Customer implies that the Payment Request has
> > been
> > >> received.
> > >>
> > >> Thoughts?
> > >>
> > >> David
> > >>
> > >> Product Management, CommerceOne
> > >> 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> > >> Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> > >> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.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
--
_/_/_/_/ _/ _/ _/ _/ 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