[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
> 4/20/2002 10:21:30 AM, "Didier PH Martin" <martind@netfolder.com> wrote:
>
> >. For them, seeing Google as a component is a natural
> >extension of their actual view of the world. They simply have to drag and
> >drop a component on their form and voila, they are now ready to glue it with
> >other components.
>
> Ah-ha, I think that's what I've been missing here! Never having used VB, etc.,
> I just didn't grok why people would want to jump through hoops to avoid dealing
> with a very simple URI/HTTP call/XML result. That just doesn't fit into the
> "paradigm" of visual component assembly programming, but WSDL/SOAP-RPC does.
Not true! When the service is simple and stateless as Google is, you can
use WSDL's GET/POST bindings to get a VB interface that is 100%
identical to the SOAP interface. WSDL starts to break down with stateful
services and that's why I am working on WRDL.
>...
> Right! This helps crystallize another issue that has been bugging me: is there
> any intrinsic reason why "functional" or "REST-like" (I'm not sure they're the
> same, but that's another issue) development can't be done in a VB-friendly way?
> I'm bewildered by this stuff partly because Microsoft, Macromedia, have
> made lots of progress in the last 5 years making web PAGE development accessible
> to non-nerds, and it seemed logical that this technology could be leveraged
> to make RESTful web SERVICE development accessible to non-nerds. Or maybe the
> people who understand "procedural" aspects of website development have been
> behind the scenes all along, and gravitate toward SOAP-RPC because it simply
> eliminates all the HTML/HTTP stuff between the producer and consumer of
> a web page/service?
Here's my take:
In the early days of the Web, everyone realized that this was radically
different than anything they had done before. Therefore the tools
vendors were willing to adapt their tools to the needs of the medium.
Out of that change came ASP, JSP, J2EE, ColdFusion etc.
Now the problem is making "procedure calls" across the Internet. They
see this as just an updated version of a problem they already
understand. Therefore they are somewhat unwilling to consider it on its
own merits as a new problem that requires new solutions. Plus, consider
the cost/benefit of taking your OLD tools, putting a shiny, expensive
XML wrapper around them and reselling them. HTTP advocates argue the
opposite: learn out how to use EXISTING (i.e. already sold) tools to
solve NEW problems.
Can REST be as easy for VB programmers?
Until state is involved, I have demonstrated that REST and SOAP/WSDL
interfaces to data can be made to seem identical. WSDL has sufficient
capability built in.
When state gets involved they diverge. REST has an explicit way of
dealing with state (the URI and URI-management methods). SOAP/WSDL does
not. All state management in SOAP is handled entirely at the application
level through magical "objectid" parameters. Both models will likely
seem alien to a programmer working in VB, but the REST way may require
them to learn a little more *up front* (how to deal with URIs and think
about them as resource identifiers) whereas the SOAP way requires them
to learn how to manage state in a different way for each service. It
seems easier at first ("just pass the handle string as the first
parameter") but it is more expensive in the long term.
If you want to see the end result of this, go look at the bizarre and
complicated way that Hailstorm (may she rest in peace) dealt with state.
Paul Prescod
|
