[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Can you stand yet another SOAP-RPC vs HTTP GET question?
Mike Champion wrote: > > 4/20/2002 10:21:30 AM, "Didier PH Martin" <martind@n...> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|