Re: [ogsi-wg] Re: Grid-SOA and service state

[Karl Czajkowski <karlcz@isi.edu>]

On Fri, Sep 05, 2003 at 03:15:24PM -0700, Peter Vanderbilt morse-keyed:
> [ in response to Savas's email of 8/23. ]
> 
> Savas & Paul,
> 
> Thank you very much for your response to my comments.  They were quite
> helpful.  Sorry I haven't gotten back to you sooner.
> 
> Here are some responses and additional points.
> 
> I believe there may be many cases where:
> 
>     Grid Service Instance (GSI) != Web Service Instance (WSI)
> 
> In fact there can be thousands of GSIs per WSI (although there may
> also be cases where they are one-to-one).  I may be abusing
> terminology, but the essential thing is that GSIs need not be heavy
> weight things.  The architecture does not require per-service state
> and certainly no per-service process.  For instance ...
> 

I would argue strongly against this idea.  Grid Services are Web
Services by definition of their use of Web Services standards.  There
is no standards-based implication that a Web Service instance is
heavyweight, corresponds to a service process, etc. either!  This
misunderstanding comes from inappropriate inference from specific
tools with biased implementation strategies.

I agree with the rest of your comments regarding scalability of OGSI
in principle, but the wording is off.  We should avoid continuing the
misunderstanding of Web Services (and by extension, Grid Services) as
corresponding to a service process, or implementation object, or what
have you.  It is little more than a service name and abstract protocol
for sending messages to the entity with that name.  OGSI simply adds a
few more standard abstract messages for introspection and control of
the abstract service environment.

All the talk about having "one heavyweight service" support "many
lightweight services" is a mixing of two different domains.  What you
mean is that many abstract, Web or Grid Services may map onto one
concrete, tooling-specific implementation component that does traffic
demultiplexing based on the binding-specific encoding of the abstract
service name in order to determine its behavior.  How that
implementation organizes itself in order to achieve this
demultiplexing is completely outside the scope of the standards
discussions.


> Pete

karl