RE: Stateful Web Services...

Hey Chalon,

> I'm very surprised to see this comment from Savas -- I think he knows
> better.  Yes the Grid community retracted OGSI, but it did not abandon
the
> effort to define a standard protocol for stateful web services.
Instead
> OGSI was superseded by a set of proposed standards collectively called
the
> Web Services Resource Framework (WSRF).  The reasons for the change
are
> many-fold, but by no means do they imply that OGSI was a miserable
> failure.

I am surprised you are surprised I made such a comment :-)) (just joking
of course)

I agree that the Grid community has continued the efforts to define
standards means to deal with state. However, in doing so it has really
shifted the focus from 'stateful services' to 'resources'. WS-RF, as the
name suggests, is not about dealing with services as stateful agents
but, rather, as agents that provide access to state. I personally see
that as a change in the focus at the architecture level. At the end of
the day it may seem as it is achieving the same thing but there was
definitely a move away from Grid Service Instances and towards to
Resources.

Perhaps "miserable failure" was not the most diplomatic way of putting
it, so I do apologise.

> Miserable failures do not have substantial follow on efforts based ona
> substantial core of the original.  (For those interested in details,
the
> main differences between OGSI and WSRF are a) abandoning creating a
> special
> version of wsdl using the extension mechanism in XML Schema, and b) a
> change
> in packaging -- splitting one standard up into a set of standards.  Of
> course, as you would expect the authors have also taken the
opportunity to
> clean up a number of smaller items, but these are what I would call
the
> big
> ones.)
> 

Factorisation and conformance to existing WS specs in WSRF has been a
great improvement over OGSI. However, I still believe that the move from
services to resources as the building blocks for distributed
applications has been significant but is never highlighted.

> I do not understand Savas' comment about scalability depending on not
> having
> an assumption about the endpoint maintaining state.  Quite the
opposite.
> You cannot scale large systems if you have to assume all state has to
be
> transferred every time.  At least this is my experience, and I think
we
> build some pretty robust, scalable systems.  I would say that what you
> really want to avoid is having to assume that you will always have to
go
> to
> the same endpoint because of dependence on state.  A mechanism that
> provides
> for transference of information about how to get at that state does
just
> that.  If you go Savas's route you invent that for yourself.  If you
> follow
> WSRF, you will be following a standard protocol for defining and
> transferring that information.
> 

As others have pointed, it is not the case that all state has to be
transferred. Only state that is required for the receiving service to
re-establish the scope for processing the message. When you send a
cookie with every HTTP request, you don't send your bank account
details. Only the information that is necessary for any web server
around the world which belongs to your bank to process your request.
It's the same in the real world. Your bank doesn't give away a phone
number for every account holder. Instead, you have to call a single,
well-known number and then let them know your account number in order to
establish a context for the interaction that will follow.


Best regards,
.savas.

Received on Friday, 29 October 2004 20:25:15 UTC