I agree with Donal's assessment. Particularly, GRAM is very much a
container interface in my view. If and what interface(s) are provided
by the job code itself are totally outside the scope of GRAM. The fact
that we rendered individual "job" resources is a result of our
WSRF-style rendering of the container state for a slight abstraction
of POSIX/HPC jobs: each "job" is a logical container that corresponds
to one submission relationship and its delivery status. As I have
explained, I think this relationship and the logical container is our
best point of interop regarding the semantics of the larger scope
container or "managed execution pool". The more you try to talk about
the global state of the container, the more you run into differences
in local scheduling strategies, authorization policies, etc. By the
way, this submission relationship is precisely what we would be
representing as agreements if we were to provide a JSDL+WS-Agreement
rendering of BES.
As I tried to advocate at the BES BOF in Seoul and later on telecons,
I think the right approach is to always have a container interface and
then have a completely separate notion of the job (application)
service endpoints if appropriate. At most, I think a BES container
could represent a rendezvous point or "mini registry" where some
applications MAY want to publish their other contact information for
the sake of bootstrapping distributed application environments. In
other cases, information will be threaded through the submission
language and/or job code itself to go off and join the "application
registry in the sky"... This discussion is orthogonal to the
discussion of rendering styles for the container state(s).
Personally, I am disappointed that the BES discussions seem mired in
this rendering-style discussion, because it is certainly not specific
nor even particularly related to execution management. If OGSA does
not find a path forward, I think there is little hope of getting
consensus in all the different activities where it matters: specific
concrete renderings of functionality that can be used to get better
interoperability between Grid software products. The community really
does not need more abstract standards or "patterns"... it needs
concrete message formats that can support interoperability now and as
the overall Grid environment continues to evolve.
karl
On May 26, Donal K. Fellows loaded a tape reading:
> Hiro Kishimoto wrote:
> >- We think MJFS corresponds to container instead of Job Manager.
> >- MJFS and others cover most of "container" interface but not all.
> >For example, BES-WG will define check-pointing interface which
> >is not supported by GRAM.
> >- GRAM covers "job" interface, which is out of BES-WG's scope.
>
> That's funny, because that does not meet my recollection of the
> discussion in the BES f2f. Instead, I believe that we agreed that the
> definition of a common base set of activity port types was going to be
> probably impossible. There seemed to be substantial agreement that the
> definition of job managability interfaces for "POSIX activities" (i.e.
> those derived from a JSDL POSIXApplication) was both worthwhile and
> in-scope. OK, I may have misinterpreted what was said, but that was
> definitely my impression.
>
> I'd also equivocate over checkpointing somewhat, as I got the impression
> that that was an example of something that people felt to be part of an
> "Advanced Execution Service" (we were seeking to distinguish between
> Basic and Advanced at the time).
>
> Donal Fellows.
--
Karl Czajkowski
karlcz(a)univa.com
