Arquitectura Orientada a Servicios

La ruta que se ha definido en Arquitectura de Sistemas para el desarrollo de soluciones o sistemas informáticos es SOA (Arquitectura Orientada a Servicios), la cual esta basada en la implementación de Servicios de Negocio, esto es; bloques funcionales de negocio que se pueden integrar, y compartir en distintas aplicaciones. La principal tecnología para implementar servicios SOA es WebServices, y es la que se recomienda, se promueve y exige, pero hay que tener cuidado, porque fácilmente se puede cometer errores, sino se asumen los siguientes principios:: 

·         Un Webservice no necesariamente es un Servicio SOA. 

·         Un Servicio SOA no necesariamente tiene que ser implementado como WebService. 

Para que un WebService se considere un Servicio SOA, debe cumplir con los estándares SOA, a grandes rasgos: debe corresponder a una funcionalidad del Negocio bien acotada (self cointained), independiente de la implementación tecnológica e independiente de los sistemas operacionales que lo soportan (loose coupling), y además debe poder ser compartido y reutilizado por otros procesos o sistemas (reuse). Por otro lado, un servicio SOA podría ser implementado con otras tecnologías, como HttpService, Mensajería, Ajax (DWR), etc, pero nuevamente para ser considerado como tal, debe cumplir los estándares SOA. 

SOA es una tecnología madura, y respaldada por los principales expertos y empresas, por ejemplo Gartner dentro de su HypeCycle (diagrama de madurez) ya el 2009 lo tiene entrando al nivel de plena productividad (plateau of productivity). (img1) 

Además Gartner la tiene dentro de las tecnologías Top Ten en la industria de Seguros (ref. “Gartner Outlines Top 10 Technologies to Impact Property and Casualty Insurance” – Harris Ferrante  – Marzo 2010).  

IBM se refiere a SOA como “la plataforma que alinea el Negocio con Tecnología” (IBM Smart SOA – Enero 2010, http://www-01.ibm.com/software/solutions/soa/smartsoa/), y ha desarrollado toda una metodología y set de herramientas para apoyar SOA.  

Oracle indica “SOA se ha movido de la sobreespectativa (hype) a una completa aceptación como estrategia de Tecnología (TI) para entregar soluciones de Negocio” (Oracle SOA Governance Solution -2009, http://www.oracle.com/technologies/soa/docs/soa-governance-datasheet.pdf). 

¿Y porque se debe implementar SOA usando WebServices?, en términos simples, porque es el estándar de facto, Webservices es una tecnología que opera en .Net y Java, que la mayoría de los motores de servicios contempla (bases de datos, ESB, ETL, etc), que las herramientas de diseño, desarrollo, y testing soportan, y que las grandes aplicaciones también manejan (CRM, ERP, SAP, SalesForce, etc.). Gartner de hecho tiene los webservices situados en “plena productividad” para Arquitectura de Aplicaciones  (ver “Hype Cycle for Application Architecture, 2009“, http://www.gartner.com/DisplayDocument?id=1077812).  

Los servicios SOA sirven para integrar sistemas, para construir procesos de negocio (orquestación de servicios), pero principalmente sirven para implementar aplicaciones Web. IBM lo ha promovido en el desarrollo de aplicaciones Web, en combinación con frameworks como Struts, Spring, lo ha promovido para el desarrollo de aplicaciones web “rich” (“Build rich Java Web applications with Apache Wink and Ajax“ – Febrero 2010) , y para el desarrollo  de aplicaciones Web dinámicas (“Build RESTful Web services and dynamic Web applications with the multi-tier architecture” –Junio 2009). Oracle lo contempla en su Arquitectura de aplicaciones; Oracle ADF. 

  Arquitectura Orientada a Servicios

Pero como toda tecnología, los WebServices pueden ser mal implementados, si no se siguen los estándares y buenas prácticas, que existen para el desarrollo de Servicios. Uno de los problemas más comunes es pretender que toda funcionalidad de un sistema se puede convertir en un servicio (WebService), y la verdad es que el enfoque es otro, las funcionalidades de Negocio, que pueden involucrar más de un sistema, son las que se deben convertir en Servicios. 

Se han mencionado buenas prácticas y antipatrones para el desarrollo de servicios, las buenas prácticas apuntan a como se deben hacer las cosas, y los antipatrones apuntan a mostrar en que problemas no debemos caer, ejemplos: ·         Servicio se nombra para maximizar consumo.Erróneo: insertarRegistroCliente()Correcto: crearNuevoCliente() 

·         Servicio tienen parámetros abultados (coarse grained)

Erróneo : crearNuevoCliente (rut, nombre, apellidos, email, fono, direccion)

Correcto: crearNuevoCliente (objetoCliente) 

·         Servicio encapsula detalles de implementación.

Erróneo : crearNuevoClientePsoft (schemaOracle, registroTablaCliente )

Correcto: crearNuevoCliente (objetoCliente) 

·         AntiPatrón, Servicio Parlanchines (Chatty Services)

Erróneo: consultaUF()

Correcto: (NO implementar ese tipo funciones como servicios) 

·         IBM SOA Antipatternshttp://www.ibm.com/developerworks/webservices/library/ws-antipatterns/ 

·         IBM SOA realization, Service design principleshttp://www-128.ibm.com/developerworks/webservices/library/ws-soa-design/ 

·         SOA Anti-Patterns: How Not to Do Service-Oriented Architecturehttp://www.oracle.com/technology/architect/entarch/pdf/oea_soa_antipatterns.pdf ·        

·         Best Practices for Web services: Web services performance considerationshttp://www.ibm.com/developerworks/webservices/library/ws-best9/index.html 

¿Pero solo basta con conocer los estándares y buenas prácticas para no equivocar el camino en la implementación de servicios y para lograr los beneficios que promete SOA?;  la verdad es que NO, se necesita más que eso, se pueden saber los patrones de diseño SOA, pero aun no interiorizarlos, o no poder lograrlo con tecnologías especificas como Java, porque solo la experiencia real, y la supervisión continua en la primeras etapas logra que el área de TI adopte de forma adecuada SOA, y aquí es donde entra a jugar otro enfoque; “SOA Governance” , que corresponde a implementar el soporte en procedimientos, metodologías, y herramientas, para lograr un SOA exitoso: 

  • SOA Governance ya no es una opción, es un imperativo, sin esta administración (governance) el retorno de la inversión es mucho menor, y todo proyecto SOA estará en riesgo (ref. “Service Oriented Architecture Craves Governance” – Gartner).
  • De hecho sin él (SOA Governance), muchas iniciativas SOA fallan” (“Oracle SOA Governance Solution” – 2009).

Si la implementación de Servicios SOA falla, entonces es determinante la implementación de un “SOA Governance”, y el primer y mas importante paso en Governance es establecer una área especializada; el “Centro de Excelencia SOA” (SOA COE), que permite enseñar y supervisar la adopción de SOA en una Empresa, un área clave liderada por Arquitectos de Sistemas. 

Advertisements