Como en diseño de aplicaciones multicapas, web, cliente-servidor u otras existen patrones que describen problemas comunes y sus soluciones estandarizadas, en el caso de SOA no es la excepción. En este post no vamos a describir los patrones más comunes, pues son muchos y son de referencia para arquitectos y desarrolladores que trabajen en el diseño de servicios SOA, en el sitio de “SOA patterns”, http://www.soapatterns.org/ hay publicado muchos patrones y constantemente se agregan nuevos.
La intención es describir algunos de los anti patrones SOA más comunes con el fin de indicar como no se debe diseñar una solución SOA.
Interfaces CRUD
CRUD en la sigla en inglés que representa las operaciones de creación, lectura, actualización y borrado. Es muy común utilizar estas operaciones en relación a las bases de datos, pero en el caso de un sistema orientado a servicios especificar las operaciones de los servicios como CRUD es una mala práctica.
Por ejemplo en un servicio de manejo de ordenes diseñar en servicio en base a CRUD implica tener operaciones del este tipo
FindOrderByIDResponse FindOrderByID(FindOrderByIDRequest request);
CreateOrderResponse CreateOrder(CreateOrderRequest request);
UpdateOrderResponse UpdateOrderByID(FindOrderByIDRequest request);
DeleteOrderResponse DeleteOrder(DeleteOrderRequest request);
Si en los casos de uso se necesita crear, actualizar y borrar ordenes esta especificación de servicios es válida, pero si la creación de una orden implica varias operaciones previas (por ej verificar la disponibilidad del producto, verificar el estado de crédito del cliente y crear la orden), la operación CreateOrder debe invocar internamente todas las operaciones necesarias para crearlo pues en caso de exponer solo la creación de la orden el consumidor debe hacer las operaciones previas. Este diseño violaría el TNet 3 pues no estaríamos compartiendo solo contratos.
En resumen lo incorrecto no es el uso de CRUD para la especificación de un servicio sino un mal diseño.
Interfaces Chatty
Este anti patrón se refiere a cuando se diseña un sistema orientado a servicios con operaciones que implican un alto nivel de granularidad. En este tipo de interfaces el consumidor es el encargado de llamar a las diferentes operaciones siguientes una lógica específica para que juntos hagan una determinada acción de negocio. Lo correcto es que todas las operaciones para hacer una determina acción de negocio se ejecuten internamente en el servicio.
Por ejemplos la siguientes operaciones se basan en un diseño que aplica este anti patrón
bool ChekGoodAvailability(Ordr order);
bool CheckCreditStatus(Order order);
bool PlaceOrder(Order order);
Estos dos anti patrones están asociados pues un mal diseño de una interfaz CRUD se convierte en una interfaz chatty.
En conclusión el formato de los servicios expuestos depende fundamentalmente de la especificación de casos de uso que estos deben implementar. Por lo tanto en ciertos casos se van a requerir operaciones tipo CRUD pero en muchas otras no. Un adecuando análisis de las especificaciones funcionales seguido de un buen diseño es importante para no terminar utilizando anti patrones.
2 comentarios:
Relacionado con el antipatrón crud, vos decis que en sí se podría tener en algunos casos un Wed Service con esas operaciones. En ese caso, yendo al diseño interno de la aplicación cliente de ese WS, qué opinás de que la misma acceda al WS desde un DAO?
El términos generales un servicios no necesariamente es un Web Services, esa sería una implementación especifica y bastante difundida.
Si el servicio expone funcionalidad de acceso a datos es válido accesde desde una módulo del cliente que contenga la lógica de acceso a datos (DAL), pues si el cliente está diseñado en el tipico modelo de capas (presentación,negocio,datos), sería la encargada de proveer la interfaces de accesos a datos a la capa de negocio.
En una aplicación cliente que usa el patrón MVC, una altetnativa es tener un controlador para esta función.
Publicar un comentario