SOA

Casos éxito de implementaciones de SOA desarrollados por Ayi & asociados

http://zion.ayi-asociados.com:7778/portal/page?_pageid=396,176175,396_185950&_dad=portal&_schema=PORTAL

Farmalink

El Proyecto macro incluye los siguientes subproyectos:

• Reingeniería del Portal Corporativo para brindarle mayor flexibilidad a los cambios e incorporaciones de nuevas funcionalidades. Desarrollo del nuevo portal utilizando Oracle Portal. Incorporación de información de Business Intelligence y Tablero de Comando

• Desarrollo de aplicaciones en J2EE (Portlets) implementando metodología basada en el estándar CMMi Level 2 y utilizando UML como estándar de modelado, integradas al portal corporativo

• Integración de Sistemas y automatización de procesos de negocios utilizando utiliza Oracle BPEL Process Manager con ciertos adaptadores para la integración de sistemas que anteriormente se realizaba en base a archivos compartidos, DBLinks y desde la Base de Datos, para otorgar mayor flexibilidad a dicha integración.

• Implementación de Seguridad con Oracle Internet Directory

• Implementación de Grid de Base de Datos y de Oracle Application Server

Banco de la República - Colombia
Consultoría en Desarrollo de Aplicaciones:

• Asesoramiento en Arquitectura y Desarrollo de Aplicaciones J2EE y Oracle con tecnología ADF Faces/JSF/EJB 3.0/TopLink sobre la plataforma Oracle JDeveloper Suite 10.1.3, integrándos a los procesos de negocio de la organización administrados por Oracle BPEL Process Manager 10.1.3

Consultoría en Modelado de Procesos:

• Asesoramiento en modelado y administración de los Procesos de Negocio sobre la plataforma Oracle BPEL Process Manager 10.1.3

Consultoría en Soporte de Tecnologías:

• ADF Faces, JavaServer Faces (JSF), Enterprise JavaBean (EJB) 3.0, TopLink, Java Enterprise Edition 2 (J2EE), BPM (BPEL Process Manager), Business Rules.

** Las siete claves del éxito SOA **

http://www.tibco.com/international/spain/resources/es_soa_together_adv.pdf
TIBCO Software Inc

** 1 Demandar la rentabilidad de la inversión en cada servicio**
Incorpore cada servicio en un proceso de negocio activo que genere rentabilidad de la inversión (ROI). Este enfoque puede apoyar una inversión sostenida en el desarrollo de servicios al cubrir los costes a corto plazo, a la vez que establece el escenario para un retorno de la inversión a mas a largo plazo.
También se puede obtener un retorno de la inversión basado en atributos específicos y características de servicios individuales. Además de la función esencial del servicio, puede que desee tener control sobre quién accede a ese servicio, llevar un registro de quién lo utiliza y de qué manera, encriptar o aceptar datos o transacciones, o asegurar el cumplimiento de la normativa a nivel de servicio. En ocasiones, funciones complementarias pueden proporcionar un retorno de la inversión más cuantificable que la función principal en sí.

** 2 Definir un Comité de Gestión de Servicios**
Recuerde que la mayor parte de los servicios tienen un origen orgánico, algunas veces casi involuntario: un equipo de desarrollo puede advertir la creación de una función que se podría utilizar en otros procesos de negocio. Sin embargo, puede que estos desarrolladores carezcan de la experiencia para decidir si dicha función tendría sentido como servicio y de la perspectiva necesaria para especificar y crear el servicio para su reutilización.
Un comité de gestión podría encargarse de esta tarea. El comité debería estar formado por arquitectos de procesos de negocio que estén familiarizados con el diseño de los procesos actuales y por expertos arquitectos de sistemas que entiendan cómo los componentes tecnológicos soportan esos procesos de negocio. El comité de gestión de SOA será el responsable de identificar los escenarios de uso de los servicios potenciales y evaluarlos para saber si la utilización, las medidas y los acuerdos a nivel de servicio son lo bastante similares entre las aplicaciones potenciales como para justificar la transformación de una función en un servicio. En caso de ser así, el comité de gestión necesita especificar el servicio para asegurarse de que se utilizará y tendrá valor en diferentes contextos.

** 3 Organizar adecuadamente los comités de gestión**
La clave para un control eficaz es que se ajuste perfectamente a su organización. Un posible enfoque consiste en centralizar el comité de gestión por completo, es decir, designar un único grupo que realice la evaluación, especificación y control de todos los servicios. Esta solución es adecuada para aquellas empresas con organizaciones de desarrollo centralizado. Otro enfoque consiste en crear comités de gestión en torno a aplicaciones principales en los que participen tanto usuarios como proveedores de dichas aplicaciones. Este enfoque es apropiado para empresas con un modelo de desarrollo distribuido.
Con independencia de cuál sea la perspectiva que más se ajuste a su situación, deberá establecer un modelo de compromiso y nivel de servicio que, en primer lugar, facilite el flujo de ideas al comité de gestión pero que también garantice una acción rápida. Una vez que se haya especificado un servicio, un equipo de proyecto puede ser el propietario y el que implemente ese servicio pero, a menos que el comité de gestión esté completamente involucrado en el proceso, los servicios no serán reutilizables.

** 4 Crear y especificar tareas y responsabilidades**
Normalmente, los procesos de negocio unidos por servicios abarcan varias aplicaciones y, muy frecuentemente, varias plataformas y organizaciones. Por eso resulta de vital importancia definir a los participantes clave y aclarar sus funciones. Existen cinco funciones clave que se deben convenir y cubrir:
• Un gestor de proyecto que disponga de una visión amplia de todo el proceso de negocio y gestione todo lo relacionado con su creación o modificación.
• Un arquitecto de procesos de negocio que determine los cambios de proceso de negocio necesarios para alcanzar los beneficios de negocio esperados.
• Un arquitecto de sistemas que establezca la tecnología necesaria para respaldar el proceso de negocio y sus objetivos.
• Un responsable de TI que se ocupe de garantizar la cooperación activa de todos los silos mantenidos dentro del grupo de TI.
• Un responsable de negocio que garantice la cooperación de todas las unidades de negocio afectadas por el proceso.

5 Ir más allá de la solicitud-respuesta
Mucha de la atención en SOA se ha centrado en los servicios bajo demanda o de solicitud-respuesta pero no se pueden crear procesos de negocios reales únicamente con los servicios de solicitud-respuesta. Mientras que la mayoría de procesos de negocio se inician con una solicitud, en realidad constan de secuencias de tareas y decisiones que inician automáticamente el siguiente paso del proceso de forma proactiva en función de los eventos. Tiene que tener presente la necesidad de servicios dirigidos por eventos cuando establezca la capa de transporte de servicio de su infraestructura.
Lo mejor es utilizar HTTP para interacciones fuera de la empresa y JMS para interacciones dentro de la empresa. La razón es que el transporte HTTP no soporta la mensajería asíncrona ni con las notificaciones dirigidas por eventos, mientras que JMS sí. Cree el nivel de transporte de servicio para la infraestructura con HTTP y JMS de forma que pueda satisfacer las necesidades delos procesos de negocio del mundo real con una combinación de servicios dirigidos por solicitudes y eventos.

6 Tener en cuenta los estándares emergentes
Si un estándar específico se ha desarrollado y es válido para desempeñar la tarea que está realizando, debe adoptarlo. No obstante, muchos de los estándares relacionados con SOA todavía están evolucionando. Si tiene que tomar una decisión sobre un estándar que se encuentra en proceso de formación, debe solucionar el problema inmediato con la tecnología disponible pero considerar el estado y planificar la futura incorporación de estándares emergentes. De ese modo, cuando un estándar se haya desarrollado, evitará quebraderos de cabeza a la hora de acometer los cambios.
WS-eventing y WS-notification son buenos ejemplos de estándares emergentes que debemos observar atentamente. Mientras se establecen los estándares, debe realizar el trabajo preliminar necesario para cumplir la normativa adoptando una estructura sobre de SOAP para las estructuras de datos de mensajería, incluso si no está utilizando otras características SOAP para la implementación de esos servicios. Este procedimiento allanará el camino para una migración posterior a los servicios SOAP completamente desarrollados sin tener impactos en las aplicaciones que acceden a los datos de esas estructuras.

7 Desarrollar para expandir y soportar todas las tecnologías y plataformas
Una de las mayores potenciales ventajas de SOA es que facilita el crecimiento de su infraestructura TI con el de su compañía. Y como tal, la infraestructura podrá incorporar cualquier plataforma, tecnología, lenguaje de programación y distribución geográfica que sea necesario.
Por lo tanto, evite crear su infraestructura con enfoques SOA o soluciones que limiten sus opciones a plataformas, servidores de aplicación o lenguajes de programación específicos.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License