Re: Draft on Callout Protocol Requirements
2001-11-22 20:35:32
--On Thursday, November 22, 2001 21:19 -0500 Mark Baker <distobj(_at_)acm(_dot_)org>
wrote:
> +----+ +----+
> 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.
OK, let's be careful... there's not to my knowledge any definition of an
"HTTP intermediary" that we can actually point to as a reference. (And
yes, I know that I'm guilty of using that phrase too.)
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.
If I2 is a gateway then I'm starting to see some very icky requirements in
the I* cloud (if there could be an I3 between I2 and OS). I think I'm
starting to see source routing too... I'm definitely seeing encapsulation
issues.
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.
Of course. But if I have 5 transformations from 5 vendors each of whom
wishes to run their own I-E protocol that means I have a total mess.
I thought the whole point of OPES was to have one I-E protocol so that we
had an open standard... kindof like HTTP... so that things can work
together properly.
I'm not sure I've seen a requirement for the OPES callout protocol being a
new on-the-wire protocol, but if it's going to be run on top of, say, HTTP
then we still need a document to be able to point to so we can all write to
the same encapsulation. (You mentioned SOAP over HTTP - that's definitely
been discussed as a candidate. If OPES uses SOAP over HTTP then it still
needs to be documented, even if the resulting documentation is a 3 page
RFC.)
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.
When can we expect to see an Internet Draft explaining the operation of the
application router and how it interoperates with proxies and gateways to
provide transformation services?
I'd already considered an entity sat in the middle of a star-like
collection of transformation engines but chose to omit that part from my
earlier email. If you're going to be using HTTP then again you run the
potential of a hideous number network stacks that the data is passing
through. It would also differ from your initial diagram in that I2 would
not have a direct connection to OS (the request would have to pass back
through the "application router").
[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
same box.
E1 + I2 = an OPES intermediary with E1 being provided by a proxylet.
Right? The "application router" is then the rule logic tying together the
various transformations that are available both in proxylets and via
callout server(s).
Mark, please feel free to contact me off-list. I agree that there's some
degree of disconnect and as such we might not be using the list in the most
productive manner.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Draft on Callout Protocol Requirements, (continued)
RE: Draft on Callout Protocol Requirements, Reinaldo Penno
Re: Draft on Callout Protocol Requirements,
Ian Cooper <=
RE: Draft on Callout Protocol Requirements, Reinaldo Penno
RE: Draft on Callout Protocol Requirements, Phil Rzewski
RE: Draft on Callout Protocol Requirements, Reinaldo Penno
RE: Draft on Callout Protocol Requirements, Phil Rzewski
RE: Draft on Callout Protocol Requirements, Tomlinson, Gary
RE: Draft on Callout Protocol Requirements, Reinaldo Penno
RE: Draft on Callout Protocol Requirements, Tomlinson, Gary
|
|
|