LAS SIETES CLAVES DEL ÉXITO SOA

Hola a todos, esta semana hablaremos de las claves dl éxito diseñar e implementar SOA.

La aplicación de estas siete claves permitirán minimizar los riesgos y  en general, aumentar las probabilidades de éxito a la hora de entregar los proyectos a tiempo y  dentro del presupuesto.

• 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).

• Definir un Comité de Gestión de Servicios: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 se justifica la transformación de una función en un servicio.

• Organizar adecuadamente los comités de gestión:Para organizaciones de desarrollo centralizado debe  designar un único grupo que realice la evaluación, especificación y control de todos los servicios. Y para empresas con un modelo de desarrollo distribuido se debe en crear comités de gestión en torno a aplicaciones principales.

• 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. 

• Ir más allá de la solicitud-respuesta:No se pueden crear procesos de negocios reales únicamente con los servicios de solicitud-respuesta por esta razón se tiene que tener presente la necesidad de servicios dirigidos por eventos cuando establezca la capa de transporte de servicio de su infraestructura.

• Tener en cuenta los estándares emergentes: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.

• Desarrollar para expandir y soportar todas las tecnologías y plataformas: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.

Referencias 

http://sigc.wikidot.com/system:las-siete-claves-del-exito-soa

http://na-h-www0.tibco.com/international/spain/resources/es_soa_together_adv.pdf

¿ COMO IMPLEMENTAR SOA ?

Hola a todos, esta semana hablaremos de lo necesario para llevar una buena implementación de SOA en las organizaciones, Lo que conlleva retos que de no llevarse a cabo pueden convertirse en problemas  

La adopción de SOA requiere de cambios en las organizaciones, entre los que encontramos:

• Se requerirán cambios organizacionales, especialmente a las estructuras administrativas.
• Se requerirá educar totalmente al personal de TI y los socios de negocio para asegurar un conocimiento consistente de la arquitectura y el desarrollo.
• Se requerirá una nueva infraestructura y actualizaciones.
• La gente se resiste al cambio y puede regresar a los viejos hábitos, perdiendo así los beneficios de SOA.

Si podemos llevar estos cambios a cabo la implementación de SOA la podemos hacer de la siguiente forma: Se comienza definiendo áreas de negocio e integrando conjuntos de necesidades de negocio. Más tarde se definen los servicios y su ensambladura para satisfacción de las necesidades. Sólo al final del proceso se diseñan los elementos modulares mínimos que se engranarán para suministrar los servicios.

La implementación SOA se realizará progresivamente para no generar estrés o traumatismo en los otros procesos existentes, y su aceptación y puesta en marcha será  progresiva. De esta forma, se asegura que si llega a existir un fallo o problema se puede  resolver en el proceso de implementación y así no generar gran conflicto con el resto de  procesos existentes.

Referencias 

http://www.iworld.com.mx/iw_news_read.asp?iwid=5544

http://www.financialtech-mag.com/_docum/111_Documento_SOA_Profit.pdf
http://www.theserverlabs.com/es/implementacioa.html

SOA Y BPM

Hola a todos esta semana hablaremos de la relación entre SOA y BPM, De cómo estas dos estrategias se pueden complementar para lograr que TI este alineado con las estrategias del negocio.

El reto se presenta en las  organizaciones las cuales generalmente  están compuestas de diferentes aplicaciones y sistemas construidos con tecnologías heterogéneas, utilizando múltiples bases de datos, y ejecutándose en varias plataformas .Además de la falta de mecanismos de comunicación entre el negocio y el departamento de TI.

Con el objetivo de hacer frente a estos desafíos, las organizaciones han dirigido su mirada hacia dos disciplinas y tecnologías: BPM (Business Process Management) y SOA (Services Oriented Architecture).

Aunque BPM y SOA tienen características que las hacen muy diferentes, lo más importante es que se complementan perfectamente realizando considerables aportaciones a los procesos de negocio .

La función de cada una de estas disciplinas las podemos resumir en:

·        BPM posibilita el desarrollo y la automatización de la gestión por procesos en una organización.

·        SOA  proporciona elementos clave para la transformación de las distintas aplicaciones existentes en las organizaciones,  en servicios reutilizables basados en estándares de integración, que al mismo tiempo facilitan la integración de las diferentes aplicaciones y sistemas entre sí.

BPM y SOA ayuda en gran medida a reducir la complejidad de las tecnologías de la información, acelerando la automatización de los procesos en las organizaciones y posibilitando un desarrollo más rápido de las aplicaciones de negocio, a la vez que contribuye a hacer los procesos de negocio más ágiles y flexibles.

En conclusión la unión de estas dos herramientas posibilita a las  empresas ajustar mejor los objetivos de los servicios informáticos y los objetivos de  negocio, mejorando el rendimiento de sus procesos de negocio, y convirtiéndose en una  empresa más ágil y competitiva.  




Referencias 
http://www.delfos.co.cu/boletines/bsa/PDF/28soaybpmlacombinacionperfecta.pdf
http://www.computing.es/Informes/201002190035/-BPM---SOA-una-sinergia-ventajosa-Lorena-Delgado-e-Inigo-Vega;-Area-de-Consultoria-y-Conocimiento-BPM-de-Ibermatica.aspx
http://www.activevos.com/blog/soa/bpm-and-soa-belong-together/2009/09/10/

FASES DE MADUREZ DE SOA

Hola a todos, esta semana hablaremos de las diferentes fases que describen el grado de madurez de una arquitectura SOA implementada en una organización, esta evaluación no solo contempla la perspectiva  tecnológica sino  que  tiene en cuenta las  perspectivas funcionales y de negocio.

 Las fases de Madurez son:

1. Servicios Iníciales: En esta fase no existe un alineamiento con las necesidades de negocio, Se implementan funcionalidades para cubrir necesidades primarias.
2. Servicios con Arquitectura: En esta fase se ejerce un control sobre los servicios lo cual proporciona consistencia y  fiabilidad de estos.
3. Servicios de Negocio y Colaborativos: Existe un alineamiento con las necesidades de negocio a través de los servicios, de tipo:
• Servicios orientados a los negocios, tales como gestión de procesos de negocio (BPM).
• Servicios colaborativos donde se definen servicios que sirven de interacción entre entidades, partners o los mismos departamentos de la organización.
4. Medición de los Servicios de Negocio: Se analizan los resultados de los servicios mediante el uso de métricas definidas y analizadas por usuarios de negocio y tecnológicos.
5. Optimización de los Servicios de Negocio: Fase en la que los servicios son analizados para encontrar puntos de mejora continua no solo se  analizan de manera individual sino también de forma conjunta analizando las interacciones entre ellos.

Referencias:
http://blogs.vass.es/?p=423
http://www.mydeveloperconnection.com/html/service_oriented_architecture.htm
http://www.steerahead.com/soastrategy-ep.htm

SOA Governance

Hola esta semana hablaremos de la importancia del control de la implementación del modelo de arquitectura SOA en la organización a través de SOA Governance.

Implementar una Arquitectura Orientada a Servicios (SOA) en una compañía es un proceso complejo, debido a que SOA se basa en desarrollar componentes (servicios) reutilizables, y con estos servicios componer nuevas soluciones tecnológicas para el negocio, esto implica un cambio cultural en como se construyen los sistemas, y un cambio en el ámbito de las soluciones:

•  En SOA los proyectos son transversales abarcan distintas áreas, y distintas aplicaciones, siguiendo el flujo transversal de los procesos de negocio de las compañías.
• En SOA las soluciones se comparten, y se construyen para que los próximos proyectos se vean beneficiados.

“SOA Governance define cambios en la administración del área tecnológica (TI) para  asegurar que los conceptos y  principios de SOA, y su arquitectura distribuida sean manejados apropiadamente, y que sea capaz de lograr los objetivos de negocio de los servicios”

SOA Governance debe definir:

• Que Hacer: El plan global de proyecto SOA de la Empresa, define el “SOA Roadmap” (Plan de Ruta SOA).
•  Quien lo Hace: La estructura organizacional (los grupos de trabajo), define la “SOA Office”.
•  Como Hacerlo: Los procesos (procedimientos) de administración, las normas.
• Como Medirlo: Las métricas para medir el éxito.

Algunos Problemas por falta de Governance:

• Se han implementado servicios con falencias en SOA, que no aseguran reutilización o flexibilidad.
• No está definido quien diseña el Servicio.
• No hay instancia de revisión del diseño del Servicio.
• Cada proyecto crea sus propias herramientas, o librerías, y estas no quedan documentadas, y accesibles para los demás.
• Las experiencias buenas o malas de los proyectos quedan en el proyecto. 

Referencias

http://www.grupocmc.es/articulos/soaPorQueYParaQue_eCuadrado.pdf

http://soaagenda.com/journal/articulos/soa-governance-es-fundamental/

http://www.slideshare.net/soaagenda/soa-governance-enfoque-practico

¿Qué es Bajo Acoplamiento?

Para las personas familiarizadas con la Programación Orientada a Objetos y los patrones de diseño GRASP (General Responsibility Assignment Software Patterns), una clase está altamente acoplada si tiene muchas asociaciones con otras clases, la principal consecuencia es la poca mantenibilidad que le da al código, pues modificar una clase involucra también realizar cambios en muchas otras.

Ahora, a modo más general y hablando no en términos de clases sino de aplicaciones, el contexto de acoplamiento cambia, pues empieza a tomar importancia cuando es necesario usar mecanismos de integración para lograr interoperabilidad entre aplicaciones. Se habla de distintas dimensiones que permiten medir este acoplamiento, a continuación algunas de estas:

Ubicación: Una aplicación no debe tener datos “quemados” en su código fuente como la dirección física o IP de donde residen otras aplicaciones con las cuales se desea establecer una comunicación. Esta mala práctica o antipatrón de diseño se conoce como Hard code.

Número de receptores: Una aplicación se considera altamente acoplada si tiene un orden explicito de llamados a otras aplicaciones. Esta tarea de controlar los mensajes entre aplicaciones la debe realizar una capa superior, por ejemplo, mediante orquestación de servicios web.

Disponibilidad de los sistemas: Una aplicación no debe depender de la disponibilidad de otras aplicaciones para funcionar, si necesita enviar un mensaje, se debe contar con un mecanismo de buffering en caso de que la aplicación destino no se encuentre disponible, y entregárselo una vez cambie de estado.

Tiempo de respuesta: cuando una aplicación hace llamados a otras aplicaciones, la decisión sobre el límite de tiempo de espera para recibir una respuesta debería considerar distintos factores como los canales de comunicación o la carga sobre otros sistemas.

Referencias:

http://wiki.sdn.sap.com/wiki/display/BBA/Loose+Coupling+Through+Web+Services

http://es.wikipedia.org/wiki/Hard_code

http://www.infoq.com/articles/tilkov-10-soa-principles

¿El FUTURO DE SOA?

Ante la aparición de Web  2.0 estos servicios cada día se ven  necesitados a enfocarse en el tema de la red. Por lo cual se busca la  consolidación de un nuevo modelo arquitectónico, el cual está llamado a ser el modelo a utilizar en el futuro, donde todo, desde la información hasta el acceso a otros recursos están orientados a la web. Es habitual encontrar que  en una organización la adopción de SOA se limita a ser implementada y accesible desde un ámbito privado de la organización (red privada).Por lo tanto es necesario adoptar una arquitectura orientada  a la web (WOA).

WOA (Web-Oriented Architecture o Arquitectura Orientada a la Web)  Podemos  definir WOA como una extensión de SOA en la que los artefactos son implementados como recursos REST (Representational State Transfer) y que serán accesibles por medio de UDDI (Universal Description Discovery and Integration) que se encargará de identificar la ubicación de los recursos en la red.

Una de las características más importantes de WOA, es que los mensajes y las interacciones están auto-contenidos.WOA no requiere de un contrato de servicios como los tradicionales webservices ya que este está implícito en la URL y en la forma del recurso.

Por último  se puede diferenciar la concepción de  SOA como la necesidad de hacer sistemas de negocios de TI que sean agiles respecto a los cambios en el mercado y a WOA como la necesidad de llevar estos sistemas a la evolución de la web con la llegada de la web colaborativa. Por lo tanto SOA es un tipo de arquitectura que sigue vigente y se acomoda a las nuevas necesidades que se van presentando.

Referencias:

http://www.zdnet.com/blog/hinchcliffe/the-soa-with-reach-web-oriented-architecture/27
http://www.tec.url.edu.gt/boletin/URL_19_SIS07_REDES.pdf
http://blogs.vass.es/?p=535

UDDI

Universal Description Discovery and Integration (UDDI) es un framework independiente de plataforma que permite describir, descubrir e integrar Web services.


Como principales beneficios de UDDI están las facilidades de reutilización y ahorro en tiempo y costos de implementación de servicios web, pues mediante el descubrimiento de servicios ya existentes y publicados por terceros, es posible mantener procesos de negocio de forma ágil y lograr interoperabilidad no solo a nivel interno de la organización, también entre diferentes empresas.

Para dar una idea de los posibles usos de este framework, podemos hablar de las aerolíneas, estas pueden registrar sus servicios de reserva de vuelos en un directorio de UDDI, las agencias de viajes pueden buscar las interfaces o los contratos de los servicios web de las aerolíneas, y una vez encuentren el que necesitan, puede empezar a usarlo inmediatamente.

Los principales conceptos de UDDI son:

• UDDI Data Model: Incluye tipos de datos que incluyen descripción de los servicios, por ejemplo, cual es su función (businessService) o quien es el publicador del servicio (businessEntity).

• UDDI Nodes and Registers: incluye una específica definición de las relaciones de jerarquía que hay entre los servidores que tienen implementaciones de UDDI.

• Essential Programmatic Interfaces: provee funcionalidades claves como publicar o buscar información sobre un servicio en el registro UDDI.

UDDI es patrocinado por OASIS (Organization for the Advancement of Structured Information Standards), un consorcio que impulsa el desarrollo, convergencia y adopción de estándares abiertos y la organización que más desarrolla estándares de servicios web.

Referencias:

http://www.w3schools.com/WSDL/wsdl_uddi.asp

http://www.oasis-open.org/who/

http://uddi.xml.org/uddi-101

http://www.ibm.com/developerworks/webservices/library/ws-featuddi/

CUANDO LOS MUNDOS DE LA ARQUITECTURA SOA Y WEB 2.0 CHOCAN

Hola esta semana les hablaremos de como dos tipos de arquitecturas como SOA y WEB 2.0 las cuales tienen propósitos diferentes pero su integración permite una mejor forma de soportar los procesos de una organización.

Aparentemente SOA y WEB 2.0 se basan en filosofías muy diferentes, El primero se basa en la idea de la fuerza de la  estandarización  cuidadosa  a través de contratos. Los cuales me permiten la integración de los diferentes sistemas  que soportan los  diferentes procesos de negocio de la organización. Por otro lado Web 2.0 tiene como objetivo principal la oportunidad de conectar personas y soportar sus esfuerzos colaborativos. Ciertamente Web 2.0 también dirige elementos asociados a conexión de aplicaciones y datos, pero se distingue en que se dirige explícitamente a una dimensión más social. Por esta razón se cuestiona su uso empresarial.

Como se puede observar estas dos arquitecturas comparten  los siguientes aspectos de :

1.          La integración de plataformas de servicios.
2.          La no dependencia de un unico proveedor. 

La combinación de estas dos filosofías que va a permitir la obtención de las siguientes características:

Mejora de accesibilidad
Una mejor  forma de acceder a  los servicios SOA es  proporcionando una interfaz mas sencilla mediante WEB 2.0 a través de REST, lo que implica más facilidad en la comunicación.

Reutilizacion 

Tanto WEB 2.0 y SOA poseen el concepto de reutilizacion. lo que permitirá la construcción de aplicaciones mas complejas a partir de unas ya existentes.

Fácil Desarrollo 

Tienen entornos para el desarrollo rápido y fácil de aplicaciones.

Innovación 
Realizar aplicaciones de gran impacto visual utilizando WEB 2.0 soportando sus operaciones con servicios SOA.

Referencias
http://www.itsc.org.sg/pdf/synthesis08/Five_SOA.pdf
http://www.zdnet.com/blog/hinchcliffe/when-the-worlds-of-soa-and-web-20-collide/35
http://webdoscero.blogspot.com/2006/05/soa-versus-web-20-en-espaol.html

La

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

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

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/

¿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:

http://www.gestiopolis.com/administracion-estrategia/erp-arquitectura-orientada-a-servicios.htm

http://es.w3support.net/index.php?db=so&id=638700

Diccionario SOA

Hola, como hemos venido hablando, SOA es una arquitectura para la integración de aplicaciones empresariales basada en la colaboración de sistemas ya existentes, con el objetivo de dar soporte a un proceso de negocio.

Es posible que algunos conceptos relacionados con SOA sean familiares o no, por lo tanto hemos decidido realizar un pequeño diccionario de consultas donde explicaremos algunos términos que se van a usar a lo largo del desarrollo de este blog.

Arquitectura de Software:

Arquitectura o configuración, nos dice como debe estar estructurado el software y como se deben comportar y relacionar sus elementos para que cumpla con los requerimientos de un enfoque en particular.

Servicio Web:

Elemento que incluye lógica de negocio y manejo de datos, y es altamente cohesivo debido a que es diseñado con un propósito específico, por ejemplo consultar a un sistema de información catastral si un predio está hipotecado o no.

Su principal característica es que permite la comunicación entre aplicaciones, independientemente de la plataforma sobre la que corran o el lenguaje de programación con que fueron implementadas.

Cliente de servicios:

Puede ser una aplicación o un servicio que necesita invocar un servicio de un proveedor.

Proveedor de servicios:

Aplicación que dispone a sus servicios de una interfaz y los publica en un repositorio para que puedan ser invocados por clientes.

Descripción de un servicio:

Esquema que especifica la forma en que se invoca un servicio, su funcionalidad y sus parámetros de entrada y salida.

Protocolo de comunicación de servicios:

Conjunto de reglas de comunicación mediante el cual un proveedor y un cliente se ponen de acuerdo en como se van a comunicar entre sí.

Proceso de negocio:

Conjunto de servicios que se invocan en un orden definido para satisfacer requerimientos del negocio.

Registro de servicios:

Repositorio donde los proveedores pueden publicar la descripción de sus servicios y donde los clientes pueden encontrar servicios disponibles.

Orquestación:

Un controlador central es quien conoce el flujo de control, es decir, en que momento se debe invocar a cada uno de los servicios, además de la información requerida en un proceso. En este caso cada servicio ejecuta tareas independiente de los demás.

Coreografía:

Los servicios interactúan entre sí sin la necesidad de un controlador central, por lo tanto cada servicio realiza sus tareas pero es posible que sus entradas sean las salidas de otro servicio.

Referencias:

http://www.gestiopolis.com/administracion-estrategia/erp-arquitectura-orientada-a-servicios.htm

http://pensandoensoa.com/2010/04/04/dicsoanario-diccionario-soa/

Video introducción a SOA

Hola, a continuación les presentamos un video donde se expone a manera de ejemplo, qué es una arquitectura orientada a servicios.

Referencias:
http://www.gestiopolis.com/administracion-estrategia/erp-arquitectura-orientada-a-servicios.htm
http://bpm-soa-experiences.blogspot.com/search/label/SOA
http://www.microsoft.com/soa

Bienvenidos Al Blog Conociendo SOA

Hola a todos nuestros visitantes  a lo largo del semestre estaremos  actualizando el blog semanalmete  con noticias e informacion relevante a  Service-oriented architecture ( SOA ). Esperamos que sea de su agrado y que aprendan de este interesante tema.