--On Thursday, November 22, 2001 20:26 -0500 Mark Baker <distobj(_at_)acm(_dot_)org>
wrote:
I'll admit that I haven't read all of the drafts recently, but I didn't
think there was a requirement for the callout protocol to be "something
totally and utterly new" if an existing protocol (HTTP, SOAP etc.)
fitted.
> We must be disconnected, but I'm not sure where. Let's dig a little
> deeper.
Agreed.
Perhaps you could give some quick back-of-the-envelope examples of how
HTTP and/or SMTP might be used as the protocol between OPES
intermediary and the gateway?
Well, the gateway is just another intermediary in the chain. So it
might look like this;
+----+ +----+
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.
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. 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.
[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]
(*) Note: I'm smacking myself on the head for not spotting this sooner but
I think it would be *very* wise to avoid the term "gateway" in this context
given the definition in RFC2616.