Tema 36 Soa Cetic

Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado
TEMA II.07 ARQUITECTURA DE SISTEMAS CLIENTE-SERVIDOR Y

MULTICAPAS: TIPOLOGÍA. COMPONENTES. INTEROPERABILIDAD DE
COMPONENTES. VENTAJAS E INCONVENIENTES. ARQUITECTURA DE
SERVICIOS WEB.
1
www.cetic.es
ÍNDICE
1. INTRODUCCIÓN 3
2. CONCEPTOS GENERALES DE LA ARQUITECTURA CLIENTE/SERVIDOR 4
2.1 PRINCIPALES CARACTERÍSTICAS 4
2.2 SEPARACIÓN DE FUNCIONES EN CAPAS 5
2.3 COMPONENTES 7
2.4 VENTAJAS DE LA ARQUITECTURA CLIENTE/SERVIDOR 7
2.5 DESVENTAJAS DE LA ARQUITECTURA CLIENTE/SERVIDOR 7
3. ARQUITECTURA DE SERVICIOS WEB 8
3.1 ARQUITECTURAS ORIENTADAS A SERVICIOS (SOA) 8
3.2 SERVICIOS WEB 9
3.3 SOAP 10
3.3.1 PARTES DE UN MENSAJE SOAP 10
3.3.2 TIPOS DE DATOS EN SOAP Y SERIALIZACIÓN 12
3.3.2.1 STRUCTS 13
3.3.2.2 ARRAYS 13
3.3.3 SOAP Y HTTP 13
3.4 UDDI 14
3.5 WSDL 15
3.5.1 WSDL: DESCRIPCIÓN DE LA INTERFAZ DEL SERVICIO 15
3.5.1.1 TIPOS 15
3.5.1.2 OPERACIONES E INTERFACES 16
3.5.2 WSDL: DESCRIPCIÓN DE LA IMPLEMENTACIÓN DEL SERVICIO 17
3.5.2.1 BINDINGS 17
3.5.2.2 SERVICIOS Y ENDPOINTS 17
3.5.3 WSDL: EL EJEMPLO COMPLETO 17
3.5.4 WSDL 2.0 Y WSDL 1.1 19
2
www.cetic.es
3.6 SEGURIDAD EN SERVICIOS WEB 19

3.6.1 ASPECTOS A CONSIDERAR EN RELACIÓN A LA SEGURIDAD 19
3.6.2 WS-SECURITY 20
3.6.3 MECANISMOS DE SEGURIDAD 21
4. REST (REPRESENTATIONAL STATE TRANSFER) 21
4.1 MÉTODOS HTTP EN REST 22
4.2 JSON (JAVASCRIPT OBJECT NOTATION) 23
4.2.1 TIPOS DE DATOS EN JSON 23
5. ANEXO I PREGUNTAS APARECIDAS EN LOS ÚLTIMOS EXÁMENES DE ACCESO AL CUERPO GSI 25
6. ANEXO II PREGUNTAS APARECIDAS EN LOS ÚLTIMOS EXÁMENES DE ACCESO AL CUERPO TAI26
7. ANEXO III RESPUESTAS CORRECTAS 30
8.GLOSARIO 31
9. CONCLUSIÓN 32
3
www.cetic.es
1. INTRODUCCIÓN
En este tema se presentan los conceptos fundamentales sobre arquitectura cliente/servidor y

sobre la arquitectura que soporta los populares servicios web.
En primer lugar se hablará de la arquitectura cliente/servidor, comenzando por algunos
conceptos generales para a continuación seguir con sus características más importantes, la
división de las funciones a realizar por las distintas capas de la arquitectura y los componentes
de que consta. Por último se comentarán sus principales ventajas e inconvenientes.
En la segunda parte del tema, que ocupa la mayor parte del mismo, se trata la arquitectura de
servicios web. Se empezará hablando del concepto de arquitecturas orientadas a servicios
(SOA), de las que los Servicios Web son una forma de implementación, para después describir
en detalle en qué consisten los Servicios Web y las tecnologías más importantes que permiten
trabajar con ellos: SOAP, UDDI, WSDL. A continuación se tratarán aspectos relacionados con la
seguridad en Servicios Web. Por último, se hablará brevemente de REST como alternativa a
SOAP, así como de JSON y su uso como alternativa a XML.
En una serie de Anexos al final del tema quedarán recogidas las preguntas que ha habido en los
exámenes de los procesos selectivos GSI y TAI en los años 2015 al 2019 (este es un tema que no
se incluye en el temario del cuerpo TIC), con indicación al punto dentro del tema donde puede
hallarse la respuesta correcta o, en caso de no estar recogida explícitamente en el mismo,
indicación de posibles referencias donde buscarla. Además, las partes concretas que han
aparecido en el primer ejercicio del GSI están marcadas en color rojo.
En el temario de la oposición GSI hay dos temas con una relación importante con este:
- II.10 -> Lenguajes de marca o etiqueta. Características y funcionalidades. SGML, HTML,
XML y sus derivaciones. Lenguajes de script.
- III.15 -> Aplicaciones web. Diseño web multiplataforma/multidispositivo. Desarrollo web
front-end y en servidor. Componentes de tecnologías de programación. Servicios web:
estándares, protocolos asociados, interoperabilidad y seguridad. Internacionalización y
localización.
Este es un tema del que no suelen aparecer demasiadas preguntas en el primer examen del
proceso selectivo GSI, (una en 2019, ninguna en los dos años anteriores ni en 2015 y tres en
2016)
4
www.cetic.es
2. CONCEPTOS GENERALES DE LA ARQUITECTURA CLIENTE/SERVIDOR
El concepto de cliente/servidor se refiere a una arquitectura en la que cada ordenador o

proceso en una red desempeña uno de estos dos papeles, el de cliente (consumidor de recursos
o servicios), o el de servidor (proveedor de recursos o servicios). Es un concepto que se
contrapone, por ejemplo, al de las redes P2P, donde todos los equipos conectados realizan las
mismas funciones.
Normalmente los clientes (front-end) son máquinas menos potentes y usan los recursos que
ofrecen los servidores (back-end), que suelen ser ordenadores potentes dedicados a tareas
especializadas:
● Servidor de ficheros (gestiona sistemas de almacenamiento)
● Servidor de impresión (gestiona colas y servicios de impresión)
● Servidor de red (gestiona el tráfico en una red)
● Servidor de datos (aloja y gestiona bases de datos)
● Servidor de aplicaciones (gestiona el acceso a aplicaciones)
La principal característica de esta arquitectura es que permite separar las funciones que ha de
realizar cada uno de los componentes que debe intervenir a la hora de proporcionar una
determinada funcionalidad, permitiendo situar cada una en la plataforma más adecuada para
su ejecución.
2.1 PRINCIPALES CARACTERÍSTICAS
● El servidor presenta a todos sus clientes una interfaz única y bien definida.
● El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa
(encapsulación)
● El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el
que se encuentra, ni de su sistema operativo (interoperabilidad)
● Los cambios en el servidor implican pocos o ningún cambio en el cliente (bajo
acoplamiento)
● Un servidor puede atender a muchos clientes al mismo tiempo y regular sus accesos a
los recursos compartidos.
● Los clientes y servidores interactúan utilizando un mecanismo de paso de mensajes. El
mensaje es el soporte para las peticiones de servicios y las respuestas.
● El código y los datos del servidor se mantienen centralizados, con lo que es menos
costoso su mantenimiento y el control de la integridad de los datos compartidos.
● Escalabilidad. Permite, sin necesidad de realizar cambios en las aplicaciones, el
crecimiento horizontal (capacidad de añadir o suprimir estaciones de trabajo que hagan
uso de la aplicación, es decir, clientes) o vertical (migración hacia servidores de mayor o
menor capacidad y velocidad o de un tipo diferente)
5
www.cetic.es
2.2 SEPARACIÓN DE FUNCIONES EN CAPAS
La arquitectura cliente/servidor permite la separación de funciones en tres capas:

● Lógica de presentación (capa 1): interacción de las aplicaciones con el usuario, para la
captura de información y para su presentación, con un nivel de procesamiento de la
información mínimo (básicamente, detección de errores durante la captura de datos no
relacionados con la lógica de negocio)
● Lógica de negocio (o aplicación, capa 2): Implementa la funcionalidad de negocio. A
partir de los datos capturados, de los existentes en la base de datos y de la petición
recibida, procesa la información y elabora una respuesta.
● Lógica de datos (capa 3): Acceso a los datos, ya sea para su lectura o para su
modificación.
Si un sistema distribuido se diseña correctamente, estas tres capas pueden distribuirse y
redistribuirse independientemente sin afectar al funcionamiento de la aplicación. Es importante
destacar que las capas 1 (presentación) y 3 (datos) no se comunican nunca de forma directa, lo
hacen siempre a través de la capa 2 (negocio)
En función de cómo se distribuyan, entre el cliente y el servidor, las tres capas de la lógica de las
aplicaciones, aparecen varias variantes de la arquitectura cliente/servidor:
● Presentación Distribuida. En este modelo, se distribuye la presentación entre el cliente y
el servidor, pero éste último ejecuta todos los procesos y almacena la totalidad de los
datos.
● Presentación Remota. Aquí, la interfaz del usuario está completamente en el cliente, la
presentación soporta la captura de datos, incluyendo una validación parcial de los
mismos y una presentación de las consultas. La lógica de la aplicación y los datos están
en el servidor.
● Proceso Distribuido. Se da cuando la presentación está en el cliente, la base de datos
está en el servidor y la lógica de la aplicación está distribuida entre el cliente y el
servidor.
● Gestión de Datos Remota. Para este modelo, tanto la presentación como los procesos de
la aplicación residen en el cliente, mientras que las bases de datos permanecen
centralizadas en el servidor.
● Bases de Datos Distribuidas. Este último modelo, la presentación, los procesos de la
aplicación y parte de los datos de la Base de Datos están en el cliente; el resto de los
datos están en el servidor.
Así, en función de si hay una mayor o menor carga de trabajo en el cliente, se habla de clientes
pesados o clientes ligeros. La variante Presentación Distribuida es el ejemplo del tipo más ligero
de cliente, mientras que la variante Bases de Datos Distribuidas sería el ejemplo de un cliente
pesado. Lógicamente, cuanto más ligero (fino, thin) sea el cliente, más pesado (grueso, thick)
será el servidor y viceversa.
6
www.cetic.es
La diferencia entre las arquitecturas de dos y tres niveles estriba en la forma de distribución de
las tres capas de la aplicación entre el cliente y el servidor.
En una arquitectura de dos niveles hay dos opciones:
● En el cliente se alojan la lógica de presentación y la lógica de negocio, mientras que los
datos se alojan y gestionan en el servidor. Son las aplicaciones tradicionales que
requieren de una instalación del software en el cliente. Un ejemplo podría ser una
aplicación instalada en cliente que se conecta, por ejemplo usando ODBC, a una base de
datos remota.
● En el cliente se aloja únicamente la lógica de presentación, mientras que la lógica de
negocio y los datos se alojan en el servidor.
En las arquitecturas de tres niveles, la lógica de presentación, la lógica de negocio y la lógica de
datos están separadas, de tal forma que mientras la lógica de presentación se ejecutará en el
cliente, la lógica de negocio se ejecuta en un servidor de aplicaciones y la de datos lo hará en un
servidor de base de datos. Es el modelo más habitual en aplicaciones web, donde el cliente es el
navegador, que se ocupa únicamente de presentar la información y de capturar la interacción
del usuario con la aplicación, un servidor de aplicaciones ejecuta la lógica de negocio y un
segundo servidor almacena la base de datos, como se muestra a continuación:
Ilustración 1: Arquitectura de tres capas
7
www.cetic.es
Debe tenerse en cuenta en cualquier caso que el número de equipos no tiene por qué
condicionar ni estar condicionado por el número de niveles de la arquitectura. Puede
perfectamente implementarse toda la arquitectura en un mismo equipo (aunque no tendría
demasiado sentido porque se perderían la mayor parte de las ventajas)
2.3 COMPONENTES
Los componentes de una arquitectura cliente/servidor son:

● Clientes: consumen servicios.
● Servidores: proporcionan servicios.
● Bases de Datos: almacenan la información.
● Red: articula la comunicación entre clientes y servidores.
● Protocolos: determinan cómo se debe realizar la petición y consumo de los servicios.
● Servicios: proporcionados por los servidores, para su consumo por los clientes, según
unos protocolos establecidos, a través de una red que los conecta y usando los datos
almacenados en una o varias bases de datos.
2.4 VENTAJAS DE LA ARQUITECTURA CLIENTE/SERVIDOR
● Facilita la interacción entre sistemas heterogéneos: clientes y servidores pueden estar

basados en tecnologías completamente diferentes (interoperabilidad)
● Especialización de los clientes: permite la creación de mejores interfaces de usuario
(mayor calidad, mayor orientación al tipo de cliente)
● Mejora de la escalabilidad: horizontal y vertical.
● Mayor facilidad de mantenimiento: cada componente puede ser mantenido por
especialistas, permitiendo además que los mantenimientos sean transparentes al resto
de componentes de la arquitectura.
● Incremento de la seguridad en relación a los clientes: los clientes no saben nada acerca
de los otros clientes, un cliente potencialmente peligroso puede ser aislado.
● Incremento de la seguridad en relación a los servidores: la capa de presentación no
accede a la capa de datos, por lo que ésta se encuentra más protegida.
2.5 DESVENTAJAS DE LA ARQUITECTURA CLIENTE/SERVIDOR
● Unido al aumento de niveles en la arquitectura siempre va un aumento del tráfico de

red.
● Problemas de disponibilidad en caso de problemas en los servidores (menos puntos de
fallo que en, por ejemplo, una arquitectura P2P)
● Necesidad de contar con servidores potentes (o con un número de elevado de ellos)
cuando crece el número de clientes.
8
www.cetic.es
3. ARQUITECTURA DE SERVICIOS WEB
3.1 ARQUITECTURAS ORIENTADAS A SERVICIOS (SOA)
La evolución de los sistemas de información ha supuesto una interacción cada vez mayor entre
aplicaciones de características muy diferentes. Esto supone un aumento en la complejidad de
los sistemas que hace necesario el establecer modelos que permitan que dicha complejidad
pueda gestionarse adecuadamente.
En este contexto, SOA (Service Oriented Architecture) se define como una forma de construir
soluciones software, mediante el uso de diferentes servicios independientes, en un entorno
distribuido (es decir, no centralizado)
Cada uno de estos servicios es una funcionalidad empaquetada como un componente
reutilizable para su utilización en un proceso de negocio.
Tienen cuatro características esenciales:
● Implementan una actividad de negocio repetible, con un resultado concreto.
● Son autocontenidos, es decir, implementan la actividad de negocio de manera completa.
● Se comportan como una caja negra frente a quién los usa, presentando una interfaz de
comunicación que oculta los detalles de la implementación.
● Pueden hacer uso de otros servicios.
No hay estándares que definan de manera exacta cómo debe implementarse una arquitectura
SOA, pero hay una serie de principios sobre los que en la práctica se ha alcanzado un consenso
entre los distintos fabricantes.
- Los servicios presentan un contrato formal: su interfaz de comunicación está claramente
definida y publicada en uno o varios documentos.
- Los servicios deben presentar un nivel mínimo de acoplamiento: cada servicio que
invoca a otros servicios, conoce de éstos solamente su existencia, no sabe
absolutamente nada de su implementación o de su ubicación.
- Los servicios deben perdurar en el tiempo y ser estables: cada servicio que invoca a
otros servicios, no debería necesitar modificar la forma en que realiza dicha invocación
siempre que lo que necesite de éstos no cambie.
- Los servicios deben ser ‘sin estado’: el resultado obtenido de la invocación a un servicio
debe ser siempre el mismo y no estar sujeto a condiciones previas.
- Los servicios deben poder estar implementados como llamadas a otros servicios.
- Los servicios deben facilitar un medio para ser descubiertos: para ello, deben publicarse
acompañados de metadatos que permitan su localización y su invocación.
9
www.cetic.es
3.2 SERVICIOS WEB
Los Servicios Web (Web Services) son en la actualidad la implementación más habitual de la
arquitectura SOA. El W3C los define como:
Sistema software diseñado para soportar la interacción máquina-a-máquina a través de
una red y de forma interoperable.
Más específicamente, un Servicio Web es una unidad de la lógica del negocio que proporciona
datos y servicios para otras aplicaciones. Las aplicaciones acceden a los Servicios Web vía
protocolos web como HTTP y SOAP y formatos de datos universales como XML, sin necesidad
de preocuparse de cómo cada Servicio Web es implementado, por tanto, facilitan la integración
de aplicaciones desarrolladas en entornos tecnológicos heterogéneos, tanto a nivel software
como hardware.
Un Servicio Web es similar a un sitio web que no cuenta con un interfaz de usuario y que da
servicio a las aplicaciones en lugar de a las personas y, en vez de obtener solicitudes desde el
navegador y retornar páginas web como respuesta, recibe solicitudes a través de un mensaje
formateado en XML desde una aplicación, realiza una tarea y devuelve un mensaje de respuesta
también en formato XML.
Algunos de los frameworks más populares para trabajar con Servicios Web son: Apache Axis
(Java y C++), Java Web Service Development Pack, JWSDP (Java), Apache CXF (Java), gSOAP (C
y C++)
En la implementación de Servicios Web hay implicados una serie de estándares:
Estándar Organismo URL

SOAP Simple Object Access Protocol W3C https://www.w3.org/TR/soap/
XML eXtensible Markup Language W3C https://www.w3.org/XML/
UDDI Universal Description, Discovery and OASIS http://uddi.xml.org/
Integration
WSDL Web Services Description Language W3C https://www.w3.org/TR/wsdl/
10
www.cetic.es
Y el esquema básico de la implementación y uso de un servicio web sería:
Ilustración 2: Esquema básico de la implementación y consumo de un servicio web
● Quién implementa el servicio (proveedor) genera el WSDL describiendo el Servicio Web

y lo registra en el directorio UDDI o Service Registry.
● Quién desea utilizar el servicio (consumidor) se pone en contacto con el UDDI para
localizar el Servicio Web.
● El consumidor a su vez, basándose en la descripción contenida en el WSDL, envía al
proveedor una petición mediante un mensaje SOAP para el servicio concreto.
● El proveedor analiza el mensaje SOAP de la petición, la procesa, genera un mensaje
SOAP con el resultado y lo devuelve a quién realizó la petición.
● El consumidor analiza el mensaje de respuesta SOAP y lo interpreta.
3.3 SOAP
SOAP (Simple Object Access Protocol), es un protocolo estandarizado por el W3C que
proporciona un mecanismo de intercambio de información entre dos puntos usando mensajes
construidos con el lenguaje XML.
SOAP surge con intención de alcanzar dos objetivos:
● Definir un protocolo de invocación a servicios remotos basado en estándares de uso

frecuente en Internet, como HTTP para la transmisión y XML para la codificación.
● Independencia del hardware, el lenguaje de programación y la implementación del
servicio.
3.3.1 PARTES DE UN MENSAJE SOAP
11
www.cetic.es
Un mensaje SOAP es un documento en formato XML constituido por tres partes bien definidas:
● SOAP Envelope, obligatorio

● SOAP Header opcional
● SOAP Body, obligatorio
Cada uno de estos elementos contiene lo siguiente:

● El Envelope es el elemento más importante y de mayor jerarquía dentro del documento
XML y representa al mensaje que lleva almacenado dicho documento.
o Contiene un elemento obligatorio, el namespace (xmlns:soap) cuyo valor, para la
última versión de SOAP (1.2) ha de ser:
▪ http://www.w3.org/2003/05/soap-envelope
o Puede contener un atributo opcional soap:encodingStyle que indica los tipos de
datos usados en el XML.
● El Header se utiliza para añadir características adicionales al mensaje SOAP.
● El Body es un contenedor de información en el cual se almacenarán los datos que se
quieran transmitir de lado a lado de la comunicación. Dentro de este campo, SOAP
define un elemento de uso opcional denominado Fault utilizado en los mensajes de
respuesta para indicar al cliente algún error ocurrido en el servidor.
Ejemplo de mensaje SOAP, en este caso solicitando información del opositor con el ID = 100:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap=”http://www.w3.org/2003/05/soap-envelope”
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Body>
<m:GetOpositor xmlns m=”http://www.ejemplos.com/ejem1”>
<m:OpositorId>100</m:OpositorId>
</m:GetOpositor>
</soap:Body>
</soap:Envelope>
Un ejemplo de respuesta (correcta) a este mensaje:

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
<soap:Body>
<m:GetOpositorResponse xmlns:m=" http://www.ejemplos.com/ejem1">
<m:Nombre>Juan</m:Nombre>
<m:Apellido>Español</m: Apellido >
</m:GetOpositorResponse >
12
www.cetic.es
</soap:Body>
</soap:Envelope>
Un ejemplo de respuesta (con error) a este mensaje:
<soap:Envelope
xmlns:soap=”http://www.w3.org/2003/05/soap-envelope”
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Error procesando petición</stringcode>
<faultactor/>
<detail/>
</soap:Fault>
</soap:Body>
</soap:Envelope>
3.3.2 TIPOS DE DATOS EN SOAP Y SERIALIZACIÓN
SOAP define una serie de tipos básicos que se empaquetan de forma directa y una serie de
mecanismos para empaquetar tipos complejos y estructurados formados por elementos
simples.
En sus versiones iniciales, SOAP contemplaba un conjunto de tipos como tipos simples con el fin
de realizar un mapeo directo entre el propio documento SOAP y tipos básicos de Java.
Actualmente este conjunto ha aumentado de forma que existe un número bastante grande de
tipos que se tratan como tipos simple. Algunos de los más importantes, junto con la
correspondiente clase Java a la que equivalen, son los siguientes:
SOAP Java
SOAP-ENC:int java.lang.Integer
SOAP-ENC:long java.lang.Long
SOAP-ENC:short java.lang.Short
SOAP-ENC:string java.lang.String
SOAP-ENC:boolean java.lang.Boolean
SOAP-ENC:float java.lang.Float
13
www.cetic.es
SOAP-ENC:double java.lang.Double
SOAP-ENC:byte java.lang.Byte
Además de todos los tipos sencillos, SOAP implementa una serie de mecanismos para serializar
tipos complejos con elementos simples en su interior:
3.3.2.1 STRUCTS
Un struct es un elemento que contiene a su vez un conjunto de elementos hijos almacenados
cada uno de ellos en un campo propio. Por ejemplo:
<Opositor xmlns=" http://www.ejemplos.com/ejemp2">
<OpositorId>100</OpositorId>
<Nombre>Juan</Nombre>
<Apellido>Español</Apellido>
</Opositor>
que representa un elemento de tipo Opositor dentro del cual hay tres elementos sencillos, uno
de tipo int y dos de tipo string.
3.3.2.2 ARRAYS
En un mensaje SOAP se representan mediante un elemento cuyo tipo es SOAP-ENC:Array.
Aunque en la mayoría de lenguajes de programación sea obligatorio que dentro de un array
haya únicamente elementos del mismo tipo, SOAP no presenta esta restricción, sino que es
posible albergar elementos de distintos tipos en un mismo array. Por ejemplo:
<EjemploDeArrayHeterogeneo xsi:type=”SOAP-ENC:Array”>
<OpositorId xsi:type=”xsd:int”>100</OpositorId>
<Nombre xsi:type=”xsd:string”>Juan</Nombre>
<Apellido xsi:type=”xsd:string”>Español</ Apellido>
</ EjemploDeArrayHeterogeneo>
Es posible restringir el número y tipo de los elementos almacenados en un array:

<EjemploArray xsi:type=”SOAP-ENC:Array” SOAP-ENC:arrayType=”xsd:int[3]”>
</ EjemploArray>
3.3.3 SOAP Y HTTP
Una de las funcionalidades más importantes con que cuenta SOAP es el envío de mensajes
usando el protocolo HTTP, de forma directa por medio de las librerías de SOAP.
14
www.cetic.es
Esto provoca que existan ciertas diferencias entre un mensaje SOAP normal y uno enviado
haciendo uso del protocolo HTTP. En este último caso deben cumplirse dos condiciones:
● El HTTP header del mensaje de petición al Servicio Web debe contener un campo
SOAPAction. El campo SOAPAction alerta a los servidores web y firewalls por los que
pase de que el mensaje contiene documento SOAP, de manera que los firewalls filtran
las peticiones SOAP sin necesidad de tener que explorar el contenido del body del
mensaje.
● Si la petición SOAP al Servicio Web falla, el servidor debe devolver en el mensaje de
respuesta un error del tipo HTTP 500 Internal Server Error en vez de un 200 OK que se
devuelve cuando todo ha ido bien.
3.4 UDDI
UDDI (Universal Description, Discovery and Integration), es un protocolo (no un estándar)

disponible en Internet y patrocinado por OASIS para el registro de servicios web.
Permite que proveedores de Servicios Web publiquen sus servicios y potenciales consumidores
de dichos servicios los descubran y los utilicen.
El registro de los servicios así como el descubrimiento de los mismos se realiza mediante el
intercambio de mensajes SOAP (el protocolo UDDI define precisamente el formato de dichos
mensajes). Cuando se descubre un servicio, lo que se recibe es un archivo WSDL con toda la
información necesaria para su consumo.
UDDI tiene tres componentes diferentes:
● Páginas blancas: Entidades que han publicados servicios, con sus datos identificativos y
de contacto.
● Páginas amarillas: Relación y descripción de los servicios, así como clasificación de los
mismos según una serie de taxonomías. Para una misma entrada en las páginas blancas
(entidad de negocio que publica servicios), habrá varias entradas en las páginas
amarillas (una por cada servicio que proporciona)
● Páginas verdes: Descripción técnica de los servicios y acceso a los mismos. Dado que un
mismo servicio puede constar de diversas operaciones, para una misma entrada en las
páginas amarillas (servicio) puede haber múltiples entradas en las páginas verdes (una
por cada operación)
Hay diversas empresas que ofrecen servicios de registro UDDI: IBM, SAP, Microsoft.
15
www.cetic.es
3.5 WSDL
WSDL (Web Services Description Language) es un lenguaje XML que permite describir un
Servicio Web, es decir, contiene toda la información necesaria para su consumo.
Está estandarizado por el W3C, siendo la última versión la 2.0, de 2007 (notar que en la versión
1.1 de WSDL, la ‘D’ no era la inicial de Description, sino de Definition)
Un documento WSDL describe tres propiedades fundamentales de un servicio web:
● Las operaciones soportadas y qué mensajes las activan.

o El formato de los mensajes.
o Los tipos de datos especiales que se envíen se incluyen en el archivo WSDL en
forma de XML Schema.
● El protocolo de comunicación en el que se envía el mensaje.
● La forma en que cada operación se compone de mensajes formateados de una manera
específica y transmitidos por un protocolo concreto de red.
Un Servicio Web definido en un WSDL consta de:
● Descripción de la interfaz del servicio (descripción abstracta)

● Descripción de la implementación del servicio (descripción concreta)
3.5.1 WSDL: DESCRIPCIÓN DE LA INTERFAZ DEL SERVICIO
Consta a su vez de dos partes diferentes: tipos y operaciones/interfaces.
3.5.1.1 TIPOS
Aquí se define el conjunto de datos (y sus tipos) que será utilizado por el servicio web e
intercambiado dentro de los mensajes.
Esta información es compartida entre cliente y servidor para que puedan ser interpretados
correctamente a ambos lados.
● El servicio web necesita acceder a la información que el cliente ha usado para codificar
los datos y debe entender cómo decodificarlos.
● El cliente del servicio web debe saber cómo codificar los datos para que el servicio los
acepte.
Ejemplo:
16
www.cetic.es
<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.ejemplos.com/Servicio/">
<xsd:element name="tOperacion">
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs="0" name="n1" type="xsd:int" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xsd:element name="tOperacionResp">
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs="0" name="resultado" type="xsd:int" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xsd:schema>
</wsdl:types>
Se han definido dos tipos, uno de ellos, llamado tOperacion, consta a su vez de dos elementos
de tipo entero, n1 y n2. El segundo, llamado tOperacionResp tiene un solo elemento, llamado
resultado, también de tipo entero
3.5.1.2 OPERACIONES E INTERFACES

Las operaciones representan los distintos métodos a los que se puede invocar y agrupan los
mensajes de entrada y salida que se pueden intercambiar. Para cada método, recoge su nombre
y los parámetros de entrada y salida.
Las operaciones pueden ser de entrada (el servicio recibe un mensaje asíncrono), de salida (el
servicio envía un mensaje asíncrono), entrada-salida (el servicio recibe un mensaje y quién lo
envía permanece a la espera de respuesta) o salida-entrada (el servicio envía un mensaje y
queda esperando a recibir una respuesta)
Las interfaces agrupan las operaciones que realiza el servicio web. A continuación se puede ver
un ejemplo de una interfaz con una operación (la definida en el apartado anterior)
Ejemplo de una interfaz con una operación de entrada-salida:
<wsdl:interface name="calcularInterface">
<wsdl:operation name="sumar"
pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input messageLabel="Entrada" element="ns:tOperacion"/>
<wsdl:output messageLabel="Salida" element="ns:tOperacionResp"/>
</wsdl:operation>
</wsdl:interface>
17
www.cetic.es
En una operación de entrada sólo aparecerían mensajes de tipo input, en una de salida sólo de
tipo output y en una de salida-entrada aparecería en primer lugar el mensaje de tipo output y a
continuación el de tipo input.
3.5.2 WSDL: DESCRIPCIÓN DE LA IMPLEMENTACIÓN DEL SERVICIO
Consta a su vez de dos partes diferentes: bindings y servicios/endpoints
3.5.2.1 BINDINGS
Definen cómo debe accederse a las operaciones que proporciona el Servicio Web. En el ejemplo
siguiente, el binding se refiere a las operaciones recogidas en la interfaz calcularInterface
(segunda línea), la tercera línea (type) determina que la forma de invocar al servicio es SOAP y
la cuarta línea indica que el protocolo usado HTTP.
<wsdl:binding name="calcularBinding"
interface="ns:calcularInterface"
type="http://www.w3.org/ns/wsdl/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
<wsdl:operation ref="ns:sumar"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
</wsdl:binding>
3.5.2.2 SERVICIOS Y ENDPOINTS

Un endpoint determina la dirección del Servicio Web. El servicio vincula el endpoint con una
interfaz.
En el ejemplo siguiente se define un endpoint que indica la dirección (address) donde está la
interfaz indicada en la línea 2 y cuya forma de invocación define el binding indicado en la línea 4
<wsdl:service name="calcularService"
interface="ns:calcularInterface">
<wsdl:endpoint name="calcularEndpoint"
binding="ns:calcularBinding"
address="http://www.ejemplo.com/Servicio/sumar.php"/>
</wsdl:service>
3.5.3 WSDL: EL EJEMPLO COMPLETO
Uniendo todas las piezas de los apartados anteriores:

<wsdl:description xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
xmlns:ns="http://www.ejemplos.com/Servicio/"
targetNamespace="http://www.ejemplos.com/Servicio/"
18
www.cetic.es
<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.ejemplos.com/Servicio/">
<xsd:element name="tOperacion"> (punto 1)
<xsd:complexType>
<xsd:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xsd:element name="tOperacionResp"> (punto 2)
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs="0" name="res" type="xsd:int" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="calcularInterface">
<wsdl:operation name="sumar" (punto 3)
pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input messageLabel="Entrada" element="ns:tOperacion"/> (punto 4)
<wsdl:output messageLabel="Salida" element="ns:tOperacionResp"/> (pto.5)
</wsdl:operation>
</wsdl:interface>
<wsdl:binding name="calcularBinding"
interface="ns:calcularInterface" (punto 6)
type="http://www.w3.org/ns/wsdl/soap" (punto 7)
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"> (punto 8)
<wsdl:operation ref="ns:sumar"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
</wsdl:binding>
<wsdl:service name="calcularService" (punto 9)

interface="ns:calcularInterface"> (punto 10)
<wsdl:endpoint name="calcularEndpoint" (punto 11)
binding="ns:calcularBinding" (punto 12)
address="http://www.ejemplo.com/Servicio/sumar.php"/> (punto 13)
</wsdl:service>
</wsdl:description>
Este WSDL describiría un Servicio Web llamado calcularService (punto 9), definido por un
endpoint llamado calcularEndpoint (punto 11) accesible en la dirección indicada en el punto 13
y que implementa lo definido en la interfaz calcularInterface (punto 10)
19
www.cetic.es
El endpoint está enlazado al binding calcularBinding (punto 12), el cual se ha definido con un
protocolo de comunicación, SOAP (punto 7) sobre HTTP (punto 8)
El binding está enlazado con la interfaz calcularInterface (punto 6), la cual tiene definida una
operación llamada sumar (punto 3), que requiere de un elemento de entrada de tipo
tOperacion (punto 4) y uno de salida tipo tOperacionResp (punto 5)
Por último, los dos tipos, tOperacion y tOperacionResp, se definen en la sección type (puntos 1 y
2 respectivamente)
3.5.4 WSDL 2.0 Y WSDL 1.1
Hay algunas diferencias significativas en la estructura de un fichero WSDL entre la versión 1.1 y
la 2.0, que se detallan en el cuadro siguiente:
A modo de resumen:
● WSDL 2.0 integra el elemento Message dentro del elemento Types.

● WSDL 2.0 renombra el elemento PortType como Interface.
● WSDL 2.0 renombra el elemento Port a Endpoint.
● WSDL 2.0 renombra la parte inicial de declaración en la interface conocida como
Definitions como Description.
20
www.cetic.es
3.6 SEGURIDAD EN SERVICIOS WEB
3.6.1 ASPECTOS A CONSIDERAR EN RELACIÓN A LA SEGURIDAD
● Asegurar una autenticación mutua entre el cliente que accede a los servicios web y el
proveedor de dichos servicios.
● Mantener una política de autorización del acceso a recursos y, más importante, a
operaciones y procesos en un entorno en el que debe administrarse y controlarse el
acceso de numerosos actores.
● Mantener al cliente identificado, de manera que pueda acceder a servicios en diversos
sistemas, sin que resulte necesario identificarse nuevamente en cada uno de ellos.
● Controlar y asegurar la confidencialidad de los datos intercambiados, ya que SOAP no es
capaz de cifrar la información, la cual viaja en claro a través de la red. Es necesario
asegurar la comunicación con algún estándar que permita crear un canal seguro de
comunicación.
● Asegurar la integridad de los datos, de manera que estén protegidos frente a ataques o
manipulaciones fortuitas.
● Comprobar que no se repudian las operaciones, para lo cual es necesario mantener
firmas en XML.
3.6.2 WS-SECURITY
La especificación WS-Security, estandarizada por OASIS, permite implementar mecanismos de

seguridad en Servicios Web a nivel de mensajes, en lugar de implementar la seguridad en el
protocolo de transferencia o en el de la conexión.
Para ello, describe la forma de firmar y encriptar mensajes de tipo SOAP.
Se basa en estándares y certificaciones digitales para dotar a los mensajes SOAP de los criterios
de seguridad necesarios. Se definen cabeceras y usa XML Signature para el manejo de firmas en
el mensaje. La encriptación de la información la realiza mediante XML Encryption. Hace uso así
mismo del intercambio de credenciales de los clientes.
WS-Addressing, desempeña un papel fundamental en la seguridad a nivel de mensajes puesto

que proporciona los mecanismos para enviarlos de un modo independiente del transporte. Esto
permite enviar un mensaje seguro a través de cualquier transporte y enrutarlo con facilidad. La
protección del mensaje en lugar del uso del protocolo de transporte ofrece varias ventajas:
21
www.cetic.es
● Resulta más flexible puesto que se pueden firmar o cifrar partes del mensaje en lugar del
mensaje completo. De este modo, los intermediarios pueden ver las partes del mensaje
destinadas a ellos.
● Los intermediarios pueden agregar sus propios encabezados al mensaje y firmarlos para
llevar a cabo el registro de auditorías.
● El mensaje protegido se puede enviar a través de diferentes protocolos, como SMTP,
FTP y TCP, sin necesidad de basarse en el protocolo para la seguridad.
3.6.3 MECANISMOS DE SEGURIDAD
Se listan a continuación diferentes mecanismos de seguridad recomendados para su uso con

Servicios Web en los diferentes elementos de seguridad a contemplar:
● Autenticación de servicios: WS-Security y Tokens (por ejemplo, con WS-Trust)

● Autenticación de usuarios: SAML (Security Authorization Markup Language)
● Integridad: SSL y WS-Signature
● No repudio: WS-Signature, WS-Adressing
● Confidencialidad: SSL y WS-Encryption
● Política de seguridad: WS-Policy
4. REST (REPRESENTATIONAL STATE TRANSFER)
REST es una alternativa a la arquitectura de servicios web implementada con SOAP.
SOAP es un protocolo extraordinariamente complejo pensado para dar soluciones a casi

cualquier necesidad en lo que a comunicaciones se refiere, incluyendo aspectos avanzados de
seguridad, transaccionalidad, mensajería segura, etc.
Aunque las primeras implementaciones no soportaban casi ningún escenario avanzado, se

generalizó el uso de SOAP, ya que parecía que era el estándar que dominaría el futuro.
Con el tiempo salieron las especificaciones WS-* que daban soluciones avanzadas, pero a la vez
que crecían las capacidades de SOAP, crecía su complejidad.
Al final, muchas de esas capacidades de los Servicios Web SOAP con esa complejidad intrínseca,
en la mayoría de los casos no se necesitan.
Por su parte REST es simple, puesto que no pretende dar soluciones para todo y por lo tanto, no
está penalizado por una excesiva complejidad. De manera que en todas esas ocasiones en que
22
www.cetic.es
no son necesarias funcionalidades avanzadas, se opta por el uso de REST frente a SOAP debido
a su mayor sencillez.
Una diferencia fundamental entre un Servicio Web clásico (SOAP) y un servicio REST es que el
primero está orientado a RPC, es decir, a invocar métodos sobre un servicio remoto, mientras
que el segundo está orientado a recursos.
En una API REST la idea de “servicio” como tal desaparece. Se tienen recursos, accesibles
mediante identificadores (URIs), sobre los que se pueden realizar acciones, generalmente
diferenciadas a través de distintos verbos HTTP.
Así, en un Servicio Web clásico (SOAP) que gestione, por ejemplo, una “Colección de productos”
se tendría un servicio llamado ProductService que tendría un método llamado GetAll() que
devolvería todos los productos. La idea, independientemente de la tecnología usada para
consumir el Servicio Web, es que se llama a un método (GetAll) de un servicio remoto
(ProductService). Así, para obtener un producto concreto se llamaría al método GetById()
pasándole el id del producto.
Por su parte en un servicio REST prevalece la idea de recurso. En el escenario, “Colección de

productos” se tiene una URI que lo identifica, por ejemplo /Products. Así, si se invoca dicha URI,
se obtiene una representación de dicho recurso, es decir, el listado de todos los productos.
Un producto forma parte de la “Colección de productos” así que a partir de la colección entera
(/Products) se puede acceder a uno de sus elementos con una URI tipo /Products/123, siendo
123 el ID del producto.
En un servicio SOAP, para dar de alta un nuevo producto se llamaría a un método AddProduct()
de ProductService, y se le pasarían los datos del producto a añadir. En cambio, en la API REST
añadir un producto consiste en usar la URI del mismo, (por ejemplo /Products/456 si se está
añadiendo el producto con ID 456) usando POST o PUT como verbo HTTP y colocando los datos
del producto en el cuerpo de la petición. La URI para acceder al producto con ID 456 es siempre
/Products/456 y es el verbo HTTP (GET, POST, PUT, DELETE,...) el que indica cual es la operación
que deseamos hacer con ese producto.
4.1 MÉTODOS HTTP EN REST
En una API REST se usan los métodos del protocolo HTTP (infrautilizados en los Servicios Web
clásicos) para indicar el tipo de operación que a realizar sobre los recursos que ofrecen los
servicios.
Estos métodos, conocidos como verbos HTTP son los siguientes:
23
www.cetic.es
● GET: Para operaciones de consulta de datos. Puedes consultar un listado de productos o

un producto determinado. Ambas operaciones serían GET, solo que la consulta al listado
se realizaría sobre el recurso /Products y la consulta a un producto particular sobre el
recurso /Products/33, por ejemplo.
● POST: Operaciones de inserción.
● PUT: Para realizar modificaciones.
● PATCH: Para realizar modificaciones parciales en un recurso.
● DELETE: Para eliminar un recurso dado.
De este modo, una misma URL, o endpoint, como /Product/77 puede servir para realizar
múltiples operaciones, todo depende del método de la solicitud HTTP que se utilice.
4.2 JSON (JAVASCRIPT OBJECT NOTATION)
Del mismo modo que REST es una alternativa más sencilla a SOAP que en muchos escenarios
permite cubrir la misma funcionalidad, JSON es un formato de intercambio de información más
sencillo que XML, y que también es suficiente en un número elevado de escenarios. De ahí que
REST y JSON se usen muchas veces juntos.
JSON un subconjunto de la notación de objetos de Javascript, aunque dado su amplísimo uso,

desde 2019 está considerado como un lenguaje con entidad propia.
La principal ventaja de JSON respecto de XML es que dada la sencillez de su formato, el parseo
de una cadena JSON es muy sencillo, hasta el punto de que basta con emplear la función eval()
de Javascript para hacerlo (y dada la disponibilidad de Javascript es casi todos los navegadores
web, no es necesario programar ni instalar componentes adicionales). En cualquier caso, todos
los lenguajes de programación modernos disponen de APIs para su tratamiento.
4.2.1 TIPOS DE DATOS EN JSON
● Números: Se permiten números negativos y opcionalmente pueden contener parte

fraccional separada por puntos. Ejemplo: 123.456
● Cadenas: Representan secuencias de cero o más caracteres. Se ponen entre dobles
comillas y se permiten cadenas de escape. Ejemplo: "Martillo"
● Booleanos: Representan valores booleanos y pueden tener dos valores: true y false
● null: Representan el valor nulo.
● Array: Representa una lista ordenada de cero o más valores los cuales pueden ser de
cualquier tipo. Los valores se separan por comas y el array se mete entre corchetes.
Ejemplo ["juan","juana","luis",”luisa”]
24
www.cetic.es
● Objetos: Son colecciones no ordenadas de pares de la forma <nombre>:<valor>

separados por comas y puestos entre llaves. El nombre tiene que ser una cadena entre
comillas dobles. El valor puede ser de cualquier tipo. Ejemplo:
{
"producto":123,
"descProducto":"Martillo",
"seccion": "Ferretería",
"stockportienda":[
{
"tienda":"Tienda_1",
"stock":300
},{
"tienda":"Tienda_2",
"stock":125
}
]
}
25
www.cetic.es
5. ANEXO I PREGUNTAS APARECIDAS EN LOS ÚLTIMOS EXÁMENES DE ACCESO AL

CUERPO GSI
Proceso Selectivo 2016. Acceso Libre (3 preguntas)

Pregunta 32: Entre los objetivos principales de las arquitecturas de servicios web se
encuentra: (apartado 3.2)
a) Proporcionar interoperabilidad entre aplicaciones desarrolladas en diferentes
entornos tecnológicos.
b) Garantizar la persistencia de datos en entornos de alta disponibilidad.
c) Simplificar el balanceo de carga en infraestructuras web basadas en granjas de
servidores.
d) Aprovechar las ventajas de los servidores dispuestos en cluster.
Pregunta 33: En una arquitectura cliente-servidor, las capas del modelo de tres capas se
denominan: (apartado 2.1)
a) Presentación, transformación y almacenamiento.
b) Vista, control y almacenamiento.
c) Frontend, transformación, backend.
d) Presentación, lógica de negocio, datos.
Pregunta 34: Un mensaje SOAP consta de un elemento: (apartado 3.3.1)
a) <Envelope> obligatorio, que contiene un elemento <Header> obligatorio y un
elemento <Body> obligatorio.
b) <Envelope> obligatorio, que contiene un elemento <Header> opcional y un elemento
<Body> obligatorio.
c) <Envelope> obligatorio, que contiene un elemento <Header> obligatorio y un
elemento <Body> opcional.
d) <Envelope> opcional, que contiene un elemento <Header> opcional y un elemento
<Body> obligatorio
Proceso Selectivo 2019. Acceso Libre (1 pregunta)
Pregunta 26: Los servicios web que utilizan estándares tales como URIs, HTTP y JSON son
aquellos basados en: (apartados 4 y 4.2)
a) SOAP
b) REST
c) API’s
d) HTML
26
www.cetic.es
6. ANEXO II PREGUNTAS APARECIDAS EN LOS ÚLTIMOS EXÁMENES DE ACCESO AL

CUERPO TAI
Proceso Selectivo 2015. Turno libre (6 preguntas)

Pregunta 3.38: ¿Cuál de los siguientes es un estándar que se utiliza como elemento de
seguridad en los servicios web? (apartado 3.6.3)
a) SAML
b) WSDL
c) SOAP
d) UDDI
Pregunta 3.39: ¿Cuál de las siguientes opciones NO es una ventaja propia de una
arquitectura de tres capas? (apartado 2.5)
a) Reduce el tráfico en la red frente a una arquitectura de dos capas
b) Es una arquitectura mucho más escalable
c) La separación de roles en capas hace mucho más fácil modificar y reemplazar capas
d) Si aumenta el tamaño o complejidad de una capa, no afecta a las demás
Pregunta 3.40: Axis2 es: (apartado 3.2)
a) Una base de datos NoSQL
b) Un motor de búsqueda
c) Un motor nuclear de servicios web
d) Una librería para la automatización de tareas de compilación y despliegue de
aplicaciones
Pregunta 3.41: ¿A qué hace referencia el modelo de 3 capas en el desarrollo de
aplicaciones?: (apartado 2.2)
a) A que la declaración de clases se realizará con al menos tres niveles de acceso
diferenciados: clases públicas, clases privadas y clases protegidas
b) A que se establecerán tres jerarquías de herencia de clases, en el que partiendo de
una clase raíz, existirán al menos hasta otras dos capas de herencia
c) A que las aplicaciones se separarán en tres capas, estableciendo una capa de Lógica
de Presentación, una capa de Lógica de Negocio y una capa de Datos o de
Persistencia
d) a que el procesamiento de documentos XML puede realizarse mediante un parser
DOM (modelo de árbol), SAX (basado en eventos tipo push) o STAX (basado en
eventos de tipo pull)
Pregunta 3.42: El protocolo SOAP (Simple Object Access Protocol): (apartado 3.3)
a) Es una recomendación del W3C
27
www.cetic.es
b) Es un estándar ISO
c) Es una norma UNE
d) Es un estándar ANSI
Pregunta 3.43: Para la implementación de una arquitectura cliente/servidor de tipo "cliente
fino-servidor grueso": (apartado 2.2)
a) Se necesitan un mínimo de dos equipos si se utiliza el modelo de dos capas
b) Se necesitan un mínimo de tres equipos si se utiliza el modelo de tres capas
c) Puede ser implantada en un único equipo
d) El cliente es el responsable del acceso a los datos físicos y de procesar la lógica de
negocio
Proceso Selectivo 2015. Promoción interna (2 preguntas)
Pregunta 3.20: Axis2 es: (apartado 3.2)
a) Una base de datos NoSQL
b) Un motor de búsqueda
c) Un motor nuclear de servicios web
d) Una librería para la automatización de tareas de compilación y despliegue de
aplicaciones
Pregunta 3.21: ¿Cuál de las siguientes NO es una característica propia de las arquitecturas
cliente/servidor? (apartado 2.1)
a) Encapsulamiento de servicios
b) Escalabilidad horizontal y vertical
c) Acoplamiento de sistemas
d) Interoperabilidad de plataformas
Proceso Selectivo 2016. Turno libre (2 preguntas)
Pregunta 3.32: ¿A cuál de los siguientes elementos de la arquitectura cliente-servidor se le
conoce también con el término front-end? (apartado 2)
a) Base de datos
b) Servidor
c) Cliente
d) Al conjunto de la arquitectura
Pregunta 3.33: Señale la respuesta correcta en relación con los servicios web (apartado 3.1)
a) Las arquitecturas orientadas a servicios (SOA) se implementan con HTML5, CSS3 y
Javascript
b) Las arquitecturas SOA están formadas por servicios de aplicación fuertemente
acoplados y altamente interoperables
c) Las arquitecturas SOA son un modelo orientado a la reutilización de los servicios en
entornos de sistemas distribuidos
28
www.cetic.es
d) Los servicios de una arquitectura SOA se basan en una definición formal

independiente de la plataforma subyacente. Esta definición formal se realiza en el
lenguaje Java
Proceso Selectivo 2017. Turno libre (1 pregunta)
Pregunta 60: En el documento WSDL 2.0 el elemento <binding> especifica: (apartado
3.5.2.1)
a) el conjunto de puertos y dirección de los mismos
b) los protocolos de comunicación usados
c) los tipos de datos usados en los mensajes
d) las operaciones permitidas
Proceso Selectivo 2017. Promoción interna (1 pregunta)
Pregunta 28: ¿Cuál de las siguientes características hace referencia a la posibilidad de
aumento de la capacidad de cálculo de los servidores en una implantación cliente/servidor?
(apartado 2.1)
a) Encapsulamiento
b) Escalabilidad horizontal
c) Acoplamiento débil
d) Escalabilidad vertical
Proceso Selectivo 2018. Turno libre (1 pregunta)
Pregunta 32: Con respecto a JSON, señale la correcta: (apartado 4.2)
a) Es un tipo de gramática XML
b) Es un API de JAVA
c) Es un conjunto de librerías de Javascript
d) Es un formato de intercambio de datos
Pregunta 31: De la pila de especificaciones de los servicios web, indique cuál de los
siguientes lenguajes se utiliza para la descripción de los mismos (apartado 3.5)
a) WSIJ
b) WSDL
c) SOAP
d) UDDI
Pregunta 30: ¿Cuál de los siguientes protocolos está asociado al descubrimiento de servicios
web? (apartado 3.4)
a) LLDP (Link Layer Discover Protocol)
29
www.cetic.es
b) UDDI (Universal Description Discovery and Integration)

c) WSDP (Web Service Discovery Protocol)
d) SSDP (Simple Service Discovery Protocol)
30
www.cetic.es
7. ANEXO III RESPUESTAS CORRECTAS
Respuestas correctas GSI:

A–D–B–B
Respuestas correctas TAI:
A–A–C–C–A
C–C–C–C–C
B–D–D–B–B
31
www.cetic.es
8. GLOSARIO
API Application Program Interface (Interfaz de programación de aplicaciones)

FTP File Transfer Protocol (Protocolo de Transferencia de Ficheros)
HTTP HyperText Transfer Protocol (Protocolo de Transferencia de HiperTexto)
JSON JavaScript Object Notation (Notación para objetos de Javascript)
Organization for the Advancement of Structured Information Standards (Organización para el
OASIS
Avance de Estándares de Información Estructurada)
ODBC Open Database Connectivity (Conectividad Abierta para Base de Datos)
P2P Peer To Peer (Red entre Pares)
REST REpresentational State Transfer (Transferencia de Estado Representacional)
RPC Remote Procedure Call (Llamada a Procedimiento Remoto)
SAML Security Assertion Markup Language (Lenguaje de Marcado para Confirmaciones de Seguridad)
SMTP Simple Mail Transfer Protocol (Protocolo para Transferencia Simple de Correo)
SOA Service Oriented Architecture (Arquitectura Orientada a Servicios)
SOAP Simple Object Access Protocol (Protocolo de Acceso a Objetos Simples)
SSL Security Sockets Layer (Capa de Puertos Seguros)
TCP Transmission Control Protocol (Protocolo de Control de Transmisión)
Universal Description, Discovery and Integration (Descripción, Descubrimiento e Integración
UDDI
Universal)
URI Uniform Resource Identifier (Identificador de Recursos Uniforme)
W3C World Wide Web Consortium (nombre comercial)
WSDL Web Services Description Language (Lenguaje de Descripción de Servicios Web)
XML eXtensible Markup Language (Lenguaje de Marcado Extensible)
32
www.cetic.es
9. CONCLUSIÓN
A lo largo del tema se han visto los conceptos más importantes relacionados con la arquitectura
cliente/servidor y la arquitectura de Servicios Web.
La primera parte del tema, arquitectura cliente/servidor, se ha centrado en comentar sus
características básicas, los conceptos de niveles y capas (y las funciones asociadas a cada una de
ellas), los componentes de la arquitectura y las ventajas y desventajas de trabajar con la misma.
Después se ha entrado en detalle a hablar de la arquitectura de Servicios Web, dentro del
contexto de las arquitecturas orientadas a servicios (SOA) y se han comentado los aspectos más
destacados de la misma: SOAP, UDDI, WSDL, aspectos relaticos a seguridad.
Por último se habla de REST, como alternativa al uso de servicios web para escenarios más
sencillos y de JSON como formato de intercambio de datos.
Los anexos incluyen las preguntas aparecidas en los exámenes de los procesos selectivos de
acceso a los cuerpos GSI y TAI de la AGE desde 2015 hasta el día de hoy (este tema no aparece
en el temario del cuerpo TIC), así como un glosario de las siglas aparecidas a lo largo del tema.
Como se podrá observar, las preguntas relacionadas con este tema son bastante más numerosas
en el proceso selectivo del cuerpo TAI que en el GSI, pero realizar las preguntas de test del
proceso TAI que aparecen en este tema puede ser una muy buena forma de prepararlo y de
testear el grado de dominio de los conceptos que se manejan en él.
33

Tema 36 Soa Cetic

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 36 Soa Cetic

Cargado por

Copyright:

Formatos disponibles

Centro de Estudios TIC

TEMA II.07 ARQUITECTURA DE SISTEMAS CLIENTE-SERVIDOR Y

3.6 SEGURIDAD EN SERVICIOS WEB 19

En este tema se presentan los conceptos fundamentales sobre arquitectura cliente/servidor y

2. CONCEPTOS GENERALES DE LA ARQUITECTURA CLIENTE/SERVIDOR

El concepto de cliente/servidor se refiere a una arquitectura en la que cada ordenador o

2.1 PRINCIPALES CARACTERÍSTICAS

2.2 SEPARACIÓN DE FUNCIONES EN CAPAS

La arquitectura cliente/servidor permite la separación de funciones en tres capas:

Ilustración 1: Arquitectura de tres capas

Los componentes de una arquitectura cliente/servidor son:

2.4 VENTAJAS DE LA ARQUITECTURA CLIENTE/SERVIDOR

● Facilita la interacción entre sistemas heterogéneos: clientes y servidores pueden estar

2.5 DESVENTAJAS DE LA ARQUITECTURA CLIENTE/SERVIDOR

● Unido al aumento de niveles en la arquitectura siempre va un aumento del tráfico de

3. ARQUITECTURA DE SERVICIOS WEB

3.1 ARQUITECTURAS ORIENTADAS A SERVICIOS (SOA)

3.2 SERVICIOS WEB

En la implementación de Servicios Web hay implicados una serie de estándares:

Estándar Organismo URL

Y el esquema básico de la implementación y uso de un servicio web sería:

Ilustración 2: Esquema básico de la implementación y consumo de un servicio web

● Quién implementa el servicio (proveedor) genera el WSDL describiendo el Servicio Web

SOAP surge con intención de alcanzar dos objetivos:

● Definir un protocolo de invocación a servicios remotos basado en estándares de uso

3.3.1 PARTES DE UN MENSAJE SOAP

● SOAP Envelope, obligatorio

Cada uno de estos elementos contiene lo siguiente:

Un ejemplo de respuesta (correcta) a este mensaje:

Un ejemplo de respuesta (con error) a este mensaje:

3.3.2 TIPOS DE DATOS EN SOAP Y SERIALIZACIÓN

Es posible restringir el número y tipo de los elementos almacenados en un array:

3.3.3 SOAP Y HTTP

UDDI (Universal Description, Discovery and Integration), es un protocolo (no un estándar)

UDDI tiene tres componentes diferentes:

Un documento WSDL describe tres propiedades fundamentales de un servicio web:

● Las operaciones soportadas y qué mensajes las activan.

Un Servicio Web definido en un WSDL consta de:

● Descripción de la interfaz del servicio (descripción abstracta)

3.5.1 WSDL: DESCRIPCIÓN DE LA INTERFAZ DEL SERVICIO

Consta a su vez de dos partes diferentes: tipos y operaciones/interfaces.

3.5.1.2 OPERACIONES E INTERFACES

3.5.2 WSDL: DESCRIPCIÓN DE LA IMPLEMENTACIÓN DEL SERVICIO

Consta a su vez de dos partes diferentes: bindings y servicios/endpoints

3.5.2.2 SERVICIOS Y ENDPOINTS

3.5.3 WSDL: EL EJEMPLO COMPLETO

Uniendo todas las piezas de los apartados anteriores:

<wsdl:service name="calcularService" (punto 9)

3.5.4 WSDL 2.0 Y WSDL 1.1

● WSDL 2.0 integra el elemento Message dentro del elemento Types.

3.6 SEGURIDAD EN SERVICIOS WEB

3.6.1 ASPECTOS A CONSIDERAR EN RELACIÓN A LA SEGURIDAD

La especificación WS-Security, estandarizada por OASIS, permite implementar mecanismos de

Para ello, describe la forma de firmar y encriptar mensajes de tipo SOAP.

WS-Addressing, desempeña un papel fundamental en la seguridad a nivel de mensajes puesto

3.6.3 MECANISMOS DE SEGURIDAD

Se listan a continuación diferentes mecanismos de seguridad recomendados para su uso con

● Autenticación de servicios: WS-Security y Tokens (por ejemplo, con WS-Trust)

4. REST (REPRESENTATIONAL STATE TRANSFER)

REST es una alternativa a la arquitectura de servicios web implementada con SOAP.

SOAP es un protocolo extraordinariamente complejo pensado para dar soluciones a casi

Aunque las primeras implementaciones no soportaban casi ningún escenario avanzado, se

Por su parte en un servicio REST prevalece la idea de recurso. En el escenario, “Colección de