Arquitectura Orientada a Servicios[Pick the date]Sistemas Operativos DestribuidosArquitecturaOrientada aServiciosTrabajo P...
Arquitectura Orientada a Servicios1Introducción1ÍNDICEIntroducción...........................................................
Arquitectura Orientada a Servicios2Introducción2INTRODUCCIÓNLas empresas necesitan poder interconectar los procesos, perso...
Arquitectura Orientada a Servicios3Qué es SOA?3QUÉ ES SOA?La Arquitectura SOA establece un marco de diseño para la integra...
Arquitectura Orientada a Servicios4Conceptos Relevantes4CONCEPTOS RELEVANTESSERVICIOUn servicio en SOA es una función de a...
Arquitectura Orientada a Servicios5Conceptos Relevantes5Es fundamental la separación entre la interface y la implementació...
Arquitectura Orientada a Servicios6WEB Services6WEB SERVICESUn error muy común es confundir servicios, componentes que for...
Arquitectura Orientada a Servicios7WEB Services7Ventajas de los Servicios Web. Proporcionan Interoperabilidad entre aplic...
Arquitectura Orientada a Servicios8WEB Services8XML, BASE DE LOS WEB SERVICESEl XML Es un metalenguaje, dado que todo paqu...
Arquitectura Orientada a Servicios9WEB Services9El XML se completa mediante una “hoja de estilo”, que es una descripción d...
Arquitectura Orientada a Servicios10WEB Services10ESTÁNDAR SOAPEn el núcleo de los servicios Web se encuentra el protocolo...
Arquitectura Orientada a Servicios11WEB Services11Además de definir un sobre de SOAP, la especificación de SOAP define una...
Arquitectura Orientada a Servicios12WEB Services12ESTÁNDAR WSDLWSDL (Web ServiceDescriptionLanguage) es el lenguaje estánd...
Arquitectura Orientada a Servicios13WEB Services13WSDL es un lenguaje basado en XML creado para definir el interfaz de los...
Arquitectura Orientada a Servicios14WEB Services14ESTÁNDAR UDDICuando todas las aplicaciones son locales, es muy sencillo ...
Arquitectura Orientada a Servicios15WEB Services15UDDI fue también concebida como un modo de mantener la ejecución de apli...
Arquitectura Orientada a Servicios16WEB Services16identifica al objeto. get_xx: Una vez que posee la clave única para ide...
Arquitectura Orientada a Servicios17Seguridad con Web Services17SEGURIDAD CON WEB SERVICESLa seguridad es uno de los mayor...
Arquitectura Orientada a Servicios18Seguridad con Web Services18Servicios que se deben implementar en un Web Services para...
Arquitectura Orientada a Servicios19WS-Security (WSS)19WS-SECURITY (WSS)El WS-Security (WSS) es una extensión del protocol...
Arquitectura Orientada a Servicios20Transacciones con Web Services20UsernameToken: se utiliza un nombre de usuario junto c...
Arquitectura Orientada a Servicios21Transacciones con Web Services21En general siempre se puede enfocar el diseño de los s...
Arquitectura Orientada a Servicios22Transacciones con Web Services22Entre los componentes que se encuentran en WS-Coordina...
Arquitectura Orientada a Servicios23Transacciones con Web Services23WS-TRANSACTIONWS-Transaction se apoya en la infraestru...
Arquitectura Orientada a Servicios24Bibliografía24BIBLIOGRAFÍA http://www.ibm.com/developerworks/ssa/webservices/newto/in...
Próxima SlideShare
Cargando en…5
×

Sod arquitecturas basadas en servicios

188 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
188
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
4
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Sod arquitecturas basadas en servicios

  1. 1. Arquitectura Orientada a Servicios[Pick the date]Sistemas Operativos DestribuidosArquitecturaOrientada aServiciosTrabajo Practico – UNLAM - 2012
  2. 2. Arquitectura Orientada a Servicios1Introducción1ÍNDICEIntroducción.................................................................................................................................................2Qué es SOA? ..............................................................................................................................................3Conceptos Relevantes ................................................................................................................................4Servicio....................................................................................................................................................4Interfaz definida o Contrato de Servicio ..................................................................................................4Entreprise Service Bus............................................................................................................................5WEB Services .............................................................................................................................................6XML, base de los Web Services..............................................................................................................8Estándar SOAP .....................................................................................................................................10Estándar WSDL.....................................................................................................................................12Estándar UDDI ......................................................................................................................................14Seguridad con Web Services....................................................................................................................17WS-Security (WSS)...................................................................................................................................19Transacciones con Web Services.............................................................................................................20WS-Coordination ...................................................................................................................................21WS-Transaction.....................................................................................................................................23Bibliografía ................................................................................................................................................24
  3. 3. Arquitectura Orientada a Servicios2Introducción2INTRODUCCIÓNLas empresas necesitan poder interconectar los procesos, personas e información tanto con la propiaorganización como -atravesando sus fronteras- con subsidiarias y socios comerciales. La falta deintegración entre los componentes de IT –sistemas, aplicaciones y datos- hace difícil obtener unarespuesta rápida y efectiva ante los cambios que afectan de forma natural a los negocios. Lainflexibilidad genera costes, reduce la capacidad de respuesta ante los clientes, compromete elcumplimiento con las normativas legales, y afecta negativamente a la productividad de los empleados.En suma, una deficiente integración es uno de los problemas más importantes a los que laorganizaciones deben hacer frente para mantener su competitividad y garantizar su crecimiento.La Arquitectura Orientada a Servicios (SOA, ServiceOrientedArchitecture) supone una estrategiageneral de organización de los elementos de IT, de forma que una colección abigarrada de sistemasdistribuidos y aplicaciones complejas se pueda transformar en una red de recursos integrados,simplificada y sumamente flexible. Un proyecto SOA bien ejecutado permite alinear los recursos de ITde forma más directa con los objetivos de negocio, ganando así un mayor grado de integración conclientes y proveedores, proporcionando una inteligencia de negocio más precisa y más accesible con lacual se podrán adoptar mejores decisiones, y ayuda a las empresas a optimizar sus procesos internos ysus flujos de información para mejorar la productividad individual. El resultado neto es un aumento muynotable de la agilidad de la organización.
  4. 4. Arquitectura Orientada a Servicios3Qué es SOA?3QUÉ ES SOA?La Arquitectura SOA establece un marco de diseño para la integración de aplicaciones independientesde manera que desde la red pueda accederse a sus funcionalidades, las cuales se ofrecen comoservicios. La forma más habitual de implementarla es mediante Servicios Web, una tecnología basadaen estándares e independiente de la plataforma, con la que SOA puede descomponer aplicacionesmonolíticas en un conjunto de servicios e implementar esta funcionalidad en forma modular.¿Qué es un servicio exactamente? Un servicio es una funcionalidad concreta que puede ser descubiertaen la red y que describe tanto lo que puede hacer como el modo de interactuar con ella.Desde la perspectiva de la empresa, un servicio realiza una tarea concreta: puede corresponder a unproceso de negocio tan sencillo como introducir o extraer un dato como “Código del Cliente”.Pero también los servicios pueden acoplarse dentro de una aplicación completa que proporcioneservicios de alto nivel, con un grado de complejidad muy superior –por ejemplo, “introducir datos de unpedido”-, un proceso que, desde que comienza hasta que termina, puede involucrar varias aplicacionesde negocio.
  5. 5. Arquitectura Orientada a Servicios4Conceptos Relevantes4CONCEPTOS RELEVANTESSERVICIOUn servicio en SOA es una función de aplicación empaquetadacomo un componente reutilizable paraser usado en unproceso de negocio.El servicio proporciona información o facilita el cambio dedatos de negocio de un estado válido yconsistente a otro.La implementación concreta de un servicio SOA no esimportante. A través de protocolos decomunicación biendefinidos, los servicios pueden ser invocados de manera quese hace hincapié en lainteroperabilidad y en la transparenciade localización.Los elementos que se componen un servicio son:Interfaz: contrato entre proveedor y consumidor. Define la forma y el procedimiento paraacceder a su funcionalidadLógica de negocio: implementación propiamente dichaCanal de comunicación: el medio físico y el conjunto de procedimientos parar poner en contacto(típicamente de forma remota) a los consumidores del servicio con su proveedorINTERFAZDEFINIDAOCONTRATODESERVICIOForma parte de la esencia misma de un servicio. Para que se considere un servicio, su interfaz deentrada/salida (su contrato con el cliente) tiene que estar explícitamente declarado. Los campos queforman parte de este interfaz deben estar correctamente tipados y ser conocidos. Con la ayuda de losestándares como WSDL y XSD, el contrato del servicio está auto descrito.Por consiguiente, los servicios web con un campo de entrada y otro de salida, en el que se inserta a suvez un XML como contenido (que no está descrito en ninguna parte) no puede considerarse un servicioweb, a pesar de que parece que son los que más abundan.Las aplicaciones SOA publican sus servicios y no saben quien los va a usar ni donde, estandofuera delcontrol de la aplicación. Publican un contrato (interface) que se mantendrá constante a lo largo del ciclode vida del servicio. El ciclo de vida de un servicio diferencia entre los servicios en producción y endesarrollo, para los servicios en producción nunca se modificará su interface sino que en su lugar elservicio se marcará como en desuso y se notificará a sus consumidores que hay una nueva versión delservicio disponible que deberán usar.
  6. 6. Arquitectura Orientada a Servicios5Conceptos Relevantes5Es fundamental la separación entre la interface y la implementación. El usuario de un servicio sólonecesita (y debe) conocer la interface. La implementación puede cambiar a lo largo del tiempo sin quepara ello deba afectar a sus consumidores.ENTREPRISESERVICE BUSOtro concepto muy asociado a SOA y que también conviene aclarar es el de ESB (Enterprise ServiceBus). A diferencia de SOA, ESB sí es una tecnología o producto software. Puede definirse un ESB comola Infraestructura que sirve como el backbone de las Arquitecturas Orientadas a Servicios (SOA). UnESB permite a una empresa, conectar,mediar, y controlar la interacción entre diversas aplicaciones yservicios a lo largo de entornosaltamente distribuidos yheterogéneos.SOA de por sí puede aportar una gran potencia y flexibilidad a una organización sin necesidad de utilizarun ESB, pero sin un ESB es muy complicada la gestión y mantenimiento de los procesos SOA y elescalado de la arquitectura en caso de ser necesario. Normalmente un ESB debe proporcionar a unaorganización por un lado un sistema de mensajería robusto de alta disponibilidad y altamente escalableque permita garantizar la comunicación entre los distintos servicios y aplicaciones de la organizaciónindependientemente de su localización geográfica, y por otro lado un mecanismo que permita fácilmentela definición de nuevos procesos o su posterior modificación orquestando los servicios existentes en laorganización. Además debe proporcionar funcionalidades avanzadas como la de enrutamiento de datosdinámico basado en el contenido de estos.
  7. 7. Arquitectura Orientada a Servicios6WEB Services6WEB SERVICESUn error muy común es confundir servicios, componentes que forman una arquitectura SOA, conservicios web. Los servicios web son una forma de implementar estos servicios, pero no es obligatorioque los servicios estén implementados como servicios web aunque sí es lo más común.Los Servicios Web son piezas de Software que utilizan un conjunto de Protocolos y Estándares quesirven para intercambiar datos entre aplicaciones. Este intercambio de información es posible gracias aque estos componentes utilizan los mismos protocolos y Estándares y por lo tanto no importa el lenguajede programación, plataforma o Sistema Operativo en el que se ejecuten, estos van a podercomunicarse.Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación delos servicios Web.El siguiente listado muestra una serie de protocolos base de los Servicios Web. XML (eXtensibleMarkupLanguage):Metalenguaje usado en Servicios Web para especificar loslenguajes y protocolosnecesarios SOAP (Simple Object Access Protocol): Protocolos sobre los que se establece el intercambio. WSDL (Web ServicesDescriptionLanguage): Es el lenguaje de la interfaz pública para los serviciosWeb. Es una descripción basada en XML de los requisitos funcionales necesarios para estableceruna comunicación con los servicios Web. UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información delos servicios Web. Permite comprobar qué servicios web están disponibles.
  8. 8. Arquitectura Orientada a Servicios7WEB Services7Ventajas de los Servicios Web. Proporcionan Interoperabilidad entre aplicaciones de Software, independientemente de latecnología o plataformas en las que estén desarrollados. Fomentan los protocolas basados en texto lo que permite acceder y entender más fácilmente sucontenido. Promueve la integración de servicios localizados en geografías distintas para brindar servicios máscompletos. Permite la reutilización de las funcionalidades encapsuladas en los servicios web. Facilita la recombinación de servicios para proveer funcionalidades más completas.Así, el conjunto de características de los servicios web permiten que sean la base de una arquitecturaOrientada a Servicios. Esto es los servicios que puede proporcionar una institución son organizados enunidades atómicas que va a permitir su utilización y recombinación con la finalidad de brindarservicios más complejos o con una mayor cantidad de características. A esta organización de serviciosse le denomina Cartera de Servicios Web.
  9. 9. Arquitectura Orientada a Servicios8WEB Services8XML, BASE DE LOS WEB SERVICESEl XML Es un metalenguaje, dado que todo paquete XML describe en forma universal cualquier tipo dearchivo. Es decir permite contener su léxico propio, sintaxis, semántica y pragmática, desligando lainformación del formato con que fue creada. En efecto, XML transforma completamente la creación y eluso de software, revolucionando la comunicación entre aplicaciones o entre equipos, dado que ofreceun formato de datos universal, que permite adaptar o transformar fácilmente la información y transmitirlacon estructura.XML es una generalización más exacta y precisa que el HTLM. En efecto el HTML es un lenguaje quedescribe una pagina Web desde un archivo plano, incorporando TAGs bajo una sintaxis predeterminada.HTML = Texto + TAGs + Sintaxis PredeterminadaSin embargo, en XML – que también es un archivo de texto plano - se marca TODO. Cualquierinformación transmitida por un XML está perfectamente estructurada, las TAGs no son fijas, sinovariables según el subformato. Es decir, todo se transforma a un componente compuesto porcomponentes que se abren y cierran por TAGs, que permite transmitir toda la información concerniente.XML = Texto + TAGs + Sintaxis según contenido y contexto a comunicarXML estructura la información en un árbol. Es decir, un paquete de datos o un documento cualquiera, elXML lo referencia en contenido, forma y localización como una componente, que a su vez esta formadode componentes, y así sucesivamente. Cada componente podría tener texto y/o más componentes.Ejemplo XML<?xml version="1.0"?><note><to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Dont forget me this weekend!</body></note>
  10. 10. Arquitectura Orientada a Servicios9WEB Services9El XML se completa mediante una “hoja de estilo”, que es una descripción de cómo debe verse unainformación en un determinado medio. A un mismo documento XML se le pueden aplicar distintas hojasde estilo según convenga. Por ejemplo usando una hoja de estilo por cada medio en la que se deberepresentar la información6.El XML sirve para que múltiples programas interpreten correcta y definidamente cualquier tipo de dato.Es decir, XML sirve para que algunos programas conversen entre ellos sin intervención humana, sinotambién implica facilitar la arquitectura de procesos distribuidos. Los Servicios Web son un casoparticular de esta arquitectura y XML es su lenguaje base
  11. 11. Arquitectura Orientada a Servicios10WEB Services10ESTÁNDAR SOAPEn el núcleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, queproporciona un mecanismo estándar de empaquetar mensajes. SOAP ha recibido gran atención debidoa que facilita una comunicación del estilo RPC entre un cliente y un servidor remoto. Pero existenmultitud de protocolos creados para facilitar la comunicación entre aplicaciones, incluyendo RPC deSum, DCE de Microsoft, RMI de Java y ORPC de CORBA.Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la industria.SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandescompañías de software del mundo. Compañías que en raras ocasiones cooperan entre sí estánofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que soportan SOAP sonMicrosoft, IBM, SUN, Microsystems, SAP y Ariba.SOAP proporciona un mecanismo estándar de empaquetar un mensaje. Un mensaje SOAP se componede un sobre que contiene el cuerpo del mensaje y cualquier información de cabecera que se utiliza paradescribir le mensaje. A continuación tiene un ejemplo:Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un únicoelemento envelope el sobre puede contener un elemento Header y puede contener un elemento body.Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el cuerpo siguiendoinmediatamente a la cabecera.El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que nopertenecen necesariamente al cuerpo del mensaje.
  12. 12. Arquitectura Orientada a Servicios11WEB Services11Además de definir un sobre de SOAP, la especificación de SOAP define una forma de codificar los datoscontenidos en un mensaje. La codificación de SOAP proporciona un mecanismo estándar para serializartipos de datos no definidos en la parte 1 de la especificación del esquema de XML.La especificación de SOAP también proporciona un patrón de mensaje estándar para facilitar elcomportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación de unmensaje de petición con un mensaje de respuesta.La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje de petición en formade una estructura.El elemento raíz tiene el mismo nombre que el método objetivo, con cada uno de los parámetroscodificado como un subelemento.El mensaje de respuesta puede contener los resultados de la llamada al método o una estructura defallo bien definida. Los resultados de la llamada a un método se serializan en el cuerpo de la peticióncomo una estructura. Por convenio, el elemento raíz tiene el mismo nombre que el método original alque se añade result. Los parámetros de retorno se serializan como elementos hijo, con el parámetro deretorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendrá unaestructura de fallo bien definida.Por convenio, el elemento raíz tiene el mismo nombre que el método original al que se añade result. Losparámetros de retorno se serializan como elementos hijo, con el parámetro de retorno en primer lugar.Si se encuentra un error el cuerpo del mensaje de respuesta contendrá una estructura de fallo biendefinida.
  13. 13. Arquitectura Orientada a Servicios12WEB Services12ESTÁNDAR WSDLWSDL (Web ServiceDescriptionLanguage) es el lenguaje estándar definido por el W3C para describirun Servicio Web y crear ese contrato. No es un documento obligatorio, pero es muy importante que seaestándar ya que así se podrá acceder de manera dinámica a los Servicios.La versión actual de WSDL es la 2.0, pero en este artículo se describirá la 1.1, ya que no todos losservidores soportan la última versión.
  14. 14. Arquitectura Orientada a Servicios13WEB Services13WSDL es un lenguaje basado en XML creado para definir el interfaz de los servicios. Un documentoWSDL está divido en dos partes claramente diferenciadas: Parte concreta: Es la parte que define el "como" y "donde". Parte abstracta: Es la parte que define qué hace el servicio a través de los mensajes que envía yrecibe.El esquema simplificado de un documento WSDL es el siguiente:A continuación se detalla brevemente cada una de las partes que componen un documento . En la parteabstracta tenemos: types: Esta etiqueta define las estructuras de datos que se utilizarán para construir los mensajes depetición como de respuesta. Estas estructuras de datos pueden construirse con cualquier lenguaje,pero lo más normal es hacerlo con XML Schema. Este apartado es el más complicado sobre todocuando tengamos que construir estructuras de datos muy complejas. message: Describe los mensajes que se van a intercambiar entre el cliente y el Servicio Web. Unmensaje puede estar dividido en varias partes, por ejemplo, si en un mensaje queremos enviardatos y una imagen. portType: Define el conjunto de operaciones que soporta el Servicio Web. Una operación no es másque un grupo de mensajes que serán intercambiados. Cada operación puede enviar o recibir almenos un mensaje cada vez.En WSDL 1.1 existen 4 tipos de operaciones: Unidireccional: El Servicio recibe un mensaje y no genera ninguna respuesta. Petición / Respuesta: El Servicio recibe un mensaje y responde con otro. Solicitud / Respuesta: El Servicio envía un mensaje y recibe una respuesta.Aunque WSDL 1.1 define los 4 tipos de operaciones, sólo soporta las 2 primeras.En la parte concreta tenemos: binding: Describe como formatear los mensajes para interactuar con un Servicio determinado.WSDL no define un estándar para formatear mensajes. Para ello utilizar la extensibilidad para definircomo intercambiar los mensajes usando SOAP, HTTP, MIME, etc. services: Este elemento indica donde se encuentra el Servicio usando la etiqueta . Cadaetiqueta define el formato de los mensajes, y la dirección donde se encuentra el servicio que aceptamensajes en ese formato.
  15. 15. Arquitectura Orientada a Servicios14WEB Services14ESTÁNDAR UDDICuando todas las aplicaciones son locales, es muy sencillo encontrar lo que desea. Sin embargo,cuando posee un sistema distribuido, tal como el de servicios web, no posee el beneficio que brinda unrepositorio centralizado. Los sistemas distribuidos también son propensos al cambio. Este es el mundoen el que se creó UDDI. Se creó con dos finalidades. En su encarnación inicial, fue concebida como unaclase de “Registro Universal de Empresas”. La idea era que las empresas podrían buscar sociosutilizando uno de los tres métodos que se describen a continuación: "Páginas blancas": Las páginas blancas eran como las páginas blancas de una guía telefónica, enlas que uno puede buscar información acerca de la empresa. Por ejemplo, si usted conocía elnombre de la empresa, podría encontrar su ubicación, cómo contactarla, y más aún, a quiéncontactar dentro de esa organización. "Páginas amarillas": Las páginas amarillas, otra vez, eran como las páginas amarillas de la guíatelefónica, en las que se pueden buscar empresas en función de una clasificación. UDDI especificóvarias taxonomías que las empresas podrían utilizar para clasificarse a sí mismas. Por ejemplo, sise buscaban artículos deportivos, podría buscar empresas con el código 339920 del Sistema deClasificación de Industrias de Norteamérica (NAICS). "Páginas verdes": No, no existen páginas verdes en su guía telefónica, pero la idea era que lasempresas pudieran utilizar este método de búsqueda para encontrar socios comerciales que habíanimplementado un servicio en particular. Por ejemplo, puede realizar una búsqueda de empresasmediante un tipo de búsqueda que calcula la distancia utilizando los códigos postales.
  16. 16. Arquitectura Orientada a Servicios15WEB Services15UDDI fue también concebida como un modo de mantener la ejecución de aplicaciones distribuidas alargo plazo. La idea era que se podría copiar en caché la información acerca de cómo accederá a unservicio en particular, y si su cliente iba a la quiebra, la aplicación iría automáticamente nuevamentehacia el registro y verificaría si se había cambiado la información. De haber cambiado, podríasimplemente realizar los cambios en su aplicación (automáticamente, en un mundo ideal) y reintentar susolicitud.La información contenida en un registro UDDI contiene cinco tipos diferentes: businessEntity, o la organización corporativa real. Esto puede significar una organización global opuede ser una filial o subdivisión. publisherAssertion, o la relación entre varias businessEntities. publisherAssertions deben serreclamadas por ambas partes para ser válidas (por lo cual no se puede reclamar que se trata deuna subdivisión de otra empresa) a menos que ambas entidades sean responsables ante el editor oexcepto que ambas partes ingresen al registro por la misma cuenta de usuario. bindingTemplate, el cual es esencialmente la especificación de una interfaz del servicio. Puede serimplementado por múltiples businessServices. businessService, o un servicio provisto por un negocio. Entonces, puede parecer simple, pero en elmundo de UDDI no significa necesariamente que se trata de un servicio web. Por ejemplo, se puedeespecificar el servicio de soporte telefónico de su empresa (lo cual significa el número telefónico realque marca el usuario y todo lo que ello conlleva) como un servicio UDDI. Por supuesto, no seobtendría un documento WSDL ficticio, pero constituiría un servicio que brinda su empresa. tModels, o modelos de metadatos. Al investigar la UDDI, Francis llega a la conclusión de que eltModel constituye quizás el motivo principal por el que no comenzó a tener éxito, tal como seesperaba. Como registro de servicios, usted esperaría encontrar una manera directa de especificarla interfaz de un servicio, tal como lo hace WSDL. Pero, tal como se especifica, no era la intenciónque UDDI se relacione exclusivamente con servicios web, y fue designado con mucha másflexibilidad. tModels un punto de ayuda para los documentos XML, tal como lo veremos más tarde,pero de hecho, tienen como finalidad especificar información acerca de algo vía un servicio, negocioo algo más.UDDI posee la reputación de ser extremadamente compleja, pero en esencia está conformada por loscinco tipos de datos detallados anteriormente, combinados con cuatro operaciones: Find (Encontrar),Get (Tomar), Save (Guardar), y Delete (Borrar). En otras palabras, las notas de especificación de UDDIestablecen que se puede realizar lo siguiente con los datos: find_xx: Estos métodos, tales como find_businessEntity, find_businessService, etc., brindan unamanera de poder buscar un registro en el registro de UDDI. Estos métodos devuelven la clave que
  17. 17. Arquitectura Orientada a Servicios16WEB Services16identifica al objeto. get_xx: Una vez que posee la clave única para identificar un objeto, puede utilizar get_xxmethods,tal como get_businessService etc., para recuperar el propio objeto real. Por ejemplo,get_businessService permite visualizar todo el objeto businessService, desde el cual puede obtenerla información que necesita. save_xx: Tal como seguramente ha podido ya adivinar, estos métodos agregan información a labase de datos o alteran información que ya se encuentra en la base de datos. delete_xx: Estos métodos, tales como delete_bindingTemplate, delete_tModel, etc., toman la claveúnica del objeto como parámetro y la sacan de la base de datos. El comportamiento real de estosmétodos depende de lo que está eliminando. Por ejemplo, dado que tModels son frecuentementereferentes de otros objetos de la base de datos, no pueden ser eliminados; en lugar de ellos se losoculta.
  18. 18. Arquitectura Orientada a Servicios17Seguridad con Web Services17SEGURIDAD CON WEB SERVICESLa seguridad es uno de los mayores desafiados en una entidad financiera o de otro rubro dondemanejen web services para comunicarse entre empresas.IBM dice, que si no hay seguridad en los Web Services los tres mayores riesgos son: Transacciones sin autorizaciónAlguien que posea un cliente no autorizado, puede enviar mensajes SOAP a el data center para obtenerdinero. Esta transacción no es autorizada.Para solventar este problema se pueden utilizar los mecanismos de WS-Security. Un ejemplo puede serque se incluya una combinación de id/password en el mensaje SOAP. Los mensajes están en texto legible, es decir sin encriptaciónEl número de cuenta o el balance que viajan en el paquete SOAP puede ser leído por un sniffer en lared. Este problema se puede solventar utilizando SSL ya que así se encriptan los mensajes. Los mensajes SOAP son susceptibles a la modificación, no existe integridadMientras el mensaje SOAP está viajando a su destino (un cliente del web Service), este puede serinterceptado en el camino y el atacante puede modificar el mensaje, por ejemplo cambiando el númerode cuenta a la cual se va a hacer el depósito.Diagrama de implementación de seguridad en Web Service:
  19. 19. Arquitectura Orientada a Servicios18Seguridad con Web Services18Servicios que se deben implementar en un Web Services para la seguridad: Identificación: La parte o cliente que acceso a un recurso, debe poder identificarse con el sistema. Autenticación: Debe existir un procedimiento para verificar la identidad de quienes accedan alsistema. Autorización: Deben existir un set de transacciones para que el cliente sea habilitado. Integridad: La información no puede cambiarse en el viaje de un Web Service a un cliente yviceversa. Confidencialidad: Nadie puede leer la información que viaje entre el cliente y el Web Service. Auditoria: Todas las transacciones deben ser guardadas, para que en caso de un problema estaspuedan ser analizadas. No-Repudiación: Ambas partes deben estar habilitadas para proveer un documento legal, a unatercera parte para que siempre sea la misma información la que se envié el servidor, como la querecibe el cliente y viceversa.
  20. 20. Arquitectura Orientada a Servicios19WS-Security (WSS)19WS-SECURITY (WSS)El WS-Security (WSS) es una extensión del protocolo SOAP que define mecanismos para proteger laintegridad y confidencialidad en los mensajes mediante el uso de SAML, Kerberos, tokens o loscertificados X.509, además de la encriptación y las signaturas XML.En primer lugar, tenemos que tener en cuenta que WS-Security no es un nuevo tipo de servicios web nide seguridad. WS-Security define cómo utilizar mecanismos existentes para proporcionar autenticación,confidencialidad e integridad a los Servicios Web. De este modo, en lugar de definir un estándar desdecero, resuelve el problema de la autenticación mediante el uso de Kerberos y certificados X.509, se cifracon el XML Encryption y se firma con la XML Signature tras preparar los datos mediante elXML Canonicalization.Una de las características del WS-Security es que es un framework que integra los anterioresestándares en el mensaje de tipo SOAP de modo que se puede aplicar tanto a trozos del documentocomo a su totalidad e independientemente de los protocolos de transporte. WS-Security define unacabecera de SOAP para almacenar la información de seguridad de tal modo que si se implementa unasignatura digital, esta cabecera incluirá la información necesaria asociada como, por ejemplo, elresultado de la misma.En la siguiente figura se muestra un ejemplo de flujo de mensajes utilizando el WS-Security.El Security TokenService es el servicio de validación empleado, es decir, Kerberos, certificados X.509 oun sistema consistente en user/password. El procedimiento consiste en un cliente que solicitalos tokens necesarios para dar seguridad a la transmisión y, a partir de aquí, los añadeconvenientemente al mensaje y los manda al servidor. Éste es capaz de validar la integridad,confidencialidad y no repudio del mensaje y, a continuación, puede responder al cliente.AUTENTICACIÓN
  21. 21. Arquitectura Orientada a Servicios20Transacciones con Web Services20UsernameToken: se utiliza un nombre de usuario junto con una contraseña para validar alcliente. En este caso, el cliente debe signar el mensaje y el servidor puede comprobar laveracidad calculando la firma del mensaje recibido y comparándola con el valor recibido.En el caso de utilizar certificados X.509, el mensaje puede ser firmado utilizando una claveprivada. Entonces, el mensaje debe contener el certificado en un BinarySecurityToken. Serecomienda firmar también el certificado con la clave privada.ENCRIPTACIÓNDado que WS-Security no define nuevos estándares sino que se basa en los ya existentes, para laencriptación se puede usar criptografía de clave pública o privada, simétrica o asimétrica. Normalmente,se realiza a través del ya antes mencionado XML Encription, que permite cifrar tanto partes de undocumento como su totalidad y que se caracteriza por cifrar contenido, por lo que se puede mantener laestructura de XMLFIRMAPara firmar los documentos se pueden utilizar los tres métodos de autenticación mencionadosanteriormente. Sin embargo, también se ofrece la posibilidad de aplicar la XML Signature, la cual definela sintaxis adecuada para las signaturas digitales que se pueden implementar. Además, también seincluye el modo de comprobar su veracidad, así como el modo de generarlas. Se distingue de otrasopciones (com el PGP) por soportar la firma de sólo unaparte del árbol XML (también se ofrece laposibilidad de que dos mensaje que difieran por ejemplo en un espacio, tengan la misma firma).TRANSACCIONES CON WEB SERVICESPodemos definir un servicio transaccional como aquel que guarda información usando una transacciónde base de datos. Si hablamos de servicios Web, habitualmente la transacción comienza cuando seinicia el servicio y finaliza tras completarse la operación al no soportar unirse a una transacción yaexistente en el sistema que los invoca.Ahora bien, como comentábamos antes, en una integración basada en servicios, su principal utilidad esproporcionar interoperabilidad para el intercambio de información entre diferentes sistemas. Por tanto,no es fundamental que las operaciones se realicen en una misma transacción. De hecho, en unaorquestación de servicios donde se realiza un flujo de llamadas a varios servicios, es habitual incluirmecanismos de compensación para poder realizar el roll back de las operaciones si, tras haberrealizado de forma satisfactoria la llamada a N servicios, la llamada al servicio N+1 no se realiza deforma correcta.
  22. 22. Arquitectura Orientada a Servicios21Transacciones con Web Services21En general siempre se puede enfocar el diseño de los servicios de forma que las diferentes operacionesque tengan que agruparse dentro de una misma transacción se puedan implementar en un mismoservicio, y en caso de no poder ser así, siempre se puede incorporar los mecanismo de compensaciónque permitan deshacer las operaciones en el orden adecuado.Pero, en el caso de necesitar implementar transacciones distribuidas entre varios servicios Web, ¿esposible?¿qué opciones hay disponibles? Si revisamos los estándares especificados en OASIS,organismo encargado de desarrollar estándares abiertos para el intercambio de información conservicios Web, encontramos: WS-AtomicTransaction v1.2 WS-BusinessActivity v1.2 WS-Coordination v1.2Se tratan de especificaciones de reciente aprobación (febrero 2009), en los que han participado lamayor parte de los líderes de la industria, Oracle, Microsoft, IBM, SAP, RedHat, etc, que hanincorporado, en algunos casos sólo de forma parcial, implementaciones en las versiones más recientesde sus principales productos.WS-COORDINATIONProporciona una infraestructura para dar soporte a formas concretas decoordinación (protocolos decoordinación)Método para introducir identificadores únicos en los mensajesintercambiados entre los servicios(Coordinationcontext, cabecera SOAP)Método para informar de la dirección de un servicio Web que participa en laconversación(Registration interface)Método para informar del rol que asumen en una conversación (Activationinterface)Estos objetivos son logrados de forma independiente del protocolo de coordinación ejecutado por losparticipantes.
  23. 23. Arquitectura Orientada a Servicios22Transacciones con Web Services22Entre los componentes que se encuentran en WS-Coordination podemos mencionar las abstraccionesutilizadas en la descripción de las interacciones entre un coordinador y sus participantes : CoordinationProtocol: Corresponde al conjunto de reglas a las cuales una conversación debeajustarse al momento de su desarrollo (descripción del protocolo de coordinación). CoordinationType: Corresponde a la especificación del tipo de protocolo utilizado, vale decir, unvalor de coordinationtype representa una conversación concreta. CoordinationContext: corresponde a la estructura de datos utilizada para detallar la conversación ala cual pertenecen los mensajes SOAP intercambiados.En cuanto a las formas de interacción que es posible encontrar entre un coordinador y sus participantespodemos mencionar: Activación: esta interacción ocurre cuando un participante solicita a un coordinador la creación deun nuevo contexto de coordinación, vale decir, la creación de una nueva conversación. Registro: Esta interacción ocurre cuando un participante se registra en un coordinador paraparticipar en una conversación. Interacciones específicas del protocolo: Estas interacciones ocurren cuando el coordinador y losparticipantes registrados intercambian mensajes específicos del protocolo de coordinación deconversación.En resumen WS-Coordination aporta la capacidad de registrar a los sistemas que tomaran parte en unproceso de negocio y generar un contexto con información (tanto del registro como de la coordinación)para entregarla a los otros sistemas participantes en el proceso de negocio.
  24. 24. Arquitectura Orientada a Servicios23Transacciones con Web Services23WS-TRANSACTIONWS-Transaction se apoya en la infraestructura de WS-Coordination, la cual modela el contexto de latransacción. Esta especificación tiene su origen como ya lo habíamos mencionado en el contexto de lasbases de datos y es utilizado en entornos distribuidos cuando dos o más Web Services estáninvolucrados en una interacción (conversación) y las operaciones invocadas no son independientes. Elobjetivo final es que todas las operaciones sean ejecutadas con éxito, o en caso contrario ninguna deellas sea ejecutada. Las transacciones en Web Services poseen algunas diferencias notables con lasgeneradas en bases de datos, entre las cuales podemos mencionar que el tiempo que cuesta encompletar un transacción en Web Services es muchísimo más largo de lo que toma en una base dedatos debido a que en los Web Services es posibles ejecutar complejos procesos de negocios; otradiferencia es que se amplia la variedad de recursos y operaciones a aplicar sobre ellos.La especificación de WS-Transaction fue publicada el año 2002 por IBM, Microsoft y BEA. La cualespecifica un protocolo estándar para la ejecución de transacciones en entornos de Web Services. Laespecificación establece dos tipos de transacciones: AtomicTransactions: Corresponde a transacciones atómicas o de corta duración, en las cuales seconserva la idea de las propiedades ACID (Atomicidad, Coherencia, Aislamiento y Durabilidad) enun sentido muy estricto, lo que resulta en que todas las operaciones dentro de una transacción seejecutan con éxito o no se ejecuta ninguna. Este tipo de transacciones por lo general resultan enentornos muy confiables. Business Activities: Corresponde a transacciones de larga duración en la cual las propiedades ACIDson flexibilizadas. Las operaciones son todas invocadas a los participantes, los cuales después desu ejecución informan al coordinador si estas operaciones han sido completadas con éxito. Sialguna de estas operaciones falla, se requiere la ejecución de operaciones de “compensación” yaque acá los cambios son permanentes desde el principio, por tanto si la operación falla se deberárealizar operaciones que permitan deshacer los cambios.De los dos tipos de mecanismos de transacción, el más utilizado para implementar procesos denegocios complejos es por transacción BusinesActivities.
  25. 25. Arquitectura Orientada a Servicios24Bibliografía24BIBLIOGRAFÍA http://www.ibm.com/developerworks/ssa/webservices/newto/index.html http://www.revista-ays.com/DocsNum08/SOA/roncero.pdf http://www.desarrolloweb.com/articulos/1557.php http://www.ibm.com/developerworks/ssa/webservices/tutorials/ws-soa1/section5.html Whitepaper: La arquitectura SOA de Microsoft® aplicada al mundo real http://iaaa.cps.unizar.es/docencia/SW/8.Coordinacion@.pdf http://www.fing.edu.uy/inco/grupos/lins/documentos/soa/ws/LINS_Introduccion_a_WS.pdf

×