[ogsa-rss-wg] RE: [ogsa-wg] Teleconference minutes - 2 November 2005

[Karl Czajkowski]

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 at univa.com