All About Interop : SOAP

More on non-standard RPC protocols - Cisco Etch

DotNetInterop — Fri, 01 Aug 2008 17:28:00 GMT

I came across this old bit of news - In May, Cisco joined the ranks of vendors that want to introduce a house-brand protocol and description in lieu of the standard ones already available in things like REST, SOAP, and WSDL. Going by the name of Etch, this new thing from Cisco is supposed to solve the problems the networking vendor has with SOAP. They say it's simpler, and oh, gee, look, it has that old famiilar RPC feel....

I have previously weighed in on such ideas, and not favorably either.

It seems I have good company - Steve Vinoski is of similar mind, at least with regard to Cisco's Etch.

Toss Etch on the pile with Hessian, ZeroC ICE, Thrift, Protocol Buffers, and the rest of the "I-need-a-new-protocol-cause-SOAP-is-so-bad" lot.

WADL and WSDL and REST, oh my!

DotNetInterop — Wed, 06 Feb 2008 21:17:00 GMT

Hernan Garcia made an interesting comment on my post of yesterday: For REST, there is an alternative to the WSDL in SOAP and it is WADL.

Good point Mr Garcia - The adoption and practical utility of WADL is worth watching. The question for me becomes whether WADL+REST is actually better than WSDL+SOAP, or just different. Whether REST has succeeded to the extent that it has, in spite of lack of WSDL-like tools, or in fact, because of the lack of WSDL-like tools? Is the appeal of REST that there is no single set of tools, which thus limits the possibility to be overcome by galloping complexity, as some have characterized WS-*?

All interesting. It is by no means certain that clear answers to these questions will be coming soon, if at all. Seriously. In 2 years' time the tea leaves may be no clearer on any of these things.

Which gets me back to my earlier philosophy: the best approach for enterprise architects today is to think strategically, but act pragmatically.

With the communication framework built into .NET, Windows Communication Foundation (aka WCF), this is the philosophy we at Microsoft are trying to endorse. It is designed to support REST and SOAP today, as well as other non-standard protocols (via the WCF LOB Adapter SDK), in a single unified programming model. A contrast here is a variety of programming models for different communications protocols; in Java-land what I am thinking is; ECI/EPI for Mainframe and 3270 integration, EJB for transactional comms, JMS for queued comms, JAX-WS for SOAP, JAX-RS for REST, RMI for like-to-like communications. This is hard for any architect or programmer to keep up with. This variety seems to be the result of pragmatic design, rather than strategic design. Each step makes sense by itself. Each API is useful by itself. But all together, there's no cohesiveness. It's overwhelming.

Another SOAP and REST discussion, Same Result

DotNetInterop — Tue, 05 Feb 2008 21:21:00 GMT

Catching up with some reading, I was looking through the SDTimes issue from January 1st (yes, I know, it is now February. Cut me some slack!). In it, Sanjiva Weerawarana, CEO of WS02, has a guest editorial column about your favorite subject and mine: REST versus SOAP.

Nothing really new, to me anyway, in that editorial, but Mr W articulates the issues well. In short, neither REST nor SOAP is the answer to every need, neither REST nor SOAP are automatic solutions. WSDL is not the greatest, but it is better than the nothing we get with REST. And so on. The bottom line, says Weerawarana, is that both REST and SOAP, properly applied, can play a role in an enterprise architecture. REST is quick and clean; SOAP is more powerful and richly elaborated. Companies should "embrace the choice" and select the best for the task.

It strikes me that the REST-v-SOAP discussion is itself pretty narrow. It's almost like having a discussion about XML versus Relational data stores that flared up years back. Of course in any enterprise of significant enough size, there will be XML as well as relational stores, and the same is true of REST and SOAP today. And furthermore, neither SOAP nor REST nor some blend of both is the answer to every communications challenge. What about legacy systems? Can someone say EDI? SAP RFC and BAPI? (alphabet soup, that). What about existing deployed middleware stacks, existing skills in development and operations?

For me the bottom line is this: Heterogeneity will prevail. SOAP and REST are just more tools in the toolkit. Check 'em out and see if they work for you. We, Microsoft, think there are good opportunities in those protocols, to generalize communications and make it simpler. But they are not one-size-fits-all approaches.

By the way, a message from our sponsor: WCF does both REST and SOAP nicely. I wrote on this before. If you're building applications that communicate, Windows Communication Foundation, part of the .NET Framework, can make it easier, whether you choose REST, or SOAP, or something else, or some blend. WCF is a good choice even if you want to defer your choice, if you don't want to choose just yet. And with the tooling support for WCF added in Visual Studio 2008, WCF programming is even easier. Definitely worth checking out!

cheers!