C -| I1 |---| I2 |- OS
| E1 |
C = client, OS = origin server, I1 = some intermediary, E1 = some
external service accessed by a different protocol, I2 = a gateway
intermediary to E1. C, S, and I1 don't care what E1's protocol is, and
that's why I don't think it's important to pick just one. I2's job is
just to make E1 look like an intermediary.
So in terms of the end-to-end HTTP flow (assume no modifications for now)
I1 and I2 are functionally equivalent: they're both HTTP proxies from what
I can see.
HTTP intermediaries. Not necessarily proxies. Re your comment about
gateway below, yes, I didn't mean to use the term. Though in the
example I had in my head, it was also a gateway. In that diagram I
provided, there's insufficient information to determine whether the
intermediaries are gateways or proxies.
The only reason to add I2 as a "gateway"(*) is in order to support the
custom protocol between I2 and E1. If you're going to do that then you're
right that there's no need to have a standardized OPES callout ... but it's
kindof missing the point of standardizing an OPES callout protocol in the
first place. If there is a series of transformations that need to occur
between OS and C (or vice versa) your model could requre as many additional
I* entities as transformations.
It could, but need not. There is room for optimization.
Even scarier than the latency each
application layer hop would add is the configuration of the I* entities in
the correct order to accomplish a set of arbitary transformations
potentially spread across multiple E* entities.
Enter the application router. My company sells them.
[Also, if I2 is only necessary to speak with E1 then it might be better to
just create a custom proxy on I2 to do the job itself]
I didn't mean to suggest that they were *necessarily* distributed about
the network. It would definitely make sense to put E1 and I2 on the
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker(_at_)planetfred(_dot_)com