Hi Lee, comments in-line.
I mentioned this at the interim but only briefly. It seems
to me that we're getting our service binding times wrong. This may be an
artifact of my confusion over whether we're discussing the Admin Service
(AS) or the Transit Intermediary (TI) when we discuss rules.
In the architecture to-date, we say that the XML form of the
rules are used both between the rule "owners" and the AS and between the
AS
and TI. In the actions, we bind to a specific instance of code.
I believe this early binding is completely inappropriate for
at least some of the rule owners who more than likely have no need nor
desire to know about the decisions made in a CDN regarding function
distribution. It is more reasonable, I think, but still undesirable for
the TI rule base to have these bindings specified in the rules.
The rule owner doesn't know/care about the binding. Binding is done at
the AS, the OPES entry point by the box(ex) operator. Service plug-in
will run on the local host. I assume that if they need to be a remote
service they'll instead become a callout service on ICAP/BEEP.
IMHO, there's entirely too much discussion about requirements for APIs
(this is the IETF after all) but it seems that there's one late binding
semantic that's needed in the architecture model: resolving a service name
to its location and making the appropriate call to the service (i.e., over
a protocol, e.g., ICAP or BEEP, or a local call to an x-let or library
service).
One of the principle benefits of policies in a network environment is
their
scalability; you loose that scalability when you bind too early.
BTW, this late binding argues for at least having a set of
semantics defined for use on the OPES platform if not a real API.
I'm reading an important requirement here. Supporting late or dynamic
binding
would allow among other things to take advantage of load balancing.
Christian