[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf-comment] Public Comment
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 >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]