- From: Jim Webber <jim.webber@arjuna.com>
- Date: Fri, 11 Jul 2003 14:03:20 +0100
- To: <public-ws-desc-state@w3.org>
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