[graap-wg] Telecon on 3/21
Jon MacLaren
maclaren at cct.lsu.edu
Mon Mar 21 09:30:31 CST 2005
On Mar 21, 2005, at 5:49 AM, Karl Czajkowski wrote:
> On Mar 21, Toshiyuki Nakata loaded a tape reading:
> ...
>> 1)If you loook at the two layered picture of Agreeement Services and
>> the
>> lower level, Real services (Such as Job submission etc), My
>> understanding is BES has to deal with the Serive layer beneath the
>> Agreement Factory layer.
>>
>
> I am not 100% certain that I understood your comment after this one,
> because I want to read it as stating something close to what I think I
> have been saying, but as I said at the BES BoF, this "Agreement + job
> submission" view is a misunderstanding of WS-Agreement's service
> abstraction. "Job submission" is not the service layer we would
> envision beneath the Agreement management layer, because the
> submission pattern is exactly what WS-Agreement is meant to address.
>
> Specifically, agreements about "generic execution jobs" or "specific
> kinds of job" are what we intended the basic agreement creation
> pattern to handle. Creation==submission. It is hard to express this
> without using the word agreement in a circular manner, but we took
> GRAM/GARA and said, "these are agreements about jobs or reservations"
> and tried to generalize it just a bit. These generalizations, while
> important, are not very intuitive for people to grasp; if they were,
> the GRAM and GARA systems would probably have started off more
> general. ;-)
Are you saying that agreement creation is equivalent to job submission?
(More comments below)
> WS-Agreement, through the GRAAP-WG charter, was scoped from the very
> beginning to address the "submission" part in its management model;
> our two explicit example use cases were job submission and advance
> reservation for jobs! That's the domain area brought in by the
> founding participants.
The GRAAP-WG charter does not address job submission. It addresses
resource allocation. We used advance reservation for computational
jobs as a use case. However, we make clear that the claiming of the
resources, i.e. the job submission part of that use case, is not
something that the GRAAP-WG would address.
> This is why I frame this as a misunderstanding/public relations
> problem. There are not open questions for how WS-Agreement SHOULD
> handle jobs except that we haven't publicized the the answers well
> enough. :-)
I can understand that the decoupling of the resource allocation from
the job submission is only one architectural viewpoint. In private
discussions that I've had with non-GGF participants, they have wanted
to view the resource allocation, job submission, and job execution as a
single "business transaction". That's a completely valid viewpoint.
However, it is different from the one described in the charter, where
we view these as separate concerns.
Perhaps this is where people's misconceptions come from.
Perhaps you could clarify exactly where you view a GRAM-type protocol
fitting in with WS-Agreement? Perhaps some sort of sequence diagram.
Do you envisage the user have a separate interaction with GRAM to
create/submit/launch the underlying computational job?
Jon.
More information about the graap-wg
mailing list