[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<snip/>
> Buried among the various debates was one point that I'd like
> to bring to
> the forefront. Firewall avoidance is either part of SOAP's
> mission or it
> isn't. Maybe SOAP uses HTTP as if it were a transport protocol merely
> because it's "easier" to plug into HTTP-centric architectures than to
> talk sockets (arguable, but anyhow). In that case firewall avoidance
> would be an accident.
It isn't part of SOAP's mission, IMO. I think you'll find many in the SOAP
community taking exception to the characterizations of SOAP trying to
subvert the firewall and SOAP developers as trying to sneak past their
firewall administrators. I think those who make such characterizations lose
the entire SOAP developer audience when they make such assertions.
Focusing more on how SOAP can be improved, in this regard, without such
characterizations is likely to get a wider hearing.
> So here's a simple test we can do. If we can all come to
> consensus that
> firewall avoidance is a BAD THING then we can put together a petition
> that SOAP should use HTTP but simply on a different port. The SOAP
> specification should say: "Applications of SOAP MUST NOT use port 80
> unless they adhere to all of the semantics of HTTP.*"
<snip/>
> * Semantics of HTTP: The addresses of all resources being manipulated
> should be expressed in the end-point URI, not the SOAP body.
> POST should
> not be used for safe, idempotent fetching of information.
I think the impact of this last point is too great to expect everyone to
drop what they are doing and retool overnight.
I think a "cold turkey" approach like this is a lost cause, at this point. I
think you'd have better luck convincing the web service community to start
thinking about REST and making incremental accommodations toward it, rather
than thinking you are going to stop the current juggernaut in its tracks and
get it to radically change course. But I doubt there is any real resistance
to visibility at the firewall within the SOAP community. Developers just
want something that works and is as easy as it reasonably can be. Punching
through HTTP is easy. That's the only reason we are doing it. There's no
subterfuge intended, here.
I'm certainly open-minded on this. Yet, I also have timelines to meet and
budgets to contend with. I can't drop the way I'm doing things to comply
with REST. All I can do is think about REST as I embark on new work, and
think about how it can guide me in doing things better. But honestly, there
will be corners cut and compromises made. Ultimately, I'm paid to make it
work, not to comply with REST. But I will probably be making incremental
changes in the approaches I adopt and thinking about how REST can help.
And I would have no objections to seeing SOAP 1.2 make some explicit
accomodations to REST. As long as it doesn't stop me from getting my work
done.
|
