ARC201 - Patterns & antipatterns for SOA

Esta era la segunda sesión del track de arquitectura a la asistía en este tech·ed. En la primera me aburrí bastante, pero en esta segunda me divertí un montón. No es que el ponente (Ron Jacobs) contase muchas cosas pero las que contó fueron interesantes... y divertidas.

Básicamente la sesión comentó tres cosillas básicas de la filosofía SoA y luego analizó un conjunto de patrones y antipatrones de SoA.

Lo que dijo primero sobre SoA fue que:

1. Las aplicaciones fuertemente acopladas no son satanás: tienen su sentido cuando el rendimiento es vital.
2. Debe preferirse siempre el comportamiento explícito al implícito.
3. Los servicios son la puerta de entrada a procesos de negocio. Si algo no es un proceso de negocio, quizás no se trate de un servicio.
4. Las barreras deben ser explícitas (sin llegar a suponer impedimentos).
5. Los servicios deben ser autónomos. Los servicios comparten sólo su interfaz (y las políticas asociadas).
6. La compatibilidad entre servicios viene dada por sus políticas asociadas (que define protocolos de transporte, temas de transaccionalidad, reliable messageing, ...).

Luego empezó a enumerar algunos antipatrones clásicos de SoA:

1. CRUDy interface: Un servicio cuyo interfaz sea únicamente operaciones CRUD (Create, Read, Update, Delete) debe hacernos plantear si realmente estas operaciones son procesos de negocio (recordar el punto 3 anterior) o simples modificaciones de datos. Las interfaces CRUDy tienden a aparecer cuando se diseñan aplicaciones débilmente ligadas a partir de la experiencia del pasado (aplicaciones fuertemente ligadas).
2. Enumeration: Un servicio cuya interfaz tenga los clásicos métodos Object current() y bool moveNext(). Debemos plantearnos dos preguntas: la primera es quien contiene la colección y los recursos necesarios (puede violar la regla de que los servicios deben ser autónomos). La segunda pregunta es que podemos hacer con un Object? Básicamente nada, sólo convertirlo a la clase real contenida en la colección, y eso implica un conocimiento que va más allá de la interfaz.
3. Chatty Interface: Interface que contiene métodos del tipo UpdateAddress(), UpdateName() y CommitChanges(). Durante las llamadas a UpdateXXX y hasta que no se llama a CommitChanges, existen datos "incosistentes". Todas las operaciones que requieren más de un mensaje para realizarse son potencialmente peligrosas.
4. Loosey Goosey: Dio una traducción al español de lo que significaba Loosey Goosey, pero sinceramente no me acuerdo. Se trata de evitar interfaces tan genéricas que no sirvan de nada. Por ejemplo una interfaz con un método XmlDocument Execute(XmlDocument request), es extremadamente flexible, adaptable (y reutilizable) pero es completamente inútil: necesitamos saber el formato del XML de entrada y de salida, que es información que no está en la propia interfaz. Resumiendo: interfaces flexibles y adaptables sí, pero todo tiene un límite.

Luego pasamos a ver un par de par de patrones válidos en arquitecuras SoA: Document processor y Reservation.

Document Processor

Este patrón se basa en las siguientes claves:

• Operaciones asíncronas
• Fronteras bien definidas
  

Decidir que proceso quiere implementarse.
Decomoponer el proceso en actividades realizables mediante un workflow.
Crear el contrato:

1. Definir los mensajes
   
2. Definir las operaciones
3. Agrupar operaciones relacionadas dentro de servicios.

Como ejemplo de Document Processor puso el proceso de apuntarse a una universidad, pero no una de actual, si no una de hace unos 10 años. Cuando uno se apunta una universidad debe asignarsele aula, horario, profesor, ...

1. Existen un conjunto de formularios a rellenar (mensajes)
2. Cada persona implicada en la operación recibe el formulario (mensaje) correspondiente y realiza su tarea (operaciones asíncronas).

Reservation
Sistemas de transacciones distribuídas asumen un grado de confianza que en aplicaciones loosely coupled muchas veces no son deseables (no siempre se quiere dar el control final de una transaccion al transaction manager de otro sistema). Para evitar esto y al mismo tiempo seguir tenir transacciones se establece un estado intermedio llamado reserva. Es nuestra responsabilidad definir bien los estados por los que pasa una reserva hasta que es consolidada y que mensajes son intercambiados en cada caso.
Como ejemplo puso el de las compañías aéreas: Cuando el cliente llama para pedir un vuelo, como no confían en el cliente para cerrar la transacción, permiten hacer una reserva. Hasta que el cliente no pague (mensaje) la reserva no pasa al estado de confirmado.

Finalmente terminó la sesión con un par de consejos básicos: intentar usar tipos portables entre plataformas (p.ej. evitar DataSets que se mapean a "any" en WSDL) y evita el comportamiento implícito (p.ej. no asumir que los datos vienen en un orden determinado si el contrato no lo especifica de forma clara).

Eso es todo lo que dio de si la sesión, muy introductoria pero eso sí: muy divertida.