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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Re: T2 Reliable Messaging w/o CPA or VIA...

First off, can those of you using HTML editors to compose
email please refrain from doing so. Not everyone has a MUA
that can handle this effectively. Besides, it is really annoying;-)

More comments below.



[1] http://lists.ebxml.org/archives/ebxml-transport/200104/msg00016.html
[2] http://lists.oasis-open.org/archives/ebxml-msg/200107/msg00146.html

David Fischer wrote:
> Comments in-line...Regards,David FischerDrummond Group.
>      -----Original Message-----
>      From: Burdett, David [mailto:david.burdett@commerceone.com]
>      Sent: Monday, July 30, 2001 2:30 PM
>      To: 'David Fischer'
>      Cc: ebXML Msg
>      Subject: RE: T2 Reliable Messaging w/o CPA or VIA...
>      DavidLet's take of these in turn ...
>      mshTimeAccuracy
>      >>>This is the accuracy to which a recipient of a message claims to keep their internal
>      system clocks. This should probably be part of a CPP and not vary from message to message
>      therefore it does not need to be in the MessageHeader
>      [David Fischer] Agreed, but what if there is no CPP?  I'm not sure why this is necessary.

It isn't represented in the CPP, nor should it be. I have repeatedly expressed my 
belief that this is unnecessary at best, and more likely unimplementable in any event [1].

If anything, I could see parties agreeing to a requirement that their respective 
system's system clock be synchronized using something like NTP or some similar
service and having this reflected in some manner within the CPP/A, but not mshTimeAccuracy!

I for one would like to see this removed from the 1.1 specification.

>      reliableMessagingMethod
>      >>>This needs to be in the Via since it can vary on each hop of a multi-hop message. I
>      suppose though that, if you are not doing multi-hop then it forces use of the Via element.
>      I think we could either:
>      1. Put reliableMessagingMethod in the main MessageHeader with the copy in the Via element
>      over-riding it, or
>      2. Change the definition of the Via element to suggest that it to be used when there is no
>      intermediary
>      Thoughts?
>      [David Fischer] Option 1.  Let's not muddle the Via.  What if the MessageHeader
>      reliability is higher (I assume "ebXML" is higher than "Transport").  Should an
>      intermediate hop have a lower reliability than the end-to-end?  Or do we care since it is
>      a "black box"?  Methods "ebXML" and "Transport" do not seem to be defined.

I agree with David F (let's not muddle Via). 

>      ackRequested
>      >>>This is in Via for the same reason as for reliableMessagingMethod - it can vary from
>      hop-to-hop
>      [David Fischer] How do we accomplish single-hop Reliable Messaging?  We need to be able to
>      request an Acknowledgement without the Via.  We could say that a DeliveryReceipt is
>      equivalent.  This means the receiver will have to process DeliveryReceipt as an
>      Acknowledgement (set the Acknowledgement flag in the message database when a
>      DeliveryReceipt is received and do all the other Reliable Messaging tasks
>      equivalently--sequencing, persistent store etc.) which would be OK.  Acknowledgement would
>      then NEVER be used except in conjunction with VIA.  This would uncomplicate Reliable
>      Messaging but chapter 10 would have to be significantly re-written (replace/combine
>      Acknowledgement with DeliveryReceipt in lots of places).  What about 10.3.3 which
>      specifies that an Acknowledgement MUST be sent.  How is the receiving MSH to know if this
>      is single-hop or multi-hop (whether to send Acknowledgement or DeliveryReceipt) by the
>      presence of a VIA element?  I don't think the Via actually get passed to the end-point
>      since SOAP-Actor=next gets consumed in-route.  How does the last hop/end know to send an
>      Acknowledgement w/o the VIA?

The MessageHeader/QualityOfService/@deliverySemantics determines whether an acknowledgment
is sent to the party originating the message.

What I hear you (David F) saying is "how do we accomplish single-hop reliable messaging
*without a CPA*? To which I would respond, you are (still) interpreting 'doesn't require
a CPA' as 'doesn't require that some representation of the information that is identified
in the specification is shared by the parties exchanging messages' which is not the
case at all. The specification *clearly* states in section 10.3.3 on line 1811 that
an Acknowledgment message MUST be generated when the deliverySemantics="OnceAndOnlyOnce"
and reliableMessagingMethod="ebXML" (default).

If you insist on not having a CPA, then either you find some other mechanism for
configuring your runtime software to understand how the two parties are going
to effect reliable messaging or you go with the default behavior that is described
in the specification, you generate an Acknowledgment message as prescribed above.

>      retries & retryInterval
>      >>>These are both parameters that apply to the sender of a message and over which the
>      receiver of message can have no effective control. There is therefore no need for them to
>      be in the header. They should however be in the CPP for the sender
>      [David Fischer] What if there is no CPP?  Is there never a need for the receiver to know
>      how often and how many times the message will be resent?  Maybe not.  In my experience,
>      the receiver usually ends up calling the sender on the phone for this info.  This is not
>      needed very often

The receiver probably doesn't ever need to know what values the sender will
use as you point out. Of course, the whole purpose of a CPP/A is to eliminate the
need for the receiver to pick up the phone in the first place!

>      -- only to troubleshoot
>        problems.  I have seen many cases of "why did you send
>        that message to me three times?" when the answer was related to
>        retries.   Agreed.
>      persistDuration
>      >>>PersistDuration only applies to the recipient of a message
>        as it specifies the minimum time the recipient will keep a message. The sender
>        cannot (should not?) control this, therefore there is no need for it to go in
>        the header.
>      [David Fischer] Agreed.  How is the sender to
>        know?  Should this be in the DeliveryReceipt?  While this should be

See my previous email regarding persistDuration [2]. I agree with David B that
it need not be represented in the envelope.

>        agreed to in the CPA, we cannot assume the existence of a CPA.  I am
>        still on the fence about whether there will be more implementations with or
>        without a CPP/CPA.  Could go either way depending upon the number of SME
>        implementations vs. LE.

What makes you think that SME implementations wouldn't benefit from a CPA? If
you believe that a CPA configured MSH is a more complex/complicated thing
than an MSH without one, then I would have to disagree. In fact, I think
that it makes things much simpler than they might otherwise be.

What is it that makes you so adamant in your opposition to what I and others consider
to be one of the most compelling aspects of ebXML?

>      I'd appreciate your thoughts.
>      David
>           -----Original Message-----
>           From: David Fischer [mailto:david@drummondgroup.com]
>           Sent: Monday, July 23, 2001 7:07 PM
>           To: Burdett, David
>           Cc: ebXML Msg
>           Subject: T2 Reliable Messaging w/o CPA or VIA...
>           Section 10.2 (line 1695) says:
>           This parameter information can be specified in the CPA or in the MessageHeader
>           But I can't find anywhere in the MessageHeader to set the following parameters:
>           mshTimeAccuracy
>           reliableMessagingMethod
>           ackRequested
>           retries
>           retryInterval
>           persistDuration
>           This seems like a formidable problem when doing reliable messaging
>           (ackRequested) without an intermediary (no Via).  If we put this information
>           back in the MessageHeader, why is it also in the Via?  This was in the
>           MessageHeader in v0.91 but it was taken out... probably shouldn't have been.
>           Regards,
>           David Fischer
>           Drummond Group.

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

Powered by eList eXpress LLC