Uf1846 issuu by Unión Editorial para la Formación

IFCd0210

Informática y Comunicaciones

desArrOLLO de APLICACIONES COn teCnOLOgÍAs WEB

Módulo Formativo 0492_3

Programación web en el entorno servidor

Unidad Formativa 1846 desarrollo de aplicaciones web distribuidas

Certiﬁcado de Profesionalidad

Impreso en España. Printed in Spain 1ª edición Autor: José Manuel Carballeira Rodrigo «Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra solo puede ser realizada con la autorización de sus titulares, salvo excepción prevista por la ley. Diríjase a CEDRO (Centro Español de Derechos Reprográficos) si necesita fotocopiar o escanear algún fragmento de esta obra (www.conlicencia.com; 91 702 19 70 / 93 272 04 47)». Reservados todos los derechos. Está prohibido, bajo las sanciones penales y el resarcimiento civil previstos en las leyes, reproducir, registrar o transmitir esta publicación, íntegra o parcialmente por cualquier sistema de recuperación y por cualquier medio sea mecánico, electrónico, magnético, electroóptico, por fotocopia o por cualquier otro medio presente o futuro, sin la autorización previa de Unión Editorial para la Formación (UEF).

IFCd0210

desArrOLLO de APLICACIOnes COn teCnOLOgÍAs Web

Módulo Formativo 0492_3 Programación web en el entorno servidor

Unidad Formativa 1846

desarrollo de aplicaciones web distribuidas

DESARROLLO DE APLICACIONES WEB DISTRIBUIDAS REFERENCIA AL CERTIFICADO DE PROFESIONALIDAD............................................................................................ 6 INTRODUCCIÓN...................................................................................................................................................................... 7 OBJETIVOS................................................................................................................................................................................... 8 MAPA CONCEPTUAL............................................................................................................................................................... 9

unidad didáctica 1. ARQUITECTURAS DISTRIBUIDAS ORIENTADAS A SERVICIOS...............................12 1.1 Características generales de las arquitecturas de ..............................................................12 servicios distribuidos..............................................................................................................................................12 1.2 Modelo conceptual de las arquitecturas orientadas a servicios..............................14 1.2.1 Basados en mensajes...........................................................................................................................................15 1.2.2 Basados en recursos...........................................................................................................................................15 1.2.3 Políticas y contratos de servicios.....................................................................................................................16 1.3 Aspectos de seguridad en arquitecturas orientadas a.........................................................16 servicios...........................................................................................................................................................................16 1.3.1 Seguridad de datos..............................................................................................................................................16 1.3.2 Seguridad de mensajes........................................................................................................................................16 1.3.3 Control de acceso. El modelo RBAC..............................................................................................................17 1.3.4 Seguridad en comunicaciones. Protocolos seguros.....................................................................................18 1.4 Implementación de arquitecturas orientadas a servicios mediante tecnologías web........................................................................................................................................................................................19 1.4.1 Especificaciones de servicios web de uso común: SOAP, REST, etc..........................................................19 SOAP................................................................................................................................................................................19 1.4.2 Lenguajes de definición de servicios: el estándar WSDL............................................................................26 1.4.3 Estándares de seguridad en servicios web: WS-Security, SAML, XACML, etc........................................30

1.5 IMPLEMENTACIÓN DE LA SEgURIDAD EN ARQUITECTURAS ORIENTADAS A SERVICIOS ..........36 1.5.1 Conceptos básicos de criptografía .................................................................................................................37 1.5.2 Tipos de criptografía ..........................................................................................................................................38 1.5.3 Entidades certificadoras ....................................................................................................................................40 1.5.4 Certificados digitales. Características ............................................................................................................41 1.5.5 Identificación y firma digital mediante certificados digitales .....................................................................48 1.5.6 Cifrado de datos .................................................................................................................................................51 1.6.1 Concepto de directorio ....................................................................................................................................53 1.6.2 Ventajas e inconvenientes ..................................................................................................................................55 1.6.3 Directorios distribuidos ....................................................................................................................................56 1.6.4 Estándares sobre directorios de servicios: UDDI .......................................................................................57 UNIDAD DIDáCTICA 2. PROgRAMACIÓN DE SERVICIOS wEB EN ENTORNOS DISTRIBUIDOS ...........78 2.1 COMPONENTES SOFTwARE PARA EL ACCESO A SERVICIOS DISTRIBUIDOS ...................................80 2.1.1 Definición de servicios ......................................................................................................................................82 2.1.2 generación automática de servicios ..............................................................................................................83 2.2 PROgRAMACIÓN DE DIFERENTES TIPOS DE ACCESO A SERVICIOS .....................................................85 2.2.1 Servicios basados en publicación/suscripción...............................................................................................88 2.2.2 Servicios basados en repositorios ..................................................................................................................92 2.2.3 Servicios accesibles desde agentes de usuario.............................................................................................94 2.2.4 Proveedores y consumidores de servicios en entorno servidor ............................................................98 2.3 HERRAMIENTAS PARA LA PROgRAMACIÓN DE SERVICIOS wEB ....................................................... 101 2.3.1 Comparativa ..................................................................................................................................................... 101 2.3.2 Bibliotecas y entornos integrados (frameworks) de uso común .......................................................... 123

RESUMEN ................................................................................................................................................................................ 126 BIBLIOgRAFíA........................................................................................................................................................................ 130 gLOSARIO .............................................................................................................................................................................. 131

Referencia al certificado de Profesionalidad CERTIFICADO DE PROFESIONALIDAD:

(IFCD0210) DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB (RD 1531/2011, de 31 de octubre)

MÓDULO FORMATIVO: MF0492_3: Programación web en el entorno servidor UNIDAD FORMATIVA: UF1846: Desarrollo de aplicaciones web distribuidas

Introducción Introducción Hoy en día la práctica totalidad de los sistemas informáticos de las empresas pueden ser considerados como sistemas distribuidos, en cuanto a que no se localiza todo en un único emplazamiento o máquina. El criterio para toda esta unidad es que, al hablar de sistemas distribuidos lo hacemos de un conjunto de ordenadores, servidores, etc., que son independientes, que comparten un estado, que dan sensación de unidad, y cuyo procesamiento de la información se distribuye entre varios elementos de la red. Para diseñar la distribución de estos sistemas se deben tener en cuenta ciertos criterios, tales como la compartición de recursos, la concurrencia, la escalabilidad, etc... Todas estas ventajas hacen que los sistemas distribuidos hayan remplazado a los sistemas heredados centralizados, desarrollados en la década de los ochenta y novena. Los sistemas distribuidos comenzaron a implementarse acompasando al crecimiento de las redes locales a principios de los años 70. En los años 80, con la llegada al mercado de forma masiva de ordenadores personales, estaciones de trabajo y servidores se propició un desarrollo de los sistemas distribuidos y una reducción de la cantidad de las grandes ordenadores. El incremento de la demanda de estos servicios impulsó un gran desarrollo de las aplicaciones distribuidas, que permiten a los ordenadores coordinar sus tareas y compartir los recursos del sistema (el hardware, el software y los datos). Las aplicaciones distribuidas se desarrollan, normalmente, en plataformas de hardware y

software con diferentes marcas y características, formando una red que puede abarcar desde unos pocos ordenadores personales conectados por una LAN, hasta una gran estructura integrada por un conjunto de redes LAN y WAN interconectadas, que conectan miles de servidores. En general, el objetivo del uso de estos sistemas es, principalmente, conseguir un ahorro. Usando sistemas distribuidos bien diseñados conseguiremos ahorro en: - Economía: estos sistemas tienen una proporción funcionalidad/ precio muy superior a la de un sistema centralizado. - Rapidez: los sistemas distribuidos presentan mayor velocidad de cálculo que uno centralizado. Así mismo, una empresa puede elegir utilizar estos sistemas por otras de sus ventajas frente a los sistemas centralizados, como son una mayor confiabilidad, modularidad (lo que hace que sea mucho más sencillo su sustitución y crecimiento), tareas y recursos compartidos, etc. Posteriormente, con el uso masivo de Internet se ha propiciado que los sistemas distribuidos puedan aprovechar las características ventajosas de la web, diseñando otro tipo de arquitectura distribuida en las que el cliente es el navegador y la aplicación está en el servidor web. En esta unidad estudiaremos todos los elementos (protocolos, interoperabilidad, modelos de arquitecturas, etc.) que nos permitirán entender, elegir y definir el sistema distribuido más adecuado según las necesidades de cada proyecto.

Objetivos Objetivos Objetivo General • Seleccionar y emplear servicios distribuidos para su integración en la aplicación web. Objetivos Específicos • Identificar las posibilidades que ofrecen los servicios distribuidos web para su integración en la aplicación a desarrollar. • Especificar las características de los protocolos estándares del mercado para poder utilizar servicios web en la aplicación a desarrollar. • Seleccionar y emplear los servicios web más adecuados para ser utilizados en la aplicación web en función del diseño especificado.

Mapa Conceptual Mapa Conceptual Basado en Recursos Servicios generales en arquitecturas distribuidas

Componentes Software

Basado en Mensajes

Servidor

Cliente

Formato de mensajes seguridad

Control de Acceso RBAC

Protoolo de aplicaci贸n

Seguridad en Servicios

SAML

WS-SECURITY

XACML

Protocolos Seguros

SSL

SSH

TSL

01 Arquitecturas distribuidas orientadas a servicios 1.1.Características generales de las arquitecturas de servicios distribuidos 1.2 Modelo conceptual de las arquitecturas orientadas a servicios 1.2.1 Basados en mensajes 1.2.2 Basados en recursos 1.2.3 Políticas y contratos de servicios 1.3 Aspectos de seguridad en arquitecturas orientadas a servicios 1.3.1 Seguridad de datos 1.3.2 Seguridad de mensajes 1.3.3 Control de acceso. El modelo RBAC 1.3.4 Seguridad en comunicaciones. Protocolos seguros 1.4 Implementación de arquitecturas orientadas a servicios mediante tecnologías web 1.4.1 Especificaciones de servicios web de uso común: SOAP, REST, etc. 1.4.2 Lenguajes de definición de servicios: el estándar WSDL 1.4.3 Estándares de seguridad en servicios web: WS-Security, SAML, XACML, etc.

1.5 Implementación de la seguridad en arquitecturas orientadas a servicios 1.5.1 Conceptos básicos de criptografía 1.5.2 Tipos de criptografía 1.5.3 Entidades certificadoras 1.5.4 Certificados digitales. Características 1.5.5 Identificación y firma digital mediante certificados digitales 1.5.6 Cifrado de datos 1.6 Directorios de servicios 1.6.1 Concepto de directorio 1.6.2 Ventajas e inconvenientes 1.6.3 Directorios distribuidos 1.6.4 Estándares sobre directorios de servicios: UDDI

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

1. ARQUITECTURAS DISTRIBUIDAS ORIENTADAS A SERVICIOS 1.1 Características generales de las arquitecturas de servicios distribuidos Un sistema distribuido es un aquel en el que se distribuye entre varios ordenadores el procesamiento de información, en lugar de estar centralizado en una sola máquina. Aunque estos sistemas tienen mucho en común con los sistemas tradicionales, hay algunas características propias que deben tenerse en cuenta a la hora de implementarlos. Las principales ventajas del uso de sistemas distribuidos son: ––Se comparten los recursos, tanto hardware (las propias máquinas, impresoras, etc.) como software (ficheros, programas). ––Existe concurrencia, ya que varios procesos pueden operar al mismo tiempo sobre diferentes equipos de la red. ––Son sistemas escalables, ya que se puede ampliar la capacidad del sistema de forma gradual. El único límite puede ponerlo la red que une el sistema, ya que puede llegar un momento en que dicha red no soporte la ampliación. ––Tienen tolerancia a fallos, de forma que si un componente del sistema falla (fallo software o hardware), otro componente, puede ser sustituido por otro componente. En estos casos, se suele proporcionar un servicio degradado. ––Son sistemas abiertos, ya que se diseñan sobre protocolos normalizados y así se puede usar hardware y software de diferentes fabricantes. ––Por contra, las desventajas de los sistemas distribuidos son: ––Son sistemas más complejos, por lo que son difíciles de probar y de comprender.Suelen ser más inseguros, ya que se puede acceder al sistema desde varios equipos y puede haber más problemas de escuchas indeseadas, ataques de denegación de servicio, etc. ––Suelen ser más difíciles de manejar y de gestionar al poder ser equipos con diferente hardware y software. ––La respuesta de estos sistemas no se puede predecir, ya que depende de la carga total en el sistema, de su organización y de la carga de red. Como todos ellos pueden cambiar con mucha rapidez, el tiempo requerido para responder a una petición de usuario puede variar drásticamente de una petición a otra. ––En los sistemas distribuidos existen dos tipos de arquitecturas que se aplican cuando la distribución de aplicaciones es dentro de una sola organización: ––Arquitectura cliente-servidor: El sistema se considera como un proveedor de servicios que son usados por los clientes.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––Arquitecturas de objetos distribuidos: El sistema se puede considerar como un conjunto de objetos que actúan entre sí, siendo su ubicación irrelevante. ––Si la distribución de aplicaciones se da entre varias organizaciones, las arquitecturas distribuidas más usadas son: ––Arquitectura de sistemas P2P (peer to peer o punto a punto) ––Arquitecturas orientadas a servicios. El software de un sistema distribuido debe ser capaz de trabajar con diferentes equipos, distintos lenguajes de programación, diferentes protocolos. Y ese software debe permitir la comunicación entre todas estas partes diferentes. Al software que trabaja en un sistema distribuido se le denomina middleware. Algunos ejemplos de middleware son: ––Gestores de comunicación con bases de datos, por ejemplo ODBC. ––Productos de programación a distancia, por ejemplo ONC y RMI (Java Remote Method Invocation)

Autor : JavierRiGa http://www.flickr.com/photos/74291475@N05/6833896015/ Los esquemas de la arquitectura se pueden dividir en dos zonas: El servicio y el ámbito funcional de la arquitectura. Respecto al servicio, ha de estar bien definido y tener un interfaz procesable cuya implementación sea reemplazable. Para medir la calidad del servicio se puede hacer por diferentes parámetros:

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––Interoperabilidad: Mide la facilidad de los componentes y sistemas para utilizar e intercambiar la información. ––Fiabilidad: Probabilidad de que el sistema funciones realizando sus funciones de forma correcta. ––Disponibilidad: Mide la operatividad del sistema. ––Usabilidad: Facilidad del sistema para poder ser ejecutado. ––Seguridad: Habilidad del sistema para resistir usos no autorizados mientras sigue proveyendo sus servicios a los usuarios legítimos. ––Rendimiento: El grado en el cual el sistema lleva a cabo su funcionalidad especifica y el uso eficiente de los recursos ––Escalabilidad: Mide el poder de reacción y adaptación sin que ello suponga pérdida de calidad. ––Extensibilidad: Mide el poder de expansión. 1.2 Modelo conceptual de las arquitecturas orientadas a servicios La arquitectura orientada a servicios o SOA (Service-Oriented Architecture) es una evolución de los principios fundamentales del desarrollo basado en componentes o CBD (component-based development) y que define la utilización de servicios para dar soporte a los diferentes requisitos del negocio. Estructura de arquitectura orientada a servicios, SOA.

Estructura de arquitectura orientada a servicios, SOA.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Mientras que los servicios de SOA son visibles para el usuario del servicio, sus componentes estructurales no son perceptibles por el mismo. Para el proveedor de servicios, el diseño de componentes, su exposición de servicio y la administración reflejan las decisiones de diseño que permiten servicios en SOA. Tomar estas decisiones requiere una comprensión de los componentes de una SOA para identificar, clasificar, precisar y estructurar los componentes de servicios habilitados. ––El modelo conceptual de las arquitecturas orientadas a servicios puede dividirse en tres elementos que hay que identificar y que interactúan entre ellos: ––Proveedor de servicio: Provee la descripción del servicio y la implementación de éste. ––Consumidor de servicio: Invoca el servicio utilizando y puede encontrar la descripción del servicio a través de un registro de servicio. ––Service Broker: Es que el que proporciona y mantiene el servicio 1.2.1 Basados en mensajes La estructura de red (hardware y software) se comunica a través de unos protocolos preestablecidos. El propio mensaje se puede definir como una estructura de datos, registros u objetos. El emisor envía una cadena de comandos especificando un método o función el cual invoca al receptor. Se permite que el consumidor de un servicio pueda hacer un registro de terceros para el servicio que se ajuste a sus criterios. Si el registro tiene este tipo de servicio, se le da al consumidor un contrato y una dirección para utilizar el servicio.

Esquema de SOA orientado a servicios 1.2.2 Basados en recursos En este modelo, al hablar de recurso, se habla de los elementos de información. Se puede acceder a los recursos usando un identificador global. Clientes y servidores se comunican, para poder manejarlos, a través de una interfaz estándar e

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

intercambian las representaciones de estos recursos: los ficheros que se descargan y se envían. Esa petición puede transmitirse por diferentes conectores pero cada uno lo hace de una forma independiente de su propia petición. De esta forma cualquier aplicación puede interactuar con cualquier recurso conociendo el identificador y la acción y entendiendo el formato de la representación, como por ejemplo un documento HTML, XML, una imagen, etc. 1.2.3 Políticas y contratos de servicios Un contrato de servicios es la interfaz web con la que trabajan las aplicaciones o dicho de otra forma, es un contrato de datos que agrupa todos los parámetros de entrada a un servicio. Esto debe ser diseñado de la forma más simple que se pueda, lo cual implica no usar parámetros de entrada ni valores de retorno ni referencias circulares entre otras pautas a evitar. 1.3 Aspectos de seguridad en arquitecturas orientadas a servicios 1.3.1 Seguridad de datos Es una parte importante y esencial en los sistemas distribuidos. Las aplicaciones de la infraestructura han de contar con una persona responsable con los suficientes conocimientos de la arquitectura creada. Se ha de garantizar también que todas las nuevas implementaciones que se realicen satisfagan las necesidades de seguridad que previamente se hayan definido. 1.3.2 Seguridad de mensajes Se debe tener un método de seguridad donde las llamadas GET no puedan ser cacheadas ni indexadas. Generalmente se usa este tipo de llamadas ya que la idea de crear un link es crear una solicitud al servidor para que este te devuelva una respuesta en forma de URL. Para tener un nivel de seguridad mínimo, las URLS han de estar encriptadas. Eso quiere decir que por cada sesión se cree una única URL, por lo que se consigue que haya una propia para cada usuario.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

1.3.3 Control de acceso. El modelo RBAC El modelo RBAC (role-based access control) o control de acceso basado en roles es una función de seguridad con la cual se pueden controlar todos los accesos a tareas a las que solo tienen acceso ciertos usuarios. Esto se consigue mediante la aplicación de atributos de seguridad. RBAC permite dividir los roles de un superusuario entre varios administradores asignando unos privilegios especiales. Aunque se pueden crear varios roles, lo más recomendable es definir cuatro basados en los perfiles con derechos del mismo nombre: ––Administrador principal: Es el perfil con todos los derechos, equivalente a un superusuario. ––Root: Es un perfil semejante a un administrador pero sin el derecho de inicio de sesión. Un usuario normal debe iniciar sesión y luego obtener el rol que hemos asignado con root. ––Administrador del sistema: Puede realizar instalaciones de software, gestionar correo, manipular sistemas de archivos entre otros permisos. Por contra no puede definir contraseñas. ––Operador: Es una especie de administrador con bastantes menos privilegios, siendo “administrador” en ciertas operaciones como la realización de copias de seguridad.

Esquema de modelo RBAC Los roles se representan según de las necesidades de seguridad. Éstos pueden ser configurados para unos fines especiales en aéreas como la administración de cortafuegos, redes o la propia seguridad. Otra estrategia es crear un solo rol

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

de superusuario junto con otro de usuario avanzado con permiso para corregir partes de los propios sistemas. 1.3.4 Seguridad en comunicaciones. Protocolos seguros Existen tres tipos de protocolos seguros: SSH, SSL y TSL. ––SSH (Secure Shell) o en español, intérprete de órdenes seguras. Se utiliza para acceder a las máquinas de forma remota mediante línea de comandos. Además, nos permite copiar y traspasar datos de forma segura a través de un canal securizado mediante este protocolo. SSH se puede decir que es un telnet seguro. ––TSL: Es una evolución del protocolo SSL. Con este protocolo se establece una conexión segura por medio de un canal cifrado entre el cliente y el servidor. Al igual que el protocolo SSL, se autentica sólo el servidor por lo que el cliente se mantiene sin autenticar y tiene tres fases básicas: ––Se negocian entre las partes el algoritmo a usar en la comunicación. ––El intercambio de claves públicas se basa en certificados digitales. ––El tráfico se basa en el cifrado simétrico. ––SSL o capa de conexión segura. Proporciona una autenticación y privacidad de la información entre las partes y sobre internet, encriptando la información. Si se usa este protocolo, se autentica sólo el servidor por lo que el cliente se mantiene sin autenticar. Este protocolo tiene tres fases básicas: ––Se negocia entre las partes el algoritmo a usar para la comunicación ––El intercambio de claves públicas se basa en certificados digitales ––El tráfico se basa en el cifrado simétrico. En la primera fase, el cliente y el servidor negocian los algoritmos criptográficos que se van a usar. Estas implementaciones proporcionan varias opciones: ––RSA o DSA para la criptografía de clave publica. ––RC2, RC4 o IDEA para el cifrado simétrico ––MD5 o la familia SHA para las funciones Hash.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

1.4 Implementación de arquitecturas orientadas a servicios mediante tecnologías web 1.4.1 Especificaciones de servicios web de uso común: SOAP, REST, etc. SOAP SOAP (Simple Object Access Protocol) es de las tecnologías de servicios Web más importantes, ya que sirve para el transporte de los datos de un lugar a otro a través de la red. SOAP como servicio de transporte de datos usa una combinación de XML y de la WEB. SOAP proporciona transporte de datos de los servicios Web En relación con la Web, SOAP es una especie de extensión del protocolo de transferencia de hipertexto (HTTP) que soporta la mensajería XML. En lugar de utilizar HTTP para solicitar una página HTML para ser descargada y ser mostrada en un navegador, SOAP envía un mensaje XML a través de peticiones HTTP y recibe una respuesta, si la hay, vía respuesta HTTP. Para manejar el mensaje XML correctamente, el servicio HTTP de escucha, por ejemplo Apache o Microsoft Internet Information Server (IIS), debe proporcionar un procesador SOAP. Dicho de otra forma, una escucha HTTP que recibe un mensaje SOAP debe incluir un XML con capacidad de procesamiento. Más específicamente, un servicio HTTP de escucha que reciba un mensaje SOAP debe ser capaz de validar y entender el formato de documento XML determinado definido en la especificación SOAP. La especificación SOAP permite al protocolo de mensajería SOAP ser mapeado a otros medios de transporte, aunque la asignación a HTTP es el único mapeo se define en la especificación. Las interacciones de SOAP se modelan como ocurre entre nodos SOAP, los cuales pueden ser remitentes de mensaje SOAP o bien receptores o ambos. Un caso especial de un nodo SOAP puede desempeñar el papel de intermediario entre el emisor y el receptor con el propósito de controlar los encabezados especiales. Un nodo SOAP acepta uno o más procesadores de SOAP y es responsable del manejo de los bloques SOAP cuando un mensaje es recibido. La siguiente figura ilustra los tres grandes bloques, o partes de los mensajes SOAP: ––Envelope: Es obligatorio y marca el principio y final del mensaje SOAP. ––Header: Es opcional, y puede contener uno o más bloques de encabezado que llevan los atributos del mensaje o la definición de las cualidades de servicio para el mensaje. Los headers se destinan a transportar contextos o cualquier información definida por la aplicación asociada al mensaje, como los tokens de seguridad o los identificadores de transacción.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––Body: Es obligatorio y contiene uno o más bloques que contienen el mensaje en sí mismo.

Estructura SOAP SOAP transporta un documento XML a través de la Web y, potencialmente, a través de otros tipos de redes, para llegar a una implementación de servicio Web. Un mensaje SOAP es, de hecho, un documento XML creado en un formato específico. Una implementación SOAP conforme entiende cómo interpretar dicho documento y cómo asignar los datos a una aplicación de software subyacente del servicio. SOAP no define el servicio en sí mismo, sólo lo suficiente sobre el mensaje para que un procesador SOAP lo pueda reconocer. SOAP define lo que significa reconocer un mensaje como un mensaje SOAP, pero la implementación del servicio Web tiene que saber interpretar los datos contenidos en el mensaje como un objetivo para la implementación del software subyacente del servicio.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

El siguiente ejemplo muestra un uso simple de SOAP, un mensaje de difusión unidireccional a una lista de los mecanismos de comunicación. El bloque Header contiene la lista de dispositivos a los que el mensaje va a ser enviado. El bloque Body contiene el mensaje de notificación que deberá entregar realmente, en este ejemplo un recordatorio de una reunión. En este ejemplo, el mensaje de recordatorio de la reunión es transmitido a la lista de dispositivos por el servicio de envío ubicada en la dirección definida por la URL url1. Espacios de nombres independientes (broadcastService y Function) se utilizan para calificar el elemento y los atributos para cada parte del mensaje. En este ejemplo no se especifica la codificación, por lo que ningún espacio de nombres de codificación aparece en el mismo, lo que significa que se utilizan tipos XML defecto (es decir, texto). Header y Body usan los espacios de nombres definidos por la aplicación para calificar los respectivos elementos y atributos.

EJEMPLO de mensaje SOAP sencillo <env:Envelope xmlns:env=”http://www.w3.org/2001/12/ soap-envelope”> <env:Header> <n:broadcastService xmlns:n=”http://url1”> <n:lista>Email, Móvil, PDA</n:lista> </n:broadcastService> </env:Header> <env:Body> <m:Function xmlns:m=”url2”> <m:message> Recordatorio: la reunión comienza a las 11:30 </m:message> </m:Function> </env:Body>

Este mensaje puede ser vinculado a HTTP usando POST de la siguiente forma indicada en este ejemplo:

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Header de petición: POST /broadcastService HTTP/1.1 Host: Host url1 Content-Type: text/xml; charset=”utf-8” Content-Length: nnnn <? xml version=’1.0’ ?> ...Documento de petición SOAP Header de respuesta, si la hay: HTTP/1.1 200 OK Content-Type: text/xml; charset=”utf-8” Content-Length: nnnn <? xml version=’1.0’ ?> ...Documento de respuesta SOAP Como se muestra en el ejemplo, se usa SOAP con HTTP es para enviar un documento de petición utilizando HTTP POST. La cabecera HTTP que indica el documento se envía al servicio broadcastService en la url url1. Cuando el programa de software de la aplicación broadcastService recibe el mensaje, descifra el bloque del Body y ejecuta la petición send. Si se define una respuesta para este mensaje (tal como una confirmación de que el mensaje ha sido enviado), la respuesta se encuentra dentro del respuesta HTTP: HTTP/1.1 200 OK. El código 200 es un código HTTP que indica que ha ido bien, sin fallos. Si se produjese algún tipo de fallo en el procesamiento la solicitud, el código HTTP daría un código de error en la respuesta, por ejemplo HTTP/1.1 500 Error interno del servidor. En caso de que exista un fallo para procesar una solicitud SOAP, el cuerpo de la respuesta incluye un mensaje de error SOAP detallando el problema Los tres estilos de uso de los servicios Web son: RPC (Remote Procedure Calls) o Llamadas a Procedimientos Remotos: Los Servicios Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones distribuidas. Se la suele llamar la primera generación de servicios Web pues las primeras herramientas estaban basadas en este estilo.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

SOA (Service-oriented Architecture) o Arquitectura Orientada a Servicios. En este modelo la unidad básica es el mensaje. Eso se suele nombrar como servicios orientados a mensajes. Al contrario que los Servicios Web basados en RPC, este estilo es débilmente acoplado. REST (Representation State Transfer). Los Servicios Web basados en REST intentan rivalizar con el protocolo HTTP u otros protocolos similares con la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (GET, PUT, etc.). Se centra interactuar con recursos con estad. Los objetivos del estilo de arquitectura REST son: ––Escalabilidad en la interacción con los componentes, ya que la Web crece rápidamente sin degradación de rendimiento y cada vez más tipo de clientes pueden acceder a través de la Web: ordenadores, móviles, etc. ––Generalidad de interfaces. Sin necesidad de configuración específica, cualquier cliente puede trabajar con cualquier servidor web, gracias al protocolo http. Esto no ocurre en otras alternativas, como SOAP. ––Independencia en funcionamiento. Los clientes y servidores deben poder trabajar de forma independiente, de forma que in servidor nuevo debe poder funcionar con clientes antiguos y viceversa. El protocolo http permite la extensibilidad usando cabeceras a través de las URIs, a través de la habilidad para crear nuevos tipos de contenidos y procedimientos. ––Compatibilidad con componentes intermedios, como pueden ser: -- cachés, usadas para mejorar el rendimiento y reducir la latencia de la interacción. -- firewalls, para la gestión y refuerzo de la seguridad -- puertas de enlace, que encapsulan sistemas que no sean de la Web Para cumplir con estos objetivos, REST aplica las siguientes restricciones: ––Mediante URIs los recursos son identificados de forma única y son manipulados mediante representaciones. Los recursos son objetos lógicos a los que son enviados los mensajes y no se pueden acceder o modificar de forma directa, por eso se indica que se trabaja con representaciones de ellos. Por ejemplo, al usar un método PUT para enviar información, se trabaja con una representación del estado del recurso, si bien luego puede ser cualquier entidad: base de datos, fichero de texto, etc. ––Los mensajes HTTP son descriptivos por sí mismos, de forma que los intermediarios interpretan los mensajes y ejecutan servicios en nombre del usuario. Estos lo logra HTTP de varias formas:

RECUERDe De los tres principales estilo de arquitecturas e Servicios web, REST se centra en la interacción con los recursos, SOA en los mensajes y RPC en operaciones. REST (Representational State Transfer) es un estilo arquitectura de software para sistemas hipermedias distribuidos tales como la Web. El término fue introducido en la tesis doctoral de Roy Fielding en 2000, uno de los principales autores de la especificación de HTTP.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

-- Usando varios métodos estándares -- Utilizando muchos encabezamientos -- A través de un mecanismo de direccionamiento. Por ejemplo, las cachés Web conocen que el método POST no se puede cachear , al contrario que el método GET. También saben verificar la caducidad de la información a través de las cabeceras. Al ser HTTP un protocolo sin estado, se puede interpretar cada mensaje sin conocer los mensajes previos. ––Se usa hipermedia para conocer el estado de la aplicación. El estado actual de una aplicación Web se debe capturar en documentos de hipertexto, que residen en el cliente y también en el servidor. residiendo tanto en el cliente como en el servidor. Los requisitos de una arquitectura REST son los siguientes: ––No se publican los servicios RPC, sino que se publican recursos que es una entidad de acceso público que representa un concepto de negocio.Así, en REST, por ejemplo, no se puede publicar una interfaz EmpleadosEmpresa con métodos “CrearEmpleado” o “ActualizarSueldoEmpleado”, sino que se publicarían recursos como “EmpleadosDeLaEmpresa” o “Empleado NIF xxx” ––Cada uno de los recursos tiene un identificador propio diferenciador de cualquier otro y que, por tanto, no se puede repetir. Así, “Empleado NIF xxx” es diferente de “Empleado NIF yyy” aunque tengan los mismos atributos (cargo, sueldo e incluso nombre, por ejemplo). Cada recurso posee un estado interno, al cual no se puede acceder de forma directa desde el exterior; en realidad, desde el exterior se accede a representaciones de ese estado interno. COMPARACIÓN DE REST Y SOAP Se explica en esta tabla un resumen con las características de SOAP y REST que sirve de comparación entre ambas tecnologías: REST Validez de las direcciones Acoplamiento de componentes

SOAP

Dirección única para Dirección única para tocada instancia del prodas las operaciones ceso Débilmente acoplados

Fuertemente acoplados

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Definición de las operaciones

Se definen en los mensa- Se definen como puertos jes WDSL

Funcionamiento

Cada objeto soporta las Múltiple instancias del operaciones estándares proceso comparten la misma operación. definidas. Usa HTTPS.

Seguridad

Usa WS-Security.

Comunicación punto a Comunicación origen a punto segura. destino segura. Se nombran los recursos No existe mecanismo de mediante URI nombrado

Tecnología

Centrado en la escalabilidad y rendimiento a gran Centrado en el diseño de escala para sistemas dis- aplicaciones distribuidas. tribuidos hipermedia. El usuario mediante forFlujo de eventos organimularios dirige la intezados. racción Se usan muchos recursos Se ejecutan muchas taen pocas operaciones reas con pocos recursos.

Gestión del estado

El estado de la conversaEl servidor no tiene es- ción puede ser mantenido por el servidor. tado Para crear sesiones se Se usan cookies para usa cabecera de sesión no estándar añadir sesiones

Las principales ventajas de REST son: • Suele ser fácil de construir y adaptar • Consumo de recursos bajo • Se crean de forma explícita las instancias del proceso • Para las notificaciones, los clientes pueden tener una interfaz de escucha genérica. Las principales ventajas de SOAP son: • Suelen ser de fácil uso • Posibilidad de depuración • Facilidad para envolver APIS existentes

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

• Existen herramientas de desarrollo • Aumenta la privacidad Las principales desventajas de REST son: • Usa una elevada cantidad de objetos. • Puede ser complicado el manejo de URIs, espacios de nombres • Tiene muy pocas herramientas de desarrollo • La descripción sintáctica y semántica es orientada al usuario, por lo que no es formal. Las principales desventajas de SOAP son: • Los clientes precisan de puertos dedicados para diferentes notificaciones • Los clientes deben conocer las operaciones y su semántica antes de poder usarlas • Se crean de forma implícita las instancias del proceso. 1.4.2 Lenguajes de definición de servicios: el estándar WSDL WSL (Web Services Description Language) es una interfaz de lenguaje basado en XML que se utiliza para describir las funcionalidades que ofrece un servicio web. WDSL fue desarrollado principalmente por Microsoft e IBM, y se presentó la versión 1.1 al W3C a través de 25 empresas, que en ese momento supuso el mayor número de W3C hasta ese momento en una presentación conjunta. WSDL se creó para describir y publicar los formatos y protocolos de un servicio Web en una forma estándar. Los estándares de interfaz de servicios Web se necesitan para garantizar que no se deben crear interacciones especiales con cada servidor en la Web. Los elementos WSDL contienen una descripción de los datos, normalmente usando uno o más esquemas XML, que se pasa al servicio Web para que tanto el emisor como el receptor entiendan los datos que están siendo intercambiados. Los elementos WSDL también contienen una descripción de las operaciones a realizar, de manera que el receptor de un mensaje sabe cómo procesarlo, y un vínculo a un protocolo o transporte, de modo que el remitente sabe cómo enviarlo. Los elementos WSDL describen los datos y las operaciones sobre el mismo

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

WSDL se utiliza a menudo en combinación con SOAP y un esquema XML que proporciona servicios web a través de Internet. Un programa cliente que se conecta a un servicio web puede leer el archivo WSDL para determinar qué opciones están disponibles en el servidor de operaciones. Los tipos de datos especiales utilizados están incrustadas en este archivo WSDL en formato XML. El cliente puede llamar a una de las operaciones que figuran en el archivo WSDL utilizando formatos como XML o protocolos como HTTP. Un archivo WSDL de un servicio web proporciona una descripción para cada cliente de cómo el servicio puede ser llamado, los parámetros, y los datos que devuelven las estructuras. WSDL se divide en tres elementos principales, según el nivel de abstracción: ––Las definiciones de tipos de datos: determinan la estructura y el contenido de los mensajes. ––Operaciones abstractas: determinan las operaciones realizadas en el contenido del mensaje. ––Enlaces de servicio: Determinan el transporte de red que llevará el mensaje a su destino. Cada elemento de WDSL se puede especificar en un documento XML independiente e importado en varias combinaciones para crear un documento final o bien todos los elementos pueden ser definidos conjuntamente en un solo documento. Dentro de estos tres elementos principales existen son más subelementos o partes: ––Los tipos de datos: en forma de esquemas XML o en algún otro mecanismo, que se utilizan en los mensajes. ––Mensaje: una definición abstracta de los datos, en la forma de un mensaje presentado ya sea como un documento completo o como argumentos para asignar a una invocación de método ––Operación: la definición abstracta de la operación para un mensaje, por ejemplo, nombrar un método, la cola de mensajes o de procesos de negocio, que aceptan y procesan el mensaje ––Tipo de puerto: un conjunto abstracto de operaciones asignadas a uno o más puntos finales ––Encuadernación: el protocolo concreto y formatos de datos para las operaciones y mensajes definidos para un tipo determinado puerto ––Puerto: una combinación de un enlace y una dirección de red, proporcionan-

RECUERDe WDSL se divide en las definiciones de tipos de datos, las operaciones y los enlaces de servicio..

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

do la dirección de destino del servicio de comunicación ––Servicio: una colección de puntos finales relacionados que abarcan las definiciones de servicios en el archivo; los servicios de mapas de la unión con el puerto e incluyen las definiciones de extensibilidad Afortunadamente, estas partes de WSDL se generan normalmente usando herramientas que transforman los metadatos de la aplicación back-end en la información de esquema XML, el cual es fusionado luego en el fichero WSDL. WSDL se genera normalmente por los productos de servicios Web y herramientas, por ejemplo IONA ‘s XMLBus Edition. La siguiente figura muestra los elementos de WSDL, en capas de acuerdo con sus niveles de abstracción, que se definen de forma independiente del transporte, de esta forma múltiples transportes se pueden utilizar para el mismo servicio. Por ejemplo, el mismo servicio puede ser accesible a través de SOAP sobre HTTP y SOAP a través de JMS. Del mismo modo, las definiciones de tipos de datos se colocan en una sección separada para que puedan ser utilizados por múltiples servicios. Principales elementos WSDL se dividen en sub-partes.

RECUERDe Los interfaces WSDL son similares a los interfaces de CORBA o DCOM

Las partes de definición incluyen las definiciones de tipo de datos, mensajes y operaciones abstractas, siendo similares a las definiciones de interfaz en CORBA o DCOM. Los mensajes pueden tener varias partes y pueden ser definidos para su uso con el estilo de interacción orientado al procedimiento, la interacción con los documentos orientada a estilo, o ambos. A través de las capas de abstracción, los mismos mensajes pueden ser definidos y utilizados por varios tipos de puertos. Al igual que las otras partes del WSDL, los mensajes también incluyen componentes de extensibilidad, por ejemplo, para la inclusión de otros atributos de mensaje.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Las definiciones de tipos de datos WSDL se basan en esquemas XML, pero se puede sustituir por otro sistema de definición similar. Por ejemplo, los tipos de datos de IDL (CORBA Interface Definition Language) podrían ser utilizados en lugar de los tipos de datos de esquema XML. Pero si se usa otro sistema de definición de tipos de datos las dos partes en una interacción de servicios web deben ser capaces de entenderlo. Los tipos de datos de servicios Web se basan en esquemas XML, pero son extensibles a cualquier otro mecanismo Los espacios de nombres XML se utilizan para garantizar la unicidad de los nombres de los elementos XML que se utilizan en cada uno de los tres principales elementos WSDL. Se debe tener cuidado si los elementos WSDL se desarrollan por separado y se importan en un archivo, ya que los espacios de nombres utilizados en los ficheros individuales no deben solaparse. Los esquemas asociados se usan para validar tanto el archivo WSDL como los mensajes y operaciones definidas en el archivo WSDL. Los servicios Web se suelen implementar utilizando lenguajes de programación diseñados para la interacción con la Web, como por ejemplo servlets Java o páginas Application Server (ASP). Estas implementaciones de servicios Web suelen estar también basados en WSDL o representados usando WSDL. Es decir, ya sean nuevos servicios se pueden generar a partir de WSDL o servicios existentes se pueden describir utilizando WSDL.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

La Figura muestra un EJB (Enterprise JavaBeans) que es descrito usando un archivo WSDL y es exportado utilizando un servlet en la red. El servlet escucha a la red mediante un servidor Web. En el ejemplo, el servlet acepta un mensaje SOAP y lo envía a los beans que están representados por el archivo WSDL. Los beans se conectan a las específicas aplicaciones de la empresa que se divulgan a la red, proporcionando la información que es transportada en el cuerpo SOAP como entrada, en su caso, y devolver cualquier resultado de vuelta a través de los beans al servlet. Si los resultados deben ser enviados de vuelta a través de la red, los datos se devuelven a los beans a través de argumentos de salida y de retorno al servlet desde el que la respuesta vuelve al servlet. Así, el servlet que proporciona la implementación de los paquetes de archivos WSDL los datos en un mensaje de respuesta SOAP para enviar de nuevo a través de la red. Así como se ha usado EJB, la aplicación detrás del servlet podría implementarse utilizando. NET, JMS, CORBA, COBOL, o cualquier otra solución de integración de propiedad. Además, los servicios Web pueden representar las interacciones de intercambio de documentos B2B (Business to Business). 1.4.3 Estándares de seguridad en servicios web: WS-Security, SAML, XACML, etc. Existe un gran número de normas de seguridad de servicios web, ya que la seguridad en los servicios web es uno de los puntos primordiales para establecer las características de su desarrollo. Se ha de conseguir implementar medidas uniformes en la seguridad de las aplicaciones y sobre todo, ser coherente al definir qué es seguro y qué no lo es. Es recomendable utiliza un estándar que sirva como punto de referencia a la hora de implementar medidas de seguridad o programar de una manera orientada a la seguridad. WS-TRUST El estándar OASIS WS-Trust es una parte de la familia WS-Security de especificaciones y define un servicio de token de seguridad (STS), y un protocolo para solicitar y emitir tokens de seguridad que utiliza WS-Security SOAP Messaging para el establecimiento de confianza. El modelo WS-Trust es flexible para acomodar formatos de tokens estándares, incluyendo a SAML. Una de las ventajas de este estándar es que permite que los servicios dependan de proveedores de identidad de confianza para la confianza explícita (en lugar de tener que determinar la confianza de banda de cada remitente del mensaje).

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

WS-Trust se utiliza con la especificación WS-Federation para la federación de identidades, y se utiliza con WS-SecureConversation con el propósito de establecer los contextos de seguridad en WS-Security SOAP Messaging. El estándar WS-Trust se rige por el Comité Técnico Web Services Secure Exchange (WS-SX. WS-SECURITY WS-Security o Seguridad de Servicios Web es un estándar OASIS que es una extensión para SOAP que aplica seguridad en los servicios web. Proporciona la capacidad de suministro de integridad, no repudio, confidencialidad, y de paso de testigo Esta norma amplía el SOAP Header para proporcionar información de seguridad para mensajería segura, aprovecha normas de nivel inferior como firma XML y XML Encryption, es extensible para soportar múltiples formatos de tokens de identidad y autorización, y es compatible con varios modelos de confianza para el intercambio de contextos de seguridad. Muchas normas se basan en el fundamento de la mensajería SOAP de WS-Security.WS-Trust y WS-SecureConversation, se pueden utilizar juntos para crear contextos de seguridad utilizados en los mensajes SOAP de WS-Security. Algunas normas OASIS de alto nivel que usan WS-Security son: ––SAML Token Profile especifica cómo los tokens SAML se pueden utilizar en mensajería WS-Security SOAP para la identificación las credenciales de autorización y la propagación de la identidad, entre otras operaciones. ––WS-Security X.509 Certificate Token Profile especifica cómo los certificados X.509 que representa una identidad puede ser pasada en un mensaje WS-Security SOAP. ––WS-Security Username Token Profile muestra como nombres de usuario y, de forma opcional, contraseñas, se pueden pasar en mensajes WS-Security SOAP. ––WS-Security REL (Rights Expression Language) Token Prodile especifica cómo REL se puede utilizar para lograr la autorización en una SOA por medio de certificados de atributos y tokens de autorización. WS-Security es el estándar para usar en cualquier SOA basado en SOAP, y la mayoría de los productos lo soportan. Debido a que es independiente de la infraestructura de seguridad, y ya que se puede utilizar con muchos otros estándares y formatos de tokens, se proporciona un mecanismo flexible para mensajería segura en cualquier solución SOA.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

SAML SAML (Security Assertion Markup Language) es un entorno basado en XML diseñado para el intercambio de información de autenticación y autorización entre los diferentes componentes hardware y software de la infraestructura. SAML trata de definir los componentes necesarios para garantizar que cualquier aplicación y entorno puedan intercambiar la información de autenticación (identificación del usuario) y autorización (control de acceso) de forma transparente. Este estándar puede facilita el uso de los entornos donde la identificación del usuario en un único punto es independiente de la aplicación utilizada. Hay muchos usos de SAML, y se utiliza comúnmente con muchas otras normas y especificaciones, como WS-Security SOAP Messaging, WS-Trust, WS-Federation, XACML y ID-WSF (Liberty Identity Web Services Framework). SAML es un estándar OASIS desde 2002 y gira en el concepto de una aserción, que no es más que una declaración sobre un tema. Una aserción puede ser: ––Una declaración acerca de la autenticación de un sujeto y por tanto de de su identidad ––Una lista de las credenciales de autorización de un sujeto ––Una decisión de autorización de la concesión de un objeto de acceder a un recurso. La confianza de una aserción SAML se basa en la confianza de la entidad que lo emite. Desde el pliego de condiciones en el que fue aprobado en el año 2002, SAML ha adquirido un impulso significativo y su versión 2.0 incluye capacidades de identidad federadas, además de utilizarse como un token basado en XML y un protocolo para el intercambio de aserciones. Hay tres tipos de declaraciones en las aserciones: ––Una declaración de autenticación que transmite una información de autenticación de un sujeto: se indica por quién, cómo y cuándo fue el sujeto autenticado ––Una declaración de atributo que enumera los atributos asociados a un sujeto ––Una declaración de decisión de autorización, que se utiliza para dar derecho a acceder a un recurso particular. used to assert information about subjects in WS-Security SOAP Messaging, and a WS-Trust STS can be used to issue SAML tokens in this model.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Los tokens SAML pueden ser usados en mensajería basada en token y se suelen usar en WS-Security y otros protocolos de mensajería. SAML define también un protocolo de solicitud y respuesta para la solicitud de las aserciones desde una autoridad emisora SAML y este protocolo se suele usar en escenarios de autorización SOA. Los protocolos SAML permiten a los proveedores solicitar aserciones de una autoridad SAML sobre ciertos temas. Un ejemplo de petición puede ser: ‘’Devolver una decisión de autorización sobre el usuario usuario1 para acceder al recurso recurso1.”’ y ‘’Dar los atributos de seguridad del usuario usuario1.’’ El protocolo SAML también se puede utilizar para solicitar que un proveedor de identidad autentique un rema y devuelva una aserción. SAML 2.0 proporciona soporte para SSO (Single sign-on). SSO es un procedimiento de autenticación que permite que un usuario pueda acceder a varios sistemas con una sola identificación. Algunos de los tipos de SSO soportados son: ––SSO de identidad, donde la identidad del usuario se registra en ambos dominios ––SSO de atributo, donde el control de acceso a los recursos de un dominio es controlado por atributos de autorización. ––SSO anónimo SSO se puede llevar a cabo enviando sólo declaraciones de atributos SAML SAML se usa como uno de los ‘componentes básicos’ para la identidad federada. Los perfiles SAML se prestan a la federación más allá de la organización del anfitrión. La ‘Liberty Alliance’ un consorcio centrado y SSO, fue decisivo en la adición de capacidades de federación en SAML 2.0 para SSO basado en el navegador, y ahora utiliza SAML 2.0 en el ID-WSF (Identity Web Services Framework), framework centrado en el servicio web SSO. SAML ha sido ampliamente adoptado como formato de token para el transporte de autenticación y para la información de autorización, y muchos productos (por ejemplo, servidores de políticas y los sistemas de gestión de identidades federadas) han adoptado el protocolo SAML y capacidades de federación de SAML. XACML XACML (eXtensible Access Control Markup Language) es un estándar basado en XML para especificar las políticas de control de acceso a recursos. XACML es un estándar OASIS desde 2003 y proporciona no sólo un formato XML para comunicar la política de control de acceso, sino que además incluye

RECUERDe SAM está basado en XML y se usa para la transmisión de información de autenticación y autorización

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

un protocolo de petición y respuesta para preguntar por la política de decisiones que se va a usar. XACML como un lenguaje de normas XML se usa para describir requisitos de control de acceso generales, y es extensible, por lo que puede definir nuevas funciones y nuevos tipos de datos entre otros elementos. El protocolo de petición y respuesta permite que los componentes formulen una petición, para preguntar si una acción debe ser o no permitida, e interpreta el resultado. Esta respuesta incluye siempre cuatro valores: ––Se permite ––Se deniega ––Indeterminado, si se produce un error y la petición no puede resolverse ––No aplicable. Se debe tener en cuenta que PEP y PDP pueden estar dentro de una sola aplicación o distribuidos a través de varios servidores. XACML proporciona: ––peticiones y respuestas ––la política de idiomas ––la búsqueda de la política que se va a aplicar a una solicitud dada y se evalúa dicha solicitud Las principales ventajas de XACML son:

RECUERDe XACML está basado en XML y se usa definir políticas de control de acceso

––Es un lenguaje estándar y como tal , ha sido revisado por una gran comunidad de usuarios y expertos. ––Es muy flexible y por tanto, es más fácil de interpretar para otras aplicaciones que utilicen el mismo lenguaje estándar. ––Es genérico: Puede ser usado en un entorno general, no en uno específico. En lugar de tratar de proporcionar control de acceso para un recurso especifico, se puede utilizar en cualquier otro entorno. Una política puede ser escrita para poder ser usada en múltiples tipos de aplicaciones. ––Se distribuye: En lugar de tener que gestionar una única política monolítica, diferentes personas o grupos pueden administrar subpiezas de políticas y XACML sabe cómo combinar correctamente los resultados en una sola. ––Es potente: Aunque es extensible, no es necesario en muchos entornos, ya que es un lenguaje estándar y compatible con una amplia variedad de tipos de datos, funciones y reglas.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

XML-SIGNATURE Es un estándar del W3C que es una manera de proporcionar la integridad del mensaje y el no repudio de los documentos y elementos de documentos XML. También se le llama XML-SIG o XML-DSIG y confía en la clave pública tecnología en la que el hash de un elemento o un conjunto de elementos XML están firmados por la clave privada del firmante y, por lo tanto, pueden ser validados por terceros, mediante la realización de una operación criptográfica en el hash de los datos con la clave pública del remitente. Un mensaje puede tener elementos que están firmados digitalmente por diversas partes, y una firma de un mensaje pueden enlazar criptográficamente elementos juntos. XMLSignature es muy utilizada por mensajería WS-Security SOAP para proporcionar integridad y no repudio, pero puede ser utilizado en cualquier solución de mensajería XML en la que se deban cumplir los objetivos de seguridad. XML ENCRYPTION Se trata de un estándar W3C que proporciona confidencialidad de documentos XML y elementos de documentos XML. Se utiliza con varios sistemas de cifrado para cifrar los datos de las diferentes partes. XML Encryption puede ser utilizado en el nivel de elemento, proporcionando confidencialidad de XML en determinados elementos sólo ciertas partes, en la protección de seguridad de datos cifrados a través de servicios web intermediarios, hasta que el destinatario es capaz de descifrar el elemento. Al igual que el estándar XML Signature, éste es muy utilizado por mensajería SOAP WS-Security así como otros protocolos de mensajería basados en XML. RESUMEN DE ESTÁNDARES DE SEGURIDAD EN SERVICIOS WEB ESTÁNDAR DE SEGURIDAD WEB

RESUMEN Una familia de especificaciones de seguridad de Servicios Web de OASIS

WS-SECURITY

WS-Security se suele referir a Web Services Security (WSS) SOAP Messaging, un estándar unificado para garantizar la seguridad de mensajería SOAP.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

WS-TRUST

Es un estándar de OASIS que define un STS y un protocolo para solicitar y emitir tokens de seguridad utilizados por WS-Security SOAP Messaging para establecer la confianza

SAML

Es un marco basado en XML que se utiliza para la comunicación de usuario, la autenticación, la autorización y la información de atributos como afirmaciones. Lo define un formato XML y un protocolo para la especificación y el intercambio de mensajes entre las partes.

XACML

Es una expresión y lenguaje flexible basado en XML para el transporte de las políticas de control de acceso para recursos. No sólo proporciona un formato XML para transporte de política de control de acceso, sino que también incluye un protocolo de solicitud / respuesta para la consulta de políticas de decisiones.

XML Signature

Un estándar W3C, que se utiliza para los elementos de la firma digital de documentos XML. Es un estándar de bajo nivel que se utiliza tanto en implementaciones SOAP y REST para proporcionar no repudio e integridad de mensajes para mensajería basada en XML.

XML Encryption

Es un Estándar W3C, que se utiliza para el cifrado de los elementos de documentos XML. Es un estándar de bajo nivel que se utiliza tanto en implementaciones SOAP como en implementaciones REST para proporcionar confidencialidad y ocultamiento de información en mensajería basada en XML.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

1.5 Implementación de la seguridad en arquitecturas orientadas a servicios 1.5.1 Conceptos básicos de criptografía La criptografía (“escritura escondida” en griego) se utiliza para enviar una información modificada a través de unas claves. En el destino, hay que volver a utilizar claves para descifrar el texto y obtener el original. De esta forma, la información está segura, puesto que sólo se puede conseguir el original si se dispone de las claves correctas para su descifrado. Para enviar un mensaje seguro, hay que modificarlo utilizando un algoritmo. Un ejemplo es cambiar cada letra por la siguiente en el alfabeto (se le llama algoritmo de cifrado de Julio César); es decir, la “a” por la “b”, la “b” por la “c” y así sucesivamente. Cualquiera que pueda ver el texto transformado, llamado criptograma, no podrá conocer su contenido, excepto si conoce el algoritmo o intenta averiguarlo utilizando técnicas de criptoanálisis. Para poder descifrar un texto cifrado, es necesario conocer la clave. Ésta nos indica, por ejemplo, cuántos saltos se deben dar en el alfabeto para codificar o decodificar el texto. Ejemplo cifrado con algoritmo y clave: Un texto cifrado con el algoritmo del César y una clave +2, nos indica que la “a” se transforma en la letra “c”, la “b” en “d”, etc.

Los puntos clave para definir un buen sistema criptográfico son: ––Confidencialidad: Se debe garantizar que sólo el usuario autorizado puede acceder a la información. ––Integridad: Se debe garantizar que el mensaje recibido fue el enviado y que ha sido manipulado. ––Vinculación: Se debe permitir vincular una transacción o documento a un usuario o un sistema de gestión criptográfica que esté automatizado por el sistema. En el caso de un usuario, se debe asegurar su conformidad respecto a esta vinculación , por ejemplo usando firmas digitales. ––Autenticación: Se deben proporcionar mecanismos que permitan verificar la identidad del comunicante. Un ejemplo es usar la función hash criptográfica MAC.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

En 1976 apareció el sistema DES (Data Encryption Standard), con el que se inició la criptografía actual. Con la aparición del algoritmo RSA, creado por Rivest, Shamir y Adleman en 1978, la criptografía comenzó a aplicarse en transacciones financieras, líneas telefónicas, redes de ordenadores, etc. 1.5.2 Tipos de criptografía La criptografía se divide en dos ramas: la criptografía de clave secreta o simétrica y la criptografía de clave pública o asimétrica. El sistema DES pertenece a la criptografía simétrica, mientras que RSA pertenece a la criptografía de clave pública. CRIPTOGRAFÍA SIMÉTRICA La criptografía de clave secreta o simétrica es la criptografía clásica. En ella se utiliza una misma clave tanto para cifrar un mensaje como para descifrarlo. Por tanto, es necesario compartir la clave entre el emisor y el receptor, buscando un canal de comunicación seguro para el intercambio de esta clave. Un ejemplo de criptografía simétrica es el algoritmo del César indicado en el punto anterior. Si se utiliza este algoritmo con una clave +2 para el cifrado, el receptor del mensaje debe obtener el texto cifrado, el algoritmo de cifrado y la clave para descifrarlo y así conseguir el mensaje original. La criptografía simétrica es muy efectiva cuando el mensaje se intercambia en un entorno controlado, de pocas personas, pero pierde efectividad al aumentar el número de usuarios. Se trata de una técnica muy rápida, que consume pocos recursos del procesador, por lo que puede resultar muy útil en muchas situaciones. Ejemplos de algoritmos de criptografía simétrica: ––DES ––3DES ––IDEA ––AES. ––Blowfish Diagrama del proceso de criptografía simétrica

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Con Emisor k se cifra el mensaje original aplicándole la clave k y con Destinatario k se descifra, aplicándole de la misma forma la clave k. La confidencialidad y la integridad se logran si se protegen las claves en el cifrado y en el descifrado. CRIPTOGRAFÍA ASIMÉTRICA La criptografía de clave pública o asimétrica utiliza dos claves: una privada y otra pública. Se debe mantener la clave privada en secreto, mientras que la pública puede ser distribuida libremente. Ambas claves son complementarias, pero es muy complicado averiguar una partiendo de la otra. Los algoritmos de clave pública o asimétrica consumen muchos recursos del procesador y necesitan claves de encriptación más grandes. Diagrama del proceso de criptografía asimétrica

Se debe tener en cuenta que se cifra con la clave pública del destinatario, de forma que solo él, al tener su clave privada pueda acceder al mensaje original. La criptografía asimétrica se basa en la utilización de números primos muy grandes. Si se multiplican dos números primos muy grandes entre sí, el resultado obtenido no puede descomponerse fácilmente.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Algunos algoritmos que usan este tipo de criptografía son: ––DSA ––RSA ––Diffie-Hellman CRIPTOGRAFÍA HIBRIDA Es un método criptográfico que se basa en los dos tipos de sistemas simétrico y el asimétrico. La criptografía hibrida utiliza el cifrado de clave pública para compartir una clave para el cifrado simétrico. Un ejemplo de criptografía híbrida es el sistema empleado por PGP. La clave de sesión es cifrada con la clave pública, y el mensaje enviado es cifrado con la clave simétrica, combinándolo así en un solo miembro. El destinatario usará su propia clave privada para descifrar esta clave de sesión para después utilizar la clave de sesión para descifrar el mensaje. 1.5.3 Entidades certificadoras La certificación digital consiste en unir unos datos de verificación, la clave pública, a los datos del propietario de la clave privada asociada. Esta operación es realizada por la “Autoridad de Certificación”, que, en la Ley, se denomina “Prestador de servicios de certificación”. Una entidad certificadora o autoridad de certificación actúa como tercero, siendo de confianza reconocida por los dos elementos implicados en una transacción: el firmante, o el titular del certificado, y el usuario receptor del certificado. Una autoridad de certificación debe gestionar sus propias claves con las que firma certificados de clave pública. Así pues, una autoridad de certificación también tiene un certificado asociado que, en muchos casos, firma ella misma. Una autoridad de certificación es una entidad de confianza, independiente y sin intereses en las transacciones en las que se utilizarán los certificados; por tanto, debe tener el reconocimiento de la comunidad a la que va a dar servicio. Todas las entidades certificadoras expiden tres tipos de certificados digitales: ––Certificados de servidor: Sirven para establecer el protocolo SSL en una comunicación entre cliente y el servidor. Por ejemplo, en el comercio electrónico

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

cifra la información que viaja entre el cliente y el servidor(numero de la tarjeta de crédito, dirección personal, productos comprados). ––Certificados de Firma de Código: con ellos se puede evitar la entrada de virus en él o establecer sistemas para el pago de licencias de un modo sencillo. ––Certificados Personales: se utilizan para identificar las personas que acceden al sitio ‘web’ o que firman un determinado documento (firma de contratos a través de Internet,Visado Digital, facturación electrónica,Voto electrónico, etc.) Algunos ejemplos de entidades certificadoras son: ––Nacionales -- FNMT (Fabrica Nacional de Moneda y Timbre) -- ACE (Agencia de Certificación electrónica) -- Camerfirma -- Verisign España ––Internacionales ––Verisign ––Entrust 1.5.4 Certificados digitales. Características Si se dispone de una clave pública de una persona, se le puede enviar mensajes de forma confidencial y validar su firma en un documento aplicando técnicas de criptografía. Pero, para poder hacerlo, se debe estar seguro que la clave pública pertenece realmente a esa persona, y esto sólo es posible si hemos recibido la clave pública por un medio seguro. El sistema de clave pública se basa en la seguridad de que la clave privada asociada a la clave pública que poseemos está custodiada únicamente por la persona con la que establecemos comunicación. Si no fuera así, se nos estaríamos comunicando con un desconocido o con un impostor. Es necesario obtener la clave pública por medios seguros que ofrezcan confianza. En entornos de pocas personas, una solución sería un intercambio personal, pero esto es muy complicado cuando interviene un gran número de personas, ya que es necesario mantener el contacto para saber si las claves están activas y, en su caso, para actualizarlas. Para poder confiar en la asociación entre una clave pública y la identidad de quien custodia la clave privada asociada, han surgido los certificados digitales. La Ley 59/2003, de firma electrónica, define este certificado como “un documento firmado electrónicamente por un prestador de servicios de certificación que vincula unos datos de verificación de firma a un firmante y confirma su identidad”.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

El certificado digital es un elemento de verificación de firma que va destinado al usuario que va a recibir la información firmada. Por otra parte, la criptografía ofrecerá al verificador la seguridad y el certificado la confianza. Un certificado incluye 4 grupos de información: ––Información del titular. Contiene los datos del titular del certificado, como por ejemplo, nombre, dirección, email, etc. ––Clave pública del titular. Es la clave que se utilizará para validar la información cifrada con la clave privada asociada, custodiada por el titular. ––Información del emisor o autoridad de certificación. Incluye los datos de la autoridad de certificación. ––Firma del emisor. Un certificado digital es un documento seguro porque incorpora la firma electrónica del emisor, que asegura su autenticidad y su integridad. Para validar la firma electrónica del emisor se necesita su clave pública, y la mejor forma de obtenerla es a través del certificado digital. Con este certificado accederemos a la clave pública del emisor y comprobaremos la firma del certificado. La estructura de un certificado digital sigue el estándar X.509 desarrollado por ITU-T (International Telecommunication Union-Telecommunication Standarization Sector) y el ISO/IEC (International Standards Organization / International Electrotechnical Commission). Según este estándar, un certificado debe contener, como mínimo, los siguientes campos: ––Versión ––Número de serie ––Algoritmo de firma ––Emisor –– Validez ––Titular ––Clave pública ––Una serie de extensiones o campos complementarios. Todos los campos de un certificado van firmados por el emisor; por ello, el certificado debe incluir la información sobre el algoritmo de firma utilizado, así como la firma digital del emisor. Los certificados digitales han de contar con una serie de características que los hacen más seguros:

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––Confidencialidad: Sólo el destinatario puede leer el mensaje cifrado. ––Autenticidad: Se debe poder verificar que el mensaje proviene de la persona que lo emitió. ––Integridad: Debe asegurarse que no se altera la información del mensaje. ––Aceptación de Autoría: El emisor no puede negar de forma válida, haber sido el remitente del mensaje. EXTENSIONES DE UN CERTIFICADO DIGITAL La versión 3 del estándar X.509, que se utiliza para crear los certificados electrónicos, incluye una serie de campos, llamados extensiones, que permiten identificar al emisor y al titular de una forma más precisa. También permiten controlar los usos y limitan la responsabilidad de la autoridad de certificación. Existen dos tipos de extensiones: ––Informativas: encargadas de informar sobre el propio certificado, ––Restrictivas: limitan el uso del certificado. Algunas de las extensiones pueden ser especificadas como críticas. Si una aplicación se encuentra con una extensión crítica en un certificado, la aplicación debe gestionarla obligatoriamente, o rechazar el certificado. Al señalar una extensión como crítica, se trata de proteger al emisor del certificado de usos inadecuados o prohibidos. Si una aplicación no sabe gestionar una extensión crítica, el certificado será rechazado por considerarse inválido. Puesto que no se sabe qué aplicaciones pueden gestionar estas extensiones críticas, los emisores de certificados tratan de evitarlas en la medida de lo posible. Algunas de las extensiones más utilizadas son las siguientes: IDENTIFICADOR DE CLAVE DE EMISOR Proporciona una identificación única de la clave pública del emisor del certificado, ya que podría tener más de una clave asociada. Esta circunstancia puede darse en un proceso de renovación de las claves. La clave tiene un período de validez, al término del cual debe sustituirse por otra. Entonces podrá haber documentos firmados por el mismo emisor con una clave privada distinta.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

IDENTIFICADOR DE CLAVE DEL TITULAR O USUARIO Tiene el mismo significado que la extensión “Identificador de clave de emisor”, pero referente a la clave pública del titular del certificado. USO DE LA CLAVE Es una extensión que informa acerca del uso de la clave que el emisor otorga al titular del certificado. Por esta razón, es recomendable señalarla como extensión crítica, para obligar a las aplicaciones a gestionar esta limitación o no dar por válido el certificado. En el uso de la clave pueden aparecer diversos valores, que pueden combinarse, por ejemplo: ––Firma de certificados ––Firma CRL ––Firma digital ––Cifrado de claves ––Cifrado de datos –– Acuerdo de clave ––Solo cifrar ––Solo descifrar ––No repudio USOS EXTENDIDOS DE LA CLAVE Es un complemento de la extensión “Uso de la Clave” y se utiliza para especificar para qué tipo de aplicaciones el emisor permite utilizar la clave privada. Los usos extendidos de la clave que pueden especificarse son: ––Autenticación de servidor: se utiliza para certificados de servidor Web. Es compatible con los usos: firma digital, cifrado de clave y acuerdo de clave. ––Autenticación de cliente: permite utilizar el certificado para garantizar la identidad del titular del certificado ante un servidor. Es compatible con los usos: firma digital y acuerdo de clave. ––Firma de código: permite la firma de programas y es compatible con la firma digital. ––Protección de email: permite utilizar el certificado en aplicaciones de correo electrónico. Es compatible con los usos: firma digital, no repudio, cifrado de clave o acuerdo de clave.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––Sellado de tiempo: permite firmar sellos de tiempo que enlazan un documento o su código resumen con una fecha. Es compatible con los usos: firma digital y no repudio. En la Ley 59/2003 se define el sello de tiempo así: “se entiende por fecha electrónica el conjunto de datos en forma electrónica utilizados como medio para constatar el momento en que se efectúa una actuación sobre otros datos electrónicos a los que están asociados”. ––Firma de OCSP (Online Certificate Status Protocol): es la firma de respuestas en línea del estado del certificado. Es compatible con los usos: firma digital y no repudio. POLÍTICA DE CERTIFICACIÓN Es un documento que elabora el emisor de los certificados y que incluye: ––Su uso ––La comunidad a la que va dirigido ––Las declaraciones de responsabilidad de los agentes implicados en la gestión del certificado ––Los requerimientos de seguridad que el emisor define como necesarios para la emisión del certificado. En los certificados incluidos en Windows, las políticas de certificación aparecen como “Bases del certificado”. La extensión correspondiente a las políticas de certificación contiene uno o varios identificadores de objeto, que indican la política, o políticas aplicables a los procesos de emisión del certificado. Una política de certificación indica el nivel de seguridad asociado al certificado, es decir, indica el grado de fiabilidad que existe en que la identidad del usuario está unida a la clave pública. Además, permite equiparar la seguridad de los certificados emitidos por diferentes emisores. El contenido de una política de certificación estándar incluye: ––Introducción: especifica la comunidad y el ámbito de aplicación del certificado. ––Requisitos generales: indica las obligaciones y responsabilidades de las partes implicadas. ––Identificación y autenticación: define los procesos de identificación y registro del titular. ––Requerimientos operacionales: describe los procesos de registro, emisión, publicación y revocación de los certificados. ––Controles de seguridad física, de procedimientos y de personal: define los re-

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

quisitos de seguridad no técnicos a implantar a nivel físico, de procesos y recursos humanos. ––Controles de seguridad técnica: describe las medidas de protección de las claves criptográficas, de los equipos y de la red de comunicaciones. ––Contenidos de los certificados y listas de revocación: describe los campos y extensiones incluidos en los certificados digitales. ––Gestión y administración del documento: incluye información sobre el mantenimiento de las políticas de certificación. PRÁCTICAS DE CERTIFICACIÓN Mientras que una política es un conjunto de reglas que indican cómo se aplica un certificado a una comunidad, con unos requerimientos de seguridad comunes, las prácticas de certificación son una serie de procedimientos que una autoridad de certificación utiliza para emitir certificados. Una política de certificación puede ser reconocida por todo un sector, pero las prácticas sólo son seguidas por un emisor en particular. Además de las políticas y las prácticas, el emisor puede publicar un documento donde se definan, de forma esquemática, los términos y condiciones de la certificación. PUNTOS DE DISTRIBUCIÓN DE LAS LISTAS DE CERTIFICADOS REVOCADOS Un prestador de servicios de certificación debe mantener accesible un servicio de consulta sobre la vigencia de los certificados. En este servicio, que debe mantenerse siempre actualizado, se indicará si los certificados están vigentes o si su vigencia ha sido suspendida o extinguida. LISTA DE CERTIFICADOS REVOCADOS (CRL) Los certificados tienen un período de validez. Pasado ese tiempo, el certificado caduca y deja de tener validez. Puede ocurrir que un certificado pierda su efectividad durante el período de validez. El emisor debe mantener una lista pública con los números de serie de los certificados que, a pesar de ser válidos, han perdido su efectividad. Esta lista se llama lista de certificados revocados (CRL) y, en ella, se mantienen los certificados hasta que se sobrepasa el período de validez. En la lista también pueden incluirse certificados suspendidos de forma temporal, pero sólo podrán mantenerse en este estado por el tiempo que se indique en las políticas de certificación.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Las listas de certificados revocados son documentos electrónicos con un formato estándar, firmados digitalmente por el emisor del certificado. Estas listas también tienen un período de validez y antes de que éste expire, deben ser reemplazadas por otras, de forma que siempre está disponible la lista de certificados revocados. El período de validez de las listas depende de la autoridad de certificación y suele especificarse en las políticas o prácticas de certificación. Existen diversas causas que provocan la extinción de la vigencia de un certificado electrónico. Todas están definidas en la Ley 59/2003, de firma electrónica: ––Cuando expira el período de validez del certificado. ––Si lo anula el firmante, la persona física o jurídica representada por éste, un tercero autorizado o la persona física solicitante de un certificado electrónico de persona jurídica. ––Si se pone en peligro el secreto de los datos de creación de firma del firmante o del prestador de servicios de certificación, o se utilizan esos datos, de forma indebida, por un tercero. ––Si existe una resolución judicial o administrativa que ordene la extinción. ––Si se extingue la personalidad jurídica del firmante, o su representado, ya sea por finalización de la actividad, o por fallecimiento, incapacidad, etcétera. ––Cuando se produzca el cese de la actividad del prestador de servicios de certificación, salvo que, con el consentimiento del firmante, el certificado electrónico sea transferido a otro prestador de servicios de certificación. ––Si se produce alguna alteración de los datos aportados para la obtención del certificado. NOMBRES ALTERNATIVOS DEL EMISOR Y DEL TITULAR Permiten especificar más información, como el correo electrónico, la dirección IP o una dirección de Internet, por ejemplo. ATRIBUTOS DE DIRECTORIO DEL TITULAR Permite incluir información como el lugar de residencia, la fecha y el lugar de nacimiento, etc. INFORMACIÓN DEL EMISOR DEL CERTIFICADO Especifica la forma de acceder a información y servicios proporcionados por el emisor, tales como servicios de validación en línea, datos de políticas del emisor o acceso al certificado del emisor.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

1.5.5 Identificación y firma digital mediante certificados digitales La firma electrónica o firma digital, es un conjunto de datos o resumen encriptado, que se añade al mensaje se envía, con el objeto de proteger la integridad de los datos que se transmiten (y de esta forma evitar que sean modificados o falsificados) y como medio para identificar al autor del documento. A través de esta codificación, el receptor del mensaje puede comprobar la integridad de los datos y la identidad de la persona que los envió. Así, la firma electrónica protege la información tanto enviada como recibida. Los requisitos que debe cumplir una firma electrónica son: ––Autentificación: Identifica al usuario que ha enviado el mensaje (de forma similar a la firma manuscrita). El receptor puede estar seguro que el emisor es el autor del mensaje. ––Integridad: Garantiza que el mensaje emitido es exactamente el mismo que recibe el emisor, y que no se ha modificado el mensaje durante la transmisión del emisor al receptor. ––No repudio o no rechazo en origen: Sólo el emisor puede haber firmado el documento (el emisor no puede negar que ha sido él quien ha enviado el mensaje, ya que se ha creado por medios que sólo él sabe) ––Confidencialidad: La firma electrónica no implica asegurar la confidencialidad del mensaje, ya que un documento firmado electrónicamente puede ser visto por otras personas, igual que una firma manuscrita. Hay varios tipos de firma electrónica, los principales son: ––la firma electrónica básica, no garantiza ni la identidad del firmante, ni la veracidad de la información recibida ya que no asegura que el envío lo haya realizado el emisor real ––la firma electrónica avanzada reconocida, sí asegura la seguridad e identidad del firmante, ya que esta ha sido garantizada por una tercera organización de confianza así mismo garantiza la integridad de la información recibida, característica inherente a la firma digital. Tendrá el mismo valor jurídico que la firma manuscrita y será admisible como prueba en juicio. A veces al hablar de firma electrónica, se habla de este tipo de firma, ya que se considera sinónimos. El proceso de firma digital viene dado por dos tipos de algoritmos: ––el utilizado para realizar el hash, o código resumen ––el utilizado para el cifrado de clave asimétrica o de clave pública.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

A modo de ejemplo, se pueden ver los certificados incluidos en Windows. Se pueden incluir en cada uno de los navegadores del equipo: Internet Explorer, Firefox, Google Chrome, etc. Para poder verlos, cada navegador tiene sus herramientas, pero por ejemplo en Internet Explorer es en Herramientas/ Opciones de Internet/Contenido/ Certificados/ Entidades emisoras de certificados de raíz de confianza. Al seleccionar una de las entidades que aparecen y pulsar el botón “Ver” y luego abriendo la pestaña “Detalles” se pueden ver todos los campos incluidos en el certificado.

Detalles de certificado digital en Internet Explorer. En cada uno de los campos incluidos en un certificado con el formato X.509 se incluye la siguiente información: ––El campo “versión” contiene el número de versión del estándar X.509 que se utiliza en el certificado.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––El “número de serie” es un entero positivo, único por certificado emitido, que permite identificar un certificado concreto partiendo del emisor y este número de serie. Este número es asignado por la autoridad de certificación. ––El “algoritmo de firma”, imprescindible para validar la firma incorporada en el certificado, indica el algoritmo utilizado por el emisor para firmar el certificado; es decir, identifica un algoritmo de hash y un algoritmo de clave pública. ––Los campos correspondientes al “emisor” y al “titular” identifican, respectivamente, a la autoridad de certificación que ha firmado y emitido el certificado y al titular del certificado cuya clave pública está certificada en el campo siguiente. Al titular del certificado en Windows se le llama “Asunto”. Para describir la identidad del emisor y del titular del certificado se utiliza una estructura de directorio X.500. Este directorio es un conjunto de información estructurada jerárquicamente. En él, los atributos que componen el nombre son: -- País (C) -- Organización (O) -- Unidad organizacional (OU) -- Calificador del nombre -- Provincia o estado (L) -- Nombre común (CN) -- Número de serie (SN) ––La “validez” del certificado del mismo. Se indica el período de tiempo durante el cual el certificado es válido y la autoridad de certificación está obligada a mantener información sobre su estado. Durante el período especificado, el emisor del certificado garantiza la asociación de la identidad del titular y su clave pública. La información se indica a través de dos fechas que indican los límites de validez del certificado. Cuando se trata de la validez de los certificados de emisor, el período debe ser amplio, habitualmente, más de 10 años. Para el resto, la Ley 59/2003, de firma digital, dispone que “el período de validez de los certificados electrónicos será adecuado a las características y tecnología empleada para generar los datos de creación de firma. En el caso de los certificados reconocidos este período no podrá ser superior a cuatro años”. ––La “clave pública” asociada al titular del certificado. Se trata de una clave basada en un algoritmo simétrico o de clave pública, como RSA, DSA, etcétera. ––El resto de campos que aparecen son las “extensiones” del certificado, ya explicadas.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Atributos correspondientes al directorio X.500 en un certificado de Windows. 1.5.6 Cifrado de datos En criptografía, el cifrado de datos es el proceso en el cual usando un algoritmo, denominado algoritmo de cifrado, y una clave, la clave de cifrado, se transforma un mensaje de forma que no sea comprensible para una persona que no tenga la clave de descifrado. Se tienen por tanto dos algoritmos: ––Algoritmo de cifrado ––Algoritmo de descifrado Y se tiene dos claves; ––Claves de cifrado ––Clave de descifrado Como se ha indicado anteriormente si las claves son iguales, se habla de criptografía simétrica y si son diferentes de criptografía asimétrica. Se va a explicar el proceso de cifrado y descifrado con un ejemplo: Dos personas han pedido un certificado electrónico, y junto a él les proporcionan dos claves a cada uno, una privada y una pública, que les permitirán firmar, encriptar y desencriptar mensajes. El receptor le envía un mensaje electrónico al receptor, y lo encripta para que no lo pueda leer nadie más que él.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Éste sería el proceso: ––El receptor oculta su clave privada para que nadie más la conozca, y le envía su clave pública al emisor (ya que la clave pública puede ser conocida por cualquier persona) ––El emisor encripta el mensaje utilizando la clave pública del receptor. Mediante operaciones matemáticas se protege la información que se quiere enviar, se oculta el texto y se convierte en una cadena de números y letras, es lo que se conoce como mensaje encriptado. Esto aumenta la seguridad de la información. ––Una vez encriptado, el emisor envía el mensaje al receptor. ––El receptor tendrá que desencriptar el mensaje recibido utilizando su clave privada y entonces la información se hará visible. El mensaje sólo puede ser desencriptado por los que conozcan las instrucciones y la clave utilizada. Si el mensaje desencriptado por el receptor es legible significa que ese mensaje ha sido encriptado con la clave pública del receptor (es decir, el único que puede leerlo es el dueño de la clave privada) y que no ha sufrido ninguna alteración durante su envío, porque si hubiera sido modificado, al descifrarlo no sería legible. Con este método nos aseguramos que únicamente el receptor pueda leer el mensaje, ya que es la única que conoce su clave privada. Este proceso es el más habitual: destinatario del mensaje proporciona su clave pública al emisor para que pueda encriptar el mensaje, y una vez recibido lo desencripta con su clave privada. Para cifrar los mensajes también podemos se puede este otro método menos habitual el emisor envía al receptor su clave pública y encripta el mensaje con su clave privada; la persona que lo recibe lo desencripta con la clave pública que le ha enviado el emisor. Así se cumplen dos de los requisitos requeridos: la integridad (certeza de que el mensaje no ha sido modificado) y no repudio en origen (imposible que el receptor niegue que el mensaje del emisor ha sido cifrado con su clave privada), pero nos e cumple la confidencialidad ya que la clave pública puede estar en manos de muchas personas. El tercer requisito (identidad del emisor del mensaje) se obtiene utilizando los certificados digitales emitidos por una autoridad certificadora de confianza. Este método es menos seguro si lo que queremos es que el receptor sea la única que lea el mensaje, ya que al desencriptarlo con la clave pública, cualquier persona que la conozca puede verlo también, es decir, no garantiza la confidencialidad.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

1.6 Directorios de servicios 1.6.1 Concepto de directorio Un servicio de directorio es el sistema de software que almacena, organiza y proporciona acceso a la información en un directorio. En la ingeniería de software, un directorio es un mapa entre los nombres y valores. Se permite la búsqueda de valores dados un nombre, similar a un diccionario. De la misma forma que una palabra en un diccionario puede tener múltiples definiciones, en un directorio, un nombre puede ser asociado con diferentes elementos de información. Del mismo modo, al igual que una palabra puede tener diferentes usos en una oración y por tanto, diferentes definiciones, un nombre en un directorio puede tener diferentes tipos de datos. Un directorio puede contener sólo un pequeño conjunto de tipos de nodos y tipos de datos, o pueden ser muy amplios, soportando un conjunto arbitrario y extensible de tipos de datos. Algunos ejemplos de directorios son: ––En una guía telefónica, los nodos son los nombres y los elementos de datos son números de teléfono. ––En el DNS (Domain Name Server) los nodos son los nombres de dominio y los elementos de datos son direcciones IP (y alias, nombres de servidor de correo, etc.) ––En un directorio que utiliza un sistema operativo de red, los nodos representan los recursos que son administrados por el sistema operativo, incluidos los usuarios, ordenadores, impresoras y otros recursos compartidos. Un servicio de directorio simple llamado un servicio de nombres, asigna los nombres de los recursos de la red a sus respectivas direcciones de red. Con el nombre del tipo de servicio de directorio, un usuario no tiene que recordar la dirección física de un recurso de red, proporcionando un nombre para localizar el recurso. Cada recurso de la red se considera un objeto en el servidor de directorio. La información sobre el recurso en particular se almacena como atributos de ese objeto. La información dentro de los objetos se puede hacer segura para que sólo los usuarios con los permisos disponibles sean capaces de acceder a ella. Algunos directorios más complicados están diseñados con espacios de nombres como suscriptores, servicios, dispositivos, derechos, preferencias, contenido, etc.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Este proceso de diseño está muy relacionado con la gestión de identidades. Un servicio de directorio define el espacio de nombres para la red. Un espacio de nombres es el término que se utiliza para contener uno o más objetos como entradas con nombre. El proceso de diseño de directorio normalmente tiene un conjunto de reglas que determinan cómo se llaman y se identifican los recursos de red. Las reglas especifican que los nombres sean únicos e inequívocos. En X.500 y LDAP el nombre es el nombre distinguido (DN) y se utiliza para referirse a un conjunto de atributos (nombres distinguidos relativos) que componen el nombre de una entrada del directorio. Un servicio de directorio es una infraestructura de información compartida para localizar, gestionar, administrar y organizar los elementos comunes y los recursos de red, que pueden incluir volúmenes, carpetas, archivos, impresoras, usuarios, grupos, equipos, números de teléfono y otros objetos. Un servicio de directorio es un componente importante de un NOS (Network Operating System). En algunos casos más avanzados, es el repositorio central de información para una plataforma de prestación de servicios. Por ejemplo, buscar “ordenadores” con un servicio de directorio podría producir una lista de equipos y la información disponible para el acceso a ellos. Al hablar de replicación en el diseño y gestión de un servicio de directorio se utiliza para indicar que el mismo espacio de nombres de directorio (los mismos objetos) se copian en otro servidor de directorio por razones de redundancia y el rendimiento. El espacio de nombres replicado se rige por la misma autoridad. Al hablar de distribución, se indica que múltiples servidores de directorio, que tienen diferentes espacios de nombres, se interconectan para formar un servicio de directorio distribuido. Cada espacio de nombres distinto se regirá por las diferentes autoridades. Los servicios de directorio son parte de una iniciativa de interconexión de sistemas abiertos (OSI) para conseguir poner de acuerdo a todos en la industria con las estándares comunes de la red para proporcionar interoperabilidad de múltiples proveedores. En la década de 1980, la UIT y la ISO propusieron un conjunto de normas denominadas X.500, los servicios de directorio. Estas normas eran de forma inicial tratadas de mensajería electrónica. LDAP (Lightweight Directory Access Protocol), se basa en los servicios de información de directorios de X.500, pero utiliza la pila TCP / IP y un esquema de codificación de ua cadena de ese protocolo. Algunas de las implementaciones de servicios de directorio antes de la llegada de X500 son:

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––Domain Name System (DNS) ––Network Information Service (NIS) ––NetInfo ––NT Domains ––Windows Registry Y algunos ejemplos de implementaciones basadas en LDAP /X500 son: ––Active Directory de Microsoft ––eDirectory de Novell ––Red Hat Directory server ––eNitiatives ViewDS Directory Server ––Open Directory ––Apache Directory Server ––CA Directory ––Sun Java Directory Server ––Open DS ––Nexor Directory ––OpenLDAP Algunas herramientas de código abierto para crear servicios de directorio son: ––OpenLDAP ––El protocolo Kerberos y el software Samba Por último comentar que en Unix, los servicios de nombres se suelen configurar a través del archivo de configuración nsswitch.conf. En ese caso, la información puede ser devuelta usando el comando getent. 1.6.2 Ventajas e inconvenientes Hay diversas diferencias entre un servicio de directorio de una base de datos relacional típica. Aunque hay excepciones, en general: ––la información del directorio se lee con más frecuencia de lo que se escribe, lo que hace las funciones relacionadas con las transacciones y la vuelta atrás menos importante. ––los datos pueden ser redundantes si esto ayuda al rendimiento. Los esquemas del directorio se definen como clases de objetos, atributos, vínculos de nombres y el conocimiento, donde una clase de objeto tiene:

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

RECUERDe Los directorios de servicios presentan una serie de diferencias frente a las bases de datos relacionales. Se deben estudiar las características de las mismas para decidir qué es más conveniente usar en cada caso.

––Must - atributos que cada una de sus instancias deben tener. ––May - atributos que pueden definirse para un ejemplo, se puede omitirse tratando su ausencia de forma semejante a un NULL en una base de datos relacional. ––Los atributos tienen a veces de varios valores que permite múltiples nombres de atributos en un nivel. ––Los atributos y clases de objetos están estandarizados en toda la industria y formalmente registrados en la IANA para su ID de objeto. Por lo tanto, las aplicaciones de directorio pretenden reutilizar gran parte de las clases y los atributos estándar para maximizar los beneficios del software de servidor de directorios existente. ––Se introducen instancias de Object de forma que cada clase de objeto hereda de la clase de objeto padre (y en última instancia de la raíz de la jerarquía) añadiendo atributos a su lista must/ may. ––Los servicios de directorio son a menudo un componente central en el diseño de la seguridad de un sistema informático ajustando de forma precisa el control de acceso: quién puede gestionar, de qué manera y qué tipo de información. 1.6.3 Directorios distribuidos Hay dos opciones de servicios de directorio: Centralizados y distribuidos. Si se habla de servicios centralizados, en la red existiría un único servidor que ofrece todo el servicio de directorio que responde a todas las consultas de los terminales clientes. En cambio, cuando un servicio es distribuido, son varios los servidores que ofrecen el servicio de directorio. En la mayoría de los casos, en el servicio de directorio distribuido, los datos están replicados o fraccionados. Se habla de datos fraccionados, si cada uno de los servidores de directorio guarda una parte de la información que no se solapa con las otras partes guardadas en los otros servidores. Se habla de información replicada, si ésta puede ser almacenada en dos o más servidores. Por lo general, cuando el servicio de directorio está distribuido, parte de la información se fracciona y otra parte está replicada. Uno de los estándares en los que se basa la gran mayoría de implementaciones es el X.500 (LDAP) pero utilizando el protocolo TCP/IP y no el modelo OSI.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

1.6.4 Estándares sobre directorios de servicios: UDDI UDDI (Universal Description, Discovery and Integration) o catálogo de negocios de Internet es un catálogo donde los registros se almacenan en XML. La iniciativa para la descripción universal, el descubrimiento y la interoperabilidad (UDDI) produce las especificaciones y la implementación de un repositorio para la descripción de servicios Web. El registro UDDI se puede buscar por medio de diversos criterios de clasificación que permiten obtener la información de contacto para las empresas que ofrecen servicios de interés. UDDI proporciona un medio de acceso público para almacenar y recuperar información acerca de los interfaces e implementaciones de servicios Web. La Web necesita algo semejante a UDDI para proporcionar un centro de intercambio de información de los servicios Web para que los editores y los consumidores pueden encontrarse. Sólo entonces se percibirá el verdadero valor de los servicios web: cuando los consumidores de servicios Web puedan localizar y comenzar a acceder implementaciones de servicios Web en cualquier parte del mundo con facilidad y rapidez. El registro UDDI acepta la información que describe una empresa, incluidos los servicios web que ofrece, y permite realizar a las partes interesadas búsquedas on-line y descargas de la información. Un registro en UDDI tiene tres partes: ––Páginas blancas: Indica la dirección, contacto, los identificadores de la empresa (nombre y descripción de la misma) y otras informaciones, como la Dun & Bradstreet universal Número del sistema de numeración. ––Páginas amarillas: Dan la categorización industrial basada taxonomía propuesta por UDDI. Esto incluye la Clasificación Industrial Estándar (SIC), el Sistema de Clasificación Industrial de América del Norte (SCIAN), Código de Servicios (UNSPSC) y taxonomías geográficas. ––Puede haber varias páginas amarillas, ya que una empresa suele proporcionar varios servicios. Cada página amarilla describe un servicio asociado a una página blanca. ––Páginas verdes: Contiene toda la información técnica sobre los servicios de la empresa. Se utilizan también para describir la forma de acceder a los servicios web, con información sobre enlaces de servicio. El servicio web tiene varios enlaces y un servicio puede tener varias páginas verdes. Este necesitará cada enlace para acceder de manera diferente.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

La clasificación e identificación de la información es útil para buscar y recuperar listas y los detalles específicos sobre las empresas. Las empresas pueden añadir cualquier número de clasificaciones para sus registros con el fin de ayudar a las búsquedas. Información La clasificación e identificación incluye elementos tales como los códigos del IRS industria, números Dun y Bradstreet DUNS, códigos de productos, códigos geográficos, etc. La clasificaciones e identificaciones se gestionan a través de “bolsas propietarias”, o secuencias de datos no estructurados, en los que se puede almacenar prácticamente cualquier tipo de clasificación y la información de identificación. UDDI ayuda a ampliar y simplificar la interacción de negocios entre empresas (B2B- Business To Business). Por ejemplo, es habitual que un fabricante necesite crear muchas relaciones con clientes diferentes, cada uno con su propio conjunto de normas y protocolos, UDDI admite una descripción muy flexible de servicios utilizando prácticamente cualquier interfaz. Otro ejemplo puede ser el proveedor de mercado B2B que necesita obtener los datos del catálogo de los proveedores en la industria. UDDI es como una especie de ventanilla única para la información sobre las empresas y los servicios electrónicos. Las bases de datos alojadas se denominan sitios de operador, y los programadores UDDI utilizan las API de SOAP para interactuar con uno o más de estos sitios. Los operadores no cobran por el servicio básico UDDI. Los datos profesionales pueden contener punteros a las especificaciones de interfaz de servicios web, como WSDL. Los servicios privados UDDI a menudo se utilizan para almacenar información interna de una empresa, tales como una lista de servicios Web disponibles.

RECUERDe UDDI fue establecido por un consorcio de la industria con el fin de crear e implementar un directorio de servicios Web..

UDDI está basado en los estándares existentes, como XML (Extensible Markup Language)y SOAP (Simple Object Access Protocol). Todas las implementaciones de soporte a la especificación UDDI UDDI. La especificación pública se desarrolla en un proceso abierto, inclusivo de los miembros de la organización. La intención es producir y poner en práctica tres versiones sucesivas de la especificación antes de encender la propiedad para el desarrollo futuro a un organismo regulador independiente. EVOLUCIÓN DE UDDI UDDI comenzó como una colaboración entre Microsoft, IBM y Ariba para promover la adopción y el uso de estándares de servicios Web. Las empresas fundaron UDDI. org e invitaron a otras empresas a participar: algunos con derechos de fundador y otros con privilegios de asesoramiento. Las empresas invitadas como fundadores sentaron las bases, definieron las especificaciones y los requisitos iniciales y decidieron sobre la eventual disposición de la obra.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Los tres fundadores originales fueron también los operadores originales o hosts, del depósito inicial UDDI público. Más tarde, Hewlett-Packard se unió al proyecto y se sustituyó Ariba como lugar de acogida del registro, uniéndose a SAP como operador. Otros operadores pueden unirse con el tiempo si se ajustan a los términos y condiciones establecidos por los operadores originales y si los miembros fundadores de acuerdo. Más de 300 empresas se unieron a UDDI.org para formar parte de los esfuerzos por establecer un directorio de empresas Web que alojen servicios. Quince de las empresas forman el grupo de trabajo central que se encarga de definir la orientación estratégica del proyecto, así como la resolución de conflictos y la toma de decisiones. El resto son miembros del Grupo Consultivo, que permite a una empresa para revisar y hacer comentarios sobre los borradores de especificaciones antes de que se hagan públicos y que, a la vista o invitación de uno o más de los miembros del Grupo de Trabajo, a unirse a una de las especificaciones de redacción equipos. Los miembros del Grupo de Trabajo tienen la última palabra en cuestiones de organización y las decisiones de especificación, pero hay pequeños equipos, incluidas las empresas que no figuran en los miembros principales, que realizan el trabajo de las especificaciones. Las especificaciones desarrolladas por los equipos son enviados para su revisión y aprobación de todos los miembros antes de ser publicados. UDDI v2 contiene mejoras tales como la publicación de las especificaciones del operador y la replicación, la mejora de la capacidad de consulta y proporcionar apoyo a la internacionalización. Las diferentes versiones de la especificación UDDI son: ––Versión 1, publicada en septiembre de 2000, estableció la base para el registro. ––Versión 2, que fue publicada en junio de 2001, produce la alineación con otros estándares y añadió otras características como las relaciones comerciales. ––Versión 3, cuya publicación se produjo en 2002, supuso la interacción de implementaciones públicas y privadas.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Figura: Integración de UDDI en los servicios web Como se muestra en la figura, UDDI encaja en una pila de servicios web en general y es un componente clave de su fundación, lo que permite la creación, la especificación y la invocación de servicios web.

RECUERDe Hay más de 300 empresas (muchas ellas muy importantes) involucradas en el proyecto UDDI, esto hace idea de su relevancia..

UDDI se basa en una capa de transporte de red y una capa de mensajería XML basados en SOAP. Los lenguajes de descripción de servicios, tales como WDSL (Web Services Description Language) proporcionan un vocabulario XML uniforme para su uso en la descripción de servicios web y sus interfaces. UDDI es un estándar básico en los servicios Web que tiene como objetivo ser accedido por los mensajes de los servicios distribuidos y dar pie a documentos WSDL. Los documentos WSDL describen todos los requisitos de protocolo y los formatos del mensaje que interactúan con los servicios Web del catálogo de registros.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Podemos decir que UDDI es un lenguaje independiente de XML (Plataforma de marcado extensible) que se basa en el registro por el que las empresas en todo el mundo publican a través de Internet. Es un mecanismo que registra y localiza las aplicaciones de servicios web. Esto permite a las empresas publicar anuncios de servicios y descubrirse unas a otras, y así definir cómo los servicios y aplicaciones software interactúan en Internet. UDDI fue propuesto en principio como un estándar básico de servicios web, y está diseñado para ser interrogado por mensajes en arquitecturas distribuidas. Facilita también el acceso a WSDL (Web Services Description Language). Se escribió en el año 2000, en un momento en el que los autores tenían una visión en de que los consumidores de servicios web se vinculaban con los proveedores por un sistema de intermediación pública, privada o dinámica. En esta visión, cualquier persona o empresa que necesitara un servicio, como por ejemplo la autenticación para una tarjeta de crédito, podría ir a su agente de servicio y seleccionar un servicio de apoyo para un interfaz de servicio, y cumplir así otros criterios. El nodo UDDI operado públicamente o corredor sería imprescindible para todos: Consumidores y agentes públicos o abiertos, que sólo volverían servicios enumerados para el descubrimiento público por otros. En cambio, para un productor de servicios, se conseguiría una buena colocación en la intermediación, apoyándose en metadatos de los índices autorizados. UDDI es un pilar central de la infraestructura en servicios web WS-I (interoperabilidad de servicios Web). Las especificaciones UDDI admiten un Registro universal de Empresas de acceso público en las cuales el sistema de denominación se construye alrededor del servicio UDDI central. Los sistemas UDDI son muy comunes dentro de las empresas. Estas los utilizan para enlazar dinámicamente sistemas de cliente para implementaciones. Sin embargo, gran parte de estos metadatos de búsqueda permitido en UDDI no se utilizan para esta función relativamente simple. El registro público UDDI funciona un poco como el servicio de nombres de dominio de Internet (DNS). Las empresas pueden inscribirse en cualquiera de los anfitriones-IBM, HP, SAP o Microsoft, y la información que proporcionan se coloca en la base de datos en el lugar que la acoge. A intervalos regulares, al menos todas las noches, toda la información se coloca en una de las bases de datos del sitio de acogida se replica en las otras bases de datos del sitio de acogida, lo que garantiza que todos ellos son mantenidos de forma síncrona. Los usuarios que solicitan datos sobre un negocio pueden recibir la misma información acerca de un negocio registrado de cualquiera de las bases de datos de acogida. Cuando se

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

actualizan los datos la empresa debe volver al sitio original al que se colocaron los datos y ejecutar la función de actualización. Por razones obvias, la seguridad es la principal preocupación de los miembros UDDI.org. Las empresas están autorizadas para actualizar la información de uno de los operadores, por lo que deben acudir siempre a la operadora original para cambiar o eliminar la información que publican. Las empresas que deseen inscribirse en UDDI deben primero obtener la autorización para hacerlo y deben ser aprobadas por, al menos, uno de los operadores. La aprobación significa enviar a la empresa un token de autorización que permite iniciar sesión en el sitio UDDI y almacenar o para actualizar datos. La autorización para actualizar el registro está a cargo de los operadores de forma individual, la información de inicio de sesión de un operador no funcionar para otro. Para todos los propósitos prácticos, alguien que registre información con UDDI tiene que elegir uno de los operadores y aferrarse a ese operador. Otra preocupación primaria es la calidad, o la validez, de los datos. Alguien tiene que asegurarse de que el negocio que se registra es un negocio real, que el nombre de la empresa, número de identificación, información de la categoría, número de teléfono, página web y dirección de la calle son correctas, y que la categoría de negocio y la información geográfica son correctas. UDDI v2 está configurado para permitir a terceros hacer esto y no validar los datos hasta realizar estas verificaciones. UDDI tiene dos partes principales: el registro y el descubrimiento. La parte de registro significa que las empresas pueden publicar información en UDDI que otras empresas pueden posteriormente buscar y descubrir (que es la otra parte). Las empresas y los individuos interactúan con UDDI mediante el uso de las API de SOAP o una de las interfaces de usuario proporcionada por los operadores o de otros proveedores de servicios Web. Los operadores UDDI envían descripciones WSDL de sus servicios web para el registro y el descubrimiento. UDDI proporciona varios archivos WSDL para los servicios de descubrimiento de registro y, utilizan su propio formato de documento XML.

RECUERDe La seguridad en la transmisión y almacenaje de datos es un tema crítico en el sistema UDDI.

Algunos UDDI API de SOAP son utilizados para insertar la información en el registro, mientras que otros se usan para navegar y recuperar información específica del registro. UDDI API requieren un subconjunto específico de SOAP; ya que UDDI no utiliza el formato de serialización opcional y muchas otras características definidas en la especificación SOAP. MODELADO DE DATOS UDDI Información de registro UDDI se compone de los siguientes cinco tipos de estructuras de datos:

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––businessEntity, la estructura de nivel superior, que describe la empresa, entidad para la que se registra la información. Las otras estructuras están relacionadas a través de referencias de esta. ––businessService, se publica el nombre y la descripción del servicio. ––bindingTemplate, la información sobre el servicio, incluyendo una dirección de punto de entrada para acceder al servicio. ––tModel, es una huella digital, o la recolección de información que identifica unívocamente la especificación del servicio. Esta estructura de datos también admite búsquedas de alto nivel. ––publisherAssertion, una estructura de puesta en relación de asociación de dos o más estructuras BusinessEntity de acuerdo con un tipo específico de relación, tal como filial o departamento. Un generador UUID utiliza un algoritmo complejo, que tiene en cuenta factores, tales como la fecha y la hora actuales, para producir un número hexadecimal que cuente con una garantía de singularidad. Las probabilidades de producir un número duplicado, en otras palabras, son prácticamente cero.

EJEMPLO Un ejemplo de UUID es: C90D731D-777D-4130-9DE3-5303371170C2. UDDI está diseñado para aceptar virtualmente cualquier tipo de descripción de servicios Web, incluyendo idiomas de descripción específicos de la industria. WSDL proporciona un lenguaje de propósito general para describir las interfaces, enlaces de protocolo y los detalles de implementación, siendo complementario de UDDI, pero no lo requiere. En otras palabras, las estructuras de datos establecidas por UDDI son anteriores a WSDL además de estar diseñado para ser completamente extensible para contener y para hacer referencia a cualquier tipo de acuerdo de contrato entre dos partes en un intercambio distribuido o efectuado o en la red de la información. Las estructuras de los esquemas XML definidos por UDDI no prescriben cualquier formato de almacenamiento subyacente. Es decir, la forma en que los datos se envían a un operador UDDI puede ser diferente de la forma en la que se almacena. Esto no es relevante, siempre y cuando la estructura XML se pueda reconstruir a partir del formato de almacenamiento de base de datos persistente. Esto es consistente con el enfoque XML sobre la independencia de datos, que se basa en la cartografía de dentro y fuera de las

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

estructuras de XML, que son independientes de la forma en que se representan los datos de los programas y bases de datos subyacentes. LA ENTIDAD BUSINESS La estructura de alto nivel businessEntity es el punto de partida de la mayoría de las consultas. Dependiendo del tipo de información que se busque las consultas por lo general también incluir uno o más identificadores o claves de categoría. Las consultas también pueden comenzar con otras entidades. LA PLANTILLA BINDING La plantilla de enlace (BINDING) proporciona información para acceder físicamente a un servicio Web u otro tipo de servicio registrado en UDDI. Una empresa puede registrar varias plantillas de unión para un determinado servicio comercial e identificar los diferentes puntos de acceso para ese servicio, si se requiere. Los tipos de punto de acceso de la estructura bindingTemplate incluye las siguientes direcciones URL: ––mailto: ––http: ––https: ––ftp: ––fax: ––phone: ––other:

RECUERDe Se debe asegurar de usar la sintaxis apropiada tras las claves binding.

La información que sigue a cada tipo tiene que tener el formato correcto para dicho tipo. Por ejemplo, el mailto: tipo que requiere una dirección válida de e-mail, el tipo http:, requiere un formato de URL válido, y el tipo phone: un número de teléfono válido. De este modo, un negocio puede proporcionar el tipo de acceso adecuado para diversos mecanismos de contacto de los mismos, o diferentes servicios. No hay validación se hace para asegurarse de que existe algo en el otro extremo de la dirección, en la mayoría de los casos esto no es más que una parte de la preocupación general acerca de la validez de los datos de UDDI. EL TMODEL En términos UDDI, un tModel es el mecanismo utilizado para el intercambio de metadatos de un servicio web, tales como la descripción del servicio Web o un puntero a un archivo WSDL. La definición UDDI de un servicio Web es mucho más amplia que los ejemplos que se muestran en este libro. El registro UDDI pretende ser lo suficientemente general como para soportar cualquier tipo de servicio accesible a través de Internet. Así que por eso UDDI no utiliza sólo

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

WSDL. Si WSDL se vuelve popular y ampliamente aceptado, tal vez la mayoría de tModels usarán WSDL. Por ahora hay otros protocolos pueden ser considerados servicios Web, por definición, al menos en términos de lo que es aceptable para poner en un tModel. UDDI también es anterior WSDL. WSDL se ha utilizado como una parte integral de una definición de servicios Web, pero UDDI define un servicio Web más ampliamente y de forma algo diferente. UDDI define los servicios Web como servicios técnicos para su uso privado o general. Como ejemplos tenemos la compra de servicios, servicios de catálogo, servicios de búsqueda, y el envío o los servicios postales expuestas sobre los transportes, tales como HTTP o por correo electrónico. Los protocolos Business-to-business, tales como RosettaNet y ebXML, se pueden considerar como servicios Web, aunque ninguno de ellos utiliza WSDL. Un tModel es más o menos el equivalente de UDDI en WSDL, pero es más amplio y puede incluir punteros y referencias a servicios que utilizan direcciones distintas URLs y permitir transportes que no sean SOAP. A cada tModel se le asigna una clave UUID por operador cuando se almacenan inicialmente. La información descriptiva almacenada asociada con la estructura principal tModel tiene la intención de ayudar a asegurar que se puedan identificar los servicios duplicados. Un tModel está diseñado para identificar unas especificaciones únicas de interfaz para los servicios Web, y también para ayudar a permitirles ser detectables. Un tModel proporciona puntos de entrada alternativos en las estructuras de datos UDDI para descubrir servicios específicos y para vincularlos con las empresas que los proveen. Es también probable que haya varias empresas que cuenten con el mismo servicio. Una vez que estén establecidos los servicios Web no van a ser únicos o personalizados a un negocio particular. Los tModels, que representan los metadatos con clave acerca de un servicio, están destinadas a garantizar la compatibilidad de las interfaces o servicios a través de múltiples entradas del registro. Para que sea útil, un tModel debe contener un puntero a un lugar donde el usuario puede obtener más información sobre el servicio. Otra función prevista de tModels es la de ayudar a realizar búsquedas de registros para un servicio específico. Por ejemplo, supongamos que una empresa quiere acceder a un servicio de catálogo o un servicio de validación de tarjetas de crédito. El apoyo UDDI APIs busca definiciones de servicios específicos y lista las empresas que ofrecen servicios compatibles. Para obtener un valor de la clave tModel asociado con el tipo de servicio que se desea, puede buscar el UDDI de las empresas que lo ofrecen.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Un tModel debe ser una entidad independiente y separada, referenciable por una o más empresas que ofrecen un determinado servicio Web. En otras palabras, los diseñadores UDDI suponen que un servicio web podría ser un servicio genérico o de propósito general que más de una empresa o entidad proporcionen. Por lo tanto un tModel no es específico para una empresa o entidad dada, siendo una estructura de búsqueda en su propio derecho, vinculada a una o más empresas o entidades. Lo contrario también es cierto: una empresa o una entidad puede hacer referencia a varios tModels. A corto plazo, parece probable que la mayoría de las empresas presenten servicios Web únicos, pero con el tiempo, parece probable que algunas empresas servirán los servicios para otras empresas, y tal vez varias empresas se involucren en el negocio de servicios de alojamiento Web.

RECUERDe tModel se utiliza para el intercambio de metadatos en UDDI.

UDDI define tModels para buscar sus propios servicios, incluyendo tModels que definen la investigación y las API de editor para interactuar con las API de registro de mantenimiento y taxonomía. Por ejemplo, tModels se definen para NAICS, UNSPSC, y taxonomías de clasificación ISO 3166. Estos ejemplos ilustran el uso de un tModel como una definición de espacio de nombres abstracto. APIs SOAP El API de UDDI se divide en aquellos que registran la información y aquellos que buscan la información en el registro. El API de registro se utiliza por los editores, es decir, por las empresas y/ o agentes comerciales que envían solicitudes para introducir información en UDDI. La búsqueda de las API de los consumidores utilizan el registro para encontrar información de negocios por categorías y para recuperar información detallada acerca de una o más empresas individuales que cumplan con los criterios de búsqueda. En general, las API de registro de la información proporcionan un ahorro en la actualización de la información actual y al borrar la información antigua. Una API para la búsqueda de información permite devolver información resumida acerca de un grupo de entradas o devolver información completa para una entrada específica. Cualquiera que desee utilizar cualquier editor de las API debe primero solicitar un token de autenticación de un operador. Cada operador utilizan su propio mecanismo para distribuir los tokens de autenticación, de modo que en la práctica, un editor interactúa con un solo operador. Por tanto, un editor se registre con un operador individual y se otorga credenciales para iniciar la sesión y utilizar la API de editor. El API de editor se deben utilizar a través de HTTPS (v3.0 SSL) para el cifrado en el cable.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

EJEMPLO El siguiente es un atributo de la API v2 para indicar que se están utilizando las API v2: xmlns=”urn:uddi-org:api_v2”. El publicador y el consumidor de APIs de SOAP están disponibles sólo a través de HTTP POST. Un API de soporte Unicode requiere el uso de la codificación UTF-8. Los editores pueden registrar empresas y otras descripciones usando múltiples lenguajes. CONSULTA DE APIs Utilizando uno o más criterios de búsqueda, los APIs permiten navegar por la información de registro y obtener información específica acerca de una empresa registrada, o una especificación de servicio una vez que se obtiene la clave única. Se usan varios criterios de búsqueda para encontrar uno o varios registros coincidentes. Por lo general, la búsqueda se inicia con una solicitud genérica que devuelve una lista de empresas que responden a una determinada categoría o cadena de identificación. Hay otras API usadas para devolver el servicio y/ o información de contacto de un negocio específico dado. Las consultas pueden realizarse usando combinaciones de nombres de empresas o identificadores, o usando información de cierta categoría, como el tipo de industria o la ubicación geográfica. Existen las siguientes consultas de las API: ––find_binding, localiza la información de enlace específica y devuelve un mensaje bindingDetail que incluye el punto de acceso, según el tipo de URL, para el servicio ––find_business, es la API principal para la búsqueda inicial, se encuentra información acerca de uno o más negocios y devuelve en un mensaje la lista de negocios ––find_relatedBusinesses, encuentra negocios relacionados con la clave de negocio y devuelve un mensaje con la lista de negocios, empresa subsidiaria u otros departamentos de una empresa determinada ––find_service, encuentra y devuelve servicios específicos enumerados para un negocio específico ––find_tModel, encuentra y devuelve estructuras tModel, proporcionando una forma de buscar en el registro para los servicios de búsqueda

RECUERDe La API diferencia entre los que introducen y los que buscan información.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––get_bindingDetail, encuentra y devuelve información bindingTemplate suficiente para invocar un servicio ofrecido por una empresa específica, devuelve un mensaje bindingDetail. ––get_businessDetail, consigue todos los detalles de un negocio registrado específica y devuelve un mensaje businessDetail, generalmente una segunda consulta una vez a la lista de empresas que coincidan es devuelto por una consulta previa ––get_businessDetailExt, encuentra y devuelve un mensaje de businessDetailExt extendida; que es el mismo que get_businessDetail pero con información extendida definido de la v1 ––get_serviceDetail, encuentra y devuelve toda la información acerca de un determinado conjunto de información registrada de servicios empresariales, devuelve un mensaje serviceDetail. ––get_tModelDetail, obtiene detalles completos de un conjunto de datos registrados tModel; devuelve un mensaje de tModelDetail. Una consulta sobre las API no devuelve ningún valor si no hay un resultado de las claves de búsqueda. El API incluye una opción para establecer un número máximo de filas que se devolverán y una indicación de que existen más filas que se pueden devolver. Hay también una “búsqueda comodín” en el parámetro de API find_business. El API find_business, la API principal de búsqueda, permite buscar a través de nombre, identificadores, categorías o referencias tModel y también puede buscar direcciones URL. Se pueden solicitar hasta cinco claves en una misma búsqueda. Por lo general, la primera búsqueda devuelve una lista de partidos a uno o más criterios. La API find_service se puede utilizar para encontrar los servicios específicos que cumplen con criterios específicos. Se puede navegar por su nombre en un servicio, obtener el UUID para el servicio, y pasarlo de nuevo a la API find_service para obtener la entrada de servicio específico. El API de unión-detalle obtiene la información que necesita para llamar a un servicio. La información puede ser almacenada en caché y refrescarse cuando se requiera. APIs de extensión están disponibles para dotar de compatibilidad cuando se añaden cosas. Por ejemplo, get_businessDetailExt devuelve la misma información que get_businessDetail, y más información.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

A veces, los resultados de una consulta alimentan la entrada para otra consulta. Por ejemplo, get_businessDetail podría devolver una clave tModel de la tModelInstanceInfo asociado con la información de negocio, y a continuación la siguiente llamada puede utilizar la salida de tModel para obtener un cierto registro tModel. Por último, el tModel puede vincularse a una o más estructuras de entidad empresarial para obtener la información necesaria para acceder al servicio.

RECUERDe Hay numerosas sentencias que permiten realizar consultas. Es necesario conocerlas bien para poder realizarlas de forma óptima.

No se requiere autenticación para las API de consulta. EDITOR DE APIs Un editor de API se utiliza para almacenar, actualizar y eliminar u ocultar la información en el registro. Al igual que todas las API que almacenan los datos, los datos almacenados se someten posteriormente a operaciones de consulta. En otras palabras, los datos tiene que ser almacenado para permitir las consultas que permitan producir resultados significativos. Pasando una clave UUID en blanco indica que los datos están siendo almacenados por primera vez. Una información nueva o diferente con el mismo UUID reemplazará la antigua. Una información sobre la relación se puede cambiar al hacer cambios en las claves que definen la información de la relación. Cuando se registran businessEntities, el operador crea una dirección URL que se puede utilizar para obtener el elemento que se está registrado mediante el uso de una operación HTTP GET. El editor de APIs permite cualquier clasificación de número de códigos para ser almacenados en un negocio. Las clasificaciones incluyen códigos de categoría de un negocio o su información geográfica. Al registrar la información, un negocio o un agente tiene la opción de pedir la información de categorización para un chequeo o para permanecer sin control, es decir, para UDDI se permite aceptar los datos de categorización de la empresa o los que el agente quiera almacenar. Los operadores UDDI esperan que terceros desarrollen y proporcionen los servicios de comprobación. A continuación se presentan algunas órdenes para el editor de API:

RECUERDe Los editores de API gestionan la información que hay en el registro.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

––add_publisherAssertions, añade afirmaciones de una relación, o pone una o más empresas en una relación, tales como los departamentos o subsidiarias. ––delete_binding, elimina una bindingTemplate. ––delete_business, elimina un businessEntity registrado. ––delete_publisherAssertions, elimina la información de relación. ––delete_service, elimina un businessService registrado. ––delete_tModel, esconde un tModel ya que las referencias existentes podrían utilizarlos, tModels no se eliminan. Los TModels ocultos pueden ser reactivados mediante la invocación del tModel guardado con los datos originales. ––discard_authToken, informa al operador con el que la empresa o el agente se registra, que el token de autenticación no es válida, es decir, la empresa o el agente desecha el token para no usarlo nunca más. ––get_assertionStatusReport, genera un informe, sobre todo para el uso del operador, para revisar y ayudar a validar las relaciones registradas. ––get_authToken, solicita un token de autenticación de un sitio de operador, un requisito previo para el uso de otras API editor. ––get_publisherAssertions, listas de afirmaciones activas para un editor determinado para definir la información de relación. ––get_registeredInfo, se presenta un resumen de toda la información registrada a nombre de un usuario específico, esto es útil para el operador, y basada en token de autenticación. ––save_binding, almacena uno nuevo o actualiza un bindingTemplate existente. ––save_business, almacena uno nuevo o actualiza un businessEntity existente. ––save_service, almacena uno nuevo o actualiza un businessService existente. ––save_tModel, almacena uno nuevo o actualiza un tModel existente. ––set_publisherAssertions, salva nuevas afirmaciones o reemplazar las existentes, precisa todos los elementos. Los operadores pueden imponer límites de espacio para evitar que las empresas se registren demasiada información. Estos límites forman parte de la negociación con el operador que se elija. Cada bindingTemplate registrado debe contener un serviceKey válido que corresponde a una businessService registrada y controlada por la misma cuenta, es decir, con la misma clave de autenticación. Es posible cambiar una relación bindingTemplate, sin embargo si un businessService o bindingTemplate está en más de un businessService, las relaciones se determinan por el orden de procesamiento: la operación final redefine las relaciones de la información registrada.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

La información vinculante se puede mover de una relación a otra, aunque UDDI no proporciona ninguna validación de los cambios resultantes. En otras palabras, UDDI no puede validar o hacer cumplir los cambios en las relaciones entre empresas y servicios. UDDI permite que las relaciones que se definen entre las empresas, pero no tiene manera de conciliar o comprobar las entradas duplicadas para el mismo negocio. La API validate_values es también parte de la API de edición, pero está reservada para el uso del operador. El operador utiliza el API de llamar a un tercero con el que se ha acordado en el uso de un servicio de validación de taxonomías categorización adicionales y esquemas de identificación. Esto permite que la categorización de datos UDDI se valide después de una operación de actualización en los nodos UDDI cuando se requiera más información o que se guarde la existente. ESCENARIO DE USO Imagina que la Compañía Reynholm quiere registrar su información de contacto, descripción del servicio, y la información de acceso al servicio en línea con UDDI. Para esto deberá seguir los siguientes pasos: 1. Elegir un operador con el que trabajar. Cada operador tiene diferentes términos y condiciones para la autorización de acceso a la réplica del registro y puede proporcionar un valor añadido en los servicios básicos UDDI. Además, siempre que sea necesario actualizar o modificar los datos que ha registrado, tiene que volver a la operadora con la que ha contratado. 2. Generar (u obtener de otro modo) el cliente UDDI, tales como los servicios prestados por los operadores. 3. Obtener un elemento de autenticación del usuario. 4. Registrar la información sobre el negocio. Incluir toda la información que pueda ser útil para aquellos que la busquen. 5. Liberar el elemento de autenticación. 6. Utilizar la API de consulta para evaluar la recuperación de la información, incluida la información de la plantilla vinculante, para garantizar que una persona que obtiene se puede utilizar con éxito para interactuar con su servicio. 7. Completar la información tModel por si alguien quiere buscar un determinado servicio y encontrar su negocio como uno de los proveedores de servicios. 8. Actualización de la información, si es necesario, para reflejar cambios en la información de contacto de negocios y nuevos detalles del servicio, obtener y liberar un nuevo elemento de autenticación del operador cada vez.

RECUERDe Siguiendo unos sencillos e intuitivos pasos podremos tener nuestro servicio en línea con UDDI.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

ACTUALIZAR EL REGISTRO Después de obtener un elemento de autenticación de uno de los operadores (por ejemplo, de Microsoft) los desarrolladores de Industrias Reynholm decidir qué información se publica en el registro y el uso de una de las herramientas proporcionadas por Microsoft UDDI. Si es necesario, los desarrolladores también pueden escribir una aplicación Java, C #, VB.NET o programa para generar los mensajes SOAP adecuados.

EJEMPLO POST /save_business HTTP/1.1 Host: http://www.reynholm.co.uk/ Content-Type: text/xml; charset=”utf-8” Content-Length: nnnn SOAPAction: “save_business” <?xml version=”1.0” encoding=”UTF-8” ?> <Envelope xmlns=”http://schemas/xmlsoap.org/soap/envelope/”> <Body> <save_business generic=”2.0” xmlns=”urn:uddi-org:api_v2”> <businessKey=””> </businessKey> <name> Reynholm Inc. </name> <description> Una industria puntera en servicios muy variados con un excelente departamento de IT. </description> <identifierBag> ... </identifierBag> ... </save_business> </Body> </Envelope>

RECUERDe La actualización del registro es necesaria para incluir la nueva información.

Este ejemplo muestra un mensaje SOAP que solicita el registro de una entidad de negocios UDDI para Industrias Reynholm. El elemento clave está en blanco debido a que el operador genera automáticamente la clave UUID para la estructura de datos. La mayoría de los campos se omiten ya que sólo se trata de un ejemplo

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

RECUPERAR INFORMACIÓN Después de que Industrias Reynholm actualiza su entrada UDDI con la información pertinente, las empresas que quieran convertirse en distribuidores de Industrias Reynholm pueden buscar información de contacto en el registro UDDI y obtener las descripciones de los servicios y de los puntos de acceso para los dos servicios web que www.reynholm.co.uk publica sobre los pedidos: los pedidos de servicios y las órdenes de mantenimiento.

EJEMPLO POST /get_businessDetail HTTP/1.1 Host: www.reynholm.co.uk Content-Type: text/xml; charset=”utf-8” Content-Length: nnnn SOAPAction: “get_businessDetail” <?xml version=”1.0” encoding=”UTF-8” ?> <Envelope xmlns=”http://schemas/xmlsoap.org/soap/envelope/”> <Body> <get_businessDetail generic=”2.0” xmlns=”urn:uddi-org:api_v2”> <businessKey=”C90C732D-777D-4131-9DC3-53A3371170C2”> </businessKey> </get_businessDetail> </Body> </Envelope>

Este ejemplo ilustra una solicitud SOAP para obtener información detallada sobre el negocio de Industrias Reynholm. Una vez conocido el UUID, o llave, para el negocio específico que se ha registrado, se puede usar en el API get_businessDetail para devolver información específica sobre ese negocio. Normalmente, para refinar la búsqueda inicial, es posible enviar un mensaje a UDDI contiene el nombre de empresa o un nombre parcial con un comodín para tratar de obtener ningún resultado. USANDO WSDL con UDDI El modelo de datos UDDI define una estructura genérica para almacenar información acerca de un negocio y los servicios Web que publica. El modelo de datos UDDI es completamente extensible, incluyendo varias estructuras de repetición de secuencia de información. A pesar de que fue diseñado y especificado antes

RECUERDe UDDI incluye sentencias que permiten la recuperación de datos contenidos en el sistema.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

de WSDL, UDDI tuvo la previsión de permitir incorporar WSDL si así se desea. UDDI está diseñado para que funcione con cualquier descripción de servicios lingüísticos. UDDI incluye estructuras de datos adecuadas para almacenar enlaces de protocolos y servicios de red. WSDL está representado en UDDI utilizando una combinación de businessService, bindingTemplate, y la información tModel. Al igual que con cualquier servicio registrado en UDDI, la información genérica sobre el servicio se almacena en la estructura de datos businessService, y la información específica de cómo y dónde se accede al servicio se almacena en una o más estructuras bindingTemplate que estén asociadas. Cada estructura bindingTemplate incluye un elemento que contiene la dirección de red del servicio y se ha asociado con él una o más estructuras tModel que describen e identifican de forma exclusiva el servicio. El servicio de información de negocio describe los servicios Web. Una plantilla de enlace contiene información técnica acerca de un punto de entrada de servicio y especificaciones de construcción. El tModel contiene descripciones de las especificaciones de los servicios o taxonomías, que son la base de una “huella dactilar” para la especificación del servicio. El punto de acceso en la plantilla de la unión da la dirección de punto final del servicio Web. Es posible almacenar la información WSDL en UDDI de varias formas diferentes, dada la flexibilidad y extensibilidad de UDDI. Los autores de las mejores prácticas recomiendan dividir la información reutilizable de la información específica de un determinado servicio. Aunque WSDL no se requiere para registro de UDDI, el kit de herramientas de IBM incluye la utilidad de registrar en WSDL UDDI, dividiendo en dos partes principales para el ajuste apropiado en UDDI: interfaz de servicio y la implementación del servicio. La división se recomienda para que la información común a una cierta categoría de negocio (tales como los formatos de mensajes y tipos de datos, tipos de puertos, y los enlaces de protocolo) se encuentren en la parte reutilizable, mientras que la información sobre un punto final determinado servicio, es decir, el puerto definición, se encuentre en la parte de la implementación del servicio. Cuando se utiliza UDDI para almacenar la información de WSDL (o enlaces a archivos WSDL), el tModel debe hacer referencia a la convención usando el tipo wsdlSpec, lo que significa que el elemento overviewDoc se identifica claramente como apuntando a una definición de interfaz de servicio WSDL.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

Para UDDI, los contenidos WSDL se dividen en dos elementos principales el archivo de interfaz y la implementación de archivos divididos de manera similar a la definición abstracta de un servicio a partir de su aplicación física en un cierto transporte. UDDI PARA USO PRIVADO UDDI se puede utilizar en el interior del servidor de seguridad como un directorio de servicios web internos, o como puntos de integración interna. Las aplicaciones pueden envolverse con tecnologías de integración XML y registrarse en el UDDI interno, incluyendo las extensiones al modelo de datos UDDI que tengan sentido o que sean aplicables a situaciones de uso interno. Al utilizar la tecnología de servicios Web para integrar aplicaciones internas, el registro de los puntos de integración en un registro común hace que sea más fácil para los otros departamentos descubrir posteriormente aplicaciones listas para ser integradas, al igual que se hace en la Web. SOPORTE UDDI PARA SOAP Y UNICODE SOAP UDDI v1 requiere un valor de cadena vacía para el campo SOAP del encabezado de HTTP Action. Sin embargo v2 se permite que se haga referencia en el mensaje SOAP al campo para incluir el nombre de la API UDDI.

EJEMPLO SOAPAction: “save_business” UDDI no admite encabezados SOAP. Sin embargo, a las implementaciones de UDDI se les permite ignorar cualquiera de las cabeceras en el mensaje SOAP, siempre y cuando no incluyan el atributo mustUnderstand, ya que se requiere un procesador SOAP para entender la cabecera dentro de la cual se especifica dicho atributo. Si un operador de UDDI recibe un mensaje SOAP que incluye una cabecera relativa a SOAP, el operador va a rechazar el mensaje y devolver un error de SOAP mustUnderstand. En consecuencia, el atributo agente de un encabezado SOAP no es compatible. UDDI no admite la codificación opcional de SOAP. Cualquier mensaje SOAP que contiene el atributo de espacio de nombres de codificación SOAP fallará y devolverá un error SOAP, un código de error de E_unsupported y un texto errinfo de SOAP que describe el error.

RECUERDe UDDI, pese a ser una tecnología más antigua, se anticipó y permite el uso de WSDL en sus instrucciones.

RECUERDe UDDI es también adecuado para el almacenamiento de los metadatos dentro del firewall.

Unidad didáctica 1. Arquitecturas distribuidas orientadas a servicios

SOAP solicita y responde los documentos enviados y recibidos de operadores UDDI; utiliza el espacio de nombres de SOAP predeterminado sin un prefijo XML.

EJEMPLO RECUERDe UDDI incluye funciones específicas para el uso de SOAP, UDDI incluyendo cómo se trata el encabezado de acción SOAP, y prohibiendo el uso de encabezados SOAP y la codificación opcional de SOAP.

xmlns=”http://schemas/xmlsoap.org/soap/envelope/”

UNICODE Los operadores UDDI optan en muchas ocasiones por utilizar la codificación UTF-8 para todas las solicitudes y requerirá que todos los sitios de operador soporten todos los caracteres definidos por el estándar Unicode para el apoyo en varios idiomas. Los mensajes pueden contener texto descriptivo en varios idiomas sobre la información empresarial que debe ser registrado en varios idiomas.

RECUERDe El uso de unicode es necesario para todas las solicitudes.

02 Programación de servicios web en entornos distribuidos 2.1 Componentes software para el acceso a servicios distribuidos 2.1.1 Definición de servicios 2.1.2 Generación automática de servicios 2.2 Programación de diferentes tipos de acceso a servicios 2.2.1 Servicios basados en publicación/suscripción 2.2.2 Servicios basados en repositorios 2.2.3 Servicios accesibles desde agentes de usuario 2.2.4 Proveedores y consumidores de servicios en entorno servidor 2.3 Herramientas para la programación de servicios web 2.3.1 Comparativa 2.3.2 Bibliotecas y entornos integrados (frameworks) de uso común

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

2. PROGRAMACIÓN DE SERVICIOS WEB EN ENTORNOS DISTRIBUIDOS Los servicios Web están cambiando la manera en que pensamos acerca de los sistemas de software distribuidos, pero hay un límite en lo que pueden hacer. Los servicios web proporcionan una capa de abstracción por encima de los sistemas software existentes, como servidores de aplicaciones, CORBA, .NET servidores, mensajería y aplicaciones empaquetadas. Servicios web funcionan a un nivel de abstracción similar a Internet y son capaces de soportar cualquier sistema operativo, plataforma de hardware, o lenguaje de programación, así como la web. A diferencia de los sistemas de computación distribuida ya existentes, los servicios Web se adaptan a la Web. Siendo el protocolo de red predeterminado HTTP. Las tecnologías de computación distribuida más actuales incluyen el protocolo de comunicaciones como parte de su ámbito de aplicación. Con los servicios Web, el protocolo de comunicaciones mueve los datos Web en todo el mundo. Las nuevas aplicaciones son posibles cuando todo es el servicio Web está habilitado. Una vez que se habilita el servicio Web, todo tipo de nuevos paradigmas empresariales, grupos de discusión, foros interactivos y modelos editoriales surgirán para aprovecharse de esta nueva capacidad. Los proveedores de software y hardware se están apresurando por igual en lanzar productos de servicios Web en el mercado. La adopción generalizada de las normas fundamentales representa un avance significativo en la industria. Las aplicaciones realmente se pueden construir utilizando una combinación de componentes de múltiples proveedores. Los especialistas están especializándose en prestar servicios en las áreas de seguridad, coordinación de transacciones, procesamiento de facturas, traducción, transformación de documentos, registros y repositorios, contabilidad, elaboración de informes y cálculos especializados. Las aplicaciones que se construyen en cualquier lugar, en cualquier momento y en cualquier sistema se puede aprovechar de los componentes creados previamente, lo que acelera el tiempo de comercialización y reducir los costos. Mientras tanto, ebXML, que creó y mantiene un rumbo separado, sigue para resolver problemas difíciles para los socios corporativos de comercio que están estableciendo sistemas de facturación automatizados compras y cadena de suministro, las grandes transferencias de documentos electrónicos, y las comunidades de negocios que comparten objetivos comunes. El legítimo heredero de EDI, ebXML es fácil de usar y de bajo costo.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

La alternativa de las empresas automatizar sus interacciones con otras empresas. Con ebXML, los sistemas internos de la empresa están conectados a los sistemas informáticos de sus socios comerciales, contratistas y colaboradores comerciales. El valor inherente a estos sistemas es por lo tanto mucho mayor, ya que se convierten en parte esencial de un sistema informático, la información esencial que fluye libremente a través de las fronteras corporativas en lugar de adherirse al interior de ellos. Existe una considerable superposición entre las tecnologías de servicios Web básicos y ebXML. La convergencia entre los dos se basa en la adopción común de SOAP como el transporte y en la capacidad de los respectivos registros para compartir datos. Las especificaciones ebXML incluyen muchos requisitos de calidad de servicio que aún no están incluidas en los servicios web, como la integridad del mensaje y su no rechazo, la mensajería fiable del flujo de procesos de negocio, y la negociación del protocolo. Es posible una mayor convergencia, ya que las principales tecnologías de servicios Web comienzan a adoptar las propuestas en estas áreas tecnológicas adicionales. El desacuerdo sigue siendo el mejor método para definir estas tecnologías adicionales en el contexto de los servicios Web. Una vez que las normas fundamentales son adoptadas ampliamente, la discusión se desplaza a la necesidad para hacer frente a los problemas de calidad de servicio. Se necesitan seguridad, transacciones, flujo de procesos y estándares de mensajería fiable, y algunos de ellos están más adelantados que otros. El poder de XML impulsa tecnologías de servicios Web en general, si se trata de las normas fundamentales, las tecnologías adicionales o ebXML. XML también resuelve el problema de la independencia de los datos para los lenguajes de programación, sistemas middleware y sistemas de gestión de bases de datos. Anteriormente, los tipos y estructuras de datos eran específicos para estos tipos de software, y los intentos de definiciones comunes, como CORBA IDL, ganaron aceptación de forma limitada. XML está bien en su camino a convertirse en una tecnología tan bien establecida como su hermano, HTML. Las tecnologías de servicios Web descritos en este capítulo son creados utilizando aplicaciones de XML de una manera u otra. XML no es un elemento sino una variedad de tecnologías en sí mismo, que abarca datos de la instancia, así como escribir, la estructura y la semántica de información relacionada con los datos. XML no sólo describe los datos de forma independiente, sino que también contiene información útil para el mapeo de los datos dentro y fuera de cualquier sistema de software o lenguaje de programación.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

La transformación de datos hacia y desde XML es esencial, ya que XML es lo suficientemente flexible como para dar cabida a cualquier tipo de datos y su estructura e incluso crear otros nuevos, si es necesario. Cuando todos los programas y sistemas de software sean un servicio Web habilitado, el mundo de la computación distribuida será muy diferente de lo que es hoy.

RECUERDe Los servicios web se usan en múltiples áreas y dotan de abstracción de la propia aplicación.

2.1 Componentes software para el acceso a servicios distribuidos El Simple Object Access Protocol (SOAP) es quizás la más importante de todas las tecnologías de servicios Web. Es cierto que los servicios Web no existirían sin una manera de representar los datos de forma abstracta y publicar las definiciones de interfaz, pero SOAP logra sin duda el aspecto más importante de los servicios Web: transportar los datos de un lugar a otro a través de la red. Con la Web emergiendo como la red más importante del mundo y XML emergiendo como principal formato de representación de datos en el mundo, tiene sentido que los servicios Web de transporte de datos requieran una combinación de los dos. Esto es exactamente lo que ofrece SOAP. SOAP permite que el remitente y el receptor de documentos XML a través de la Web usen un protocolo de transferencia de datos común para una eficaz comunicación en red. En relación con la Web, SOAP es una especie de extensión del protocolo de transferencia de hipertexto (HTTP), que dispone de mensajes XML. En lugar de utilizar HTTP para solicitar una página HTML para ser descargada y visualizada en un navegador, SOAP envía un mensaje XML a través de peticiones HTTP y recibe una respuesta, en su caso, a través de la respuesta HTTP. Para gestionar el mensaje XML correctamente, el receptor de HTTP, como Apache o Microsoft Internet Information Server (IIS), debe proporcionar un proceso SOAP. En otras palabras, una escucha HTTP recibir un mensaje SOAP debe incluir una capacidad de procesamiento de XML. Más específicamente, una escucha HTTP que recibe un mensaje SOAP debe ser capaz de validar y de entender el formato de un documento XML definido en la especificación SOAP. La especificación de SOAP permite que el protocolo de mensajería SOAP sea asignado a otros medios de transporte, a pesar de la asignación a HTTP es el único mapeo se define en la especificación. A pesar de su nombre, SOAP no incluye un modelo de objetos. SOAP define un solo sentido del protocolo de mensajes XML en la parte superior de las aplicaciones para que pueden ser construidas, incluyendo la petición / respuesta estilo de interacción de objetos y el procesamiento orientado al procedimiento, la mensajería asíncrona y notificación de eventos familiares para sistemas midd-

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

leware orientados a mensajes, sin acuse de recibo mensajes y reenvío a través de intermediarios SOAP. Las interacciones de SOAP se modelan como ocurre entre nodos SOAP, que pueden ser los remitentes de mensajes SOAP, los receptores, o ambos. Un caso especial es el de un nodo SOAP que pueda desempeñar el papel de intermediario entre el emisor y el receptor con el fin de controlar los encabezados especiales. Un nodo SOAP soporta uno o más procesadores de SOAP y es responsable de la gestión de los bloques de SOAP cuando se recibe un mensaje. SOAP transporta un documento XML a través de la Web y, potencialmente, a través de otros tipos de redes, para llegar a una implementación de servicio Web. Un mensaje SOAP es, de hecho, un documento XML creado en un formato específico. Una implementación SOAP se entiende cómo interpretar dicho documento y de cómo asignar los datos a una aplicación de software subyacente del servicio. SOAP no define el servicio en sí, sino lo suficiente sobre el mensaje para que un procesador SOAP se pueda reconocerlo. SOAP define lo que significa reconocer el mensaje como un mensaje SOAP, pero la implementación del servicio Web tiene que saber interpretar los datos contenidos en el mensaje como un objetivo para la implementación del software subyacente del servicio. Por otro lado, siguiendo el modelo cliente-servidor tendremos los siguientes componentes: ––Lado servidor: La programación se ejecuta en un ordenador conectado a una red. Este espera las peticiones de los clientes a través de un puerto. La escucha, por ejemplo, de un servidor Web es por el puerto 80 y para un servidor seguro (https) el 8080. El PC que ejecuta un servidor de aplicación debe estar conectado a la red para responder a las peticiones de los clientes. ––Lado cliente: Son los programas que ejecuta el usuario de la aplicación. El cliente realiza las peticiones al servidor a través de la propia red utilizando un navegador web o un cliente de correo electrónico por ejemplo. ––Protocolo de aplicación: Son los protocolos que se utilizan para la comunicación entre el servidor y el cliente. El protocolo define el tipo de mensajes que se intercambiarán; Por ejemplo, a través del protocolo HTTP, que es el que define la capa de aplicación de la Web. ––Formato de los mensajes: El formato de mensajes que se intercambian, son muchas veces parte del servicio; En el correo electrónico por ejemplo se define el formato de los propios mensajes electrónicos. Todos estos componentes son completamente independientes de la arquitectura de red que se utiliza.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

2.1.1 Definición de servicios

RECUERDe SOAP extiende a HTML para la mensajería de documentos XML.

Los servicios son lo que conecta entre sí mediante servicios web. Un servicio es el punto final de una conexión. Además, un servicio tiene algún tipo de sistema subyacente equipo que soporta la conexión ofrecida para el equipo. Component Based Software Engineering (CBSE). Definición de arquitecturas de sistemas en función de las dependencias que conectan un conjunto de componentes reutilizables (dimensión espacial). Los componentes de software son reutilizables Para utilizar un componente, éstos deben: ––ser empaquetados para ser desplegados como parte de algún sistema de aplicación más grande ––encajar con el marco existente que se utiliza para desarrollar el sistema (como un ejercicio de tratar de usar . NET para hacer un plug-in de Eclipse) Los componentes se pueden vender, cobrando sus desarrolladores en cargo a lo desarrollado, cobrando cada vez que un nuevo cliente se descarga el componente. Hay muchos marcos de componentes disponibles para la construcción de sistemas distribuidos (por ejemplo, J2EE, DCOM, NET, CORBA). El mayor problema es que no son compatibles Arquitecturas Orientadas a Servicios (SOA). La arquitectura de un sistema distribuido se define en términos de las interacciones entre sus servicios de los componentes (dimensión temporal) Los servicios Web también son reutilizables. Para utilizar un servicio se debe publicará en la Web (una vez) y anunciar su descripción y ubicación a los clientes potenciales a través de la Web, para que puedan acceder a él utilizando protocolos estándar Los servicios web se pueden vender también. Los proveedores de servicios pueden cobrar de forma per-call: cada vez que un cliente existente interactúa con un servicio mediante el intercambio de un nuevo mensaje.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Al igual que los componentes, los servicios Web pueden reutilizarse, integrados en sistemas más grandes y (por supuesto) que se pueden encontrar en la Web. La principal diferencia de los componentes y los servicios Web es que los servicios Web no tienen que ser descargados y desplegados con el fin de ser utilizado por los clientes. En su lugar, un cliente puede descubrir y acceder a su funcionalidad mediante el uso de protocolos estándar (WSDL, SOAP, UDDI) basado en XML. 2.1.2 Generación automática de servicios Los nuevos métodos de programación de software y de OOMethodo OOWS en particular, han de plantear mejoras en el proceso de producción de software. Para ello, se ha de dotar del soporte necesario para el desarrollo de aplicaciones Web. Se ha de disponer de una estrategia de generación automática de aplicaciones. La generación automática ofrece soporte, de una forma transparente, a todas las aproximaciones tecnológicas existentes en los servicios Web. Web Services Description Language (WSDL) es un formato para la descripción de una interfaz de servicios web. Es una manera de describir los servicios y la forma en que deben estar unidos a las direcciones de red específicas.WSDL tiene tres partes: ––Definiciones ––Operaciones ––Los enlaces de servicio Las definiciones se expresan generalmente en XML e incluyen tanto las definiciones de tipos de datos como las definiciones de mensajes que utilizan las definiciones de tipos de datos. Estas definiciones se basan generalmente en algún vocabulario XML acordado. Este acuerdo podría ser dentro de una organización o entre organizaciones los vocabularios dentro de una organización pueden ser diseñados específicamente para esa organización. Ellos pueden estar basados,o no, en un vocabulario de toda la industria. Si el tipo de mensaje y definiciones de datos deben ser utilizados entre las organizaciones, entonces se usará muy probablemente un vocabulario de toda la industria. XML, sin embargo, no es requerida para las definiciones. El OMG Interface Definition Language (IDL), por ejemplo, podría ser utilizado en lugar de XML. Si se utiliza un formato de definición diferente, emisores y receptores tendrían que ponerse de acuerdo sobre el formato, así como el vocabulario. Sin embargo, con el tiempo se prevé que dominen los vocabularios y mensajes basados en XML.

RECUERDe Las arquitecturas orientadas a servicios presentan la ventaja con respecto a las arquitecturas orientadas a objetos en que los elementos no han de ser descargados.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Los nombres XML se utilizan para garantizar la unicidad de los nombres de los elementos XML de las definiciones, operaciones y enlaces de servicio. Las operaciones describen acciones para los mensajes de apoyo de un servicio Web. Hay cuatro tipos de operaciones: ––Unidireccionales: Los mensajes enviados sin respuesta requerida ––Petición / respuesta: El emisor envía un mensaje y la envía recibido una respuesta. ––Solicitar respuesta: A solicitud de una respuesta. (La definición específica de esta acción está pendiente.) ––Notificación: Los mensajes enviados a varios receptores. (La definición específica de esta acción está pendiente.) Las operaciones se agrupan en tipos de puertos. Los tipos de puertos definen un conjunto de operaciones con el apoyo de los servicios Web. Los enlaces de servicio conectan tipos de puerto a un puerto. Un puerto se define mediante la asociación de una dirección de red con un tipo de puerto. Una colección de puertos define un servicio. Esta unión se crea comúnmente utilizando SOAP, pero permite usar otras formas. Estas otras formas podrían incluir CORBA Internet Inter-ORB Protocol (IIOP), DCOM,. NET, Java Message Service (JMS) o WebSphere MQ, por nombrar unos pocos. Web Services Dynamic Discovery (WS-Discovery) define un protocolo de detección de multidifusión para localizar servicios. Por defecto, las sondas se envían a un grupo de multidifusión, y servicios de destino que responden a una respuesta directamente al solicitante. Para escalar a un gran número de puntos finales, el protocolo define el comportamiento de supresión de la multidifusión si un hay proxy de detección disponible en la red. Web Service Endpoint Language (WSEL) es un formato XML para la descripción de las características no operacionales de puntos finales de servicio, como la calidad del servicio, el costo o las propiedades de seguridad. Web Services Metadata Exchange (WS-MetadataExchange) define tres pares de mensajes solicitud-respuesta para recuperar los tres tipos de metadatos: uno recupera la WS-Policy asociado con el extremo receptor o con un espacio de nombres determinado, otra recupera bien el WSDL asociado con el receptor punto final o con un espacio de nombres determinado, y una tercera recupera el esquema XML con un espacio de nombres determinado. En conjunto, estos mensajes permiten la recuperación gradual de los metadatos de un servicio Web.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Web Services Policy Framework (WS-Policy) proporciona un modelo de propósito general y la sintaxis correspondiente para describir y comunicar las políticas de un servicio Web. WS-Policy define un conjunto básico de las construcciones que se pueden usar y se extendieron por otras especificaciones de servicios web para describir una amplia gama de necesidades de servicios, preferencias y capacidades. WS-PolicyAssertions especifica un conjunto de aserciones de directivas de mensajes comunes que se pueden especificar en una norma. WS-PolicyAttachment especifica tres mecanismos de unión específicos para el uso de expresiones políticas con las tecnologías de servicios Web XML existentes. En concreto, definen cómo asociar expresiones de normas con definiciones de tipo WSDL y UDDI entidades. También definen cómo asociar la norma específica de la implementación con la totalidad o parte de un portType de WSDL cuando se expone a partir de una aplicación específica. 2.2 Programación de diferentes tipos de acceso a servicios El fin de la programación es hacer el desarrollo más eficiente y de construcción más funcionalidad, en menos tiempo, a un costo menor. Esto dependerá de una gran variedad de factores, incluyendo la reutilización de los servicios y la capacidad para componer rápidamente aplicaciones de esos servicios. Esto a su vez requiere de un enfoque diferente para el desarrollo de servicios y soluciones, que el enfoque que se ha utilizado en el pasado. Los desarrolladores de servicios no pueden crear servicios de forma aislada, sino que el ajuste de los servicios de basa en la arquitectura general y se ajustan a los modelos de negocio y la información de la empresa. Sin embargo, no se puede esperar a la versión inicial de un servicio para cumplir los requisitos de todos los posibles futuros usuarios. Tiene que haber un proceso gestionado para decidir la financiación y la implementación de mejoras para dar cabida a los nuevos usuarios. Pero, al mismo tiempo, hay que hacer de una manera controlada las mejoras en los servicios que mantienen la integridad de la arquitectura de servicio y el diseño, ajustándose al control de versiones y a la compatibilidad. Los desarrolladores de soluciones que consumirán los servicios tienen que ser capaces de encontrar fácilmente los servicios existentes y evaluarlos, determinar lo que hacer, y solicitar mejoras. Además, se necesita establecer los métodos y herramientas para el modelado y crear procesos de negocio de los servicios existentes.

RECUERDe La generación automática da soporte transparente a la tecnología Web.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Cuando los proyectos llevan a cabo los procesos de negocio, el diseño de un sistema necesita una metodología que se centre en la composición de los procesos de negocio de los servicios existentes. Tiene que haber una variedad de tipos de servicios disponibles, en diferentes niveles de la organización para apoyar a la composición de los procesos de negocio. También tiene que haber una metodología de análisis y diseño de los servicios además de describir las características de los diferentes tipos de servicios y explica la interacción, la interfaz y las decisiones de diseño de implementación. Por último, tiene que haber cambios en la organización para apoyar el desarrollo de servicios y el uso de toda la empresa. Se precisan los siguientes requisitos arquitectónicos para el desarrollo con una productividad eficaz: ––Ha de tener una arquitectura de referencia que guía el desarrollo de los servicios. ––Ha de usar el Business Process Management (BPM) para definir los procesos de negocio, sobre la base de la composición de servicios, y el conjunto de capas de servicios. Usar BPM para conducir al descubrimiento y diseño de los servicios requeridos. ––Ha de tener procesos eficientes que gestionan la integridad del conjunto total de los servicios tanto para los proveedores y consumidores de acuerdo con la visión general y los modelos de negocio y la información. Para que sea útil, SOAP, WSDL, UDDI y ebXML necesita ser ampliamente aplicado y disponible en los productos de software. Sólo entonces el objetivo de lograr la interoperabilidad y la integración pueden lograr sistemas de software dispares. Muchos proveedores de software ya han comenzado a poner en práctica estas y otras especificaciones clave de servicios Web, y muchos otros proveedores se han comprometido a proporcionar implementaciones más completas en el futuro. Los esfuerzos de aplicación tienden a caer en dos categorías principales. En la industria del software, una gran comunidad gira en torno al ambiente de Microsoft, y otro se centra en el entorno Java. Ambos ambientes proporcionan apoyo para el desarrollo y despliegue de servicios web, y por lo tanto los desarrolladores y los usuarios de los servicios Web en general, tienen que tomar una decisión. Por supuesto, ya que los servicios Web tratan todos sobre la interoperabilidad y la integración, estos dos entornos son compatibles, al menos en la medida en que ambos implementan las mismas especificaciones y las interpretan de la misma manera.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Microsoft está centrando su aplicación dentro de su iniciativa .NET, mientras que Mircrosystems Sun y otros proveedores de Java se están centrando sus implementaciones dentro de la plataforma Java 2, la iniciativa Enterprise Edition (J2EE). Como líder de la iniciativa de Java, Sun Microsystems ha publicado su entorno de red de arquitectura abierta (SunONE) como modelo para la evolución de los servicios Web. Microsoft ha definido su arquitectura XML Global para extender los servicios de apoyo en el Web. NET Framework, y en general a través de la estandarización. Ahora que las tecnologías básicas han establecido unas especificaciones ampliamente adoptadas, el siguiente paso es definir una arquitectura global para tecnologías adicionales, como la seguridad, el flujo de proceso, la mensajería fiable y transacciones. El Grupo de Trabajo de Servicios Arquitectura Web W3C está haciendo precisamente eso. Dado que los servicios Web se dedican a resolver los problemas de integración de la empresa, los vendedores corren con la integración de servicios de Web a través de adaptadores y componentes de integración, o bloques de construcción. Los proveedores de bases de datos soportan interfaces de servicios web directamente a los sistemas de gestión de bases de datos. La planificación de recursos empresariales (ERP) y gestión de los recursos de clientes (CRM), aplicaciones empaquetadas soportan interfaces de servicios web para la integración con otros paquetes y productos de software. Por último, un número de vendedores están creando los productos destinados exclusivamente a la aplicación de una capa de servicios Web. Las principales categorías de actividades de implementación de servicios Web, son ––NET Framework de Microsoft: Windows está bien establecida como el entorno de escritorio más popular, y muchos desarrolladores utilizar las herramientas de Microsoft para aplicaciones cliente y servidor. Microsoft está añadiendo soporte de servicios web a través de su plataforma. NET, en el que cada programa es potencialmente un servicio Web, y todos los medios de transporte puede utilizar los protocolos XML. ––Los servidores de aplicaciones J2EE: La comunidad, compuesta por fabricantes de servidores de aplicaciones, es la adición de interfaces de programación de aplicaciones de servicios Web (API) para servlets Java, y las clases, beans, por lo que la integración de XML y los servicios Web parte de la definición de servidor de aplicaciones base. ––Corredores de integración: Los proveedores de este segmento del mercado de middleware están utilizando servicios Web para aplicaciones con integración de dentro de la empresa, y de empresa a empresa (B2B), uniendo aplicaciones de servicios Web dentro y por fuera del firewall.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

RECUERDe Hay diferentes tecnologías de implantación de servicios Web. Se debe estudiar las necesidades particulares de cada caso para elegir la más adecuada.

––Proveedores de bases de datos:Vendedores de este grupo se centran en el uso de servicios web para proporcionar un medio de acceso a las tablas de bases de datos y los procedimientos almacenados. ––ERP, CRM y otros: Los proveedores de aplicaciones empaquetadas son la adición de interfaces de servicios web para la integración de los paquetes con otros paquetes de software y sistemas. ––Plataforma de servicios Web: Se están desarrollando y suministrando ––Servicios de productos de infraestructura Web como independiente o autónomo. 2.2.1 Servicios basados en publicación/suscripción. El modelo suscripción-publicación envía información a una serie de destinatarios que están suscritos a un tema concreto de información. La suscripción-publicación basada en mantener la lista de suscriptores. Cuando existe información para compartir, esta envía una copia a cada suscriptor de la lista. En un modelo dinámico de suscripción-publicación basada en lista, los clientes deben poder suscribirse o cancelar su suscripción las veces que ellos consideren. La suscripción-publicación basada en una lista debe tener un cliente, un servicio y un programa de origen de datos. Puede existir más de un cliente y más de un programa de origen de datos. Los clientes se suscriben al servicio, reciben las notificaciones y cancelan su suscripción. Los programas de origen de datos envían información al servicio para compartir con todos los suscriptores actuales. En la arquitectura de software, la publicación-suscripción es un patrón de mensajería en el que los remitentes de mensajes, llamados editores, no programar los mensajes que se envían directamente a los receptores específicos, llamados suscriptores. En su lugar, los mensajes publicados se caracterizan en clases, sin requerir que haya o no abonados. Del mismo modo, los suscriptores de expresar interés en una o más clases, y sólo reciben mensajes que son de su interés, sin conocimiento de lo que, en su caso, hay en los editores. La publicación / suscripción es un hermano del paradigma de encolado de mensajes, y es una parte de un sistema de middleware orientada mensaje más grande. La mayoría de sistemas de mensajería son compatibles con los modelos de la cola de mensajes de publicación / suscripción y en su API, por ejemplo, Java Message Service (JMS). Este modelo proporciona una mayor escalabilidad de la red y una topología de red más dinámica.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

En el modelo publicación / suscripción, los suscriptores reciben típicamente sólo un subconjunto de los mensajes totales publicados. El proceso de selección de mensajes para la recepción y el procesamiento se denomina filtrado. Hay dos formas comunes de filtrado: por tema y basados en contenidos. En un sistema basado en temas, los mensajes se publican en temas o canales lógicos con nombre. Los suscriptores de un sistema basado en temas recibirán todos los mensajes publicados en los temas a los que suscriben, y todos los suscriptores a un tema recibirán los mismos mensajes. El editor es responsable de definir las clases de mensajes a los que los suscriptores pueden suscribirse. En un sistema basado en el contenido, los mensajes sólo se entregan a un abonado si los atributos o el contenido de esos mensajes coinciden con las restricciones definidas por el abonado. El suscriptor es responsable de clasificar los mensajes. Algunos sistemas admiten un híbrido de los dos; editores publicar mensajes en un tema mientras que los suscriptores registrarse suscripciones basadas en el contenido de uno o más temas. En muchos sistemas de publicación / suscripción, los editores envían mensajes a un intermediario de mensajes o bus de eventos, y los suscriptores registran suscripciones con ese corredor, dejando que el agente realice el filtrado. El agente generalmente la realiza en función del avance para enrutar los mensajes de los editores a los abonados. Además, el corredor puede dar prioridad a los mensajes en una cola antes de proceder a su envío. En los sistemas con interfaz gráfica de usuario, los suscriptores pueden codificar con la gestión de los comandos de usuario (por ejemplo, haga clic en un botón), lo que corresponde a la construcción de un registro de tiempo. Algunos marcos de referencia y productos de software utilizan archivos de configuración XML para registrar suscriptores. Estos archivos de configuración se leen en tiempo de inicialización. La alternativa más sofisticada es cuando los suscriptores se pueden agregar o quitar en tiempo de ejecución. Esto se realiza, por ejemplo, en disparadores de base de datos, listas de correo y RSS. La mayoría de los OMG Data Distribution Service (DDS) no utiliza un corredor. En cambio, cada editor y el suscriptor en el sistema de publicación / suscripción comparte los meta-datos de cada uno. El editor y los suscriptores de caché de esta información a nivel local permiten enrutar los mensajes del conocimiento compartido. OMG Data Distribution Service (DDS). Ventajas: ––Acoplamiento débil: Los editores están débilmente acoplados a los suscriptores, y ni siquiera necesita saben de su existencia. Con el tema de ser el foco,

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

a editores y suscriptores se les permite permanecer en la ignorancia de la topología del sistema. Cada uno puede seguir funcionando normalmente, independientemente del otro. En el paradigma cliente-servidor tradicional fuertemente acoplado, el cliente no puede enviar mensajes al servidor, mientras que el proceso del servidor no está en ejecución, ni el servidor recibe mensajes a menos que el cliente se esté ejecutando. Muchos sistemas publicación / suscripción desacoplan no sólo la ubicación de los editores y suscriptores, sino que también los desacoplan temporalmente. Una estrategia común utilizada por los analistas de middleware por sistemas publicación / suscripción es acabar con un editor para que el abonado pueda trabajar a través de la cartera de pedidos (una forma de limitación de ancho de banda). ––Escalabilidad: la publicación / suscripción brinda la una mejor escalabilidad que tradicional cliente-servidor, a través de la operación en paralelo, caché de mensajes, basado en árboles o en la red basada en rutas, etc. Sin embargo, en ciertos tipos acoplados, los entornos empresariales de gran volumen, como los sistemas que escala hasta convertirse en centros de datos con miles de servidores que comparten la infraestructura publicación / suscripción, sistemas de proveedores actuales suelen perder este beneficio la escalabilidad para productos publicación / suscripción de alta carga en estos contextos es un reto para la investigación.

RECUERDe Los servidores de publicación / suscripción, pese a sus inconvenientes, son ampliamente usados en la actualidad, especialmente en los RSS.

Fuera del entorno de la empresa, por otro lado, el paradigma publicación / suscripción ha demostrado su capacidad de ampliación a los volúmenes muy superiores a los de un solo centro de datos, proporcionando en todo Internet mensajes distribuidos a través de protocolos de sindicación web como RSS y Atom (estándar). Estos protocolos sindicación aceptar una mayor latencia y la falta de garantías de entrega, a cambio de la posibilidad de que incluso usando un servidor web de gama baja a los mensajes del sindicato que (potencialmente) millones de nodos suscriptores individuales. Inconvenientes: Los problemas más graves con los sistemas de publicación / suscripción son un efecto secundario de su principal ventaja: la desvinculación de la editorial de abonado. Un sistema de publicación / suscripción debe ser cuidadosamente diseñado para ser capaz de proporcionar las propiedades del sistema más fuertes que una aplicación particular puede requerir, como asegurado de entrega. ––El intermediario en un sistema de publicación / suscripción puede ser diseñado para enviar mensajes a una hora determinada, pero luego se detiene el intento de entrega, o no se ha recibido la confirmación de la recepción satisfactoria del mensaje por todos los suscriptores. Un sistema de publicación / suscripción así diseñado no puede garantizar la entrega de mensajes a todas las aplicacio-

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

nes que puedan requerir tales entrega asegurada. Más estrecha es la unión de los diseños de un par como editor y el suscriptor debe aplicarse fuera de la arquitectura publicación / suscripción para realizar dicha entrega segura (por ejemplo, al exigir que el abonado pueda publicar mensajes de confirmación). ––Un editor de un sistema de publicación / suscripción puede “suponer” que un abonado está escuchando cuando no lo está. Una fábrica puede utilizar un sistema publicación / suscripción en el equipo puede publicar problemas o fracasos a un abonado que muestra y registra los problemas. Si el registrador no se bloquea, equipo de editores de problemas no necesariamente recibirá la notificación de la falta del registrador y no se muestran ni se graban mensajes de error por cualquier equipo en el sistema publicación / suscripción. Debe tenerse en cuenta que esta es también un reto de diseño para las arquitecturas de mensajería alternativas, tales como un sistema cliente / servidor. En un sistema cliente / servidor, cuando se registra un error de fallo, el sistema va a recibir una indicación del registrador de error (servidor) que falló. Pero el sistema cliente / servidor tendrá que lidiar con que el hecho de tener servidores redundantes de registro en línea, o servidores de registro de reserva dinámica. Esto añade complejidad al cliente y diseños de servidores y la arquitectura cliente / servidor en su conjunto. Sin embargo, en un sistema de publicación / suscripción, los suscriptores de registro redundantes que son duplicados de forma exacta por el registrador existente se pueden añadir al sistema para aumentar la fiabilidad de registro sin ningún impacto a cualquier otro equipo en el sistema. En un sistema de publicación / suscripción, la función de registro de mensajes de error fijo, se puede añadir incrementalmente, con posterioridad a la aplicación de la funcionalidad básica simple de mensaje de problema con el equipo de registro. Escalas de publicación / suscripción funciona bien con redes pequeñas con un pequeño número de editores y los nodos de los abonados y de bajo volumen de mensajes. Sin embargo, cuando el número de nodos y mensajes crece, la probabilidad de inestabilidad aumenta, lo que limita la escalabilidad máximo de un pub / sub red. Ejemplo inestabilidades rendimiento en grandes escalas incluyen: ––Cargar oleadas de mensajes cuando las solicitudes de abonados saturan rendimiento de la red seguido de periodos de bajo volumen de mensajes (ancho de banda de red infrautilizada) ––Desaceleraciones ––Tormentas-una difusión IP de red de área local puede cerrarse por completo al saturar con mensajes generales que ahogan todo el tráfico normal sin relación con el tráfico de publicación / suscripción.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Para los sistemas de publicación / suscripción que utilicen intermediarios (servidores), el acuerdo para un corredor para enviar mensajes a un suscriptor está dentro del rango, y puede estar sujeto a los problemas de seguridad. Los corredores podrían ser engañados en el envío de notificaciones al cliente equivocado, amplificando la negación de solicitudes de servicio contra el cliente. Los propios corredores podrían ser sobrecargados ya que asignan recursos para rastrear las suscripciones creadas.

RECUERDe En cada caso se deben estudiar los posibles inconvenientes propios de cada empresa o cada caso, para decidir si implantar o no un sistema publicación/ suscripción.

Incluso con sistemas que no se basan en los corredores, un abonado podría ser capaz de recibir datos que no está autorizado a recibir. Un editor no autorizado puede ser capaz de introducir mensajes incorrectos o perjudiciales en el sistema publicación / suscripción. Esto es especialmente cierto con los sistemas de difusión o multidifusión de sus mensajes usan. Cifrado (por ejemplo, Transport Layer Security (SSL / TLS)) puede prevenir el acceso no autorizado, pero no puede impedir que los mensajes dañinos que se introduzcan por los editores autorizados. Arquitecturas distintos publicación / suscripción, tales como los sistemas cliente / servidor también son vulnerables a los remitentes de mensajes autorizados que se comportan de forma maliciosa. 2.2.2 Servicios basados en repositorios Un repositorio, depósito o archivo es un sitio centralizado en el que se guarda y mantiene toda la información digital necesaria para una empresa o individuo, con una serie de políticas de preservación a largo plazo. Internet permite mucha facilidad para publicar y compartir documentos, pero los repositorios surgen de la necesidad de almacenarlos en entornos fiables, con facilidad para organizar, dar estabilidad en las direcciones, autoarchivo y licenciamiento de documentos de cualquier tipo de carácter. Los repositorios pueden ofrecer diferentes modelos de metadatos (Mets, Premis o DublinCore) y suelen utilizar el protocolo OAI/PMH para recolectar los datos. El significado de repositorio en el ámbito de la informática tiene que ver con el CVS o gestión de versiones en los procesos de desarrollo de aplicaciones y del almacenamiento del código fuente accesible a un grupo de programadores. Existen diferentes tipos de repositorios. Según la entidad responsable: ––Los institucionales, promocionados o gestionados por una institución. Por lo general suelen ser de investigación, que sería la única responsable de la gestión del contenido. Como ejemplos, pueden sere-Spacio UNED,DSpace@MIT,

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Gredos,Digital.CSIC, Eprints Complutense o e-archivo UC3M ––Colaborativos o promocionados por una red o entidad. Estos permiten el depósito de documentos de diferentes procedencias institucionales. Como ejemplos, pueden ser: HAL, Recercat,E-LIS oRePEc. Según el enfoque disciplinar: ––Temáticos, dirigidos a de un ámbito específico. Como ejemplos, pueden ser ELIS, DSpace@MIT,Bibliopsiquis,arXiv, CogPrints, Earth-prints, OrganicEprints, PsyDok. ––Multidisciplinares, abiertos a todas las disciplinas de una institución o consorcio. Como ejemplos, pueden ser HAL, Digital.CSIC, Gredos USAL, Eprints Complutense. Casos especiales: Las revistas electrónicas con un software de gestión y edición en acceso abierto. La publicación de estas revistas en acceso abierto, con plataformas tipo OJS, también tiene un repositorio especializado en artículos y revistas. Como ejemplos pueden ser las plataformas de revistas del CSIC, UCM, Universidad de Salamanca, Universidad de Barcelona,... Algunos repositorios están específicamente dedicados a tesis doctorales. Con el desarrollo de los repositorios institucionales y colaborativos, los documentos se integran dentro de estos como una modalidad documental más; Aunque también persisten otros repositorios de archivos abiertos a tesis como NDLTD, TDR/ TDX, Dialnet tesis. Recolectores: Los recolectores recopilan la información de varias fuentes y las integran en un único recurso. Los recolectores son considerados proveedores de servicios, pero pueden también actuar como proveedores de datos para diferentes servicios. Por ejemplo, Hispana o Recolecta son recolectores nacionales y pueden actuar a su vez de proveedores para un proyecto internacional. Sistemas mixtos entre el repositorio y la base de datos referencial. Los sistemas de información suelen actuar como productos, los cuales ofrecen funciones tanto de archivado de documentos como de base de datos para la bibliográfica referencial. El contenido de estas integra los registros de documentos o texto completo junto a simples referencias, que incluyen o no enlaces al texto completo en otras ubicaciones externas. Ejemplos: HAL, RePEc, Dialnet. Sistemas mixtos entre el archivo abierto y el repositorio de uso interno. Otros repositorios admiten el registro de documentos de acceso restringido.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

POLÍTICAS DE GESTIÓN DE REPOSITORIOS En todos los repositorios, la alimentación de datos estimula el autoarchivado directo de cada uno de los autores de documentos, aunque esta forma de funcionamiento puede sustituirse con políticas de archivo delegado, que están realizados por terceras personas con autorización expresa de los autores. La administración del repositorio realiza también tareas de revisión o validación de nuevos registros. En las empresas es imprescindible realizar las tareas previas a la planificación que contemplan la sostenibilidad y el mantenimiento de los repositorios que se quieran guardar de una forma permanente. Debemos tener definidos de una forma clara todos los contenidos digitales que queramos eliminar debido a la complejidad y el coste que representaría la migración de formatos en el futuro. Hay que entender que, más allá de las herramientas (ERPS o gestores documentales por ejemplo), es imprescindible contar con un sistema de gestión de repositorios digitales sólido y que englobe unas políticas definidas, unas responsabilidades asignadas y unos calendarios de conservación y de eliminación, aparte de manuales de procedimientos. La política de contenidos y para los repositorios se debe perfilar para una función en concreto o para la integración de varias aplicaciones:

RECUERDe El repositorio se usa para almacenar de forma accesible y segura la información.

––Archivo administrativo: Es un depósito de documentos de carácter solo informativo, normativo o administrativo. ––Biblioteca digital: Son colecciones de documentos históricos y fondos ––Digitalizados específicamente procedentes de bibliotecas y archivos, o de las colecciones editoriales de una institución. ––Archivo científico: Es un repositorio de documentos o conjuntos de datos que provienen de proyectos de investigación científica. ––Archivo de material docente: Son depósitos de documentos con carácter didáctico y/o utilizados en la enseñanza. 2.2.3 Servicios accesibles desde agentes de usuario Las Pautas de Accesibilidad para Agentes de Usuario (UAAG) explican cómo hacer que las aplicaciones de usuario accesible a las personas con discapacidad, en particular para aumentar la accesibilidad a contenido Web. Los agentes de usuario incluyen navegadores, reproductores multimedia y tecnologías de apoyo, que

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

son programas que algunas personas con discapacidad utilizan para interactuar con los ordenadores. UAAG es principalmente para los desarrolladores de los navegadores Web, reproductores multimedia, tecnologías de apoyo, y otros agentes de usuario, pero los recursos UAAG y su soporte están destinados a satisfacer las necesidades de diferentes públicos, incluidos los responsables políticos, administradores, y otros, por ejemplo, ––personas que quieren elegir los agentes de usuario por ser más accesibles, pueden utilizar UAAG para evaluar las aplicaciones; ––personas que quieren fomentar el desarrollado del agente de usuario existente para mejorar la accesibilidad en las versiones futuras pueden referir al agente de usuario UAAG. ––UAAG 1.0 contiene un amplio conjunto de puntos de control que permiten: ––acceder a todo el contenido, incluido el contenido vinculado a los eventos lanzados por el ratón o el teclado ––control del usuario sobre cómo se representa el contenido ––control del usuario sobre la interfaz de usuario, con la documentación de las funciones de accesibilidad ––interfaces de programación estándar, que permitirán la interacción con tecnologías de asistencia. PAUTAS DE UAAG 1.0 Dar soporte a la entrada y la salida del dispositivo independiente: Se asegura de que el usuario puede interactuar con el agente de usuario (y el contenido que hace) a través de diferentes dispositivos de entrada y salida. Garantizar el acceso de usuarios a todo el contenido: Compruebe que los usuarios tienen acceso a todo el contenido, el contenido particular que se haya adoptado para cumplir con los requisitos de las Pautas de Accesibilidad al Contenido en la Web 1.0. Permitir la configuración que permita no mostrar el contenido que pueda reducir la accesibilidad: Asegúrese de que el usuario puede desactivar la representación de los contenidos (por ejemplo, audio, video, scripts) que pueden reducir la accesibilidad al ocultar el contenido o desorientar al usuario. Asegurar el control de usuario de la prestación: Asegúrese de que el usuario puede seleccionar estilos preferidos (por ejemplo, colores, tamaño de texto representado, y características de voz sintetizada) de las opciones que ofrece el agente de usuario. Permitir al usuario anular estilos y estilos de agente de usuario

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

por defecto especificados por el autor. Asegurar el control de usuario del comportamiento de la interfaz de usuario: Asegúrese de que el usuario puede controlar el comportamiento de las ventanas y los controles de interfaz de usuario, incluidos los que pueden ser manipulados por el autor (por ejemplo, a través de secuencias de comandos). Implementar las interfaces de programación de aplicaciones inter-operables: Implementar interfaces inter-operables para comunicarse con otros programas (por ejemplo, las ayudas técnicas, el entorno operativo y los plugins). Observar las convenciones ambientales: Para la interfaz de usuario del agente de usuario, documentación, configuraciones de entrada, y la instalación. Implementar las especificaciones que beneficien la accesibilidad: Apoyar las características de accesibilidad de todas las especificaciones implementadas. Poner en práctica las recomendaciones del W3C cuando estén disponibles y sean apropiadas para la tarea. Proporcionar mecanismos de navegación: Proporcionar acceso a los contenidos a través de una variedad de mecanismos de navegación, incluyendo navegación secuencial, la navegación directa, búsquedas y navegación estructurada. Orientado al usuario: Proporcionar información que ayudará al usuario a comprender el contexto de la navegación.

RECUERDe Las pautas de accesibilidad dan una gran ventaja para permitir acceder y usar las aplicaciones a gente con discapacidad.

Permitir la configuración y personalización: Permitir a los usuarios configurar el agente de usuario para que las tareas se realizan con frecuencia se hacen conveniente, y permiten a los usuarios guardar sus preferencias. Proporcionar la documentación del agente de usuario accesible y ayuda: Asegúrese de que el usuario puede aprender acerca de las características de software beneficiando la accesibilidad de la documentación. Asegúrese de que la documentación pueda consultarse. EVALUACIÓN La evaluación de los resultados consta de un informe de aproximadamente 1.500 palabras que abarcan: Una descripción clara y precisa de las diferencias entre las normas y/ o directrices y la legislación y su aplicación en el desarrollo de contenidos web accesibles.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

El papel que juegan las instituciones profesionales en el establecimiento de pautas de accesibilidad en el desarrollo web, en particular el papel del Consorcio World Wide Web (W3C) en la organización de la Iniciativa de Accesibilidad Web (WAI) desarrollan directrices y recursos para ayudar a hacer la Web accesible para las personas con discapacidad. Las cinco áreas de trabajo WAT, garantizan la accesibilidad de las tecnologías web, la elaboración de directrices para la accesibilidad, mejorando las herramientas para evaluar y reparar la accesibilidad web, materiales para la educación y divulgación del desarrollo, en coordinación con la investigación y el desarrollo, y el modo de funcionamiento. Se puede usar un resumen de tres de las principales directrices de accesibilidad, incluido el acceso a la conformidad con éstos en el contexto del estudio de caso. Se deben incluir pautas de accesibilidad en relación con: Directrices de Accesibilidad para el Contenido Web (WCAG), Pautas de Accesibilidad para Herramientas de Autor (ATAG), Pautas de Accesibilidad para Agentes de Usuario (UUAG). Se debe realizar una evaluación precisa y clara de por lo menos seis pautas WCAG que se deben cumplir en el desarrollo de contenidos web en el contexto del estudio de caso. Web Content Accessibility Guidelines, debe tomar muestras de: ––Imágenes: Uso del atributo alt para describir la función de cada visual ––Mapas de imágenes: El uso de mapas de imágenes del lado del cliente y texto para las zonas activas ––Marcos: El no uso de frames y títulos de página significativos ––Tablas: Haga línea por línea de lectura sensibles, contenidos tabla que resume ––Organización de páginas: uso de encabezados, listas y estructura consistente, agrupación de datos relacionados. El uso de hojas de estilo en cascada (CSS) para el diseño y el estilo. ––Gráficos y cuadros: Resumir datos, el uso del atributo longdesc ––Texto: Relativa tamaño, color, uso de hojas de estilo en cascada (CSS) ––Multimedia: Suministro de subtítulos y trascripción de contenido de audio, descripción de contenido de vídeo ––Enlaces de hipertexto: Use de texto que tenga sentido leído fuera de contexto, por ejemplo, evitar ‘Pulse aquí’ ––Scripts, plugins y applets: Suministro de contenidos alternativos en las características activas de casos no son accesibles ––Independencia de Dispositivo: Diseño de contenidos para utilización en el método preferido de entrada! de salida, por ejemplo la entrada de voz ––Idioma: El uso de lang y xml: lang atributos para identificar el lenguaje natural

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

RECUERDe Las aplicaciones accesibles no se usarán únicamente por personas con discapacidad, sino que garantiza un diseño más intuitivo y accesible para todos.

de las páginas y los cambios en el lenguaje para ayudar a las tecnologías de asistencia 2.2.4 Proveedores y consumidores de servicios en entorno servidor El término Cliente-Servidor se utilizó inicialmente para denominar ordenadores personales en una red. El modelo Cliente-Servidor es una arquitectura de software que tiene una estructura modular basada en mensajes que mejoran la usabilidad, la flexibilidad y la interoperabilidad y escalabilidad comparados con otras estructuras centralizadas. El cliente se define como un “solicitador de servicios” y el servidor se define como un “proveedor de servicios”. En los entorno Cliente-Servidor el cliente se relaciona con las funciones de presentación de datos y con las actividades lógicas de validación y verificación en local. En cambio, el servidor desarrolla muchas actividades relacionadas con la búsqueda y la recuperación de los resultados en sus bases de datos. Podemos tratar a los clientes o programas que representan entidades que necesitan servicios y los servidores o programas que proporcionan estos servicios como objetos separados que se comunican en una red de comunicaciones, y realizan varias tareas de forma conjunta. En una estructura de esta tipo, el cliente desarrollaría las siguientes funciones: ––Mantiene y procesa todo el dialogo con el usuario. ––Maneja las pantallas. ––Crea los menús e interpreta los comandos. ––Introduce los datos y los valida. ––Procesa las ayudas y la recuperación de errores. Por otro lado, el servidor se caracteriza por cumplir con las siguientes funciones. ––Accede, almacena y organiza los datos. ––Actualiza los datos almacenados. ––Administra los recursos compartidos. ––Ejecuta toda la lógica para procesar las transacciones. ––Procesa los elementos comunes del servidor (datos, capacidad de CPU, almacenamiento en disco, capacidad de impresión, manejo de memoria y comunicación)

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

El modelo Cliente-Servidor asigna roles diferentes a los dos procesos que colaboran: ––El servidor interpreta el papel del proveedor de servicio y espera de forma pasiva la llegada de peticiones. En cambio, el cliente invoca algunas peticiones al servidor y espera la respuesta. ––El modelo Cliente-Servidor facilita de una manera eficiente todos los servicios de red. En general, casi todos los servicios de Internet dan soporte para aplicaciones Cliente-Servidor, como los servicios HTTP, DNS, o FTP. Características de la arquitectura Cliente-Servidor. La arquitectura cliente-Servidor, tiene una serie de características básicas imprescindibles para la comunicación. Se podría dividir en las siguientes: ––Protocolos asimétricos: Con una relación de varios a uno entre los clientes y un único servidor. El cliente es quien inicia el dialogo, mediante la solicitud de un servicio. Los servidores, mientras tanto, esperan por las solicitudes de los clientes. ––Encapsulación de servicios: El servidor es el que determina cómo y cuándo se hace la entrega de un mensaje y a través de que protocolo. El servidor se puede actualizar sin que ello afecte a los clientes, mientras que la interfaz pública de mensajes que se está utilizando permanezca sin cambiar. ––Integridad: Tanto los datos como el código del servidor se mantienen centralizados. Esto origina que el mantenimiento sea más económico y la protección de la integridad de datos compartidos. Los clientes siguen manteniendo su independencia y autonomía. ––Transparencia de localización: El software Cliente-Servidor suele ocultar la localización de los servidores a los clientes utilizando la redirección de servicios. Los programas pueden utilizarse como cliente, como servidor o como ambos simultáneamente. ––Intercambios basados en mensajes: Los clientes y servidores utilizan procesos acoplados que intercambian las solicitudes de servicios y las respuestas utilizando mensajes. ––Modularidad o diseño extensible: Gracias al diseño modular, la aplicación cliente-servidor es tolerante a fallos. Los fallos que puedan producirse no causarían la caída completa de la aplicación. Los servidores son redundantes entre sí, por lo que si un servidor que proporcione un servicio cae, los otros servidores activos pueden ofrecerlo. Una ventaja más de la modularidad es que la aplicación respondería automáticamente al decremento o incremento de carga en los

100

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

sistemas añadiendo o quitando servicios o servidores ––Independencia de la plataforma: El software Cliente-Servidor ha de ser independiente tanto del hardware como de los sistemas operativos, permitiendo así al programador mezclar plataformas de clientes y servidores. ––Código reusable: La implantación de un mismo servicio se puede realizar en varios servidores a la vez. ––Escalabilidad: Existen dos tipos de escalabilidad en la arquitectura Cliente-Servidor, la horizontal y la vertical. En el escalado horizontal, podemos añadir y/o eliminar terminales con un impacto mínimo en el rendimiento. En cambio, en el escalado vertical podremos realizar la migración a un servidor más grande y rápido o incorporar nuevos. ––Separación de la funcionalidad del Cliente-Servidor: El modelo Cliente-Servidor separa de una forma clara las funciones de cada uno de los servicios de red. Los procesos se pueden ejecutar en el mismo terminal o en terminales separados. El servidor es el que provee de servicios y el cliente el consumidor de estos. ––Recursos compartidos: El servidor proporciona servicios a muchos clientes y regula el acceso a una serie de recursos compartidos. Tipos de Servidores Hay diferentes tipos de servidores que podemos encontrar en la arquitectura cliente-Servidor que ofrecen diferentes servicios. Los principales podrían ser los siguientes:

RECUERDe Cliente: solicitador de servicios. Servidor: proveedor de servicios.

––Servidores de archivos: Los archivos se almacenan en el servidor y es el cliente el que realiza la solicitud de archivos que el servidor comparte en forma de repositorios de documentos, imágenes o programas. ––Servidores de bases de datos: Las aplicaciones alojadas en el cliente envían solicitudes SQL al servidor y este devuelve el resultado de la consulta. ––Servidores de transacciones: El terminal cliente solicita un procedimiento remoto o transacción sobre la base de datos. Los datos intercambiados serian: ––De Cliente a Servidor: solicitud. ––De Servidor a Cliente: mensaje de resultado. ––Servidores groupware: Intercambio la información estructurada: texto, imágenes o documentos a través del correo electrónico utilizando plataformas como Lotus Notes o MS Exchange. ––Servidores de aplicaciones web: Los clientes son los que solicitan la información Web servidor o servidores. La solicitud se hace por nombre utilizando el protocolo es HTTP.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

2.3 Herramientas para la programación de servicios web El diseño de una página Web se puede definir en tres pasos: la planificación, el diseño y la implementación. Hay que tener en cuenta también la interactividad con el usuario o la navegabilidad. Dentro del diseño Web, se definen tres etapas que hay que tener muy en cuenta: ––El diseño visual. En esta etapa crearemos la distribución del texto, la ubicación de las imágenes y gráficos, y los hipervínculos a otros documentos. Es necesario también antes de empezar a programar, que se piense en una idea y se pase a papel sobre cómo será la página Web. Esto nos permitirá tener una perspectiva amplia sobre el diseño que queremos para la página. ––Editar la página Web. Hay que elegir un buen editor Web. En esta etapa se han de establecer los hipervínculos; Un hipervínculo es el enlace que nos permite ingresar en la página Web. Este se puede personalizar para que se muestre una página relacionada o que muestre una página totalmente diferente. ––Posicionamiento en el buscador. Para poder mejorar las posiciones en los buscadores web tipo Google o Yahoo, es necesario optimizar el contenido y la estructura web. También usar palabras clave que utilizaremos dependiendo del contenido web. 2.3.1 Comparativa Existe mucha diversidad de aplicaciones para diseño de páginas Web. En este punto describiremos una serie de ellas, tanto de pago como gratuitas. WYSIWYG Web Builder. WYSIWYG Web Builder es una serie de herramientas que nos permite la construcción de páginas web sin necesidad de editar el código de manera manual. Las herramientas incluidas se dividen en dos categorías: Las herramientas propietarias on-line, que son ofrecidas por las empresas de alojamiento web, o destinadas, por lo general, a los usuarios para crear su propio sitio web privado;Y el software que se ejecuta en los terminales para la creación de páginas off-line que permite luego publicar estas páginas en cualquier host. HTMLSpy. HTMLSpy es una herramienta que permite saber cómo están creados los diferentes sitios web. Permite visitar cualquier página web y recoger el código fuente HTML. Otras funciones de HTMLSpy es la validación visual del código html.

101

RECUERDe Elegir una u otra herramienta dependerá de lo que precisemos de ella. Este es el criterio para la elección de la que debemos usar.

102

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

GI Web. GI-WEB es un producto más orientado a empresa. Puede crear desde páginas muy sencillas hasta otro tipo de páginas complejas, como la inclusión de plugins para comercio electrónico. El destinatario del producto es generalmente el personal de Marketing, ya que sólo será necesario un diseñador web para consultas puntuales. Esto es debido a que se trabaja con esta herramienta como si de una suite ofimática se tratara. Adobe Flash. Adobe Flash es una plataforma multimedia que permite la creación de gráficos vectoriales, animaciones, juegos y aplicaciones, normalmente para uso web o móvil. Flash se utiliza habitualmente para añadir vídeos en streaming a una web y/o contenido multimedia interactivo. Permite la transmisión bidireccional de audio y video. Gracias a esto, puede interactuar con el usuario a través del ratón, teclado, micrófono o cámara. El lenguaje utilizado para crear las Aplicaciones Flash y las animaciones es un lenguaje orientado a objetos llamado ActionScript. El software también permite la automatización a través del lenguaje JavaScript de Flash. Para que el usuario pueda ver el contenido, necesitará instalarse el plugin de Adobe Flash Player en los dispositivos informáticos que necesite. Dreamweaver. Es un conjunto de aplicaciones con el que podremos construir, diseñar y editar sitios, videos y aplicaciones Web. Es uno de los programas más utilizados para el diseño y la programación web, ya que permite por sus funcionalidad y su integración con diferentes herramientas como Adobe Flash. También ofrece soporte de otros estándares como el World Wide Web Consortium. Microsoft FrontPage. Es el editor de páginas web que utilizan los sistemas operativos Windows. En principio estuvo incluido como parte de la suite de Office. Uno de los grandes errores de esta aplicación es que utiliza la etiqueta Font, la cual ha sido ya declarada obsoleta por el organismo WWW Consortium. Aparte, posee funcionalidades, como los WebBots, que solo son usables con Internet

RECUERDe La tarea de creación de páginas web se puede facilitar y agilizar bastante con el uso de herramientas.

Explorer Microsoft dejo de dar soporte para esta aplicación y ahora ofrece Expression Web, que utiliza el mecanismo WYSIWYG para la creación de páginas web. Boss Enterprise Application Platform La JBoss Enterprise Application Platform 6 es una plataforma del middleware que añadió estándares abiertos, y que se integra con Java EE. Dota al Servidor de

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Aplicación JBoss 7 con la posibilidad de mensajería agrupada y otras tecnologías para crear una plataforma estable, ampliable, eficaz y rápida. Además, también incluye APIs y marcos de desarrollo que puede usar para desarrollar Java de forma segura, para implementar aplicaciones de EE rápidamente. Un dominio provee la dirección centralizada de múltiples servidores físicos, mientras un Servidor Independiente tiene solo en cuenta un caso del servidor. Las configuraciones, los despliegues, bindings, módulos, extensiones y propiedades del sistema se pueden gestionar por grupo del servidor. No hay ninguna necesidad de corregir archivos de configuración XML a mano. CLI ofrece el procesamiento por lotes, de modo que permita la escritura y automatizar tareas de la direccionamiento. La seguridad de aplicación se maneja centralmente para la simplificación de la configuración. La disposición del directorio de la JBoss Enterprise Application Platform 6 se ha simplificado. Los módulos y directorios ahora contienen los módulos del servidor de aplicación, en vez de usar directorios comunes y otros específicos para el servidor. El mecanismo classloading se ha hecho completamente modular, de modo que los módulos se carguen y se descarguen a petición. Esto proporciona rendimiento y ventajas de seguridad, así como una inicialización muy rápida. La dirección de Datasource se agiliza. Los drivers de la base de datos se pueden desplegar igual que otros servicios. Además, los datasources se crean y se gestionan directamente en la Consola de la dirección o dirección CLI. La JBoss Enterprise Application Platform 6 usa menos recursos y es muy eficiente en su uso de recursos del sistema. La JBoss Enterprise Application Platform 6 oferta herramientas de gestión múltiple para configurar y administrar su realización. Éstos incluyen la nueva Consola de la dirección o la dirección Command Line Interface (CLI), como ejemplos del API de la dirección subyacente que permite a usuarios expertos desarrollar sus propios instrumentos si así lo desean. La JBoss Enterprise Application Platform 6 incluye una estructura del directorio simplificada, comparado con versiones anteriores. A continuación se enumera la estructura del directorio y una descripción de lo que el directorio contiene.

103

104

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Directorios y archivos de alto nivel: NOMBRE

PROPÓSITO

Appclient/

Contiene detalles de la configuración para el contenedor del cliente de la aplicación.

Bin/

Contiene escrituras de inicialización para la JBoss Enterprise Application Platform 6 en Red Hat Linux y Microsoft Windows.

Bundles/

Contiene OSGi que pertenecen a la funcionalidad interna de JBoss Enterprise Application Platform 6.

Docs/

Archivos de la licencia, esquemas y ejemplos.

Domain/

Archivos de configuración, contenido de despliegue y áreas escribibles usadas cuando JBoss Enterprise Application Platform 6 corre como un dominio gestionado.

Modules/

Los módulos que son dinámicamente cargados por la JBoss Enterprise Application Platform 6 cuando los servicios se solicitan.

Standalone/

Archivos de configuración, contenido de despliegue y áreas que se pueden escribir, usadas cuando JBoss Enterprise Application Platform 6 corre como un servidor independiente.

Welcome-content/

Contiene el contenido usado por la aplicación web Bienvenida que está disponible en el puerto 8080 de una instalación por defecto.

jboss-modules.jar

El mecanismo que mejora que carga módulos.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Directorios dentro del directorio domain/ NOMBRE

PROPÓSITO

Appclient/

Contiene detalles de la configuración para el contenedor del cliente de aplicación.

Configuration/

Los archivos de configuración para el dominio administrado. Estos archivos son modificados por la consola de administración y gestión CLI, y no están destinados a ser editado directamente.

Data/

Información sobre servicios implementados. Los servicios se implementan utilizando la consola de administración y gestión CLI. Por lo tanto, no se deben colocar los archivos en este directorio manualmente

Log/

Contiene los archivos de registro de tiempo de ejecución de los controladores de host y el proceso que se ejecutan en la instancia local.

Servers/

Contiene los equivalentes a los directorios data/ log/ tmp/ para cada instancia de servidor en un dominio, que contienen datos similares a los mismos directorios dentro del dominio / directorio de nivel superior.

Tmp/

Contiene datos temporales, como los archivos relacionados con el mecanismo de clave compartida utilizada por la administración CLI para autenticar a usuarios locales del dominio administrado.

105

106

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Directorios dentro del directorio standalone/ Nombre

Propósito

configuration/

Archivos de configuración para el servidor independiente. Estos archivos son modificados por la consola de administración y gestión CLI, y no están destinados a ser editados directamente.

deployments/

Información sobre servicios implementados. El servidor independiente sí incluye un escáner de implementación, por lo que puede colocar los archivos en el directorio que se desplegarán. Sin embargo, el enfoque recomendado es gestionar desarrollos utilizando la consola de administración o de gestión CLI.

lib/

Bibliotecas externas que se refieren a un modo de servidor independiente. La forma predeterminada está vacía.

tmp/

Contiene datos temporales, como los archivos relacionados con el mecanismo de clave compartida utilizada por la administración CLI para autenticar a usuarios locales del servidor.

El concepto de perfiles que se usó en versiones anteriores de la Plataforma ya no se usa. JBoss Enterprise Application Platform 6 ahora usa un pequeño número de archivos de configuración para gestionar toda la información sobre su configuración. Los módulos y los drivers se cargan de forma que el concepto de un perfil por defecto que se usó en versiones anteriores de la Plataforma de la Aplicación de empresa JBoss 6, donde los perfiles eran usados para hacer al servidor comenzar más eficazmente, ya tampoco aplique. En el momento de despliegue, las dependencias del módulo se determinan, se piden, y se responden por el servidor o regulador del dominio, y se cargan correctamente. Es posible inhibir módulos, drivers u otros servicios a mano borrando los subsistemas de la configuración. Sin embargo, para la mayor parte de casos esto es innecesario. Si ninguna de sus aplicaciones usa un módulo, no se cargará.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

La configuración de JBoss Enterprise Application Platform 6 ha cambiado considerablemente desde versiones anteriores. Una de las diferencias más obvias es la utilización de una estructura de archivo de configuración simplificada, que incluye uno o más de los archivos que aparecen a continuación. Localizaciones del Archivo de Configuración Modo de Servicio

Localización

Propósito

domain.xml

EAP_HOME/domain/ configuration/domain. xml

Este es el archivo de configuración de un dominio administrado. Sólo el dominio maestro lee este archivo. En otros miembros del dominio se puede quitar.

EAP_HOME/domain/ configuration/host.xml

Este archivo incluye información de configuración específica de un host físico en un dominio administrado, como los interfaces de red, los enlaces de socket, el nombre del host, y otros detalles específicos del host. El archivo de host.xml incluye todas las características de ambos de host-master.xml y anfitrión-slave.xml, que se describen a continuación. Este archivo no está presente en servidores independientes.

host.xml

host-master.xml

Este archivo incluye sólo los datos de configuración EAP_HOME/domain/ necesarios para ejecutar el servidor como un serviconfiguration/host-masdor maestro de dominio administrado. Este archivo ter.xml no está presente en servidores independientes.

host-slave.xml

Este archivo incluye sólo los datos de configuración EAP_HOME/domain/ necesarios para ejecutar el servidor como un serviconfiguration/host-slave. dor esclavo dominio administrado. Este archivo no xml está presente en servidores independientes.

standalone.xml

Este es el archivo de configuración por defecto para EAP_HOME/standalone/ un servidor autónomo. Contiene toda la informaconfiguration/standalo- ción sobre el servidor independiente, incluyendo subsistemas, redes, despliegues, los enlaces de socne.xml ket, y otros detalles configurables.

standalone-ha.xml

Este archivo de configuración permite al mod_clusEAP_HOME/standalone/ ter y JGroups subsistemas para un servidor indepenconfiguration/standalo- diente, para que pueda participar en un clúster de alta disponibilidad y balanceo de carga. Este archivo ne-ha.xml no es necesario para un dominio administrado.

107

108

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Estas son sólo las ubicaciones predeterminadas. Puede especificar otro archivo de configuración en tiempo de ejecución. Gestión de clientes JBoss Enterprise Application Platform 6 ofrece tres enfoques diferentes para configurar y administrar servidores, siendo una interfaz web, un cliente de línea de comandos y un conjunto de archivos de configuración XML. Mientras que los métodos recomendados para la edición del archivo de configuración incluyen la consola de administración y gestión CLI, las ediciones realizadas de configuración de los tres siempre están sincronizados a través de los diferentes puntos de vista y, finalmente persistido a los archivos XML. Tenga en cuenta que las ediciones realizadas en los archivos de configuración XML, mientras que una instancia de servidor está en ejecución será reemplazado por el modelo de servidor. API nativo Un ejemplo de una herramienta de API nativa es el CLI de gestión. Esta herramienta de gestión está disponible para un entorno administrado o instancia de servidor independiente, permitiendo que el usuario se conecte al controlador de dominio o una instancia de servidor independiente y ejecutar las operaciones de gestión disponibles a través del modelo de gestión. El punto final de la API nativa es el punto de entrada para clientes de gestión que se basan en el protocolo nativo para la integración con la capa de gestión. Se utiliza un protocolo binario abierto y una API RPC sobre la base de un número muy pequeño de tipos de Java para describir y ejecutar las operaciones de gestión. Es utilizado por la herramienta CLI de gestión, y también ofrece capacidades de integración de una amplia gama de clientes. El punto final de la API nativa se incluye con cualquiera de un controlador host o un servidor independiente. Debe estar activada para utilizar la CLI de gestión. Por defecto, se ejecuta en el puerto 9999.

EJEMPLO <management-interfaces> <native-interface interface=”management” port=”9999”/> [...] <management-interfaces>

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

API HTTP La consola de administración es un ejemplo de un interfaz web construido con el Google Web Toolkit (GWT). La consola de administración se comunica con el servidor mediante la interfaz de administración HTTP. El punto final de la API HTTP es el punto de entrada para clientes de gestión que se basan en el protocolo HTTP para la integración con la capa de gestión. Se utiliza un protocolo de codificación JSON y una API, de estilo RPC para describir y ejecutar las operaciones de gestión contra un dominio gestionado o servidor independiente. La API HTTP es utilizado por la consola de web, pero también ofrece capacidades de integración para una amplia gama de otros clientes. El punto final de la API HTTP se incluye con el controlador de dominio o con una instancia de servidor independiente. El punto final API HTTP tiene dos contextos diferentes: uno para ejecutar las operaciones de gestión y otro para acceder a la interfaz web. Por defecto, se ejecuta en el puerto 9990.

EJEMPLO <management-interfaces> [...] <http-interface interface=”management” port=”9990”/> <management-interfaces> La consola web que se sirve a través del mismo puerto que el API de gestión de HTTP. Es importante distinguir entre la consola de administración de acceso como en una máquina local por defecto, la consola de administración como acceder de forma remota por un huésped específico y combinación de puerto y la API de dominio expuesto. http://localhost:9990/console

La Consola de administración de acceso en el host local, el control de la configuración de dominio administrado.

http://localhost:9990/console

La Consola de administración de acceso remoto, nombrando el host y el control de la configuración de dominio administrado.

http://hostname:9990/management

La API de administración HTTP se ejecuta en el mismo puerto que la consola de administración, mostrando los atributos primas y los valores expuestos a la API.

109

110

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Oracle Fusion Middleware Oracle Fusion Middleware es un conjunto de productos de software basados en estándares que se extiende por una amplia gama de herramientas y servicios: de Java EE y las herramientas de desarrollo, los servicios de integración, gestión de identidad, inteligencia de negocios y la colaboración. Oracle Fusion Middleware ofrece soporte completo para el desarrollo, implementación y administración. En concreto, el middleware es el software que conecta componentes de software o aplicaciones empresariales. Middleware es la capa de software que se encuentra entre el sistema operativo y las aplicaciones en cada lado de una red informática distribuida. Normalmente el middleware es compatible con las aplicaciones de software empresarial distribuidos complejos. Middleware es también la infraestructura que facilita la creación de aplicaciones empresariales, y proporciona servicios básicos como la concurrencia, transacciones, mensajería, y el marco de SCA para aplicaciones de arquitectura orientada a servicios (SOA). También ofrece seguridad y permite la funcionalidad de alta disponibilidad para la empresa. Middleware incluye servidores web, servidores de aplicaciones, sistemas de gestión de contenidos y herramientas similares que apoyan el desarrollo de aplicaciones y la entrega. Es esencial para tecnologías de la información basada en Extensible Markup Language (XML), Protocolo de acceso a objetos simple (SOAP), servicios web, SOA, Unicode, la infraestructura Web 2.0 y Lightweight Directory Access Protocol (LDAP). Los datos textuales usa el conjunto de caracteres Unicode para apoyar el intercambio de datos en cualquier idioma. UTF-8 se usa como el estándar de codificación para el transporte de datos para la compatibilidad y la eficiencia óptima, mientras codificaciones no Unicode tradicionales también se pueden utilizar cuando apoyado. Debido al crecimiento continuo y el uso de aplicaciones basadas en la red de las empresas, las tecnologías de middleware son cada vez más importantes. Las empresas y organizaciones están construyendo sistemas de información de toda la empresa mediante la integración de las aplicaciones anteriormente independientes con nuevos desarrollos de software. El proceso de integración puede incluir aplicaciones heredadas que pueden ser utilizados únicamente con, o por medio de una interfaz modificable. En algunos casos, volver a escribir el código para una aplicación de legado puede ser un costo prohibitivo. Cada vez más, los sistemas de información se componen de una colección de varios dispositivos de hardware especializados interconectados por una red. Cada dispositivo lleva a cabo una función que implica la recepción de datos en tiempo real y la interacción remota con otros dispositivos del sistema. Algunos ejemplos

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

incluyen las redes de computadoras, sistemas de telecomunicaciones, fuentes de alimentación ininterrumpidas, y unidades de fabricación descentralizados. La interacción con el sistema de información puede abarcar una amplia gama de rendimiento. Puede interactuar con las aplicaciones de Internet a través de una variedad de dispositivos, cuyas características y rendimiento figuras abarcar una gama cada vez mayor. Entre un alto rendimiento del ordenador personal, un teléfono inteligente y un asistente digital personal, las variaciones en el ancho de banda, potencia de procesamiento local, la capacidad de la pantalla, y la capacidad de mostrar imágenes en color, son muy grandes. Las aplicaciones utilizan software intermedio que se encuentra en la parte superior de los sistemas operativos y protocolos de comunicación para llevar a cabo las siguientes funciones: ––Ocultar la naturaleza distribuida de la aplicación. Representa una colección de piezas interconectadas que están en funcionamiento en ubicaciones distribuidas, fuera de la vista. ––Ocultar la heterogeneidad de la empresa. Esto incluye los componentes de hardware utilizados, sistemas operativos y protocolos de comunicación. ––Proporcionar interfaces, estándar, de alto nivel para los desarrolladores de aplicaciones e integradores, por lo que las aplicaciones pueden ser fácilmente integrados, reutilizados, adaptadas, y hecho para interoperar. ––Suministro de un conjunto de servicios comunes para realizar diversas funciones de uso general para evitar la duplicación de esfuerzos, y para facilitar la colaboración entre aplicaciones. El middleware hace más fácil el desarrollo de aplicaciones, proporcionando abstracciones de programación comunes, mediante la aplicación de enmascaramiento y la distribución de los sistemas operativos y el hardware subyacente, y ocultando los detalles de programación de bajo nivel. La función del middleware es mediar la interacción entre las partes de una aplicación o entre aplicaciones. Por lo tanto, las consideraciones de estructura arquitectónica juegan un papel central en el diseño de middleware. El diseño arquitectónico abarca la organización, la estructura general y los patrones de comunicación, tanto para aplicaciones como para el propio middleware. El Oracle WebLogic Server es una plataforma Java lista para la empresa escalable servidor de aplicaciones Enterprise Edition (Java EE). La infraestructura de Oracle WebLogic Server soporta el despliegue de muchos tipos de aplicaciones distribuidas y es una base ideal para la construcción de aplicaciones basadas en SOA.

111

112

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Java EE es una plataforma ampliamente utilizada para la programación de servidor en el lenguaje de programación Java. La plataforma Java EE se diferencia de la edición estándar de Java que añade las bibliotecas que proporcionan funcionalidad para desplegar, software Java multi-tier distribuido de alta disponibilidad, basado en gran medida en los componentes modulares que se ejecutan en un servidor de aplicaciones. Además de la implementación de Java EE, Oracle WebLogic Server permite a las empresas desplegar aplicaciones críticas de negocio en un entorno robusto, seguro y de alta disponibilidad, administrable y escalable. Estas características permiten a las empresas para configurar clústeres de las instancias de Oracle WebLogic Server para distribuir la carga y proporcionar capacidad adicional en el caso de hardware u otras fallas. Las nuevas herramientas de diagnóstico permiten a los administradores del sistema monitorear y ajustar el rendimiento de las aplicaciones implementadas y el entorno Oracle WebLogic Server en sí. También puede configurar Oracle WebLogic Server para supervisar y optimizar el rendimiento de aplicaciones de forma automática, sin intervención humana. Numerosas funciones de seguridad protegen el acceso a los servicios, mantener los datos empresariales seguros y prevenir ataques maliciosos. Oracle SOA Suite es un componente middleware de Oracle Fusion Middleware. Oracle SOA Suite permite a los servicios que se crean, administran y supervisada en las aplicaciones compuestas SOA. Las aplicaciones compuestas le permiten montar fácilmente varios componentes de la tecnología en una aplicación SOA compuesto. Oracle SOA Suite se usa en infraestructuras heterogéneas y permite a las empresas a adoptar gradualmente SOA. Oracle Identity Management es un sistema de gestión de identidad de la empresa que gestiona automáticamente los privilegios de acceso de los usuarios a los recursos de una empresa. La arquitectura de Oracle Identity Management trabaja con los requisitos empresariales más exigentes sin necesidad de cambios en la infraestructura existente, las políticas o los procedimientos. Los componentes de Oracle Identity Management se ocupan de gestionar todo el ciclo de vida de gestión de la identidad, desde la creación inicial de los privilegios de acceso a adaptar dinámicamente a los cambios en las necesidades de negocio de la empresa.

RECUERDe Middleware provee la capacidad de integración con las bases de datos de Oracle.

Los productos de Oracle de gestión de identidad proporcionan una infraestructura compartida para todas las aplicaciones de Oracle. También ofrece servicios e interfaces que facilitan el desarrollo de aplicaciones empresariales de terceros. Estas interfaces son útiles para los desarrolladores de aplicaciones que deben incorporar la gestión de identidad en sus aplicaciones.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Java Open Application Server (JOnAS): a J2EETM Platform La especificación J2EE SunTM, junto con sus especificaciones relacionadas (EJBTM, JMSTM, ...), define una arquitectura e interfaces para el desarrollo y despliegue de aplicaciones de servidor Java ™ Internet distribuidos basados en una arquitectura multi-tier. Esta especificación tiene la intención de facilitar y estandarizar el desarrollo, despliegue y montaje de componentes de la aplicación, tales componentes se despliegue en plataformas J2EE. Las aplicaciones resultantes se basan normalmente en la web, transacciones, de base de datos orientada, multi-usuario, segura, escalable y portátil. Esta especificación describe dos tipos de información: ––El primero es el entorno de ejecución, llamado un servidor J2EE, que proporciona el entorno de ejecución y el servicios de sistema requerido, tales como el servicio de transacción, el servicio de persistencia, Java Message Service (JMS), y el servicio de seguridad. ––El segundo es el programador y el usuario de la información explicando cómo debe ser un componente de la aplicación desarrollados, desplegados y utilizados. No sólo un componente de aplicación ser independiente de la plataforma y sistema operativo (ya que está escrito en Java), también será independiente de la plataforma J2EE. Una aplicación típica de J2EE se compone de: 1. Componentes de presentación, también llamados “componentes Web” (Servlets y JSPsTM), que definen la interfaz web de la aplicación. 2. Los componentes de la empresa, el “Enterprise JavaBeans” (EJB), que definen la lógica empresarial de la aplicación y los datos de aplicación. El servidor J2EE proporciona contenedores para alojamiento web y los componentes de la empresa. El contenedor proporciona la gestión y las interfaces de los del ciclo de vida de los componentes con los servicios prestados por el servidor J2EE. Hay dos tipos de envases, el contenedor web maneja los componentes servlets y JSP, mientras que el contenedor EJB maneja los componentes de Enterprise JavaBeans. Un servidor J2EE también puede proporcionar un entorno de despliegue de los clientes de Java (acceso EJB), se llama contenedor de cliente.

113

114

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

ObjectWeb JOnAS es un servidor de aplicaciones de código abierto, desarrollado dentro del consorcio ObjectWeb. ObjectWeb es un proceso de la iniciativa de código abierto que puede ser comparado a Apache o Linux, pero en el área de middleware. El objetivo es de ObjectWeb para desarrollar y promover el software middleware de código abierto. ObjectWeb es un Consorcio Internacional organizado por INRIA, fundada oficialmente en febrero de 2002 por Bull, Francia Telecom y INRIA.Todo el software está disponible con la licencia LGPL. El objetivo técnico de este consorcio es desarrollar una tecnología distribuida basada en componentes middleware, en línea con los estándares del W3C CORBA, Java y. La intención es aplicar el modelo de componentes, como ya se ha utilizado en el nivel de aplicación de J2EE y en el modelo de componentes CORBA, en el mismo nivel de middleware. La cobertura funcional de los proyectos ObjectWeb trata de nombres, el comercio, la comunicación (eventos, mensajes), la disponibilidad y la seguridad (transacciones, persistencia, replicación, tolerancia a fallos), equilibrio de carga y seguridad. Algunos temas relacionados también son la robustez, la optimización, la calidad del código, así como puntos de referencia, pruebas, evaluaciones, los manifestantes, y herramientas de desarrollo. Por lo tanto, el modelo arquitectónico ObjectWeb va de arriba hacia abajo de las aplicaciones (como puntos de referencia tales como Rubis del proyecto JMOB) que se ejecutan en plataformas middleware (como JOnAS, OpenCCM o proactiva). Las plataformas están basado en componentes técnicos como Middleware orientado a mensajes (JORAM que implementa JMS), una marco de comunicación (CAROL), un framework de persistencia (Jorm), un marco de consulta de base de datos (MEDOR), una el monitor transaccional (JOTM), un Object Request Broker (Jonathan). Un componente técnico como C-JDBC permite cualquier plataforma para beneficiarse de las agrupaciones de base de datos. JOnAS hace uso de todos estos componentes ObjectWeb (JORAM, CAROL, Jonathan, Jorm, MEDOR, C-JDBC, y pronto JOTM), pero también utiliza componentes de fuente abierta de otros comunidades, tales como Tomcat o embarcadero utilizado como contenedor Web, ni de AXIS se utilizan para proporcionar la “Web Servicios de medio ambiente “. ObjectWeb ya cuenta con un número significativo de miembros: las empresas, las universidades, los miembros individuales (la membresía individual es gratuita). Miembros ObjectWeb contribuyen a orientaciones ObjectWeb y participar en todas las ObjectWeb grupos de trabajo, reuniones, talleres y conferencias. La

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

comunidad de desarrolladores y usuarios que trabajan con Componentes y plataformas ObjectWeb está en constante crecimiento. JOnAS ofrece las siguientes funciones avanzadas importantes: ––Administración: la administración de servidores JOnAS utiliza JMX y proporciona una consola de gestión JSP / Struts-based. ––Servicios: arquitectura basada en servicios de JOnAS ofrece alta modularidad y capacidad de configuración del servidor. ––Permite a los desarrolladores aplicar un enfoque de componentes-modelo a nivel de middleware, y hace que la integración de nuevos módulos sea sencilla (por ejemplo, para los contribuyentes de código abierto).También proporciona una manera de empezar sólo los servicios necesarios en una aplicación concreta, ahorrando valiosos recursos del sistema. Servicios de JOnAS son manejables a través de JMX. ––Escalabilidad: JOnAS integra diversos mecanismos de optimización para aumentar la escalabilidad del servidor. Esto incluye un conjunto de beans de sesión sin estado, un conjunto de beans controlados por mensajes, un grupo de subprocesos, un conjunto de beans de entidad, activación / inhibición de beans de entidad, un grupo de conexiones (para JDBC, JMS, J2EE CA), acceso de almacenamiento optimizaciones (bandera compartida, IsModified). ––Clustering: soluciones de clustering JOnAS, tanto a nivel Web y EJB, proporcionar equilibrio de carga, alta disponibilidad y soporte de conmutación por error. ––Distribución: JOnAS trabaja con varios entornos de procesamiento distribuido, debido a la integración de la CAROL proyecto ObjectWeb (Arquitectura Común para RMI ObjectWeb Layer), que permite soporte simultáneo de varios protocolos de comunicación: ––RMI mediante el Sun protocolo propietario JRMP ––RMI sobre IIOP ––CMI, el protocolo de distribución de “clústeres” de JOnAS ––Jeremie, la personalidad de un RMI Object Request Broker llamado Jonathan, desde ObjectWeb. ––Usado con Jeremie o JRMP, JOnAS se beneficia de optimización local transparente llamada RMI. ––Apoyo a Servicios Web: Debido a la integración de AXIS, JOnAS permite que los componentes J2EE para acceder a Servicios Web (es decir, como Servicios Web clientes), y permite a los componentes de J2EE que se desplegarán como puntos de Servicios Web finales. Es compatible con el estándar de clientes de servicios web y el despliegue puntos finales, según lo especificado en J2EE 1.4. ––Soporte de JDO: Mediante la integración de la aplicación ObjectWeb de JDO, Speedo, y su asociado J2EE

115

RECUERDe ObjectWeb es una asociación que dicta reglas para la construcción de mejores aplicaciones Web.

116

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

––Adaptador de recursos de CA, JOnAS proporciona la capacidad de utilizar JDO dentro de los componentes J2EE. Tres aspectos críticos J2EE se implementaron desde el principio en el servidor JOnAS: ––J2EECA: Sistemas de información empresarial (EIS) se puede acceder fácilmente desde las aplicaciones de JOnAS. Para apoyar el Java Connector Architecture, JOnAS permite el despliegue de cualquier J2EE CA cumple con los recursos Adaptador (conector), lo que hace el EIA correspondiente disponible en los componentes de aplicaciones J2EE. Por ejemplo, al Bull SMOC mainframes se puede acceder desde JOnAS con sus conectores HooX asociados. Por otra parte, los adaptadores de recursos se convertirá en la forma “estándar” para conectar controladores JDBC (y la aplicación JMS, con J2EE 1.4) a las plataformas J2EE. Un adaptador de recursos JDBC está disponible con JOnAS, que proporciona a JDBC la puesta en común y se puede utilizar en lugar del servicio de JOnAS DBM. A JORAM JMS Recursos adaptador también está disponible. ––JMS: las implementaciones de JMS pueden ser fácilmente conectados a JOnAS. Funcionan como un servicio JOnAS en el mismo JVM (Java Virtual Machine) o en una JVM por separado, y JOnAS disponen de servicio de la administración que ocultan la JMS patentada API de administración. En la actualidad, se pueden utilizar tres implementaciones de JMS: la JORAM abierto fuente de la aplicación JMS de ObjectWeb, SwiftMQ y Websphere MQ. J2EE CA Adaptadores de recursos

RECUERDe JonAS emplea las bases de J2EE, ampliándose y especializándose en aplicaciones web.

También están disponibles, proporcionando una forma más estándar para conectar JORAM o SwiftMQ a JOnAS. ––JTA: La plataforma JOnAS soporta transacciones distribuidas que implican múltiples componentes y recursos transaccionales. El apoyo de transacciones JTA es proporcionada por un monitor de transacciones que ha sido desarrollado en una implementación del servicio de transacciones CORBA (OTS). IBM LOTUS IBM Lotus Domino Document Manager (anteriormente Domino.Doc) es la solución de gestión documental construida para el mundo actual con una informática distribuida basada en la red.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

117

Fue diseñado para satisfacer las demandas de la red ubicando de una forma eficiente respecto de la gestión de la integridad del trabajo colaborativo. El Lotus Domino Document Manager proporciona funcionalidad de gestión de documentos. Lotus Domino Document Manager 6.5.1 compatible con estas plataformas de servidor: ––AIX 5.1 y 5.2 ––Solaris 8 y 9 ––OS/400 V5R1 y V5R2 ––NT Windows 2000 Advanced Server y 2003 Server Puede instalar gestor de documentos en un único servidor o en varios servidores. Si se va a instalar Document Manager en un servidor de réplica, es necesario designar y configurar un servidor maestro Document Manager antes de instalar cualquier servidor de réplica. Cada red debe tener al menos un gestor de documentos definido como servidor maestro. MACROMEDIA COLD FUSION MX7 ColdFusion MX es un potente servidor de aplicaciones web que te permite crear sitios robustos y aplicaciones sin una larga curva de aprendizaje. ColdFusion MX no requiere codificación tradicional basada en lenguajes de programación (por ejemplo, C, C + +, Java, XML), a pesar de que apoya los tradicionales lenguajes de programación. ColdFusion MX consta de los siguientes componentes principales: - El servidor de aplicaciones ColdFusion - ColdFusion Markup Language (CFML) - ColdFusion MX administrador En las siguientes secciones se describen estos componentes básicos con mayor detalle. El servidor de aplicaciones ColdFusion es en sí mismo una aplicación web que normalmente reside en el mismo equipo que el software del servidor web. Es el programa que analiza (lee e interpreta) instrucciones suministradas por procesos. Estas instrucciones se pasan a ColdFusion a través de páginas de ColdFusion, que utilizan una extensión de nombre de archivo. cfm o. cfc. Una página de ColdFusion

RECUERDe IBM Lotus es un producto comercial de pago que también sirve de herramienta de ayuda a los desarrolladores de aplicaciones Web.

118

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

se parece a una página HTML, pero contiene etiquetas especiales que indican que el servidor de ColdFusion realiza operaciones específicas. ColdFusion Markup Language (CFML) es un lenguaje basado en etiquetas similares a HTML que utiliza especiales etiquetas y funciones. Con CFML, puede mejorar sus archivos HTML estándar con la base de datos comandos, operadores condicionales y funciones de formato de alto nivel, y rápidamente producen aplicaciones web fáciles de mantener. CFML es similar al HTML: incluye etiquetas de inicio y fin, y cada etiqueta se incluye en corchetes. Todas las etiquetas que terminan se preceden por una barra inclinada (/) y todos los nombres de las variables están precedidas con cf. Se utiliza el Administrador de ColdFusion MX para configurar y mantener el servidor de aplicaciones ColdFusion. Se trata de una aplicación basada en la web que se puede acceder con cualquier navegador web, desde cualquier ordenador con una conexión a Internet. Puede administrar las opciones de configuración con el administrador de ColdFusion MX: ––Fuentes de datos ColdFusion ––Salida de depuración ––Configuración del servidor ––Seguridad de las aplicaciones Los siguientes pasos explican cómo el servidor ColdFusion procesa una página ColdFusion: ––El servidor ColdFusion analiza el contenido de la página y busca las siguientes instrucciones de ColdFusion: ––Los nombres de etiquetas que comienzan con cf. ––Variables y funciones que siempre están rodeados de signos de número (#). ––Si el servidor ColdFusion encuentra alguna HTML o texto sin formato en la página, el servidor ColdFusion devuelve al servidor web sin cambios. ––El servidor ColdFusion procesa todas las instrucciones de ColdFusion encontrados, y devuelve los resultados que quedaron en el servidor web. El servidor web envía toda la salida al navegador A construir aplicaciones ColdFusion como una serie de páginas que utilizan CFML. Los desarrolladores pueden ampliar esta lengua mediante la creación de sus propias etiquetas personalizadas o funciones definidas por el usuario (UDF), o mediante la integración de COM, C + +, Java y componentes, tales como Java

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

119

Server Page (JSP) bibliotecas de etiquetas. Aplicaciones ColdFusion pueden interactuar con cualquier base de datos que soporta un conductor basado en la tecnología JDBC. Un conductor basado en la tecnología JDBC utiliza una interfaz de programación de aplicaciones (API) para ejecutar sentencias SQL para bases de datos en la mayoría de las plataformas. Sin embargo, ColdFusion no se limita a fuentes de datos JDBC. También puede interactuar con conectividad existente (Open Database) orígenes de datos mediante ODBC Socket, un conductor que interactúa con un controlador ODBC existente. ColdFusion MX 7 permite crear aplicaciones que pueden responder a eventos y mensajes de diversas fuentes, incluyendo mensajería instantánea, teléfono móvil Servicio de mensajes cortos (SMS) Mensajes de texto, las solicitudes de socket de Internet y los eventos del sistema. Se puede codificar su aplicación ColdFusion con el Bloc de notas o cualquier editor de HTML, sin embargo, Macromedia recomienda que cree sus aplicaciones usando Macromedia Dreamweaver MX. Dreamweaver MX ofrece funciones y asistentes que mejoran el desarrollo ColdFusion. Java Web Services Development Pack

RECUERDe

JAX-WS es sinónimo de API de Java para servicios web XML. JAX-WS es una tecnología para la creación de servicios web y clientes que se comunican usando XML. JAX-WS permite a los desarrolladores escribir servicios web RPC orientadas orientado a mensajes.

No es necesaria una herramienta especial para implementar ColdFusion, pudiendo realizarla hasta en un bloc de notas.

En JAX-WS, una llamada a procedimiento remoto se representa mediante un protocolo basado en XML como SOAP. La especificación SOAP define la estructura del sobre, las reglas de codificación, y las convenciones para representar llamadas a procedimientos remotos y respuestas. Estas llamadas y respuestas se transmiten como mensajes SOAP (archivos XML) sobre HTTP. Aunque los mensajes SOAP son complejos, el API JAX-WS oculta esta complejidad desde el desarrollador de aplicaciones. En el lado del servidor, el desarrollador especifica los procedimientos remotos mediante la definición de los métodos de un interfaz escrito en el lenguaje de programación Java. El desarrollador también realiza los códigos de una o más clases que implementan esos métodos. Los programas cliente también son fáciles de código. Un cliente crea un proxy (un objeto local que representa el servicio) y luego simplemente invoca métodos en el proxy. Con JAX-WS, el desarrollador no generar o analizar mensajes SOAP. Es

120

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

el sistema de tiempo de ejecución JAX-WS que convierte las llamadas a la API y respuestas hacia y desde los mensajes SOAP. Con JAX-WS, clientes y servicios web tienen una gran ventaja: la independencia de la plataforma del lenguaje de programación Java. Además, JAX-WS no es restrictiva: un cliente JAX-WS se puede acceder a un servicio web que no se ejecuta en la plataforma Java, y viceversa. Esta flexibilidad es posible gracias a JAX-WS utiliza tecnologías definidas por el Consorcio World Wide Web (W3C): HTTP, SOAP, y el Web Service Description Language (WSDL). WSDL especifica un formato XML para la descripción de un servicio como un conjunto de puntos finales que operan en los mensajes. El punto de partida para desarrollar un servicio web JAX-WS es una clase Java anotada con la anotación javax.jws.WebService. La anotación WebService define la clase como un punto final de servicios web. Una interfaz de extremo de servicio (SEI) es una interfaz Java que declara los métodos que un cliente puede invocar en el servicio. Un SEI no se requiere en la construcción de un punto final de JAX-WS. La clase de implementación del servicio Web define implícitamente una SEI. Se puede especificar una SEI explícita añadiendo el elemento endpointInterface a la anotación WebService en la clase de implementación. A continuación, se debe proporcionar un SEI que define los métodos públicos puestos a su disposición en la clase de implementación de punto final. Se utiliza la clase de implementación de punto final y la herramienta wsgen para generar los artefactos de servicios web y los talones que conectan un cliente de servicios web para el tiempo de ejecución JAX-WS. En conjunto, la herramienta wsgen y el servidor de aplicaciones proporcionan la implementación del servidor de aplicaciones de JAX-WS. Estos son los pasos básicos para crear el servicio web y el cliente:

RECUERDe JAX-WS no es una herramienta, sino un API de Java.

––El Código de la clase de implementación. ––Compilar la clase de implementación. ––Despliegue el archivo WAR. Las clases de unión (que se utilizan para comunicarse con los clientes) son generados por el servidor de aplicaciones durante la implementación. ––El Código de la clase de cliente. ––Utilice wsimport para generar y compilar los archivos de código auxiliar. ––Compile la clase de cliente. ––Ejecute el cliente.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

StAX StAX permite crear analizadores XML Bidrectional que son rápidos, relativamente fácil de programar, y tienen una huella de memoria luz. StAX ofrece la última API de la familia JAXP, y ofrece una alternativa a SAX, DOM, Trax y DOM para los desarrolladores que buscan hacer stream de alto rendimiento de filtrado, procesamiento y modificación, en particular con los requisitos de extensibilidad limitada y poca memoria. El proyecto fue encabezado por StAX BEA con el apoyo de Sun Microsystems, y la especificación JSR 173 aprobó el Proceso de votación la aprobación definitiva Java, en marzo de 2004. El objetivo principal de la API StAX es dar “control de análisis para el programador mediante la exposición de un iterador sencillo basado API. Esto permite al programador solicitar el siguiente evento (tirar del evento) y permite que el estado se almacena en forma de procedimiento.” StAX fue creado para hacer frente a las limitaciones en las dos APIs de análisis más frecuente, SAX y DOM. En términos generales, existen dos modelos de programación para trabajar con conjuntos de información XML: streaming de documentos y el Document Object Model (DOM). El modelo DOM implica la creación de objetos en memoria que representa un árbol de documento completo y el estado conjunto de información completa para un documento XML. Una vez en la memoria, se puede navegar libremente por los árboles DOM y analizan arbitrariamente, proporcionando la máxima flexibilidad para los desarrolladores. Sin embargo, el coste de esta flexibilidad es potencialmente una gran capacidad de memoria y los requisitos significativos del procesador, como la totalidad de la representación del documento debe ser mantenido en la memoria como objetos para la duración del procesamiento de documentos. Esto puede no ser un problema cuando se trabaja con documentos pequeños, pero los requisitos de memoria y el procesador puede crecer rápidamente con el tamaño del documento. Streaming se refiere a un modelo de programación en el que se transmiten conjuntos de información XML y analizan en serie en tiempo de ejecución de aplicación, a menudo en tiempo real, y, a menudo a partir de fuentes dinámicas cuyo contenido no se conoce con precisión de antemano. Por otra parte, los analizadores basados en streams pueden comenzar a generar la salida de inmediato, y los elementos de conjunto de información pueden ser descartados inmediatamente después de su uso. Además de proporcionar una huella más pequeña de memoria, la reducción de los requisitos de procesador, y un mayor rendimiento en determinadas situaciones, la disyuntiva principal de procesamiento de flujo es

121

122

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

que sólo se puede ver el estado del conjunto de información en un solo lugar a la vez en el documento. Usted está esencialmente limitado a la vista “de cartón tubo” de un documento, lo que implica que usted necesita saber lo que el procesamiento que quieres hacer antes de leer el documento XML. Modelos de streaming para el procesamiento de XML es particularmente útil cuando la aplicación tiene estrictas limitaciones de memoria, al igual que con un teléfono móvil J2ME corriendo, o cuando la aplicación necesita procesar simultáneamente varias peticiones, como un servidor de aplicaciones. De hecho, se puede argumentar que la mayoría de la lógica de negocio XML puede beneficiarse de procesamiento de flujos, y no requiere el mantenimiento en memoria de los árboles DOM enteras. La transmisión de análisis sintáctico de empuje se refiere a un modelo de programación en el que un analizador XML envía (empuja) de datos XML para el cliente como el analizador encuentra elementos en un conjunto de información XML - es decir, el analizador envía los datos si el cliente está listo para usar en ese momento. La especificación StAX define un número de usos de los casos de la API: ––El enlace de datos ––Unmarshalling un documento XML ––Marshalling un documento XML ––Procesamiento de documentos en paralelo ––La comunicación inalámbrica ––Procesamiento de mensajes SOAP ––Analizar las estructuras predecibles simples ––Analizar las representaciones gráficas con referencias a plazo ––Analizar WSDL ––Fuentes de datos virtuales ––Viendo como datos XML almacenados en bases de datos –– Visualización de datos en objetos Java creados por los datos XML vinculantes ––Navegando un árbol DOM como un flujo de eventos ––Analizar vocabularios XML específicos –– Procesamiento XML Pipelined Como una API en la familia JAXP, StAX se puede comparar, entre otras API, de SAX, Trax y JDOM. De los dos últimos, StAX no es tan potente o flexible como TRAX o JDOM, pero tampoco requiere tanta memoria o la carga del procesador para ser útil, y StAX puede, en muchos casos, superan a las API de DOM-based.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

123

Los mismos argumentos descritos anteriormente, con un peso del costo / beneficios del modelo DOM en comparación con el modelo de streaming, se aplican aquí. Con esto en mente, las comparaciones más cercanas entre se pueden hacer entre StAX y SAX, y es aquí donde StAX ofrece características que son beneficiosos en muchos casos, algunos de estos incluyen: ––StAX clientes habilitados son generalmente más fáciles de código de los clientes SAX. Si bien se puede argumentar que los analizadores SAX son ligeramente más fáciles de escribir, código de análisis StAX puede ser más pequeño y el código necesario para que el cliente interactuar con el programa de análisis más simple. ––StAX es una API bidireccional, lo que significa que puede leer y escribir documentos XML. SAX es de sólo lectura, por lo que se necesita otra API si desea escribir documentos XML. ––SAX es un API de empuje, mientras que StAX es pull. 2.3.2 Bibliotecas y entornos integrados (frameworks) de uso común El IDE (en inglés de integrated development environment) o entorno de desarrollo integrado es un software que se compone de un conjunto de herramientas de programación, que utiliza uno o varios lenguajes de programación. IDE se puede definir también como un entorno de programación empaquetado como una sola aplicación; O sea, contiene el editor de código, el compilador, el depurador y la GUI (constructor de interfaz gráfica). Los IDE pueden utilizarse como una aplicación por sí sola o ser parte de otras aplicaciones existentes. Por ejemplo, en el lenguaje Visual Basic, puede usarse dentro de las propias aplicaciones Microsoft Office. Esto hace posible poder escribir sentencias Visual Basic en forma de macros para Word. Los IDE son compatibles con la gran mayoría de lenguajes de programación como Visual Basic ,C++,Python, Java, C#, Delphi, PHP… En algunos de estos lenguajes, un IDE funciona como un sistema en tiempo de ejecución, donde es permitido utilizar los lenguajes de programación de una forma interactiva, sin la necesidad de trabajar orientándose a archivos de texto, como por ejemplo Smalltalk u Objective-C. Muchos de los entornos IDE son compatibles con lenguajes de programación basados en java, como NetBeans o Eclipse. También con otros lenguajes basados en C#MonoDevelop. Puede incorporarsetambien la funcionalidad para otro tipo

RECUERDe STAX es una API muy útil para códigos especializados en streaming.

124

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

de lenguajes alternativos usandoplugins. Eclipse y NetBeans por ejemplo tienen plugins para C, C++, Ada, Perl, Python, Ruby, PHP. En los sistemas basados en Microsoft Windows, las herramientas de línea de comando no son de uso común. Para ello, hay otras soluciones comerciales y no comerciales. La mayoría de los proveedores de compiladores para sistemas Windows ofrecen copias gratuitas de estas herramientas de línea de comando. Otros entornos libres, como Netbeans, Code-Blocks, Eclipse, KDevelop o Lazarus se desarrollan utilizando un lenguaje multiplataforma como Pascal o Java. Ademas, puede ejecutarse en diversas plataformas como Windows, Linux, o Mac OS X. Frameworks Un Framework es una aplicación o conjunto de módulos que permiten el desarrollo de aplicaciones mediante la aportación de funcionalidades o librerías ya creadas para que las podamos usar directamente. El empleo de frameworks presenta ventajas en un periodo razonable de tiempo, mejoras tales como en el mantenimiento de la aplicaciones, en el código, en las ampliaciones y en las mejoras. Los frameworks suelen basarse en un patrón de diseño Model-View-Controller o MVC. Esto significa que nuestra aplicación debería tener tres capas por lo menos:Vista, modelo y controlador. Los frameworks nos ayudan en los procesos de desarrollo para nuestra aplicación siguiendo el patrón de diseño MVC e implementado las tres capas de las que hemos hablado. La capa vista es la capa de presentación. Es decir, es la manera en como los datos se presentan al usuario final. La capa modelo se encarga de trabajar con los datos, almacenándolos en una base de datos, por ejemplo. El controlador es el mediador entre las otras dos capas. La vista, normalmente, utiliza los datos del modelo, pero no tiene comunicación directa con el modelo. Es decir, la vista demanda los datos al controlador y éste al modelo, que es el que maneja los datos en la forma que hemos definido nuestra lógica de aplicación y nos devuelve la respuesta de nuevo al controlador. Este último, entrega la respuesta a la vista para poder ser renderizada.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

125

Los frameworks tienen una serie de reglas de convención que hay que aplicar. Una de las reglas sería, por ejemplo, la estructuración de directorios. Montando una buena jerarquía de directorio, conseguiremos localizar rápidamente los códigos que necesitemos. Muchos frameworks también permiten una libertad total para obviar las convenciones por defecto y poder así crear otras propias. Con Frameworks se puede desarrollar una librería propia con iguales funcionalidades, que nos permitirán alcanzar un gran nivel de testeo. Muchos de los frameworks disponibles poseen una comunidad de usuarios. En esta comunidad, algunos usuarios desarrollan extensiones o módulos para el frameworks, distribuyéndolos gratuitamente. Con esto conseguimos que muchas funcionalidades puedan incorporarse en nuestra aplicación sin necesidad de desarrollarla. Crea un estándar, por lo que es mucho más sencillo trabajar con ellos si el equipo de desarrollo conoce el funcionamiento del Framework.

RECUERDe Usando Frameworks se pueden realizar librerías propias.

126

Resumen Resumen Características generales de las arquitecturas de servicios distribuidos La arquitectura de servicios distribuidos se define como un entorno de aplicaciones de negocio que permite programar, distribuir e integrar estos en diferentes plataformas. El modelo conceptual de la Arquitectura orientada a servicios puede dividirse en tres servicios que hay que identificar y que interactúan entre ellos: ––Proveedor de servicio: Provee la descripción del servicio y la implementación de este. ––Consumidor de servicio: Invoca el servicio utilizando y puede encontrar la descripción del servicio a través de un registro de servicio. ––Service Broker: Es que el que proporciona y mantiene el servicio Asimismo, puede basarse en dos tipos: ––Basados en mensajes: La estructura de red (hardware y software) se comunica a través de unos protocolos preestablecidos. ––Basados en recursos: Basamos entonces la distribución de estos entre las máquinas de la red, haciendo así desaparecer la dualidad remoto-local. Servicio El servicio ha de estar bien definido y tener un interfaz que permita el procesamiento y cuya implementación sea reemplazable. La medición de la calidad del servicio se puede hacer por diferentes parámetros como son Interoperabilidad, Fiabilidad, Disponibilidad, Usabilidad, Seguridad, Rendimiento, Escalabilidad, Extensibilidad y Adaptabilidad. Control de acceso. El modelo RBAC El modelo RBAC o control de acceso basada en roles es una función de seguridad con la cual podemos controlar todos los accesos a tareas a las que solo tienen acceso ciertos usuarios. Esto se consigue mediante la aplicación de atributos de seguridad. RBAC puede dividir los roles en el Administrador principal, Root, Administrador del sistema y operador.

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

Protocolos seguros Existen tres tipos de protocolos seguros: SSH, SSL y TSL. REST: (Representational State Transfer) es una arquitectura de software pensada para sistemas distribuidos basados en hiper-media. Actualmente el concepto de las arquitecturas REST se utiliza para referirse a una interfaz web que utiliza XML y HTTP sin ningún conjunto de cabeceras como podría ser en el caso de SOAP y XML-RPC. Se pueden diseñar interfaces XML + HTTP siguiendo la filosofía de Remote Procedure Call sin utilizar la complejidad del protocolo SOAP. Se puede definir también como una familia de arquitecturas: una arquitectura de servicios distribuidos que sea congruente con una serie de requisitos se puede considerar como una arquitectura REST. Los requisitos de una arquitectura REST son los siguientes: WSDL WSDL describe los servicios como colecciones de puntos de red finales o puertos. La especificación WSDL trabaja con un formato XML para todos los documentos. Estándares de seguridad en servicios Web Los estándares principales son WS-Security, SAML y XACML. Directorios de Servicios Un directorio de servicio es una aplicación o varias aplicaciones que almacenan y organizan la información de los usuarios de una red, y que permite a los administradores gestionar los accesos de los usuarios a los recursos. Podemos basar la gestión y el diseño de un servicio de directorio en dos conceptos básicos: La réplica y la distribución Estándares sobre directorios de servicios: UDDI Es el catálogo de negocios de Internet o UDDI, también denominado Universal Description, Discovery and Integration. Este registro en el catálogo se almacena en XML y tiene tres partes:

127

128

Unidad didáctica 2. Programación de servicios web en entornos distribuidos

––Páginas Blancas ––Páginas Amarillas ––Páginas Verdes Directorios distribuidos Uno de los estándares en los que se basa la gran mayoría de implementaciones es el X500 (LDAP) que utiliza el protocolo TCP/IP y no el modelo OSI. Componentes software para el acceso a servicios distribuidos Siguiendo el modelo cliente-servidor tiene los siguientes componentes: ––Lado servidor: La programación se ejecuta en un ordenador conectado a una red. ––Lado cliente: Son los programas que ejecuta el usuario de la aplicación. ––Protocolo de aplicación: Son los protocolos que se utilizan para la comunicación entre el servidor y el cliente. ––Formato de los mensajes: El formato de mensajes que se intercambian, son muchas veces parte del servicio.

Unidad did谩ctica 2. Programaci贸n de servicios web en entornos distribuidos

129

Bibliografía Bibliografía • F.J. Soriano/J.J. Moreno/J. Garbajosa. Tecnologías Software orientadas a objetos. Ed. Fundación Madrid para el conocimiento, 2006. • Joan Rivas Lequerica. Web Services. Guía rápida para usuarios. Ed. Anaya Multimedia, 2011 • Alonso, Gustavo. Web Services. Springer, 2004. • Barry, Douglas. Web Services, SOA y Cloud Computing. Morgan Kaufmann, 2013

Glosario Glosario Algoritmo DSA Estándar para firmas digitales del Gobierno de EE.UU. Sirve para firmar y cifrar información. Requiere más tiempo de cómputo que el RSA. Algoritmo RSA Método de encriptado de datos usado para la transmisión segura de datos a través de canales inseguros. Anillo de seguridad También llamados dominios de protección jerárquica son el conjunto de mecanismos que permiten proteger los datos y tener tolerancia a errores. Asimismo, evita comportamientos maliciosos en los terminales. Autoridad de Certificación Prestador de servicios de certificación que actúa como tercero, siendo de confianza reconocida por los dos elementos implicados en una transacción: el firmante, o titular del certificado, y el usuario receptor del certificado Certificados digitales Un certificado digital o certificado electrónico es un documento en el que un prestador de certificación firma el documento, vinculando los datos de verificación de firma a un firmante confirmando así su identidad. Es un documento que permite al firmante identificarse en Internet. De esta forma, permite garantizar la confidencialidad de las comunicaciones entre el emisor y el receptor, ya que permite autentificar a ambos. Criptografía Genéricamente, podemos describir la criptografía como las técnicas que permiten cifrar un mensaje para hacerlo ininteligible sin recurrir a una acción concreta. Normalmente, en los casos de archivos de texto, se transforman las letras que conforman el mensaje números en forma de bits para luego realizar los cálculos y poder modificarlos o leerlos. Directorios distribuidos El servicio de directorio es un sistema de software que organiza, almacena y proporciona el acceso a toda la información contenido en un directorio, permitiendo la búsqueda de valores por nombre. Firma digital Método criptográfico que asocia la identidad de una persona o de un equipo informático al mensaje o documento. En función del tipo de firma, puede, además, asegurar la integridad del documento o mensaje.

131

132

Firma electrónica Conjunto de datos en forma electrónica, consignados junto a otros o asociados a ellos, que pueden utilizarse como medio de identificación del firmante. HTTP Es el protocolo usado en todas las transacciones Weby ha sido desarrollado por el World Wide Web Consortium e Internet Engineering Task Force. OOMethod OOMethod o programación orientada a objetos es un paradigma de la programación que representa conceptos como “objetos” que contienen campos de datos y una serie de procedimientos asociados también conocidos como métodos. Por lo general, los objetos se utilizan para interactuar entre ellos en aplicaciones de diseño y software. C + + y Java son dos de los más utilizados. Protocolo OAI/PMH Son las siglas de Protocolo de la iniciativa de archivos abiertos para la recolección de metadatos. Se trata de un conjunto de servicios que se invocan a través del protocolo HTTP. Superusuario (Root) En sistemas operativos Linux o UNIX, root es el nombre de usuario que tiene todos los derechos en todos los modos y la que utilizará el administrador. Este usuario se utiliza para cambiar los permisos de archivos y estructuras, por ejemplo. XML En inglés de eXtensible Markup Language es un lenguaje de marcas desarrollado por W3C. Deriva del lenguaje SGML y permite definir la gramática de lenguajes específicos. XML ofrece soporte a bases de datos. Esto es útil cuando dos o más aplicaciones se tienen que comunicar entre sí o integrar la información.

Certiﬁcado de Profesionalidad

IFCD0210

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB

as competencias profesionales que se adquieren con este Certificado de Profesionalidad son desarrollar documentos y componentes software que constituyan aplicaciones informáticas en entornos distribuidos. utilizando tecnologías web, partiendo de un diseño técnico ya elaborado, realizando la verificación, documentación e implantación de los mismos.

Módulos formativos y Unidades formativas MF0491_3: Programación web en el entorno cliente uF1841: elaboración de documentos web mediante lenguajes de marca uF1842: desarrollo y reutilización de componentes software y multimedia mediante lenguajes de guión uF1843: Aplicaciones técnicas de usabilidad y accesibilidad en el entorno cliente

uF1844: desarrollo de aplicaciones web en el entorno servidor uF1845: Acceso a datos en aplicaciones web del entorno servidor uF1846: desarrollo de aplicaciones web distribuidas MF0493_3: Implantación de aplicaciones web en entorno internet, intranet y extranet

ISBN: 978-84-16047-35-2

MF0492_3: Programación web en el entorno servidor