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: Need to change Service and Action for Errors,Delivery Receip ts etc.

Why have a fixed depth (2) to these invocation semantics at all? It still
seems to me that the
upper level environment that is mapping down to the Message Service
should have the flexibility to profile the invocation. Some envirnments may
need 2, some may
need 3. The Mail Room actually underlines this. In different places, a
varying number
of qualifications (country, street, apartment, ?) are need to actually
determine the correct upper
level handoff.

This is a version2 concept for discussion, but I believe it better
seperates the concerns of
the Message Service.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074

"Burdett, David" <david.burdett@commerceone.com> on 08/09/2001 10:29:33 AM

To:   "'Arvola Chan'" <arvola@tibco.com>, Catherine H
      Crawford/Poughkeepsie/IBM@IBMUS, ebxml-msg@lists.oasis-open.org
Subject:  T2: 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

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.


-----Original Message-----
From: Arvola Chan  [mailto:arvola@tibco.com]
Sent: Wednesday, August 08, 2001 6:59  PM
To: Burdett, David; 'Dr Crawford';  ebxml-msg@lists.oasis-open.org
Subject: Re: T2: Reliable Messaging  (point-to-point)

Sorry for the delayed response. I was tied up the last  couple of days
attending to some personal matters.

To answer Cait's original question about the Service and Action elements
that should be used when a message containing a DeliveryReceipt element is
to  be sent not in conjunction with any business level reply, the following
excerpt from the 1.0 spec clearly states:

If there are no errors in the message received and a DeliveryReceipt is
being sent on its own, not as part 848

of message containing payload data, then the Service and Action  MUST be
set as follows:  849

 the  Service element MUST be set to uri:www.ebXML.org/messageService/

 the  Action element MUST be set to DeliveryReceipt 851

Unfortunately, the above information is located in section
deliveyReceiptRequested attribute, rather than in section 8.14
DeliveryReceipt  element.

I believe the spec is currently quite specific about the Service and
Action elements to use when Acknowledgement, DeliveryReceipt, Error,
StatusRequest, StatusResponse, and Ping elements are sent on their own (not
in  conjunction with business payloads).


-----Original Message-----
From: Burdett,  David <david.burdett@commerceone.com>
To:  'Dr Crawford' <catcraw@us.ibm.com>; ebxml-msg@lists.oasis-open.org  <
Date:  Monday, August 06, 2001 6:39 PM
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
>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
>it was  not sent reliably).
>I also think we should follow the same  approach for the Message Status
>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
>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
>Now, Party B receives the  message. Now assume that there is NO REPLY
>the  application. Party B is required to send an "Acknowledgement
>(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
>ack. Clearly, as there is  no business-level reply, the service and
>should not reflect any  business or application level service & action.
>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
>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
>the  MessageHeader?
>In general, I think that the Reliable Messaging  section should be
>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
>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
>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