WADL and WSDL and REST, oh my!

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.