- From: Steve Graham <sggraham@us.ibm.com>
- Date: Tue, 17 Jun 2003 16:06:25 -0400
- To: "VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com>
- 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, Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>, Steve Tuecke <tuecke@mcs.anl.gov>, Umit Yalcinalp <umit.yalcinalp@oracle.com>
I am struggling with the notion of information appearing only in the binding and not in the abstract interface. This seems to be far too surprising. Many tools work off of the interface to define most of the application API, hiding the binding detail. I am not clear that putting this information only in the binding solves any problems, it just shifts them. sgg ++++++++ Steve Graham sggraham@us.ibm.com (919)254-0615 (T/L 444) STSM, On Demand Architecture ++++++++ "VAMBENEPE,WILLIA M To: Steve Graham/Raleigh/IBM@IBMUS, Savas Parastatidis (HP-Cupertino,ex1 <Savas.Parastatidis@newcastle.ac.uk> )" <vbp@hp.com> cc: David Snelling <d.snelling@fle.fujitsu.com>, Jim Webber <jim.webber@arjuna.com>, ksankar@cisco.com, Paul Watson <Paul.Watson@newcastle.ac.uk>, 06/17/2003 01:21 public-ws-desc-state@w3c.org, Steve Tuecke <tuecke@mcs.anl.gov>, Umit Yalcinalp PM <umit.yalcinalp@oracle.com> Subject: RE: Some requirements What I hear Savas say is "the interface should only contain the list of attributes, not how to get them". This is different from "the information on how to get an attribute is not available in the WSDL document". Bindings and ports are part of the WSDL doc. I don't have a problem with this information being entirely in the binding. We have one proposal from ServiceData in which information on how to get hold of attributes is really split between the interface and the binding (plus port for the endpoint URL). In order to "get" an attribute using the ServiceData approach, I need to find the interface with the get operation but I also need to find a binding for this interface. So really the information on how to build my "get" message is half in the interface half in the binding. If we can come up with a way to keep this information entirely in the binding I'd be ok with that as long as this technique also meets our other requirements (like bulk access to attributes). At this point I don't really see what this would look like, but I am interested in investigating this approach as long as we keep our requirements in mind (which are not met by a simple implicit get/set scenario). But this would mean that whoever creates a new binding for WSDL 1.2 (the WG in the case of the SOAP over HTTP binding, other people for other bindings) need to provide in their bindings information on how to format not only an operation request but also an attribute access request. The important thing from my point of view is that when I get a complete WSDL doc (including abstract and concrete parts) I know exactly what to do to access the attributes. Savas, do you agree that bindings should provide this information and that, in the case of the SOAP over HTTP binding it means that the WSDL working group would have to enrich the binding to tell people how to access attributes defined in the interface? Or are you saying that this does not belong in the "generic" bindings even but somewhere else altogether (but then I ask why would binding be specific to operations and not attributes?). Regards, William > -----Original Message----- > From: Steve Graham [mailto:sggraham@us.ibm.com] > Sent: Tuesday, June 17, 2003 9:20 AM > To: Savas Parastatidis > Cc: David Snelling; Jim Webber; ksankar@cisco.com; Paul > Watson; public-ws-desc-state@w3c.org; Steve Tuecke; Umit Yalcinalp > Subject: RE: Some requirements > > > > > > > > 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 16:11:49 UTC