[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WS-Resource Framework
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 in terms > that 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 sending messages to > a > service that knows about it)*/ > myService->getResourceValue(); > myService->setResourceValue(101); > > // The WS-RF-like approach > myService->_serviceResource = 101; > > // Note: myService->_serviceResource is the "addressing mechanism for > resources" > > } > > A WSA-like Web Service would execute and action in response to a message > (my > analogy here is that some logic gets fired on a function call). This is > fine > since (in both cases) the private data/resources is not exposed outside of > the 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, which in my > main program is "myService->_serviceResource". Now we can bind directly to > that which is a bad thing since it means I cannot evolve the > implementation > of my service/class without potentially breaking any users. In fact this > is > so bad that even my very forgiving C++ compiler reminds me that private > means private! > > So how should addressing for resources be done? My short answer is that it > shouldn't since it invites one to build brittle applications with > inter-organisational dependencies on all sorts of low-level abstractions > like files. > > Instead I would advocate the building of higher-level abstractions like > file > stores instead of files. These higher-level (i.e. coarser grained) > services > can service many requests for "file access" and by using a mechanism such > as > WS-Context we can effectively give the file store the information it needs > to do the right thing at its back end. This does not necessarily mean that > there is a one to one association between a file and a context - the file > store service is free to implement (and indeed re-implement) its back-end > as > it sees fit, because I haven't peeked into its private state and I hold no > references 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 (or > can 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 class is > that 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 a team > of > trained monkeys with typewriters and huge filing cabinets under the > covers, > or it could indeed be files. The point is that we no longer allow these > back-end resources to be addressed and thus we don't encourage people to > bind 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 of bound > mechanism 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 Services space. My > fear 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]