- From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
- Date: Mon, 16 Jun 2003 23:59:06 +0100
- To: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
- Cc: <ksankar@cisco.com>, "Steve Graham" <sggraham@us.ibm.com>, "David Snelling" <d.snelling@fle.fujitsu.com>, "Jim Webber" <jim.webber@arjuna.com>, "Paul Watson" <Paul.Watson@newcastle.ac.uk>, <public-ws-desc-state@w3c.org>, "Steve Tuecke" <tuecke@mcs.anl.gov>
- Message-ID: <BC28A9E979C56C44BCBC2DED313A447001D75499@bond.ncl.ac.uk>
[snip] Perhaps the analogy is not to a C++ language specification, but to a component model. It is not the language specification that dictates the usage of some interfaces or methods, but the definition of these models. For example, EJB 2.0 CMP model defines both attributes that describe state in its abstract model and also well defined syntax to access these attributes via get/set methods. Without defining how the access should happen in a uniform and well understood way, just defining a set of attributes may not be that useful. What I am not clear about is your position actually. I have been trying to follow your postings. Are you suggesting that a set of attributes that describe state is not a useful concept or are you suggesting that providing an agreed convention for accessing them (perhaps via a set of operation conventions) should not be targeted by the WSD wg? Apologies if my postings have not been clear :-( I will try to clarify my position... I can see the reason we need attributes. Attributes can be used to expose state in a standard way. However, I believe that the WSD specification should only define the syntax of attributes and how they relate to messages. For example... (please note that this should be used as an example and not as a proposal) <attribute name="myAttribute" message="tns:messageName" readonly="true"> <!--other attribute-related elements or XML attributes--> </attribute> <interface> <attribute name="tns:myAttribute"/> <operation name="tns:myOperation"/> </interface> I do not believe that the WSD specification should define a number of specific operations, like the ones specified by OGSI: get, set, find, subscribe, etc. If such operations was seen as necessary, another specification should be introduced that talks about them and their relation to the WSDL attributes. Please, note that since the attribute of the example above specifies a relationship with a wsdl:message, there would probably not be a need for get/set operations. But then again, that attribute is part of the interface while OGSI allows attributes (serviceData) to appear at runtime, which is the reason get/set operations are required. As for the analogy with C++, or Java for that matter... The EJB component model is built on top of a language specification (Java language). The Java language does not specify any operations. Perhaps I should have used the IDL specification instead of C++. IDL is used to describe OO interfaces and not to define the behavioural semantics of a component model. It is my understanding that WSDL is used to define the interface of web services and how that interface maps to operations and messages (no?). Nothing is said so far in WSDL about specific operations that must be supported (like get/set). I believe that such specific operations should not be part of a WSDL specification. The mapping of attributes to messages, though, is probably required (see example above). I am not clear about your comment. Are you suggesting WS-I should be responsible for defining common interfaces? Since I did not understand the previous comment well, it may be speculation on my part. No no. I am not suggesting that WS-I should be responsible for that. Part of WS-I's role is to create profiles of Web Service specifications. If a specification that included specific attributes-related operations was deemed necessary, then WS-I would be responsible for adopting it and including in its profile of standards, thus ensuring interoperability. We can not say that the web services oriented architecture is stateless or stateful. At best, the assertion we can make is that there is no well defined mechanism for defining explicitly what external state is, or how internal state is exposed. If I were to provide a counter method on a service which returned the next integer to the client, would this service be stateless or would its state be undefined with respect to WSDL today? I would say that in the current SOA the state of the service is undefined. It is obvious that in order for a counter service to provide a useful functionality, some state has to be maintained. However, the SOA says nothing about that state, how it is maintained and how it is exposed. IMHO, I don't believe that attributes would provide a solution to this. Instead of having a getCounterValue operation, now we will have a counterValue attribute (granted, with some more information attached to it). Still, nothing is said about the state that is maintained but, rather, just the type of the counter's value and the wsdl:message that will be returned. Please, do forgive me if I haven't been clear. Let me know if clarification on any of the above is necessary. Again, all these are just my personal views and I may be very very wrong. I hope I am not causing problems or delaying progress by supporting them. Best regards, .savas.
Received on Monday, 16 June 2003 18:59:29 UTC