Public Comment

[comment-form@oasis-open.org]

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. 

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/) 

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.

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? 

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.

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. 

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.

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.

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.

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.

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. 

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.

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.

11.	Standardized Fault messages are not defined in WSDL.