RE: Stateful Web Services...

> 
> First, thanks Chalon for initiating this very good conversation.
> 

And to Cristovao who started the original thread.

> Second, I need to weigh in a little on some of the comments related to
the
> transition from OGSI -> WSRF (as an author on both, I have some
insight
> here).
> 
> OGSI->WSRF was motivated by a combination of things.  Most
importantly, it
> was the aggressive use of WSDL and XSD that was a major motivator for
the
> shift to WSRF.  An observer should note that most/all of the concepts
in
> OGSI migrated to WSRF in some form.  The syntactical representations
of
> these concepts in WSRF (in particular the use of WSDL 1.1 (not GWSDL),
the
> more conventional use of XSD, the use of WS-Addressing) were made in
order
> to rehost the statefulness concepts in OGSI onto a platform that was
more
> in line with the "state of the art" (excuse the pun) of Web services.
> 

It is certainly the case that many of the concepts from OGSI have
remained in WS-RF. However, I personally see the move from the Grid
Service Instances, where there was an assumption of a 1-1 association
between a Grid Service Instance and a resource, to a model where
resources are explicitly modelled as a change in the architecture. As
always, I think we'll have to agree to disagree on this one.

In WS-RF, if there wasn't the concept of a service it wouldn't have
mattered. The model would have been the same. Please note that we are
talking about an architectural difference and not a technological one.
Yes, WS-RF uses existing specs, it doesn't introduce extensions to WSDL,
and it doesn't "aggressively" use XSD. However, it models resources not
services.


> Although some may claim that the conversion of terminology from
'stateful
> services' to 'resource' reflected in the transition from OGSI to WSRF
was
> somehow profound, I fail to see it.  For the most part, this
transition of
> terminology was minor in comparison to the other conversions that
happened
> from OGSI to WSRF (syntactical reorientation, factoring of the
> specifications etc.).  Some folks get hung up on the distinction
between
> 'stateful services' and 'resources', but I don't.  The types of
problems
> we are addressing with WSRF are the same as those with OGSI.
> 

There is no argument that you are trying to deal with the same set of
problems. I would have been very surprised if you had chosen to move
away from OGSI and choose a new set of problems to deal with :-)

You could have chosen CORBA to deal with the same set of problems. In
fact, I know many in the OGSI community who wanted to do exactly that:
model CORBA using angle brackets. 

> Finally, a direct comment on Mark's point:
> >Well, I personally feel that the Grid community has made a mistake by
> >so fully embracing stateful comms with WS-RF.  YMMV, of course. 8-)
> 
> Two major thoughts here:
> a) the Grid community is lining up with the systems management
community
> (eg OASIS WSDM) to represent system resources (in the systems
management
> sense) using the same technologies.  In this way, the part of the Grid
> "stack" that manipulates system resources, can do so in such a way as
> systems management applications do.  This alignment was a major
motivating
> factor in transitioning from OGSI to WSRF.  Net/Net, Grid apps can
> leverage the investment resource providers do in instrumenting their
> resources to present a WSRF interface.
> 

I have said in many occasions that OGSI and now WS-RF seem like very
good candidates for systems-management scenarios. Your above comment
seems to verify that. WSRF is a reasonable solution if one wishes to
remotely manage disks, CPUs, computers, software, etc. However, for the
internet-scale, cross-organisation applications I fail to see how
allowing remote parties to directly bind to the exposed state
(accompanied by a set of operations in a similar manner to objects) will
not introduce breaking references and tight-coupling. I am waiting to be
surprised on this one.

> b) Not all parts of the Grid application stack will use WSRF.  The
layers
> that are closest aligned to the system resources will likely use WSRF
for
> compatibility reasons with the resource instrumentation.  Besides that
> Grid applications that wish to deal with their own stateful resources
in
> an open standard way will choose WSRF.  Those Grid applications that
don't
> have a major component of state will use little or no WSRF.
> 

I have been using the SDSS SkyServer to access huge amounts of data in a
"stateful" manner without using WS-RF. Google Web Services provide you
access to huge amounts of state without WS-RF. WS-RF is not a solution
to all problems of state. It's just a solution.

My personal views of course!

Regards,
.savas.