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 Monday, 16 June 2003 20:27:33 UTC