At the Feb OPES workshop in New York, I brought up some parallels between
the structure of OPES Intermediate Rule Markup Language (IRML, formerly
PSRL) and the Portable Channel Representation (PCR). I have been working on
PCR for a couple of years in the context of the Internet2 Distributed
Storage Infrastructure (I2-DSI), an academic Edge Services project that
predates the industry term "Content Delivery Network." An edge services
system based on PCR has been implemented by a Swedish company, Lokomo
Systems, that was founded by particpants in the I2-DSI project, myself
included.
A paper on PCR entitled "Implementing Full Service Surrogates using the
Portable Channel Represenation" will appear in WWW10 this May, but we are
making a draft available online for the benefit of participants in the OPES
list at
http://www.cs.utk.edu/~tmoore/docs/surrogates_draft.pdf
PCR was presented at the first OPES workshop in San Jose and mentioned
briefly at the OPES BOF in San Diego, but the relationship between OPES and
PCR was not immediately clear to many people. The recent discussion at the
OPES workshop in NYC made things clearer to me. In this note, I will
attempt
to explain just where the two are similar and different in intent and in
structure.
1) What is PCR?
PCR is a framework for managing code that runs on edge servers in
response to requests from end users. The particular code to run in response
to
a given request is determined by a set of rules that match on the protocol
and
fields in the request header. The rules are organized into channels, and
these are
described in an XML/RDF-encoded language known as PCR (Portable Channel
Representation).
2) How is PCR different from OPES?
The code that PCR manages is intended to be server-resident content and
servelets. In practical terms, this means a few things:
i. Only one rule can fire in response to a single request. This simplifies
the rule language and obviates the need for a rule ordering policy and
mechanism.
ii. Servelets are thought of as having access to server resources and not
having access to proxy resources. However, this is all a matter of the
servelet/proxylet API.
3) PCR rules come from a single source, the "Channel Publisher" whereas OPES
rules come from three sources: the content provider, the ISP and the end
user. How do these models relate?
The OPES model includes an Admin Server that is responsible for combining
rules from different sources and transfering a single, unambiguous set of
compiled rules to the "OPES box". PCR makes two simplifications:
i. PCR channels are disjoint, so no two rules will fire in response to the
same request.
ii. The combining of different sets of rules within a single channel is
outside the scope of PCR, and can be done in any way that the channel
publisher sees fit.
4) PCR rules specify an executable object that can be expressed in any
interpretable format (language and API) as long as there is a globally
understood identifier for that format (similar to a MIME type).
The question of what is an appropriate API for OPES proxylets came up at the
Feb OPES workshop in New York, and I suggested the PCR approach of not
prescribing the API but instead only describing it, and allowing the choice
to be agreed upon between the provider of edge service platform and the
channel publisher. This makes the OPES framework neutral to API,
restricting its scope and allowing it to be used in very disparate
applications.
i) using a proxylet API, services such as those proposed by OPES can be
implemented (filtering, adaptation, etc).
ii) using servelet APIs, active and static content can be implemented at the
edge.
iii) non-portable and perhaps unsafe APIs such as resource-intensive gaming
or multimedia serving can be implemented using this framework, as long as
the
content provider has a lot of control over the edge servers.
5) It is reasonable to consider combining the OPES/IRML and PCR frameworks
into a general rule-based edge services mechanism that can describe a range
of
scenarios involving proxylets and servelets. Such a framework might not
encompass all of OPES, but in being less ambitious it might be more widely
applicable. If a framework were crafted that was neutral as to the
particular
choice of API and associated operating environment it might be more likely
to gain IETF approval.
Micah Beck