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@ggf.org
[mailto:owner-ogsa-wg@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