On Dec 12, Donal K. Fellows modulated: ...
I don't see a major difference, or at least, not until you start having nailed-down reservations attached. Without any committed reservations, a candidate execution plan is indistinguishable in the case of it being issued by an advisory or an authoritative broker. Furthermore, it was agreed at the last GGF that neither of the RSS services would cause any reservations to be entered into. By that, I mean that no consumption of resources would start that could be charged to the user; systems are
OK, it sounds like you are clearly scoped to have "advisory" brokers, with my definition of authoritative meaning that the selection response is "what will be allowed", e.g. an obligating decision. :-) BTW, I was responding to how I read Dave's inquiry about generalizing the problem, and not specifically to scoping of RSS...
The other point is that there is no way to stop a resource from going away unexpectedly or a client from failing to consume its allocation. The resource might get hit by a disaster (natural or man-made), the client might die, etc. But this isn't a new problem; it occurs in the world of business every day and they deal with it. We should learn from them (e.g. by describing the consequences of such failures in terms of finanicial penalties) and not reinvent this particular wheel.
Yes, I entirely agree. I guess it is out of scope though, if the RSS result is just a list of candidates rather than some obligation of service. Filtering and ordering should be sufficient, rather than the added difficulty of precise monetized (linear) values.
2. You will most likely not get a complete picture of the future service allocation plans, in the event of advance reservation. It would be too much data to exchange for each request; it might include confidential information; and it might not be clearly separable from the scheduling algorithm that might include statistical approximations and/or other hueristics.
At the University of Manchester we're looking into these things in more detail. At the moment, it looks like the brokering world is going to be categorizable into multiple types of service depending on the quality of information available. This work is still actively ongoing though, so it is a bit too soon to report on it.
Right; as I was trying to describe in response to Dave's question, I think the boundaries of what is to be accomplished must be set pretty specifically, because different protocols will be appropriate depending on the kind of information that can be revealed (and the sizes of the various data for realistic environments).
All interface "refactorings" are not equivalent across protocol boundaries between parties with different authority and trust roles...
True, but I'm not at all convinced that WS-Ag is quite in the sweet spot either. It would help a lot if it was easier to tackle the document parts of the spec separately from the service parts because at the moment, the sheer size of the overall spec and the feeling that you have to read virtually all of it to understand it[*] is scareing some people off.
Donal. [* FWIW, I found I had to read not just the spec but also some of the presentations about it too to understand what was going on. To me, that indicates that the spec document itself has not yet captured all that you intend it to. ]
Yes, public comments have said as much... the problem area is pretty large, unfortunately, and GRAAP-WG is trying to trim the spec down to the basic normative aspects. The group also plans to develop a sort of primer to provide more useful non-normative introduction to the approach. (This was decided because earlier feedback indicated the specification was too large to digest for people looking for all the normative bits.) The difficulty is that the core abstraction of agreement-about-service is pretty abstract stuff, and the domain-specific examples that can help illustrate it are definitely non-normative to the base spec. In an ideal world, we could present some fully-developed profiles of WS-Agreement with specific service/resource management domains to illustrate the base model. In practice, I think we need to get a "version 1" out there so that domain profiles can be developed and usage experience gathered to inform further versions of WS-Agreement. karl -- Karl Czajkowski karlcz@univa.com