OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[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
> for what WS-RF does. I'd like to illustrate this with an example in
> 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
> resources"
> }
> A WSA-like Web Service would execute and action in response to a
> (my
> analogy here is that some logic gets fired on a function call). This
> 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
> is
> so bad that even my very forgiving C++ compiler reminds me that
> 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
> like files.
> Instead I would advocate the building of higher-level abstractions
> 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
> as
> WS-Context we can effectively give the file store the information it
> to do the right thing at its back end. This does not necessarily mean
> there is a one to one association between a file and a context - the
> store service is free to implement (and indeed re-implement) its
> 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
> 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
> 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
> 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
> back-end resources to be addressed and thus we don't encourage people
> 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
> 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]