Hi Karl, Very interesthing thoughts. Just some quick comments below. Karl Czajkowski wrote:
Well, my practical view, keeping in mind bounded-rationality systems, is that if the template was insufficient to guide you to an acceptable agreement offer, then a "hint" would not fair any better. Either the advertiser announces its policies/restrictions in detail sufficient to create an agreement, or it does not. Why would it reveal more information on the next iteration? If you're trying to address intelligent parties who do bluffing and bartering, then your problem is out of scope for WS-Agreement...
It is certainly possible that the detail contained in a template may increase in complexity as interaction between parties proceeds. For instance, one could consider a coarse-grained advertisement that identifies the types of capability that a provider offers, and not necessarily the ranges associated with those capabilities. The hint would then be a subsequent refinement of these capabilities in future interations. Yes, therefore there could be revelation of additional information in subsequent interactions.
Another intractable problem is that the resource manager making the decision may not even be able to formulate a specific reason for "why it didn't match", e.g. in a scheduler that is matching many properties at once against a dynamic load of competing requests, it is not necessarily easy to determine what would need to change to make a request get handled above other requests. Furthermore, it would have race conditions since the dynamic load may be different by the time the next offer arrives.
Yes, agree about the matching problem. However, it is possible to rank matches (or mis-matches) using some "match distance" metric. This can range from a associating as weight with attributes that are of most significance to a particular party -- say, I am more interested in having a certain disk space rather than a specific processor speed. The way to deal with dynamic load -- as often undertaken in other performance prediction efforts -- is to deal with summary and aggregate data -- rather than raw data. Hence, one would base a prediction on average (or some other time-based aggregate statistic) rather than the value at a particular point in time.
So I think in practice, an automated WS-Agreement initiator is going to operate with some narrowly-defined commodity offers and try fallback, retry, and fail-over among responders. If this fails, offline analysis and problem determination will be required to understand what went wrong, and how to improve templates and offering systems to avoid these doomed offers.
Yes, agree with this. In the abscence of well defined constraints, I can see a lot of problems with the approach. There are some automated approaches that can help with doing some of the post-failure analysis. regards Omer -- http://www.cs.cf.ac.uk/User/O.F.Rana/index.html / work-fax:+44(0)29-2087-4598 work:+44(0)29-2087-5542 / other:+44(0)7956-299981 / distributed collaborative computing / room n2.14 / school of computer science / cardiff university queen's buildings / newport road / cardiff cf24 3aa / wales / uk