Re: [ws-caf] WS-Resource Framework

[Greg Pavlik <greg.pavlik@oracle.com>]

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