Translate

jueves, 24 de marzo de 2011

¿Que herramienta de registro utilizar?

El objetivo de tener un registro de las funcionalidades desarrolladas es que todos los desarrolladores conozcan las funcionalidades y no exista duplicidad de servicios. Para esto se podría utilizar diferentes herramientas de propósito más general, como una wiki o una base LDAP, pero es mejor utilizar una herramienta de propósito particular. En el mercado existen herramientas open source para el registro de servicios. Entre los más importantes podemos mencionar a MuleSource Galaxy y Registro de WSO2.

MuleSource Galaxy: Esta basado en un diseñador de repositorios para la gestión de artefactos de software basados en SOA. Entre ellos se incluye la configuración del ESB Mule, WSDL, archivos xml y configuración de Spring. Es una perfecta herramienta de registro cuando se utiliza ESB mule ya que se integra totalmente con ese producto.

Registro de WSO2: Esta diseñado para almacenar, catalogar, indexar y gestionar metadatos de empresa relacionados con artefactos SOA. Incluye el control de versiones y su rapidez lo hace un buen candidato para sistemas empotrados.

El producto Galaxy tiene soporte para las mismas funcionalidades generales que el registro de WSO2, como puede ser la categorización de recursos, la monitorización y la gestión de ciclo de vida y de la dependencia. Además, su versión 1.5 incluye nuevas funcionalidades como la replicación (disponible solo la versión de pago) tiene soporte para scritps y una API de eventos.

El producto de registro WSO2 es muy sencillo de utilizar y en este punto supera a Galaxy gracias a su mejor infraestructura para Atom/Rss y sus funcionalidades de control de versiones y de restauración de versiones anteriores.

Las funcionalidades más atractivas de Galaxy se encuentran en la versión de pago mientras que la herramienta de registro de WSO2 es 100% libre y gratuita. Por esta razón y la facilidad de uso, optamos por la herramienta de registro de WSO2.

¿Cómo se desarrolla sobre una arquitectura SOA?

El desarrollo sobre una arquitectura SOA debe siempre tener en cuenta las funcionalidades desarrolladas y debe consumir estos servicios y exponer las nuevas funcionalidades. Por lo tanto es importante tener un registro actualizado donde se registran los servicios desarrollados y si la empresa cuenta con sistemas heredados con servicios expuestos se debe realizar un relevamiento de los servicios desarrollados y reflejarlos en el registro. Que el registro esté actualizado y sea visual para todos los desarrolladores es vital para que no exista comportamiento replicado.

El desarrollador esta obligado a pensar los servicios de forma atómica y desacoplada. Un servicio nunca debe depender de una implementación sino de una interfaz que describe a dicha dependencia, agregando más complejidad a la tarea de diseñar pero disminuyendo el esfuerzo de mantenimiento ante un cambio. Promoviendo el desacoplamiento y la mantenibilidad.

El estilo arquitectónico SOA no es intrusivo, no nos obliga a utilizar una forma propia de SOA para desarrollo, ni un Paradigma de programación, ni un lenguaje, ni plataforma. Pero si nos obliga a no repetir funcionalidad publicada y publicar los servicios de tal forma sean útiles a otros sistemas. Por ejemplo podríamos programar con POO y publicar la funcionalidad por medio de servicios o utilizar el patrón facade. En este esquema los servicios van a seguir la arquitectura SOA, dando la libertad de diseñar nuestros objetos independientes de la arquitectura SOA. Lo más recomendado es utilizar una arquitectura en Capas sumado a la arquitectura SOA.

Una arquitectura en capas nos permite separar de forma lógica las incumbencias generales en capas. El objetivo de separar las incumbencias en capas, es el desacoplamiento. De esta forma podríamos cambiar ciertas capas si necesidad de modificar las demás.

Sumado a la arquitectura SOA con la arquitectura en Capas, aprovechamos lo mejor de los dos mundos.
En la actualidad existen gran cantidad de framework que nos permiten desarrollar servicios web (CXF, Spring WS, Apache AXIS 1 y 2, Metro, etc.) y a la vez existen muchas formas de exponer estos servicios REST, SOAP, Mensajería, etc. y también existen diferentes formatos de datos JSON, SOAP, RSS, ATOM, etc. Todas estas tecnologías pueden conformar mis sistemas lo cual dificulta la comunicación ya que diferentes aplicaciones hablan diferentes idiomas.

Dada esta problemática surgió del mercado un estándar llamado Service Component Architecture (SCA), que propone una forma de desarrollo SOA. Basándose en el concepto de componentes promueve que un componente publica servicios que le permiten hablar idiomas diferentes (más usados) y entender la mayoría de los formatos de datos.

También a raíz de la diversidad de tecnologías para exponer servicios nace el ESB, que como dijimos anteriormente es un adaptador de diferentes “lenguajes”. Por lo tanto podríamos decidir utilizar un framework para exponer servicios y un ESB con su adaptador, o desarrollar con SCA. Dependiendo de los requerimientos se debe realizar una elección.


EAI (Enterprise Application Integration)

EAI (Enterprise Application Integration, traducido al español como integración de aplicaciones empresariales) es definido como el uso de software y sistemas de computadora para integrar un conjunto de aplicaciones.
El propósito de la EAI es lograr la interoperabilidad y organización del flujo de información entre aplicaciones heterogéneas, es decir, asegurar la comunicación entre las distintas aplicaciones y formar el sistema de información de la empresa, incluso de los clientes, socios o proveedores.

Por lo tanto, y en primer lugar, un proyecto de EAI implica implementar una arquitectura bajo la cual las distintas aplicaciones se comuniquen entre sí. En consecuencia, esto conlleva el desarrollo de conectores (middleware) que posibilitan la interfaz de aplicaciones mediante el uso de distintos protocolos de comunicación (por lo general exclusivos).

Sin embargo, el proyecto de EAI va más allá de la interoperabilidad de las aplicaciones: ofrece la posibilidad de definir un workflow entre las aplicaciones; así, representa una alternativa a la ERP1 con un enfoque más modular.
No obstante, la EAI todavía presenta limitaciones relacionadas con la rigidez de los sistemas heredados (en inglés legacy), porque se debe modificar el middleware cuando hay cambios importantes en las aplicaciones.

Cuando los sistemas no pueden compartir su información efectivamente se crean cuellos de botella que requieren de la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la información. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor en lugar de enfocarse en la coordinación de labores operativas.

Durante varias generaciones, los sistemas de las empresas han servido para un propósito especifico a un único usuario o grupo de usuarios, los cuales actúan como la interfaz de dicho sistema con el resto de la organización, con lo cual se ha limitado su conexión con otros sistemas modernos o más amplios en la empresa, más aún por la creciente demanda de las empresas por compartir datos y usarlos en sus procesos sin tener que realizar cambios en sus aplicaciones o en sus estructuras de datos.

Uno de los retos que encaran las organizaciones modernas es darles a sus empleados información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de mover esta información entre las aplicaciones.

EAI, como una disciplina, busca solventar muchos de esos problemas, así como crear nuevos paradigmas para ciertamente mejorar las organizaciones, tratando de trascender el objetivo de conectar las aplicaciones individuales para buscar ser un mecanismo de incrementar el conocimiento de la organización y crear ventajas competitivas futuras a la empresa.

La integración de aplicaciones de empresa ha incrementado su importancia porque la computación en las empresas frecuentemente toma la forma de islas de información. Esto ocasiona que el valor de los sistemas individuales no sea aprovechado al máximo debido a su mismo aislamiento.

Si la integración se aplica sin seguir un enfoque estructurado de EAI, las conexiones punto a punto crecen al interior de la organización resultando en una masa imberbe que es difícil de mantener. Esto se denota normalmente como el espagueti, en alusión al equivalente en programación: el código espagueti.
EAI puede ser usado con diferentes fines:
  • Integración de datos (información): asegurando que la información en varios sistemas es consistente. Esto también se conoce como EII (Enterprise Information Integration).
  • Integración de procesos: enlace de los procesos de negocios entre diferentes aplicaciones.
  • Independencia de proveedor: extrayendo las políticas o reglas del negocio de las aplicaciones e implementándolas en un sistema EAI, de forma que cualquiera de las aplicaciones usadas pueda ser cambiada sin que dichas reglas de negocio deban ser reimplementadas.
  • Facade común: Un sistema EAI puede actuar como el front-end de un cúmulo de aplicaciones, proporcionando una interfaz de acceso única y consistente a esas aplicaciones y aislando a los usuarios sobre la interacción con distintas aplicaciones.

CEP (Complex Event Processing) y ESP (Event Stream Processing)

Las tecnologías emergentes como el Procesamiento de Eventos Complejos (Complex Event Processing o CEP) y el Procesamiento de Flujos de Eventos (Event Stream Processing o ESP) han comenzado a ocuparse de problemas de mayor complejidad que no podían resolverse con el procesamiento de eventos tradicional. Por ejemplo, con CEP se puede analizar, correlacionar y resumir eventos de bajo nivel en eventos de más alto nivel adecuados para informar a las personas en términos humanos o para desencadenar procesos automáticos. CEP y ESP emplean técnicas como la detección de patrones complejos en numerosos eventos, utilizando algoritmos de procesamiento de reglas para la correlación y abstracción de eventos, empleando jerarquías de eventos y relaciones entre los eventos. Los análisis de causalidad, membrecía, oportunidad y procesos impulsados por eventos son capacidades centrales de estas tecnologías.

ESP y CEP se consideran parte de una tendencia más extensa llamada EDA (event-Driven Architecture) EDA es un estilo arquitectónico, que esta centrado en comunicaciones asíncronas basadas en eventos. Es totalmente complementario a SOA y utiliza mensajes asíncronos en lugar de llamadas a funciones al estilo RPC, para realizar computación distribuida. Un evento es simplemente la acción de algo que está ocurriendo, bien sea un pedido, un aviso de entrega o la finalización del trabajo de un empleado. El sistema que registra el evento (también llamado sensor) genera un objeto de eventos que se envía mediante una notificación. El consumidor de la notificación o receptor puede ser otro sistema que por su parte, utilice el evento para iniciar alguna acción como respuesta. Aquí es donde el concepto de ESP entra en juego.

ESP permite analizar los procesos e identificar eventos inusuales, lo que permite a raíz de estos eventos informarlos o ejecutar algún proceso. Por ejemplo una persona que saca del cajero un monto inusual de dinero el sistema podría enviar un e-mail al cliente notificando la extracción. Otro ejemplo podría ser: un servicio demora más de lo normal esto puede generar un evento el cual sea notificado a un servicio que informe al administrador.

Implementar ESP en una arquitectura SOA nos facilita su mantenimiento y permite manejar eventos complejos de una forma fácil.

BPEL

Business Process Execution Language (lenguaje de ejecución de procesos de negocio), se trata de un lenguaje XML para la especificación de procesos de negocio ejecutables, aplicado principalmente a la orquestación de los servicios web. BPEL es un subconjunto de BPM. Definido para representar workflows de servicios web.

La interacción entre servicios web puede ser descripta de dos formas: procesos de negocio ejecutable y procesos de negocio abstracto.
  • Proceso de negocio ejecutable: es el comportamiento real de un participante de una interacción.
  • Proceso de negocio abstracto: es el proceso que no está destinados a ser ejecutados, puede ocultar algunos de los detalles necesarios de las operaciones concretas. Los Procesos abstractos desempeñan una función descriptiva, con más de un caso de uso posible, incluyendo el comportamiento observable y plantilla de proceso. Un proceso abstracto que incluye información como cuándo es mejor esperar para mensajes, cuándo enviar mensajes, cuándo compensar las transacciones fallidas, etc.
BPEL provee un lenguaje para la especificación de Procesos de negocios Ejecutables y Abstractos. De este modo, se extiende el modelo de servicios Web y la posibilidad de interacción para apoyar las transacciones comerciales. WS-BPEL define un modelo de integración interoperable que debería facilitar la expansión de la integración de procesos automatizados, tanto dentro como entre las empresas.

Bpel fue diseñado con los siguientes objetivos:
  1. Definir procesos de negocio que interactúan con entidades externas a través de operaciones de Web services definidas en archivos WSDL, y que se manifiestan en los servicios Web definen utilizando WSDL.
  2. Esta basado en xml. No define una representación gráfica de procesos, ni provee algún particular metodología de diseño.
  3. Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio.
  4. Proveer sistemas de control jerárquicos y de estilo grafo, que permitan que su uso sea lo más fusionado e inconsútil posible. Esto reduciría la fragmentación del espacio del modelado de procesos.
  5. Proveer funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control.
  6. Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. Los identificadores de instancias deben ser definidos por socios y pueden cambiar.
  7. Brindar la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida. Operaciones avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar" pueden agregarse en futuras versiones para mejorar el manejo del ciclo de vida.
  8. Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera a brindar recuperación a fallos para partes de procesos de negocios de largo plazo.
  9. Usar servicios Web como modelo para la descomposición y ensamblaje de procesos.
  10. Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y extensible.
BPEL es una herramienta concebida para diseñar workflows basados en web services, esto lo hace una herramienta más apta que BPM para la orquestación de servicios SOA. BPM es más amplio y menos específico para SOA por estas razones nace BPEL. Un lenguaje más específico que suple las deficiencias que tiene BPM.

BPM

BPM (Business Process Management) podría ser definido como un Flujo de trabajo o workflow1, es una forma de representar los procesos, los cuales son seguidos por el sistema. Permitiendo en tiempo de ejecución modificar el workflow y que se aplique estos cambios sin volver a compilar ni a bajar o subir la aplicación.

BPM marca al sistema el orden de ejecución de procesos dando la flexibilidad para poder modificar este orden cuando se lo desee. Esto permite centrarse en la lógica de negocio dando el poder de decisión al usuario final el cual por medio de un editor puede modificar el workflow como crea más conveniente. Se centra en el negocio.
BPM es un concepto muy sencillo. Es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales; un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno.

El objetivo de una solución para la gestión de procesos de negocio es proporcionar, dentro de las TI, implementaciones automatizadas de procesos de negocio de la vida real, como por ejemplo los procesos de pedidos y cobros, o de gestión de reclamaciones. Combinada con una SOA, esta forma de proporcionar funcionalidades de TI, con una visión orientada a procesos.

La tecnología BPM incluye lo necesario para diseñar, representar, analizar y controlar los procesos de negocio operacionales:
  • El diseño y modelado de procesos posibilitan que, de forma fácil y rigurosa, pueda definir procesos que abarcan cadenas de valor y coordinar los roles y comportamientos de todas las personas, sistemas y otros recursos necesarios.
  • La integración le permite incluir en los procesos de negocio cualquier sistema de información, sistema de control, fuente de datos o cualquier otra tecnología. La arquitectura orientada a servicios (SOA) lo hace más rápido y fácil.
  • La ejecución convierte de forma directa los modelos en acción del mundo real, coordinando los procesos en tiempo real.
  • La supervisión de la actividad de negocio (BAM) realiza el seguimiento del rendimiento de los procesos mientras suceden, controlando muchos indicadores, mostrando las métricas de los procesos y tendencias clave y prediciendo futuros comportamientos.
  • El control le permite responder a eventos en los procesos de acuerdo a las circunstancias, como cambio en las reglas, notificaciones, excepciones y transferencia de incidentes a un nivel superior.
Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management System y con ellas se construyen aplicaciones BPM.

BPM no esta acoplado al mundo SOA, se puede controlar procesos de una aplicación usando BPM sin tener servicios web. Pero BPM se puede utilizar para modelar flujo de trabajo llamando servicios web. Permitiendo una gran flexibilidad el flujo de trabajo no depende de una aplicación sino que esta constituido por servicios referenciados por una URI. El motor BPM no esta acoplado a implementaciones sino que conoce solo interfaces dadas por WSDLs o otros descriptores desacoplando el motor BPM de los servicios. Además se puede extender el motor BPM para que ofrezca información del workflow por servicios web. Proporcionando funcionalidades completas por servicios web.

WS-CDL

Cuando hablamos de coreografía de Servicios Web se debe mencionar a WS- CDL (Web Services Choreography Description Language) y por tanto de colaboración entre actores; es decir, de interacciones entre servicios web. Este lenguaje, basado en XML, permite lograr interacción entre servicios Web. Dicha interacción es independiente del lenguaje o de la plataforma utilizada.

La coreografía es una visión más abstracta y descriptiva de los actores que intercambian mensajes para ejecutar varios procesos particulares (varios flujos de control). WS-CDL tiene como propósito definir la interoperabilidad necesaria para crear un sistema compuesto por servicios web.

Orquestación y Coreografía

La integración se debe llevar a cabo mediante un mecanismo que permita que los servicios cooperen entre ellos. Para ello comúnmente se utilizan dos términos: La orquestación y la coreografía. Hablamos de orquestación de servicios cuando es controlado por una única unidad, es decir un cliente y un servicio establecen un acuerdo con respecto al transporte de mensajes y al contenido. Un proceso es una coreografía de servicios cuando las colaboraciones son definidas entre cualquier tipo de aplicaciones.

La coreografía brinda reglas que revelan como múltiples componentes pueden colaborar entre pares, lo que denominamos peer-to-peer, y de que forma o en que secuencia. Esta colaboración se realiza mediante el intercambio de mensajes. Una coreografía describe la colaboración entre más de un servicio para lograr un objetivo común. Por lo tanto no se centra en un servicio en particular, pero si en un objetivo que tiene que cumplir el flujo de proceso. Para ello, la lógica de control es distribuida sobre los servicios participantes. Para diseñar una coreografía, se debe describir primero las interacciones que los servicios tienen que realizar entre sí para cumplir el objetivo y las relaciones que existen entre estas interacciones. Una coreografía no describe las acciones que son realizadas internamente por el servicio principal para realizar el flujo de procesos.

Si usted alguna vez pudo apreciar una presentación de ballet, puede haberse percatado como cada integrante del equipo (servicios) inicia y finaliza un conjunto de movimientos (flujo de proceso), estos movimientos siguen una trilla (interacciones entre los servicios) musical determinada.

Una orquestación describe el comportamiento que el servicio principal implementa para realizar un flujo de proceso. Esto quiere decir, que el enfoque se centra sobre un servicio en particular, y la lógica de control es centralizada sobre el servicio principal el cual implementa el comportamiento. Para diseñar una orquestación, se describe las interacciones que el servicio principal tiene con las otras partes (servicios, adaptadores, interfaces, etc.) y las acciones que el servicio principal realiza internamente para realizar el flujo de proceso. Una orquestación es ejecutada por una máquina de orquestación. Por lo que es llamado proceso ejecutable.

Para entender mejor la definición de orquestación, imagine como un maestro de una orquesta sinfónica dirige y controla a cada uno de los integrantes (servicios) de la orquesta con el fin de poder lograr un objetivo común (un flujo de proceso), que es el de poder establecer una melodía armoniosa basada en un conjunto de especificaciones (objetivo principal y interrelaciones entre servicios) que contienen las notas, que instrumentos deben tocarse, que notas deben tocar cada uno de esos instrumentos y cuando deben iniciar o detener sus melodías.

Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores). Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio de diversos servicios web.
La orquestación es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). La Orquestación podría verse como la ejecución de un proceso de negocio definido en BPM o BPEL y que puede ser ejecutado por un motor BPM o BPEL.

La coreografía se define mediante WS-CDL y la orquestación puede definirse con BPM o BPEL.

Herramienta SOA: Registro o repositorio

Sólo se puede gobernar lo que se ve, por lo tanto, el primer paso es crear un único catálogo maestro en el que estén visibles, para todas las partes interesadas, los elementos más importantes de su SOA. El registro/repositorio se ha erigido en el estándar para la creación de este tipo de sistema de registros.

El registro es donde se publican los servicios y es donde se debe consultar los servicios existentes para poder consumirlos.

El registro puede ser desde una base de datos LDAP a una entrada en wiki de la empresa, dependiendo de los requerimientos de la empresa. Pero siempre debe tener al menos esta información:
  • Punto final del servicio (donde esta publicado).
  • Descripción del servicio.
  • Ubicación WSDL si usamos servicios SOAP o como se utiliza el servicio.
  • Numero de revisión y versión.

Gobierno SOA

Los servicios por si solos son incompletos, necesitan una arquitectura que los mantenga y soporte sus ventajas. Por ejemplo a la hora de desarrollar un nuevo servicio ¿cómo se si no existe ya? O ¿existen servicios que pueden ayudar al nuevo servicio? Por lo tanto debo tener un registro donde registrar mis servicios, en el cual puedo buscar los servicios ya existentes.

El gobierno SOA es el conjunto de roles, políticas y procedimientos que sirven de guía para la adopción de la SOA. Al implementar los componentes tecnológicos de gobierno, está creando la infraestructura para soportar y aplicar estos roles, políticas y procedimientos en toda su SOA.

Luego de desarrollar los servicios hay que gestionarlos, la gestión de los servicios se le llama gobierno SOA.

Gobierno de SOA es una ampliación del gobierno de IT centrada en el ciclo de vida1 de los servicios y en las aplicaciones compuestas en una arquitectura orientada a servicios (SOA) de una organización. La función del gobierno de SOA es definir:
  • Derechos para tomar decisiones para el desarrollo, el despliegue y la gestión de nuevos servicios.
  • La supervisión y notificación de procesos para capturar y comunicar los resultados del gobierno. Debido a que las aplicaciones SOA están intrínsecamente fragmentadas, introducen nuevos retos de gobierno. No obstante, con políticas, principios, estándares y procedimientos adecuados, los empresarios pueden darse cuenta de todas las ventajas que ofrece la arquitectura orientada a servicios. Una plataforma de gobierno de SOA eficaz no sólo ayuda a los equipos de IT y negocio a identificar mejor qué proyectos contribuyen más a los objetivos empresariales, sino que también dotan de más facilidades a los empleados para trabajar y colaborar de forma más eficaz definiendo claramente sus roles y sus responsabilidades.
El Gobierno SOA pretende dotar de los mecanismos de control, procesos, procedimientos y métodos probados en la práctica para garantizar el orden en las decisiones que se tomen en una iniciativa SOA, evitando el caos en cualquier proyecto SOA que se plantee, logrando la efectividad y agilidad esperada en la transición hacia SOA.

El Gobierno se refiere a los procesos que una empresa establece para garantizar que las acciones realizadas se adhieren a las mejores prácticas, normativas, estándares y principios de arquitectura, con objeto de gobernar la adopción e implementación de SOA.

La ausencia del Gobierno SOA puede desembocar en los siguientes problemas:
  • El Programa SOA entrega resultados inconsistentes.
  • Crecimiento caótico a nivel de infraestructura y servicios.
  • Servicios con funcionalidad redundante.
  • Disponer de servicios que no se pueden reutilizar en la organización.
  • Inconsistencia en la identificación, diseño y uso de los servicios.
  • No se definen métricas para cuantificar el éxito.
  • Ausencia de coordinación entre proyectos.
La definición de una Estrategia de Gobierno SOA proporciona la coherencia necesaria para todas las acciones que se lleven a cabo en un Plan de Adopción SOA, siguiendo un enfoque incremental de adopción en distintas fases para reducir riesgos, y proporcionando un modelo de gobierno que constituya un marco de referencia para las decisiones que se tomen.

Por lo tanto podríamos definir a SOA como la suma de servicios y gobierno SOA.

El Gobierno SOA comprende varias herramientas que permiten gobernar los servicios:
  • Registro de servicios, permite registrar nuestros servicios y consultar servicios existentes.
  • Bus de servicios o ESB (Enterprise Service Bus) facilita la comunicación entre diferentes servicios.
  • Orquestación y coreografía, herramienta que permite definir la interoperabilidad de los servicios.
  • CEP (Complex Event Processing) y Procesador de flujos de eventos o ESP(Event Stream Processing) son herramientas para diseñar, gestionar y monitorizar los eventos que fluyen a través de un entorno orientado a EDA dado.
  • Integración de aplicaciones empresariales o EAI (Enterprise Application Integration) facilita la integración con aplicaciones o bases de datos de una empresa.
A la vez existen muchos frameworks que nos permiten desarrollar servicios SOA, con mayor flexibilidad y rapidez. Permitiendo obtener más fácilmente los beneficios del uso SOA y a la vez preparados para ser Gobernados por el gobierno SOA. En la tesis nos centraremos en el estándar de OASIS4, SCA (Service Component Architecture). SCA es un estándar que simplifica el desarrollo SOA basándose en el concepto de componentes. Nos centraremos en esta especificación dado que brinda gran facilidad en el desarrollo, además promueve el uso de las mejores prácticas.

No necesariamente se deben tener todas las herramientas descriptas para conformar el gobierno SOA. Se deben adoptar las herramientas que satisfagan las necesidades propias de la empresa que adopta SOA.

Servicios.

Los servicios son funcionalidad necesaria para la empresa, es decir son funcionalidad expuesta a otros servicios, sistemas o una interfaz gráfica. Los cuales fueron concebidos para solucionar un requerimiento. Los servicios son los ladrillos de nuestra arquitectura SOA. Ellos pueden contener lógica de negocio, acceso a bases de datos, accesos a otros servicios, etc.

Los servicios están descriptos en una interfaz que indica como utilizarlos. Pero los servicios nunca exponen como funcionan; son una caja negra. Lo que permite cambiar un servicio fácilmente por otro, favoreciendo la mantenibilidad y agilidad de desarrollo. Los servicios exponen como se utilizan pero no exponen como funcionan.

Los servicios pueden acoplarse para formar nuevos servicios, que solucionan nuevos requerimientos, esto ayuda a que no se duplique el código. Los servicios son atómicos y sin estado lo que permite distribuirlos en diferentes maquinas favoreciendo la escalabilidad de los sistemas.

¿Que define la Arquitectura SOA?

La arquitectura SOA define :
  • Los servicios.
  • Como localizar un servicio.
  • Como conseguir que se comuniquen diferentes servicios.
  • Como encajar diferentes servicios para que funcionen como un sistema.
En una SOA, los servicios se encuentran documentados en un repositorio denominado registro, se ensamblan mediante las llamadas aplicaciones compuestas, y el plano que le sirve de guía es lo que se conoce como esquema global de la SOA.

¿Que es SOA?


Todo el mundo habla de SOA, que SOA esto que una arquitectura SOA es mejor, bla, bla... Pero que es SOA? En este post vamos a intentar dar una idea general.
En la Facultad nos enseñan que para comprender una realidad compleja se debe dividirla y de esta manera analizar cada componente y comprenderlo para luego analizar la totalidad de la realidad. Utilizaremos este método para definir la Arquitectura Orientada a Servicios. Primero analicemos el término servicio.
Servicio tradicionalmente se ha utilizado para describir una función de negocio autocontenida, con una interfaz bien definida y estable, que recibe requerimientos de sus clientes. El servicio no depende del contexto de sus clientes y puede ser consumido por varios sistemas sin ser modificado. Los servicios son instalados (o desplegados) una única vez, esto lo diferencia de los componentes que deben ser incluidos dentro del contexto de cada aplicación que requiera de su uso y permanecen disponibles, sin consumir recursos hasta que son invocados.

Propiedades de un servicio:
  • Interfaz bien definida.
  • Autocontenido.
  • No depende del contexto de sus clientes.
  • No requiere ser desplegado con cada cliente.
Luego de definir servicio especificaremos arquitectura. Una definición reconocida es la de Clements: “La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones”.

Una vez aclarada la definición de servicio y arquitectura, podemos avanzar sobre la de SOA. Se podría definir como un estilo arquitectónico que propone modelar la empresa como una colección de servicios expuestos en la red. Nos propone ver a la empresa no como sistemas aislados sino como un todo.

La principal utilidad de los servicios web es que promueven la interoperabilidad entre diferentes plataformas, sistemas y lenguajes. Con servicios web, por ejemplo, sería posible integrar una aplicación Windows desarrollada con Microsoft .NET con una aplicación desarrollada en JEE desplegada en un servidor de aplicaciones bajo un sistema Linux.
Alrededor de los Web services, que dominan el campo de un estilo SOA más amplio que podría incluir otras opciones, se han generado las controversias que usualmente acompañan a toda idea exitosa. Al principio hasta resultaba difícil encontrar una definición aceptable y consensuada que no fuera una fórmula optimista de mercadotecnia. El grupo de tareas de W3C, por ejemplo, demoró un año y medio en ofrecer la primera definición canónica adecuada, que no viene mal reproducir aquí:“Un Web service es un sistema de software diseñado para soportar interacción máquina-a-máquina sobre una red. Posee una interfaz descripta en un formato procesable por máquina (específicamente WSDL3). Otros sistemas interactúan con el Web service de una manera prescripta por su descripción utilizando mensajes SOAP, típicamente transportados usando HTTP con una serialización en XML en conjunción con otros estándares relacionados a la Web”
Un servicio es una entidad de software que encapsula funcionalidad de negocios y proporciona dicha funcionalidad a otras entidades a través de interfaces públicas bien definidas.
Los componentes del estilo (o sea los servicios) están débilmente acoplados. El servicio puede recibir requerimientos de cualquier origen. La funcionalidad del servicio se puede ampliar o modificar sin rendir cuentas a quienes lo requieran. Los servicios son las unidades de implementación y diseño.

Como todos los otros estilos, las SOA poseen ventajas y desventajas. Como se trata de una tecnología que está en su pico de expansión, sus virtudes y defectos varían con el tiempo.



Un sistema sencillo basado en servicios. Una aplicación además de implementar sus propios componentes de negocio y datos, también puede reutilizar la funcionalidad de servicios existentes en la red empresarial.

SOA no es un concepto concreto para un área de la empresa, sino que dependiendo del punto de vista que se emplea. Ya que un ejecutivo de negocio lo puede ver como un conjunto de servicios de negocio, un arquitecto de software lo verá como un estilo arquitectónico y el desarrollador un conjunto de estándares, herramientas y tecnologías concretas que permiten llevar a cabo sus tareas.

Actualmente en el mercado se encuentran múltiples frameworks para implementar el modelo SOA, algunos basados en el modelo empresarial de Java y otros no. Además hay que analizar la madurez de la solución y la aceptación que tiene en los programadores.

lunes, 21 de marzo de 2011

Reia la fusión de Erlang y Ruby.


Reia es un lenguaje de programación script inspirado en Ruby que corre sobre la maquina virtual de Erlang. Reia une lo mejor de los dos mundos Ruby y Erlang. Reia tiene reflexion, meta-programación, bloques de código, manejo de concurrencia mediante el modelo de actores, distribuido, hot code y tolerancia a fallos.

Veamos de la pagina de Reia una pequeña muestra del lenguaje:

# Hello, world!
"Hello, world!".puts()

# Assignment
number = 42
opposite = true

# Conditions
number = -42 if opposite

# Lists (stored as immutable singly-linked lists)
list = [1, 2, 3, 4, 5]

# Tuples (think of them as immutable arrays)
tuple = (1, 2, 3, 4, 5)

# Atoms (known as symbols to Ruby people)
# Think of them as an open-ended enumeration
atom = :up_and_atom

# Dicts (also known as hashes to Ruby people)
dict = {:foo => 1, :bar => 2, :baz => 3}

# Strings (unlike Erlang, Reia has a real String type!)
string = "I'm a string! Woohoo I'm a string! #{'And I interpolate too!'}"

# Ranges
range = 0..42

# Funs (anonymous functions, a.k.a. lambdas, procs, closures, etc.)
# Calling me with plustwo(40) would return 42
plustwo = fun(n) { n + 2 }

# Modules (collections of functions)
# Calling Plusser.addtwo(40) would return 42
module Plusser
def addtwo(n)
n + 2
end
end

# Classes (of immutable objects. Once created objects can't be changed!)
class Adder
# Reia supports binding instance variables directly when they're passed
# as arguments to initialize
def initialize(@n); end

def plus(n)
@n + n
end
end

# Instantiate classes by calling Classname(arg1, arg2, ...)
# For you Ruby people who want Classname.new(...) this is coming soon!
fortytwo = Adder(40).plus(2)

# Function references can be obtained by omitting parens from a function call,
# like JavaScript or Python
numbers = [1,2,3]
reverser = [1,2,3].reverse

# Function references can be invoked just like lambdas
reversed = reverser() # reversed is now [3,2,1]

# You can add a ! to the end of any method to rebind the method receiver to
# the return value of the given method minus the bang.
numbers.reverse!() # numbers is now [3,2,1]

# List comprehensions
doubled = [n * 2 for n in numbers] # doubled is [6,4,2]

### Numbers

42 # integer
4.2 # float

### Booleans

true # All expressions evaluate true in a boolean context except false and nil
false
nil

### Atoms (an open enumeration, like Ruby's symbols)

:foobar # A simple atom
:"I am the very model of a modern major general" # quoted

### Lists

list = [3,4,5] # lists are singly linked and good for ordered sequences
list2 = [1,2,*list] # the splat operator lets you prepend to an existing list
[1,2,3,*rest] = list2 # splats match patterns. rest is now [4,5]
five = list[2] # List#[] retrieves the nth (zero indexed) member

### Tuples

tuple = (1,2,3) # tuples are immutable arrays
two = tuple[1] # Tuple#[] retrieves the nth (zero indexed) member
# Tuple#[]= produces new versions of a tuple and binds them to the receiver
tuple[1] = 42 # tuple is now (1,42,3)
tuple[2] += 40 # tuple is now (1,42,43)

### Dicts

dict = {:foo => 1, :bar => 2, :baz => 3} # Dicts are key/value maps
bar = dict[:bar] # Use Dict#[] to retrieve a value for a given key. bar is 2
dict[:bar] += 40 # Dict#[]= alters the value of a member

### Strings

"Ohai!" # strings can be double quoted
'Ohai!' # or single quoted
"Ohai, #{name}!" # double quoted strings interpolate
'Ohai, #{name}!' # single quoted strings interpolate too

### Binaries

<[1,2,3]> # binaries allow you to store binary data without stringy fluff
<["string"]> # you can make binaries from strings, too
<[1,2,x]> = <[1,2,3]> # pattern matching can be used with binaries too

### Regexps

%r/^.{3}/ # I'm a regex literal! (Soon %r will go away and /.../ will work)
%r/^.{3}/.match("foo bar baz") # Returns "foo"

### Ranges

1..10 # I'm a range!
(1..10).to_list() # Returns [1,2,3,4,5,6,7,8,9,10]
[n * 2 for n in 1..10, n % 2 == 1] # List comprehension of a range, returns [2,6,10,14,18]

### Funs (a.k.a. anonymous functions or lambda expressions)

adder = fun(x, y) { x + y }
adder(40, 2) # returns 42

multipler = fun(x, y) do
x * y
end

multiplier(7, 6) # returns 42

Como siempre dejo link:


jueves, 17 de marzo de 2011

Apache Shiro


Apache Shiro es un poderoso y fácil de usar framework para la seguridad de nuestras aplicaciones echas en java. Este framework provee autorización, autenticación, criptografía y manejador de sessiones y además puede ser usado en diferentes aplicaciones, desde una aplicación de lineas de comando, una aplicación móvil o empresarial

Shiro proporciona una API para llevar a cabo los siguientes aspectos:

  • Autenticación - que verifique la autenticidad del usuario, a menudo llamada "entrada" del usuario.
  • Autorización - control de acceso
  • Criptografía - proteger u ocultar los datos de miradas indiscretas
  • Gestión de sesiones - el estado del usuario en el tiempo

Shiro también es compatible con algunas características auxiliares, tales como seguridad de aplicaciones web, pruebas unitarias, y el soporte a multi-hilo, pero estos aspectos existen para reforzar las cuatro principales preocupaciones.

Como todos los proyectos apache es open source y ademas es Apache Software Foundation Top Level Project.

Muchas comunidades open-source estan usando Shiro por ejemplo: Spring, Grails, Wicket, Tapestry, Tynamo, Mule y Vaadin, entre otros.

Como siempre dejo links:

http://www.infoq.com/articles/apache-shiro
http://shiro.apache.org/
http://shiro.apache.org/10-minute-tutorial.html