RE: Summing up on visibility(?)

> Yes it is, except in the case of a method dispatch, because a method
> dispatch is necessarily superfluous; if you've already dispatched on a
> method, and then dispatch on another one somewhere else in the message,
> then the dispatch on the first method was meaningless.
>
> GET http://example.org/setValue?foo=3
>
> If an HTTP intermediary saw that message, what does it mean to it?  It
> means GET, that the message initiator is requesting a representation of
> some resource be returned.  So if the service interprets that as a
> request to set the value of foo to "3", then the intermediary was
> fooled, i.e. a second method-dispatch occurred that made the meaning of
> the message be something other than "GET".  That's how you get over
> firewalls; don't try to fool them (aka don't tunnel).

Let's say I have an itermediary there that looks that messages and asks
questions like: who send this message? what information do they want? can
they get that information? should I charge them for that information? are
they allowed to make so many requests? would I process it faster than other
requests?

The answer "it's a request" is fine, but not always sufficient. Of course we
can shift the problem away. We can say, look at the message content. For
example, have an HTTP intermediary that looks at the HTTP method, and a SOAP
intermediary that looks at the message.

We fool firewalls every time we do an HTTP method because we are tunnelling.
The firewall that does packet filtering has no clue if client X is able to
make request from application Y if all the applications are HTTP on the same
TCP port. So the firewall needs a new definition of ports. If application Y
and application Z are both exposed on port 80 (or 8080 when using a proxy),
then you need to somewho distinguish the actual port of the application from
the port of the protocol.

Perhaps that explains why WSDL strives to define service ports as distinct
from TCP ports.

arkin


>
> If you only put nouns in that URI (which, since it's just an identifier,
> makes sense), then the meaning of that message remains "GET".
>
> > Not really because you didn't understand my example... Can we try again?
> > (Sorry for not making it clearer before... It was certainly clear in my
> > head,
> > just never made it to the electrons making up the ascii
> characters in my
> > note:)
>
> No problem.  I should have asked you to clarify off-line.
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis

Received on Tuesday, 14 January 2003 20:58:47 UTC