[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: T2 Items August 1 to 10 that are missing from the list you publishedlast week
David:
Here is a retransmission in HTML format.
Regards,
-Arvola
Request Date: 8/6/2001
Request Source: e-mail Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00038.html
Change Type: MinorTechnical
Requested By: Cait Crawford
Issue: Reliable Messaging section should be expanded to
include the POINT-TO-POINT option where no Via or Acknowledgment elements are
used
I have a comments/questions regarding POINT-TO-POINT reliable
messaging
implementation for ebXML MS 1.0. First, lets assume that Party A is sending a message reliably
-- that the
deliverySemantics have been set to OnceAndOnlyOnce and deliveryReceiptRequested to Unsigned (I don't think that Signed/Unsigned makes a difference for the example, actually) in the QualityOfService element in the MessageHeader. I am sending this message w/out intermediaries, so I am not making use of the Via or Acknowledgment elements, although I am populating the TraceHeader element as appropriate. Now, Party B receives the message. Now assume that there
is NO REPLY from
the application. Party B is required to send an "Acknowledgement Message" (section 10.3.2) which at a minimum has a MessageData element with a RefToMessageId of the received message. Since a deliveryReceipt is also requested, the MSH must also generate the DeliveryReceipt element in the ack message. My question concerns the service and action elements of this ack. Clearly, as there is no business-level reply, the service and action should not reflect any business or application level service & action. In section 10.3.3, the spec says that if an Acknowledgment element is being sent on its own then service MUST be set to: uri:www.ebxml.org/messageService and action MUST be set to Acknowledgment. What is the equivalent service/action for a DeliveryReceipt element being sent on its own?? (as set in the MessageHeader element for this ack message)?? Is this described in the CPP/BPSS since this is one of the "signals" that need to be processed by the MSH-application interface?? What would happen if the deliveryReceiptRequested was false,
but the
semantics were set to OnceAndOnlyOnce?? The minimal acknowledgement required only a RefToMessageId within the MessageData element -- any guidelines as to what should be used in the Service and Action elements in the MessageHeader? In general, I think that the Reliable Messaging section should
be expanded
to include the POINT-TO-POINT option where no Via or Acknowledgment elements are used, but deliveryReceiptRequested attributes are turned on. (i.e. there is no information about whether the reply is sync or not in the message header). ============================================================================
Request Date: 8/6/2001
Request Source: e-mail Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00045.html
Change Type: MinorTechnical
Requested By: David Fischer
Issue: SyncReply and ReliableMessagingMethod should also be in
QualityOfServiceInfo
There should be nothing in the Via which is not also in other
headers. Via
should only be used for multi-hop intermediaries. In the case of SyncReply, there is no single-hop way of requesting SyncReply=true. Attributes SyncReply and ReliableMessagingMethod should also
be in
QualityOfServiceInfo. They should retain their current defaults. ============================================================================
Request Date: 8/9/2001
Request Source: e-mail Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00095.html
Change Type: MSG/CPPA Alignment
Requested By: Himagiri Mukkamala
Issue: Schema element in Manifest
Reference element has a schema element in it.
Where does this come from? I could'nt find it in the CPA from the packaging
element?
============================================================================
Request Date: 8/9/2001
Request Source: e-mail Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00096.html
Change Type: MinorTechnical
Requested By: David Burdett
Issue: Need to change Service and Action for Errors, Delivery
Receip ts etc.
I agree that the spec is quite specific. However I think that
having just one value for Service and Action for a Delivery Receipt makes it
hard a MSH which receives a Delivery Receipt to work out which application to
notify. For normal messages, Service and Action contain some useful name, e.g
Service=SupplierOrderManagement, Action=NewPurchase order. This can be used to
route the message to the application that supports
OrderManagement.
On a Delivery Receipt, Service contains "uri:www.ebXML.org/messageService" and Action "DeliveryReceipt" as you quote below and the MSH is given no clue on which application to forward the message to. This means that the MSH has to look up the original message sent to work out where the DR was sent to. There is an IDENTICAL problem with Error Messages as the MSH will not know which the application to forward the message to. This time though, it is worse as the message may not have been saved if it was sent with RM as BestEffort. If we don't change the spec then a Sending MSH will have to PERSIST ALL MESSAGES whether sent reliably or not so that they can work out which applicatioon to notify if there is an error. The better alternative I propose is to make Action hold all the information, e.g. Action =uri:www.ebXML.org/messageService/MessageError Then Service could contain "BuyerOrderManagement" so that the MSH could work out which application to notify of the error. However this requires that you know what to put in the Service when an error or other similar message is returned to the sender of a message. To solve this you also need to specify the Sending "From Service" in the original message. ============================================================================ Request Date: 8/9/2001
Request Source: e-mail Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00107.html
Change Type: minorTechnical
Requested By: David Smiley
Issue: Use of Message Status Requests
Being relatively new to the ebXML world, but learning more
every day, I have
been hesitant to jump in where those even more experienced may fear to tread, but here I go... I have extracted a relevant paragraph from the large body of
the "T2
SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo" thread. <Martin W Sachs>
The problem about this use case is that the intermediary is neither a participant in the business process nor strictly a pass through. I suspect that means that it does participate in the business process though "not much". </Martin W Sachs> From a business perspective, please help me understand how any
intermediary
is not a participant in the business process? If they are only a "pass through", why are they used? If they are involved, but "not much", is that like being "a little pregnant" ;-)? It seems to me that any party which handles my business transactions, intelligently, persistently or otherwise, is part of the business process. In the discussion of acks, delivery receipts, reliable
messaging and floods,
no mention is made of the use of Message Status Requests. I realize that this capability is optional in the implementation of a Message Service Handler, but wouldn't it be useful in some of the scenarios mentioned? In lieu of always resending a message whose delivery status is unknown, use of Message Status Requests could reduce the number of large messages that are resent unnecessarily. This may result in a very high tide, but floods may be avoided. ============================================================================
Request Date: 8/10/2001
Request Source: e-mail Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00125.html
Change Type: MajorTechnical
Requested By: David Burdett
Issue: Proposed solution for various issues related to
reliable messaging
I have some ideas for a few changes that might solve the
problems raised in
this thread so the rest of this email contains: 1. Extracts from a number of recent emails from you both and analysis of the issues/requirements they raise 2. Some additional further analysis of the issues to identify a few more requirements 3. A proposed solution to meeting the identified requirements which hopefully will solve the problem ... and who knows perhaps bring this email thread to an end :-) So please let me know if:
a) I've missed a requirement b) You (or anyone else) think the proposed solutiuon is wrong or could be improved ... but then I know you will anyway ;) Details below
David
****************************** EMAIL THREAD and ISSUES/REQUIREMENTS ==================================== Arvola Chan: Thu 8/9/2001 3:28
PM
--------------------------------- >>I am of the opinion that the DeliveryReceipt element should be used by the ToParty MSH to inform the FromParty MSH that a reliable message has been received. ... It is the non-arrival of a DeliveryReceipt that requries the MSH to notify the application. In this case, it must rely on persistent information to determine the application service that must be notified.<< >>I think end to end acknowledgement is always needed to
support reliable
messaging, so it is unnecessary to explicitly set deliveryReceiptRequested to true, it should always be implied by deliverySemantics of OnceAndOnlyOnce. On the other hand, if intermediary acks are optional, then ackRequested needs to be an explicit attribute at the QOS level and it should apply to all intermediaries.<< [DavidB]This highlights a number of
issues/requirements:
Req 1. A positive Ack sent back to the sender of a message by the ultimate destination is the only sure way the sender can be certain the message was delivered. If no Delivery Receipt is sent, then the sender cannot be so certain. Req 2. If end-to-end Delivery Receipts are always required for the sender to be certain, then it would be simpler if there was a rule that deliverySemantics of OnceAndOnlyOnce implies a Delivery Receipt is sent. The only remaining issue is whether or not the Delivery Receipt should be signed. David Fischer: Thu 8/9/2001 7:31
PM
----------------------------------- >>Question 1 ... the end-to-end MUST be able to do RM as if it does not know (which it probably doesn't) what the IM(s) are doing. The end-to-end probably doesn't care if the IM(s) are doing RM at all (even though each IM might care very much)<< >>On the issue of Sender time outs and retries, their
are two kinds: 1) a
timeout to the first IM and 2) a timeout getting to the end. The first is easy and obvious so we don't need to discuss it. The second is a timeframe that is usually contractually guaranteed ...<< >>While the Sender/Receiver may not have any idea what
path or IM transport
the message is taking (and they really don't need to) they must have an idea about delivery times to the end. We MUST generate some kind of an end-to-end Ack allowing the ends to do RM.<< >>Proposal:
1) We need to update section 10 with end-to-end RM (deliveryReceipt or something new that is similar to Acknowledgement). 2) We need to put in the spec somewhere that ALL MessageHeaders (including Via) MUST be passed to the next hop, including the end.<< >>Question 2 ... I agree that it doesn't matter if
ackRequested gets changed
because an Ack gets sent based upon DeliverySemantics (This was my second solution to Question 2). Why then do we have ackRequested? The only way it would change is if there was some kind of local CPA overriding ackRequested. If RM is requested and an IM can do RM then it MUST, right? Then why have this parameter? (I see from your comments that you are considering this.) << [DavidB]This highlights a number of
issues/requirements:
Req 3. The sender should not know nor care if an IM is being used and whether or not they are doing RM with the next IM. Req 4. There are two different types of "acks" that are useful: a) It's been accepted by the postal system (i.e. the next MSH has received, this is the Acknowledgement Message) b) It's been received by the final destination (i.e. the To Party has received it, this is the Delivery Receipt) Req 5. Even if the initial Ack (i.e. Acknowledgment Message) is received there needs to be some method of automated retry if the Delivery Receipt is not received within the expected timeframe. Req 6. If you a doing reliable messaging between two hops, then you do not need ackReqeusted as an acknowledgment must be sent if the ebXML RM protocol is being sent and not needed if it isn't. David Fischer: Thu 8/9/2001 8:02
PM
----------------------------------- >>I am concerned that end-to-end RM is taking a back seat to IM RM. This is the opposite of how it should be. Most transactions will be single-hop. Many other cases will be single IM where the sender or receiver may not even know there is an IM so it still appears to be single-hop. The ends should not even have to know about the IMs. Ends will always do automatic retries. RM should work for the ends in exactly the same manner whether or not there are IMs.<< [DavidB]This really just provides further support for
issues/requirements
numbered 3 and 5 above. Arvola Chan: Fri 8/10/2001 12:23
AM
----------------------------------- >>Even if you have a channel that calls for the use of synchronous reply mode, the syncReply attribute still has to be set. In other words, it is still necessary to use the Via element if the syncReply attribute is present only there, but this constradicts the assumption that the Via element is only used when intermediaries are involved.<< [DavidB]This highlights a number of
issues/requirements:
Req 7. The syncReply needs to be set at the message level whether or not an intermediary is being used Req 8. There is a contradiction in the spec (which therefore needs to be removed) that the Via element is only for intermediaries when it is actually also needed for non-intermediaries. DAVID BURDETT's COMMENTS
======================== Before proposing a resolution to all these requirements I'd like to make a few comments and identify an additional couple of requirements. Firstly on Requirement 6 above (you don't need ackRequested).
There could be
benefit in gettingan acknowledgement element back even if you are using a reliable messaging protocol such as MQ Series as you then have evidence (especially if it is signed) that the next MSH has received the message. I'm not convinced though that this is a huge benefit. Secondly if we put syncReply at the message level then there
is an
additional requirement ... Req 9. The next recipient of a message needs to know whether or not to return an acknowledgement message synchronously or not. Now for the proposed solution.
PROPOSED SOLUTION
================= The solution dsecribed below refers to the requirements identified above ... Change 1
-------- Summary: Rename the Via element as "Next Actor Data" or similar Rationale: There can always be "intermediaries" in a message
transfer even
if you are going point-to-point. For example consider the two example message flows that I recently posted (also posted here) that cover the following use cases: 1. A genuine intermediary who is a third party that is running a MSH and forwards messages to the final destination. 2. A Party which has a MSH that acts as a "mailroom" that forwards the message internally using ebXML RM to another MSH that then forwards it to the application. The "mailroom" MSH ia an intermediary. I think we need to support both use cases. By renaming the Via
element as
"Next Actor Data" we are simply saying that the data contained within the element is for the Next Actor **only** and does not need to be forwarded. The Next Actor recreates the data as they need to. If we think of the data in the Via as being for the "Next Actor" then we are more closely aligned with SOAP. It also removes the problem of treating intermediaries as "something special" and allows an internal MSH to forward the message to another MSH without the original sender needing to know and without having to re-create the complete message. This change addresses Req 3 and 8.
Change 2
-------- Summary: Data in the Next Actor Data (Via) element is for the Next Actor only Rationale: What Change 1 means is that we must carefully
review the existing
elements in the header and check to see whether they are needed by the ultimate destination/endpoint or the next actor. I think that this will require the following changes: 1. CPAId. The CPAId in the Message Header identifies parameters that apply "end-to-end", e.g. business process level stuff, whereas the CPAId in the NAD/Via element applies to the transport over a single hop, e.g. transport level stuff. I realise this will require changes to the CPP/A ... and probably more discussion. 2. Acknowledgment Element. This should be part of the NAD/Via element as acknowledgments are between two MSHs and are not propogated to the original sending party. This change addresses Req 3, 4a
Change 3
-------- Summary: Make the return of a Delivery Receipt required if deliverySemantics=OnceAndOnlyOnce Change 4 -------- Summary: Replace deliveryReceiptRequested by deliverReceiptSigned=true or false(the default) Rationale: As the return of a Delivery Receipt is the only
sure way that you
know a message was delivered suggests that it will be a simpler solution if we make this always the case. Therefore we can make the return of a delivery required if the deliverySemantics are OnceAndOnlyOnce. However you still need to know if the receipt must be signed. These changes address Reqs 1, 2, 4b
Change 5
-------- Summary: Make the return of an Acknowledgment element in a message required if the ebXML RM protocol is being used Change 6 -------- Summary: Replace ackRequested by ackSigned=true or false(the default) Rationale: The rationale for doing this is similar to changes
3 and 4. It
simply gives the rule that if you are doing ebXML RM then you must include an Acknowledgment element in the response. The response can be synchronous or asynchronous (see change 9 below). Change 7
-------- Summary: Include automated retry by the original sender (From Party) if no Delivery Receipt is returned Change 8 -------- Summary: Include "ResendOfMessageId" element in the Message Header Rationale: There is a need for automated retry by the original
sender (from
party) if a Delivery Receipt is not received. However, the original sender cannot send the **identical** message as it will be treated as a duplicate and therefore ignored by any intermediate MSH that has previously received it. To solve this problem the from party needs to use a different MessageId. However there is now a need to stop the message being treated as a completely new message. To solve this problem we could add a "ResendOfMessageId" element that identifies which message the new message is a resend of. In this case even if the resend is received first and the original appears some time later, the ToParty will be able to recognize that the message has already been processed and therefore the original should be ignored. This logic needs to be included in section 10 and probably needs a bit more thinking through. These changes addresses Req 5
Change 9
-------- Summary: Include syncReply at both the Message Header and the NAD/Via elements The To Party needs to know whether the From Party wants the
Delivery Receipt
and Business Payload assembled into one message.The next MSH needs to know whether to send back an Acknowledgment synchronously or wait for the Business Payload before sending it. The Delivery Receipt and Business Payload can be sent asynchronously and the Acknowledgment sent synchronously and vice versa as they are independent of each other. As you can't easily cover both requirements in a single element, they need to be included separately in the header and in the via. This change adresses Reqs 7 and 9.
============================================================================
Request Date: 8/10/2001
Request Source: e-mail Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00127.html
Change Type: Editorial
Requested By: David Fischer
Issue: Inconsistent SERVICE specification
The Service for an Acknowledgement should match between 10.3.2
number 1 and
10.3.3 second bullet set, first bullet. Action is correct. Service=uri:www.ebxml.org/messageService/
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC