Buscar

Google
La Webe-SOA

domingo, 21 de noviembre de 2010

Arquitectura Orientada a Servicios - Concepto UNO

La Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.
Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
SOA define las siguientes capas de software:
  • Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
  • De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web);
  • De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración;
  • De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio;
  • De entrega - donde los servicios son desplegados a los usuarios finales.
SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividad.

SOA - Concepto DOS

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.

Diseño y Desarrollo de SOA

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura.
Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los siguientes:
Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "orientado a servicios" pero es altamente recomendable su uso.
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios.

Diferencias con Otras Arquitecturas

Al contrario de las arquitecturas orientado a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación (p.ej., WSDL). La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Plataforma Java o Microsoft.NET). Con esta arquitectura, se pretende que los componentes de software desarrollados sean muy reutilizables, ya que la interfaz se define siguiendo un estándar; así, un servicio C# podría ser usado por una aplicación Java. En este sentido, ciertos autores definen SOA como una Súper-Abstracción.

SOA Open Source

Ahora que esto de SOA se lleva en muchas aplicaciones (multitud de aplicaciones de todo tipo se “Orientan a SOA”), habría que pensar en las posibilidades de construir arquitecturas orientadas a servicios con software realmente barato (o incluso hasta un punto de gratuito con herramientas open source).
Se me ocurren multitud de aplicaciones a coste 0 inicial:

Portales : Liferay, Jakarta Pluto, OpenPortal, JBoss Portal …
Brokers / ESB : ServiceMix, MULE ESB, openESB …
Procesos de Negocio / BPM : jBPM, Intalio, Bonita Workflow …
Servidores de Aplicaciones : Jboss, Glassfish …
Frameworks para Servicios Web : Metro, Axis …
Entornos de desarrollo : Eclipse, Netbeans …
Testeadores de XML, Servicios Web, etc… : soapUI, PushToTest, HtmlUnit …
Gobernabilidad : CentraSite, WSO2 …

Y muchas más, que posiblemente podrían constituir soluciones realmente complejas para cualquier tipo de empresa.
En este punto y viendo como las empresas se gastan miles de euros en soluciones de pago de diversos fabricantes; ¿no estaría mejor invertir ese dinero en desarrolladores, arquitectos… sus propios empleados al fin y al cabo, para que luego sus desarrollos fueran lo mejor posibles?
Ver como después de comprar las suites más caras del mercado, se realizan auténticas barbaridades en los desarrollos (por desconocimiento de las mismas o simplemente por no dedicarles el tiempo necesario) le deja a uno perplejo.
No estoy diciendo que una empresa deba estructurar su IT, en su totalidad a partir de Open Source. Quizá, para la parte más importante de su negocio, fabricantes de pago sea la mejor alternativa (al final, si pagas por un producto; en cierto modo, te aseguras que funciona… sino, el fabricante tendrá que responder ante él). Pero estoy seguro que en muchas ocasiones se desperdicia dinero en comprar herramientas que no se utilizan adecuadamente o que directamente se piensan que van a resolver los problemas por sí solas (cuando en realidad el saber utilizarlas adecuadamente tiene más importancia).
Es verdad que algunas empresas ya se están dando cuenta de ésto y cada vez más apuestan por herramientas de código libre. Incluso las administraciones públicas lo promueven en la teoría (aunque a veces la realidad sea muy distinta). Pero todavía queda mucho camino por recorrer…
En fin, habrá que esperar…