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@univa.com