RE: attributes & WSDL (was: Re: attributes in CORBA IDL)

David:

> 2) Declaration of static values in the WSDL.
> 
> I don't see a problem here as long as something like this is 
> possible (converted to OGSI terminology).
> 
>  <wsdl:interface name="myInterface">
>     <wsdl:attribute name="foo"         type="xsd:string"
>                     modifiable="false" mutability="static">
>        "Imagination is the only weapon in the war against reality.
>                                - Jules de Gautier "
>     </wsdl:attribute>
>  </wsdl:interface>

Could you elaborate on this? if this really is static in its classical sense
I have two niggling doubts.

Firstly (and even though this is a staeful services list) what does it mean
to have a static value for a service? Surely since a service is a service
(and not an object) eveything is implicitly static?

Secondly, even if I put my OGSI goggles on and see things as objects, I
can't quite reconcile static constructs in an interface. After all if you
look at (say) Java, then static fields/methods in an interface are not
allowed because it doesn't make sense.

> 4) Dynamic attributes
> 
> You will recall that the OGSI model allows serviceData values 
> to be added to a service's state dynamically. I believe that 
> the translation to getter/setter makes this a bit 
> complicated. The "is translated to this" bit in the proposal 
> would need to be done on the fly at invocation time. My guess 
> is that this is possible, if requiring a bit of cleverness in 
> the tooling.

This raises a more general issue. If you want to do something dynamic, then
I don't think WSDL is the place for it. 

> 6) Getting multiple attributes at once
> 
> One requirement not addressed is the ability to get more than 
> one attribute in a single invocation.

Absolutely right, because attributes are taken from closely coupled
component models like Java and .Net. When we find ourselves resorting to
this kind of "attribute bundling" then I think it is indicative of a deeper
problem. Of course attributes for Web services should be coarse grained just
like messages that underpin operations, but the requirements that the Grid
community (which seems object-focussed) would detract from that (and hence
the artifical bundling).

> This addresses most of out needs. The complex query 
> processing across multiple attributes could be done at the 
> GridService level (e.g. in our interface specification). I 
> have left out deletion of attributes, but setting them to nil 
> might work. We would need to rework the distinction we make 
> between nil and not there, but this was an area of some debate anyway.

I agree with this and in fact I think a lot of these issues can be addressed
at the application (Grid) level. If we view the Grid as an application
framework which just happens to utlise Web services as its (logical)
network, and layer Grid-esque things on top.

From the point of view of a Web services protagonist I value the feedback
from the Grid community, but I feel that some parts of what the Grid wants
Web services to become is actually Grid-specific.

Jim

Received on Thursday, 3 July 2003 06:51:44 UTC