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 16:11:49 UTC