[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
>
> ....
>
> I've seen WSDL files and they don't seem any more difficult to read than
> XML schemas or stylesheets. Even then presentation tools can be created
> to make them more palatable to those who feel that WSDL files
I am strongly opposed to XML technologies that are designed based on the
principle that human beings won't need to look at them. It's a common
joke in the industry that WSDL is too ugly to be hand read and written.
You're at Microsoft...grab a copy of the WSDL's for .NET My Services.
In my experience, WSDLs are on average ten times longer than the
equivalent IDL. Trivial example:
http://213.23.125.181:8080/chemistry.wsdl
That defines 14 methods and as near as I can see the inputs are all
simple types. So in IDL it would be roughly 20 lines long. If I were a
conspiricist I'd find it interesting that WSDL was developed by tools
vendors.
>....
> > That's not true. The protocol was designed to make it easy to
> > wrap existing COM/DCOM components. Ask Don Box. That usage
> > model was envisioned since the beginning. I've only ever
> > heard two advantages cited for RPC: 1. It is intuitive
> > because it works just like regular programming 2. It is more
> > compatible with legacy systems and existing functions. Until
> > I hear other advantages of RPC I'm going to presume that
> > these are the two main things. I don't believe that either of
> > them is desirable from a security point of view.
>
> The reason I like RPC for web services is because I can seamlessly
> integrate them into my applications in my programming language of
> choice.
Deja vu. Isn't that what I said in the paragraph above?
Seamlessness is great for usability. That's why I think XML-RPC is great
for some applications. But in this thread we are talking about security
and I don't see seamlessness as an advantage.
> ... On the other, after looking at the chapters on REST in Fieldings
> dissertation I am unclear as to how I can achieve this same degree of
> integration using REST.
You probably can't. REST isn't hard but it requires networking code to
look like networking code, not like method calls. In my very rough idea
of an API you don't say "component.methodcall()" you say "resource.POST"
and "resource.GET".
But then common wisdom around SOAP (see, for example Amy Lewis' message)
is that the RPC usage will fall away in importance. Any "serious" app
will use "messaging". And in fact you can already see this happening.
The .NET My Services API looks like HTTP re-implemented, not like RPC.
You build up up a really complicated XML message and then you POST it.
It isn't OO at all.
http://www.oreillynet.com/pub/a/dotnet/2001/12/03/myservices.html
>...
> I agree that using RPC instead of REST makes it more difficult to
> perform logging, caching and filtering. That is an unfortunate tradeoff
> that one makes when picking RPC over REST. However, I'd love to a REST
> implementation of a non-trivial web service
Amazon. Expedia. Hotmail. If you switch them from HTML to XML you're 80%
of the way to making them REST web services.
> ... or even better a REST web
> services platform
Apache. IIS.
> ... before I can decide exactly how significant the
> tradeoff.
There is no tradeoff. You knew how to do REST before you knew how to do
SOAP. Like many of us (including me) you were told that you needed a
bunch more standards to accomplish tasks you already knew how to
accomplish like sending XML across the network.
>...
> Most firewalls I know filter based on packet information meaning
> primarily source IP, destination IP and destination port.
Which is why SOAP should have a port. Or really, one per SOAP binding.
> ... Anything
> sophisticated enough to filter based on whether it is a HTTP POST or not
> is very likely to be able to do more complex filtering as well.
You mean XPaths?
>...
> Again you have a good point and I'd like to reiterate that instead of
> pointing out the shortcomings of SOAP it's more productive to go ahead
> and propose a RESTful alternative or even better to create one and see
> where that takes you.
The hard part about REST is that it doesn't require many new tools so it
is very hard to evangelize it by writing tools. Also, there are already
hundreds of REST web services only they aren't serving XML yet and I
can't force them to. Nevertheless, if new frameworks and acronyms are
what will get people on board REST then here are a couple:
* http://www.prescod.net/wrdl.html
* http://conveyor.com/RESTwiki/moin.cgi/HttpEvents
Paul Prescod
|
