Acerca de SOA

En InfoQ hay una presentación sobre SOA que dio un tal Gregor Hohpe, arquitecto en Google, en JavaZone; unas conferencias organizados por un grupo noruego de programadores de Java.

Este ser humano es, por cierto, el autor de "Enterprise Integration Patterns" y tiene un artículo muy simpático llamado "Your Coffee Shop Does Not Use Two-Phase Commit" que salío publicado el año pasado en la revista Software de IEEE en el que explica que un sistema que tiene que tener gran capacidad tiene que abandonar cosas como el 2pc por el camino.

Resumo los puntos que me parecieron interesantes de su presentación:

1. ¿Qué es SOA?

• Es un estilo de arquitectura, en el que las interacciones entre sistemas están orientadas a documentos es decir, están autocontenidas en un alto grado
  
• Bajo nivel de acoplamiento, se puede cambiar un servicio internamente sin que los consumidores del servicio se enteren
  
• Las interfaces están claramente especificadas

2. ¿Cómo hemos llegado hasta aquí?
Principalmente en los sistemas distribuidos el objetivo hasta ahora, en arquitecturas previas, era ocultar la complejidad al desarrollador; es decir: el código remoto es exactamente igual que el código local. Este enfoque ignora:

• latencia de la red
• redes desconectadas intermitentemente
• inexistencia de referencias (punteros)
• alto acoplamiento entre sistemas

En muchos sistemas actuales, altamente distribuidos y con muy grandes requerimientos de rendimiento estos problemas existen, y mucho. Si ocultamos el hecho de que los sistemas están distribuidos al desarrollador el resultado puede ser que el sistema resultante no sea todo lo escalable que deseamos.

Así surgió la "orientación a servicios"; no existen interacciones complejas (polimorfismo, referencias, etc...) sino interacciones simples, autocontenidas, basadas en un documento que normalmente es XML y, más apropiadas para ser asíncronas.

3. ¿Cómo está la situación ahora?
El hecho es que este es un nuevo modelo de programación; y las herramientas actuales son bastante primitivas todavía. Está por ver si llegan a ser como las que tenemos para los lenguajes tradicionales. Es cierto que aparentemente se puede programar gráficamente un proceso de negocio y demás pero... ¿cómo se buscan las diferencias entre este proceso y su versión anterior? ¿hay algo similar a diff o merge para los diagramas? y si, quizás no haya que programar mucho hasta que hay que hacer algo "avanzado", en ese momento ya hay que programar y, de todas maneras, programar gráficamente puede ser algo bastante complicado.


Es interesante también el artículo "Developing in a SOA World", que contiene la mayor parte de las ideas de la presentación.