lunes, 28 de febrero de 2011

Principios SOA

Hola, esta semana les hablaremos sobre los principios. Para empezar, un principio no es más que una buena práctica para lograr un objetivo, está basado en la experiencia y es ampliamente aceptado por la industria. A continuación les describimos los principios de diseño de SOA:

Contratos de Servicio Estandarizados

Cada servicio debe establecer un contrato con el cliente donde se especifique: nombre del servicio, forma de acceso, funcionalidades, parámetros de entrada y salida. En caso de ser necesaria una modificación a la implementación del servicio, se debe respetar el contrato, por lo tanto se logra una independencia entre el cliente y la implementación del servicio.

Servicios Débilmente Acoplados

Debe haber un bajo acoplamiento entre un servicio y los clientes que lo usan, esto se logra con los contratos, ya que estos esconden la lógica del servicio y garantizan una forma estándar de invocación, de modo que si se llega a cambiar la implementación del servicio, éste será el único punto de actualización, no será necesario modificar la forma en que los clientes hacen el llamado.

Reusabilidad de Servicios

La reutilización es el pilar de SOA, cada servicio debe ser pensado de modo que se pueda explotar al máximo su uso, es decir, que sea de algún modo genérico con el fin de que pueda ser usado en diferentes contextos y satisfacer distintos objetivos, este es el caso de los procesos de negocio donde cada uno de estos puede tener un propósito totalmente distinto del otro y aún así estar usando un mismo servicio.

Autonomía de Servicios

Cada servicio SOA es mantenido, desarrollado, instalado y versionado de forma independiente. De esta forma el servicio es autónomo y podemos asegurar que podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.

Servicios sin Estado

Los servicios no deben depender del estado de otros servicios, esta independencia garantiza la posibilidad de reutilización de estos en variados contextos. Para lograr esta independencia, un servicio no debe conservar información del cliente que lo usa, tan solo debe recibir en el mensaje de invocación los argumentos necesarios para llevar a cabo su tarea y dar una respuesta, sin dejar algún rastro de la información dentro del servicio.

Descubrimiento de Servicios

Para garantizar la reutilización de los servicios y evitar realizar implementaciones de servicios ya existentes pero desconocidos, se debe proveer de algún método o herramienta que permita descubrirlos; UDDI (Universal Description Discovery and Integration) es un mecanismo y repositorio basado en XML que permite registrar web services, publicarlos y realizar consultas sobre sus contratos para poder interactuar con estos.

Composición de Servicios

En la medida en que las soluciones orientadas a servicios crecen, así crece la complejidad de las mismas, Por esta razón Los servicios deben ser construidos para ser parte de servicios más complejos, a si mismo se necesita de conceptos como orquestación y coreografía para cumplir con el propósito del servicio compuesto.

Referencias

http://www.soapatterns.org/patterns_principles.php

http://arquitecturaorientadaaservicios.blogspot.com/2006/06/principios-de-la-orientacin-servicios.html

http://info-soa.blogspot.com/2010/09/principios-de-una-arquitectura.html

http://www.ibm.com/developerworks/library/ws-soaintro.html

http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

lunes, 21 de febrero de 2011

ORACLE y SOA

Hola, la semana pasada les hablamos sobre algunos de los problemas que tienen que afrontar las organizaciones cuando sus soluciones no están basadas en arquitecturas de integración de aplicaciones como SOA. Esta semana les traemos soluciones en el mercado por parte de una de las mayores compañías de software en el mundo, les estamos hablando de ORACLE y sus productos Oracle Fusion Middleware y Application Integration Architecture (AIA), ambos basados en SOA.


Application Integration Architecture AIA

La Arquitectura de Integración de Aplicaciones de Oracle está compuesta por un conjunto de herramientas, metodologías y buenas prácticas que recogen los más de 30 años de desarrollo y experiencia en integración de aplicaciones por parte de esta compañía.

Una de las razones para implementar esta arquitectura es el tamaño de la organización, pues a medida que crece, el número de aplicaciones que necesita también aumenta, y si no se tiene una estrategia de integración, la gestión de los procesos de negocio soportados por estas aplicaciones se volverá cada vez más compleja.

Para resolver estos problemas Oracle ha hecho de la integración un producto, con el cual los proyectos de integración se vuelven más rápidos, menos complejos y de menor costo. Entre sus principales características están:

  • Mejor compatibilidad entre aplicaciones.

  • Procesos de negocio integrados.

  • Integraciones que son fáciles de mantener y que tienen habilidad de evolución.

  • Menores costos de mantenimiento y soporte.

Los principales componentes de AIA son:

Foundation packs: contiene las piezas de construcción y plantillas (modelos de procesos, objetos de negocio, servicios de negocio) necesarias para integrar cualquier tipo de aplicación y construir procesos de negocio basados en SOA.

Process integration packs: contiene procesos de negocio preconstruidos que conectan aplicaciones específicas de Oracle con terceros como SAP.


Oracle Fusion Middleware SOA

Es un conjunto de soluciones que brinda a las organizaciones la posibilidad de aprovechar de manera inteligente sus capacidades en la gestión de la información. Dentro de este conjunto de aplicaciones encontramos un componente en especifico que hace referencia a SOA, este es ORACLE SOA SUITE, el cual permite la creación, implementación y administración de los servicios; lo interesante de esta aplicación es que su implementación se puede realizar de manera gradual de tal forma que no afecta el funcionamiento de la organización.

Las características de ORACLE SOA SUITE son:

  • Un administrador de procesos basado en BPEL para componer servicios en los procesos de negocio.

  • Un monitor de la actividad de los negocio a fin de obtener visibilidad en tiempo real de las operaciones y el desempeño de los servicios y procesos de negocio.

  • Motor de reglas de negocio para capturar y automatizar las políticas de negocios.

  • Conectividad con diferentes fuentes de datos.

  • Seguridad y administración de servicios Web para hacer cumplir las políticas de autenticación y autorización en torno a los servicios.

  • Detección y administración del ciclo de vida de los servicios.


Referencias:

www.prensariotila.com/pdf/Especial%20ERP&SOA_0510.pdf

http://www.oracle.com/us/products/applications/057281.pdf

http://www.oracle.com/us/products/applications/application-integration-architecture/apps-integration-architecture-210164.html

http://www.oracle.com/technology/global/lad-es/documentation/collaterals/Oracle-SOA-Suite-Datasheet-Espanol.pdf

lunes, 14 de febrero de 2011

SOA y el ERP

Hola, esta semana les hablaremos de los beneficios que se obtienen al aplicar SOA en una solución ERP.


Para empezar necesitamos saber que es un ERP, un Enterprise Resource Planning es una solución de software cuyo objetivo es aportar valor a todas las áreas de la empresa mediante la integración de distintos módulos que comparten información, entre los que podemos destacar: manufactura, financieros, Supply Chain Management (SCM), Human Resource Management (HRM), entre otros.

Como podemos ver esta solución brinda un gran apoyo a las labores de gestión en una empresa, pero uno de sus puntos débiles es lo costoso que resulta su implementación en términos de tiempo y monetarios, y si a esto le sumamos las futuras y seguras tareas de actualización para satisfacer nuevos requerimientos de negocio, nos damos cuenta que las ERP convencionales no son la panacea, pues a la hora de customizar tendríamos dos opciones, la primera, dedicarle gran cantidad de esfuerzo, tiempo y recursos a esta labor, o como segunda opción, forzar el negocio a adaptarse al ERP.

Es aquí donde donde el paradigma SOA entra a tomar parte del juego, pues sacando a relucir uno de sus principios: “escribir código tan poco como sea posible”, nos damos cuenta que el beneficio que puede aportar SOA a las ERP es importante, ayudando a mitigar los problemas de implementación y de respuesta al cambio.

Esta nueva filosofía de desarrollo de ERP's facilitara la labor de integración entre soluciones y servicios de distintos proveedores, dotando a las ERP's de flexibilidad, facilidades de extensión y todo esto con un reducido coste de gestión.

En nuestra siguiente entrada les hablaremos sobre soluciones software en el mercado que han adoptado el modelo SOA, no dejen de visitarnos.


Referencias:

http://www.ehow.com/facts_6106695_difference-between-erp-_amp_-soa_.html

http://www.baquia.com/posts/soa-aplicada-a-las-soluciones-de-gestion-erp

www.prensariotila.com/pdf/Especial%20ERP&SOA_0510.pdf

http://bakker.co.za/?p=48

http://blogs.livetime.com/category/itil/

lunes, 7 de febrero de 2011

¿Por qué usar SOA?


Hola a todos nuestros visitantes, continuando con nuestra tarea de entender que es SOA y para que sirve, a continuación les describiremos las principales razones por las que es conveniente usar una arquitectura orientada a servicios en una organización.


Reutilización:
Es posible dar soporte a nuevos procesos de negocio simplemente reutilizando funcionalidades de aplicaciones ya existentes que han sido expuestas como servicios web, de esta forma se logra una respuesta a nuevos requerimientos del negocio en poco tiempo y con el mínimo esfuerzo, pues reescribir una aplicación o parte de ella definitivamente no sería la solución más conveniente.

Interoperabilidad:
Los servicios y los clientes, muchas veces limitados por la plataforma sobre la que corren o el lenguaje de programación con que fueron implementados, necesitan tener un mecanismo de comunicación para interactuar entre sí que se encuentre por encima de estas limitantes, es por esto que SOA utiliza protocolos estándares que permiten que ambas partes se pongan de acuerdo sobre la forma en que se comunicarán.

Escalabilidad:
A modo general, una arquitectura es mas escalable que otra si su costo por unidad de capacidad añadida es menor.

Cuando hablamos de SOA, una unidad de capacidad añadida sería el equivalente a decir que agregamos un nuevo servicio web a un sistema para que interactúe con otros y soporte un nuevo proceso de negocio.

Se podría pensar que realizar esto agrega más complejidad, pero afortunadamente los servicios web no tienen estado, es decir no necesitan mantener información de sesión cada vez que un cliente los invoca, lo que quita el peso de encima de tener que manejar este estado entre cada llamado al servicio.

Flexibilidad:
Debido a que las funcionalidades de las aplicaciones han sido expuestas como servicios web dotados de una interfaz estándar que les da interoperabilidad, cualquier cambio en la implementación de un servicio no afectará la forma en que éste pueda ser invocado, pues su interfaz o fachada permanecerá inalterada y al mismo tiempo esconderá los posibles cambios del servicio.

Eficiencia en coste
El concepto de reutilización juega un papel muy importante cuando se trata de disminuir costos y aumentar la productividad, pues el hecho de reutilizar aplicaciones ya existentes disminuye la inversión en infraestructura y reduce la necesidad de adquirir nuevo software especializado.

Referencias: