Re: clearinghouses (or not)

Orca doesn't really view these strategies as necessarily competing,
since it effectively separates "management" into two functions:
allocation and control.   So using your words:

User **controls** (resources from) multiple Aggregates (SM
functionality runs on the client and user **control** requests go
directly to the aggregates)

Clearinghouse **allocates** (resources from) multiple Aggregates (SM
functionality runs on the server with all user **allocation** requests
funneled through the SM)

So the SM functionality that does control resides with the user, while
the SM functionality that does allocation resides with the
Clearinghouse.

That said, we often compose users, clearinghouses, and AMs together to
produce similar divisions of function as you propose for your SM.  To
do the first approach, we have each aggregate manager run its own
personal clearinghouse, so it incorporates all the Clearinghouse
authorization functions (this is how we often run Orca in practice).
To do the second approach,  a single Clearinghouse allocates resources
from multiple AMs (this is our approach in Cluster D) that the user
then controls.   In both cases, we assume some persistent server runs
under the auspices of the user (whether on the desktop or a remote
server), so it can receive asynchronous callbacks/notifications from
the Clearinghouse and/or AM about its resources.

So from an architectural standpoint, I view this as maybe a false
choice between two extremes in a spectrum of possibilities.  However,
from an implementation standpoint, I agree with Rob, in that your
first choice is probably best.  Despite our focus on Clearinghouses
managing multiple AMs, this was a first step in our development and
remains in practice a useful way to organize our system (especially
when coordinated allocation of resources across aggregates is not
necessary).

-David

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg