SOA WS-* vs REST

Este debate tiene sus ciclos. Parece que se vuelve a reabrir.

Mark Nottingham lo decía bien claro – y no sin sorna – hace pocas fechas en un artículo (Squid is my service bus) del que Stefan Tilkov destaca el siguiente fragmento:

The point of this is that Squid — or most any other HTTP cache implementation, for that matter (because HTTP has a well-defined intermediary role, it’s easy to drop a new one in) — can serve as the basis of what most people think of as an Enterprise Service Bus for HTTP. True, it doesn’t support any WS-*, but more people are considering that a plus, not a minus, and you don’t have to pay a vendor for the privilege of debugging their beta product; it’s free and battle-tested. Oh, and a hell of a lot faster.

La cuestión es que Squid – o cualquier otra implementación de HTTP cache con este propósito (porque HTTP tiene bien definido el rol de intermediario, es fácil de escalar) – puede servir como base a lo que mucha gente piensa que es un ESB para HTTP. Ciertamente no soporta ninguna [especificación] WS-*, pero mucha gente lo considera un punto a favor, no en contra, y no tienes que pagar a un tercero por depurar su producto beta; es gratis [/libre] y está sobradamente probado. Ah, y mucho más rápido.

Por su parte Dare Obasanjo comenta la existencia de un proyecto en incubación con codename Astoria que pretende facilitar la exposición de datos para que puedan ser consumidos mediante web por clientes. Es decir, consumir un servicio de datos con verbos básicos (GET, PUT, POST y DELETE) de HTTP.

Es innegable la atención de Microsoft hacia REST y sus posibilidades. Sin embargo es necesario notar que REST no es un comodín. Por ello la posición en el debate WS-* vs REST es clara: cada cosa para lo suyo. Y en el caso de ISPAMAT no hay ninguna duda de que SOA WS-* es la elección correcta: los servicios son altamente heterogéneos y SOA aporta la orquestación necesaria para crear los servicios de valor añadido necesarios en el proyecto.