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
"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]