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

David:

> > I worry that including these kind of mechanisms will turn WSDL into 
> > the XML equivalent of C++ header files, and that as a result 
> > developers make bad decisions about the granularity of service 
> > interactions.
> 
> In one way this is probably true, but language designers have 
> always aimed to prevent bad designs, but developers will 
> always find a way to mess up.

I believe only too well the final part of that sentence. I am not so sure
whether the addition of attributes into WSDL tries to prevent developers
from messing up. In terms of grain size, it actively encourages them to mess
up. Still there are probably other compelling arguments for having them, and
althoug it might sound to the contrary, I haven't yet completely villified
attributes in my own head.

> > If we move away from the idea of WSDL as an IDL, and think 
> about WSDL 
> > as a protocol description language then I believe that things like 
> > this constant/static mechanism are unnecessary (since we 
> use WSDL to 
> > describe message format and binding, and not the interface 
> of an agent 
> > per se).
> 
> Just to get this clear in my mind - you would recommend 
> having WSDL-attributes declared and some way to access them 
> (which is not the issue in this thread), but not provide a 
> way to include and attribute values in the WSDL.

If I follow this correctly then yes. I would prefer to see:

<wsdl:attribute name="someAttribute">
  <wsdl:input message="someMesasge"/>
</wsdl:attribute>

than

<wsdl:attribute name="foo" value="bar"/>

because I see attributes as syntactic sugar for operations. Without
OGSI-esque service instances I think attributes in second way lose a lot of
their appeal.

> I think I see where you are going. In this case I would call 
> the GridServiceHandle the context. The WSDL service then uses 
> this information to appear 'stateful' regardless of its 
> actual implementation.

The difference is that a GSH exposes software agents that are logically
private to an administrative domain (i.e. the service provider). This means
that you effectively bind directly to someone else's object/process which is
not a good idea for building robust applications.

With a context, the service provider (who knows its own back end better than
any client could) can do the right thing. This loosely couples the
application and allows much nicer failure and recovery characteristics  for
one thing (especially if you make the interactions asynchronous).

> In the current OGSA architecture, this handle is mapped to a 
> reference (usually an endpoint) which exposes the instance 
> nature of the service. The important point here is that the 
> OGSA architecture does not actually have a bit of context 
> that is passed to a service endpoint to 'rehydrate' the 
> state. Without additional (application level information), 
> any client talking to that endpoint talks to the same instance.

Sure thing, and you can reproduce the same behaviour by sharing contexts,
and from my experience building transaction systems I can say that sharing
contexts is programmatically just as easy (if not more so) than sharing
references (since contexts are usually implicity shared by variable scope -
ctx.begin(), some work, ctx.end()).

I am certainly not trying to tell the Grid community to change its
requirements, just saying that they don't have to reinvent so much of the
work that the WS community has put in. I know much of the Grid WS-based
efforts comes from history where WS standards were new and the Grid
perceived that it had more advanced requirements than the WS specs at the
time could handle. It always puzzled me why in that case the Grid community
just didn't adopt CORBA and declare victory, rather than forking its own
WS-based efforts.

So to get back to the state issue as pertinent to this mailing list, I am
not convinced that attributes are anything but syntactic sugar for
operations, and I am convinced that WSDL has been able to support stateful
interactions since way back because it can describe SOAP header blocks.

Jim

Received on Friday, 11 July 2003 09:03:25 UTC