Desarrollo de aplicaciones web distribuidas.

Desarrollo de
aplicaciones web
distribuidas.
Programación web en el entorno servidor
12/12/2017
José Miguel Castillo Castillo

DESARROLLO DE APLICACIONES WEB DISTRIBUIDAS
1
INDICE DE CONTENIDO. DESARROLLO DE APLICACIONES WEB DISTRIBUIDAS
1. ARQUITECTURAS DISTRIBUIDAS ORIENTADAS A SERVICIOS
1.1 Características de las arquitecturas de servicios distribuidos
1.2 Modelo conceptual
1.3 Aspectos de seguridad
1.4 Implementación de arquitecturas orientadas a servicios
1.5 Implementación de la seguridad
1.6 Directorios de servicios
1.7 Cuestionario: cuestionario de evaluación
2. PROGRAMACIÓN DE SERVICIOS WEB EN ENTORNOS DISTRIBUIDOS
2.1 Componentes software para el acceso a servicios distribuidos
2.2 Programación de diferentes tipos de acceso a servicios
2.3 Herramientas para la programación de servicios web

2
1. ARQUITECTURAS DISTRIBUIDAS ORIENTADAS A SERVICIOS
La definición más extendida de las arquitecturas distribuidas es que se trata de sistemas cuyos
componentes hardware y software se encuentran en ordenadores conectados en red coordinando
las acciones mediante el paso de mensajes u otras técnicas para conseguir un objetivo común.
Habitualmente se establece la comunicación mediante un protocolo prefijado por un esquema
cliente-servidor.
1.1. Características generales de las arquitecturas de servicios distribuidos
Casi todos los grandes sistemas informáticos son en la actualidad sistemas distribuidos.
La ingeniería de sistemas distribuidos tiene mucho en común con la ingeniería de cualquier otro
software pero existen cuestiones específicas que deben tenerse en cuenta cuando se diseña este tipo
de sistemas.
Colouris estableció como seis las características principales responsables de la utilidad de los
sistemas distribuidos. Se trata de compartición de recursos, apertura (openness), concurrencia,
escalabilidad, tolerancia a fallos y transparencia.
Se identifican las siguientes ventajas del uso de una aproximación distribuida para el desarrollo de
sistemas:
Compartir recursos. Un sistema distribuido permite compartir recursos hardware y software (discos,
impresoras, ficheros y compiladores) que se asocian con ordenadores de una red.
El término recurso es el que mejor abarca toda la variedad de entidades que pueden compartirse en
un sistema distribuido incluyendo componentes hardware como discos e impresoras hasta
elementos software como ficheros, ventanas, bases de datos y otros objetos de datos.
La idea de compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos.
Los sistemas multiusuario clásicos prevén compartir recursos entre sus usuarios aunque esta acción
se hace de manera natural entre todos sus usuarios. Los usuarios de estaciones de trabajo
monousuario o computadoras personales dentro de un sistema distribuido no obtienen
automáticamente los beneficios de la compartición de recursos.
Los recursos en un sistema distribuido están físicamente encapsulados en una de los ordenadores y
sólo pueden ser accedidos por otros equipos mediante las comunicaciones en red. Para que la
compartición de recursos sea efectiva debe ser manejada por un programa que ofrezca un interfaz
de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera
fiable y consistente. Todo esto lleva a la definición de gestor de recursos.

3
Para muchos autores un gestor de recursos es un módulo software que maneja un conjunto de
recursos de un tipo concreto en particular.
Cada uno de estos tipos de recursos requiere métodos específicos junto con requisitos comunes para
todos ellos. Se suele hablar de la utilización de un esquema de nombres para cada clase de recurso
para poder ser accedidos desde cualquier localización.
Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y
un conjunto de programas que usan los recursos.
Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los
recursos compartidos del sistema. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos:
el modelo cliente-servidor y el modelo basado en objetos.
Apertura.
Los sistemas distribuidos son normalmente sistemas abiertos lo que significa que se diseñan sistema
utilizando protocolos estándar que permiten combinar hardware y software de diferentes
fabricantes.
Un sistema informático es abierto si el sistema puede ser extendido de diversas maneras.
Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (añadir periféricos,
memoria o interfaces de comunicación, etc.) o con respecto a las extensiones software (añadir
características al sistema operativo, protocolos de comunicación y servicios de compartición de
recursos, etc.).
Básicamente los sistemas distribuidos deben cumplir una serie de características:
1. Los interfaces software clave del sistema están claramente especificados y se ponen a
disposición de los desarrolladores.
Los interfaces se hacen públicos.
2. Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de
comunicación entre procesos e interfaces publicados para acceder a recursos compartidos.
3. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software
heterogéneo, posiblemente proveniente de vendedores diferentes.
La conformidad de cada componente con el estándar publicado debe ser cuidadosamente
comprobada y certificada si se quiere evitar tener problemas de integración.
Concurrencia.
Estos procesos pueden (aunque no es obligatorio) comunicarse con otros durante su funcionamiento
normal.
Cuando existen varios procesos en una única maquina decimos que se están ejecutando
concurrentemente. Si el ordenador está equipado con un único procesador central la concurrencia
tiene lugar entrelazando la ejecución de los distintos procesos.
Si la computadora tiene N procesadores entonces se pueden estar ejecutando estrictamente a la vez
hasta N procesos.
En los sistemas distribuidos hay muchas maquinas, cada una con uno o más procesadores centrales.
Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una
entonces hasta M procesos estar ejecutándose en paralelo.

4
En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad
de ejecución paralela ocurre por dos razones:
1. Muchos usuarios interactúan simultáneamente con programas de aplicación.
Este caso es el menos conflictivo porque normalmente las aplicaciones de interacción se
ejecutan aisladamente en la estación de trabajo del usuario y no entran en conflicto con las
aplicaciones ejecutadas en las estaciones de trabajo de otros usuarios.
2. Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a
diferentes peticiones de los procesos clientes.
Esta situación se produce por la existencia de uno o más servidores para cada tipo de
recurso. Estos procesos servidores se ejecutan en distintas maquinas, de manera que se
están ejecutando en paralelo diversos servidores, junto con diversos programas de aplicación
Las peticiones para acceder a los recursos de un servidor dado son puestas en las colas de trabajo del
servidor y son procesadas secuencialmente o procesadas concurrentemente por múltiples instancias
gestor de recursos. Cuando esto ocurre los procesos servidores deben sincronizar sus acciones para
asegurarse de que no existen conflictos.
La sincronización debe ser cuidadosamente planeada para asegurar que no se pierden los beneficios
de la concurrencia.
Escalabilidad.
Los sistemas distribuidos son escalables en tanto que la capacidad del sistema puede incrementarse
añadiendo nuevos recursos para cubrir nuevas demandas sobre el sistema.
Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La
escala más pequeña consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que un
sistema distribuido construido alrededor de una red de área local simple podría contener varios
cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresión y otros
servidores de propósito específico. A menudo se conectan varias redes de área local para formar
internetworks, y éstas podrían contener muchos miles de ordenadores que forman un único sistema
distribuido, permitiendo que los recursos sean compartidos entre todos ellos.

5
Tanto el software de sistema como el de aplicación no deberían cambiar cuando la escala del sistema
se incrementa.
La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardwares que
está íntimamente ligada con todos los aspectos del diseño de los sistemas distribuidos.
El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad o de lo contrario
aparecerán serias limitaciones.
La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofía de diseño en
que cualquier recurso simple -hardware o software- puede extenderse para proporcionar servicio a
tantos usuarios como se quiera.
Si la demanda de un recurso crece, debería ser posible extender el sistema para darla servicio.
Por ejemplo, la frecuencia con la que se accede a los ficheros crece cuando se incrementa el número
de usuarios y estaciones de trabajo en un sistema distribuido. Entonces, debe ser posible añadir
ordenadores servidores para evitar el cuello de botella que se produciría si un solo servidor de ficheros
tuviera que manejar todas las peticiones de acceso a los ficheros. En este caso el sistema deberá estar
diseñado de manera que permita trabajar con ficheros replicados en distintos servidores, con las
consideraciones de consistencias que ello conlleva.
El trabajo necesario para procesar una petición simple para acceder a un recurso compartido debería
ser prácticamente independiente del tamaño de la red. Las técnicas necesarias para conseguir estos
objetivos incluyen el uso de datos replicados, la técnica asociada de caching, y el uso de múltiples
servidores para manejar ciertas tareas, aprovechando la concurrencia para permitir una mayor
productividad.
Tolerancia a defectos.
Los sistemas distribuidos pueden ser tolerantes a algunos fallos de funcionamiento del hardware y
del software. En la mayoría de los sistemas distribuidos se puede proporcionar un servicio degradado
cuando ocurren fallos de funcionamiento.
Realmente una completa pérdida de servicio sólo ocurre cuando existe un fallo de funcionamiento en
la red.
Los sistemas informáticos a veces fallan. Cuando se producen fallos en el software o en el hardware,
los programas podrían producir resultados incorrectos o podrían pararse antes de terminar la
operación que estaban realizando. El diseño de sistemas tolerantes a fallos se basa en dos cuestiones
complementarias entre sí:
Redundancia hardware (uso de componentes redundantes).
Recuperación del software (diseño de programas que sean capaces de recuperarse de los
fallos).
En los sistemas distribuidos pueden replicarse los servidores individuales que son esenciales para la
operación continuada de aplicaciones críticas.
La recuperación del software tiene relación con el diseño de software que sea capaz de recuperar
(roll-back) el estado de los datos permanentes antes de que se produjera el fallo.
Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos
hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está a
disponible para su uso.

6
Por ejemplo, cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el
trabajo que estaba realizando el componente averiado. Un usuario podría desplazarse a otra estación
de trabajo; un proceso servidor podría ejecutarse en otra máquina.
Transparencia.
La transparencia se define como la ocultación al usuario y al programador de aplicaciones de la
separación de los componentes de un sistema distribuido, de manera que el sistema se percibe como
un todo, en vez de una colección de componentes independientes. La transparencia ejerce una gran
influencia en el diseño del software de sistema.
En los manuales de referencia se identifican ocho formas de transparencia. Estas proveen un
resumen útil de la motivación y metas de los sistemas distribuidos. Las transparencias definidas son:
1. Transparencia de Acceso.
Permite el acceso a los objetos de información remotos de la misma forma que a los objetos de
información locales.
2. Transparencia de Localización.
Permite el acceso a los objetos de información sin conocimiento de su localización
3. Transparencia de Concurrencia.
Permite que varios procesos operen concurrentemente utilizando objetos de información
compartidos y de forma que no exista interferencia entre ellos.
4. Transparencia de Replicación.
Permite utilizar múltiples instancias de los objetos de información para incrementar la fiabilidad y las
prestaciones sin que los usuarios o los programas de aplicación tengan por que conoces la existencia
de las réplicas.
5. Transparencia de Fallos.
Permite a los usuarios y programas de aplicación completar sus tareas a pesar de la ocurrencia de
fallos en el hardware o en el software.
6. Transparencia de Migración.
Permite el movimiento de objetos de información dentro de un sistema sin afectar a los usuarios o a
los programas de aplicación.
7. Transparencia de Prestaciones.
Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varia.
8. Transparencia de Escalado.
Permite la expansión del sistema y de las aplicaciones sin cambiar la estructura del sistema o los
algoritmos de la aplicación.
Las dos más importantes son las transparencias de acceso y de localización; su presencia o ausencia
afecta fuertemente a la utilización de los recursos distribuidos. A menudo se las denomina a ambas
transparencias de red.

7
La transparencia de red provee un grado similar de anonimato en los recursos al que se encuentra en
los sistemas centralizados.
Otras cuestiones vinculadas a los sistemas distribuidos son:
Seguridad.
Puede accederse al sistema desde varias computadoras diferentes, y el tráfico en la red puede estar
sujeto a escuchas indeseadas. Esto hace más difícil el asegurar que la integridad de los datos en el
sistema se mantenga y que los servicios del sistema no se degraden por ataques de denegación de
servicio.
Manejabilidad.
Los ordenadores en un sistema pueden ser de diferentes tipos y pueden ejecutar versiones
diferentes de sistemas operativos. Los defectos en una máquina pueden propagarse a otras
máquinas con consecuencias inesperadas. Esto significa que se requiere más esfuerzo para gestionar
y mantener el funcionamiento del sistema.
Impredecibilidad.
Las condiciones de cada equipo 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.
Habitualmente trabajamos con dos tipos genéricos de arquitecturas de sistemas distribuidos:
1) Arquitectura cliente-servidor.
En esta concreción, el sistema puede ser visto como un conjunto de servicio que se proporcionan a
los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma
diferente en estos sistemas.

8
2) Arquitecturas de objetos distribuidos.
En este caso, no hay distinción entre servidores y clientes, y el sistema puede ser visto como un
conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un
proveedor de servicios y el usuario de estos servicios.
Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones
generalmente tiene lugar dentro de una única organización.
La distribución soportada es, como suele decirse, intraorganizacional.
Los dos tipos de arquitecturas distribuidas que son más adecuadas para la distribución
interorganizacional son:
La arquitectura de sistemas peer-to-peer (p2p).
Las arquitecturas orientadas a servicios.
Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de
programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos
de datos, la representación de la información y los protocolos de comunicación pueden ser todos
diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes
distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos.
El término middleware se usa para hacer referencia a ese software; se sitúa en medio de los
diferentes componentes distribuidos del sistema.

9
El middleware es un software de propósito general que normalmente se compra como un
componente comercial más que escribirse especialmente por los desarrolladores de la aplicación.
Ejemplos de middleware son software para gestionar comunicaciones con bases de datos,
administradores de transacciones, convertidores de datos y controladores de comunicación.
Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a
objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una
de las cuales pueden interaccionar directamente con los usuarios o con otras partes del sistema.
Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos
software reflejan estas características; por lo tanto, son abstracciones naturales para los
componentes de sistemas distribuidos.
1.2. Modelo conceptual de las arquitecturas orientadas a servicios
Este tipo de modelo permite la creación de sistemas de información altamente escalables que
reflejan el negocio de la organización y a su vez brindan una forma bien definida de exposición e
invocación de servicios lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
SOA (arquitecturas orientadas a servicios) define las siguientes capas de software:
Aplicaciones básicas.
Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y
bajo cualquier figura de propiedad.
De exposición de funcionalidades.
De integración de servicios.
Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos
empresariales internos o en colaboración.
De composición de procesos.
Definen el proceso en términos del negocio y sus necesidades.
De entrega - donde los servicios son desplegados a los usuarios finales.
SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de
negocio y puede dar soporte a las actividades de integración y consolidación.

10
Basados en mensajes.
Otra posibilidad de implementar una aplicación distribuida es mediante una arquitectura basada en
mensajes. Este tipo de arquitecturas proporcionan a las aplicaciones un servicio de comunicación
entre procesos, utilizando la tecnología de colas de mensajes.
Estas arquitecturas suelen desarrollarse sobre productos de colas de mensajes como por ejemplo,
Microsoft Message Queuing (MSMQ) o IBM MQSeries.
Las arquitecturas basadas en mensajes consisten en el intercambio de mensajes en vez de llamadas a
métodos lo que permite que las peticiones se puedan reordenar o redirigir en función de la carga del
sistema o de la prioridad de la petición.
Por otro lado, al contrario de las basadas en RPCs, estas arquitecturas son asíncronas, lo que
ocasionará que el cliente no se bloquee al enviar un mensaje esperando respuesta del servidor. Los
clientes podrán seguir trabajando mientras esperan el resultado de la petición.
Políticas y contratos de servicios.
A la interfaz pública de un servicio se la conoce como contrato de servicio.
Es muy importante, por tanto, diseñar un contrato de servicio guardando toda la sencillez que nos
sea posible lo que implicará tener en cuenta dos factores:
No usar objetos con referencias circulares en los parámetros de entrada y en los valores de
retorno.
Usar parámetros de entrada y valores de retorno tipados.
El principio de autonomía hace referencia al concepto de servicios débilmente acoplados que puedan
diseñarse y ser desplegados independientemente del resto de servicios pero que a su vez sean
capaces de comunicarse con otros a través de contratos y políticas.
Por ejemplo, en SOA los servicios se comunican mediante el intercambio de contratos de datos.
Un contrato de datos se traduce en una clase que se compone exclusivamente de propiedades y que
viene a representar a un objeto DTO que no tiene nada que ver con los objetos del modelo de
dominio.
En resumen, un contrato de datos agrupa los parámetros de entrada de un servicio pero los
contratos de servicio y los contratos de datos no son demasiado importantes si el servicio no hace
exactamente lo que el consumidor espera de él.

11
La información relativa a la funcionalidad de un servicio es conocida como semántica de servicio que
debe ser expuesta y descubierta a través de políticas.
Para expresar políticas a nivel de servicio y poder descubrirlas es necesario usar la especificación WS-
Policy.
Construir un sistema basado en SOA, es un proceso incremental que no requiere de una revisión
completa de los procesos de negocio existentes.
SOA habla de servicios pero los servicios no son un tipo concreto de tecnología y usar servicios en
una aplicación no implica que nuestra aplicación use SOA.
SOA es un conjunto de principios que inspiran buenas prácticas en el diseño de servicios.
1.3. Aspectos de seguridad en arquitecturas orientadas a servicios
En los negocios digitales y las comunicaciones electrónicas se es fundamental crear mecanismos que
permitan garantizar la seguridad e integridad de las transacciones. Los criterios que definen una
transacción segura (o cualquier tipo de comunicación) son:
Confidencialidad. Mantener la información privada.
Integridad.
Autentificación. Garantizar la identidad de quien realiza la transacción.
No repudio. Garantizar que no se pueda rebatir la procedencia (la propiedad) de la
información.
La seguridad de la información es un elemento imprescindible ante las nuevas exigencias de la
sociedad de la información. La falta de seguridad, a menudo, se cita como una de las principales
trabas para el crecimiento del comercio electrónico, el cual, sólo puede basarse en la confianza que
procede de saber que todas las transacciones electrónicas están protegidas por mecanismos tan
seguros (al menos), como los que existen en las transacciones tradicionales.
Seguridad de datos.
El procesamiento de base de datos distribuida es difícil de controlar porque los procesos muchas
veces se llevan a cabo en las áreas de trabajo de los usuarios e incluso el acceso físico no es
controlado, lo que genera una falta de seguridad de los datos.
Por ejemplo, la pérdida de mensajes, saturación en el tráfico, etc.
Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de cómputo a
grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prácticamente
todas las aplicaciones comerciales y técnicas de los ordenadores.
Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra
interferencias externas y privacidad de la información que el sistema mantiene. Se deben garantizar
accesos concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos de
respuesta, ofrecer puntos de acceso al servicio que están distribuidos geográficamente. Todo ello
incrementará el potencial crecimiento del sistema y ayudará en la expansión del negocio.

12
Seguridad de mensajes.
Cuando un servicio recibe un mensaje este hace una serie de chequeos para detectar el contenido
mal formado. Naturalmente, se requiere tiempo de procesamiento extra, y la lógica de detección
requiere rutinas especializadas para procesar contenido de los mensajes binarios, tales como
archivos adjuntos.
Por ejemplo, un atacante puede transmitir mensajes con contenido malicioso o incorrecto a un
servicio dando lugar a un comportamiento indeseable.
Control de acceso. El modelo RBAC.
Como respuesta al nivel de complejidad que las organizaciones están adquiriendo con el paso de los
años se hace necesario mejorar el control de acceso a los distintos niveles de información.
Para ello puede implantarse un sistema de control de acceso basados en roles, también conocidos
como RBAC (Role Based Access Control).
Estos sistemas cobran su máximo sentido en aplicaciones que sustentan procesos de negocio (ERP,
ECM, etc.).
La arquitectura de los sistemas basados en roles se puede representar de la siguiente forma,
La idea consiste en la asignación de permisos (lectura, escritura, etc.), sobre objetos o procesos a los
distintos roles ya existentes en la organización (por ejemplo concretando en Revisor, Editor, Calidad,
Dirección, etc). Posteriormente se asignan estos roles a los distintos usuarios según las
responsabilidades que tienen que adoptar en cada momento (sesión).
Un ejemplo puede ser el típico flujo de trabajo (workflow) que se genera en la aprobación de una
factura de un proveedor en cualquier ERP o Sistema de Gestión Documental. En este caso, dicha
factura pasará por distintos estados intermedios en los que distintos usuarios (Jefe de compras, Jefe
de un departamento, etc.) con rol “Revisor” le darán el visto bueno hasta que finalmente sea
aprobada por Dirección. Durante ese flujo dichos usuarios jugarán el Rol “Revisor” de forma
consecutiva, pero una vez esté aprobada la factura para su pago, dichos usuarios adquieren el Rol
“Lector”, que a diferencia del Rol anterior, solo nos dejará consultar la factura.
Como hemos visto en el ejemplo anterior, un sistema basado en roles no es una ventaja destacada:
Rápida asignación de permisos ya que de forma indirecta cuando le asignas un rol a un
usuario también le estas asignando permisos. Esto facilita mucho la labor con nuevas
incorporaciones, cambios estructurales en el organigrama, etc.

13
En cuanto a la seguridad, RBAC es un arma de doble filo. Si presumimos que la implementación a
bajo nivel está bien realizada, la mayoría de los problemas de seguridad vienen dados por:
Una arquitectura mal ideada.
Normalmente esto se justifica por una mala interpretación de la organización, de sus
responsabilidades y de sus procesos de negocio.
Por ejemplo, permisos de roles mal establecidos.
Pruebas insuficientes o mal realizadas.
La principal recomendación para la implementación segura de un sistema RBAC es por un lado, el
establecimiento de un responsable (arquitecto del sistema) que tenga conocimientos muy amplios
de la organización y sus procesos de negocio y por otro, establecer una metodología que nos permita
la eficaz realización de pruebas de nuestro sistema.
Recordemos que un rol con un permiso mal asignado se propaga inmediatamente a todos los
usuarios de la organización con ese Rol.
Seguridad en comunicaciones. Protocolos seguros.
La seguridad de este tipo se basa en el hecho de poder encriptar los mensajes que se envían por la
red entre un servidor y un cliente y que solo ellos puedan descifrar los contenidos a partir de una
clave común conocida solo por los dos.
Para llevar a cabo esta seguridad se crearon diversos protocolos basados en esta idea:
SSH (Secure Shell). Usado exclusivamente en reemplazo de telnet.
Cumple la misma función que telnet o rlogin pero además usando criptografía.
A diferencia de telnet u otro servicio similar SSH utiliza el puerto 22 para la comunicación y la forma
de efectuar su trabajo es muy similar al efectuado por SSL.
Para su uso se requiere que por parte del servidor exista un demonio que mantenga continuamente
en el puerto 22 el servicio de comunicación segura, el sshd.
El cliente debe ser un software tipo TeraTerm o Putty que permita hacer pedidos a este puerto 22 de
forma cifrada.
Ejemplo de configuración de puertos,
La idea consiste en la asignación de permisos (lectura, escritura, etc.), sobre objetos o procesos a los
distintos roles ya existentes en la organización (por ejemplo concretando en Revisor, Editor, Calidad,
Dirección, etc). Posteriormente se asignan estos roles a los distintos usuarios según las
responsabilidades que tienen que adoptar en cada momento (sesión).
Un ejemplo puede ser el típico flujo de trabajo (workflow) que se genera en la aprobación de una
factura de un proveedor en cualquier ERP o Sistema de Gestión Documental. En este caso, dicha
factura pasará por distintos estados intermedios en los que distintos usuarios (Jefe de compras, Jefe
de un departamento, etc.) con rol “Revisor” le darán el visto bueno hasta que finalmente sea
aprobada por Dirección. Durante ese flujo dichos usuarios jugarán el Rol “Revisor” de forma
consecutiva, pero una vez esté aprobada la factura para su pago, dichos usuarios adquieren el Rol
“Lector”, que a diferencia del Rol anterior, solo nos dejará consultar la factura.

14
Como hemos visto en el ejemplo anterior, un sistema basado en roles nos una ventaja destacada:
Rápida asignación de permisos ya que de forma indirecta cuando le asignas un rol a un usuario
también le estas asignando permisos. Esto facilita mucho la labor con nuevas incorporaciones,
cambios estructurales en el organigrama, etc.
En cuanto a la seguridad, RBAC es un arma de doble filo. Si presumimos que la implementación a
bajo nivel está bien realizada, la mayoría de los problemas de seguridad vienen dados por:
Una arquitectura mal ideada.
Normalmente esto se justifica por una mala interpretación de la organización, de sus
responsabilidades y de sus procesos de negocio. Por ejemplo, permisos de roles mal
establecidos.
Pruebas insuficientes o mal realizadas.
La principal recomendación para la implementación segura de un sistema RBAC es por un lado, el
establecimiento de un responsable (arquitecto del sistema) que tenga conocimientos muy
amplios de la organización y sus procesos de negocio y por otro, establecer una metodología que
nos permita la eficaz realización de pruebas de nuestro sistema.
Recordemos que un rol con un permiso mal asignado se propaga inmediatamente a todos los
usuarios de la organización con ese Rol.
Seguridad en comunicaciones. Protocolos seguros.
La seguridad de este tipo se basa en el hecho de poder encriptar los mensajes que se envían por la
red entre un servidor y un cliente y que solo ellos puedan descifrar los contenidos a partir de una
clave común conocida solo por los dos.
Para llevar a cabo esta seguridad se crearon diversos protocolos basados en esta idea:
SSH (Secure Shell). Usado exclusivamente en reemplazo de telnet.
Cumple la misma función que telnet o rlogin pero además usando criptografía.
A diferencia de telnet u otro servicio similar SSH utiliza el puerto 22 para la comunicación y la forma
de efectuar su trabajo es muy similar al efectuado por SSL.
Para su uso se requiere que por parte del servidor exista un demonio que mantenga continuamente
en el puerto 22 el servicio de comunicación segura, el sshd.
El cliente debe ser un software tipo TeraTerm o Putty que permita hacer pedidos a este puerto 22 de
forma cifrada.
Ejemplo de configuración de puertos,

15
La forma en que se entabla una comunicación es en base la misma para todos los protocolos seguros:
El cliente envía una señal al servidor pidiéndole comunicación por el puerto 22.
El servidor acepta la comunicación en el caso de poder mantenerla bajo encriptación mediante
un algoritmo definido y le envía la llave pública al cliente para que pueda descifrar los mensajes.
El cliente recibe la llave teniendo la posibilidad de guardar la llave para futuras comunicaciones o
destruirla después de la sesión actual.
SSL (Secure Socket Layer). Usado principalmente en comunicaciones de hipertexto pero con
posibilidad de uso en otros protocolos.
El protocolo SSL fue desarrollado por Netscape para permitir confidencialidad y autenticación en
Internet. SSL es una capa por debajo de HTTP y tal como lo indica su nombre está a nivel de socket
por lo que permite ser usado no tan solo para proteger documentos de hipertexto sino también
servicios como FTP, SMTP, TELNET entre otros.
La idea que persigue SSL es encriptar la comunicación entre servidor y cliente mediante el uso de
llaves y algoritmos de encriptación.
TSL (Transport Layer Secure). Es del mismo estilo del anterior.
El protocolo TLS está basado en SSL y son similares en el modo de operar.
Es importante señalar que ambos protocolos se ejecutan sobre una capa de transporte definida, pero
no determinada. Esto indica que pueden ser utilizados para cualquier tipo de comunicaciones. La
capa de transporte más usada es TCP cobre la cual pueden implementar seguridad en HTTP.
Como punto de diferencia se puede mencionar que existen protocolos implementados sobre la capa
de red, por ejemplo sobre IP. Tal es el caso de IPSec.
HTTPS (Hypertext Transfer Protocol Secure). Usado exclusivamente para comunicaciones de
hipertexto.
Este protocolo lo utilizan entidades bancarias, tiendas en línea y cualquier servicio que solicite el
envío de datos personales o contraseñas a través de la web. Entre sus características está la
utilización de un cifrado establecido en SSL/TLS para crear un canal cifrado más adecuado para la
transferencia de información sensible como son usuario y claves de paso, que el HTTP.

16
El nivel de cifrado de este canal va a depender del servidor remoto y del navegador que utilice el
cliente. A su vez, de esta manera, se consigue que esa información privada o sensible no pueda ser
usada por un atacante que haya podido interceptar la transferencia de datos, porque lo que consigue
son datos cifrados que no puede descifrar.
Este protocolo fue creado en 1992 por Netscape Communications para su navegador Netscape
Navigator. Solamente era usado originalmente, para SSL, pero esto se volvió obsoleto ante la
aparición de TLS. En el año 2000 HTTPS fue adoptado como un estándar web.
1.4. Implementación de arquitecturas orientadas a servicios mediante tecnologías web
Una vez que la iniciativa SOA ha sido analizada como un enfoque viable y se ha puesto en marcha el
proyecto piloto, la organización empezará la implementación iterativa de proyectos SOA. Los
proyectos son incluidos en la iniciativa basándose en la prioridad e impacto que poseen en la
organización. El registro de servicios disponibles crecerá con cada iteración.
Las siguientes actividades deberán realizarse de forma iterativa:
Análisis detallado de todos los procesos de negocio y servicios a ser utilizados en el proyecto,
diseño e implementación. Reutilización de servicios cuando sea posible.
Definición del modelo de arquitectura evolutivo (modelo de datos, dominios funcionales, etc.).
Definición y aplicación de metodologías, procedimientos y buenas prácticas.
Transferencia de conocimiento.
Análisis de riesgos.
Especificaciones de servicios web de uso común: SOAP, REST, etc.
SOAP.
Este protocolo deriva de un protocolo creado por David Winer en 1998 llamado XML-RPC.
SOAP fue creado por Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno de
los protocolos utilizados en los servicios Web.
SOAP puede formar la capa base de una pila de protocolos de web service, ofreciendo un framework
de mensajería básica en la cual los web services se puedan construir. Este protocolo basado en XML
consiste de tres partes:
1. Un sobre (envelope), el cual define qué hay en el mensaje y cómo procesarlo.
2. Un conjunto de reglas de codificación para expresar instancias de tipos de datos.
3. Una convención para representar llamadas a procedimientos y respuestas.
El protocolo SOAP tiene tres características principales:
Extensibilidad. Seguridad y WS-routing son extensiones aplicadas en el desarrollo.
Neutralidad. SOAP puede ser utilizado sobre cualquier protocolo de transporte como HTTP,
SMTP, TCP o JMS.
Independencia. SOAP permite cualquier modelo de programación.
Por ejemplo, un mensaje SOAP podría ser enviado a un sitio Web que tiene habilitado Web service
para realizar la búsqueda de algún precio en una base de datos, indicando los parámetros
necesitados en la consulta.

17
El sitio podría retornar un documento formateado en XML con el resultado, por ejemplo, precios,
localización, características. Teniendo los datos de respuesta en un formato estandarizado parseable,
este puede ser integrado directamente en un sitio Web o aplicación externa.
La arquitectura SOAP consiste de muchas capas de especificación: para el formato del mensaje, MEP
(Message Exchange Patterns), subyacentes enlaces de protocolo de transporte, modelo de
procesamiento de mensajes, y extensibilidad del protocolo.
SOAP es el sucesor de XML-RPC, a pesar de que toma el transporte y la neutralidad de la interacción
y el envelope / header / body de otra parte (probablemente de WDDX).
REST.
El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding uno
de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente
utilizado por la comunidad de desarrollo.
El término REST se refería originalmente a un conjunto de principios de arquitectura que se usan
para describir cualquier interfaz web simple con XML y HTTP.
Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y
también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento
remoto pero sin usar SOAP.
Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas,
aunque RPC no es un ejemplo de REST.
REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños
fundamentales clave:
Un protocolo cliente/servidor sin estado.
En la práctica muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos
para mantener el estado de la sesión (algunas de estas prácticas, como la reescritura de
URLs, no son permitidas por REST).
Un conjunto de operaciones bien definidas que se aplican a todos los recursos de
información.
HTTP en sí define un conjunto pequeño de operaciones, las más importantes son POST, GET, PUT y
DELETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD que se requieren
para la persistencia de datos, aunque POST no encaja exactamente en este esquema.
Una sintaxis universal para identificar los recursos.
En un sistema REST, cada recurso es direccionable únicamente a través de su URI.
El uso de hipermedios tanto para la información de la aplicación como para las
transiciones de estado de la aplicación.
La representación de este estado en un sistema REST son típicamente HTML o XML.
Es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el
uso de registros u otra infraestructura adicional.

18
Un concepto importante en REST es la existencia de recursos (elementos de información) que
pueden ser accedidos utilizando un identificador global (un Identificador Uniforme de Recurso).
La petición puede ser transmitida por cualquier número de conectores (por ejemplo clientes,
servidores, cachés, túneles, etc.) pero cada uno lo hace sin ver más allá de su propia petición (lo que
se conoce stateless, otra restricción de REST, que es un principio común con muchas otras partes de
la arquitectura de redes y de la información).
Una aplicación puede interactuar con un recurso conociendo el identificador del recurso y la acción
requerida, no necesitando conocer si existen cachés, proxys, cortafuegos, túneles o cualquier otra
cosa entre ella y el servidor que guarda la información.
La aplicación, sin embargo, debe comprender el formato de la información devuelta (la
representación), que es por lo general un documento HTML o XML, aunque también puede ser una
imagen o cualquier otro contenido.
Lenguajes de definición de servicios: el estándar WSDL.
WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de
comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para
interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se
describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje.
WSDL se usa a menudo en combinación con SOAP y XML Schema.
Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar qué
funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen en el archivo
WSDL en forma de XML Schema. El cliente puede usar SOAP para hacer la llamada a una de las
funciones listadas en el WSDL.
La estructura del WSDL tiene los siguientes elementos:
Tipos de Datos.
<types>. Esta sección define los tipos de datos usados en los mensajes. Se utilizan los tipos definidos
en la especificación de esquemas XML.
Mensajes.
<message>. Aquí definimos los elementos de mensaje. Las partes pueden ser de cualquiera de los
tipos definidos en la sección anterior.
Tipos de Puerto.
<portType>. Con este apartado definimos las operaciones permitidas y los mensajes intercambiados
en el servicio.
Bindings.
<binding>. Especificamos los protocolos de comunicación usados.
Servicios.
<service>. Conjunto de puertos y dirección de los mismos. Esta parte final hace referencia a lo
aportado por las secciones anteriores.

19
Con estos elementos no sabemos qué hace un servicio pero sí disponemos de la información
necesaria para interactuar con él (funciones, mensajes de entrada/salida, protocolos...).
Por ejemplo, un documento WSDL y sus diferentes secciones.
En este ejemplo concreto se implementa un servicio que muestra a partir del nombre de un valor
bursátil su valor actual en el mercado.

20
Estándares de seguridad en servicios web: WS-Security, SAML, XACML, etc.
WS-Security.
Originalmente desarrollado por IBM, Microsoft, y VeriSign, el protocolo es ahora llamado
oficialmente WSS y está desarrollado por un comité en Oasis-Open.
El protocolo contiene especificaciones sobre cómo debe garantizarse la integridad y seguridad en
mensajería de Servicios Web.
El protocolo WSS incluye detalles en el uso de SAML y Kerberos, y formatos de certificado tales como
X.509.
La Integridad de datos y confidencialidad podrían también garantizarse sobre Servicios Web a través
del uso de la Transport Layer Security (TLS).
Por ejemplo el envío de mensajes sobre HTTPS. Esto puede reducir significativamente la sobrecarga,
por ejemplo eliminando la necesidad de codificar claves y firmas de mensaje en ASCII antes de enviar.
La parte negativa de usar TLS sería en el caso de que los mensajes necesitaran pasar a través de un
servidor proxy. En tal caso, el servidor vería la petición que llega del proxy, no del cliente lo que
podría ser solventado si el proxy tiene una copia de la clave y certificado del cliente, o teniendo un
certificado de firmado de confianza para el servidor, con el cual podría generar un par
clave/certificado que coincida con aquellos del cliente. Sin embargo, el hecho de que el proxy está
operando el mensaje significa que no asegura la seguridad extremo a extremo, sino que solo asegura
la seguridad punto a punto.
WS-Security incorpora características de seguridad en el encabezado de un mensaje SOAP,
trabajando en la capa aplicación. Así asegura seguridad extremo a extremo.

21
SAML. (Security Assertion Markup Language).
SAML es un estándar XML para el intercambio de datos de autentificación y autorización entre
dominios de seguridad, esto es, entre un proveedor de identidad (un productor de afirmaciones) y un
proveedor de servicio (un consumidor de afirmaciones).
Se espera que sea la base para los controles de seguridad de acceso en internet y la seguridad de los
nuevos servicios web.
El comité OASIS Security Services Technical Committee (SSTC) se reunió por primera vez en enero de
2001 con la idea de definir un framework XML para el intercambio de información de autentificación
y autorización.
En cuanto a la seguridad de SAML las especificaciones SAML recomiendan, y en algunos casos
obligan, una variedad de mecanismos de seguridad:
SSL 3.0 o TLS 1.0 para la seguridad a nivel transporte.
Firma XML y encriptación XML para seguridad a nivel mensaje.
XACML.
Es un lenguaje que pueda realizar especificaciones y definiciones sobre políticas de acceso
XACML, es el encargado de crear un modelo para el intercambio de información de autorización, así
como de almacenar y estructurar el citado almacenamiento de dicha información. A partir del citado
modelo se estandariza una base de comportamiento, pero se le dota de la flexibilidad necesaria para
permitir a los diferentes sistemas que manifiesten sus políticas de autorización.
Por ejemplo, algunos sistemas basaran sus políticas en usuarios, perfiles y páginas permitidas,
mientras que otros los basaran en terminales, transacciones y tipos de producto XACML.
XACML presenta dos esquemas:
1. Un esquema para los mensajes de autorización: Este esquema define la estructura del mensaje
XML para un pedido de autorización (request), así como la estructura del mensaje de respuesta
(response), el cual indica si la autorización se concede o no.
2. Un esquema para expresar las políticas de acceso: definiendo la estructura XML de las políticas
de acceso. Las políticas son la unidad básica que expresa quién puede hacer qué y bajo qué
circunstancias o contexto.
1.5. Implementación de la seguridad en arquitecturas orientadas a servicios
Conceptos básicos de criptografía.
El único objetivo de la criptografía es conseguir la confidencialidad de los mensajes por lo que se
diseñaban sistemas de cifrado y códigos. Al principio la única criptografía que había era la llamada
criptografía clásica.
Este desafío ha generalizado los objetivos de la criptografía para ser la parte de la criptología que se
encarga del estudio de los algoritmos, protocolos (se les llama protocolos criptográficos) y sistemas
que se utilizan para proteger la información y dotar de seguridad a las comunicaciones y a las
entidades que se comunican.
Para ello los criptógrafos investigan, desarrollan y aprovechan técnicas matemáticas que les sirven
como herramientas para conseguir sus objetivos.

22
Los grandes avances que se han producido en el mundo de la criptografía han sido posibles gracias a
los grandes avances que se han producido en el campo de las matemáticas y la informática.
La criptografía actualmente se encarga del estudio de los algoritmos, protocolos y sistemas que se
utilizan para dotar de seguridad a las comunicaciones, a la información y a las entidades que se
comunican.
El objetivo de la criptografía es diseñar, implementar, implantar, y hacer uso de sistemas
criptográficos para dotar de alguna forma de seguridad.
El tipo de propiedades de las que se ocupa la criptografía son:
Confidencialidad.
Es fundamental garantizar que la información esté accesible únicamente al personal autorizado. Para
conseguirlo se deben usar códigos y técnicas de cifrado.
Integridad.
Hay que garantizar la corrección y completitud de la información y para lograrlo se pueden usar
técnicas como funciones hash criptográficas MDC, protocolos de compromiso de bit o protocolos de
notarización electrónica.
Se llaman funciones hash criptográficas a aquellas funciones hash que se utilizan en el área de la
criptografía. Este tipo de funciones se caracterizan por cumplir propiedades que las hacen idóneas
para su uso en sistemas que confían en la criptografía para dotarse de seguridad. Estas propiedades
las hacen resistentes frente ataques maliciosos que intentan romper esa seguridad.
Vinculación.
Tradicionalmente se ha estado empleando el término No repudio que implicaba conceptos jurídicos
que la tecnología por sí sola no puede resolver proporcionando protección.
Por ejemplo, la firma digital.
En algunos contextos lo que se intenta es justo lo contrario, es decir, poder negar que se ha
intervenido en la comunicación.
Por ejemplo cuando se usa un servicio de mensajería instantánea y no queremos que se pueda
demostrar esa comunicación. Para ello se usan técnicas como el cifrado negable.
Autenticación.
Para conseguirlo puede usar por ejemplo función hash criptográfica MAC o protocolo de
conocimiento cero.
Soluciones a problemas de la falta de simultaneidad en la telefirma digital de contratos.
Para conseguirlo puede usar por ejemplo protocolos de transferencia inconsciente.
Un sistema criptográfico es seguro respecto a una tarea si un adversario con capacidades especiales
no puede romper esa seguridad, es decir, el atacante no puede realizar esa tarea específica.

23
Tipos de criptografía.
Cifrado simétrico.
La criptografía simétrica sólo utiliza una clave para cifrar y descifrar el mensaje. Obviamente debe ser
conocida por el emisor y el receptor previamente y aquí es donde aparece el punto débil del
sistema, la comunicación de las claves entre ambos sujetos.
Siempre resulta más fácil interceptar una clave que se ha transmitido sin seguridad (por ejemplo,
diciéndola en alto, mandándola por correo electrónico u ordinario o haciendo una llamada
telefónica).
Teóricamente debería de ser más fácil conocer la clave interceptándola que probándola una por una
por fuerza bruta, teniendo en cuenta que la seguridad de un mensaje cifrado debe recaer sobre la
clave y nunca sobre el algoritmo (por lo que sería una tarea eterna reventar la clave, como comenté
en un ejemplo de ataque por fuerza bruta).
Un ejemplo sería la máquina Enigma (que era una máquina de cifrado electromecánica que generaba
abecedarios según la posición de unos rodillos que podrían tener distintas órdenes y posiciones) que
empleaba un método simétrico con un algoritmo que dependía de una clave generada por los rotores
o rodillos del engranaje, dependiendo de su orden y la posición de cada anillo.
Y otro inconveniente que tiene este sistema es que si quieres tener un contenido totalmente
confidencial con 10 personas tienes que aprenderte o apuntarte (siendo esta forma menos segura)
las 10 claves para cada persona.
De forma esquemática podría definirse como que si E y R conocen la clave K. El Emisor E, desea
transmitir el mensaje Mensaje a R. Para ello usa un algoritmo de cifrado simétrico y la clave K, genera
entonces el mensaje Mensaje(K), que es transmitido a R, este aplicando la clave y el algoritmo
inverso, obtiene nuevamente el mensaje original.
Por ejemplo,
Cifrado asimétrico.
Este método usa un par de claves para el envío de mensajes.
Estas claves pertenecen a la misma persona a la que se ha enviado el mensaje. Una clave es pública
que se le entrega a cualquier persona y otra clave privada que el propietario debe guardarla de
modo que nadie tenga acceso a ella.

24
El funcionamiento esquemático sería: el emisor conoce la clave pública; cifra y envía el mensaje
mediante esta clave al receptor este descifra el mensaje con la clave privada.
Por ejemplo, si queremos que tres trabajadores nos envíen un fichero cifrado debemos de mandarle
nuestra clave pública (que está vinculada a la privada) y nos podrán mandar de forma confidencial
ese archivo que solo nosotros podremos descifrar con la clave privada.
Puede pensarse que sabiendo la clave pública se llega a deducir la privada pero este tipo de sistemas
criptográficos usan algoritmos bastante complejos que generan a partir de la frase de paso (la
contraseña) la clave privada y pública que pueden tener perfectamente un tamaño de 2048bits
(probablemente imposible de reventar).
Otro propósito de este sistema es también el de poder firmar documentos, certificando que el
emisor es quien dice ser, firmando con la clave privada y verificando la identidad con la pública.
La diferencia fundamental entre criptografía simétrica y asimétrica es que la primera es más insegura
simplemente porque el hecho de pasar la clave genera una gran vulnerabilidad pero presenta la
ventaja de que se puede cifrar y descifrar en menor tiempo del que tarda la criptografía asimétrica
que es su principal inconveniente y es la razón por la que existe la criptografía híbrida.
Criptografía hibrida.
Es una combinación de cifrado simétrico y asimétrico. Utiliza una clave pública para cifrar el mensaje
en el que envía una clave para el cifrado simétrico. Para darle mayor seguridad la clave simétrica, es
diferente para cada sesión.
Este sistema es la unión de las ventajas de los dos anteriores donde debemos de partir que el
problema de ambos sistemas criptográficos es que el simétrico es inseguro y el asimétrico es lento.
El proceso para usar un sistema criptográfico híbrido es el siguiente (para enviar un archivo):
Generar una clave pública y otra privada (en el receptor).
Cifrar un archivo de forma síncrona.
El receptor nos envía su clave pública.
Ciframos la clave que hemos usado para encriptar el archivo con la clave pública del receptor.
Enviamos el archivo cifrado (síncronamente) y la clave del archivo cifrada (asíncronamente y solo
puede ver el receptor)

25
Entidades certificadoras.
En criptografía una autoridad de certificación, certificadora o certificante (AC o CA por sus siglas en
inglés Certification Authority) es una entidad de confianza, responsable de emitir y revocar los
certificados digitales o certificados, utilizados en la firma electrónica para lo cual se emplea la
criptografía de clave pública.
Jurídicamente es un caso particular de Prestador de Servicios de Certificación.
Ejemplos de entidades certificadoras,
La Autoridad de Certificación, por sí misma o mediante la intervención de una Autoridad de Registro,
verifica la identidad del solicitante de un certificado antes de su expedición o, en caso de certificados
expedidos con la condición de revocados, elimina la revocación de los certificados al comprobar
dicha identidad.
Los certificados son documentos que recogen ciertos datos de su titular y su clave pública y están
firmados electrónicamente por la Autoridad de Certificación utilizando su clave privada.
La Autoridad de Certificación es un tipo particular de Prestador de Servicios de Certificación que
legitima ante los terceros que confían en sus certificados la relación entre la identidad de un usuario
y su clave pública. La confianza de los usuarios en la CA es importante para el funcionamiento del
servicio y justifica la filosofía de su empleo, pero no existe un procedimiento normalizado para
demostrar que una CA merece dicha confianza.
Un certificado revocado es un certificado que no es válido aunque se emplee dentro de su período
de vigencia. Un certificado revocado tiene la condición de suspendido si su vigencia puede
restablecerse en determinadas condiciones.

26
Certificados digitales. Características.
Un certificado digital es un documento que permite al firmante identificarse en Internet. Su
obligatoriedad se está extendiendo y es necesario en muchas administraciones para realizar trámites,
tanto a nivel de organismos públicos como en numerosas entidades privadas.
Según la Sede Electrónica del Instituto Nacional de Estadística un certificado electrónico sirve para:
Autentificar la identidad del usuario, de forma electrónica, ante terceros.
Firmar electrónicamente de forma que se garantice la integridad de los datos trasmitidos y su
procedencia. Un documento firmado no puede ser manipulado, ya que la firma está asociada
matemáticamente tanto al documento como al firmante
Cifrar datos para que sólo el destinatario del documento pueda acceder a su contenido.
Identificación y firma digital mediante certificados digitales.
En España, actualmente los certificados electrónicos emitidos por entidades públicas son el DNIe o
DNI electrónico y el de la Fábrica Nacional de Moneda y Timbre (FNMT).
Para el certificado digital de la FNMT es necesario contar con DNI o NIE.
El certificado se descarga en el navegador del equipo donde lo han solicitado. No es necesario que se
guarde en el disco duro, pudiendo exportarse directamente a un dispositivo extraíble (como una
memoria USB o memoria flash).
Una firma digital es un mecanismo criptográfico que permite al receptor de un mensaje firmado
digitalmente determinar la entidad originadora de dicho mensaje (autenticación de origen y no
repudio), y confirmar que el mensaje no ha sido alterado desde que fue firmado por el originador
(integridad).
La firma digital se aplica en aquellas áreas donde es importante poder verificar la autenticidad y la
integridad de ciertos datos.
Por ejemplo documentos electrónicos o software, ya que proporciona una herramienta para detectar
la falsificación y la manipulación del contenido.

27
Se han establecido una serie de propiedades necesarias que tiene que cumplir un esquema de firma
para que pueda ser utilizado.
La validez de una firma se ampara en la imposibilidad de falsificar cualquier tipo de firma radica en el
secreto del firmante.
En el caso de las firmas escritas el secreto está constituido características de tipo grafológico innatas
al signatario y por tanto difíciles de falsificar.
En el caso de las firmas digitales, el secreto del firmante es el conocimiento exclusivo de una clave
(secreta) utilizada para generar la firma. Para garantizar la seguridad de las firmas digitales es
necesario a su vez que estas sean:
Únicas.
Las firmas deben poder ser generadas solamente por el firmante y por lo tanto infalsificable. Por
tanto la firma debe depender del firmante.
Infalsificables.
Para falsificar una firma digital el atacante tiene que resolver problemas matemáticos de una
complejidad muy elevada, es decir, las firmas han de ser computacionalmente seguras. Por tanto la
firma debe depender del mensaje en sí.
Verificables.
Innegables.
Viables.
Las firmas han de ser fáciles de generar por parte del firmante.
Cifrado de datos.
El cifrado de datos es el proceso por el que una información legible se transforma mediante un
algoritmo (llamado cifra) en información ilegible, llamada criptograma o secreto.
Esta información ilegible se puede enviar a un destinatario con muchos menos riesgos de ser leída
por terceras partes.
El destinatario puede volver a hacer legible la información introduciendo la clave del cifrado. A
menudo se denomina encriptación a este proceso, pero es incorrecto, ya que esta palabra no existe
en castellano. Es una importación del inglés encrypt que se debe traducir como cifrar y todo el
conjunto del proceso reconocerlo como cifrado.
La seguridad de un buen sistema de cifrado depende enteramente de la clave, y no debe depender
del algoritmo de cifrado usado. Es decir, el algoritmo de cifrado a menudo es público, y es conocido
por los posibles atacantes, pero si el algoritmo es bueno, esto no debe bastarles para descifrar el
mensaje.
Los algoritmos usados en las comunicaciones seguras de Internet son públicos prácticamente
siempre, por lo que es necesario centrarse en crear claves suficientemente seguras.

28
El cifrado de datos se usa en numerosas aplicaciones cotidianas. Algunas de las más habituales son:
SSL.
Esta seguridad es en forma de privacidad y autenticación. No sólo autentica el servidor de la
comunicación (mediante certificados) sino que además selecciona un algoritmo de cifrado
permitiendo el intercambio de claves de forma segura entre cliente y servidor. Cifra la información
con cifrado simétrica.
Esta capa de seguridad se puede aplicar en diversos ámbitos:
HTTPS. Protocolo HTTP seguro.
FTP. Protocolo de intercambio de ficheros. Puede utilizar SSL para ser seguro.
SMTP. Protocolo de correo. Puede utilizar SSL para ser seguro.

29
Un certificado SSL sirve para brindar seguridad al visitante de su página web lo que aportará a los
clientes la confianza de que el sitio es auténtico, real y confiable para ingresar datos personales.
Las siglas SSL responden a los términos en inglés (Secure Socket Layer) que recoge un protocolo de
seguridad que hace que sus datos viajen de manera íntegra y segura por la red.
La transmisión de los datos entre un servidor y usuario web va totalmente cifrada o encriptada.
Cuando hablamos de cifrar datos estamos hablando de utilizar algoritmos matemáticos y un sistema
de claves que sólo son identificados entre la persona que navega y el servidor. Al tener un certificado
SSL confiable nuestros datos están encriptados y en ese momento podemos asegurar que nadie
puede leer su contenido.
Para poder utilizar un certificado SSL es fundamental que el servidor de Internet soporte SSL.
Un certificado SSL es una tecnología que le brinda una gran solución de seguridad en línea ayudando
a garantizar a los clientes que el sitio que están visitando es seguro: desde una simple visita, realizar
compras o iniciar sesión.
Un certificado SSL implementa el modelo preferido de seguridad en web ya que contiene claves
digitales que protegen la integridad de sus datos al momento de enviar y recibir. Los servidores que
corren SSL crean una vía con un cifrado único para las sesiones privadas a través que Internet, la
clave pública del servidor está al alcance de cualquier persona. Es por eso que utilizan una clave
pública y una clave privada.
La clave pública es para cifrar la información, la clave privada para descifrarla.
En la actualidad la mayoría de las aplicaciones web y servidores soportan un certificado SSL es por
eso que le recomendamos analizar a profundidad la finalidad de su sitio web y haga una excelente
decisión en cuanto a certificado SSL se refiere.
Firma digital.
La firma digital es el método criptográfico que permite asociar la identidad de una persona o
máquina a un documento como autor del mismo. Para incorporar las firmas digitales, primero se
calculan los datos de la firma, que se obtienen de aplicar cierto algoritmo matemático. Esos datos se
cifran con algoritmos concretos y posteriormente la firma cifrada es incorporada al documento.
El receptor del documento deberá tener medios tecnológicos tanto para extraer la firma cifrada
como para descifrarla, por lo que también deberá tener la clave.
Este sistema cifra los mensajes gracias a dos claves, una pública y otra privada, vinculadas entre sí (lo
que cifra una, sólo puede ser descifrado por la otra).

30
La clave privada debe permanecer bajo el exclusivo control de su propietario.
La clave pública, es enviada junto al mensaje y posibilita al destinatario verificar quién es
el autor del mensaje.
1. Escribimos el mensaje o creamos el documento.
2. Al aplicar la firma al documento realmente se está aplicando mensaje una función matemática
(función HASH) que generará un resumen de dicho documento que se denomina huella digital.
Dos documentos distintos generarán huellas digitales distintas.
3. Se descifra la firma digital. Es necesario que el destinatario realice varias acciones:
Aplicar la función hash al documento original y de esa forma vuelve a obtener su huella
digital.
Descifrar gracias a la clave pública la firma digital y el resultado es también la huella digital.
Comparar las dos huellas, y si las dos huellas digitales coinciden se tiene asegurado que el
documento no ha sido alterado, y además que el emisor es quien dice ser.
VPN.
Para que estas redes sean seguras se usan técnicas de tunneling que consisten en crear un túnel
seguro dentro de la red insegura por el que circulan los datos de la VPN cifrados.
Las redes privadas virtuales utilizan este método de cifrado de forma muy habitual.
Para garantizar la seguridad de la red VPN se usan protocolos de comunicación segura como IPSec
que es el estándar de facto aunque también se usan otros como SSL o PPTP.

31
El llamado tunneling es el proceso de colocación de la información que se envía dentro de un
paquete. El protocolo del paquete que hace de envoltorio solo es entendido por el emisor y por el
receptor, en concreto, por el gateway que lo envía y por el gateway que lo recibe.
Una pasarela (en inglés gateway) o puerta de enlace es el dispositivo que actúa de interfaz de
conexión entre aparatos o dispositivos, y también posibilita compartir recursos entre dos o más
computadoras. Su propósito es traducir la información del protocolo utilizado en una red inicial, al
protocolo usado en la red de destino
Para los usuarios que utilizan estos dispositivos el proceso es transparente porque todo se realiza en
el gateway.
El protocolo del paquete que hace de envoltorio solo es entendido por el emisor y por el receptor, en
concreto, por el gateway que lo envía y por el gateway que lo recibe.
Cifrado de archivos.
También existen aplicaciones que permiten el cifrado, no ya de una información que se va a enviar,
sino de un archivo.
Por ejemplo, puede interesar enviarse cifrado para que sólo puedan leerlo quienes tengan una clave.
Esto también es útil para almacenar información confidencial de una organización. En caso de
sustracción de la información no servirá de nada si no se tiene una clave para descifrarla.
Cifrado de disco duro.
Tener todo el sistema de archivos cifrado permite que cada vez que se guarde un archivo ya lo haga
cifrado por defecto y que todo lo contenido en el disco duro esté cifrado. Esto provocará que haya
procesos que se gestionen más lentamente ya que cada vez que se guarda se ha de cifrar.
1.6. Directorios de servicios
Concepto de directorio.
En informática, un directorio es una agrupación de archivos de datos, atendiendo a su contenido, a
su propósito o a cualquier criterio que decida el usuario. Técnicamente el directorio almacena
información acerca de los archivos que contiene como los atributos de los archivos o dónde se
encuentran físicamente en el dispositivo de almacenamiento.
El directorio de servicio se utiliza para hacer referencia a:
La información contenida.
El conjunto formado por el hardware y el software que gestiona dicha información.
Las aplicaciones Cliente/Servidor que usan dicha información.
Un servicio de directorio (SD) es una aplicación o un conjunto de aplicaciones que almacena y
organiza la información sobre los usuarios de una red de ordenadores y sobre los recursos de red que
permite a los administradores gestionar el acceso de usuarios a los recursos sobre dicha red.
Además, los servicios de directorio actúan como una capa de abstracción entre los usuarios y los
recursos compartidos.

32
Un servicio de directorio no debería confundirse con el repositorio de directorio, que es la base de
datos la que contiene la información sobre los objetos de nombrado gestionada por el servicio de
directorio
Una de las principales desventajas es la no actualización de la información.
Por ejemplo, una tradicional guía telefónica.
Sin embargo si se piensa en la programación de un medio como la radio o la televisión, seguramente
esta podrá ser la actualizada semanalmente con sus contenidos y programas para el caso de la radio
y diariamente para el caso de la televisión.
Directorios distribuidos.
El servicio de directorio puede estar centralizado o distribuido. En el caso de ser centralizado, un
único servidor da todo el servicio de directorio, respondiendo a todas las consultas de los clientes. Si
el directorio está distribuido, varios servidores proporcionan el servicio de directorio.
Cuando el servicio de directorio está distribuido, los datos pueden estar fraccionados y/o replicados.
Cuando la información esta fraccionada, cada servidor de directorio almacena un subconjunto único
y no solapado de la información, es decir, una entrada es almacenada en un solo servidor.
Cuando la información esta replicada, una entrada puede estar almacenada en varios servidores.
Generalmente cuando el servicio de directorio es distribuido, parte de la información está
fraccionada y parte está replicada.
En el caso del modelo de servicio de directorio distribuido en X.500 se usa uno o más espacios de
nombre (árbol de objetos) para formar el servicio de directorio. El servicio de directorio aporta la
interfaz de acceso a los datos que se contienen en unos o más espacios de nombre de directorio.
La interfaz del servicio de directorio es la que gestiona la autenticación de los accesos al servicio de
forma segura.
Como base de datos, un servicio del directorio está altamente optimizado para lecturas y
proporciona alternativas avanzadas de búsqueda en los diferentes atributos que se puedan asociar a
los objetos de un directorio.
Los servicios de directorio utilizan un modelo distribuido para almacenar su información y esa
información generalmente está replicada entre los servidores que forman el directorio.
Estándares sobre directorios de servicios: UDDI.
El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la
OASIS) entroncada en el contexto de los servicios Web.
El registro de un negocio en UDDI tiene tres partes:
1. Páginas blancas: dirección, contacto y otros identificadores conocidos.
2. Páginas amarillas: categorización industrial basada en taxonomías.
3. Páginas verdes: información técnica sobre los servicios que aportan las propias empresas.
UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por los
mensajes SOAP y dar paso a documentos WSDL en los que se describen los requisitos del protocolo y
los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros.

33
UDDI surgió con la intención de centralizar web services comunes, así como ofrecer un depósito
central donde se puede acudir a realizar búsquedas de web services específicos.
UDDI ha sido desarrollado por un grupo de empresas entre las que figuran principalmente Microsoft,
IBM y SAP. Es interesante destacar que estas empresas se encargan de mantener y ofrecer este tipo
de servicios en Internet.
Algunos directorios de prueba que se puede usar son:
UDDI IBM (http://uddi.ibm.com/testregistry/registry.html).
UDDI Microsoft (http://uddi.microsoft.com/).
UDDI SAP (http://udditest.sap.com/).
UDDI puede ayudarnos a resolver los siguientes problemas:
Descubrir la empresa más adecuada de entre las muchas presentes en Internet.
Obtener información sobre cómo contactar con esa empresa.
Conseguir nuevos clientes y facilitar el acceso a los actuales.
Incrementando los servicios ofertados y extendiendo el mercado al que se puede acceder.
Describir servicios y procesos empresariales en un entorno seguro y fácil de usar.

34
Por ejemplo, supongamos que se crea un estándar UDDI para reserva y venta de billetes de avión.
Las aerolíneas podrían registrar sus servicios en un directorio UDDI siguiendo ese estándar (e
interface UDDI). Así, las agencias de viaje, accediendo al repositorio UDDI a través de la interfaz,
podrían comunicarse
Recuerda…
Las técnicas Tunneling se usan para que las redes sean seguras.
El único objetivo de la criptografía era conseguir la confidencialidad de los mensajes.
El registro de un negocio en UDDI tiene varias partes.
Los algoritmos usados en las comunicaciones seguras de Internet son públicos en la mayoría de los
casos.
El modelo conceptual SOA proporciona una metodología y un marco de trabajo para documentar las
capacidades de negocio.
WSDL describe la interfaz pública a los servicios Web.
WS-Security incorpora características de seguridad en el encabezado de un mensaje SOAP.
La Firma Digital es el método criptográfico que permite asociar la identidad de una persona o
máquina a un documento como autor del mismo.
Casi todo los grandes sistemas informáticos no son en la actualidad sistemas centralizados.
FTP es el protocolo de intercambio de ficheros.

35
2. PROGRAMACIÓN DE SERVICIOS WEB EN ENTORNOS DISTRIBUIDOS
La programación de servicios web en entornos distribuidos incluye aplicaciones y servicios que
permitirán su creación así como las interfaces que ayudarán a usarlo.
En esta etapa pueden incorporarse todas las arquitecturas que fueran necesarias y se estimen
oportunas como son servicios centralizados, Batch, servicios transaccionales, estructura cliente /
servidor basado en sistema operativo, cliente/servidor basada en Internet y aplicaciones Web
Internet.
2.1. Componentes software para el acceso a servicios distribuidos
Definición de servicios.
Un servicio web (en inglés, Web Service o Web Services) es una tecnología que utiliza un conjunto de
protocolos y estándares que sirven para intercambiar datos entre aplicaciones.
Las diferentes aplicaciones de software desarrolladas en distintos lenguajes de programación y
ejecutadas sobre diversas plataformas pueden llegar a utilizar los servicios web para intercambiar
datos en redes de ordenadores como Internet.
La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones
OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web.
Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se creó el
organismo WS-I que es el encargado de desarrollar diversos perfiles para definir de manera más
exhaustiva estos estándares.
El trabajo en el W3C se centra en las nuevas versiones de las especificaciones del núcleo de los
servicios Web esta otra organización independiente (WS-I) vuelca toda su atención en la
interoperabilidad.
La Organización para la Interoperabilidad de Servicios Web (Web Services Interoperability
Organization, WS-I) tiene como objetivos fomentar y promover la interoperabilidad de servicios web
sobre cualquier plataforma, sobre aplicaciones, y sobre lenguajes de programación.

36
Realmente lo que pretende es permitir la integración de estándares que facilite el progreso de los
servicios web hacia unas formas estructuradas y coherentes. La WS-I ha definido los estándares que
afectan a la interoperabilidad de los servicios web en una pila basada en funcionalidades.
Por ejemplo, dentro de la arquitectura SOA para la implementación de Servicios Web, la
interoperabilidad es tal vez el principio más importante. Como método de implementación de SOA,
Web Services debe ofrecer importantes beneficios de interoperabilidad, y permitir la ejecución de
servicios Web distribuidos en múltiples plataformas de software y arquitecturas de hardware.
Hay varios estándares que necesitan ser coordinados para llevar a buen término las cuestiones de
interoperabilidad de servicios. Dichos estándares se están desarrollando en paralelo y de manera
independiente.
La WS-I ha desarrollado el concepto de 'perfil' (profile) La WS-I define un perfil como un conjunto de
definiciones/especificaciones comúnmente aceptadas por la industria y a partir del apoyo a
estándares basados en XML, junto con un conjunto de indicaciones que recomiendan cómo se deben
usar las especificaciones para desarrollar servicios web interoperables entre sí.
La WS-I es una organización de carácter abierto por lo que en ella participan las principales
compañías de desarrollo de software, como IBM, Microsoft o Sun Microsystems lo que demuestra un
definitivo compromiso por incluir estos estándares en el mundo de la programación actual y futura.
Hemos visto que un sistema distribuido es un sistema de información en el cual las funciones
se reparten por áreas de trabajo diferentes que trabajan de forma coordinada para asumir los
objetivos que la organización asigna a ese sistema de información.
Esta definición no obliga a que los servicios sean internos ni fabricados por la propia
organización.
Los elementos que definen los servicios son:
Los objetivos propios de la empresa.
La plataforma donde se vaya a implementar. Una vez diseñado el sistema será la
encargada de proporcionar los recursos físicos y el software de base para ejecutarlo.
Los elementos de la conectividad. Estos se encargarán de proporcionar el transporte para
comunicar e integrar los elementos de la plataforma. Son básicamente las redes y las
comunicaciones. •
El almacenamiento de datos, formado por los datos en sí y los gestores donde se localizan. •

37
Los elementos de software donde se incluyen las aplicaciones, los servicios que ayudan a
crearlas y las interfaces que ayudan a usarlas.
En este componente se integran diferentes arquitecturas que pueden ser integradas:
Batch.
Sistema transaccional
Sistema cliente / servidor
Aplicaciones Web Internet.
Debe realizarse la gestión del sistema como un conjunto integrado y coordinado a través de
los recursos de dirección y administración. La gestión del sistema debe permitir la
coexistencia de varios centros de gestión diferentes. Hay dos cuadros de mandos o de
gestión diferentes:
El cuadro de mandos de seguimiento de los objetivos de negocio pensado para
proporcionar información automática a los gestores de como la realidad se mueve
respecto a las previsiones de los objetivos de negocio en “tiempo real”.
El cuadro de mandos de explotación desde donde se centraliza y coordina toda la
administración, supervisión y explotación del sistema.
Siempre teniendo en cuenta que se pueden usar diferentes plataformas físicas distribuidas
por compañías propias, clientes, proveedores y terceros con dispersión geográfica y
desconocimiento mutuo de las plataformas respectivas.
Generación automática de servicios.
Los servicios Web facilitan el acceso a la funcionalidad de las aplicaciones a través de Internet
facilitando la interoperabilidad entre servicios y aplicaciones, y permitiendo integrar la funcionalidad
de distintas aplicaciones empresariales.
Los métodos de producción de software plantean la necesidad de mejorar el proceso de producción
de software proporcionando una clara estrategia de generación automática de código.
Desde el punto de vista de la ingeniería dirigida por modelos estas aplicaciones se deben de generar
automáticamente a partir de modelos. La generación automática debe poder dar soporte, de forma
transparente, a las diferentes tecnologías existentes en el ámbito de los servicios Web en la
actualidad.

38
Por ejemplo, la generación de un servicio Web XML básico mediante ASP.NET.
Los servicios Web XML se construyen encima de .NET Framework y de Common Language Runtime.
Un servicio Web XML puede aprovechar estas tecnologías. Por ejemplo, mediante la creación de
servicios Web XML con ASP.NET, se puede aprovechar el rendimiento, la administración de estados y
la compatibilidad con autenticación de ASP.NET.
La infraestructura que se genera para los servicios Web XML es compatible con estándares como
SOAP, XML y WSDL, y permite a los clientes de otras plataformas interactuar con los servicios Web
XML.
Por ejemplo, si un cliente puede enviar mensajes SOAP compatibles con los estándares, con un
formato que se ajuste a una descripción de servicio, dicho cliente puede llamar a un servicio Web XML
creado con ASP.NET (independientemente de la plataforma en la que resida el cliente).
El lenguaje sobre el cual se soportan los servicios Web es XML.
XML, en inglés Extensible Markup Language, es un estándar pero realmente es algo más que un
conjunto de reglas que permiten definir etiquetas semánticas para organizar un documento en
diferentes partes.
XML es un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas
estructurados.
Para comprenderlo bien hay que procurar olvidarse del patrón de trabajo de HTML.
En teoría HTML es un subconjunto de XML especializado en presentación de documentos para la
Web mientras que XML es un subconjunto de SGML especializado en la gestión de información para
la Web. En la práctica XML contiene a HTML aunque no en su totalidad.
La definición de HTML contenido totalmente dentro de XML y por lo tanto que cumple a rajatabla la
especificación SGML es XHTML (Extensible, Hypertext Markup Language).

39
Las razones principales por las que se usa XML son:
Es un estándar abierto, es decir, es reconocido el sistema ya que muchas compañías
tecnológicas integran en sus software compatibilidad con dicho lenguaje.
Esto quiere decir que la gran mayoría de software de escritorio de sistema operativo, aplicaciones
móviles permiten la compatibilidad con XML lo que lo hace muy potente a la hora de permite la
comunicación entre distintas plataformas de software y hardware.
Sintaxis sencilla lo que permite escribir de forma sencilla en XML y que la representación de
los datos sea casi entendible por cualquier ser humano.
Es muy flexible a la hora de representar datos de cualquier naturaleza. Sólo necesitaremos un editor
de texto sencillo y aprender unas cuantas instrucciones básicas.
El hecho de que XML sea tan fácil de codificar y de entender lo hace el lenguaje ideal para utilizarlo
en los servicios Web.
Independencia del protocolo de transporte. El hecho de que XML sea un lenguaje de
marcado no necesita de ningún protocolo de transporte especial.
Sólo es necesario un protocolo que pueda trasferir texto o documentos simples. Existen muchos
protocolos con estas características como son los populares HTTP y SMTP.
¿Qué es SOAP?
Las siglas corresponden a Simple Object Access Protocol. Es un protocolo que deriva de un protocolo
anterior creado por David Winer, el XML-RPC.
En el sitio web, Userland (http://www.userland.com) se puede encontrar abundante documentación
acerca de este primer protocolo de comunicación bajo HTTP mediante XML.
Usando este protocolo se podía ya desde el cliente o desde el servidor realizar peticiones mediante
HTTP a un servidor web. Los mensajes deben tener un formato determinado empleando XML para
encapsular los parámetros de la petición. Con el paso del tiempo el proyecto empezó a cuajar entre
las multinacionales como IBM y Microsoft.
En el centro de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP que
proporciona un mecanismo estándar de empaquetar mensajes.

40
SOAP facilita una comunicación entre un cliente y un servidor remoto pero existen multitud de
protocolos creados para facilitar la comunicación entre aplicaciones:
RPC de Sum.
DCE de Microsoft.
RMI de Java.
ORPC de CORBA.
Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la industria y
ha sido aceptado prácticamente por todas las grandes compañías de software del mundo.
Compañías que en raras ocasiones cooperan entre sí ofrecieron su apoyo a este protocolo. Algunas
de las mayores empresas que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba.
Algunas de las Ventajas de SOAP son:
No está asociado con ningún lenguaje.
SOAP no especifica una API por lo que dicha implementación se deja al lenguaje de programación,
como en Java, y la plataforma como Microsoft .Net.
No se encuentra fuertemente asociado a ningún protocolo de transporte.
La especificación de SOAP no describe como se deberían asociar los mensajes de SOAP con HTTP. Un
mensaje de SOAP no es más que un documento XML por lo que puede transportarse utilizando
cualquier protocolo capaz de transmitir texto.
No está ligado a ninguna infraestructura de objeto distribuido. La mayoría de los sistemas de
objetos distribuidos se pueden extender.
Aprovecha los estándares existentes en la industria.
Los principales contribuyentes a la especificación SOAP optaron por extender los estándares
existentes para que coincidieran con sus necesidades.
Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes en lugar de utilizar su propio
sistema de tipo que ya están definidas en la especificación esquema de XML.
SOAP no define un medio de trasporte de los mensajes; los mensajes de SOAP se pueden asociar a
los protocolos de transporte existentes como HTTP y SMTP.
Permite la interoperabilidad entre múltiples entornos.
SOAP se desarrolló sobre los estándares existentes de la industria por lo que las aplicaciones que se
ejecuten en plataformas con dicho estándares pueden comunicarse mediante mensaje SOAP con
aplicaciones que se ejecuten en otras plataformas.
Por ejemplo, una aplicación de escritorio que se ejecute en una PC puede comunicarse con una
aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.

41
Estructura de un mensaje de SOAP.
SOAP proporciona un mecanismo estándar de empaquetar un mensaje.
Un mensaje SOAP se compone de una parte que contiene el sobre del mensaje y cualquier
información de cabecera que se utilice para describir el mensaje.
Por ejemplo,
El elemento raíz del documento es el elemento Envelope.
El ejemplo contiene dos subelementos, Body y Header. Un ejemplo de SOAP valido también puede
contener otros elementos hijo en el sobre.
El sobre puede contener un elemento Header opcional que contiene información sobre el mensaje.
En el ejemplo anterior, la cabecera contiene dos elementos que describen a quien compuso el
mensaje, y posible receptor del mismo.
El sobre debe contener un elemento body el elemento body (cuerpo) contiene la carga de datos del
mensaje. En el ejemplo el cuerpo contiene una simple cadena de caracteres.
El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no
pertenecen necesariamente al cuerpo del mensaje.
Además de definir un sobre de SOAP la especificación de SOAP define una forma de codificar los
datos contenidos en un mensaje.
La especificación de SOAP también proporciona un patrón de mensaje estándar para facilitar el
comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación de un
mensaje de petición con un mensaje de respuesta.
La llamada a un método y sus parámetros se realizan en el cuerpo del mensaje de petición en forma
de una estructura.
El mensaje de respuesta puede contener los resultados de la llamada al método o también una
estructura de fallo bien definida. Hay que tener en cuenta que los resultados de la llamada a un
método se serializan en el cuerpo de la petición como una estructura.
Por convenio, el elemento raíz tiene el mismo nombre que el método original al que se añade result.

42
Los parámetros de vuelta o retorno se serializan como elementos hijo, con el parámetro de retorno
en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendrá una
estructura de fallo bien definida.
Por convenio, el elemento raíz tiene el mismo nombre que el método original al que se añade result.
Los parámetros de retorno se serializan como elementos hijo, con el parámetro de retorno en primer
lugar.
Si se encuentra un error el cuerpo del mensaje de respuesta contendrá una estructura de fallo bien
definida.
Documentación de servicios web con WSDL.
El esquema XML por sí solo no puede describir totalmente un servicio Web.
Por ejemplo, supongamos que se ha creado un servicio Web Calculadora. Este servicio Web expone
los métodos sumar y restar. Ambos métodos aceptan dos enteros y devuelven un único entero con el
resultado; sumar devuelve la suma de los dos enteros y restar devuelve su diferencia.
Además de la información que proporciona el esquema, necesitaríamos invocar los métodos que
expone el Servicio Web Calculadora. Como el cuerpo de un mensaje de SOAP puede contener
cualquier cosa que no invalide el XML los mensajes de SOAP se pueden combinar para disponer de
una amplia variedad de patrones de intercambio de mensajes. Los patrones de intercambio de
mensajes para el Servicio Web Calculadora son bastante inmediatos pero una asociación formal entre
los mensajes de petición Sumar y Restar y sus mensajes de respuesta asociados eliminarían cualquier
posible ambigüedad.
Una descripción formal de los patrones de mensaje resulta aún más importante en el caso de Servicio
Web más complejos. Algunos servicios podrían aceptar una petición pero no enviar la respuesta
correspondiente devuelta al cliente. Otros podrían solamente enviar mensajes al cliente.
Además, el esquema no contiene información sobre cómo acceder al Servicio Web porque SOAP es
independiente del protocolo e intercambiarán los mensajes entre el cliente y el servidor de
numerosas formas.
El lenguaje de descripción de servicios Web (WSDL, Web Service Description Language) es una
variante en XML del esquema que describe un servicio Web. Un documento WSDL proporciona la
información necesaria al cliente para interaccionar con el servicio Web.
WSDL es extensible y se pude utilizar para describir, prácticamente, cualquier servicio de red
incluyendo SOAP sobre HTTP e incluso protocolos que no se basan en XML como DCOM sobre UDP.

43
Como los protocolos de comunicaciones y los formatos de mensajes están estandarizados en la
comunidad del Web a medida que pasa el tiempo aumenta la posibilidad e importancia de describir
las comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramática
XML que describe los servicios de red como colecciones de puntos finales de comunicación capaces
de intercambiar mensajes.
Las definiciones de servicio de WSDL proporcionan documentación para sistemas distribuidos y
sirven como fórmula para automatizar los detalles que toman parte en la comunicación entre
aplicaciones.
Los documentos WSDL definen los servicios como colecciones de puntos finales de red o puertos.
En WSDL, la definición abstracta de puntos finales y de mensajes se separa de la instalación concreta
de red o de los enlaces del formato de datos lo que facilita la reutilización de definiciones abstractas.
Un puerto se define por la asociación de una dirección de red y un enlace reutilizable; una colección
de puertos define un servicio. Por esta razón, un documento WSDL utiliza los siguientes elementos
en la definición de servicios de red:
Types.
Contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos.
Por ejemplo, XSD.
Message.
Definición abstracta y escrita de los datos que se están comunicando.
Operation.
Descripción abstracta de una acción admitida por el servicio.
Port Type.
Conjunto abstracto de operaciones admitidas por uno o más puntos finales.
Binding.
Especificación del protocolo y del formato de datos para un tipo de puerto determinado.
Port.
Punto final único que se define como la combinación de un enlace y una dirección de red.
Service.
Colección de puntos finales relacionados.
UDDI.
Una vez definido el servicio web necesitamos dar a conocer de su existencia a la comunidad. Aquí es
donde interviene UDDI que se va a encargar de ello.

44
Existe un mecanismo de descubrimiento que cumple estos requisitos, es UDDI (Universal Description
Discovery and Integration) que es una iniciativa del sector para hacer compatible el descubrimiento
de servicios Web con todo tipo de tecnologías y plataformas.
UDDI es un registro público diseñado para almacenar de forma estructurada información sobre
empresas y los servicios que éstas ofrecen. A través de él se puede publicar y descubrir información
de una empresa y de sus servicios.
Se puede utilizar sistemas taxonómicos estándar para clasificar estos datos y poder encontrarlos
posteriormente en función de la categorización. Lo fundamental es que UDDI contiene información
sobre las interfaces técnicas de los servicios de una empresa.
A través de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI
tanto en tiempo de diseño como de ejecución para descubrir datos técnicos de los servicios que
permitan invocarlos y utilizarlos. De este modo, UDDI sirve como infraestructura para una colección
de software basado en servicios Web.
El servicio Web XML.
El servicio Web XML creado mediante ASP.NET admite automáticamente clientes que se
comuniquen mediante los protocolos SOAP, HTTP-GET y HTTP-POST. Puesto que los protocolos HTTP-
GET y HTTP-POST permiten el paso de mensajes en pares de nombre y valor codificados en
direcciones URL, no admiten tantos tipos de datos como SOAP.
En el protocolo SOAP, en el que se pasan datos con origen y destino en el servicio Web XML
mediante XML, puede definir tipos de datos complejos con esquemas XSD, que admiten un conjunto
más amplio de tipos de datos. Los programadores que creen un servicio Web XML con ASP.NET no
tienen que definir de forma explícita los tipos de datos complejos que esperan recibir con un
esquema XSD. En su lugar, pueden crear simplemente una clase administrada. ASP.NET controla la
asignación de definiciones de clase a un esquema XSD y la asignación de instancias de objeto a datos
XML, con el fin de transmitirlos en una red.
Es importante observar que los servicios Web XML no son una forma de reemplazar DCOM, sino una
infraestructura de mensajería para llevar a cabo la comunicación entre plataformas con estándares
del sector.
Un servicio web XML es un ente programable que proporciona un elemento determinado de
funcionalidad. Permite aplicar sobre él la lógica de la aplicación y es accesible por diversos sistemas
potencialmente dispares usando los estándares de Internet, como XML y HTTP.
Los servicios web XML dependen en gran medida de la amplia aceptación de XML y otros estándares
de Internet para crear una infraestructura que admita la interoperabilidad de aplicaciones en un nivel
que resuelva muchos de los problemas que anteriormente impidieron tales intentos.

45
Por ejemplo, un servicio web XML puede usarse internamente por una sola aplicación o exponerse
externamente a través de Internet para su uso por diversas aplicaciones. Puesto que es accesible a
través de una interfaz estándar, un servicio web XML permite a sistemas heterogéneos funcionar
juntos como una sencilla web de cálculo.
En lugar de seguir las funciones genéricas de portabilidad de código, los servicios web XML
proporcionan una solución viable para habilitar los datos y la interoperabilidad del sistema.
Los servicios web XML usan la mensajería basada en XML como un medio fundamental para la
comunicación de datos.
Los programadores pueden crear aplicaciones que desarrollen juntas servicios web XML de varios
orígenes de la misma manera que usan tradicionalmente los componentes para crear una aplicación
distribuida.
Una de las características básicas de un servicio web XML es el alto grado de abstracción que existe
entre la implementación y el uso de un servicio.
Los servicios web XML proporcionan la interoperabilidad en un nivel completamente nuevo que
niega tales rivalidades contraproducentes.
Los servicios Web XML deben su funcionamiento a SOAP que es un protocolo basado en normas
estándar que se utiliza para intercambiar información en formato XML a través de una red.
Cada servicio Web incluye un archivo WSDL (lenguaje de descripción de servicios Web) que contiene
información sobre el servicio Web XML y sus capacidades. Los proveedores de servicios Web pueden
registrar sus servicios Web utilizando Universal Description Discovery and Integration (UDDI), una
especificación para la publicación y la localización de información relativa a los servicios Web.
Los usuarios interesados pueden buscar en el registro de UDDI servicios Web que podrían resultarles
de utilidad. Una vez agregado un servicio Web a un sitio Web, la información sobre dicho servicio se
muestra utilizando el Protocolo de transferencia de hipertexto (HTTP).
Un servicio Web utiliza SOAP y WSDL para comunicarse con el explorador
Para agregar un servicio Web a la Biblioteca de orígenes de datos, debe conocer la dirección URL de
la descripción WSDL del servicio Web que es una URL normalmente termina por ?WSDL o .wsdl.

46
Windows SharePoint Services 3.0 proporciona servicios Web para interaccionar con casi cualquier
aspecto de cada servidor, sitio, lista, biblioteca, encuesta o página Web.
El servicio Web Webs proporciona métodos para trabajar con sitios y subsitios de SharePoint.
Por ejemplo, puede usar este servicio Web para mostrar y realizar consultas de los títulos y
direcciones URL de todos los sitios contenidos en la colección actual de sitios, de los títulos y
direcciones URL de todos los sitios ubicados directamente debajo del sitio actual, o de la dirección URL
del sitio principal de la dirección URL de la página especificada.
2.2. Programación de diferentes tipos de acceso a servicios
Servicios basados en publicación/suscripción.
El funcionamiento sigue unas normas específicas:
Las aplicaciones comunican intercambiando mensajes caracterizados por tipo y un conjunto
de parámetros.
Las aplicaciones que envían mensajes, los “publican “ en el middleware, que se encarga de
redirigirlos.

Desarrollo de aplicaciones web distribuidas.

Desarrollo de aplicaciones web distribuidas.

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Desarrollo de aplicaciones web distribuidas.

Ähnlich wie Desarrollo de aplicaciones web distribuidas. (20)

Mehr von Jomicast

Mehr von Jomicast (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (16)

Desarrollo de aplicaciones web distribuidas.