Re: [ws-caf-comment] Public Comment

[Mark Little <mark.little@arjuna.com>]

Thanks for the comments. I'm sure other members of the TC may want to 
reply, but here are my initial thoughts.

Firstly, many of the things you mention in your comments are valid 
(e.g., re-setting context timeouts after creation), but have been 
considered and voted against by the TC. Please remember that this work 
has been going on for over 2 years, including several interoperability 
events, with feedback from other standards and specifications. As with 
any standard, it is impossible to please all of the people all of the 
time, so WS-Context represents a compromise that satisfies all of the 
basic requirements from companies such as Oracle, IONA, Arjuna etc.

Secondly, I would encourage you to go back through the WS-CAF mail 
archive and see the arguments that have developed over the lifetime of 
this TC in relation to many of the issues to bring forth.

More specific comments inline.


comment-form@oasis-open.org wrote:


>>Comment from: wuchou@avaya.com
>>
>>Name:W. Chou & L. Li
>>Title:Comments and Questions on WS-Context 1.0 Draft
>>Organization:Avaya
>>Regarding Specification:WS-Context 1.0 Draft
>>
>>The current WS-Context 1.0 Draft is still too loose to ensure predictable and interoperable operations and this is a must for any standard. 
>>  
>>
>  
>
I disagree. In many ways, WS-Context is more constrained than many of 
the current WS standards. You also need to remember that although this 
specification can be used in relative isolation, it is really intended 
to be used in conjunction with referencing specifications, which SHOULD 
place further restrictions on what is allowed.


>>It should reference existing industry standards on context and session, e.g. ECMA-366, WS-Session, ECMA International (http://www.ecma-international.org/standards/ecma-366/ws-session/) 
>>  
>>
>  
>
WS-Context is not an academic paper and hence cannot be expected to 
reference all work in this space, particularly work that began 18+ 
months after WS-Context. The inverse could be argued: WS-Session (and 
this is the first time I've heard about such a thing) should reference 
WS-Context. Although I am aware of ECMA, and fully support any efforts 
for open standards, it isn't a body that features prominently in the 
world of Web Services standards or specifications.


>>Detailed comments and questions on WS-Context 1.0 Draft are attached below.
>> 
>>1.	In WS-Context, the context is externalized from the web services participating in an activity. How do these services agree upon and validate the context propagated? 
>>
>>For example, if a client C creates a context X on a Context Service and passes it to a server S, how does S know X is a valid context since S did not create X? 
>>
>>It seems some hand-shaking must be standardized between the Context Service and all the web services participating in an activity during context creation. But this is not specified by WS-Context.
>>  
>>
>  
>
That is part of the relationship between WS-Context and referencing 
specifications, which the current specification makes clear in several 
places.


>>2.	WS-Context seems to imply that there are two versions of context, the base context created on Context Service and the derived contexts augmented by each Web Service based on the base context. Is the relationship between base context and activity one-to-one or many-to-one? 
>>  
>>
>  
>
Again, the relationship between context and activity is made clear in 
the current specification.


>>3.	WS-Context allows web services to modify an existing context (by wsctx:setContents). This may introduce data coupling issues beyond web service interfaces. For instance, if a web service C sets an ad-hoc element in context X, it expects other web services sharing this context to understand the element.
>>  
>>
>  
>
The TC discussed this issue at some length during its first 6 months and 
decided that it would be unwise to address this within the base 
WS-Context specification. It is something that referencing specification 
or implementations can impose.


>>4.	WS-Context seems to allow derived context to be propagated between Web Services (line 320). If so, these web services may establish ad-hoc point-to-point relation which defeats the purpose of a centralized context promoted by WS-Context. 
>>  
>>
>  
>
WS-Context does not promote a notion of centralised contexts. It allows 
it, if you use pass-by-reference, but it doesn't require it. In fact, 
the current interoperability scenarios work purely in pass-by-value.


>>For example, if client C creates a context X0 and passes it by value to servers A and B. A and B augment X0 to Xa and Xb respectively and pass them back to C. Now C has to remember X0, Xa with A, and Xb with B, instead of just X0, in order to use and terminate these contexts.
>>  
>>
>  
>
Not so. I would encourage you to re-read the specification on 
activity-to-context relationships as well as the primer and papers such 
as 
http://webservices.sys-con.com/read/44675.htm?CFID=21423&CFTOKEN=7063163F-A462-EC9A-EF02116F440E0482 
and 
http://www.orablogs.com/pavlik/archives/The-Session-Concept-in-Web-Services.pdf

>>5.	WS-Context does not mandate Context Service to notify web services of context status. Web services have to call Context Service to get the status. Coupled with passing-by-value of context, it may create a lot of staled contexts on web services and introduce overhead in context synchronization and management. For example, many web services may frequently call Context Service to get status, or many web services may try to wsctx:complete a context which was already terminated by somebody else.
>>  
>>
>  
>
Again this was something the TC debated and agreed was to be handled by 
implementations. Not the best solution in some situations, but it hits 
the 80/20 mark.


>>6.	WS-Context does not allow change of a context expiry after it has been created. It is impossible for a web service to renew a context to a longer duration which is a fatal flaw.
>>  
>>
>  
>
See above.


>>7.	Web services participating in an activity need to report its status to Context Service so that Context Service can monitor activity on each context. WS-Context does not specify any interface for doing this. This may introduce interoperability issues.
>>  
>>
>  
>
No they don't. There is no relationship between Web Services and the 
activity/context they participate within in terms of status 
requirements. There was something in very early drafts (the Activity 
Lifecycle Service, or ALS), but we dropped that very early on in the 
standardisation process.

We have successfully demonstrated interoperability of WS-Context between 
multiple vendor implementations on at least 2 occassions.


>>8.	WS-Context defines all operations in its WSDL as one-way operations. This is highly unsafe, since there is no acknowledgement. It is more natural to define them as request-response operations which capture the causal relations between messages. 
>>  
>>
>  
>
The TC debated whether to support request/response as well as one-ways. 
The concensus was to simply go with one-ways because a) that is the 
prevelant way in which other WS specifications are going, and b) 
request/response can be layered on top. Causal relationships can be 
addressed via appropriate WS-Addressing useage.


>>9.	wsctx:begin message requires a wsctx:type element based on which a context is created. However, the meaning of wsctx:type is not defined at all.
>>  
>>
>  
>
It is defined within the current specification.


>>10.	WS-Context equates the concept of context with the concept of “Session”, which is incorrect. Session is a high level context based container construct as used in communication. If WS-Context models “session”, it should specify that when a context is terminated, all of its child contexts, if any, will be terminated, as defined in ECMA-366, WS-Session.
>>  
>>
>  
>
Sorry, but WS-Context's defines a pretty precise notion of session which 
is compatible with other session models in other environments. Please 
re-read the specification and/or the cited papers above.


>>11.	Standardized Fault messages are not defined in WSDL.
>>  
>>
>  
>
Not a problem. Follows existing WS specifications.

Thanks again for your comments.

Mark.


>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ws-caf-comment-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: ws-caf-comment-help@lists.oasis-open.org
>>
>>  
>  
>