[ogsa-wg] Basic EM BOF: Issues

[Ian Foster]

Dear All:

Steven suggested that we raise issues on the list ahead of the BEM BOF, so 
I'll take the bull by the horns and make a few comments about the largish 
"elephant in the room" that we seem to be ignoring.

OGSA WG has identified a few basic patterns that seem to arise frequently 
in distributed system management, at least, and apparently elsewhere too, 
and has proposed to use some conventional encodings of those patterns. 
E.g., it has proposed to use:

a) EPRs as names for things

b) portTypes defined in WS-ResourceLifetime for lifetime management 
(explicit and lease-based destruction)

c) portTypes defined in WS-ResourceProperties for access to state/status 
information

d) portTypes defined in WS-Notification for subscription.

The Grimshaw/Newhouse proposal involves at least the first three of these 
patterns, but uses a different conventional encoding for each of them, 
i.e., it proposes to use abstract names plus context-ids to name things, 
and it introduces new portTypes for lifetime management and subscription.

Thus, the elephant: what do we do about this? Does this make the proposed 
design non-OGSA-compliant? Does it mean that we are going to abandon 
attempts at common mechanisms for common things? Is this an implicit 
suggestion that we should be dropping those conventions in OGSA?

We addresses exactly these questions at the last F2F, and agreed (I 
thought) that we *did* want to build on our previously agreed conventional 
encodings of standard patterns. However, it seems that the issue is being 
put back on the table. I think we need to resolve this before we move forward.

I'll mention again that the GT4 GRAM design, which I circulated a few weeks 
ago, provides a complete job management interface based on the OGSA 
conventions. I'd like to suggest that people study this ahead of the 
meeting, as it shows how simple a rendering of BES functionality can be 
achieved based on WSRF/WSN conventions for state access, etc.

Regards -- Ian.


At 08:59 AM 3/8/2005 +0000, Dave Berry wrote:
>I thought this was what Andrew meant.  Anyway, it is important that
>people taking part in the new WG realise that they are constrained by
>decisions made in the overall group.  They can of course raise issues to
>be decided in the overall group, with the BEM service(s) as examples of
>why the issues are important.  But we don't want to end up in a
>situation where (say) DAIS implements the "multiple arguments" pattern
>one way and OGSA-BEM implements it a different way.
>
>Dave.
>
> > -----Original Message-----
> > From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
> > Behalf Of David Snelling
> >
> > I would agree with Ian here based on our agreement at the Washington
> > F2F. There we agreed the our ptofiles would be consistent with the
> > architecture. I believe this should also apply to these spawned WGs.
> > Technically however, the forming WG could charter its self to be
> > constrained to the current EMS model. I would prefer that charter
> > support the same "invariant" model we use for profiles. This would
> > allow the EMS model to be modified in light of lessons learned in the
> > new WG.

_______________________________________________________________
Ian Foster                    www.mcs.anl.gov/~foster
Math & Computer Science Div.  Dept of Computer Science
Argonne National Laboratory   The University of Chicago
Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
Tel: 630 252 4619             Fax: 630 252 1997
         Globus Alliance, www.globus.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050308/057f334a/attachment.html