Job Template vs. Job Instance Options
I was enlightened today on the telecon to the opinions of those of you who see a clear distinction between the activity template (JSDL) and activity instance options. I'm fine with that, although thinking about this I realize that we need extensibility, then, also in the CreateActivity operation. As a specific example, GRAM needs to access delegated credentials. Security requirements are out of scope of the OGSA-BES spec, but EPRs pointing to credentials clearly are in the activity instance category rather than the activity template category. The only way not to violate the above philosophy is to add an xsd:any (minOccurs="0" maxOccurs="unbounded" namespace="##other") to the parameter list of CreateActivity. Putting these extensions in the JSDL document isn't appropriate. This could also be a better solution for things like the subscription request and the CreateInSuspendedState parameters. They would essentially be out of scope of the spec, but not forbidden. I think that would appease those who don't like it specified in the spec given that not all implementations will want to have that feature or the exact same feature. Peter
Hi; Yes, this is how I see things as well. Extensibility means that CreateActivity must be able to include an extensible set of parameters. The details of whether these are extensions to the interface WSDL or extensions to one or more infosets that represents the parameters of CreateActivity is to be determined. But the key idea is that a simple, basic version of CreateActivity can be defined in the spec and that we have a clean way to add optional extensions to the functionality of CreateActivity, such as delegated credentials, subscription requests, create-in-suspended-state, etc. Marvin. -----Original Message----- From: owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Peter G. Lane Sent: Thursday, June 29, 2006 10:37 AM To: ogsa-bes-wg@ggf.org Subject: [ogsa-bes-wg] Job Template vs. Job Instance Options I was enlightened today on the telecon to the opinions of those of you who see a clear distinction between the activity template (JSDL) and activity instance options. I'm fine with that, although thinking about this I realize that we need extensibility, then, also in the CreateActivity operation. As a specific example, GRAM needs to access delegated credentials. Security requirements are out of scope of the OGSA-BES spec, but EPRs pointing to credentials clearly are in the activity instance category rather than the activity template category. The only way not to violate the above philosophy is to add an xsd:any (minOccurs="0" maxOccurs="unbounded" namespace="##other") to the parameter list of CreateActivity. Putting these extensions in the JSDL document isn't appropriate. This could also be a better solution for things like the subscription request and the CreateInSuspendedState parameters. They would essentially be out of scope of the spec, but not forbidden. I think that would appease those who don't like it specified in the spec given that not all implementations will want to have that feature or the exact same feature. Peter
participants (2)
-
Marvin Theimer -
Peter G. Lane