La orientación a servicios describe una arquitectura de servicios independientes entre si que se acoplan para soportar los diferentes requerimientos de los usuarios y los procesos de negocio. Los recursos de una RED en un ambiente SOA se hacen independientes de la plataforma tecnologica que los soporta, lo único importante es que apoyan a los procesos de negocios.

Sin embargo no hay una definición exacta sobre la que se haya puesto de acuerdo la comunidad de tecnologia sobre SOA, más alla de su traducción literal como una Arquitectura cuyo principio principal de diseño es ser orientada a servicios.

SOA no esta atado a una tecnología específica. Puede ser implementado utilizando un amplio rango de tecnologías, incluyendo REST, RPC, DCOM, CORBA o Web Services.

Soa está diseñado para enlazar negocios y recursos computacionales on demand(principalmente organizaciones, aplicaciones y datos) para obtener los resultados deseados por los usuarios de los servicios (que pueden ser usuarios finales u otros servicios). OASIS la organización para estandares avanzados estructurados define SOA como lo siguiente:

“Es un paradigma para organizar y utilizar capacidades distribuidas y bajo el control de diferentes propietarios y dominios. Provee una manera uniforme de ofrecer, descubrir, interactuar y usar dichas capacidades para producir los efectos deseados de manera consistente y medible.”

Los principales factores para la adopción de SOA son las interacciones entre recursos computacionales y el intento de reutilizar estos recursos. Un arquitecto empresarial cree que SOA puede ayudar a su negocio a responder más rápido y a menor costo a las condiciones variantes del mercado. Este tipo de arquitectura promueve el reuso de servicios a nivel macro en lugar de a nivel micro (o nivel de objetos). SOA puede tambien simplificar las interconexiones y el reuso de los sistemas antiguos o legacy systems.

Muchos de los “nuevos” conceptos enmarcados en SOA fueron propuestos desde las decadas de los 70, 80 y 90 por otras teorias como la programación modular, el diseño orientado a eventos o los diseños basados en interfases/componentes.

La siguiente principios guia establecen las bases para el desarrollo, mantenimiento y uso de SOA:

• Reuso, granularidad, modularidad, componentización, interrelacionamiento de los componentes e interoperabilidad.
• Cumplimiento con estandares (tanto estandares comunmente aceptados como especificos de cada industria).
• Identificacion y categorización de servicios, provisionamiento y despacho, así como monitoreo y seguimiento.

Los siguientes son los principios especificos de la arquitectura SOA para el diseño y definición enfocada en servicios que deberan influenciar intrinsecamente el comportamiento de un sistema, su estilo y diseño:

• Encapsulamiento de servicios.
• Servicios de Acoplamiento Suelto (Service Loose coupling) - Este servicio mantiene un relacionamiento que minimiza las dependencias entre sistemas y unicamente requiere que cada parte simplemente tenga conocimiento que el otro existe.
• Contrato de servicios: Los servicios se deben incluir en los acuerdos de comunicaciones que se definen de comun acuerdo en los documentos de descripción de servicios entre uno o mas servicios.
• Abstracción de servicios: Más alla de la descripción del servicio, está la logica oculta de como funciona el servicio en el mundo real.
• Documentacion del servicio: Una descripción del diseño orientado al servicio debe contener al menos tres usos diferentes de la frase “valor para el negocio”.
• Reutilización o reuso del servicio: Se deberán plantear servicios que puedan ser facilmente reutilizados.
• Empaquetamiento de servicios: Una coleccion de servicios que pueden ser coordinados y ensamblados para formar un paquete compuesto de servicios.
• Autonomia de servicios: Servicios que tienen el control sobre la logica que ellos encapsulan.
• Optimización de servicios: Aseguramiento de servicios de alta calidad.
• Habilidad de descubrimiento de servicios: Los servicios son creados con descripciones adecuadas de manera que puedan ser descubiertos utilizando los mecanismos adecuados para tal fin.
• Uso eficiente de los recursos del sistema
• Madurez del servicio y desempeño.
• EAI Enterprise Application Integration (integracion con aplicaciones empresariales).

La metodologia de modelamiento y diseño utilizada por aplicaciones SOA se comenzo a conocer como “Diseño y analisis orientado a servicios” o SOAD (Service-oriented analysis and design). SOAD es una metodologia de diseño para desarrollo de sistemas muy agiles en un modelo cliente/productor donde se abstrae la implementacion de el proceso actual, de manera que el servicio proveido puede ser modificado o cambiado sin afectar al cliente.

Basicamente se debe estructurar un contrato de servicios que debe contener los siguientes componentes:

• Encabezado
• Nombre del servicio.
• Version del contrato de servicio.
• Propietario: Persona o equipo encargados del servicio
• RACI
  • Responsable de los entregables del contrato/servicio.
  • Accountable (Dueño): Nivel maximo de escalamiento en terminos de el contrato/servicio.
  • Consultado: Quien debe ser consultado antes de tomar cualquier accion sobre el presente contrato/servicio.
  • Informado: quien debe ser informado sobre cualquier decision o accion que se vaya a tomar sobre el presente contrato/servicio.
• Tipo: Es el tipo de servicio, ayuda a distinguir en que capa residirá.
  • Datos
  • Procesos
  • Funcionalidad
  • Presentación
• Funcionalidad
  • Requerimientos funcionales: Indica especificamente la funcionalidad que este servicio debe proveer. El lenguaje debe permitir la generación de casos de prueba sobre la funcionalidad.
  • Operación del servicio: Se debe definir en terminos de que parte de la funcionalidad se provee (metodos usados, acciones etc).
  • Invocación: Indica los medios como se invoca o llama al servicio, eto puede ser URL, interface, triggers etc. Pueden existir multiples caminos para invocar un mismo servicio.
• Requerimientos no funcionales, tales como
  • Seguridad: Roles, mecanismos de invocación etc.
  • Calidad del servicio: Determina el nivel de tolerancia de fallos del servicio.
  • Transaccionales: Es este servicio capas de realizar gran cantidad de transacciones? cuantas? bajo que condiciones?
  • ANS (Acuerdos de nivel de servicios) o SLA: Determina la maxima latencia permitida para el servicio bajo la cual se pueden realizar acciones.
  • Semantica: Define el glosario de terminos usadas en la descripción e interfases del servicio. (similar al common language del pmi)
  • Procesos: Describe los procesos (si existen) relacionados con el contrato de servicios.

SOA se puede construir sobre servicios web estandares (por ejemplo SOAP) los cuales gozan de gran aceptación industrial. Estos estandares (tambien definidos como especificaciones de servicios web) tambien proveen gran interoperatibidad y protección contra vendedores de software propietario. Sin embargo es posible implementar SOA utilizando cualquier tecnologia basada en servicios como por ejemplo Jini.

Los servicios web relevantes para SOA son los siguientes:

• XML : Un lenguaje de etiquetas para describir datos en mensajes en formato de documento. Similar a html pero mucho mas completo y amplio.
• HTTP o HTTPS: Protocolo para solicitar o responder mensajes entre clientes y servicios. Protocolo estandar web.
• SOAP: Protocolo para intercambiar mensajes basados en XML en una red de computadores, usualmente usando HTTP.
• WSDL o Lenguaje de descripción de servicios web: Servicio basado en XML que describe las interfaces publicas, protocolos y formato de mensajes, requeridos para interactuar con un servicio web.
• UDDI o Descripción, descubrimiento e Integración Universal: Registro basado en XML para publicar descripciones de servicios (WSDL) y permitir su descubrimiento.

Tenga en cuenta sin embargo que un sistema no necesita algunos o todos estos estandares para ser orientado a servicios, por ejemplo hay sistemas orientados a servicios que se han implementado usando Corba, Jini y REST.

Web 2.0 hace referencia a la segunda generacion de websites, principalmente a la posibilidad que tienen los visitantes de contribuir con el website colaborando y compartiendo (tal como en la wiki de WADOOA). Las aplicaciones web 2.0 pueden utilizar servicios web como wikis, AJAX, Blogs etc. Mientras que no hay un conjunto de estandares para web 2.0, estos se caracterizan por construirse sobre arquitecturas web que utilizan servicios, por lo tanto Web 2.0 puede estar considerado dentro del marco de SOA.

Oracle comezo a hablar de SOA 2.0 como la proxima generación de SOA, combinando la arquitectura orientada a servicios y la arquitectura enfocada en eventos, de igual manera categorizó a la primera generación de SOA como enfocada en client-servidor.

Sin embargo la comunidad en general considera estas afirmaciones más como mercadeo de productos o evangelización de la nueva forma de hacer las cosas. En general se comenta que en lugar de hablar de SOA 2.0, se deberia hablar de la evolución de SOA.

Uno de los más obvios y comunes retos es el manejo de servicios de metadata. Los ambientes basados en SOA pueden incluir muchos servicios que intercambian mensajes para realizar tareas. Dependiendo del diseño una simple aplicación puede generar millones de mensajes. Manejar y proveer la información sobre como deben interactuar los servicios puede ser una tarea muy compleja.

Otro de los retos es proveer los niveles apropiados de seguridad. Un modelo de seguridad integrado dentro de una aplicacion, puede ya no ser apropiado cuando las funciones de la aplicacion estan expuestas como servicios que pueden ser usados por otras aplicaciones. Esto significa que el modelo de seguridad basado en aplicaciones ya no es el modelo adecuado para manejar la seguridad de los servicios. Actualmente estan surgiendo nuevos modelos de seguridad para SOA.

De igual manera las especificaciones de SOA y Webservices estan constantemente en expansión, actualización y refinamiento, por lo que hay muy poca gente con el conocimiento y experiencia para trabajar con sistemas SOA.

Interoperabilidad es otro aspecto importante en implementaciones de SOA. Es importante que se tengan en cuenta los estandares desarrollados por la organizacion WS-I (Web Services) como Basic Profile y Basic Security Profile. De igual manera las herramientas de pruebas desarrolladas por esta organización para asegurar que un servicio cumple con sus estandares.

Finalmente se debe tener en cuenta que no todo lo que los vendedores de tecnologia SOA estan prometiendo es realizable siempre, ya que en algunos casos las expectativas de reducir costos de TI, mejorar agilidad de los sistemas, mejores tiempos de desarrollo y puesta en produccion etc, no se obtienen. Es altamente relevante contar con un equipo lo suficientemente preparado (interno y externo) ya que los beneficios potenciales dependen de GRAN MANERA del diseño de la arquitectura de los sistemas.

Algunas criticas de SOA radican en los requerimientos de mayor necesidad de poder de procesamiento dadas las capas adicionales que se incluyen en esta arquitectura.

Tambien se discute sobre los problemas de escalabilidad, dado que cualquier nueva funcionalidad debe ser consultada/acordada con los actores del sistema y se deben tener en cuenta las afectaciones que un cambio puede generar en cascada.

Un problema adicional es que los estandares y productos aun estan evolucionando, por lo que se corre un alto riesgo de incurrir en sobre costos adicionales por no estar implementando una tecnologia madura.

Adoptar SOA es solo el primer paso para definir un sistema real de negocios. El siguiente paso en el proceso de diseño es la definición de una plataforma de despacho de servicios (SDP) y su implementación. Es en el diseño de un SDP donde se define los modelos de información del negocio, manejo de identidades, productos, dispositivos y caracteristicas del servicio para el usuario, asi como de que manera el sistema puede manejar la evolución del negocio y sus clientes.

HyPerformix IPS Performance Optimizer

HP Management Software / Mercury SOA Manager

IBM Tivoli Framework

Tidal Software Intersperse

Unify Corporation Nxj products

• Productos y proveedores de SOA
• Enterprise Service Bus (ESB).
• Graficas descripción SOA.
• SOA Governance
• Service-oriented analysis and design
• Comparison of business integration software
• Service-Oriented Architecture Implementation Framework
• otros docs: http://www.soablueprint.com/whitepapers/SOAPGPart2.pdf http://www.soablueprint.com/whitepapers/SOAPGPart3.pdf http://www.soablueprint.com/whitepapers/SOAPGPart1.pdf

• SOA Segun SUN: http://www.sun.com/products/soa/index.jsp
• SOA segun microsoft: http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp
• SOA segun Oracle: http://www.oracle.com/technologies/soa/index.html?SC=NA05060039C0.GCM.7001.SOA.soa.br

Curso ITIL

Ejercicios de preparación para el examen de certificacion de ITIL

Curso SOA

Examen de certificacion PMP

El PMI

El PMBOK

Teoria de gerencia de proyectos

preguntas examen pmp

Recuerde visitar nuestros otros portales:

• Pagina PMI Colombia
• Portal de Empleo Latinoamericano
• Foro mundial del trabajo - en ingles
• Headhunters Portal