[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] WS-Resource Framework
This raises some very good points, though I wonder if the analogy
wouldn't be stronger if your "bad" C++ example wasn't recast to:class FactoryService { public: FactoryService(void); ~FactoryService(void); ResourceService getResourceReference(); }; class ResourceService { public: ResourceService(void); ~ResourceService(void); int getResourceValue(); void setResourceValue(int); private: int _serviceResource; };To illustrate more clearly just how brittle this model is: (assuming I read the specs/whitepapers correctly) resources don't necessarily exist qua services at all; they are artifacts of a service. It seems to me that one of the key rationales for the CORBA-like encoding of reference to resources is programmer convenience, but at what cost? I agree that a combination of a) higher level abstractions and b) judicious use of context mechanisms would provide a more robust infrastructure. Greg Savas Parastatidis wrote: Jim Webber (Jim.Webber@newcastle.ac.uk) requested me to send this message on his behalf because he's not subscribed to the WS-CAF mailing list yet. I am sending it to both lists since I think it's relevant...---------------------------------------- Hi Eric, Your post got me thinking, particularly the coining of the term"pointer"for what WS-RF does. I'd like to illustrate this with an example intermsthat we're all familiar with (C++): Imagaine a simple service: class Service { public: Service(void); ~Service(void); int getResourceValue(); void setResourceValue(int); private: int _serviceResource; }; I'll leave out the implementation of the two member functions here. They're just logic that provides some level of access to the data in the class (aka the resources that the service is built from). int main(int argc, char* argv[]) { Service* myService = new Service; /* The normal way to access a logical resource (by sendingmessages toa service that knows about it)*/ myService->getResourceValue(); myService->setResourceValue(101); // The WS-RF-like approach myService->_serviceResource = 101; // Note: myService->_serviceResource is the "addressing mechanismforresources" } A WSA-like Web Service would execute and action in response to amessage(my analogy here is that some logic gets fired on a function call). Thisisfine since (in both cases) the private data/resources is not exposedoutside ofthe object/Web Service and so we prevent direct binding and brittle applications. In the WS-RF case we get to know the address of some resource, whichin mymain program is "myService->_serviceResource". Now we can binddirectly tothat which is a bad thing since it means I cannot evolve the implementation of my service/class without potentially breaking any users. In factthisis so bad that even my very forgiving C++ compiler reminds me thatprivatemeans private! So how should addressing for resources be done? My short answer isthat itshouldn't since it invites one to build brittle applications with inter-organisational dependencies on all sorts of low-levelabstractionslike files. Instead I would advocate the building of higher-level abstractionslikefile stores instead of files. These higher-level (i.e. coarser grained) services can service many requests for "file access" and by using a mechanismsuchas WS-Context we can effectively give the file store the information itneedsto do the right thing at its back end. This does not necessarily meanthatthere is a one to one association between a file and a context - thefilestore service is free to implement (and indeed re-implement) itsback-endas it sees fit, because I haven't peeked into its private state and Ihold noreferences to anything in there either, just a context which helps the file store service to do its job. It's harder to illustrate this in C++ (for obvious reasons that C++ is(orcan be) object oriented, not service oriented): class FileStoreService { public: Context createFile(); byte* getData(Context c, int start, int offset); // Other member functions left out for clarity }; Now the important thing to understand about the FileStoreService classisthat we don't actually know that there are any files at all under the covers (that's why I left the private bit out). It could be that there is ateamof trained monkeys with typewriters and huge filing cabinets under the covers, or it could indeed be files. The point is that we no longer allowtheseback-end resources to be addressed and thus we don't encourage peopletobind to resources they shouldn't and so we discourage the creation of brittle applications. Now there is the case where some information at the back end has a lifetime which exceeds that of the context within which it was created. This is fine, all we need there is a unique name to associate with that information which can be used to rehydrate and interaction context (via some out ofboundmechanism like registries), or which can be used in some application-specific way (e.g. as an element in a message sent to a service). None of this requires any additional infrastructure to be built, other than what is already available or in the pipeline in the Web Servicesspace. Myfear is that WS-RF will be (indvertantly) used to create "CORBA on the Web" which just makes me sad. Jim |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]