OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [REL-94] POLL from user perspective

I would like to try a different approach to thinking about how we are going to be defining the Polling operation. I think the concerns as to how this is going to be represented, i.e. as a header or body operation, center around issues related to platform implementation, intermediaries or application developer usage. So let me try to express what the implications of this operation are for each of these.

I think that the platform implementation concerns are largely not valid. It seems to me that there is no real issue in getting a SOAP stack to inspect either the header or body. Obviously there are advantages in only having to inspect headers in some implementation approaches. The use case that explains why only inspecting headers and avoiding the body altogether is when the reliability layer is provided by intermediaries. In this scenario the reliability features would be added to the message header by nodes that are transparent to the client application. In this case it would not ever be possible that the client application would even make the request for the poll operation as it has no knowledge of the reliability layer. 

So why would the intermediaries make use of the poll operation themselves? The use cases we have for the poll operation do not apply to intermediaries that one would assume are on servers in a data center somewhere. The only case where I see an "intermediary" needing to make use of the poll pattern is when it needs to expose the semantics of the operation to a client that has no RM implementation but needs to make use of it's features. This could occur when you have a limited device that is communicating messages (sales orders etc.) that need confirmation before they are removed. Note that the client application has at least some notion of reliability.

As for application developers obviously if they are not adding any reliability features to their messages and it is handled by intermediaries I think they would never make use of a polling operation. If the developer is working on an application that fits into our use cases for the polling operation they are likely to be utilizing the features of WS-Reliability directly in their code. In this case when they utilize the polling operation that they will need to identify the endpoint to which they will address this operation. In that case I think providing polling pattern as an operation represented in the SOAP body will better facilitate its usage. I think leaving it in the header for these users, whether or not it is exposed via wsdl, will hamper its proper usage. Admittedly proper toolkits and/or apis would largely address concerns I have with the intuitiveness of only using the header, but these are unlikely to be available in the near term and it is important that this proto!
col be adopted quickly.

Marc g

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]