Wow! I thought we'd discussed this ad nauseum in GRAAP face-to-faces, so I neglected to mention it. I see GRAM as being obsolete once WS-Agreement is available to form agreements bearing JSDL terms. The only bits of GRAM that might need to remain are some extended operations or RPs on the Agreement itself. karl On Mar 21, Jon MacLaren loaded a tape reading: ...
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.
-- Karl Czajkowski karlcz@univa.com