Re: Some requirements

What you're proposing looks like the same approach BPEL took
with properties - they are carried as part of the <message>
and the definition tells you where to find it in the message.

Interesting. I have to think about this more.

Sanjiva.

----- Original Message -----
From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
To: "Steve Graham" <sggraham@us.ibm.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>; "Steve
Tuecke" <tuecke@mcs.anl.gov>; "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
Sent: Tuesday, June 17, 2003 6:27 AM
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 02:55:15 UTC