[graap-wg] condition expression language requirements for WS-Agreement

[Anne Anderson]

Karl,

Thank you very much for pointing out the RangeValue_Type in the Job
Submission Description Language (JSDL), which I had overlooked in my
earlier reading of WS-Agreement.  This is exactly the type of mechanism
on which automated intersection/agreement can be based.  RangeValue_Type
handles numeric types; also needed, however, are SetValue_Type types for
IP address subnets, regular expressions over strings, and a few other
basic types used in service agreements, along with Boolean operators for
combining range or exact-value constraints.  The simple condition
language in the WS-Agreement "Preference Example" is an example of such
Boolean operators.

So many of the pieces exist.  If they can be pulled together into a
"condition expression language" that could be referenced, it would go
far toward allowing automated agreement, and would improve
interoperability.  The variables used in such expressions will be
domain-dependent, but if the condition expressions over their values use
a standard condition expression language, then implementations of
WS-Agreement can be smaller (supporting fewer mechanisms), more easily
testable (no domain-specific tests of comdition expression
intersection/agreement), and more interoperable.  Agreements can be more
easily computed by brokers or other 3rd parties that may not have or
need the domain-specific code associated with the variables themselves:
this seems like an important consideration for Grid environments.
Interoperability may not be a goal, but if an implementation of
WS-Agreement will be used with more than one other partner, with more
than one other condition expression language, being able to reduce the
number of mechanisms that need to be supported is at least a valuable
objective.

For the current draft, if you are really intending to address the
condition expression language in a meaningful way in the next version,
how about removing the suggestions that XQuery might be an appropriate
condition expression language.  XQuery is great for what it was designed
to do: express query constraints.  But it was not designed for nor is it
suitable for expressing agreement constraints.  There are no
intersection/agreement mechanisms defined for XQuery expressions in
general, and intersection/agreement is undefinable in many cases.

This would involve removing the statement that "An example of a generic
assertion language can be found in [XQUERYX]." in section "4.2.6.2
Qualifying Condition and Service Level Objective" and the statement that
"A general purpose constraint language has been proposed as part of the
XQuery and XPATH language. The XML rendering of this expression
language, XQueryX, MAY contain a suitable constraint language that can
be used to phrase constraints involving multiple items." in section
"5.1.2 Free–form Constraints", along with the subsequent
"wsag:XQueryXConstraint" extension of "<wsag:Constraint/>".

Please understand, I am not objecting to XQuery itself, but only to
suggestions that it may be an appropriate constraint language where
agreement semantics are needed.  Few WS-Agreement users will understand
the real implications of the choice of condition expression language
until they have invested significant time and effort into implementation
and use.  At least don't lead them down the wrong path while you wait
for an appropriate path to appear.

Regards,
Anne

Karl Czajkowski wrote On 02/08/06 10:06,:
> On Feb 08, Anne Anderson modulated:
> 
>>WS-Agreement is supposed to be "a Web Services protocol for establishing
>>agreement between two parties".  Unless there are defined mechanisms for
>>reaching agreement on the contents of a WS-Agreement specification, I
>>don't believe WS-Agreement has met its primary goal.
>>
> 
> 
> I think I understand your point, and unfortunately this is an area
> that has not been documented very well.  Aside from your assertion
> below, I think most of us have considered this a non-normative
> documentation issue that should be captured in a "primer" document.
> 
> In a nutshell, the expected "agreement handshake" really starts with
> the initiator consuming the advertised template(s) from a responder.
> The first decision then is the initiator deciding whether the
> responder accepts an agreement format that is acceptable to the
> initiator. If so, he may proceed with formulating an agreement and
> making an offer.  If not, he has to go back to discovery.
> 
> The second decision is whether the responder understands an offer and
> wants to accept it.  This of course requires being able to extract the
> semantic content of the offer in some form such that the responder's
> policies can be evaluated to determine whether to accept or reject.
> 
> 
> 
>>Particularly in the area of condition expression languages, there has
>>been little successful work on feasible intersection/agreement
>>mechanisms other than the work done in the field of "narrowing
>>algorithms".  For example, there is intersection/agreement between two
>>general XQuery expressions is undefined.  There is a comment suggesting
>>that the condition expression language/dialect be completely at the
>>discretion of the WS-Agreement instance originator, which will make this
>>problem even harder unless there is a corresponding requirement that two
>>parties must either agree on the dialect used (and that it have a
>>feasible intersection/agreement mechanism) or that there must be a
>>defined intersection/agreement mechanism between the two dialects.
>>
> 
> 
> You are assuming, perhaps, that a general WS-Agreement implementation
> will exist that computes intersections without domain-specific
> knowledge.  While I think this would be interesting, I think many
> participants have set a lesser goal of being able to implement
> domain-specific WS-Agreement implementations which can interoperate
> according to a "profile" specification.  There are two reasons this is
> worth pointing out:
> 
>   1) the profile may define the specific intersection model that is
>      appropriate for the domain
> 
>   2) the profile may define additional discovery content to simplify
>      discovery of "interoperable profile implementations"
> 
> You might be pleased if you were to look into the JSDL job example in
> the specification.  I think you will find that the "range value" type
> in the JSDL language has very simple intersection semantics which can
> allow narrowing between the template, offer, and responder operating
> policies to determine a match.
> 
> 
> 
>>I recommend inserting a requirement that any language/dialect specified
>>for WS-Agreement condition expressions must have a referenceable
>>specification for computing intersection or agreement between any two
>>expressions in the language/dialect.  Unless this is done, WS-Agreement
>>will not meet its goals and will not be interoperable.
>>
> 
> 
> I don't have a problem with inserting a "SHOULD" statement about this,
> but I think I disagree about the consequence of not having it.  I do
> not think there is a necessary interoperability between all
> WS-Agreement implementations, but merely between implementations which
> follow profiles where the conditional languages are normatively
> defined.
> 
> I would be interested to hear others' opinions on this...
> 
> 
> karl
> 

-- 
Anne H. Anderson             Email: Anne.Anderson at Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692