Service Oriented Architecture (SOA): ¿Por dónde empezar?


Hace un par de semanas hablabámos de un concepto que últimamente está muy “de moda”: SaaS. Otra sigla, término o palabra que hemos oido mencionar bastante en los últimos años y de la que se vuelve a hablar con fuerza es el de SOA: Arquitectura Orientada a Servicio. Como siempre ocurre en un proyecto de implementación de “algo nuuevo”, cuando se empieza a pensar en adoptar e implantar una solución SOA en una organización, hay que tener muy claros una serie de puntos de cara a garantizar el éxito e implantación de dicha adopción. El primer paso es compreder claramente que es SOA a nivel conceptual y sus implicaciones. Una definición bastante buena la podemos encontrar en este whitepaper sobre SOA de Microsoft, aunque me quedo con la siguiente: SOA es un patrón de diseño arquitectónico, un estilo de arquitectura que se basa en la definición de relaciones con un grado de acoplamiento débil entre una serie de elementos consumidores y productores. SOA no tiene una relación directa con el software, la programación o la tecnología. SOA agrupa nuevas funcionalidades, y las ya existentes, en servicios atómicos que se comunican entre sí a través de pasar datos entre servicios o coordinando una actividad entre uno o más servicios.


A la hora de planficar la implementación de una solución SOA, hay una serie de pasos que hemos de considerar:



  • Comprender los objetivos de negocio y definir las condiciones de éxito. Frente a la visión tradicional de aplicaciones en las que se tendía a dar más importancia a la tecnología a utilizar que a los problemas a resolver, con SOA se trata de clarificar primero que queremos lograr y luego ya especificaremos como (pero sin imponer ningún tipo de restricción). Nos encontramos por tanto, ante la típica recogida y análisis de requisitos en la que buscamos determinar que información se necesita, como se intercambia la información, qué se hace con la información, etc.
  • Definir el dominio en el que se circunscriben el problema o problemas. Se trata de definir el ámbito en el que se aplicará SOA dentro de una organización. Además de definir el ámbito, tenemos que pensar en qué SOA se implementa mejor si empezamos poco a poco, es decir, vamos en lugar de atacar el dominio completo vamos atacando pequeñas partes del mismo (¡Divide y Vencerás!).
  • Comprender todas las semánticas de aplicación que existen en el dominio. O lo que es lo mismo, es importante analizar y comprender la naturaleza de la información que se va a intercambiar, así como identificar todos los casos posibles. A este nivel, buscamos evitar que se produzcan contradicciones en cuanto al significado de la información.
  • Comprender todos los servicios disponibles en el dominio. Tenemos que responder a las preguntas: ¿Cuántos servicios tengo? ¿ Dónde están estos servicios? ¿Cuál es el objetivo de cada servicio? ¿Qué información está vinculada con cada servicio? ¿Existen dependencias? ¿Qué problemas de seguridad hay? Por tanto, la idea es crearnos un directorio de servicios en el que tengamos plasmada toda esta información.
  • Comprender todas las fuentes de información dispobibles en el dominio. En este caso, se trata de identificar aspectos relativos a: la ubicación de estas fuentes, la estructura de la información almacenada, restricciones de integridad, dependencias, problemas de seguridad, etc.
  • Comprender todos los procesos del dominio. Tenemos que definir y enumerar todos los procesos de negocio que existen en el dominio del problema (automáticos o no). De esta orma, seremos capaces de implementar mecanismos de alto nivel que faciliten el modelado de dichos procesos.
  • Identificar y clasificar todas la interfaces al exterior del dominio que puedan ser necesarias. También en este punto tenemos que pensar en otras interfaces (además de las ya existentes) que puedan ser necesarias para nuestro dominio.
  • Definir nuevos servicios y los límites de la información para esos servicios.
  • Definir nuevos procesos y los límites de la información para esos procesos. Se trata de diseñar nuevos procesos de negocio que automaticen la interacción entre servicios, así como los flujos de información. No se trata tanto de crear nueva funcionalidad, sino de orquestar servicios y flujos de información existentes.
  • Seleccionar la tecnología(s) que vamos a utilizar. Y que será un mix de de productos y elementos que satisfacen adecuadamente las necesidades en términos de SOA. La tarea de seleccionar la base tecnológica de una implementación SOA no es trivial, por lo que es recomendable iniciarla con un proyecto de tipo piloto.
  • Desplegar esa tecnología.
  • Probar y evaluar.

¿Y en que se traduce todo esto en plataforma Microsoft? Pues como cabría esperar, se traduce en un modelo de arquitectura con una serie de capas en las que tenemos identificados una serie de elementos diferenciados y que podemos mapear con tecnologías existentes:







Post_SOA1 Post_SOA2 Post_SOA3

Cómo vemos en las figuras, la clave de una implementación SOA está precisamente en aquellas capas  en las que SOA actúa como elemento de unión entre los procesos de negocio y la tecnología. Se trata de que SOA facilite el trabajo conjunto y en “armonía” de ambas capas. Por un lado, ha de proporcionar los mecanismos necesarios para habilitar la interacción con el usuario. Por otro, tiene que aportar los mecanismos de transaccionalidad necesarios para integrar la información de diversos sistemas, conseguir que funcionen de manera orquestada y conjunta: que operen como un todo. Pero, ¿qué implicaciones tienen estos requerimientos?


Iteracción con el Usuario


A este nivel necesitamos que el usuario pueda interactuar con la información: experiencia de usuario e iteracción con contenidos, Business Intelligence, colaboración, comunicación, etc. Esto es posible mediante una serie de servicios:



  • Servicios de composición, que permiten encaminar la información según un cierto formato de datos (KPI’s, Dashboards, etc). A este nivel necesitamos elementos como: workflows, servicios de búsqueda, creación de KPI’s, bibliotecas de documentos / formularios (para centralizar el almacenamiento de información), acceder a la información de los sistemas LOB, etc. Si le ponemos nombre a estos elementos dentro de la plataforma Microsoft tendríamos: WF, Microsoft Windows Sharepoint Server, CAB, etc.
  • Servicios de Colaboración, que permiten coger la información que sirven los servicios de composición y distribuirla de manera adecuada: comunicaciones en tiempo real, colaboración offline, online P2P, etc. En este caso, dentro de plataforma Microsoft tendríamos Live Communication Server y Microsoft Sharepoint Office Server.
  • Servicios de Presentación, que cotemplan distintas opciones para visualizar e interactuar con la información: portales, web parts, smart clients, extensiones de cliente Office, clientes móviles, etc. El mapeo correspondiente tecnológico nos lleva a hablar de Microsoft Office Sharepoint server, de Silverlight, Cliente Windows, VSTO, ASP.NET, o Clientes Móviles.

Transacciones de Negocio


Aquí se trata no sólo de integrar sistemas existente dentro de una organización (o más allá de ella), se trata de que trabajen de forma orquestada y conjunta para modelar los procesos de negocio de una organización: tienen que operar como un todo. Para que esto sea posible, se necesitan:



  • Servicios de conectividad, que hagan posible que aplicaciones diversas (en cuanto a tecnología y cometidos) sean capaces de dialogar y entenderse. La implementación de estos servicios se traduce en conceptos ya conocidos: servicios web y adaptadores. Y en plataforma Microsoft hablaríamos de WCF y de los adaptadores de BizTalk Server.
  • Servicios para procesos de negocio, es decir, servicios que nos permitan modelizar los procesos de negocio de nuestra organización, dar una visión alto nivel de los mismos, etc. En este caso nos estamos refiriendo a capacidads presentes en BizTalk Server: orquestaciones (Orchestration Designer integrado en Visual Studio 2005)  y reglas (Business Rules Editor), BAM (Business Activity Monitoring, para ofrecer una vista de negocio de los procesos modelados con orquestaciones), TPM (Trading Partner Management, para la gestión de las relaciones con nuestros socios comerciales).
  • Servicios para la integración de la información, que permiten realizar cierto tratamiento de los datos recogidos de los sistemas existentes. En concreto nos referimos a operaciones como ETL (Extract, Transform & Load) o MDM (Master Data Management). Estas operaciones las tenemos en plataforma Microsoft con SQL Server y los componentes de SQL Server Integration Services y/o SQL Server Analysis Services.
  • Servicios de Mensajería, que habiliten el flujo de información entre aplicaciones dentro de una organización o con organizaciones fuera de los límites de la misma. Por lo tanto, estos servicios son los que permiten modelar escenarios EAI, ESB, P2P o colas de mensajería. Dentro de Microsoft, estos servicios son cubiertos por WCF y BizTalk Server.

¿Cómo puedo saber más sobre SOA y la visión de la misma por parte de Microsoft? Pues hay varias opciones, como siempre, la primera pasa por documentarse bien sobre la visión que Microsoft tiene sobre SOA a partir de documentos como el que os comentaba o bien asistir a eventos como el que tendrá lugar el próximo día 24 de octubre en el museo Thyssen de Madrid: Lanzamiento de BizTalk Server 2006 R2 y en la qué el CIIN participa como patrocinador y ponente (dentro del último track del evento: Extendiendo la Arquitectra Orientada a Servicios (SOA), desde la Empresa al Mundo). La agenda del evento es la siguiente:



 


Agenda:


09:15-09:45 Bienvenida e inicio de las sesiones
09:45-10:15 Seis tendencias tecnológicas que marcarán la próxima década
10:15-11:15 Extendiendo el Negocio Conectado
11:15-11:40 Coffee
11:40-13:10 Soluciones y testimonios de clientes
13:10-14:15 Cocktail


Sesión técnica Biztalk

14:15-14:50 Orquestando la empresa actual, de la fábrica a la tienda
14:50-15:25 Integración B2B-EDI,XML y Web 2.0


15:25-16:00 Extendiendo la Arquitectura Orientada a Servicios (SOA), desde la Empresa al Mundo.



Por supuesto, os animo a que os inscribáis y participéis en este evento que va a resultar muy interesante. Espero que el post os haya resultado de interés.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

9 comentarios en “Service Oriented Architecture (SOA): ¿Por dónde empezar?”

  1. Excelente articulo, realmente muy bien expllicado los conceptos y su redacción.
    Queria hacer una pregunta.
    Sobre la capa de transaccions de negocio en el item de Servicios de procesos de negocio se propone Biztalk Server, ¿cabría poner WWF en vez de biztalk en una SOA mas austera? y que este servicio que da host a un WF orqueste ciertas actividades y reglas de negocio, aunque se pierda la posibilidad de BAM.

  2. Hola Carlos!
    Para responderte a lo que preguntas, te remito a esta entrada en la que se explica cuando aplica BizTalk, cuando WF y cuando SharePoint:
    http://geeks.ms/blogs/ciin/archive/2007/12/06/moss-wf-bts-2006-r2-191-cu-225-ndo-191-d-243-nde-191-sirven-para-lo-mismo.aspx

    Básicamente te diría que no, puesto que WF no te da la capacidad de integración e intercambio de mensajes de manera orquestada que tienes con BizTalk…para conseguir lo mismo con WF, tienes que implementarlo…piensa que en SOA la idea es intercambiar mensajes XML, con WF lo podrías hacer, perio hay que implementarlo. Sin embargo, BTS ya lo tiene y funciona muy bien…aparte tienes toda la capacidad de integración que tiene BTS con sus adaptadores que WF no tiene de serie y que tienes que implementar.

    Un saludo

    JC

  3. Muchas gracias Juan Carlos por tu pronta respuesta. Realmente en tus artículos he encontrado en buena medida lo que he estado buscando pues en estos precisos momentos me encuentro iniciando todo un analisis general y de arquitectura de Software y quiero comenzarlo aplicando esta filosofia SOA pues cuento con las herramientas MS necesarias y realmente me pierdo un poco entre tantos conceptos,y herramientas, pero gracias a tu articulo podré orientar mejor mi búqueda y estudio.
    Nuevamente, Muchas gracias.

  4. Hola Carlos,
    Gracias a ti por tus comentarios…y recuerda que tienes las herramientas, pero lo primero que tienes que tener en tus manos son los requerimientos y necesidades, luego definir la capa de serivicios y finalmente implementarlo con las herramientas Microsoft correspondientes.

    Un saludo

    JC

  5. Hola Juan Carlos:
    Efectivamente tengo las herramientas, pero primero estoy investigando los requerimientos, por el momento ya tengo diagramado en Visio todos los flujos de procesos que se están haciendo a papel y lapiz, creo que eso es un paso importante, pienso tomar uno de ellos y hacer un desarrollo piloto. Además invité a la jefatura de mi lugar de trabajo a que reflexionemos entre todos sobre los pasos a considerar que mencionas arriba, pues cuando me puse a leerlos me di cuenta que tenemos varias lagunas de conocimiento.
    Esta sería mi primera experiencia con este tipo de arquitectura. Me gustaria poder profundizar más en los componentes teoricos de las distintas capas pero la info que encuentro en general está en ppt que en realidad sin un orador se quedan cortas.¿ Sabes de algun libro o documento más profundo?

    Nuevamente muchas gracias!
    Carlos.

  6. Buenos días Carlos,
    Pues un libro muy buen, amplio y quizás demasiado espeso sobre SOA es:

    Service-Oriented Architecture
    Concepts, Technology, and Design
    Thomas Earl
    Editorial: Prentice Hall

    Yo he leido sobre todo literatura disponinble en Internet (y sobre todo de Microsoft). Un saludo

    JC

  7. Buenas Noches me piden que modele al orquestador pero tenia entendido que el oruestador es simplemente una aplicacion por lo que no se como voy a hacer los reqeurimientos funcinales y no funcionales, los casos de uso..etc. te gardesco em coalbores por qeu no entiendo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *