PDF M8 Java

Módulo 8
Diseñando Servicios
web Java
Profesional en
Plataforma
JAVA
www.learning.es
Para uso exclusivo de los alumnos de LEARNING & TRAINING CLOUD, S.L.
Contenido
Introducción y Objetivos ........................................................................................................ 1
Unidad 1. Analizando Oportunidades con los Servicios Web ........................................................ 2
Estándares Principales de Web Services ................................................................................ 5
Arquitectura orientada a servicios......................................................................................... 6
Desarrollo de servicios web con tecnología java ..................................................................... 8
API Java para Servicios Web XML (JAX-WS) ......................................................................... 13
Laboratorio: Analizando ServiciosWeb ................................................................................. 17
Unidad 2. Diseñando Buenas Prácticas y Patrones para los Servicios Web ................................... 19
Componentes fundamentales ............................................................................................. 21
Tipos de patrones ............................................................................................................. 22
Patrones de diseño basados en servicios web ....................................................................... 26
Buenas prácticas para desarrollar servicios web SOAP ........................................................... 28
Usa http://localhost:puerto como dirección url del endpoint................................................... 28
Laboratorio: Buenas prácticas para desarrollar servicios web SOAP. ....................................... 31
Unidad 3. Manejando Excepciones en los Servicios Web ........................................................... 33
Tipos de excepciones con servicios web............................................................................... 33
Excepciones predefinidas en servicios web ........................................................................... 42
Excepciones personalizadas en Servicios Web ...................................................................... 44
Laboratorio: Excepciones WebServices ................................................................................ 45
Unidad 4. Seguridad en los Servicios Web .............................................................................. 50
WS-Security .................................................................................................................... 50
WS-SecurityPolicy ............................................................................................................ 51
WS-TRUST ...................................................................................................................... 52
Web Services Trust Model.................................................................................................. 52
Relaciones de confianza .................................................................................................... 53
Técnicas criptográficas y las firmas digitales ........................................................................ 54
Listas de Anulación de Certificados X.509 ............................................................................ 57
Infraestructuras de Clave Pública ....................................................................................... 58
Implementar la seguridad en los servicios web ..................................................................... 58
Laboratorio: Seguridad Servicios ........................................................................................ 69
www.learning.es
Introducción y Objetivos
Introducción
Este módulo ofrece al estudiante los conocimientos para analizar y reconocer las ventajas de los
servicios web como implementación de una arquitectura orientada a servicios. Se utilizarán los
patrones de diseño para desarrollar servicios web y se examinan varios aspectos de los servicios
web, tales como el manejo de excepciones y la seguridad proporcionada por la plataforma Java.
Objetivo
Describir las tecnologías utilizadas para el desarrollo de servicios web.
www.learning.es
Unidad 1. Analizando Oportunidades con los
Servicios Web
Objetivos
 Describir la arquitectura orientada a servicios.
2
 Entender los servicios web como una implementación de SOA.
Introducción
El término servicios Web designa una tecnología que permite que las aplicaciones se comuniquen en
una forma que no depende de la plataforma ni del lenguaje de programación. Un servicio Web es
una interfaz de software que describe un conjunto de operaciones a las cuales se puede acceder por
la red a través de mensajería XML estandarizada. Usa protocolos basados en el lenguaje XML con el
objetivo de describir una operación para ejecutar o datos para intercambiar con otro servicio Web.
Un grupo de servicios Web que interactúa de esa forma define la aplicación de un servicio Web
específico en una arquitectura orientada a servicios (SOA).
La arquitectura en capas se complementa entonces con la arquitectura orientada a servicios (SOA),
ya que se hace necesaria una forma de comunicación eficiente y escalable, independientemente del
lenguaje de programación y plataforma de cada una de las aplicaciones. Es necesario entonces
desarrollar los servicios que se presentan y son utilizados. Un servicio es una función que acepta
una llamada y devuelve una respuesta mediante una interfaz bien definida. La manera en la que un
servicio procesa internamente la llamada para producir la respuesta es independiente de la
definición del servicio.
La arquitectura orientada a servicios proporciona, además, la posibilidad de orquestación de los
servicios, esto es, secuenciación, orden y control de los servicios, añadiendo la lógica de datos
necesaria para el proceso.
Los elementos básicos que conforman SOA son:
 Proveedores de servicios
 Consumidores de servicios
 Bus de Servicios Empresariales.
En la siguiente unidad estudiaremos la arquitectura en servicios, servicios web implementando SOA
y el análisis de casos típicos de SOA.
Algunas implementaciones SOAP también usan WSDL durante la ejecución para soportar
comunicaciones dinámicas.
Tipos de comunicación entre aplicaciones en Web Services:
 Protocolo de Transporte:
o HTTP/HTTPS
 Codificación de datos
o Protocolo SOAP (Simple Object Access Protocol) y Esquema XML (DTD/XSD)
 Descripción de interfaces o puntos de acceso a aplicación
o WSDL (Web Services Description Language)
 Descripción de servicio y descubrimiento
o UDDI (Universal Description, Discovery and Integration)
 Seguridad
www.learning.es
o WS-Security, XML Signature y XML Encription (Especificaciones JSR)
Las APIs de Java para los Web Services son las siguientes:
 JDOM
 JAXP: Java API for XML processing
 JAXB: Java API for XML binding
 JAX-RPC: Java API for RPC
 JAXR: Java API for UDDI registry
 SAAJ: SOAP API with Attachements
 JAX-WS: Java API for WebServices
o API de más alto nivel
o Usa todas las demás por debajo
o Permite manejo de WS sin conocimientos de XML, SOAP, etc
Servicios JAX-RS
API de Java que define una infraestructura (clases e interfaces) para implementar una arquitectura
REST (paquete javax.ws.rs).
Vamos a visualizar primer que es una arquitectura REST:
REST (Representational State Transfer): Se define como un "estilo arquitectónico" para el desarrollo
de aplicaciones distribuidas.
Características de REST:
 Forma de construir aplicaciones distribuidas.
 Centrada en el concepto de RECURSO
 Mecanismos RPC centrados en concepto de operación
 El estado de los recursos reside en el servidor
 Los clientes acceden al estado de recurso mediante REPRESENTACIONES del mismo
transferidas desde el servidor o desde el cliente empleando el protocolo HTTP como
mecanismo de transporte (podrían emplearse otros, REST no es específico de un protocolo)
 Cada aplicación puede utilizar diferentes formatos para la representación de los recursos
o HTML para navegadores web
o XML, JSON para aplicaciones
o Con el parámetro Content-Type de las cabeceras HTTP se especifica el tipo MIME de
los datos intercambiados (text/html, application/xml, application/json)
o El cliente puede informar al servidor del tipo de representación que necesita
(parámetro Accept en cabecera de las peticiones HTTP)
www.learning.es
 Los recursos son identificados y están accesibles mediante uno o varios URI (Uniform
Resource Identifier).
 Incluye un conjunto de anotaciones para especificar el mapeo entre las URIs de los recursos
y los métodos HTTP con los métodos Java de una clase de implementación (endpoint)
 Gestiona automáticamente las representaciones de los recursos intercambiados.
 Emplea JAXB para el tipo MIME application/xml
4
 Emplea la librería BadgerFish para mapeo de XML a JSON en el caso del tipo MIME
application/json
 La generación y tratamiento de otros tipos de representaciones debe manejarse
manualmente (imágenes, PDF…) implementando las interfaces
javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter en una clase
anotada con @jax.ws.rs.ext.Provider.
ANOTACIONES JAX-RS
@Path
La clase de implementación de los recursos REST (resource class) debe señalarse con una anotación
@Path, especificando el path de alto nivel dentro del que se enmarcan las URIs gestionadas por la
clase de implementación (context root).
Pueden anotarse clases Java "normales" o EJBs sin estado.

En el caso de anotar clases "normales" se deberá especificar en el web.xml de la aplicación web el
uso del Servlet de JAX-RS.
En los métodos de dicha clase se puede especificar el path (dentro del path de la clase de
implementación) al que se vinculan los métodos Java.
Podemos asociar nombres a los distintos fragmentos que componen el path, dichos nombres irán
señalados entre los signos {...}.
Podemos especificar los fragmentos del path empleando expresiones regulares.

Anotaciones de métodos http
Especifican el método HTTP al que se vinculan los métodos Java anotados para compatibilidad con
los servicios web JAX-RS.
@GET
Vincula al método anotado las peticiones HTTP GET dirigidas al path correspondiente a ese método.
@PUT
Vincula al método anotado las peticiones HTTP PUT dirigidas al path correspondiente a ese método.
@DELETE
Vincula al método anotado las peticiones HTTP DELETE dirigidas al path correspondiente a ese
método.
@POST
Vincula al método anotado las peticiones HTTP POST dirigidas al path correspondiente a ese método.
Existe otro tipo de servicios web en java que son JAVA-WS y que describiremos en módulos
posteriores.
www.learning.es
Estándares Principales de Web Services
Los estándares principales y tecnologías para construir y habilitar Web services son:
XML
Es el estándar de facto para estructurar datos, contenido y formatos para documentos electrónicos. 5
Es el lenguaje universal para intercambio de información entre aplicaciones, sistemas y dispositivos

sobre Internet.
SOAP
Es una especificación de un protocolo que define una forma uniforme de pasar datos codificados en
XML.
También define una forma de invocar procedimientos remotos (RPC: Remote Procedure Call) usando
a HTTP como el protocolo de comunicación.
SOAP parte de la premisa que no importa si el middleware es simple o complejo, todos requieren un
WAN wrapper (envoltorio).
El envío de mensajes como texto XML plano tiene ventajas en términos de que asegura la
interoperabilidad y en el middleware se acepta el costo del parsing y la serialización XML, para su
visibilidad en todas las redes.
Es un protocolo simple de mensajería XML sobre los protocolos HTTP, SMTP, FTP y otros de Internet.
Permite el intercambio de información entre dos o más pares y permite que se comuniquen en un
ambiente de aplicación
distribuida.
Es independiente del modelo de objetos de la aplicación, del lenguaje y de la plataforma o
dispositivo sobre el cual corre
Es un protocolo del W3C y de Sun Microsystems, IBM, HP, SAP, Oracle y Microsoft. Estas empresas
participan en el W3C XML protocol-working group. ebXML de UN/CEFACT usa SOAP.
Usa XML Infosets como formato para los mensajes y sus reglas de codificación para representar
datos y mensajes.
WSDL
Define a los servicios como colecciones de extremos de la red (network
endpoints) o puertos (ports).
Un documento WSDL usa los siguientes elementos en la definición de servicios:
Types – un contener de definiciones de tipos de datos usando algún tipo de sistema (tal como XSD).
Message – una definición abstracta con tipos de los datos que se transmiten.
Operation – una descripción abstracta de una acción soportada por el servicio
Port Type – un conjunto abstracto de operaciones soportadas por uno o mas endpoints.
Binding – un protocolo concreto y especificación de datos para un port type
en particular.
Port – un endpoint en particular, definido como una combinación de un
binding y una dirección de red
www.learning.es
Resumiendo, WSDL es una plantilla (template) de cómo se describen servicios y los usan los clientes
UDDI
Provee un mecanismo para que los clientes dinámicamente puedan encontrar otros web services.
Usando una interface UDDI, una aplicación comercial se puede conectar dinámicamente con los
servicios provistos por una aplicación comercial externa de otra empresa. 6
Un UDDI registry tiene dos tipos de clientes:

Aplicaciones comerciales que quieren publicar un servicio y sus interfaces de uso, y clientes que
quieren obtener servicios de un cierto tipo y vincularse
por medio de programas a ellos.
Es una capa superior sobre SOAP y asume que requerimientos y respuestas son objetos UDDI
enviados como mensajes SOAP.
No soporta descubrimiento con todas las opciones (por ejemplo búsquedas limitadas
geográficamente o vinculación y negociación de contratos tipo
eLance).
Se espera que UDDI sea la base para servicios de capas superiores soportadas por otros estándares.
El UDDI working group incluye a Sun Microsystems,IBM, HP, SAP, Oracle y Microsoft.
ebXML
Define un mercado electrónico global en el cual las empresas se encuentran unas a otras y realizan
operaciones comerciales y transacciones cooperativamente.
Define un conjunto de especificaciones para empresas para conducir negocios electrónicos sobre
Internet estableciendo un estándar común para especificar procesos de negocio, modelado de
información comercial, colaboración en procesos de negocio, perfiles de colaboración de socios,
acuerdos y mensajería.
Es una iniciativa de United Nations Center for Trade Facilitation and Electronic Business
(UN/CEFACT) y la Organization for the Advancement of Structured Information Standards (OASIS).
Otras organizaciones de estándares como Open Travel Alliance (OTA), Open Application Group, Inc.
(OAGI), Global Commerce Initiative (GCI), Health
Level 7 (HL7, una organización de estándares dedicados a la salud), y RosettaNet (un comité de
estándares XML ) lo han adoptado.
Framework de ebXML
• ebXML Business Process Service Specifications (BPSS).
• ebXML CPP/CPA.
• ebXML Messaging Service Handler (MSH)
• ebXML registry
• ebXML Core components
Arquitectura orientada a servicios

La Arquitectura Orientada a Servicios de cliente, es un concepto de arquitectura de software que
define la utilización de servicios para dar soporte a los requisitos del negocio.
www.learning.es
Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su
vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no
exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de
terceros.
SOA 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; 7
De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en

forma de servicios (generalmente como servicios web);
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 - Que define el proceso en términos del negocio y sus necesidades, y
que varía en función del negocio;
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.
Los puntos de entrada definidos por -- basados en experiencias reales de clientes -- pueden ayudar
su empresa a beneficiarse con la implementación de soluciones SOA predefinidas. Esos puntos de
entrada son impulsados por necesidades empresariales (puntos de entrada relacionados con
personas, procesos e información) y necesidades de TI (puntos de entrada relacionados con
conectividad y reutilización). He aquí algunas descripciones generales de los cinco puntos de
entrada:
 Personas: Este punto de entrada a SOA enfoca la experiencia del usuario para ayudar a
generar innovación y más colaboración, lo que posibilita la interacción consistente entre
personas y procesos y, consecuentemente, aumenta la productividad empresarial. Al usar
SOA se puede, por ejemplo, crear portlets basados en servicios para aumentar esa
colaboración.
 Procesos: El punto de entrada relacionado con procesos ayuda las compañías a saber qué
está sucediendo en los negocios, lo que les permite mejorar los modelos empresariales ya
existentes. Al usar SOA, puede transformar sus procesos empresariales en servicios
reutilizables y flexibles, lo que le permite mejorar y optimizar los nuevos procesos.
 Información: Al usar ese punto de entrada a SOA, puede sacar provecho a las informaciones
de su compañía en forma consistente y visible. Al facilitar informaciones consistentes y
confiables a todas las áreas de la empresa, habilita todas las áreas de la compañía a innovar
y, consecuentemente, puede competir con más eficiencia. Al usar SOA, se tiene un control
mejor sobre sus informaciones; al alinear las informaciones a sus procesos empresariales,
puede descubrir relaciones nuevas e interesantes.
www.learning.es
 Conectividad: Aproveche el punto de entrada relacionado con la conectividad para conectar
su infraestructura con eficiencia, integrando todas las personas, procesos e informaciones de
su compañía. Al tener conexiones flexibles de SOA entre los servicios y en todo el entorno,
puede tomar un proceso empresarial ya existente y ofrecerlo sin mucho esfuerzo a través de
otro canal empresarial. Puede incluso conectarse a socios externos fuera de su firewall en
una forma segura.
 Reutilización: La reutilización de servicios con SOA permite aprovechar servicios que ya
8
existen en la compañía. Al basarse en los recursos ya existentes, puede optimizar sus
procesos empresariales, asegurar la consistencia en toda la compañía y reducir el tiempo de
desarrollo. Todo ello ahorra tiempo y dinero. Usted también reduce la duplicación de
funcionalidades en sus servicios y tiene la oportunidad de aprovechar las aplicaciones
centrales comprobadas con las cuales el personal de su compañía está familiarizado.
Propiedades de SOA
Algunas de las más importantes propiedades de SOA son:

Orientación a la conversación. El foco de atención no está en los nodos sino en los mensajes
que se intercambian entre los mismos.
 Vista Lógica: El servicio es una abstracción (vista lógica) de los programas, bases de datos,
procesos de negocio, etc.
 Orientación a Mensajes: El servicio se define formalmente en términos de los mensajes que
se intercambian entre agentes proveedores y solicitantes. Esto posibilita que se incorpore un
componente “decorando” estos componentes con software de gestión y conversión.
 Abstracción del agente. La estructura interna del agente (lenguaje de programación, BD,
etc.) se abstrae en SOA, un nodo es una entidad computacional que participa en
conversaciones con otros nodos. No es necesario conocer las particularidades del lenguaje de
implementación. Esto evita problemas arquitectónicos derivados de la necesidad de conocer
determinados sistemas a nivel estructural.
 Metadatos. SOA se asocian con metadatos, los mismos son descripciones acerca de la forma
y tipo de los elementos que transportan los mensajes, el orden de los mensajes, el
significado de los mensajes, etc.
 Orientación a la Internet: Los servicios tienden a usarse a través de la red, aunque este no
es un requisito absoluto.
 Granularidad: Los servicios tienden a usar un pequeño número de operaciones con mensajes
complejos.
 Neutral a la Plataforma: Los mensajes se envían en un formato estándar y neutral a la
plataforma, utilizando XML.
 Un sistema distribuido es un conjunto de agentes software que colaboran entre si para
implementar una determinada funcionalidad. SOA es un tipo de sistema distribuido ya que los
agentes rara vez trabajan en el mismo entorno, necesitando alguna forma de comunicación
entre ellos. En SOA los agentes son servicios que realizan una operación determinada y que
puede ser invocado desde afuera del contexto de una gran aplicación.
Desarrollo de servicios web con tecnología java

Un servicio web ofrece una infraestructura independiente de lenguaje y plataforma para
comunicación. Un servicio web tiene las siguientes características:
www.learning.es
 Independiente de lenguaje y plataforma: Separación de la especificación y la
Implementación.
 Desacoplada: Basa en mensajes con interacción síncrona y asíncrona.
 Sobre una Internet: No existe control centralizado, se usan protocolos bien establecidos y
consideraciones de seguridad.
 Interoperable: Basado en estándares.
9
 Aplicación – Aplicación: Internet tradicional es Aplicación – Humano (SMTP, FTP, HTTP);
esquemas RPC (procedural), ORB y COM (objetos), MOM (mensajes – jms/mq) para
aplicación – aplicación dentro de una Internet sin considerar interoperar con otros sistemas.
Ejemplo de desarrollo web con tecnología java

En este ejemplo realizaremos un servicio web que devuelva un simple mensaje, el servicio web lo
consumiremos desde una aplicación java, y posteriormente se consumirá a través de una aplicación
web:
Crear un proyecto Web Services con un método que devuelva un String.
Realizar un proyecto cliente que consuma el servicio web.
1. Abrir un proyecto de tipo web y llamarlo WSNombre.
2. Elegir el servidor GlassFish para que posteriormente nos resulte más sencillo enlazarnos al
explorar sitios web.
3. Agregamos un archivo de tipo WebService, le damos un nombre y un paquete donde

guardarlo.
www.learning.es
10
4. En la pestaña diseño agregamos una nueva operación. Esta opción nos creará un método
público que ofreceremos a los clientes que quieran consumir el servicio.
5. Modificamos el código que nos genera para devolver un mensaje predeterminado.

@WebMethod(operationName = "Nombre")
public String Nombre() {
return "Hola Pepe";
}
Ejecutar el proyecto para que genere los archivos necesarios.
6. Creación de un cliente que consuma el servicio. Seleccionamos un proyecto de tipo java
application y le llamaremos ConsumirWSNombre.
www.learning.es
11
7. Agregamos un archivo de tipo Web Service Client.
8. Pulsamos sobre la opción examinar y elegimos el servicio web recién creado.
9. Pulsamos botón derecho en código sobre la clase que tiene el método main y seleccionamos
insert code y Call Web Service Operation. Por último, elegimos el método nombre.
www.learning.es
12
10. Nos generará el código necesario para invocar al método. Probarlo llamando desde el método
main.
public static void main(String[] args) {
System.out.println(nombre());
}
private static String nombre() {

consumirwsnombre.WebService1Service service = new
consumirwsnombre.WebService1Service();
consumirwsnombre.WebService1 port = service.getWebService1Port();
return port.nombre();
}
Consumir el servicio web desde un proyecto web
Crear un proyecto web y en la página jsp insertar el mismo código que nos generó en la aplicación
cliente.
<%@page contentType="text/html" pageEncoding="UTF-8"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</head>
www.learning.es
<body>
<% consumirwsnombre.WebService1Service service = new
consumirwsnombre.WebService1Service();
consumirwsnombre.WebService1 port = service.getWebService1Port();
%>
<%= port.nombre()%>
</body>
</html> 13
Resultado:
API Java para Servicios Web XML (JAX-WS)

La especificación JAX-WS proporciona soporte para servicios web que utiliza la API JAXB para
vincular datos XML en objetos Java. La especificación JAX-WS define APIs clientes para acceder a
servicios web así como técnicas para implementar puntos finales de servicios web. Los servicios web
para la especificación J2EE describen el despliegue de servicios basados en clientes JAX-WS. La
especificación EJB y servlet también describe aspectos de ese desarrollo. Esto debe posibilitar el
despliegue de aplicaciones basadas en JAX-WS utilizando cualquiera de estos modelos de
despliegue.
La especificación JAX-WS describe el soporte para los manejadores de mensajes que pueden
procesar mensajes de solicitud y respuesta. En general, estos manejadores de mensajes se ejecutan
en el mismo contenedor y con los mismo privilegios y contextos de ejecución que el JAX-WS cliente
o en el componente punto final con el que esta asociado. Estos manejadores de mensajes tienen
acceso al mismo espacio de nombres JNDI java:comp/env como su componente asociado.
Serializadores y deserializadores a la medida, si son soportados, son tratados de la misma forma
que los manejadores de mensaje.
Es la implementación por defecto que se incluye en Java SE 6
La gestión de los documentos XML incluidos en las peticiones y respuestas SOAP se delegan en
JAXB.
JAX-WS define su propio conjunto de anotaciones para definir las clases y métodos que actúan como
puntos finales de los mensajes que conforman las invocaciones SOAP para especificar la definición
del fichero WSDL y del binding SOAP.
La implementación del servicio web puede desplegarse empleando un Servlet como endpoint o un
EJB endpoint.
En contenedores que soporten Java EE 6 el despliegue es automático en ambos casos. Al iniciar la
aplicación el contenedor inspecciona las clases en busca de las anotaciones @WebService y
establece los mapeos de URL pertinentes.
En contenedores que no son Java EE 6, debe configurarse en el descriptor de despliegue de la
aplicación (WEB-INF/web.xml) y en el servlet de "escucha" del API JAX-WS.
Definición de servicios web con JAX-WS
El único requisito es contar con un interfaz y/o una clase de implementación anotado con
@WebService.
www.learning.es
En el caso de EJB endpoints, además deben de estar anotados como @Stateless (los servicios web
son sin estado).
La clase de implementación debe ser pública y no puede ser final ni abstract.
La clase de implementación debe contar con un constructor vacío.
La clase de implementación no puede definir un método finalize().
Debe garantizarse una implementación sin estado. 14
La clase de implementación no puede guardar información de estado entre llamadas del cliente.
Por defecto, para la clase/interface de implementación se generará un elemento WSDL service con el
mismo nombre de la clase y el sufijo Service, además se generará un elemento WSDL portType con
el nombre de la clase.
Para cada método público de la clase se generará un elemento WSDL operation con el mismo
nombre del método y dos elementos WSDL message, uno para la petición (con el nombre del
método) y otro para la respuesta (añadiendo al nombre del método el sufijo respose).
Los parámetros y valores de devolución deben de ser tipos básicos Java, clases anotadas con JAXB,
arrays, Map, List o Collection de los anteriores.
Tipos de Anotaciones JAX-WS
Anotaciones que definen el mapeo WSDL (modifican el comportamiento por defecto):
@WebService:
Señala una clase o interfaz como endpoint de un servicio web.
Incluye atributos para modificar el nombre del elemento service, portType, el name space, etc
(name, targetNamespace, serviceName, portName, wsdlLocation, endpointInterface)
@WebMethod
Permite modificar la definición de las operaciones WSDL (atributo operationName) o excluir métodos
de la clase que no se desean exponer como operaciones del web service (con el atributo
exclude=true).
@WebResult
Permite controlar el nombre del elemento message de WSDL que contendrá el valor de retorno
(atributo name).
@WebParam
Permite configurar los elementos parameter de WSDL vinculados a los parámetros de una operación
(atributos: name, mode [IN, OU, INOUT], targetNamespace, header, partName)
@OneWay
Permite indicar que un método no tendrá valor de retorno.
Existen también anotaciones que definen el binding SOAP de las operaciones y los métodos:
@SOAPBinding
Para un método de la clase endpoint especifica el estilo de codificación de los mensajes (RPC vs.
document) y el tipo de codificación de los parámetros a usar (encoded vs.literal).
Atributos: style, use, parameterStyle.
@SOAPMessageHandler
Especifica detalles de la gestión de los mensajes (petición y respuesta).
Atributos: name, className, initParams, roles, heards
www.learning.es
En el siguiente ejemplo consumiremos el servicio web que devuelve el tiempo meteorológico
Servicio web tiempo meteorológico

Crear una aplicación java que utilice el servicio web que nos devuelve la previsión meteorológica en
tiempo real.
15
Utilizar los dos métodos del servicio web.
Agregamos el archivo de tipo Web Service Client a nuestro proyecto de tipo java application.
Referencia al servicio web:

http://www.webservicex.net/globalweather.asmx?WSDL
Probamos el servicio recién referenciado.

String tiempo=getWeather("MADRID","SPAIN");
www.learning.es
System.out.println(tiempo);
}
private static String getCitiesByCountry(java.lang.String countryName) {

MisServicios.GlobalWeather service = new MisServicios.GlobalWeather();
MisServicios.GlobalWeatherSoap port = service.getGlobalWeatherSoap();
return port.getCitiesByCountry(countryName);
} 16
private static String getWeather(java.lang.String cityName, java.lang.String countryName) {

MisServicios.GlobalWeather service = new MisServicios.GlobalWeather();
MisServicios.GlobalWeatherSoap port = service.getGlobalWeatherSoap();
return port.getWeather(cityName, countryName);
}
Ver Video: Analizando Servicios Web , en la Unidad 1,

en el Módulo 8, en la plataforma elearning
www.learning.es
Laboratorio: Analizando ServiciosWeb
Objetivo
Consumir un proyecto Web Service de ASP.Net desde una aplicación Java.
17
Enunciado
Servicio web monedas asp.net
- Realizar un Servicio Web con ASP.NET cuya funcionalidad será convertir Monedas.
- Podremos convertir entre diversas monedas a euros y viceversa, de euros a monedas.
- Las Monedas que vamos a convertir son:
 DOLAR = 1,26201 Euros
 PESOS = 14,4762 Euros
 RUPIAS = 75,6061 Euros
 YENES = 135,861 Euros
 PESETAS = 166,386 Euros
Servicio web monedas

1. Crear un servicio web con Visual Studio .Net con el código siguiente:
public double[] valores = new double[] { 1.26201, 14.4762, 75.6061, 135.861, 166.386 };
[WebMethod]
public double convertirMonedaEuro(double valor, int indice)
{
return (valor * valores[indice]);
}
[WebMethod]
public double convertirEuroMoneda(double valor, int indice)
{
return (valor / valores[indice]);
}
2. Ejecutar el servicio.
Ejemplo prueba conversión de monedas

1. Crear un proyecto en NetBeans de tipo java application y agregar un archivo de tipo WebService
Client.
www.learning.es
2. Enlazarnos al servicio web recién creado. Colocamos la dirección del servicio seguido de WSDL.
http://localhost:2920/ServicioConvertirMonedas/Service.asmx?WSDL
18
public static void main(String[] args)

{
double resultado = convertirMonedaEuro(121,2);
System.out.println(resultado);
private static Double convertirMonedaEuro(double valor, int indice) {

ConsumirWS.NewWebServiceService service = new ConsumirWS.NewWebServiceService();
ConsumirWS.NewWebService port = service.getNewWebServicePort();
return port.convertirMonedaEuro(valor, indice);
}
Actividades
“Recuerde que para un seguimiento óptimo de la unidad es imprescindible realizar las actividades
que encontrará en la unidad correspondiente de la plataforma eLearning”.
www.learning.es
Unidad 2. Diseñando Buenas Prácticas y
Patrones para los Servicios Web
Objetivos
 Comprender los patrones de diseño en el contexto de los servicios web.
19
 Describir los patrones de diseño basados en servicios web.
 Implementar patrones de diseño.
Introducción
Un Patrón de Diseño (design pattern) es una solución repetible a un problema recurrente en el
diseño de software. Esta solución no es un diseño terminado que puede traducirse directamente a
código, sino más bien una descripción sobre cómo resolver el problema, la cual puede ser utilizada
en diversas situaciones. Los patrones de diseño reflejan todo el rediseño y remodificación que los
desarrolladores han ido haciendo a medida que intentaban conseguir mayor reutilización y
flexibilidad en su software. Los patrones documentan y explican problemas de diseño, y luego
discuten una buena solución a dicho problema. Con el tiempo, los patrones comienzan a
incorporarse al conocimiento y experiencia colectiva de la industria del software, lo que demuestra
que el origen de los mismos radica en la práctica misma más que en la teoría. La definición de
Christopher Alexander sobre patrones: “cada patrón describe un problema que ocurre una y otra vez
en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar esta
solución un millón de veces, sin hacer lo mismo dos veces”. Si bien ésta definición es sobre patrones
de ciudades y edificios la idea es aplicable a la industria del software: encontrar una solución a un
problema dentro de un contexto. Un patrón de diseño nomina, abstrae e identifica los aspectos clave
de una estructura de diseño común, lo que los hace útiles para crear un diseño orientado a objetos
reutilizable. El patrón de diseño identifica las clases e instancias participantes, sus roles y
colaboraciones, y la distribución de responsabilidades. Cada patrón de diseño se centra en un
problema concreto, describiendo cuándo aplicarlo y si tiene sentido hacerlo teniendo en cuenta otras
restricciones de diseño, así como las consecuencias, ventajas e inconvenientes de su uso. En los
últimos años los patrones han ido ganando aceptación, y se fueron extendiendo a otras áreas dentro
del desarrollo y mantenimiento de software. Su utilización, si bien todavía le queda mucho camino
por recorrer, comienza a tener suficiente madurez. Los patrones de diseño proveen una forma
efectiva para compartir experiencia con la comunidad de programadores de software orientado a
objetos.
El término “patrón de diseño” no es extremadamente preciso pero sí muy útil. En la forma en la que
se suele entender actualmente fue acuñado en Gamma y col.(1994), importante referencia que se
suele designar abreviadamente como GoF1. Por la manera en que se emplea este concepto en esta
referencia básica y en la mayoría de usos posteriores, se refiere a una manera especialmente
inteligente y perspicaz de resolver un tipo general de problema.
A pesar de constar el término “diseño” no se suele considerar que se refiera únicamente a la fase de
diseño de un programa, es una solución completa que incluye análisis, diseño e implementación. Un
“patrón de diseño” no se considera bien especificado hasta que se ha podido plasmar en forma de
código en algún lenguaje, pero claramente no es una convención o receta “idiomática”, ligada a un
lenguaje concreto, como podría la relacionada con “cómo recorrer de forma eficiente un vector en C
empleando aritmética de punteros”, por poner un ejemplo. Sin embargo, en GoF se remarca que un
patrón puede serlo, tener sentido identificarlo como tal o no, dependiendo del lenguaje utilizado. En
el lenguaje de implementación elegido en GoF, C++, un patrón como “herencia” no tiene sentido (ya
está implícito en el propio lenguaje) mientras que sería una solución general muy adecuada a
numerosos problemas si el lenguaje de implementación fuese C, por ejemplo. Tampoco hay que
confundir “patrón de diseño” con un algoritmo adecuado para resolver un tipo concreto de problema
–que, lógicamente, se tendría que implementar de forma distinta según el lenguaje. Un patrón de
www.learning.es
diseño debe ser una especificación muy general, una especie de invariante que se cumple en
problemas de ámbitos diversos y que define una solución general y muy estable.
Los desarrolladores de software han aprendido a reutilizar código y de esa manera tendrán su marco
de trabajo básico para usar cuando se enfrenten a problemas de similares características. Una de las
formas de solucionar estos problemas de manera eficiente y efectiva es la utilización de los Patrones
de Diseño. Una notación práctica y aceptada para la especificación, visualización, construcción y
documentación de sistemas de software es UML que permite la construcción de una serie de
20
diagramas que facilitan el desarrollo y comunicación de un proyecto de software. . Dado que UML es
un lenguaje que permite ser extendido y que los Patrones de Diseño aportan buenas soluciones a
problemas recurrentes, este Trabajo Final tiene como objetivo extender UML e incorporarle el uso de
Patrones de Diseño para ampliar las potencialidades de este lenguaje y brindar al desarrollador de
software la posibilidad de incorporar Patrones de Diseño en sus proyectos.
Actualmente, los patrones de diseño son, sin duda, alguna la herramienta más importante de la que
disponemos los ingenieros, arquitectos, analistas, desarrolladores, etc., para la creación de sistemas
robustos, escalables, fácilmente adaptables y con grandes cotas de reutilización. Se han escrito
miles y miles de líneas sobre las ventajas de los patrones de diseño, pero sin embargo, pocos han
sido los análisis de los problemas asociados a su uso.
Son una forma de formalizar la reusabilidad de código ante situaciones similares a las ya conocidas.
Se plantean como una buena herramienta para el diseño y la documentación de aplicaciones y
frameworks. Son descripciones de objetos y clases que se comunican y que son capaces de
solucionar un problema de diseño en general, en un contexto en particular. . "Cada patrón describe
un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la
solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces
sin hacerlo ni siquiera dos veces de la misma forma". (Alexander Christopher)
Proponen una forma de reutilizar la experiencia de los programadores. Contribuyen a dar flexibilidad
y extensibilidad a los diseños. Contribuyen a reutilizar diseño, identificando aspectos claves de la
estructura de un diseño que puede ser aplicado en una gran cantidad de situaciones. Mejoran
(aumentan, elevan) la flexibilidad, modularidad y extensibilidad.. Incrementan el vocabulario de
diseño, ayudando a diseñar desde un mayor nivel de abstracción.
Elementos:
 Nombre: resume la esencia del patrón. .
 Clasificación: según el propósito - ¿Qué hacen? - y el alcance - ¿Dónde se aplican? - .
Sinopsis: responde a ¿Qué hace el patrón? .
 Contexto: ejemplo que ilustra el problema y cómo se estructuran clases y objetos para
solucionarlo. .
 Aplicabilidad: situaciones en las que puede aplicarse el patrón. .
 Estructura: representación gráfica de las clases que intervienen y sus relaciones. .
Participantes: clases, objetos y responsabilidades. .
 Consecuencias: resultados y cambios al usar el patrón. .
 Diagrama de Ejemplo: diagrama del modelo del usuario que usa el/los estereotipo/s que
forma/n el patrón y en el que se cumplen las Reglas OCL.
Clasificación:
Según el Propósito: ¿Qué hacen?
 Creacionales: relacionados con el proceso de creación de objetos.
 de Comportamiento: relacionados con la interacción de clases y objetos y la distribución de
responsabilidades.
 Estructurales: relacionados con la composición de clases y objetos.
Según el Alcance: ¿Dónde se aplican?

 Clase: tratan la relación entre subclases a través de herencia.
www.learning.es
 Objeto: tratan la relación entre objetos que cambian en tiempo de ejecución.
Diseñar una arquitectura basada en patrones de diseño es una tarea compleja, que reporta muchos
beneficios, pero prácticamente imposible sin un estudio previo del dominio del problema que
estamos tratando. El uso de lenguajes de modelado como UML nos ayuda a ver mejor las
propiedades del sistema que estamos diseñando y harán aparecer relaciones entre los componentes
que a primera vista eran difusas o que simplemente no habíamos visto. El mero hecho de utilizar
patrones de diseño y comenzar a realizar su implementación sin tener en cuenta el dominio de
21
nuestro modelo, es un error gravísimo y degenera en la práctica de ir esparciendo patrones por las
diferentes partes de un proyecto sin ningún criterio general.
Estos patrones no representarán ningún concepto de nuestro dominio, probablemente no reflejarán

ningún significado a alguien que no esté familiarizado con nuestro proyecto, y dificultarán
notablemente la extensibilidad de nuestro proyecto obligando a una refactorización continua. Antes
de abordar un proyecto con patrones hemos de analizar minuciosamente qué patrones nos pueden
ser útiles, cuáles son las relaciones entre los diferentes componentes de nuestro sistema, cómo
podemos relacionar los patrones entre sí de modo que formen una estructura sólida, cuáles son los
patrones que reflejan nuestro dominio, etc. Esta tarea obviamente es mucho más compleja que el
mero hecho de ponerse a codificar patrones.
Existen cientos y cientos de patrones que han ido apareciendo con el tiempo y que se han
convertido en soluciones estándar para diferentes problemas, y por supuesto no limitados al ámbito
informático sino que podemos encontrar patrones de arquitectura, de economía, etc. Así que la
clave de todo es la experiencia puede que hayamos realizado un análisis fantástico y que hayamos
estudiado los patrones más avanzados en el ámbito que estamos afrontando, sin embargo, sin la
experiencia adecuada nuestro proyecto fracasará.
Sea como sea, la experiencia se adquiere con el tiempo y a base de tropiezos. Seguramente
nuestros primeros proyectos no queden como los habíamos ideado en su concepción, y con el
tiempo, nos demos cuenta de que podríamos haber utilizado otros métodos para abordar de un
modo más eficiente los problemas con los que nos habíamos enfrentado.
La primera regla de los patrones de diseño coincide con la primera regla de la optimización:
retrasar. Del mismo modo que no es aconsejable optimizar prematuramente, no se deben utilizar
patrones de diseño antes de tiempo. Seguramente sea mejor implementar algo primero y
asegurarse de que funciona, para luego utilizar el patrón de diseño para mejorar las flaquezas; esto
es cierto, sobre todo, cuando aún no ha identificado todos los detalles del proyecto (si comprende
totalmente el dominio y el problema, tal vez sea razonable utilizar patrones desde el principio, de
igual modo que tiene sentido utilizar los algoritmos más eficientes desde el comienzo en algunas
aplicaciones).
Los patrones de diseño pueden incrementar o disminuir la capacidad de comprensión de un diseño o
de una implementación, disminuirla al añadir accesos indirectos o aumentar la cantidad de código,
disminuirla al regular la modularidad, separar mejor los conceptos y simplificar la descripción. Una
vez que aprenda el vocabulario de los patrones de diseño le será más fácil y más rápido
comunicarse con otros individuos que también lo conozcan. Porque atraviesa una estructura y
realiza llamadas de retorno, en tanto que algunos métodos deben estar presentes y son llamados de
este modo y en este orden”.
La mayoría de las personas utiliza patrones de diseño cuando perciben un problema en su proyecto
—algo que debería resultar sencillo no lo es — o su implementación— como por ejemplo, el
rendimiento. Examine un código o un proyecto de esa naturaleza. ¿Cuáles son sus problemas, cuáles
son sus compromisos? ¿Qué le gustaría realizar que, en la actualidad, es muy difícil lograr? A
continuación, compruebe una referencia de patrón de diseño y busque los patrones que abordan los
temas que le preocupan.
Componentes fundamentales
www.learning.es
Para que una solución sea considerada un patrón debe poseer ciertos componentes fundamentales:
 Nombre del patrón. Permite describir en pocas palabras un problema de diseño junto con sus
soluciones y consecuencias.
 Problema (o fuerzas no balanceadas). Indica cuándo aplicar el patrón. En algunas
oportunidades el problema incluye una serie de condiciones que deben darse para aplicar el
patrón. Muestra la verdadera esencia del problema. Este enunciado se completa con un
conjunto de fuerzas, término que se utiliza para indicar cualquier aspecto del problema que 22
deba ser considerado a la hora de resolverlo, entre ellos:
- Requerimientos a cumplir por la solución.
- Restricciones a considerar.
- Propiedades deseables que la solución debe tener.
Son las fuerzas las que ayudan a entender el problema dado que lo exponen desde distintos puntos
de vista.
 Solución. No describe una solución o implementación en concreto, sino que un patrón es más
bien como una plantilla que puede aplicarse en diversas situaciones diferentes. El patrón
brinda una descripción abstracta de un problema de diseño y cómo lo resuelve una
determinada disposición de objetos. Que la solución sea aplicable a diversas situaciones
denota el carácter “recurrente” de los patrones.
 Consecuencias. Resultados en términos de ventajas e inconvenientes.
Tipos de patrones
Según el nivel de abstracción los patrones de diseño pueden clasificarse de la siguiente forma:
 Patrones arquitectónicos. Centrados en la arquitectura del sistema. Definen una estructura
fundamental sobre la organización del sistema. Proveen un conjunto predefinido de
subsistemas, cuáles son sus responsabilidades y como se interrelacionan.
 Patrones de diseño. Esquemas para refinar los subsistemas o componentes de un sistema de
software, o sus relaciones. Describen una estructura recurrente y común de componentes
comunicantes que resuelven un problema de diseño dentro de un contexto.
Ejemplo: el patrón singleton asegura que exista sólo una instancia de una determinada clase.
Patrones de codificación o modismos (idioms). Patrones que ayudan a implementar aspectos
particulares del diseño en un lenguaje de programación específico. Ejemplo: en Java implementar
una interface en una clase anónima.
Los patrones arquitectónicos podrían considerarse estrategias de alto nivel que abarcan
componentes a gran escala, propiedades y mecanismos del sistema. Tienen implicancias muy
amplias que afectan tanto a la estructura como a la organización del sistema. Los patrones de
diseño son tácticas de medio nivel para profundizar en la estructura y comportamiento de ciertos
componentes y sus relaciones. Los patrones de diseño no influencian la estructura del sistema sino
que definen micro-arquitecturas para los subsistemas y componentes. Por último, los modismos son
técnicas específicas del paradigma y lenguaje de programación que complementan detalles de bajo
nivel (internos o externos) de la estructura de un componente.
Patrones Creacionales. Los patrones creacionales abstraen el proceso de instanciación de objetos,

ayudando a que el sistema sea independiente de cómo se crean, componen y representan sus
objetos. Estos patrones encapsulan el conocimiento sobre las clases concretas que utiliza el sistema.
En otras palabras, estos patrones brindan soporte a una de las tareas más comunes dentro de la
programación orientada a objetos: la instanciación. Estos patrones brindan las siguientes
características:
www.learning.es
 Instanciación genérica: permite que los objetos sean creados dentro del sistema sin especificar
clases concretas en el código.
 Simplicidad: algunos patrones facilitan la creación de objetos, evitando que el cliente deba tener
código complejo sobre como instanciar un determinado objeto.
 Restricciones creacionales: algunos patrones ayudan a establecer restricciones sobre la creación
de objetos, tales como qué objeto crear, cuándo, cómo, etc.
23
Por lo general, son alternativas de diseño bajo estrategias de herencia o delegación que encapsulan
el mecanismo de creación, independizando los tipos de objetos “producto” que se manejan. Los
patrones creacionales son los siguientes:
1. Singleton: asegura que una determinada clase sea instanciada una y sólo una vez,
proporcionando un único punto de acceso global a ella.
2. Abstract Factory: provee una interfaz para crear familias de objetos productos relacionados o
que dependen entre si, sin especificar sus clases concretas.
3. Factory Method: define una interfaz para crear un objeto delegando la decisión de qué clase
crear en las subclases. Este enfoque también puede ser llamado constructor “virtual”.
4. Builder: separa la construcción de un objeto complejo de su representación, de forma que el
mismo proceso de construcción pueda crear diferentes representaciones. Simplifica la
construcción de objetos con estructura interna compleja y permite la construcción de objetos
paso a paso. Ejemplo: este patrón se encuentra en los restaurantes de comidas rápidas que
preparan menús infantiles. Generalmente estos menús están formados de un plato principal,
un acompañamiento, una bebida y un juguete. Si bien el contenido del menú puede variar, el
proceso de construcción es siempre el mismo: el cajero indica a los empleados los pasos a
seguir. Estos pasos son: preparar un plato principal, preparar un acompañamiento, incluir un
juguete y guardarlos en una bolsa. La bebida se sirve en un vaso y queda fuera de la bolsa.
5. Prototype: facilita la creación dinámica de objetos mediante la definición de clases cuyos
objetos pueden crear duplicados de si mismos. Estos objetos son llamados prototipos.
Ejemplo: un escenario frecuente es contar con GUIs (Interfaz Gráfica de Usuario) que
cuenten con un gran número de controles similares, los cuales deben ser inicializados a un
determinado estado común para mantener consistencia. El proceso de inicialización se repite
varias veces por cada control de manera que las líneas de código se incrementan. Con el fin
de optimizar estas partes del código se puede contar con un objeto inicializado en un
determinado estado estándar y luego obtener clones de él ya inicializados. Patrones
estructurales. Se encargan de cómo se combinan clases y objetos parar formar estructuras
más grandes. Los patrones estructurales de clases utilizan la herencia para componer
interfaces o implementaciones. En lugar de combinar interfaces o implementaciones, los
patrones estructurales de objetos describen formas de componer objetos para obtener
nuevas funcionalidades. La flexibilidad añadida mediante la composición de objetos viene
dada por la capacidad de cambiar la composición en tiempo de ejecución, que es imposible
con la composición de clases. Ejemplos típicos son cómo comunicar dos clases incompatibles
o cómo añadir funcionalidad a objetos. Los patrones estructurales son los siguientes:
6. Adapter: oficia de intermediario entre dos clases cuyas interfaces son incompatibles de
manera tal que puedan ser utilizadas en conjunto. Ejemplo: en la vida cotidiana se ven
ejemplos de este patrón, quizá el más común de ellos sea el de los adaptadores de enchufes
el cual permitiría utilizar un enchufe de dos patas planas adaptándolo a un toma corriente de
dos patas redondas.
7. Bridge: disocia un componente complejo en dos jerarquías de clases: una abstracción
funcional y la implementación interna, para que ambas puedan variar independientemente.
Ejemplo: los electrodomésticos y sus interruptores de encendido pueden ser considerados
como ejemplos de este patrón donde el interruptor de encendido es considerado la
abstracción y el electrodoméstico en si la implementación. El interruptor podría ser un simple
interruptor de encendido/apagado, un regulador de velocidades u alguna otra opción,
mientras que el electrodoméstico puede ser una lámpara, un ventilador de techo, etc.
www.learning.es
8. Composite: compone objetos en estructuras de árboles para representar jerarquías parte-
todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los
complejos. Ejemplo: en una gráfica de Gantt existen tareas simples (con una actividad) y
compuestas (que contienen varias tareas). Modelar estos dos tipos de tareas en una
jerarquía de clases donde ambas son subclases de una clase que cuente con un método
“calculáTiempoUtilizado” permitiría tratar de forma uniforme a tareas simples y compuestas
para calcular el tiempo utilizado por cada una de ellas. Concretamente una tarea simple
informa el tiempo dedicado a ella, mientras que una compuesta lo hace sumando los tiempos 24
insumidos de cada una de las tareas que contiene.
9. Decorator: agrega o limita responsabilidades adicionales a un objeto de forma dinámica,
proporcionando una alternativa flexible a la herencia para extender funcionalidad. Ejemplo: si
bien es cierto que se pueden colgar pinturas, cuadros y fotos en las paredes sin marcos,
éstos suelen ser utilizados a menudo y son ellos los que se cuelgan en la pared en lugar de
su contenido (pinturas, cuadros, etc.). Al momento de colgarse los cuadros junto con su
marco pueden formar un solo “componente visual”
10. Facade: proporciona una interfaz simplificada para un conjunto de interfaces de subsistemas.
Define una interfaz de alto nivel que hace que un subsistema sea más fácil de usar. Ejemplo:
En un sistema de compras los clientes contactan a un responsable de ventas que actúa como
Facade al momento de realizar un pedido. Este representante de ventas actúa como Facade
proveyendo una interface con los departamentos (subsitemas) de pedidos, facturación y
envíos.
11. Flyweight: permite el uso de un gran número de objetos de grano fino de forma eficiente
mediante compartimiento. Ejemplo: La red telefónica pública conmutada es un ejemplo de
este patrón ya que hay diversos componentes, como por ejemplo nodos de conmutación, que
se deben compartir entre los distintos usuarios. Los usuarios no conocen cuántos
componentes de cada tipo hay disponibles al momento de realizar la llamada. Lo único por lo
que se preocupan los usuarios es por obtener tono para marcar, poder discar y efectuar la
llamada.
12. Proxy: Provee un sustituto o representante de un objeto para controlar el acceso a éste. Este
patrón posee las siguientes variantes: - Proxy remoto: se encarga de representar un objeto
remoto como si estuviese localmente. - Proxy virtual: se encarga de crear objetos de gran
tamaño bajo demanda. - Proxy de protección: se encarga de controlar el acceso al objeto
representado. Patrones de comportamiento Tienen que ver con algoritmos y asignación de
responsabilidades. Estos patrones se focalizan en el flujo de control dentro de un sistema.
Ciertas formas de organizar los controles dentro del sistema pueden llevar a grandes
beneficios en cuanto a mantenibilidad y eficiencia. Algunos ejemplos de estos patrones
incluyen la definición de abstracciones de algoritmos, las colaboraciones entre objetos para
realizar tareas complejas reduciendo las dependencias o asociar comportamiento a objetos e
invocar su ejecución. Los patrones de comportamiento basados en clases utilizan la herencia
para distribuir el comportamiento entre clases, ellos son: Template Method e Interpreter.
Mientras que los basados en objetos utilizan la composición. Los patrones de comportamiento
son los siguientes:
13. Chain of responsibility: establece una cadena de mensajes dentro del sistema de manera tal
que dicho mensaje sea manejado en el mismo nivel donde fue emitido, o redirigido a un
objeto capaz de manejarlo. Evita acoplar el emisor del mensaje con un receptor, dando a
más de un objeto la posibilidad de responder al mensaje.
14. Command: representa una solicitud con un objeto, de manera tal de poder parametrizar a los
clientes con distintas solicitudes, encolarlas o llevar un registro de las mismas, y poder
deshacer las operaciones. Estas solicitudes, al ser representadas como un objeto también
pueden pasarse como parámetro o devolverse como resultados.
15. Interpreter: en un contexto donde se repite una determinada clase de problemas y el
dominio es bien conocido, se pueden caracterizar estos problemas como un lenguaje y, a su
vez, estos problemas pueden ser tratados por un “motor” de interpretación. Este patrón
busca definir un intérprete para dicho lenguaje, para el cual define una gramática y un
www.learning.es
intérprete de la misma para poder resolver los problemas. Ejemplo: distintos motores de
bases de datos (Oracle, SQL Server, Sybase, DB2, etc.) utilizan distintos códigos de error
para indicar fallas (errores de clave duplicada, violación de restricciones de integridad
referencial, longitud de datos, etc.). La utilización de éste patrón permitiría definir un
intérprete de errores para cada motor de base de datos con el cual se determinaría la falla y
tomarían las acciones pertinentes en función de la misma. El sistema debe configurarse para
utilizar el intérprete adecuado según el motor de base de datos.
25
16. Iterator: provee un modo de acceder secuencialmente a los elementos de un objeto agregado
(una colección) sin exponer su representación interna. El iterador está altamente acoplado al
objeto agregado. Ejemplo: Los árboles-B pueden recorrerse de tres formas distintas: pre-
orden, en-orden y post-orden. La aplicación de este patrón permitiría definir un iterador para
cada tipo de recorrido, pudiendo ser utilizados para recorrer el árbol sin exponer su
contenido.
17. Mediator: simplifica la comunicación entre objetos dentro del sistema mediante la
introducción de un objeto mediador que administra la distribución de mensajes entre objetos.
Promueve bajo acoplamiento al evitar que los objetos se referencien unos a otros
explícitamente, permitiendo variar la interacción entre ellos independientemente. Ejemplo:
Este patrón puede verse en las torres de control de los aeropuertos. Los pilotos de los
aviones que se encuentran por despegar o aterrizar se comunican con la torre en lugar de
hacerlo explícitamente entre ellos. La torre de control regula quien puede aterrizar y
despegar, pero no se encarga de controlar todo el vuelo.
18. Memento: preserva una “fotografía instantánea” del estado de un objeto con el fin de
permitirle volver a su estado original, sin revelar su contenido al mundo exterior. Ejemplo:
una funcionalidad muy importante de los editores de texto es “Deshacer” o “Undo”, esta
funcionalidad puede implementarse vía Memento. Para realizar esto se debe considerar al
contenido del documento como estado del editor y ante cada cambio del documento se debe
tomar una nueva fotografía del estado del documento antes de la modificación, para poder
volver al mismo. Dos factores importantes deben ser tenidos en cuenta: el orden de
guardado de los cambios, para poder deshacerlos correctamente y cuando limpiar el registro
de estados intermedios ya que esto puede consumir muchos recursos.
19. Observer: brinda un mecanismo que permite a un componente transmitir de forma flexible
mensajes a aquellos objetos que hayan expresado interés en él. Estos mensajes se disparan
cuando el objeto ha sido actualizado, y la idea es que quienes hayan expresado interés
reaccionen ante este evento. Ejemplo: este patrón puede verse en las subastas donde cada
ofertante (Observer) tiene un indicador con su número, el cual es utilizado para indicar la
aceptación de una oferta. El subastador(Subject, objeto observado) comienza la subasta con
una oferta inicial, cuando un ofertante toma esa oferta el subastador les retransmite a todos
los ofertantes que el precio ha cambiado.
20. State: permite que un objeto modifique su comportamiento cada vez que cambie su estado
interno. El objeto parecerá que cambió de clase. Ejemplo: este patrón puede observarse en
las máquinas expendedoras de golosinas, las cuales pasan por distintos estados: stock
disponible, dinero depositado, capacidad para dar vuelto, golosina seleccionada, etc. En cada
uno de éstos estados la máquina se comporta distinta. Cuando se deposita dinero y se elije
una golosina la expendedora puede entregar un producto y no cambiar su estado, entregar
un producto y cambiar su estado (por ejemplo quedarse sin stock, en cuyo caso no entregará
mas golosinas, o no entregar golosinas ya sea por falta de stock o cambio).
21. Strategy: define una jerarquía de clases que representan algoritmos, los cuales son
intercambiables. Estos algoritmos pueden ser intercambiados por la aplicación en tiempo de
ejecución. Ejemplo: Se dispone de un programa que encripta y desencripta mensajes de
texto usando distintos algoritmos de encriptación. Cada uno de estos algoritmos de
encriptación puede modelarse como una clase con servicios de encriptación (un método
“encriptaMensaje” que recibe el texto llano y una clave, para devolver un texto cifrado y
servicios de desencriptación (un método “desencriptaMensaje” que recibe una clave y un
texto cifrado para devolver uno descifrado).
www.learning.es
22. Template Method: define en una operación el esqueleto de un algoritmo, delegando en las
subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del
algoritmo sin cambiar su estructura.
23. Visitor: representa una operación sobre elementos de una estructura de objetos. Permite
definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
Brinda una forma sencilla y mantenible de realizar acciones sobre una familia de clases.
Ejemplo: un compilador interpreta código fuente y lo representa como un árbol de sintaxis
26
abstracta (Abstract Syntax Tree, AST), el cual cuenta con diversos tipos de nodos
(asignaciones, expresiones condicionales, etc.). Sobre este árbol se desean ejecutar algunas
operaciones como: revisar que todas las variables fueron declaradas, chequeos de tipos de
datos, generación de código, etc. Una forma de realizar estas operaciones es mediante la
implementación del patrón Visitor, el cual recorrerá toda la estructura del árbol. Cuando un
nodo acepte al Visitor, éste invocará al método de visita definido en el Visitor que toma por
parámetro al nodo siendo visitado.
Patrones de diseño basados en servicios web

Para el desarrollo de aplicaciones orientadas a servicio utilizando arquitecturas SOA, se han
desarrollado una serie de patrones de software.
Estos patrones se pueden dividir en cinco categorías:
Aprendizaje
Es importante entender el entorno de los servicios Web. Dentro de esta categoría podemos
encontrar:
Service-Oriented Architecture: Es el patrón que forma la arquitectura de los servicios Web como ya
hemos visto anteriormente.
Architecture Adapter. Se puede ver como un patrón genérico que facilita la comunicación entre
arquitecturas.
Service Directory: Este patrón facilita la transparencia en la localización de servicios, permitiendo
realizar robustas interfaces para encontrar el servicio que realmente se quiere.
Adaptación
Estos patrones son los llamados básicos para conocer el funcionamiento del entorno de los Servicios
Web.
En esta categoría nos encontramos:
 Business Object: Un business object engloba a un concepto de negocio del mundo real como
puede ser un cliente, una compañía o un producto, por ejemplo, y lo que pretende este patrón
es trasladar el concepto de objeto de negocio dentro del paradigma de los servicios Web.
 Business Process: Este patrón se utiliza para tratar con procesos de negocio. En este momento
existen dos estándares:
o Business Process Execution Lenguaje (BPEL) propuesto por Bea Systems, IBM y Microsoft.
o Business Process Modeling Languaje (BPML) propuesto por el resto de compañías que no
están en el grupo anterior como pueden ser WebMethods, SeeBeyond, etc.
 Bussines Object Collection: Con este patrón se pueden realizar composiciones de procesos de
negocio.
 Asynchronous Bussines Process: Este patrón es la evolución del patrón anterior Bussines
Process.
www.learning.es
Determinando Cambios
Aunque los servicios Web permiten llamadas asíncronas, las implementaciones del servicio pueden
estar basados en paso de mensajes, también son importantes los servicios basados en eventos,
estos patrones se basan en patrones tradicionales como el Observer o el patrón
Publicación/Suscripción.
27
En esta categoría podemos encontrar:
o Event Monitor: Es un patrón para crear formas efectivas para integrar aplicaciones sin la
intervención de otros componentes. El escenario más común donde se utiliza este patrón es
para aplicaciones EAI (Enterprise Application Integration).
o Observer Services: Este patrón representa la manera más natural de detectar cambios y
actuar en consecuencia.
o Publish/Subscribe Services: Es la evolución del Observer Pattern, mientras que el patrón
Observer se base en el registro, el patrón Publish/Subscribe se base en notificaciones, esto
permite que distintos servicios puedan enviar la misma notificación.
Redefinición
Estos patrones te permiten acceder al comportamiento de un servicio que está implementado en un
lenguaje. Ayudan a entender el entorno del Servicio Web y a moldear este entorno de acuerdo con
nuestras necesidades.
En esta categoría podemos encontrar:
o Physical Tires: Este patrón ayuda a estructurar mejor la lógica de negocio de los servicios
Web, e incluso se puede utilizar para controlar el flujo de negociaciones que puede llegar a
producirse utilizando el patrón Publish/Subscribe.
o Connector: Este patrón se suele utilizar con el anterior para resolver los posibles problemas
que surgen en la subcripción.
o Faux Implementation: Es una alternativa para resolver los problemas que surgen en la
utilización de eventos en los servicios Web. Es simplemente un “socket abierto” que recibe
conexiones y aporta las respuestas para los distintos eventos.
Creando flexibilidad
Para crear servicios más flexibles y optimizados.
En esta categoría se encuentran:
o Service Factory: Es uno de los patrones más importantes y permite la selección de servicios y
aporta flexibilidad en la instanciación de los componentes que crean los servicios Web. Este
patrón también se suele utilizar con el patrón Service Cache para aportar una mayor
flexibilidad en el mantenimiento de las aplicaciones que utilizan servicios Web, aportando un
mayor ROI a las aplicaciones.
o Data Transfer Object: Este patrón aporta rendimiento ya que permite recoger múltiples datos
y enviarlos en una única llamada, reduciendo el número de conexiones que el cliente tiene
que hacer al servidor.
o Partial Population: Este patrón permite a los clientes seleccionar únicamente los datos que
son necesarios para sus necesidades y sólo recuperar del servidor lo necesario. Este patrón
además de rendimiento aporta mayor ancho de banda en la red.
www.learning.es
o Algunos patrones utilizan otros por ejemplo el Business Process Patern usa el Business Object
Patern y el Business Object Collection. Y el Service-Oriented Architecture usa los patrones
Service Directory y Architecture Adapter.
Buenas prácticas para desarrollar servicios web SOAP

28
Es importante conocer las prácticas más recomendables a la hora de desarrollar servicios web SOAP.
Comentaremos en este bloque las prácticas más recomendables:
Analizar qué servicios web y con qué operaciones hay que desarrollar
Debemos analizar y diseñar servicios web con las responsabilidades bien repartidas, que sean
cohesivos, extensibles, escalables y reutilizables.
Escribe tu mismo el fichero WSDL (Contract-First)

Es el interfaz, el contrato y, en definitiva, la clave para una interoperabilidad real e independiente de
la tecnología. Además los generadores de WSDL pueden introducir dependencias con una tecnología
concreta. Por eso merece la pena aprender a escribir WSDL y schemas XSD.
Más eficiente un único mensaje enorme
A la hora de diseñar el interfaz de las operaciones, ten siempre en cuenta que un solo mensaje es
mucho más rápido que el equivalente en múltiples mensajes.
Sé coherente con la nomenclatura de namespaces de la organización
No hay nada que de peor impresión que un servicio web que no ha cuidado los namespaces.
El WSDL debe ser compatible con el WS-I Basic Profile
El WS-I Basic Profile es un conjunto de especificaciones y buenas prácticas definidas por la industria
para obtener servicios web interoperables.
Usa http://localhost:puerto como dirección url del endpoint

Deja que sea el motor de webservices el encargado de sustituirla por la real. Así evitarás tener un
fichero WSDL por entorno.
Separa la definición de los mensajes del fichero WSDL.
Diseña por separado un schema XSD donde se definan los mensajes y que sea importado por el
fichero WSDL. Las principales ventajas son que se reduce el tamaño/complejidad del WSDL, permite
utilizar editores especializados para el diseño del schema XSD y permite reutilizar schemas y
namespaces.
Define los mensajes de forma detallada mediante las restricciones de los schemas XSD
De esta forma podrás validar los mensajes a nivel de XML mediante el api XML u OXM que uses, sin
necesidad de implementar código propio.
Crea tipos y elementos globales
A la hora de diseñar el schema XSD, (a nivel raíz) para poder reutilizarlos, tanto a nivel de
elementos XML como clases del lenguaje de implementación del servicio web.
Envío de ficheros adjuntos
www.learning.es
Si necesitas enviar ficheros adjuntos (attachments), hazlo a nivel de http attachment y no como un
elemento del mensaje XML.
Automatización
Automatizaremos el proceso de generar el Skeleton y las clases OXM de mensajes del servicio web a
partir del WSDL (wsdl2code).
Programar tus tests a nivel de la clase Skeleton 29
Para realizar pruebas unitarias del servicio web no necesitas desplegarlo. Ahorraras mucho tiempo y
ya desplegarás para las pruebas de integración o alguna demo.
Guarda log
El de los mensajes de entrada y salida junto con datos del cliente (ip, usuario), a nivel de fichero o
base de datos.
Organizando los archives WSDL (Web Services Definition Language)
WSDL es un archivo XML estándar utilizado para describir totalmente un servicio web
 Los archivos WSDL pueden publicarse en un registro UDDI para simplificar su distribución
 La mayoría de las herramientas de desarrollo permiten crear un cliente para un servicio a partir
del archivo WSDL que lo describe.
Un archivo WSDL está dividido en cuatro secciones que representan:

 El protocolo (HTTP, JMS, etc.), ubicación del servicio y características del mensaje SOAP
 Las operaciones soportadas por el servicio web
 Los mensajes que intercambian cliente y métodos del servicio web al invocar el servicio
 La estructura de los datos incluidos en los mensajes, descritos usando XML-Schema
Los archivos WSDL pueden contener hasta cuatro partes
<definitions>
<types>
Si se intercambian tipos complejos, estos se definen en esta sección y
son referenciados por los mensajes. Un mismo tipo puede ser
referenciado por múltiples mensajes.
</types>
<message>
Un mensaje es la estructura de datos enviado a o regresado por un
servicio. Un mensaje puede ser usado por múltiples ports, por lo que
el resultado de un servicio puede ser el input de otro servicio.
</message>
www.learning.es
<portType>
Es en esta sección en la que se describen todas las operaciones del
servicio web con referencias a los mensajes de entrada y salida
enviados y recibidos por cada operación.
</portType>
<binding>
Esta sección define el formato del mensaje SOAP así como los
protocolos de transporte soportados para accesar el servicio 30
</binding>
</definitions>
Ejemplo de un archivo WSDL incompleto

<message name="romanNumber">
<part name="term" type="xs:string"/>
</message>
<message name="decimalNumber">
<part name="value" type="xs:nonNegativeInteger"/>
</message>
<portType name="romanNumbers">
<operation name="romanToDecimal">
<input message="romanNumber"/>
<output message="decimalNumber"/>
</operation>
<operation name="decimalToRoman">
<input message="decimalNumber"/>
<output message="romanNumber"/>
</operation>
</portType>
Sección de binding para el anterior archivo WSDL

<binding type="romanNumbers" name="rn">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/
http" />
<operation>
<soap:operation soapAction="http://ejemplos.com/ejer"/>
<input>
<soap:body use="literal"/>
</input>
<output>
</output>
</operation>
<operation>
<soap:operation soapAction="http://ejemplos.com/ejer"/>
<input>
</input>
<output>
</output>
</operation>
</binding>
www.learning.es
Ver Video: Diseñando WS, en la Unidad 2, en el Módulo 8,
en la plataforma elearning
Laboratorio: Buenas prácticas para desarrollar servicios web SOAP.

31
Objetivo
Desarrollar un proyecto Web Service y consumirlo desde un proyecto Java Application.
Enunciado
- Realizar un Servicio Web cuya funcionalidad será convertir Monedas.
- Podremos convertir entre diversas monedas a euros y viceversa, de euros a monedas.
- Las Monedas que vamos a convertir son:
 DOLAR = 1,26201 Euros
 PESOS = 14,4762 Euros
 RUPIAS = 75,6061 Euros
 YENES = 135,861 Euros
 PESETAS = 166,386 Euros
Creación servicio web monedas:

Crear dos métodos en el servicio web como se muestra en la imagen:
El código que nos generará será el siguiente:

//Declaramos un array con el valor de cada una de las monedas.
public double[] valores=new double[] {1.26201, 14.4762, 75.6061, 135.861, 166.386};
@WebMethod(operationName = "convertirMonedaEuro")
public Double convertirMonedaEuro(@WebParam(name = "valor")
double valor, @WebParam(name = "indice")
int indice) {
return (valor * valores[indice]);
}
@WebMethod(operationName = "convertirEuroMoneda")
www.learning.es
public Double convertirEuroMoneda(@WebParam(name = "valor")
int indice) {
}
Consumo web service:

32
Ejemplo prueba conversión de monedas
{

}
Actividades
www.learning.es
Unidad 3. Manejando Excepciones en los
Servicios Web
33
Introducción
Una excepción es una condición que interrumpe el flujo normal de operaciones dentro de un
programa. Imagina una excepción como una condición de error, un error de programación
inesperado, como una división entre cero o un posible error que ocurra en tiempo de ejecución,
como un "disco completo" mientras escribe un archivo. Cuando ocurre una excepción, el flujo normal
de instrucciones se rompe. En concreto, se lanza la excepción y el flujo continua en el punto en el
que se capturó la excepción. Al arrojarse la excepción se permite la eliminación del código
controlador de excepciones del flujo regular de operaciones. Si la condición anormal no se controla
adecuadamente, pueden aparecer resultados incorrectos u otras condiciones anormales.
La diferencia entre un buen desarrollo de software y un mal desarrollo de software es a menudo la

forma en que los errores y problemas se manejan. Es mucho más fácil tratar con los procesos en
que todo está funcionando adecuadamente de lo que es lidiar con los fracasos. Los lenguajes de
programación estructurados y orientado a objetos proporcionan un montón de técnicas para el
manejo de errores. En Java, los métodos que suelen producir una excepción que indica que algo
raro ha ocurrido. Un buen software se escribe para esperar ciertos tipos de errores, y está dispuesta
a tomar las medidas oportunas. En la terminología de SOAP, estos inusuales o circunstancias
excepcionales, se llaman fallos. Los fallos se producen cada vez que un método de servicio no es
capaz de procesar los parámetros de entrada y devuelven resultados correctamente. Hay infinitas
razones por que esto puede ocurrir. Los problemas comunes que resultan en fallos son el paso de
parámetros a los métodos, problemas de fondo, y con formato incorrecto mensajes de petición
SOAP. En esta unidad veremos los mecanismos para la generación y el tratamiento de fallos en
SOAP.
Objetivos
 Manejar excepciones en servicios web.
 Conocer las excepciones relacionada con los servicios web.
 Utilizar clases de excepciones predefinidas en servicios web.
Tipos de excepciones con servicios web

Las excepciones podrían ser lanzadas dentro de un servicio Web por diversas razones. Los posibles
tipos de excepciones que puedan ser lanzados son RuntimeException, RemoteException,
SOAPFaultException y excepciones definidas por el usuario.
El desarrollador de servicios Web podría intentar lanzar una RuntimeException como
NullPointerException o ArrayIndexOutOfBoundsException dentro del servicio Web. Pero,
www.learning.es
RuntimeException lanzar dentro del servicio Web se considera un ejercicio malo porque
RuntimeException siempre se convertirá en RemoteException en el lado del cliente. Mientras que el
cliente está esperando a coger el RuntimeException después de invocar un servicio Web, recibirá
sólo el RemoteException en lugar de RuntimeException. Finalmente, no puede realizar un correcto
manejo de RuntimeException.
El problema con el lanzamiento de RemoteException es que las bibliotecas de cliente secundarios
diferentes a interpretar esta excepción en formas diferentes. No es portátil.
34
SOAPFaultException
La excepción SOAPFaultException representa lo errores producidos por SOAP 1.1 o 1.2.

Un SOAPFaultException envuelve un SAAJ SOAPFault que administra la representación SOAP
específica de errores. El método createFault de javax.xml.soap.SOAPFactory puede utilizarse para
crear una instancia de javax.xml.soap.SOAPFault para uso con el constructor. SOAPBinding contiene
un descriptor de acceso para los SOAPFactory utilizado por la instancia de enlace.
Tenga en cuenta que el valor de getFault es la única parte de la excepción que se utiliza cuando se
realiza un error de SOAP.
La excepción que proceda la aplicación de servicio Web podría lanzar es SOAPFaultException. El
SOAPFaultException consta de cuatro partes: faultcode, faultstring, el actor, y el detalle. Esta
excepción le puede dar la información completa acerca de la condición de error. El faultcode le
puede decir si el error que ha sucedido a causa de el servidor, cliente, o algo más. Por ejemplo,
cuando un cliente no proporciona la información de seguridad, tales como nombre de usuario y
contraseña en el HTTP / encabezado SOAP, pero los mandatos servicio de ellos, la lógica de
tratamiento previo en la implementación del servicio, obviamente, podría desencadenarse una
excepción de autenticación. Este tipo de error es considerado como un error del cliente. El
faultstring contiene la descripción correspondiente de la condición de error que ha sucedido. Este
mensaje de cadena es legible por humanos y el desarrollador puede depurar el problema con la
ayuda de la misma. El elemento de detalle contiene el mensaje de excepción real y su completo
seguimiento de la pila. En realidad, el elemento de detalle es una instancia de la clase
javax.xml.soap.Detail y se pueden crear utilizando el API javax.xml.soap.SOAPFactory.createDetail
().
Ejemplo de control de Excepción SOAPFaultException

Creación del servicio
Abrir NetBeans y elegir un proyecto nuevo de tipo aplicación web.
www.learning.es
35
Seleccionamos usar el proyecto con Apache Tomcat
Y por último, no seleccionamos ningún Framework.
Agregamos a nuestro proyecto un archivo de tipo Web Service. Botón derecho sobre nuestro
proyecto WSSumando y elegimos File, new y Web Service.
www.learning.es
36
Indicamos que lo guarde en el paquete ControlExcepciones.
Añadimos tres operaciones al servicio como se muestra en el diseñadores de WebService:
El código que incluiremos en los tres métodos que compone nuestro WebService, serán operaciones
para sumar, restar y multiplicar dos números introducidos como parámetros.
package ControlExcepciones;
www.learning.es
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
@WebService()
public class WSSumador {
@WebMethod(operationName = "sumar", action = "sumar") 37
public int sumar(@WebParam(name="a") int a, @WebParam(name="b") int b)
{
return a + b;
}
@WebMethod(operationName = "restar", action = "restar")
public int restar(@WebParam(name="a") int a, @WebParam(name="b") int b)
{
return a - b;
}
@WebMethod (operationName = "multiplicar")
public int multiplicar (@WebParam(name="x") int a, @WebParam(name="b") int b)
{
return a * b;
}
}
Consumir el servicio
Creamos un proyecto web con NetBeans y los llamamos ConsumirWsSumador.
Seleccionamos el servidor Apache Tomcat.
www.learning.es
38
Dejamos sin seleccionar Framework.
Añadiremos a nuestro proyecto web un archivo de tipo Web Service Client, nos pedirá el Web
Sevrvice al que nos queremos conectar; pulsaremos sobre la opción proyect, examinaremos y
seleccionaremos el Web Service WSSumador.
El archivo WSDL que generará:

<?xml version='1.0' encoding='UTF-8'?><definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
www.learning.es
wssecurity-utility-1.0.xsd" xmlns:wsp_
="http://www.w3.org/ns/ws-policy"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" _
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" _
xmlns:tns="http://ControlExcepciones/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" _
xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://ControlExcepciones/" _
name="WSSumadorService"> 39
<types>
<xsd:schema>
<xsd:import namespace="http://ControlExcepciones/"
schemaLocation="http://localhost:8084/WSSumador/WSSumador?xsd=1" />
</xsd:schema>
</types>
<message name="sumar">
<part name="parameters" element="tns:sumar" />
</message>
<message name="sumarResponse">
<part name="parameters" element="tns:sumarResponse" />
</message>
<message name="restar">
<part name="parameters" element="tns:restar" />
</message>
<message name="restarResponse">
<part name="parameters" element="tns:restarResponse" />
</message>
<message name="multiplicar">
<part name="parameters" element="tns:multiplicar" />
</message>
<message name="multiplicarResponse">
<part name="parameters" element="tns:multiplicarResponse" />
</message>
<portType name="WSSumador">
<operation name="sumar">
<input wsam:Action="sumar" message="tns:sumar" />
<output wsam:Action="http://ControlExcepciones/WSSumador/sumarResponse"
message="tns:sumarResponse" />
</operation>
<operation name="restar">
<input wsam:Action="restar" message="tns:restar" />
<output wsam:Action="http://ControlExcepciones/WSSumador/restarResponse"
message="tns:restarResponse" />
</operation>
<operation name="multiplicar">
<input wsam:Action="http://ControlExcepciones/WSSumador/multiplicarRequest"
message="tns:multiplicar" />
<output wsam:Action="http://ControlExcepciones/WSSumador/multiplicarResponse"
message="tns:multiplicarResponse" />
</operation>
</portType>
<binding name="WSSumadorPortBinding" type="tns:WSSumador">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="sumar">
<soap:operation soapAction="sumar" />
<input>
<soap:body use="literal" />
</input>
www.learning.es
<output>
</output>
</operation>
<operation name="restar">
<soap:operation soapAction="restar" />
<input>
<soap:body use="literal" /> 40
</input>
<output>
</output>
</operation>
<operation name="multiplicar">
<soap:operation soapAction="" />
<input>
</input>
<output>
</output>
</operation>
</binding>
<service name="WSSumadorService">
<port name="WSSumadorPort" binding="tns:WSSumadorPortBinding">
<soap:address location="http://localhost:8084/WSSumador/WSSumador" />
</port>
</service>
</definitions>
Agregaremos una página html a nuestro proyecto para que el usuario introduzca en dos cajas de
texto los parámetros a pasar a los métodos del WebService.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title></title>
</head>
<body>
<h1>Control de excepciones en WebServices</h1>
www.learning.es
<form name="form1" action="resultado.jsp">
<input type="text" name="caja1" size="3"/>+
<input type="text" name="caja2" size="3"/>=
<input type="submit" value="Enviar"/>
</form>
</body>
41
Al pulsar sobre el botón de submit, llamaremos una página jsp que será la encargada de recoger los
valores introducidos en las dos cajas de texto y consumir el método sumar de nuestro Web Service.
Al solicitar el Web Service, comprobaremos como estamos controlando la excepción
SOAPFaultException, ésta exception se puede producir habitualmente en el consumo de servicios
web si se produce un error al intentar autenticarnos, realizar solicitudes,…
<%@page contentType="text/html" pageEncoding="UTF-8"

import="javax.xml.rpc.soap.SOAPFaultException"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>JSP Page</title>
</head>
<body>
<h1>RESULTADO: </h1>
<%
try{
int a = Integer.parseInt(request.getParameter("caja1"));
int b = Integer.parseInt(request.getParameter("caja2"));
controlexcepciones.WSSumadorService service = new

controlexcepciones.WSSumadorService();
controlexcepciones.WSSumador port = service.getWSSumadorPort();
out.println(port.sumar(a, b));
} catch (SOAPFaultException se) {
out.println("Fallo de autenticación");
out.println("");
out.println(se);
}
www.learning.es
%>
</body>
</html>
Excepciones predefinidas en servicios web

Aunque SOAPFaultException da la información necesaria que se necesita para depurar el problema,
el cliente de servicio Web puede que quiera realizar algo más con el error que se ha producido. La 42
opción que disponemos es tener una descripción de texto configurables y dinámica del error que se
produjo. La otra posibilidad podría ser la de contar con el apoyo de internacionalización de los
mensajes de error. Al proporcionar la descripción de texto en idiomas distintos del Inglés, se podría
tratar de responder a las necesidades de todos los grupos de personas. La lista puede crecer más y
más.
Para lograr los objetivos podríamos recurrir a una excepción definida por el usuario con un formato
específico que fuera lanzado en el servicio. La excepción definida por el usuario lanzado dentro del
servicio Web está mapeada en el elemento wsdl: fallo en el Web Services Description Language
(WSDL) del servicio web. Se podía ver el elemento de culpa como uno de los elementos secundarios
del elemento de operación de la portType. Los otros dos elementos secundarios de la operación son
de entrada y salida.
El elemento fault, define el formato de resumen del mensaje de error que pueden ser lanzados por
el servicio Web.
El elemento wsdl:messages relativos a WSDL:fault sólo puede contener una parte del mensaje, y la
parte del mensaje podría ser un XMLType complexType o simple.
En el siguiente ejemplo incluimos una excepción definida por el usuario, MyCustomException, se
dedicará a manejar mejor los mensajes de error. El MyCustomException contiene un mensaje de
error apropiado que es como se define en la definición WSDL. El mensaje de error contiene las tres
partes siguientes:
Código de error, que contiene una de cinco letras identificativo y un identificador de tres dígitos
Por ejemplo, GENEX001 podría significar un error genérico, mientras que AUTEX001 podría significar
un error de autenticación.
Texto descriptivo del error, incluyendo variables de sustitución (mencionado como {0}, {1}, y así
sucesivamente)
Por ejemplo, la descripción de texto correspondiente Código de error GENEX001 será algo así como
"El número que ha introducido es {0}."
Una lista de valores correspondientes a las variables de sustitución se define en el texto anterior.
Por ejemplo, para el caso anterior, la lista de variables que contienen un solo valor (por ejemplo 1)
porque la descripción del texto anterior contiene sólo una variable de sustitución.
Después de procesar el texto usando la lógica pertinentes, la descripción del texto final sería "El
número que ha introducido es 1."
Los fallos pueden ser identificados, utilizando el código de error, sin necesidad de aplicaciones, y
además se podrá comprender el independientemente del idioma.
La descripción del texto se puede definir en muchos idiomas, y las variables correspondientes se
pueden colocar en consecuencia de manera independiente del lenguaje.
Los servicios web ofrecen soporte de internacionalización.
Las excepciones lanzadas deben usar la anotación javax.xml.ws.WebFault
name: nombre en wsdl.
targetNamespace. Espacio de nombres en wsdl.
www.learning.es
Por la forma en la que JAX-WS define el mapping de Exceptions java a WSDL y viceversa, es
conveniente que las Excepciones utilizadas cumplan las siguientes reglas:
La información encapsulada en la Excepción debe ir en un objeto separado.
Este objeto debe ser obtenido a través del método getFaultInfo.
De esta forma, las excepciones lanzadas por los stubs del cliente serán iguales que las usadas en el
servicio.
43
Ejemplo de servicio web con manejo de excepciones

Este servicio tiene dos entradas: int numero y el mensaje de cadena. Si el número es 1,se lanzará
un SOAPFaultException. Si el número es 2, MyCustomException será lanzado, de lo contrario, el
método devolverá éxito.
package nuevo;
import javax.xml.soap.SOAPException;
import javax.xml.soap.SOAPFactory;
import javax.xml.soap.Detail;
public class NewWebService{
public String echo(int number, String message)
throws MyCustomException{
System.out.println("Numero: "+number+", Mensaje: " + message);
switch(number){
case 2:
throw new MyCustomException(
"GENEX001",
"El número que ha introducido es {0}",
new String[]{String.valueOf(number)}
);
case 1:
Detail detail = null;
try{
detail = SOAPFactory.newInstance().createDetail();
//añadir mensajes de error
detail.addTextNode(
"Opción SOAPFaultException");
}catch(SOAPException ex){
throw new MyCustomException(
"SEREX001",
"Error al crear el elemento",
new String(){});
}
throw new javax.xml.rpc.soap.SOAPFaultException(
new javax.xml.namespace.QName("env.Server"),
"El número que ha introducido es "+number,
"NO ACTOR",
detail);
}
return "SUCCESS";
}
}
www.learning.es
Excepciones personalizadas en Servicios Web
En Java podemos crear una excepción propia creando una clase que extienda de la clase Exception.
En este ejemplo creamos una exception llama OpcionErroneaException que hereda de la clase
exception.
public class OpcionErroneaException extends Exception{
public OpcionErroneaException(){ 44
}
public String mensaje(){
return("OPCION ERRONEA");
}
}
Podemos crear una clase en Java que lance la excepción creada por el programador.
public class LeerDatos3{

public static void main(String args[]) throws IOException{
BufferedReader teclado=new BufferedReader(new InputStreamReader(System.in));
String numero="";
String continua="";
try{
do{
System.out.println("Introduzca un numero:");
numero=teclado.readLine();
int num=Integer.parseInt(numero);
if (num%2==0){
System.out.println("El numero: "+ num +" es par");
}else{
System.out.println("El numero: "+ num +" es impar");
}
System.out.println("¿Desea continuar (s/n)?");
continua= teclado.readLine();
if(!continua.equals("s") && !continua.equals("n")){

throw new OpcionErroneaException();
}
}while (continua.equals("s") || continua.equals("S"));
//Para compara se pone .equals
}catch (NumberFormatException e){

System.out.println("Debe introducir numeros");
}catch (OpcionErroneaException e){
System.out.println(e.mensaje());
teclado.readLine();
}
}
}
Dentro de los Web Service también podemos hacer uso de la creación de excepciones propias.
Podríamos crear una excepción propia con un esqueleto como el que mostramos a continuación:
public class ErrorWebService extends Exception
www.learning.es
{
public ErrorWebService (String code)
{
}
public String getA() {...}
public void setA() {..}
public String getB() {...}
public void setB() {..} 45
}
Podemos lanzarlo desde el Web Service como en el siguiente ejemplo:
@WebService
public class MyWS
{
public MyWS()
{
}
public Response getSomething(String id) throws ErrorWebService
{
throw new ErrorWebService (id);
}
}
Ver Video: Excepciones WebServices , en la Unidad 3,

Laboratorio: Excepciones WebServices
Objetivos
 Crear un proyecto Java Application que nos permita consumir el Web Service del Catastro.
 Controlaremos las posibles excepciones que se produzcan al consumir el servicio.
Enunciado
Abrir un proyecto Java Application para poder consumir el servicio web del catastro ubicado en la
siguiente dirección:
https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCallejero.asmx?WSDL
www.learning.es
46
1. Crear un proyecto Java Application y llamarlo ConsumirServicioWebCatastro.
2. Agregar un nuevo elemento de tipo Web Service Client.
3. Añadir la dirección al servicio web del catastro.
www.learning.es
47
4. Incluir la llamada a los métodos del servicio.
5. Selecccionar el método ObtenerProvincias que es el que queremos invocar.
6. Llamar al método obtenerProvincias que nos genera desde el main.

package consumirserviciowebcatastro;
public class Principal {
/**
* @param args the command line arguments
*/
Provincias p=obtenerProvincias();
}
www.learning.es
private static Provincias obtenerProvincias() {
consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrónicaX0020DelX0020
Catastro service = new_
Catastro(); 48
CatastroSoap port =_
service.getCallejeroX0020DeX0020LaX0020SedeX0020ElectrónicaX0020DelX0020CatastroSoap12();
return port.obtenerProvincias();
}
}
7. Si el servicio web está caído obtendremos el siguiente error.
8. Controlaremos el error para avisar al usuario.

package consumirserviciowebcatastro;
public class Principal {
/**
*/
try{
Provincias p=obtenerProvincias();
}catch(javax.xml.ws.WebServiceException e){
System.out.println("Web Service detenido");
}
}
private static Provincias obtenerProvincias() {
Catastro service = new _
Catastro();
CatastroSoap port = _
service.getCallejeroX0020DeX0020LaX0020SedeX0020ElectrónicaX0020DelX0020CatastroSoap12();
return port.obtenerProvincias();
}
www.learning.es
49
Actividades
www.learning.es
Unidad 4. Seguridad en los Servicios Web
Introducción
Hoy en día, considerar la tecnología de web services sin considerar los aspectos de seguridad es algo
inconcebible, sobre todo si se trata de comunicación de información referida a lógica de negocios,
donde la información debe ser confiable y segura. 50
A su vez, varios aspectos surgidos desde el mismo momento de la concepción de la tecnología de

web services deben ser mantenidos al momento de la incorporación de algún mecanismo de
seguridad, como ser por ejemplo de su sencillez y de la interoperabilidad entre plataformas y
fabricantes.
Con esto en mente surge WS-*. Parte importante de este conjunto de especificaciones está
directamente vinculada a la seguridad en web services, siendo WS-Security quizá la piedra
fundamental de las demás, ya que las demás especificaciones o bien complementan o bien
extienden los mecanismos definidos en WS-Security.
Objetivos
 Describir requerimientos y soluciones en seguridad de servicios web.
 Entender los tipos de protecciones de un servicio web.
WS-Security
WS-Security define extensiones a SOAP que permiten el pasaje de security tokens los cuales
identifican y autentifican a los clientes de los servicios. De esta forma se puede asegurar la
integridad de los mensajes y la confidencialidad de los mismos; entendiendo como integridad al
hecho de que los mensajes enviados se mantengan inalterados durante la transmisión, y como
confidencialidad al hecho de que ningún agente externo a la comunicación pueda obtener de
ninguna forma el contenido del mensaje (problema conocido como “man-in-the-middle”).
WS-Security define y estandariza la forma de uso de mecanismos de seguridad ya existentes,

adaptándolos a su funcionamiento con los mensajes SOAP. Quizás lo más fundamental que define
WS-Security es el elemento que se embebe en el encabezado del mensaje SOAP. La
estructura de un mensaje SOAP que incluye este elemento se muestra en el ejemplo 1, a
continuación:
<?xml version="1.0" encoding="utf-8"?>

<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<s:Header>
<wsse:Security>
•••
</wsse:Security>
</s:Header>
<s:Body>
•••
</s:Body>
</s:Envelope>
La especificación define asimismo como enviar security tokens, ya sea un username token, un
certificado X.509 o un ticket Kerberos, por nombrar los más conocidos y utilizados actualmente.
www.learning.es
El principal problema que enfrenta el receptor de un mensaje es saber quien es
exactamente el que le está realizando el pedido. Existen varias formas de verificar la identidad del
cliente: con un username token, se debe proveer una pareja usuario/contraseña correcta; un ticket
kerberos está encriptado, y el receptor del mensaje puede verificar que es correcto.
51
WS-Security es extremadamente flexible en el hecho de no definir que tipo de security tokens
utilizar; sin embargo no lo es en lo siguiente: dos sistemas pueden conformar WS-Security, pero
igualmente ser incapaces de comunicarse entre sí. Un sistema por ejemplo podría llegar a aceptar
solamente tickets Kerberos, mientras que el otro aceptar solamente certificados X.509, por ejemplo,
por lo que solamente WS-Security no alcanza. Este tipo de problemas son los que intentan atacar
WS-SecurityPolicy y WS-Trust.
WS-SecurityPolicy
Siempre que se utilicen mecanismos de seguridad, en cualquier ámbito, debe existir algún tipo de
políticas de seguridad; una cosa va de la mano con la otra. Estas políticas clarifican los requisitos de
seguridad específicos en una situación particular. Supongamos por ejemplo un servicio web
utilizando WS-Security, se deben definir claramente ciertos aspectos con el fin de que un cliente
pueda comunicarse efectivamente con el servicio. Aspectos como: que tipo de security tokens
acepta, que algoritmo de encriptación se utilizó para encriptar el mensaje, etc., deben estar
claramente definidos por el servicio. Para definir estos aspectos es que se utilizan las políticas.
La especificación WS-Policy define una aproximación general para la especificación de todo tipo de
políticas para los servicios web. Basándose en esto, WS-SecurityPolicy define una sintaxis XML para
especificar políticas relacionadas con la seguridad. Esta sintaxis define elementos denominados
assertions; que permiten a un servicio web especificar sus políticas en una forma no ambigua.
Las assertions definidas por WS-SecurityPolicy incluyen las siguientes:
Permiten a un web service especificar que tipos de security tokens aceptará, y, opcionalmente, de
quien permitirá que procedan.
Permite a un web service especificar varias opciones sobre las firmas digitales que aceptará.
Permite a un web service especificar opciones sobre como la encriptación se realizará, como por
ejemplo que algoritmo de encriptación se utilizará.
Permite a un web service especificar que ciertas partes de un mensaje no deben estar encriptadas, y
cuales son esas partes.
www.learning.es
La forma exacta de cómo las políticas son transportadas desde el servicio al cliente interesado no se
define en WS-SecurityPolicy. Las assertions pueden ser enviadas en un mensaje SOAP o entregado
de cualquier otra forma. WS-Policy define un elemento general, , que puede contener una o
más assertions para las políticas.
El elemento puede contener políticas sobre security tokens, integridad,
confidencialidad y otras cosas.
52
A continuación se pasa a detallar la especificación de WS-Trust, objetivo principal del presente
documento.
WS-TRUST
WS-Security define las bases para proveer seguridad al intercambio de mensajes SOAP.
WS-Trust utiliza estas bases o mecanismos y define primitivas adicionales y
extensiones para el intercambio de security tokens para permitir la obtención y
diseminación de credenciales entre distintos dominios de confianza.
Para asegurar la comunicación entre dos partes, las mismas deben intercambiar credenciales de
seguridad, ya sea directa como indirectamente. Para que el intercambio funcione correctamente,
cada una de las partes debe poder determinar si pueden confiar en las credenciales de la otra parte.
El objetivo principal de WS-Trust es habilitar a las distintas aplicaciones a construir intercambios
confiables de mensajes. La confianza es representada a través del intercambio e intermediación de
security tokens. La especificación provee una forma para solicitar, renovar y validar estos security
tokens.
WS-Security, WS-SecurityPolicy y WS-Trust son los cimientos fundamentales para el modelo de

Federación de servicios, definido en WS-Federation, que queda fuera del alcance de este documento.
Web Services Trust Model

El modelo de seguridad en web services definido en WS-Trust está basado en un proceso en el cual
un servicio puede requerir que todo pedido que se le haga cumpla con un conjunto de claims. Si el
pedido viene sin los claims requeridos, se debe rechazar o ignorar el mismo. La manera que tiene un
servicio de indicar cuales son los claims requeridos es mediante políticas de seguridad definidas
sobre el propio servicio.
Si el cliente no tiene el(los) token(s) necesarios para cumplir los requisitos de seguridad indicado
por el servicio en sus políticas, el mismo puede contactar a las autoridades apropiadas y solicitar los
tokens necesarios. Estas autoridades se indican en la política del servicio, y son llamadas Security
Token Services(STS).
Los STS a su vez tienen definidas sus propias políticas de seguridad, y el cliente debe cumplirlas
para realizar el pedido de security tokens.
La figura que se muestra a continuación muestra que cualquier servicio puede ser un cliente, y a su
vez que el STS es un Web Service. Las flechas muestran posibles vías de comunicación; el cliente
(requestor) puede obtener un token del STS o puede haberlo obtenido por otro medio.
www.learning.es
53
Se tiene un servicio web, el cual tiene definida ciertas políticas de seguridad. Dichas políticas
establecen que para realizar un pedido al servicio, es necesario que en el pedido haya un security
token, pero que además este token esté firmado por un STS determinado, con el cuál el servicio
tiene una relación de confianza previamente establecida de alguna forma.
El cliente debe solicitar al STS indicado el o los security tokens indicados en la política del servicio.
Para esto, el cliente debe enviar las claims apropiadas al STS, el cual define cuales son en su propia
política de seguridad. El STS verifica que los claims sean validos, y de así serlo, envía el token
solicitado en mensaje de respuesta.
Finalmente, el cliente envía el pedido al servicio, con el token recibido (firmado por el STS). Como el
servicio confía en el STS, valida el pedido del cliente.
Relaciones de confianza
Existen varios mecanismos que pueden ser utilizados para verificar las relaciones de confianza de un
servicio. Estos mecanismos no son obligatorios y no son requeridos por WS-Trust. O sea, los
servicios son libres de verificar las relaciones de confianza y de establecer las mismas sobre un
dominio o extender las mismas hacia otros dominios mediante cualquier mecanismo.
WS-Trust define los siguientes mecanismos:
Fixed Trust Roots: El más simple de todos. El servicio (más específicamente la “trust engine” del
servicio) contiene una lista de todas sus relaciones de confianza. Si los tokens vienen de un servicio
perteneciente a esta lista, el servicio los utiliza.
Trust Hierarchies: El servicio confiará en los tokens siempre y cuando provengan de una jerarquía
de confianza que lleve a un “trusted root”.
Authentication Service: Este es un servicio especial con el cual el servicio mantiene una relación de
confianza. Cuando el servicio recibe un token, lo envía directamente a este servicio, que es el que va
a decidir si es de confianza o no.
Security Token Service
A continuación se explica el funcionamiento de los STS en un escenario WS-Trust.
Un cliente realiza un pedido de un security token al STS; si la política y los requerimientos del STS
se cumplen, el cliente recibe un security token response.
Este proceso utiliza los siguientes dos elementos: para solicitar al STS un
security token y para la respuesta del STS al cliente.
El elemento (RST) debe estar firmado por el que realiza el pedido, utilizando
tokens contenidos o referenciados en el propio pedido.
La sintaxis del elemento se muestra en el siguiente ejemplo:
<wst:RequestSecurityToken Context="...">
www.learning.es
<wst:TokenType>
...
</wst:TokenType>
<wst:RequestType>
...
</wst:RequestType>
...
</wst:RequestSecurityToken> 54
Como ya se dijo, el elemento es utilizado para

enviar una respuesta a un pedido de un security token.
En general, el token retornado por el STS al cliente que realizó el pedido, no será modificado de
ninguna forma por el cliente. Si puede llegar a ser incluida otra información respecto al security
token, como ser el tiempo de vida, etc..
La sintaxis de este elemento se muestra a continuación:
<wst:RequestSecurityTokenResponse Context="...">
<wst:TokenType>
...
</wst:TokenType>
<wst:RequestedSecurityToken>
...
</wst:RequestedSecurityToken>
...
</wst:RequestSecurityTokenResponse>
Técnicas criptográficas y las firmas digitales

Firmas digitales
DSA y DSS
El DSA (Digital Signature Algorithm o Algoritmo Estándar de Firmado) es el algoritmo de firmado
digital incluido en el DSS (Digital Signature Standard o Estándar de Firmas Digitales) del NIST
Norteamericano. Se publicó en 1994.
El DSA está basado en el problema de los logaritmos discretos y sólo puede emplearse para las
firmas digitales (a diferencia del RSA, que también puede emplearse para encriptar). La elección de
este algoritmo como estándar de firmado generó multitud de críticas: se pierde flexibilidad respecto
al RSA (que además, ya era un estándar de hecho), la verificación de firmas es lenta, el proceso de
elección fue poco claro y la versión original empleaba claves que lo hacían poco seguro.
El algoritmo es más rápido para generar la firma que para validarla, al revés de lo que sucede con el
RSA. Emplea claves de 1024 bits (originalmente eran 512 bits, pero se aumento por falta de
seguridad). No se conocen ataques eficientes contra este algoritmo, sólo existen problemas con un
conjunto de números primos, pero son fácilmente evitables si se siguen los sistemas adecuados de
generación de claves.
Certificados digitales
Los certificados digitales son el equivalente digital del DNI, en lo que a la autentificación de
individuos se refiere, ya que permiten que un individuo demuestre que es quien dice ser, es decir,
que está en posesión de la clave secreta asociada a su certificado.
Para los usuarios proporcionan un mecanismo para verificar la autenticidad de programas y
documentos obtenidos a través de la red, el envío de correo encriptado y/o firmado digitalmente, el
control de acceso a recursos, etc.
www.learning.es
En este apartado explicaremos qué son los certificados digitales, cuales son los formatos estándar,
como podemos controlar sus periodos de validez o anularlos si se ven comprometidos, quien los
genera y las infraestructuras necesarias para soportarlos.
Un certificado de clave pública es un punto de unión entre la clave pública de una entidad y uno o
más atributos referidos a su identidad. El certificado garantiza que la clave pública pertenece a la
entidad identificada y que la entidad posee la correspondiente clave privada.
Los certificados de clave pública se denominan comúnmente Certificado Digital, ID Digital o 55
simplemente certificado. La entidad identificada se denomina sujeto del certificado o subscriptor (si
es una entidad legal como, por ejemplo, una persona).
Los certificados digitales sólo son útiles si existe alguna Autoridad Certificadora (Certification
Authority o CA) que los valide, ya que si uno se certifica a sí mismo no hay ninguna garantía de que
su identidad sea la que anuncia, y por lo tanto, no debe ser aceptada por un tercero que no lo
conozca.
Es importante ser capaz de verificar que una autoridad certificadora ha emitido un certificado y
detectar si un certificado no es válido. Para evitar la falsificación de certificados, la entidad
certificadora después de autentificar la identidad de un sujeto, firma el certificado digitalmente.
Los certificados digitales proporcionan un mecanismo criptográfico para implementar la
autentificación; también proporcionan un mecanismo seguro y escalable para distribuir claves
públicas en comunidades grandes.
Certificados X.509
El formato de certificados X.509 es un estándar del ITU-T (International Telecommunication Union-
Telecommunication Standarization Sector) y el ISO/IEC (International Standards Organization /
International Electrotechnical Commission) que se publicó por primera vez en 1988. El formato de la
versión 1 fue extendido en 1993 para incluir dos nuevos campos que permiten soportar el control de
acceso a directorios. Después de emplear el X.509 v2 para intentar desarrollar un estándar de
correo electrónico seguro, el formato fue revisado para permitir la extensión con campos
adicionales, dando lugar al X.509 v3, publicado en 1996.
Los elementos del formato de un certificado X.509 v3 son:
Versión. El campo de versión contiene el número de versión del certificado codificado. Los valores
aceptables son 1, 2 y 3.
Número de serie del certificado. Este campo es un entero asignado por la autoridad certificadora.
Cada certificado emitido por una CA debe tener un número de serie único.
Identificador del algoritmo de firmado. Este campo identifica el algoritmo empleado para firmar
el certificado (como por ejemplo el RSA o el DSA).
Nombre del emisor. Este campo identifica la CA que ha firmado y emitido el certificado.
Periodo de validez. Este campo indica el periodo de tiempo durante el cual el certificado es válido
y la CA está obligada a mantener información sobre el estado del mismo. El campo consiste en una
fecha inicial, la fecha en la que el certificado empieza a ser válido y la fecha después de la cual el
certificado deja de serlo.
Nombre del sujeto. Este campo identifica la identidad cuya clave pública está certificada en el
campo siguiente. El nombre debe ser único para cada entidad certificada por una CA dada, aunque
puede emitir más de un certificado con el mismo nombre si es para la misma entidad.
Información de clave pública del sujeto. Este campo contiene la clave pública, sus parámetros y
el identificador del algoritmo con el que se emplea la clave.
Identificador único del emisor. Este es un campo opcional que permite reutilizar nombres de
emisor.
www.learning.es
Identificador único del sujeto. Este es un campo opcional que permite reutilizar nombres de
sujeto.
Extensiones.
Las extensiones del X.509 v3 proporcionan una manera de asociar información adicional a sujetos,
claves públicas, etc. Un campo de extensión tiene tres partes:
Tipo de extensión. Es un identificador de objeto que proporciona la semántica y el tipo de
56
información (cadena de texto, fecha u otra estructura de datos) para un valor de extensión.
Valor de la extensión. Este subcampo contiene el valor actual del campo.
Indicador de importancia. Es un flag que indica a una aplicación si es seguro ignorar el campo de
extensión si no reconoce el tipo. El indicador proporciona una manera de implementar aplicaciones
que trabajan de modo seguro con certificados y evolucionan conforme se van añadiendo nuevas
extensiones.
El ITU y el ISO/IEC han desarrollado y publicado un conjunto de extensiones estándar en un
apéndice al X.509 v3:
Limitaciones básicas. Este campo indica si el sujeto del certificado es una CA y el máximo nivel de
profundidad de un camino de certificación a través de esa CA.
Política de certificación. Este campo contiene las condiciones bajo las que la CA emitió el
certificado y el propósito del certificado.
Uso de la clave. Este campo restringe el propósito de la clave pública certificada, indicando, por
ejemplo, que la clave sólo se debe usar para firmar, para la encriptación de claves, para la
encriptación de datos, etc. Este campo suele marcarse como importante, ya que la clave sólo está
certificada para un propósito y usarla para otro no estaría validado en el certificado.
El formato de certificados X.509 se especifica en un sistema de notación denominado sintaxis
abstracta uno (Abstract Sintax One o ASN-1). Para la transmisión de los datos se aplica el DER
(Distinguished Encoding Rules o reglas de codificación distinguible), que transforma el certificado en
formato ASN-1 en una secuencia de octetos apropiada para la transmisión en redes reales.
Listas de Anulación de Certificados (CRLs)
Los certificados tienen un periodo de validez que va de unos meses a unos pocos años. Durante el
tiempo que el certificado es válido la entidad certificadora que lo generó mantiene información sobre
el estado de ese certificado.
La información más importante que guarda es el estado de anulación, que indica que el periodo de
validez del certificado ha terminado antes de tiempo y el sistema que lo emplee no debe confiar en
él. Las razones de anulación de un certificado son varias: la clave privada del sujeto se ha visto
comprometida, la clave privada de la CA se ha visto comprometida o se ha producido un cambio en
la afiliación del sujeto (por ejemplo cuando un empleado abandona una empresa).
Las listas de anulación de certificados (Certification Revocation Lists o CRL) son un mecanismo
mediante el cual la CA publica y distribuye información a cerca de los certificados anulados a las
aplicaciones que los emplean. Una CRL es una estructura de datos firmada por la CA que contiene su
fecha y hora de publicación, el nombre de la entidad certificadora y los números de serie de los
certificados anulados que aun no han expirado. Cuando una aplicación trabaja con certificados debe
obtener la última CRL de la entidad que firma el certificado que está empleando y comprobar que su
número de serie no está incluido en él.
Existen varios métodos para la actualización de CRLs:
Muestreo de CRLs. Las aplicaciones acceden a la CA o a almacenes de archivos y copian el último
CRL a intervalos regulares. La pega de este esquema es que durante el periodo entre actualizaciones
del CRL podemos aceptar un certificado ya anulado, por lo que el periodo debe ser corto.
www.learning.es
Anuncio de CRLs. La entidad certificadora anuncia que ha habido un cambio en el CRL a las
aplicaciones. El problema de este enfoque es el anuncio puede ser muy costoso y no sabemos que
aplicaciones deben ser informadas.
Verificación en línea. Una aplicación hace una consulta en línea a la CA para determinar el estado
de revocación de un certificado. Es el mejor método para las aplicaciones, pero es muy costoso para
la CA.
57
Listas de Anulación de Certificados X.509
El formato de listas de anulación de certificados X.509 es un estándar del ITU-T y la ISO/IEC que se
publicó por primera vez en 1988 como versión 1. El formato fue modificado para incluir campos de
extensión, dando origen al formato X.509 v2 CRL.
Los campos básicos de un formato X.509 CRL (válidos para las versiones 1 y 2) son:
Versión. Debe especificar la versión 2 si hay algún campo de extensión.
Firma. El campo contiene identificador del algoritmo empleado para firmar la CRL.
Nombre del generador. Este campo contiene el nombre de la entidad que ha generado y firmado
la CRL.
Esta actualización. Fecha y hora de la generación de la CRL.
Próxima actualización. Indica la fecha y hora de la próxima actualización. El siguiente CRL puede
ser generado antes de la fecha indicada pero no después de ella.
Certificado del usuario. Contiene el número de serie de un certificado anulado.
Fecha de anulación. Indica la fecha efectiva de la anulación.
Existe también un conjunto de campos de entrada de extensión en las CRLs X.509 v2, como el
código de razón, que identifica la causa de la anulación: sin especificar, compromiso de clave,
compromiso de la CA, cambio de afiliación, superado (el certificado ha sido remplazado), cese de
operación (el certificado ya no sirve para su propósito original), certificado en espera (el certificado
está suspendido temporalmente) y elimina de la CRL (un certificado que aparecía en una CRL previa
debe ser eliminado).
Adicionalmente también se ha añadido un conjunto de extensiones para las X.509v2 CRL con los
mismos subcampos que en los certificados X.509v3. Estas extensiones permiten que una comunidad
o entidad se defina sus propios campos de extensión privados.
Autoridades Certificadoras
Una autoridad certificadora es una organización fiable que acepta solicitudes de certificados de
entidades, las valida, genera certificados y mantiene la información de su estado.
Una CA debe proporcionar una Declaración de Prácticas de Certificación (Certification Practice
Statement o CPS) que indique claramente sus políticas y prácticas relativas a la seguridad y
mantenimiento de los certificados, la responsabilidades de la CA respecto a los sistemas que
emplean sus certificados y las obligaciones de los subscriptores respecto de la misma.
Las labores de un CA son:
Admisión de solicitudes. Un usuario rellena un formulario y lo envía a la CA solicitando un
certificado. La generación de las claves pública y privada son responsabilidad del usuario o de un
sistema asociado a la CA.
Autentificación del sujeto. Antes de firmar la información proporcionada por el sujeto la CA debe
verificar su identidad. Dependiendo del nivel de seguridad deseado y el tipo de certificado se
deberán tomar las medidas oportunas para la validación.
www.learning.es
Generación de certificados. Después de recibir una solicitud y validar los datos la CA genera el
certificado correspondiente y lo firma con su clave privada. Posteriormente lo manda al subscriptor
y, opcionalmente, lo envía a un almacén de certificados para su distribución.
Distribución de certificados. La entidad certificadora puede proporcionar un servicio de
distribución de certificados para que las aplicaciones tengan acceso y puedan obtener los certificados
de sus subscriptores. Los métodos de distribución pueden ser: correo electrónico, servicios de
directorio como el X.500 o el LDAP, etc.
58
Anulación de certificados. Al igual que sucede con las solicitudes de certificados, la CA debe
validar el origen y autenticidad de una solicitud de anulación. La CA debe mantener información
sobre una anulación durante todo el tiempo de validez del certificado original.
Almacenes de datos. Hoy en día existe una noción formal de almacén donde se guardan los
certificados y la información de las anulaciones. La designación oficial de una base de datos como
almacén tiene por objeto señalar que el trabajo con los certificados es fiable y de confianza.
Infraestructuras de Clave Pública

La difusión de las técnicas de clave pública requiere una infraestructura que defina un conjunto de
estándares, autoridades de certificación, estructuras entre múltiples CAs, métodos para descubrir y
validar rutas de certificación, protocolos operacionales, protocolos de gestión, herramientas que
pueden operar entre sí y un marco legislativo.
Los protocolos operacionales se dirigen al problema del envío de certificados y CRLs a los sistemas
que emplean certificados. Los protocolos de gestión tratan de los requisitos para la interacción de
dos componentes de la infraestructura: registro, inicialización, certificación, anulación y recuperación
de claves.
Una estructura entre múltiples CAs proporciona una o más rutas de certificación entre un subscriptor
y una aplicación. Una ruta de certificación (o cadena de certificación) es una secuencia de uno o más
puntos conectados entre el subscriptor y una CA raíz. Una CA raíz es una autoridad en la que confía
la aplicación, ya que tiene almacenada de forma segura su clave pública.
Un sistema que emplea certificados necesita obtener una ruta de certificación entre un subscriptor y
un CA raíz antes de evaluar el nivel de confianza en el certificado del subscriptor. El problema de
determinar una ruta de certificación entre dos subscriptores arbitrarios en una estructura de
interconexiones entre diferentes CAs se denomina descubrimiento de rutas de certificación. El
problema de verificar la asociación entre el nombre del subscriptor y su clave pública en una ruta de
certificación se denomina validación de la ruta de certificación.
Implementar la seguridad en los servicios web

En la siguiente unidad veremos la forma que tenemos de implementar seguridad en un proyecto
creado con el IDE NetBeans.
Abrir un proyecto de tipo Java Web, Web Application.
www.learning.es
59
Llamaremos al proyecto WS_Seguridad.
Seleccionamos como servidor GlassFish.
No seleccionaremos ningún Framework, y por último le daremos a finalizar.
www.learning.es
60
Añadiremos a nuestro proyecto web un archivo de tipo Web Service.
En la caja de texto para introducir el nombre del servicio introduciremos ServicioSeguridad. Guardar
el servicio en el paquete Servicios.
www.learning.es
Añadimos una nueva operación para crear un método llamado mensaje, devolverá un string con un
nombre.
61
Veremos el código que generado, e introducimos un string con el nombre que devolverá el método.
package Servicios;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
@WebService()
public class ServicioSeguridad {
@WebMethod(operationName = "mensaje")
public String mensaje(@WebParam(name = "nombre")
String nombre) {
return "Hola: "+ nombre;

}
}
Anotaciones creadas:
@WebService identifica a la clase como un servicio Web.
Al incluir este descriptor en la clase el editor del netbeans nos avisa que debemos importa la clase
javax.jws.Webservice.
@WebMethod identifica a una operación como parte del servicio web.
Al igual que con WebService se debe importar la clase WebMethod de mismo paquete.
@WebParam asigna un nombre a los parámetros de una operación.
Probaremos el servicio antes de implementar seguridad.

Sobre la carpeta Web Services, seleccionaremos la opción Test Web Service.
www.learning.es
62
Cuando comprobemos que el servicio web desplega bien, comenzaremos con la implementación de
seguridad.
WSDL generado.
<?xml version='1.0' encoding='UTF-8'?><definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-utility-1.0.xsd" _
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" _
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://Servicios/" _
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://Servicios/" _
name="ServicioSeguridadService">
<types>
<xsd:schema>
<xsd:import namespace="http://Servicios/"
schemaLocation="http://localhost:8084/WS_Seguridad/ServicioSeguridad?xsd=1" />
</xsd:schema>
</types>
<message name="mensaje">
<part name="parameters" element="tns:mensaje" />
</message>
<message name="mensajeResponse">
<part name="parameters" element="tns:mensajeResponse" />
</message>
<portType name="ServicioSeguridad">
<operation name="mensaje">
<input wsam:Action="http://Servicios/ServicioSeguridad/mensajeRequest" message="tns:mensaje"
/>
<output wsam:Action="http://Servicios/ServicioSeguridad/mensajeResponse"
message="tns:mensajeResponse" />
www.learning.es
</operation>
</portType>
<binding name="ServicioSeguridadPortBinding" type="tns:ServicioSeguridad">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="mensaje">
<soap:operation soapAction="" />
<input>
<soap:body use="literal" /> 63
</input>
<output>
</output>
</operation>
</binding>
<service name="ServicioSeguridadService">
<port name="ServicioSeguridadPort" binding="tns:ServicioSeguridadPortBinding">
<soap:address location="http://localhost:8084/WS_Seguridad/ServicioSeguridad" />
</port>
</service>
</definitions>
Marcamos la opción de Secure Service en la consola de nuestro servicio.
Seleccionamos la opción avanzadas, para abrir el editor de atributos.
www.learning.es
En la sección de seguridad del servicio, se puede ver que la han seleccionado los siguientes
opciones:
Compatibilidad de la versión. NET 1.0 o 3.0/Metro. 3.5/Metro NET 1.3. Seleccione la última
versión que coincide con la versión de Metro o. NET que tenemos instalado.
Mecanismo de seguridad. Especifica el método utilizado para asegurar el servicio web. En este
caso, la autenticación de usuario con claves simétricas se selecciona. La autenticación de usuario
con claves simétricas protege a la aplicación de la integridad y confidencialidad. la criptografía de 64
clave simétrica se basa en una sola tecla, el secreto compartido que se utiliza para firmar y cifrar un
mensaje. Las claves simétricas son generalmente más rápido que la criptografía de clave pública.
Por este mecanismo, el cliente no posee ningún tipo de certificado / clave de su cuenta, sino que
envía su nombre de usuario / contraseña para la autenticación. El cliente comparte una clave
secreta con el servidor. La clave compartida, se genera en tiempo de ejecución y cifrados con el
certificado del servicio. El cliente debe especificar el alias en el almacén de confianza mediante la
identificación de alias del servidor de certificados.
Usar valores predeterminados para el Desarrollo. Seleccione esta opción para importar
certificados en el almacén de claves del servidor y almacén de confianza, para que puedan ser
utilizados inmediatamente para el desarrollo. Debido a que los certificados por defecto no se
encuentran en un formato adecuado para ser utilizado en este contexto, esta importación se hace
para usted, de modo que usted no tiene que hacerlo manualmente. Además de importar
certificados, un usuario por defecto se crea con nombre de usuario "wsitUser". En un entorno de
producción, es probable que desee ofrecer sus propios certificados y configuración del usuario, sin
embargo, en un entorno de desarrollo es posible encontrar estos valores predeterminados.
Como mecanismo de seguridad elegiremos autenticación de usuario con el mecanismo de claves

simétricas.
En nuestro ejemplo elegiremos autenticación de usuario con el mecanismo de claves simétricas,

pero podríamos seleccionar cualquiera de las siguientes opciones:
Mutual Certificates Security: El mecanismo mutuo de certificados de seguridad añade seguridad a
través de mensaje de protección de autenticación que garantiza la integridad y confidencialidad.
Cuando use certificados mutuos, el archivo de almacén de confianza debe ser configurado tanto para
el lado del cliente y el servidor de la aplicación.
www.learning.es
Transport Security (SSL): El mecanismo de seguridad de transporte protege su aplicación durante
el uso de SSL de transporte para la autenticación y confidencialidad. La seguridad de transporte de
la capa es proporcionada por los mecanismos de transporte utilizados para transmitir información
sobre el alambre entre los clientes y proveedores, por lo tanto la seguridad de capa de transporte se
basa en garantizar el transporte HTTP (HTTPS) usando Secure Sockets Layer (SSL).
Message Authentication over SSL: La autenticación de mensajes a través de SSL mecanismo
otorga un seguro de identidad criptográficamente o token de autenticación con el mensaje y el uso
65
de SSL para la protección de la confidencialidad.
SAML Authorization over SSL: El mecanismo de autorización SAML sobre SSL concede una
autorización simbólica con el mensaje y utiliza SSL para la protección de la confidencialidad.
Endorsing Certificate: Este mecanismo utiliza mensajes seguros con la clave simétrica para
protección de la integridad y la confidencialidad, y utiliza un certificado de cliente para aumentar
respaldar las reivindicaciones proporcionada por el símbolo asociado a la firma del mensaje.
SAML Sender Vouches with Certificates: Este mecanismo protege los mensajes con los
certificados mutuo de la integridad y la confidencialidad y con un remitente da fe de la autorización
SAML token.
SAML Holder of Key: Este mecanismo protege a los mensajes con una aserción de SAML firmada
(expedido por una autoridad de confianza) cliente de llevar a la clave pública y la información con la
autorización y confidencialidad protección de la integridad mediante certificados mutuo.
Podemos seleccionar las casillas de verificación de la derecha para el elemento que le gustaría
firmar, cifrar o requierir. Para ello, pulsaremos sobre el botón Message Parts de la sección Input
Message.
Después dejar configurado el Web Service, crearemos el cliente que consuma el servicio.
Crear un proyecto aplicación java.
www.learning.es
66
Llamamos al proyecto ConsumoWS_Seguridad.
Añadir un elemento de tipo Web Service Client.
Seleccionamos el Web Service que queremos consumir y pulsamos sobre finalizar.
www.learning.es
67
Dentro de nuestra clase, pulsaremos botón derecho para que nos genere el código de llamada al
método mensaje de nuestro Web Service. Seleccionar Insert code, como se muestra en la imagen.
Posteriormente, pulsamos sobre la opción Call Web Service Operation.
Elegiremos el método mensaje del servicio web que queremos consumir.
www.learning.es
68
Realizaremos en el main la llamada al método mensaje que nos acaba de generar. Pasaremos como
parámetro un string que es lo que espera nuestro método mensaje.
package consumows_seguridad;
public class Main {
/**
*/
System.out.println(mensaje("Rosa"));
}
private static String mensaje(java.lang.String nombre) {
aa.NewWebServiceService service = new aa.NewWebServiceService();
aa.NewWebService port = service.getNewWebServicePort();
return port.mensaje(nombre);
}
}
Pulsamos sobre edit web Service Attributes para poder incluir validación al conectarnos al web
Service.
www.learning.es
Marcamos la opción Use development default, de esta manera nos validaremos con el usuario por
defecto que tiene GlassFish.
Debido a que los certificados por defecto no se encuentran en un formato adecuado para ser
utilizado en este contexto, se importan unos por defecto. In addition to importing certificats, a
default user is created in the "file" realm, with username "wsitUser". Además de importar
certificados, un usuario puede utilizarlos validándose con el nombre de usuario "wsitUser". In a
production environment, you will probably want to provide your own certificates and user settings,
69
however, in a development environment you may find these defaults useful. En un entorno de
Salida del Consumidor del Servicio:
Ver Video: Seguridad Servicios , en la Unidad 4,

Laboratorio: Seguridad Servicios

Objetivo
Implementar seguridad a nuestro servicio web de monedas.
Enunciado
Abriremos un proyecto Web Application para crear el servicio web.
www.learning.es
70
Llamaremos al proyecto WS_Seguridad.
Seleccionamos como servidor GlassFish.
No seleccionaremos ningún Framework, y por último le daremos a finalizar.
www.learning.es
71
Añadiremos a nuestro proyecto web un archivo de tipo Web Service.
En la caja de texto para introducir el nombre del servicio introduciremos ServicioSeguridad. Guardar
el servicio en el paquete Servicios.
Añadimos las operaciones del servicio web de monedas.
//Declaramos un array con el valor de cada una de las monedas.
www.learning.es
public double[] valores=new double[] {1.26201, 14.4762, 75.6061, 135.861, 166.386};
@WebMethod(operationName = "convertirMonedaEuro")
public Double convertirMonedaEuro(@WebParam(name = "valor")
int indice) {
return (valor * valores[indice]); 72
}
@WebMethod(operationName = "convertirEuroMoneda")
public Double convertirEuroMoneda(@WebParam(name = "valor")
int indice) {
}
Marcamos la opción de Secure Service en la consola de nuestro servicio.
Seleccionamos la opción avanzadas, para abrir el editor de atributos.
Como mecanismo de seguridad elegiremos autenticación de usuario con el mecanismo de claves

simétricas.
www.learning.es
73
Después dejar configurado el Web Service, crearemos el cliente que consuma el servicio.
Crear un proyecto aplicación java.
Llamamos al proyecto ConsumoWS_Seguridad.
www.learning.es
Añadir un elemento de tipo Web Service Client.
74
Seleccionamos el Web Service que queremos consumir y pulsamos sobre finalizar.
Dentro de nuestra clase, pulsaremos botón derecho para que nos genere el código de llmada al
método mensaje de nuestro Web Service. Seleccionar Insert code, como se muestra en la imagen.
www.learning.es
Posteriormente, pulsamos sobre la opción Call Web Service Operation.
75
Realizaremos en el main la llamada al método mensaje que nos acaba de generar. Pasaremos como
parámetro un string que es lo que espera nuestro método mensaje.

{
}
}
Pulsamos sobre edit web Service Attributes para poder incluir validación al conectarnos al web
Service.
Marcamos la opción Use development default, de esta manera nos validaremos con el usuario por
defecto que tiene GlassFish.
Debido a que los certificados por defecto no se encuentran en un formato adecuado para ser
utilizado en este contexto, se importan unos por defecto. In addition to importing certificats, a
default user is created in the "file" realm, with username "wsitUser". Además de importar
certificados, un usuario puede utilizarlos validándose con el nombre de usuario "wsitUser". In a
production environment, you will probably want to provide your own certificates and user settings,
however, in a development environment you may find these defaults useful. En un entorno de
www.learning.es
76
Actividades
www.learning.es

PDF M8 Java

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PDF M8 Java

Enviado por

Direitos autorais:

Formatos disponíveis

Módulo 8

Pueden anotarse clases Java "normales" o EJBs sin estado.

Podemos especificar los fragmentos del path empleando expresiones regulares.

Es el lenguaje universal para intercambio de información entre aplicaciones, sistemas y dispositivos

Un UDDI registry tiene dos tipos de clientes:

Arquitectura orientada a servicios

De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en

Desarrollo de servicios web con tecnología java

Ejemplo de desarrollo web con tecnología java

3. Agregamos un archivo de tipo WebService, le damos un nombre y un paquete donde

5. Modificamos el código que nos genera para devolver un mensaje predeterminado.

7. Agregamos un archivo de tipo Web Service Client.

8. Pulsamos sobre la opción examinar y elegimos el servicio web recién creado.

private static String nombre() {

Consumir el servicio web desde un proyecto web

<%@page contentType="text/html" pageEncoding="UTF-8"%>

API Java para Servicios Web XML (JAX-WS)

Servicio web tiempo meteorológico

Referencia al servicio web:

public static void main(String[] args) {

private static String getCitiesByCountry(java.lang.String countryName) {

private static String getWeather(java.lang.String cityName, java.lang.String countryName) {

Ver Video: Analizando Servicios Web , en la Unidad 1,

Servicio web monedas

Ejemplo prueba conversión de monedas

public static void main(String[] args)

private static Double convertirMonedaEuro(double valor, int indice) {

Según el Alcance: ¿Dónde se aplican?

Estos patrones no representarán ningún concepto de nuestro dominio, probablemente no reflejarán

Patrones Creacionales. Los patrones creacionales abstraen el proceso de instanciación de objetos,

Patrones de diseño basados en servicios web

Buenas prácticas para desarrollar servicios web SOAP

Escribe tu mismo el fichero WSDL (Contract-First)

Usa http://localhost:puerto como dirección url del endpoint

Un archivo WSDL está dividido en cuatro secciones que representan:

Los archivos WSDL pueden contener hasta cuatro partes

Ejemplo de un archivo WSDL incompleto

Sección de binding para el anterior archivo WSDL

Laboratorio: Buenas prácticas para desarrollar servicios web SOAP.

Creación servicio web monedas:

El código que nos generará será el siguiente:

public double[] valores=new double[] {1.26201, 14.4762, 75.6061, 135.861, 166.386};

Consumo web service:

private static Double convertirMonedaEuro(double valor, int indice) {

La diferencia entre un buen desarrollo de software y un mal desarrollo de software es a menudo la

Tipos de excepciones con servicios web

La excepción SOAPFaultException representa lo errores producidos por SOAP 1.1 o 1.2.

Ejemplo de control de Excepción SOAPFaultException

Seleccionamos usar el proyecto con Apache Tomcat

Y por último, no seleccionamos ningún Framework.

Indicamos que lo guarde en el paquete ControlExcepciones.

Añadimos tres operaciones al servicio como se muestra en el diseñadores de WebService:

Seleccionamos el servidor Apache Tomcat.

Dejamos sin seleccionar Framework.

El archivo WSDL que generará:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<%@page contentType="text/html" pageEncoding="UTF-8"

controlexcepciones.WSSumadorService service = new

Excepciones predefinidas en servicios web

Ejemplo de servicio web con manejo de excepciones

public class LeerDatos3{

if(!continua.equals("s") && !continua.equals("n")){