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

Jacques,

Jacques Durand wrote:
 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,

As far as I recollect,
we don't support piggybacking on Faults and also I can't think of current
scenarios

that requires
bundling.

 

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

Fault is indeed
a  different type of Ack, that's why we send the Response element.
However, it is still labeled as "fault'

 

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

That will be
a new requirement. Too complex and too confusing to support. So how will
we know what part of the transaction

was succeed
and what failed?

 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 samemessage.

yup. I don't
mind Faults have dependency on Acks (1% case), but not the other way round
(i.e. Acks on Faults which

is the 99% case).

 

 (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 elementnot
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"
anda
"reliable message" in our terminology, I would avoid pinning one or the
other.)Why
not use just "type", or "signal" for the attribute name?

Optionality of
this attribute and the name of the attribute are secondary. I'm fine either
with type or responseType.

 

 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.