RE: [wsrm] REL-xyz:proposal to add a new attribute (messageType) to Response element

[Jacques Durand <JDurand@us.fujitsu.com>]

Sunil:

 

Overall I am sympathetic with a more explicit mention - and faster resolution - of the "Ack",

however two aspects need be secured:

 

1. Are we positive that we will never bundle an Ack and  a Fault together,

or that we don't want a Fault to also serve as an Ack? For example,

could it be that a Fault "NotSupportedFeature" still allows message delivery?

E.g. if guaranteed deliv + dup elim were requested, and only the first is supported:

it would still make sense to deliver the message, Ack it, and send back an error.

Of course in that case, we could still use type="Ack", and the additional Fault would also refer to the same

message.

(what is the policy in case of unsupported features is another issue...)

 

2. "messageType" is a confusing name: this is only the type of an RM- response element

not of all the message sent ( Acks can be piggy-backed on regular business messages, which we call

"reliable messages" too. Even though a message can be both an "acknowledgment message" and

a "reliable message" in our terminology, I would avoid pinning one or the other.)

Why not use just "type", or "signal" for the attribute name?

 

Jacques

-----Original Message-----
From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
Sent: Monday, February 09, 2004 11:11 AM
To: wsrm@lists.oasis-open.org
Subject: Re: [wsrm] REL-xyz:proposal to add a new attribute (messageType) to Response element

 
Oracle feels that this attribute is a necessity and not just an optimization. Here are the reasons:

• For the same reason folks opposed having the SequenceNum as a child element of MessageOrder before the group unordered came up. The justification at that time was MessageId processing logic should not span across multiple Headers. Same should apply here.
• Without this attribute:
  • Ack and Poll response processing spans across Headers (in SOAP 1.1 case) and a Header and a Body (in the 1.2 case)
  • Not only Faults but our Ack Response processing logic becomes SOAP protocol dependent.
  • Ack. and Poll response processing becomes much more complex as we end up checking for Fault Header or fault subcode in SOAP 1.2 case. So essentially 1% case (Faults) case is given more prominence than the 99% case (Acks and Polls)
• More error prone:
  • If some reason Fault Header (or sub faultcode) doesn't appear in real Fault case, response will be treated as an Ack.
  • When Fault Header (or sub faultcode) accidentally linger around, then a real Ack. is treated as a Fault.
  • The above two cases are very likely when a Faults are generally processed by different (mostly centralized) nodes or Handlers.
  • When implementations are based on Handlers which generally are triggered based on Header QNames.
• We already have many similar attributes and hence I don't understand the complexity with this one:
  • Status attribute on SequenceNum is very similar. We could have gotten around it, but had it for simplicity.
  • For a response to a single message, we still need both 'from' and 'to' attribute on the SequenceNumRange element., We could have just had the 'to' attribute for a single message ack, but for simplicity and for validation, we had both the attributes. Same thing holds for this MessageType attribute.

 We are okay perfectly fine changing the name to ResponseType.

 It will be useful for me if people opposing this can justify their reasoning.

 -Sunil

Sunil Kunisetty wrote:

 I like to suggest that we add an attribute by name messageType to the
 response Header element to easily distinguish a RM-Fault message with
 an RM-Ack. Message. Currently we need to check for the existence of
 the Fault Header (for SOAP 1.1_ to distinguish an Ack. To a Fault.
 This is some what tedious and instead having a simple attribute with the type
 of the message will make it simpler and less error prone.

 This attribute can have any one of the following 2 values: Acknowledgment or Fault.

 We have 2 ways to go wrt optionality:

 1) Make it mandatory and require that every message has the type mentioned.
 2) Make it optional and default to Acknowledgment.

 I prefer Option (2)

 Issue Editors,

 Could you please add this a new issue?

 Thx!
 -Sunil

 PS: This may be a resend as I had problems when sending the previous one.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.