
Guys, my view basically matches Karls view. To me, the consequence would be to refactor out the User section to an embracing document, which then maps User credentials to particular elements in the JSDL document (hence the ability to construct QNames referring to elements in a JSDL document). Referring to Karls other mail concerning Execution(User|Group), these would consequently permeate to the POSIXApplication element I think. Cheers, Michel N.B.: Ali, I didn't check, but did you already upload the conf minutes to Gridforge? On 30 Mar 2005, at 10:00, Ali Anjomshoaa wrote:
Many thanks for this Karl. It is very clear. Any other thoughts on this? Donal, Michel, Darren...?
Thanks in advance,
Ali
On Wed, 30 Mar 2005, Karl Czajkowski wrote:
I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps.
I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers).
For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP).
We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa.
karl
-- Karl Czajkowski karlcz@univa.com
--
---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------