On Dec 12, Donal K. Fellows modulated: ...
At the moment, I thinking about the abstract output of the RSS services as ordered sets of candidate execution plans, probably encapsulated within WS-Agreement Templates. The ground elements of the plans (or at least those parts that relate to computational activity, of course) will likely be JSDL documents suitable for submission to BES containers. When it comes to data stuff, I don't understand the requirements well enough to say much, but I believe that the suggested outer structure (ordered set of agreement templates) will extend to that sort of thing nicely; it is just the leaves of such a tree that I don't understand.
By ordered, you mean the ranking/preference order of the client? That's a pretty interesting use of WS-Agreement templates! I'm not sure what others will think, but I kind of like it. It starts to lead down the path of negotiation services with a well-defined non-obligating semantics. In some sense, it opens the possibility of getting personalized templates, instead of just the generic ones that are exposed via the template resource property of the WS-Agreement factory service... however, meaningful use of WS-Agreement would then need a follow-up CreateAgreement to actually choose one of the templates. This could be totally appropriate with a broker, where the broker then goes off and makes "recursive" agreements with remote resource managers before accepting the client's specific agreement offer. It starts to get a bit weird to use WS-Agreement template syntax if the selection step is not an agreement offer back to the same party who issued the template(s). ...
If we have parameterisation, then the question arises of how expressive a language we need to specify the parameterisation. Do we need a general-purpose programming language (e.g. Python script) or will the draft WS-Agreement language be sufficient?
As far as I can see from reading the version that went out to public comment, WS-Agreement currently just punts on this issue. I'm hoping that it will be possible to avoid putting a general programming language expression though; it's remarkably hard to secure such things, and mandating one language over another (necessary for interoperability) would trigger a lot of arguments.
WS-Agreement is silent on the domain-specific parameterization of a service (we expect JSDL would be appropriate for executable job parameterization), but it does provide a "business value" model to express how a particular service parameter may be more or less preferable at runtime. You might be able to use this to express an "abstract" job and then assign different values to different concretizations of the job. The underlying metalanguage is sound, involving: 1. preference tuple structure to associate a metric, value for metric, and relative preference for different values 2. a way to associate "free variables" in the metric expression with domain-specific service parameters 3. an extensibility escape to use specialized metric expression languages 4. a simple concrete metric language that may be used in the absence of more specialized domain languages However, because the first version of WS-Agreement scopes away negotation, the business values model is really to parameterize parameters which may vary during the delivery of service. It does not have something to specifically parameterize "agreement time" decision preferences. (The WS-Agreement decision is simple yes/no rather than any selection choices.) If you are defining your own "template generating" protocol, I imagine you have the freedom to reuse the business value model to parameterize the choices for templates, where each template will have one fixed parameterization from the available pre-template choices. I think GRAAP-WG would definitely appreciate feedback as to the expressivity of the "business values" model. If you were to have agreements with JSDL embedded in service terms, and you wanted to qualify certain JSDL element contents with ordering preferences to distinguish resources, do you think the business values metalanguage could express the ordering? I know this is a bit vague, since you have to imagine a non-WS-Agreement protocol to push in a "pre-template offer" and get back the templates you describe, but I have a suspicion that this does not really impact the metalanguage requirements at all... I'm sure the graap-wg mailing list would welcome further exploratory discussion here if you are interested. karl -- Karl Czajkowski karlcz@univa.com