>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