Hi Mark, Hi Ian.
On Fri, Nov 23, 2001 at 06:25:46PM -0500, Mark Baker wrote:
Ok, let's make it a bit more concrete. Let's say I1 is a firewall,
E1 is a language converter available through an RPC call, and OS is
an english stock quote. We'll also assume that all requests from C
are sent with an Accept-Language header. In addition, let's assume
that I1/E2 are owned and maintained by the same authority as OS
(thereby making I1 a gateway, as C specifically addresses I1, not
OS).
I2's job is to make E1 look like an HTTP intermediary. It does
this by accepting the responsibility on behalf of E1, of not just
dispatching requests to it, but of providing the end-to-end
guarantees that HTTP requires. In this example, one of those
guarantees is that it will mediate language conversion, so will
look for "Accept-Language: fr" on an inbound request (from C),
"Content-Language: en" on an inbound response (from OS), and will
know to change Content-Language to the value of the inbound
Accept-Language after dispatching the conversion process to E1
(assuming the conversion was successful).
To run through the example then,
- C does GET http://i2-host.com with "Accept-Language: fr" header
- I1 (the firewall) passes it through, perhaps perform proxy
authentication to check that the user is authorized to traverse
it
- I2 receives the request, remembering the Accept-Language header,
and passes it on to OS
- OS responds with some content tagged "Content-Language: en" (it
gets the Accept-Language header, but doesn't process it).
- on the return path, I2 sees that the content is in English,
but the user wants it in French, so it dispatches the content to
E1 to do the conversion
- I2 returns this content on the response path with
"Content-Language: fr"
- C gets the French stock quote
Ah. My current understanding (which isn't very current ;) is that
this isn't the intent of OPES. I think OPES is restricted to:
1. using the ruleset as a heuristic to match messages
2. doing things to those messages as a result
"doing things" encompasses vectoring to a proxylet/servelet; the
responsibility for honoring the semantics of the protocol (e.g.,
HTTP) are entirely the responsibility of the service. (OPES folks, is
this still the case?)
One of the things that always bothered me about ICAP was that it
advertised itself as taking away the burden of understanding HTTP
from the service authors. This simply isn't true; while some
low-level stuff like connection handling can be taken away, the hard
and most delicate part - the semantics - still need to be dealt with.
So, as I understand OPES, you have a situation where a service is
effectively split into two; the service provision and the heuristics
to stick in the ruleset to invoke it. If you're going to do this, I
think it makes sense to keep the protocol-specific semantics split
out into the rulesets, if possible.
Mark, I know you've stuck your head into RDF/SW stuff. One of the
things I've been interested in doing for a while is writing a
"Semantic Web Server"; i.e., where HTTP messages are parsed into RDF
statements, and then contextual logic is applied to affect handling.
E.g.,
log:forAll :x, :y, :z .
{ :http_request headers:accept_language :x .
:http_response headers:content_language :y .
}
log:implies
{ http_response opes:invoke [ :service :lang_trans ; :from :y ; :to :x ] .
http_response headers:content_language :x .
} .
I think this is along the lines of what you're talking about. Doing
it as statements gives a nice way to introduce access control, trust,
etc.
--
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)