- From: Steve Graham <sggraham@us.ibm.com>
- Date: Tue, 17 Jun 2003 12:20:01 -0400
- To: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
- Cc: "David Snelling" <d.snelling@fle.fujitsu.com>, "Jim Webber" <jim.webber@arjuna.com>, ksankar@cisco.com, "Paul Watson" <Paul.Watson@newcastle.ac.uk>, public-ws-desc-state@w3c.org, "Steve Tuecke" <tuecke@mcs.anl.gov>, "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
well, I guess what I am not comfortable with is the separation of the approaches to do dynamic queries and direct attribute get/set. If this met requirements, then the better approach would be to use getter/setter pattern like used in Java Beans, and avoid this entire approach. However, we rejected that approach because queries across multiple attributes, multiple attribute get, multiple attribute set and dynamic attributes need to be supported. so, all things considered, a single standard approach to accessing state is what I would prefer, over splitting this function over multiple, potentially divergent specs. sgg ++++++++ Steve Graham sggraham@us.ibm.com (919)254-0615 (T/L 444) STSM, On Demand Architecture ++++++++ "Savas Parastatidis" <Savas.Parastatidis@newca To: Steve Graham/Raleigh/IBM@IBMUS stle.ac.uk> cc: "David Snelling" <d.snelling@fle.fujitsu.com>, "Jim Webber" <jim.webber@arjuna.com>, <ksankar@cisco.com>, "Paul Watson" 06/16/2003 08:27 PM <Paul.Watson@newcastle.ac.uk>, <public-ws-desc-state@w3c.org>, "Steve Tuecke" <tuecke@mcs.anl.gov>, "Umit Yalcinalp" <umit.yalcinalp@oracle.com> Subject: RE: Some requirements > > Savas: > Ok, things are getting more clear, but I still do not see your point. > :-) and :-( > In your example, how do I as a requestor know how to get/set the value of > myAttribute? how can I query whether the state of the service has > myAttribute="someValue" and anotherAttribute > 12 and ...? > OK. This is not an example that I have thought through well nor it is a proposal on how attribute should be presented in WSDL... just a vehicle for discussion (I hope). An attribute is associated with a wsdl:message. A wsdl:message indirectly provides the type of the attribute. <message name="msgName" type="xsd:positiveInteger"/> <interface> <operation name="getValue"> <output message="msgName"/> </operation> <attribute name="myAttribute"> <output message="msgName"/> </attribute> </interface> In the above example, the attribute is readonly (no input message). Unlike an operation, an attribute may have 0 to 1 output and 0 to 1 input messages (if it has 0 and 0 it can be considered as static). An alternative representation with the same semantics could be: <attribute name="myAttribute" message="msgName" readonly="true"/> (Only allows a message "msgName" to travel from the service to the consumer and not the other way around). Please note that the above example says nothing about the binding of the attribute construct to an underlying communications protocol, exactly as it is the case with operations. Attributes can have static values, like in OGSI (Note, no input or output messages, so you need a type): <attribute name="myAttribute" type="xsd:positiveInteger"> <input/> <output/> <value> 1 </value> </attribute> You get the value of an attribute when you receive a message "msgName" (how the "get 'myAttribute'" request is made to the service is binding-specific). In the same way, you set the value of an attribute by sending a "set 'myAttribute'" request, which, again, is binding-specific. WSDL says nothing about these requests, as it says nothing about how an operation is mapped to a specific communications protocol. You see, however, such an approach does not require wsdl:operation declarations, while the serviceData model does. Of course, there are restrictions... No common way to dynamically created attributes, no service-side queries. IMHO, these are facilities that should be introduced by another specification (e.g., WS-ServiceData). WSDL just introduces the syntax of an attribute and how it maps to messages. WS-ServiceData may define what kind of wsdl:operations must be supported by a web service that adheres to that spec. > If one somehow associates attributes with messages, does the requestor > somehow have to figure out which operations somehow use those messages as > input and output? > > I guess I still don't understand the approach you are suggesting, nor do I > completely understand your concerns with the OGSI service data approach. > I want to make it clear that I have no problems with the OGSI approach. It works fine for what it is meant to address. It is defined by a specification that meets the requirements of an application domain. Now, you argue that serviceData, as defined by OGSI, can be useful not only to the Grid application domain but in general to all application domains in Web services. Again, I agree that this may be the case. However, I believe that the serviceData concepts cannot be defined as is in WSDL because they require the use of specific wsdl:operations. WSDL could be used to define how attributes can be made part of an interface (as in the example above). Once you have that, you can build, in a separate specification, the extra operations (wsdl:operations) that are required. Just my 2c (or 2p since I am in the UK :-), .savas.
Received on Tuesday, 17 June 2003 12:25:44 UTC