[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