>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.
>
>Thoughts?
>
>David
>
>-----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.
>
>Regards,
>Cait
>
>Cait
Crawford
>B2B Integration
>IBM Research
>Hawthorne,
NY
>
catcraw@us.ibm.COM>
>
>------------------------------------------------------------------
>To
unsubscribe from this elist send a message with the single
word
>"unsubscribe" in the body to:
ebxml-msg-request@lists.oasis-open.org>
>------------------------------------------------------------------
>To
unsubscribe from this elist send a message with the single
word
>"unsubscribe" in the body to:
ebxml-msg-request@lists.oasis-open.org