To ensure delivery directly to your inbox, please add reply@oracle-mail.com to your address book today.
If you are having trouble viewing this newsletter, please click here.
If you are having trouble viewing this newsletter, please click here.
| ||||||||||||||||||||||||||
|
Mostrando las entradas con la etiqueta SOA. Mostrar todas las entradas
Mostrando las entradas con la etiqueta SOA. Mostrar todas las entradas
martes, 12 de agosto de 2014
Oracle Service Bus: SOA Reference Architecture Design Patterns
Quiero compartir el siguiente curso de oracle:
domingo, 4 de marzo de 2012
Resource-oriented architecture
Resource-oriented architecture (ROA) es un estilo arquitectónico basado en Rest, como sabrán SOA es un estilo arquitectónico que indica que funcionalidades del negocio deben estar colgadas es servicios web (normalmente) lo cual permite desacoplamiento de funcionalidad de negocio y reutilización. ROA en cambio no se basa en exponer funcionalidad sino recursos. Lo cual marca una diferencia importante con SOA, SOA se centra en verbos "realizar movimiento bancario" mientra que ROA se basa en los sustantivos "movimientos bancarios".
ROA se basa en REST para exponer los recursos, es decir usa todas las características de REST por lo tanto expone los recursos con URL RestFul. Es decir el movimiento bancario va estar en /movimiento-bancario y se lo va a poder crear con el método PUT, listar con el GET, modificar con POST y borrar con DELETE.
ROA propone exponer los recursos, de forma tal que sea muy similar a la forma que accedemos a base de datos; select - GET, delete - DELETE, update - POST, insert - PUT. Dando una forma clara de acceder, borrar y modificar cada uno de los recursos.
También al basarse en REST se crean arquitecturas livianas flexibles.
Personalmente creo que la gran desventaja es que no contamos con todo el estándar ws-* y el conjunto de herramientas que permiten la orquestación,interacción, seguridad, etc. que si nos brinda SOA.
Creo que el tiempo va a coronar un ganador por ahora a utilizar la mejor herramienta para los problemas particulares y hacer camino al andar!
Dejo Links:
http://en.wikipedia.org/wiki/Resource-oriented_architecture
http://www.infoq.com/articles/RESTSOAFuture
ROA se basa en REST para exponer los recursos, es decir usa todas las características de REST por lo tanto expone los recursos con URL RestFul. Es decir el movimiento bancario va estar en /movimiento-bancario y se lo va a poder crear con el método PUT, listar con el GET, modificar con POST y borrar con DELETE.
ROA propone exponer los recursos, de forma tal que sea muy similar a la forma que accedemos a base de datos; select - GET, delete - DELETE, update - POST, insert - PUT. Dando una forma clara de acceder, borrar y modificar cada uno de los recursos.
También al basarse en REST se crean arquitecturas livianas flexibles.
Personalmente creo que la gran desventaja es que no contamos con todo el estándar ws-* y el conjunto de herramientas que permiten la orquestación,interacción, seguridad, etc. que si nos brinda SOA.
Creo que el tiempo va a coronar un ganador por ahora a utilizar la mejor herramienta para los problemas particulares y hacer camino al andar!
Dejo Links:
http://en.wikipedia.org/wiki/Resource-oriented_architecture
http://www.infoq.com/articles/RESTSOAFuture
lunes, 19 de diciembre de 2011
domingo, 4 de septiembre de 2011
Arquitectura Orientada a Servicios
La Arquitectura de Empresa y Arquitectura orientada a servicios le ayudan a mantener el control sobre la complejidad en un mundo siempre cambiante.
Frente a los rápidos cambios - a partir de la creciente globalización, la consolidación de la industria y los mercados emergentes – las organizaciones necesitan ser ágiles en los negocios, así como en TI. Los cambios estratégicos en las actividades empresariales deben ser apoyados por sistemas flexibles y ágiles de TI. La información tiene que ser abierta en forma estandarizada y las transformaciones de negocio y de TI tienen que ser apoyadas por planes de trabajo alineados.
Según Gartner, en 2011 un ochenta por ciento de las organizaciones de todo el mundo se habrán cambiado a SOA, este porcentaje fue mucho menor sin embargo en inegable que las organizaciones se interesan por migrar a una arquitectura abierta orientada a Servicios. La razón: los modelos SOA hacen que sea mucho más fácil adaptar los procesos de negocio a los cambios del mercado que mediante las arquitecturas tradicionales de software. Como ha ocurrido muy a menudo en el pasado, las grandes compañías fueron las pioneras en este desarrollo. Gracias a soluciones inteligentes y modulares, este cambio de paradigma se ha hecho ahora atractivo y factible también para las compañías de tamaño mediano, por tanto se puede afirmar que el futuro pertenece a las arquitecturas orientadas a servicios (SOA).
En una empresa pueden coexistir varias aplicaciones. Esto lleva a una serie de inconvenientes que aumentan el esfuerzo y el tiempo en que se responde a un requerimiento determinado. Uno de los inconvenientes es, por ejemplo, ante aplicaciones diferentes probablemente desarrolladas en lenguajes diferentes, no poder acceder desde una de las aplicaciones hacia la otra para consultar algún dato.
Mediante la aplicación de la Arquitectura SOA se pretende solucionar los inconvenientes antes mencionados. Dentro de la arquitectura SOA la funcionalidad se implementa en pequeños componentes autónomos reutilizables denominados servicios.
SOA obtiene una integración de aplicaciones o componentes, uniendo la tecnología de información con las necesidades del negocio, logrando una respuesta rápida con un bajo acoplamiento, un ambiente operativo integrado que provee servicios para integrar personas, procesos e información.
El hecho de optar por este tipo de arquitectura requiere de una infraestructura de comunicación, en este caso la arquitectura orientada a servicios utiliza ESB (Enterprise Service Bus). Según Craggs es una plataforma basada en estándares que incluye funciones básicas como servicio de mensajería, servicios Web, enrutamiento inteligente y transformación de datos para conectar y coordinar la interacción de un número significativo de aplicaciones de empresas extendidas con integridad transaccional.
SOA es una arquitectura de Software orientada a servicios. Esta arquitectura surge de la continua y creciente evolución de la Tecnología de Información (IT), en conjunto con la evolución de los procesos de negocios.
SOA integra procesos, recursos humanos e información en un ambiente operativo más ágil y flexible. Para poder lograr esta integración hace uso del concepto de servicio, Orquestación y Coreografía de Servicios Web.
La funcionalidad se encapsula en servicios independientes entre sí. Alta interoperabilidad entre los servicios. La aplicación final orquesta la ejecución de los servicios y añade la interfaz.
García, Gabriel Alejandro, SOA Architect, se refiere a la arquitectura diciendo que hace un tiempo era IBM quién buscaba a los posibles clientes para ofrecerles esta tecnología, mientras que hoy en día son los clientes los que se acercan a consultar, más que nada por las siglas, sin conocer muy bien como funciona y que implica. Gabriel, continúa diciendo que, si bien IBM es quien más tiempo tiene en el mercado, otras empresas como Oracle y Weblogic están ganando terreno. En cuanto a los proyectos en Argentina que utilizan esta tecnología, sostiene que las empresas de Telefonía son las que están avanzando en estos proyectos.
Por su parte otro especialista del área de soporte de productos, opina que a nivel País el tema de SOA está en sus comienzos, recién se están comenzando a encarar proyectos serios. Sin embargo, brinda soporte a toda América del Sur, y Países de habla hispana, y considera que a nivel región ya existen proyectos funcionando utilizando SOA y muchos proyectos más en proceso de desarrollo que serán puestos en marcha muy pronto.
Frente a los rápidos cambios - a partir de la creciente globalización, la consolidación de la industria y los mercados emergentes – las organizaciones necesitan ser ágiles en los negocios, así como en TI. Los cambios estratégicos en las actividades empresariales deben ser apoyados por sistemas flexibles y ágiles de TI. La información tiene que ser abierta en forma estandarizada y las transformaciones de negocio y de TI tienen que ser apoyadas por planes de trabajo alineados.
Según Gartner, en 2011 un ochenta por ciento de las organizaciones de todo el mundo se habrán cambiado a SOA, este porcentaje fue mucho menor sin embargo en inegable que las organizaciones se interesan por migrar a una arquitectura abierta orientada a Servicios. La razón: los modelos SOA hacen que sea mucho más fácil adaptar los procesos de negocio a los cambios del mercado que mediante las arquitecturas tradicionales de software. Como ha ocurrido muy a menudo en el pasado, las grandes compañías fueron las pioneras en este desarrollo. Gracias a soluciones inteligentes y modulares, este cambio de paradigma se ha hecho ahora atractivo y factible también para las compañías de tamaño mediano, por tanto se puede afirmar que el futuro pertenece a las arquitecturas orientadas a servicios (SOA).
En una empresa pueden coexistir varias aplicaciones. Esto lleva a una serie de inconvenientes que aumentan el esfuerzo y el tiempo en que se responde a un requerimiento determinado. Uno de los inconvenientes es, por ejemplo, ante aplicaciones diferentes probablemente desarrolladas en lenguajes diferentes, no poder acceder desde una de las aplicaciones hacia la otra para consultar algún dato.
Mediante la aplicación de la Arquitectura SOA se pretende solucionar los inconvenientes antes mencionados. Dentro de la arquitectura SOA la funcionalidad se implementa en pequeños componentes autónomos reutilizables denominados servicios.
SOA obtiene una integración de aplicaciones o componentes, uniendo la tecnología de información con las necesidades del negocio, logrando una respuesta rápida con un bajo acoplamiento, un ambiente operativo integrado que provee servicios para integrar personas, procesos e información.
El hecho de optar por este tipo de arquitectura requiere de una infraestructura de comunicación, en este caso la arquitectura orientada a servicios utiliza ESB (Enterprise Service Bus). Según Craggs es una plataforma basada en estándares que incluye funciones básicas como servicio de mensajería, servicios Web, enrutamiento inteligente y transformación de datos para conectar y coordinar la interacción de un número significativo de aplicaciones de empresas extendidas con integridad transaccional.
SOA es una arquitectura de Software orientada a servicios. Esta arquitectura surge de la continua y creciente evolución de la Tecnología de Información (IT), en conjunto con la evolución de los procesos de negocios.
SOA integra procesos, recursos humanos e información en un ambiente operativo más ágil y flexible. Para poder lograr esta integración hace uso del concepto de servicio, Orquestación y Coreografía de Servicios Web.
La funcionalidad se encapsula en servicios independientes entre sí. Alta interoperabilidad entre los servicios. La aplicación final orquesta la ejecución de los servicios y añade la interfaz.
García, Gabriel Alejandro, SOA Architect, se refiere a la arquitectura diciendo que hace un tiempo era IBM quién buscaba a los posibles clientes para ofrecerles esta tecnología, mientras que hoy en día son los clientes los que se acercan a consultar, más que nada por las siglas, sin conocer muy bien como funciona y que implica. Gabriel, continúa diciendo que, si bien IBM es quien más tiempo tiene en el mercado, otras empresas como Oracle y Weblogic están ganando terreno. En cuanto a los proyectos en Argentina que utilizan esta tecnología, sostiene que las empresas de Telefonía son las que están avanzando en estos proyectos.
Por su parte otro especialista del área de soporte de productos, opina que a nivel País el tema de SOA está en sus comienzos, recién se están comenzando a encarar proyectos serios. Sin embargo, brinda soporte a toda América del Sur, y Países de habla hispana, y considera que a nivel región ya existen proyectos funcionando utilizando SOA y muchos proyectos más en proceso de desarrollo que serán puestos en marcha muy pronto.
jueves, 24 de marzo de 2011
Aprendiendo SOA
Dejo una serie de libros y links para la persona que quiere empezar con SOA
Libros:
Open Source SOA.
Autor: Jeff Davis
Publicado por Manning Publications corp.
ISBN: 1933988541
Java SOA cookbook
Autor: Eben Hewitt
Publicado por O’Reilly Media, Inc.
ISBN: 978-0-596-52072-4
Service-Oriented Architecture: Concepts, Technology, and Design
Autor: Thomas Erl
Publicado por Prentice Hall PTR
ISBN: 0-13-185858-0
Service-Oriented Architecture Governance for the Services Driven Enterprise
Autor: Eric E. Marks
Publicado por Wiley Publishing.
ISBN 978-0-470-17125-7
Adopción de SOA para Dummies.
Autores:Miko Matsumura, Bjoern Brauel y Jignesh Shah
ISBN: 978-0-470-48334-3
Publicado por Wiley Publishing.
Introducción a BPM para Dummies.
Autores: Kiran Garimella, Michael Lees y Bruce Williams
ISBN: 978-0-470-37359-0
Publicado por Wiley Publishing.
Papers:
Introducing SCA
autor: David Chappell
Url: http://www.davidchappell.com/articles/introducing_sca.pdf
BPM and SOA
Autor: Mike Rosen
Oracle SCA – The Power of the Composite
Autor: Pat Shepherd
Fabric3 Reference Guide
Url: http://dist.codehaus.org/fabric3/releases/doc/1.6/fabric3-reference-1-6.pdf
Sitios Web:
http://msdn.microsoft.com/webservices/
¿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.
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.
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.
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.
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.
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:
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:
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:
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:
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.
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 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.
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.
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.
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.
¿Que es SOA?
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.
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.
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, 17 de enero de 2011
WOA (Web-oriented architecture)
Web-oriented architecture (WOA), como SOA, tiene varias definiciones. Algunos ven a WOA como un estilo arquitectonico y un subestilo de SOA basado en aplicaciones web, más liviano que SOA. Otra definición es el uso de REST para construir servicios web usando tecnología web como HTTP y documentos XML.
Si buscamos una definición rapida podemos decir que :
SOA + Web 2.0 = WOA
El uso de REST y la separación de la interfaz (concebida de forma web pero que consulta los servicios por javascript expuestos mediante REST) dio nacimiento a este estilo arquitectónico.
Este enfoque mucho más orientado a la Web es algo que muchos han llamado Web-Oriented Architecture (WOA) y se basa en la enorme fuerza de tracción de la World Wide Web en sí y sus fundamentos arquitectónicos subyacentes. Y se basa en los conceptos básicos y los resultados que han hecho de la Web con mucho, la mayor red abierta en el planeta, así como el mayor SOA actualmente en existencia. En el extremo principal de esto es la historia de mashups de web con aplicaciones híbridas empresariales es una de las importantes mejoras en el entorno de TI que se anuncia la WOA.
Si buscamos una definición rapida podemos decir que :
SOA + Web 2.0 = WOA
El uso de REST y la separación de la interfaz (concebida de forma web pero que consulta los servicios por javascript expuestos mediante REST) dio nacimiento a este estilo arquitectónico.
Este enfoque mucho más orientado a la Web es algo que muchos han llamado Web-Oriented Architecture (WOA) y se basa en la enorme fuerza de tracción de la World Wide Web en sí y sus fundamentos arquitectónicos subyacentes. Y se basa en los conceptos básicos y los resultados que han hecho de la Web con mucho, la mayor red abierta en el planeta, así como el mayor SOA actualmente en existencia. En el extremo principal de esto es la historia de mashups de web con aplicaciones híbridas empresariales es una de las importantes mejoras en el entorno de TI que se anuncia la WOA.
sábado, 4 de septiembre de 2010
FUSE
FUSE es una comunidad que promueve el uso de productos Apache para el uso de SOA. La idea es crear una comunidad Open Source de uso de SOA, de esta forma poder compartir experiencias, conocimiento, etc.
Dejo el link: http://fusesource.com/
sábado, 7 de agosto de 2010
¿Que herramienta de registro de servicios utilizar?
El objetivo de tener un registro de las funcionalidades desarrolladas en una arquitectura SOA es que todos los desarrolladores conozcan los servicios 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 herramientas de objetivo particular. En el mercado existen herramientas open sources 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. Ambienta se 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.
Hay que decir que el producto de registro WSO2 es muy sencillo de utilizar y gana 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.
Cual utilizar? como todo en esta vida depende, Si usamos Mule hay que optar por la integración de sus productos por lo tanto en buena opción MuleSource Galaxy, en otros casos puede ser uno u otro. Yo pienso que WSO2 es 100% libre y gratuita, por esta razón y la facilidad de uso, creo que es mejor optar por la herramienta de registro de WSO2.
domingo, 11 de julio de 2010
Servicios y Gobierno SOA
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 negoció, 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 su funcionamiento; 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.
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 ¿como se si no existe ya? O ¿si existen servicios que pueden ayudar? Por lo tanto debo tener un registro a donde registrar mis servicios, en el cual puedo buscar los servicios 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 gestion de los servicios se le llama gobierno SOA.
Gobierno de SOA es una ampliación del gobierno de IT centrada en el ciclo de vida 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
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.
- Procesador de flujos de eventos o ESP(Event Stream Processing) herramienta para diseñar, gestionar y monitorizar los eventos que fluyen a traves de un entorno orientado a EDA(Event-Driver Architecture) dado.
- Integración de aplicaciones empresariales o EAI (Enterprise Application Integration) facilita la integración con aplicaciones o bases de datos legacy.
No necesariamente se deben tener todos las herramientas descriptas para conformar el gobierno SOA. Se deben adoptar las herramientas que satisfagan las necesidades propias de la empresa que adopta SOA.
domingo, 4 de julio de 2010
BPM
BPM (Business Process Management) es lo que normalmente llamabamos workflow, es decir es un a 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. Faculta a los individuos de cualquier rincón de una empresa para alcanzar un mayor éxito. Reúne a personas y sistemas. BPM es donde se condensan todas las elevadas ambiciones y mejores estrategias.
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 es el resultado de muchos años de experiencia en desarrollo y aplicación; el producto de los avances más actuales en sistemas y procesamiento de información; la cumbre de todas las arquitecturas, lenguajes y protocolos informáticos. La tecnología BPM constituye un gran avance, y un nuevo paradigma en cuanto a flexibilidad, gestión y control de información y datos.
BPM, como práctica de gestión integral, es el resultado de la combinación de avances técnicos con métodos y prácticas establecidos, de un modelo empresarial centrado en el proceso.
La tecnología BPM incluye todo lo que necesita a la hora de diseñar, representar, analizar y controlar los procesos de negocio operacionales:
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. Faculta a los individuos de cualquier rincón de una empresa para alcanzar un mayor éxito. Reúne a personas y sistemas. BPM es donde se condensan todas las elevadas ambiciones y mejores estrategias.
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 es el resultado de muchos años de experiencia en desarrollo y aplicación; el producto de los avances más actuales en sistemas y procesamiento de información; la cumbre de todas las arquitecturas, lenguajes y protocolos informáticos. La tecnología BPM constituye un gran avance, y un nuevo paradigma en cuanto a flexibilidad, gestión y control de información y datos.
BPM, como práctica de gestión integral, es el resultado de la combinación de avances técnicos con métodos y prácticas establecidos, de un modelo empresarial centrado en el proceso.
La tecnología BPM incluye todo lo que necesita a la hora de 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 que nunca. No es necesario desprenderse de las inversiones ya realizadas; todo se puede reutilizar.
- Los entornos de trabajo de aplicaciones compuestas le permiten construir e implementar aplicaciones basadas en web casi de forma instantánea, completamente funcionales y sin necesidad de código.
- La ejecución convierte de forma directa los modelos en acción en el 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.
jueves, 3 de junio de 2010
Aprendiendo SOA
Dejo algunos links que vienen bien leer:
http://blogs.tecsisa.com/articulos-tecnicos/¿por-que-soa/
http://blogs.tecsisa.com/articulos-tecnicos/¿por-que-un-enterprise-service-bus
Además les aconsejo un blog, Espacio SOA y además el mio jeje.
http://www.espaciosoa.net
http://blogs.tecsisa.com/articulos-tecnicos/¿por-que-soa/
http://blogs.tecsisa.com/articulos-tecnicos/¿por-que-un-enterprise-service-bus
Además les aconsejo un blog, Espacio SOA y además el mio jeje.
http://www.espaciosoa.net
viernes, 14 de mayo de 2010
Apache Tuscany y Spring
Sigo experimentando con Apache Tuscany, hoy el objetivo es hacer un ejemplo con integración con spring. Mismo ejemplo que hicimos en : http://emanuelpeg.blogspot.com/2010/05/desarrollar-un-ejemplo-con-apache.html
Comenzamos escribiendo la interfaz:
@Remotable
public interface ExampleService {
String sayHello();
}
Su implementación :
@Service(ExampleService.class)
public class ExampleServiceImpl implements
ExampleService {
private String hello = "Holasss !!! \n";
public void setHello(String hello) {
this.hello = hello;
}
/**
* @see org.assembly.nornas.ExampleService#sayHello()
*/
@Override
public String sayHello() {
System.out.print("llamaron a Say");
return hello;
}
@Init
public void init() {
System.out.println("Starting with "+ExampleServiceImpl.class + " \n");
}
}
Ahora tenemos que configurar el beans de spring, en un archivo que llamaremos: appcontext-spring.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:sca="http://www.springframework.org/schema/sca"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/sca http://www.osoa.org/xmlns/sca/1.0/spring-sca.xsd ">
<bean id="service.example" class="com.elpaquete.ExampleServiceImpl">
<property name="hello" value="Hola desde Spring!!" ></property>
</bean>
<sca:service name="ExampleService"
type="org.assembly.nornas.sandbox.service.example.ExampleService" target="service.example" />
</beans>
Notaron que además de declarar el bean le indicamos a Apache Tuscany cual es la interfaz de nuestro bean que va a ser un componente de Apache Tuscany.
Ahora escribimos el archivo ExampleSpring.composite:
<?xml version="1.0" encoding="UTF-8" ?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"
targetNamespace="http://nornas"
xmlns:nornas="http://nornas"
name="Example" >
<component name="ExampleServiceComponent">
<implementation.spring location="spring-sandbox.xml" />
<service name="ExampleService">
<interface.java interface="org.assembly.nornas.sandbox.service.example.ExampleService"/>
<binding.ws uri="http://localhost:8080/nornas/ws" />
<t:binding.atom uri="http://localhost:8080/nornas/atom" />
<t:binding.jsonrpc uri="http://localhost:8080/nornas/jsonrpc" />
<t:binding.rss uri = "http://localhost:8080/nornas/rss"/>
<binding.sca />
</service>
</component>
</composite>
Notaron que la implementación del componente no se indica clase si no el archivo appcontext-spring.xml, Apache tuscany va a leer y buscar de ahí la implementación.
Ya lo tenemos, ahora vamos a hacer la clase main:
public class MainSpring {
public static void main(String[] args) throws IOException {
System.out.println("Starting ...");
SCADomain scaDomain = SCADomain.newInstance("ExampleSpring.composite");
System.out.println("Example in "+scaDomain.getURI());
System.in.read();
System.out.println("Stopping ...");
scaDomain.close();
System.out.println();
}
}
Si todo salio bien, en http://localhost:8080/nornas/ws?wsdl va a estar wsdl de su web service soap.
Por ultimo las dependencias de maven:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6.SEC01</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-sca-api</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-core-spi</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-policy-security</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-embedded</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-data-api</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
<version>1.5.3</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-java-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-atom-abdera</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rss-rome</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-ws-axis2</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-jsonrpc-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rmi-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-resource-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-http-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-jetty</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-spring</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-spring-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
</exclusions>
</dependency>
Comenzamos escribiendo la interfaz:
@Remotable
public interface ExampleService {
String sayHello();
}
Su implementación :
@Service(ExampleService.class)
public class ExampleServiceImpl implements
ExampleService {
private String hello = "Holasss !!! \n";
public void setHello(String hello) {
this.hello = hello;
}
/**
* @see org.assembly.nornas.ExampleService#sayHello()
*/
@Override
public String sayHello() {
System.out.print("llamaron a Say");
return hello;
}
@Init
public void init() {
System.out.println("Starting with "+ExampleServiceImpl.class + " \n");
}
}
Ahora tenemos que configurar el beans de spring, en un archivo que llamaremos: appcontext-spring.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:sca="http://www.springframework.org/schema/sca"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/sca http://www.osoa.org/xmlns/sca/1.0/spring-sca.xsd ">
<bean id="service.example" class="com.elpaquete.ExampleServiceImpl">
<property name="hello" value="Hola desde Spring!!" ></property>
</bean>
<sca:service name="ExampleService"
type="org.assembly.nornas.sandbox.service.example.ExampleService" target="service.example" />
</beans>
Notaron que además de declarar el bean le indicamos a Apache Tuscany cual es la interfaz de nuestro bean que va a ser un componente de Apache Tuscany.
Ahora escribimos el archivo ExampleSpring.composite:
<?xml version="1.0" encoding="UTF-8" ?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"
targetNamespace="http://nornas"
xmlns:nornas="http://nornas"
name="Example" >
<component name="ExampleServiceComponent">
<implementation.spring location="spring-sandbox.xml" />
<service name="ExampleService">
<interface.java interface="org.assembly.nornas.sandbox.service.example.ExampleService"/>
<binding.ws uri="http://localhost:8080/nornas/ws" />
<t:binding.atom uri="http://localhost:8080/nornas/atom" />
<t:binding.jsonrpc uri="http://localhost:8080/nornas/jsonrpc" />
<t:binding.rss uri = "http://localhost:8080/nornas/rss"/>
<binding.sca />
</service>
</component>
</composite>
Notaron que la implementación del componente no se indica clase si no el archivo appcontext-spring.xml, Apache tuscany va a leer y buscar de ahí la implementación.
Ya lo tenemos, ahora vamos a hacer la clase main:
public class MainSpring {
public static void main(String[] args) throws IOException {
System.out.println("Starting ...");
SCADomain scaDomain = SCADomain.newInstance("ExampleSpring.composite");
System.out.println("Example in "+scaDomain.getURI());
System.in.read();
System.out.println("Stopping ...");
scaDomain.close();
System.out.println();
}
}
Si todo salio bien, en http://localhost:8080/nornas/ws?wsdl va a estar wsdl de su web service soap.
Por ultimo las dependencias de maven:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6.SEC01</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-sca-api</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-core-spi</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-policy-security</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-embedded</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-data-api</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
<version>1.5.3</version>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-java-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-atom-abdera</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rss-rome</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-ws-axis2</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-jsonrpc-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rmi-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-resource-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-http-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-jetty</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-spring</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-spring-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
</exclusions>
</dependency>
Suscribirse a:
Entradas (Atom)
