RE: Some requirements

The list of attributes will be in the interface, so the tools will be able
to use this to expose what attributes are available, just the way they today
expose what operations are available. Only at invoke time will they need to
use the binding, which they will anyway if we use the ServiceData approach
as the get/set methods need bindings anyway.

Once again, I am not convinced this approach will allow us to meet all our
requirements elegantly. But if it does then I don't dislike it.

In the heart of it, they are really similar. I can translate the ServiceData
approach into one that maps to the "binding only" approach just by saying in
the spec that whenever a binding maps to an interface which includes
attribute, the interface can be assumed to also have "virtual" (but
well-defined by the spec) operations that do not appear physically in the
interface but are assumed to be there because the attributes are there. And
add to the binding the information that would be needed in a separate
binding that would have to map to the get/set interface if it existed. In
graphical form:

ServiceData approach is:

<myInterface> ---- maps to -----> <myBinding>
  <operation1/>                      <operation1 binding info>
  <operation2/>                      <operation2 binding info>
  <attribute1/>                    </myBinding>
  <attribute2/>
</myInterface>

AND

<GridServiceInterface> ---- maps to ----> <GridServiceBinding>
  <find/>                                    <find binding info/>
  <set/>                                     <set binding info/>
</GridServiceInterface>                   </GridServiceBinding/>

An alternate approach could be:

<myInterface> ---- maps to -----> <myBinding>
  <operation1/>                      <operation1 binding info/>
  <operation2/>                      <operation2 binding info/>
  <attribute1/>                      <find binding info/>
  <attribute2/>                      <set binding info/>
</myInterface>                    </myBinding>

In this approach the find and set operations are implicitly added to
myInterface by the addition of the attributes. Aren't these two approaches
really the same thing for all practical purposes? In fact, if there is a
difference it is that the second approach allows you to use different
bindings to retrieve attributes defined in different interface, which is a
nice plus as the operations in the different interfaces might be accessible
through different bindings.

As I said earlier, I like keeping the symmetry between attributes and
operation as much as possible. The one thing that will force us to break it
at some point is that we have requirements that require us to access several
attributes in one invocation, which is not the case for operations (WSDL
doesn't describe how to send one message that invokes several operations).

Regards,

William

> -----Original Message-----
> From: Steve Graham [mailto:sggraham@us.ibm.com] 
> Sent: Tuesday, June 17, 2003 1:06 PM
> To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1)
> Cc: David Snelling; Jim Webber; ksankar@cisco.com; Paul 
> Watson; public-ws-desc-state@w3c.org; Savas Parastatidis; 
> Steve Tuecke; Umit Yalcinalp
> Subject: RE: Some requirements
> 
> 
> 
> 
> 
> 
> 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 18:14:34 UTC