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

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:]
Sent: Monday, February 09, 2004 
  11:11 AM
To: 
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.