Dave, I think the interesting point of collision with "candidate set generation" and "planning", e.g. traditional scheduling, is when you consider non-trivial QoS regimes. For example, when services do not give best effort service to all callers, and you cannot just assume statistical averaging to predict future service based on past, etc. Then, there is a significant difference between a scheduler or broker who returns advisory information and one who returns authoritative information. In the advisory case, he is essentially a discovery service helping you locate services with nice properties observed in the usefully recent past. However, until you act on that information by attempting to acquire service, you have no idea whether the service is actually nice or not for your goals. He may be suddenly congested, or have differentiated policies which make your request impossible to fullfill despite his overall nice status. In the authoritative case, the scheduler actually has some control over those remote services, i.e. (part of) their capacity is reserved to be used at his discretion. In this case, he can actually determined when and how much service you should obtain, and inform you of a stateful adjustment to his overall resource plans that includes you. There might be protocol differences to support these cases, e.g. an authoritative answer might carry some rights assertion that you can present to the service, or the broker may have to go update remote services behind the scenes but before you manage to contact them. Also, the authoritative broker may demand that you "decline" allocations he has issued you, while you can presumably walk away from an advisory information source since no stateful allocation has been made. I do think you are on the right track to call a ranking function "policy", and in non-trivial scheduling regimes I think you will always have to present such policy rather than being able to obtain a sufficient picture of the environment to make decisions yourself. This is because of several things: 1. You will not get an atomically consistent view of the environment to act on, while the remote manager may have such a mechanism. 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. 3. You will not get a complete picture of the differentiated polcicies that different brokers or services apply to specific individuals, because it may be confidential and is also meaningless without a global view of other competing activities. Thus, I think a significant step of ANY distributed planning exercise with non-trivial QoS will be the sort of handshake captured in WS-Agreement: make an "offer" bearing policy expressions that describe what you want; allow the authoritative resource manager to consider this offer among others and its stateful policy and resource availability models; obtain an answer of whether the manager can arrange services according to your offer; and (optionally) introspect to find out HOW the manager will provide you service. All interface "refactorings" are not equivalent across protocol boundaries between parties with different authority and trust roles... (More specific comments inline.) On Dec 10, Dave Berry modulated: ...
One factor that influences this choice might be who has the access to the necessary information. If the client has privileged information that should not be made public, then the choice might have to be made by the client; or the framework should encrypt the policy parameter and provide a trust relationship with the selection service. Conversely, the client may want to see only an abstraction of the detailed selection process.
Right, I think it is critically important to find out the nature of the roles here before trying to design a protocol.
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?
The replies I received suggested both that the parameterisation would require a general programming language and that the client may have privileged knowledge that it does not wish to share, and therefore it would be better to leave decisions to the client. I'm rather sceptical of the first point but it would be good to examine real systems to determine what is really needed.
Just a reminder: one often-discussed "trick" for handling such isolation of data and abstraction is to allow delegation of resource management authority. An explicit advance reservation interface can abstract away the application goals (and confidential information) to describe required capabilities. The remote manager can schedule and allocate a solution to these without understanding the application, policy permitting. The result of the reservation is a new "virtual resource" and a policy giving the client-side manager authority over it. Then, the client-side logic can perform the fine-grained planning of that resource capability for its specific application functions, revealing only the minimum operational information.
There are clearly many possible answers in this space - which brings us back to Ian's list of schedulers. One question might be whether we can identify an interface, or a small number of interfaces, that generalises a significant number of practical use cases.
Best wishes,
Dave.
karl -- Karl Czajkowski karlcz@univa.com