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 (point-to-point)

I think that this is a bug in the spec.

To solve this problem I think we should include in every message that is
sent, an identifier for Service that is sending it. You can then use this
Service when returning a message if there is no business process specific
one to use instead. You would then use the Action element to identify why
the message is being sent.

If we make this approach the rule for returning errors, for example, then it
fixes the problem that a MSH does not know which application it should
notify if the original message was not persisted (which it shouldn't be if
it was not sent reliably).

I also think we should follow the same approach for the Message Status and
Ping transactions for the same reasons.



-----Original Message-----
From: Dr Crawford [mailto:catcraw@us.ibm.com]
Sent: Monday, August 06, 2001 8:11 AM
To: ebxml-msg@lists.oasis-open.org
Subject: T2: Reliable Messaging (point-to-point)

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).

Your guidance is greatly appreciated.


Cait Crawford
B2B Integration
IBM Research
Hawthorne, NY

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org

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

Powered by eList eXpress LLC