[ogsa-wg] Paper proposing "evolutionary vertical design efforts"

[Dave Berry]

Steve,

I don't want to have "exciting" GGFs; I just want meetings where we can
get some work done.  Several developments at GGF16 seemed to be pushing
us along, with practical, focussed work on standards & interoperation.
The Grid Interoperation Now sessions are one such. The proposal for an
OGSA-HPC design is another.  I like focussed, incremental steps like
these that start from where people are now.

Best wishes,

Dave.



-----Original Message-----
From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
Steve Loughran
Sent: 20 February 2006 15:09
To: Marvin Theimer
Cc: ogsa-wg at ggf.org; Savas Parastatidis; Tony Hey; Marty Humphrey;
gcf at grids.ucs.indiana.edu
Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design
efforts"

Marvin Theimer wrote:
> Enclosed is a paper that advocates an additional set of activities 
> that the authors believe that the OGSA working groups should engage
in.
> 

Marv -could you also send out the slides that we saw at the F2F; not
everyone on the mail list will have seen them.
>  
> 
> Broadly speaking, the OGSA and related working groups are already 
> doing a bunch of important things:
> 
> *         There is broad exploration of the big picture, including 
> enumeration of use cases, taxonomy of areas, identification of 
> research issues, etc.
> 
> *         There is work going on in each of the horizontal areas that 
> have been identified, such as EMS, data services, etc.
> 
> *         There is working going around individual specifications,
such 
> as BES, JSDL, etc.
> 
>  
> 
> Given that individual specifications are beginning to come to 
> fruition, the authors believe it is time to also start defining 
> "vertical profiles" that precisely describe how groups of individual 
> specifications should be employed to implement specific use cases in 
> an interoperable manner.  The authors also believe that the process of

> defining these profiles offers an opportunity to "close the design
loop"
> by relating the various on-going protocol and standards efforts back 
> to the use cases in a very concrete manner.  This provides an 
> end-to-end setting in which to identify holes and issues that might 
> require additional protocols and/or (incremental) changes to existing 
> protocols.  The paper introduces both the general notion of doing 
> focused vertical "design efforts" and then focuses on a specific 
> vertical design effort, namely a minimal HPC design.
> 
>  
> 
> The paper derives a specific HPC design in a "first principles" manner

> since the authors believe that this increases the chances of 
> identifying issues.  As a consequence, existing specifications and the

> activities of existing working groups are not mentioned and this paper

> is not an attempt to actually define a specifications profile.  Also, 
> the absence of references to existing work is not meant to imply that 
> such work is in any way irrelevant or inappropriate.  The paper should

> be viewed as a first abstract attempt to propose a new kind of
activity within OGSA.
> The expectation is that future open discussions and publications will 
> explore the concrete details of such a proposal.
> 
>  
> 
> This paper was recently sent to a few key individuals in order to get 
> feedback from them before submitting it to the wider GGF community.
> Unfortunately that process took longer than intended and some members 
> of the community may have already seen a copy of the paper without 
> knowing the context within it was written.  This email should 
> hopefully dispel any misconceptions that may have occurred.
> 

I don't know whether it was good or bad that the paper didnt surface
till after the main GGF was over; I think it could have been a more
exciting conference if we had this paper to talk about all week.

Regarding the contents, pragmatic and evolutionary are a good way of
learning what works, though hill-climbing solutions are always a risk. I
do worry about the use of "non-contentious" technologies, because I'd
like to see a mention of "stable and broadly implemented" in there too. 
There are many specs beginning with WS- that, while non contentious, are
too unstable to make the underpinnings of anything 'strategic'. I will
not name the guilty here; there are too many to choose from.

One thing that worries me as someone in a downstream group is this new
trend for parallel profiles, the WSDM and the other one. This is not
sustainable. Not only does it double the engineering costs of the
standards group (double the profiles, tests, docs...), if you split the
set of possible interoperable nodes in two, the value of each partition
network is reduced to a quarter of that possible, as Metcalfe's law
kicks in on the fractions. That was the Corba mistake: not caring enough
about interop on the wire.

-Steve