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