Manual de WebServicesJava EE5

MANUAL DE
WEB SERVICES JAVA EE5

Web Services Java EE 5
ÍNDICE GENERAL
UNIDAD DIDACTICA 1. APRENDIENDO LA BASE DE LOS SERVICIOS WEB 1
LECCIÓN 1. Introducción 1
1. Qué es un servicio web y sus beneficios 1
2. Estándares parar el desarrollo de servicios web 6
3. Decisiones clave para el diseño de servicios web 10
LECCIÓN 2. Publicación de un servicio web 13

Introducción 13
1. Publicar un servicio web en el registro 13
2. Escenarios del registro de implementación 16
3. Distribuir y empaquetar un servicio Endpoint 17
EJERCICIOS DE REPASO DEL TEMA 1 24

Enunciados 24
Soluciones 25
UNIDAD DIDÁCTICA 2. TECNOLOGÍAS DE SERVICIOS WEB 26
LECCION 1. JAX-WS 2.0. JAVA API PARA SERVICIOS WEB XML 26

1. Construir servicios web JAX-WS 27
2. Crear un servicio web y un cliente sencillo con JAX-WS 28
3. Requerimientos de un JAX-WS ENDPOINT 29
4. Codificar la clase de implementación del servicio Endpoint 30
5. Empaquetar y distribuir el servicio 30
6. Tipos soportados por JAX-WS 32
7. Un cliente JAX-WS simple 32
LECCIÓN 2. JAXB. VINCULACIÓN ENTRE LOS ESQUEMAS XML Y LAS CLASES JAVA 34
Introducción 34
1. Arquitectura JAXB 35
2. Representación del contenido XML 37
3. Vincular los esquemas XML 38
4. Personalización de las vinculaciones 40
5. Utilizar JAXB 44
LECCION 3. StAX (STREAMING API para XML) 48

Introducción 48
1. STREAMING VS DOM 48
2. La API StAX 50
3. Utilizar StAX 55

Enunciados 66
Soluciones 64
UNIDAD DIDÁCTICA 3. OTRAS TECNOLOGIAS DE SERVICIOS WEB 65
LECCION 1. SAAJ. SOAP WITH ATTACHMENTS API PARA JAVA 65

Introducción 65
1. Mensajes 65
2. Objetos de conexion SOAP 68
LECCION 2. JAXR. JAVA API FOR XML REGISTRIES 75

1. ¿Qué es un registro? 75
2. ¿Qué es JAXR? 75
3. Arquitectura JAXR 75
4. Implementar un cliente JAXR 77
LECCIÓN 3. SEGURIDAD EN LOS SERVICIOS WEB 89

Introducción 89
1. Mensaje de seguridad 89
2. Especificaciones de seguridad 92
3. Utilizar el mensaje de seguridad con JAVA EE 96

Enunciados 99
Soluciones 100
PRÁCTICAS 101
Enunciados 101
Soluciones 103
GLOSARIO 104
Web Services Java EE5
TEMA 1. APRENDIENDO LA BASE DE LOS SERVICIOS WEB
Los servicios web - componentes de software de programación que son accesibles

a través de protocolos estándar de Internet - se están expandiendo rápidamente
debido a la creciente necesidad de aplicaciones que mantengan comunicación entre
las propias aplicaciones y la interoperabilidad.
Los servicios Web nos dan una interfaz estándar que es independiente de la
plataforma y de la tecnología que usemos, además se ajustan a las normas
aceptadas por la mayoría de las reglas de negocio, proporcionando un medio de
comunicación entre aplicaciones de software que se ejecutan en diferentes
plataformas y se escriben en diferentes lenguajes de desarrollo de aplicaciones.
LECCION 1. INTRODUCCIÓN A LOS SERVICIOS WEB
1. QUÉ ES UN SERVICIO WEB Y SUS BENEFICIOS
Existen numerosas definiciones para los servicios Web, que van desde los de
carácter muy técnico al más simple posible.
Por ejemplo, la organización World Wide Web Consortium (W3C), que establece
las normas para servicios Web, las define así: "Un servicio Web es un sistema de
software identificado por un URI con interfaces públicas y los enlaces son definidos
y descritos utilizando XML. Su definición puede ser descubierta por otros sistemas
de software. Estos sistemas pueden interactuar con el servicio Web en la forma
prescrita por su definición, usando mensajes basados en XML transmitidos por los
protocolos de Internet".
Una definición más sencilla, y quizá más útil, podría ser: "un servicio Web es
una aplicación de software, accesible en la Web (o la intranet de una empresa) a
través de una URL, que es visitada por los clientes que utilizan protocolos basados
en XML, como (SOAP) enviados a través de protocolos de Internet como HTTP.
Los clientes acceden a una aplicación de servicio Web a través de sus interfaces y
enlaces, que se definen mediante XML, como el lenguaje de definición de servicios
Web (WSDL).”
Los servicios Web son el resultado de la evolución natural de la Web.

Inicialmente, la red constaba de sitios que eran simples páginas HTML, más tarde,
las aplicaciones web generaron dinámicamente estas mismas páginas HTML.
1
A pesar de sus capacidades ampliadas, las aplicaciones Web están todavía limitadas
a la capacidad de la interfaz gráfica de sus páginas HTML ya que una aplicación
Web se puede utilizar sólo a través de la interfaz de usuario limitada y vinculada a
las páginas HTML.
Los servicios web van más allá de esta limitación, ya que se separa el sitio Web o
una aplicación (el servicio) de su interfaz gráfica de usuario HTML.
En cambio, el servicio se representa en XML y está disponible a través de Internet

como XML, como resultado, un mapa del sitio Web puede extender su funcionalidad
para proporcionar un servicio Web que otras empresas pueden usar para dar
instrucciones a sus oficinas, se integran con los sistemas de posición global, y así
sucesivamente.
Los servicios Web, o simplemente los servicios, se basan en los conocimientos

adquiridos en los ámbitos más maduros de computación distribuida (como CORBA
y Java Remote Method Invocation) para permitir la aplicación a la comunicación
entre aplicaciones y la interoperabilidad.
Los servicios web proporcionan una forma estándar a las aplicaciones para
exponer su funcionalidad a través de Internet o comunicarse con otras
aplicaciones en una red, independientemente de la aplicación, lenguaje de
programación o plataforma de computadora.
Hay tres tipos de arquitecturas básicas:
• Un servicio Web permite una arquitectura orientada a servicios, que es

un estilo arquitectónico que promueve la reutilización de software mediante
la creación de servicios reutilizables.
• Las arquitecturas tradicionales orientadas a objetos utilizan la
reutilización de las clases o de los objetos. Sin embargo, a menudo los
objetos son “grano fino” para reutilizarlos de una manera eficaz.
• Las arquitecturas orientadas a componentes los utilizan tratando estos
componentes como unidades reutilizables. Estos componentes están
compuestos por el conjunto de clases relacionadas, sus recursos, y la
información de configuración, este tipo de arquitectura todavía sigue siendo
muy útil para diseñar sistemas de software, sin embargo, no abordan las
cuestiones adicionales derivadas de los entornos empresariales actuales.
Hoy en día, los entornos empresariales son bastante complejos debido a que se
utilizan una gran variedad de plataformas de software y hardware, basadas en
Internet, comunicación distribuida, integración de aplicaciones empresariales, etc.
2
Las arquitecturas orientadas a servicios pueden resolver estos problemas

mediante el uso de un servicio como una entidad reutilizable.
Los servicios son normalmente menos finos que los componentes, y se centran en
la funcionalidad proporcionada por sus interfaces.
Estos servicios se comunican entre sí y con los clientes finales a través de

interfaces bien definidas y conocidas.
La comunicación puede ir desde un simple paso de mensajes entre los servicios a

un escenario complejo en el que un conjunto de servicios juntos se coordinen entre
sí para lograr un objetivo común. Estas arquitecturas permiten a los clientes
invocar la funcionalidad de un servicio Web a través de interfaces expuestas del
servicio.
En una arquitectura orientada a servicios, tenemos lo siguiente:
• Un servicio que implementa la lógica de negocio y expone esta lógica

de negocio mediante interfaces bien definidas.
• Un registro en el servicio que publica sus interfaces para permitir a los

clientes descubrir el servicio.
• Los clientes (incluyendo clientes que pueden ser los propios

servicios) que descubren el servicio mediante los registros y el acceso al
servicio directamente a través de las interfaces expuestas.
Una ventaja importante de una arquitectura orientada a servicios es que permite el

desarrollo de aplicaciones de acoplamiento flexible que pueden ser distribuidas y
son accesibles a través de la red.
Para habilitar esta arquitectura, se necesita lo siguiente:
• Un mecanismo que permita a los clientes acceder a un servicio y el

registro.
• Un mecanismo para permitir a los diferentes servicios registrar su

existencia con un registro y una manera para que los clientes puedan
buscar el registro de los servicios disponibles. Los servicios web se basan en
una arquitectura en la que el servicio se puede encontrar en la red y su
ubicación es transparente, lo que significa que los clientes podrán
descubrir de forma dinámica un determinado servicio que quieran utilizar.
• Un mecanismo de servicios para exponer las interfaces bien definidas y

una forma para que los clientes acceder a las interfaces.
3
Los beneficios que podemos obtener utilizando Servicios Web son los siguientes:
• Interoperabilidad en un entorno heterogéneo:

Probablemente la principal ventaja del modelo de servicios Web es que permite
a diferentes servicios distribuidos funcionar en una gran variedad de
plataformas y arquitecturas de programas, y les permite ser escritos en
diferentes lenguajes de programación.
A medida que las empresas desarrollan sus aplicaciones van añadiendo

sistemas y soluciones que a menudo requieren diferentes plataformas y con
frecuencia no se comunican unas con otras.
Más tarde, tal vez debido a una consolidación o la adición de otra aplicación, se
hace necesario unir estas funcionalidades dispares. La mayor fortaleza de los
servicios Web es su capacidad para permitir la interoperabilidad en un
entorno heterogéneo.
Mientras los distintos sistemas estén habilitados para los servicios Web, pueden
utilizar estos servicios para interoperar fácilmente con otros sistemas.
• Servicios a las empresas a través de la Web:

Una empresa puede utilizar los servicios Web para aprovechar las ventajas de la
World Wide Web para sus operaciones. Por ejemplo, una empresa puede
hacer que su catálogo de productos y el inventario estén a disposición de sus
proveedores a través de un servicio Web para lograr una mejor gestión de la
cadena de suministro.
• Integración con los sistemas existentes:

La mayoría de las empresas tienen una enorme cantidad de datos almacenados
en los sistemas de información de la empresa existentes, y el coste de
reemplazar estos sistemas es tal que descartar estos sistemas no entra como
opción posible.
Los servicios Web permiten a los desarrolladores de aplicaciones empresariales

la reutilización de esta información existente. Los servicios web nos
proporcionan procedimientos estándar para acceder al nivel medio y a los
“servicios back-end”, como los sistemas de gestión de bases de datos y los
monitores de transacción, e integrarlos con otras aplicaciones.
• La libertad de elección:
Las normas de servicios Web han abierto un gran mercado para las
herramientas, productos y tecnologías. Esto da a las organizaciones una gran
variedad de opciones, y pueden seleccionar las configuraciones que mejor
satisfagan sus requisitos de aplicación.
4
Los desarrolladores podemos mejorar nuestra productividad, ya que, en lugar

de tener que desarrollar nuestras propias soluciones, podemos elegir de una
lista de mercado de componentes de aplicación de la propia plataforma. Además
las herramientas, proporcionan la capacidad de moverse rápida y fácilmente de
una configuración a otra según sea necesario.
Los servicios Web también garantizan la estandarización de las herramientas, de

modo que las herramientas de desarrollo pueden adoptar nuevos instrumentos,
tanto de proveedores de servidores o de otros desarrolladores de la
herramienta.
• Soporte más tipos de clientes:

Dado que un objetivo principal de los servicios Web es mejorar la
interoperabilidad, la exposición de las aplicaciones existentes o servicios como
los servicios Web aumenta su alcance a distintos tipos de clientes.
Esto ocurre independientemente de la plataforma en la que se basa el cliente:

no importa si el cliente se basa en Java o plataformas de Microsoft, o incluso si
se basa en una plataforma inalámbrica.
En resumen, un servicio Web puede ayudarnos a ampliar nuestras aplicaciones

y servicios a un amplio conjunto de diferentes tipos de cliente.
• Programación de la productividad:
Para ser productivo en la economía de la información se requiere la habilidad de
desarrollar y distribuir aplicaciones de una manera oportuna. Las solicitudes
deberán ir rápidamente desde el prototipo hasta la producción y deben seguir
evolucionando, incluso después de que se coloquen en producción.
La productividad es mayor cuando los equipos de desarrollo de aplicaciones

tienen un nivel medio para acceder a los servicios requeridos por las
aplicaciones de varios niveles y formas estándar para apoyar una variedad de
clientes. Los servicios Web, mediante la creación de un estándar de
programación común, contribuyen a mejorar la productividad de la
programación.
Antes de la llegada de los servicios Web, los desarrolladores de programación

en el entorno de computación distribuida nos basábamos en un conjunto de
distintas tecnologías siempre compatibles. Se han tratado de unir de nuevo
diversos sistemas de servidor, tales como la personalización y los sistemas
estándar de gestión de bases de datos y procesadores de transacciones, con las
tecnologías tradicionales de Internet, pero han tenido que lidiar con una
multitud de modelos de programación.
5
El desarrollo de aplicaciones también se ha visto complicado por el requisito de

que una aplicación en particular, el apoyo de un tipo específico de cliente o de
varios tipos simultáneamente. Los servicios Web fomentan la interoperabilidad,
y simplifica este aspecto del proceso de desarrollo de aplicaciones.
2. ESTÁNDARES PARA EL DESARROLLO DE SERVICIOS WEB
Los estándares son diferentes a las tecnologías. Los estándares son un conjunto
de especificaciones, normas y directrices formuladas y aceptadas por los
participantes en el mercado principal. Aunque estos estándares nos indican una
manera común de alcanzar un objetivo no indican los detalles de implementación.
Los desarrolladores haremos nuestras propias implementaciones de cada estándar.

Estas diferentes implementaciones de un estándar dado por los distintos
proveedores dan lugar a una variedad de tecnologías. Sin embargo, a pesar de las
diferencias de la implementación del detalle, las tecnologías pueden trabajar juntas.
Los estándares de servicios web han sido ampliamente aceptados y para ello deben
cumplir los siguientes criterios:
• Un servicio Web debe ser capaz de atender las solicitudes de

cualquier cliente, independientemente de la plataforma en la que se
ejecuta el cliente.
• El cliente debe ser capaz de encontrar y utilizar cualquier servicio

web, independientemente de los detalles de implementación del servicio o
de la plataforma en la que se ejecuta.
Establecer una base de normas comunes para permitir a los servicios Web lograr
una amplia aceptación e interoperabilidad.
Estas normas abarcan áreas tales como:
• Lenguaje de marcado común para la comunicación (XML). Para

empezar, los proveedores de servicios, que representan los servicios
disponibles, y los solicitantes de servicios, que utilizan los servicios, deben
ser capaces de comunicarse unos con otros.
Esta comunicación exige el uso de una terminología común, o el idioma, a

través del cual los proveedores y los solicitantes puedan hablar entre sí. Un
lenguaje de marcado común facilita la comunicación entre los
proveedores y los solicitantes, ya que cada partido es capaz de leer y
entender la información intercambiada basado en las etiquetas de marcado
incrustado.
6
Aunque los proveedores y los solicitantes pueden comunicarse mediante los

intérpretes o traductores no es práctico porque tales agentes intermediarios
son ineficientes y no rentables. Los Servicios Web usan eXtensible Markup
Language (XML) para el lenguaje de marcado común.
En esta serie de ejemplos de código veremos las partes necesarias para que un
documento XML que representa información de un contacto individual:
<? xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

<ContactInformation>
< Nombre >Juan Español</ Nombre>
< Dirección >
< Calle >Pza de España</ Calle >
<Ciudad>Madrid</Ciudad>
<Provincia>Madrid</Provincia>
<País>España</País>
</ Dirección >
<Teléfono>123-456-7890</Telefono>
<EMail>juanespañ[email protected]</EMail>
</ContactInformation>
1. DTD que describe la estructura del documento XML.
<! ELEMENT ContactInformation (Nombre, Direccion, Telefono, EMail)>

<! ELEMENT Nombre (#PCDATA)>
<! ELEMENT Direccion (Calle, ciudad, Provincia, Pais)>
<! ELEMENT Calle (#PCDATA)>
<! ELEMENT Ciudad (#PCDATA)>
<! ELEMENT Provincia (#PCDATA)>
<! ELEMENT Pais (#PCDATA)>
<! ELEMENT Telefono (#PCDATA)>
<! ELEMENT EMail (#PCDATA)>
2. Esquema XSD para el documento XML.
<? xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

<ContactInformation
xmlns="http://simple.ejemplo.com/CInfoXmlDoc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi: schemaLocation=
"http://simple.ejemplo.com/CInfoXmlDoc
file:./CInfoXmlDoc.xsd">
< Nombre >Juan Español</ Nombre >
< Direccion >
< Calle >Pza España</ Calle >
< Ciudad >Madrid</ Ciudad >
< Provincia >Madrid</ Provincia >
< Pais >España</ Pais >
</ Direccion >
< Telefono >123-456-7890</ Telefono >
<EMail>juanespañ[email protected]</EMail>
</ContactInformation>
7
3. Documento XML.
<? xml version="1.0" encoding="UTF-8"?>
<xsd: schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace=http://simple. ejemplo.com/CInfoXmlDoc
xmlns=" http://simple.ejemplo.com/CInfoXmlDoc"
elementFormDefault="qualified">
<xsd: element name="ContactInformation">
<xsd: complexType>
<xsd: sequence>
<xsd: element name="Nombre" type="xsd: string" />
<xsd: element name="Dirección">
<xsd: complexType>
<xsd: sequence>
<xsd: element name="Calle” type="xsd: string" />
<xsd: element name="Ciudad" type="xsd: string" />
<xsd: element name="Provincia" type="xsd: string" />
<xsd: element name="Pais" type="xsd: string" />
</xsd: sequence>
</xsd: complexType>
</xsd: element>
<xsd: element name="Telefono" type="xsd: string" />
<xsd: element name="EMail" type="xsd: string" />
</xsd: sequence>
</xsd: complexType>
</xsd: element>
</xsd: schema>
• Formato de mensaje común de intercambio de información. A pesar de

que establecer un lenguaje de marcado común es importante, por sí solo no es
suficiente para que ambas partes (en concreto, los proveedores de servicios y
los solicitantes del servicio) puedan comunicarse correctamente.
Para una comunicación eficaz, las partes deben ser capaces de intercambiar
mensajes poniéndose de acuerdo con un formato. Al contar con este formato,
las partes que no se conocen entre sí pueden comunicarse de manera eficaz.
Simple Object Access Protocol (SOAP) es un formato de mensaje común de
los servicios Web.
Código ejemplo de una petición SOAP para obtener una cuota de stock.
<SOAP-ENV: Envelope xmlns: SOAP-ENV="SoapEnvelopeURI"

SOAP-ENV: encodingStyle="SoapEncodingURI">
<SOAP-ENV: Header>
</SOAP-ENV: Header>
<SOAP-ENV: Body>
<m: GetLastTradePrice xmlns: m="ServiceURI">
<tickerSymbol>SUNW</tickerSymbol>
</m: GetLastTradePrice>
</SOAP-ENV: Body>
8
</SOAP-ENV: Envelope>
• Formatos de especificación común de servicio. Además de los formatos de

mensaje común y lenguaje de marcas, debe haber un formato común que todos
los proveedores de servicios pueden utilizar para especificar los detalles del
servicio, tales como el tipo de servicio, la forma de acceder al servicio, etc …
Un mecanismo estándar para especificar los detalles del servicio permite

a los proveedores especificar sus servicios de modo que cualquier solicitante
puede entender y usar. Por ejemplo, Web Services Description Language
(WSDL) ofrece servicios de Internet con los formatos de especificación común.
Código ejemplo de un documento WSDL para un servicio web.

<definitions name="WeatherWebService"
targetNamespace="urn: WeatherWebService"
xmlns: tns="urn: WeatherWebService"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types/>
<message name="WeatherService_getWeather">
<part name="String_1" type="xsd: string"/>
</message>
<message name="WeatherService_getWeatherResponse">
<part name="result" type="xsd: string"/>
</message>
<portType name="WeatherService">
<operation name="getWeather" parameterOrder="String_1">
<input message="tns: WeatherService_getWeather"/>
<output
message="tns: WeatherService_getWeatherResponse"/>
</operation>
</portType>
<binding name="WeatherServiceBinding"
type="tns: WeatherService">
<operation name="getWeather">
<input>
<soap: body use="literal"
namespace="urn: WeatherWebService"/>
</input>
<output>
<soap: body use="literal"
namespace="urn: WeatherWebService"/>
</output>
<soap: operation soapAction=""/></operation>
<soap: binding transport="http://schemas.xmlsoap.org/soap/http"
style="rpc"/>
</binding>
<service name="WeatherWebService">
<port name="WeatherServicePort"binding="tns: WeatherServiceBinding">
<soap: address location="http://mycompany.com/weatherservice"/>
</port>
</service>
</definitions>
• Medios comunes de búsqueda de servicios. De la misma manera que los

proveedores necesitan una forma común de especificar los detalles del servicio,
9
los solicitantes de servicio debe tener una forma común para buscar y
obtener información de un servicio.
Esto se logra teniendo lugares donde los proveedores pueden registrar sus
especificaciones de servicio y donde los solicitantes saben que pueden ir a
buscar los servicios.
Al tener estos medios, cuya situación es conocida y se puede acceder de una

forma estándar a ellos, los servicios pueden ser accesibles universalmente por
todos los proveedores y los solicitantes.
La especificación Universal Description, Discovery and Integration (UDDI)

define un medio común para buscar los servicios Web.
Figura 1
3. DECISIONES CLAVE PARA EL DISEÑO DE SERVICIOS WEB
Los servicios Web interactúan con los clientes para recibir las solicitudes de los
clientes y las respuestas de retorno.
En medio de la petición y la respuesta, un servicio Web aplica la lógica de negocio

apropiada para procesar y cumplir con la petición de un cliente.
El diseño de un servicio web eficaz comienza con la comprensión de la naturaleza

del servicio que debe prestarse, es decir, cómo el servicio va a interactuar con
el cliente y cómo se va a procesar y completar la solicitud del cliente.
Al diseñar un servicio Web, debemos tener en cuenta el flujo de la lógica de los

servicios típicos de Internet. En general, un servicio Web:
• Muestra una interfaz que los clientes usan para hacer peticiones al servicio.
• Hace qué un servicio esté disponible para los socios y los clientes
interesados mediante la publicación de los detalles del servicio.
• Recibe peticiones de los clientes.
10
• Los delegados reciben las solicitudes de la lógica de negocio y los

procesos adecuados de las solicitudes.
• Formula y envía una respuesta a la solicitud.
Sabiendo que tenemos que tener en cuenta este flujo de la lógica, los siguientes
son los pasos típicos para el diseño de un servicio Web.
1. Decidir la interfaz para los clientes. Nosotros como desarrolladores de

servicios Web antes de iniciar el proceso de diseño debemos decidir que interfaz
hará público nuestro servicio a los clientes.
La interfaz debe reflejar el tipo y la naturaleza de las llamadas que hacen los
clientes al utilizar el servicio, tenemos que considerar el tipo de parámetros que
queremos utilizar, (los servicios Endpoint EJB o los servicios endpoint JAX-
RPC) y cuándo usarlos.
También tendremos que decidir si vamos a utilizar los controladores de SOAP. Por
último, pero no menos importante, ya que una razón para agregar una interfaz de
servicios web es lograr la interoperabilidad, tenemos que asegurarnos de que
nuestras decisiones de diseño no afectan a la interoperabilidad de los servicios en
su conjunto.
Después de todo esto decidiremos si queremos publicar la interfaz de servicio, y, en

caso afirmativo, la forma de publicarlo.
2. Determinar la forma de recibir las solicitudes y preproceso. Una vez que

hayamos decidido la interfaz y, si es necesario, cómo hacer que esté disponible,
estaremos preparados para estudiar la forma de recibir las solicitudes de los
clientes.
Es decir lo que necesitaremos para diseñar nuestro servicio no sólo para recibir
una llamada de un cliente que ha hecho, sino también para hacer cualquier pre-
procesamiento necesario para la solicitud (como traducir el contenido de la
solicitud en un formato interno) antes de aplicar la lógica de negocio del servicio.
3. Determinar cómo delegar la solicitud a la lógica de negocio.

Una vez que una solicitud ha sido recibida y preprocesada, entonces deberemos
delegar a la lógica de negocio del servicio.
4. Decidir la forma de procesar la solicitud. A continuación, el servicio de los

procesos de una solicitud. Si el servicio ofrece una interfaz de servicios Web a la
lógica de negocio existente, entonces el trabajo de este paso puede ser
11
simplemente para determinar cómo las interfaces de la lógica de negocio existente

se pueden utilizar para tramitar las solicitudes del servicio Web.
5. Determinar la forma de formular y enviar la respuesta. Por último,

debemos diseñar cómo el servicio web va a formular y enviar una respuesta al
cliente. Es mejor mantener estas operaciones juntas.
6. Determinar cómo informar de los problemas. Como los servicios Web no

son inmunes a los errores, debemos decidir cómo desechar o controlar las
excepciones o errores que se producen.
Es necesario abordar cuestiones tales como la posibilidad de lanzar servicios de

excepciones específicas o bien para que el sistema subyacente lance un sistema de
excepciones específicas.
También tenemos que pensar un plan para la recuperación de las excepciones

en aquellas situaciones que requieren la recuperación.
12
LECCION 2. PUBLICACIÓN DE UN SERVICIO WEB
INTRODUCCION
Hasta ahora, hemos visto las directrices para el diseño y la implementación de un

servicio Web. Pero es igual de importante, que nuestro servicio de Web pueda ser
accesible desde nuestros clientes. Recordemos que algunos de los servicios Web
son para uso de público en general, otros servicios web son para utilizarse sólo
entre los socios comerciales de confianza (entre empresas), y otros están
destinados a ser utilizados sólo dentro de una empresa (intra-empresa).
Independientemente de si un servicio tiene que ser accesible al público, a otras

empresas, o incluso dentro de una sola empresa, primero tenemos que hacer que
los detalles sobre el servicio de Web como su interfaz, los parámetros, donde se
encuentra el servicio, etc sean accesibles a los clientes.
Esto se realiza haciendo una descripción del servicio Web a disposición de las partes
interesadas. WSDL es el lenguaje estándar para la descripción de un servicio.
Hacer esta descripción WSDL disponible para los clientes, nos permite utilizar el
servicio.
Una vez que el WSDL está listo, tenemos la opción de publicar en un registro. Si
hacemos la descripción WSDL de su servicio disponible en un registro público, luego
un cliente basado en Java puede utilizar las API de JAXR para buscar la
descripción de su servicio y después utilizar ese servicio. Por lo demás, un cliente
puede utilizar las mismas API de JAXR para buscar la descripción de cualquier
servicio Web con una descripción WSDL disponible.
1. PUBLICAR UN SERVICIO WEB EN EL REGISTRO
La publicación de un servicio en un registro es un método para hacer disponible

el servicio a los clientes. Si decidimos publicar un servicio en un registro, hay que
decidir sobre el tipo de registro que vamos a utilizar según el escenario que vaya a
usar el servicio web.
Las primeras decisiones que deberemos tomar son:

• Si queremos registrar los servicios web para el consumo público en general
en un registro público conocido.
Cuando queremos que nuestro servicio tenga abierta la accesibilidad del servicio
para la mayor audiencia posible lo registraremos en un registro público,
13
cualquier cliente, incluso uno sin el conocimiento previo del servicio, puede buscar y
utilizar el servicio.
Hay que tener en cuenta que el registro público contiene la descripción de

servicios Web, que consiste no sólo en la descripción del servicio WSDL, sino
también cualquier esquema XML que hace referencia a la descripción del servicio.
En resumen, el servicio Web se debe declarar como público en los esquemas XML y
los esquemas adicionales definidos en el contexto del servicio. También tenemos
que publicar en el mismo Registro Público los esquemas XML que se refieren a
la descripción de servicios Web.
• Cuando un servicio Web es estrictamente para uso dentro de la
empresa, podemos publicar una descripción de servicios Web en un
registro corporativo de la empresa.
• Si los servicios web están dedicados a todos los clientes de sus servicios
web y no hay un acuerdo entre los socios sobre el uso de los servicios No
es necesario usar un registro de socios. Cuando este es el caso, podemos
publicar la descripción de servicios Web - la referencia a los esquemas WSDL
y XML - en un lugar conocido que tenga el acceso adecuado de protección.
1.1. CONCEPTOS SOBRE EL REGISTRO
Al considerar la posibilidad de publicar un servicio a través de un registro, es

importante comprender algunos de los conceptos, tales como depósitos y
taxonomías, que están relacionados con los registros.
Los registros públicos no son repositorios, los registros públicos sólo contienen
detalles sobre los servicios que están disponibles y cómo acceder a estos servicios.
Por ejemplo, un servicio de venta de paquetes de aventura no puede registrar su
catálogo completo de productos.
Un registro sólo puede almacenar el tipo de servicio, su ubicación, y la información

necesaria para acceder al servicio. Un cliente interesado en un servicio de primera
tiene que descubrir el servicio del registro y luego se unen con el servicio para
obtener el catálogo completo de servicios de los productos.
Una vez que obtenga el catálogo de servicios, el cliente puede comprobar si el

servicio satisface sus necesidades particulares. Si no, el cliente debe volver a
repetir el registro y el descubrimiento y el proceso de enlace, es decir el cliente
busca en el registro para algún otro servicio que puede ofrecer lo que quiere, se
une a ese servicio, obtiene y evalúa su catálogo, y así etc.
14
Como este proceso, que no es insignificante, puede tener que repetirse varias
veces, es fácil ver que es importante registrar un servicio en virtud de su
taxonomía (clasificación) adecuada.
Crear un servicio bajo la taxonomía adecuada
Si queremos publicar nuestro servicio en un registro, ya sea un registro público o

empresarial, debemos hacerlo en contra de una taxonomía que clasifica o
categoriza correctamente el servicio Web.
Es importante decidir la taxonomía adecuada, ya que esto afecta la facilidad con la

que los clientes pueden encontrar y utilizar su servicio. Hoy en día existen varias
taxonomías estándar bien definidas de la industria, tales como los sistemas
definidos por organizaciones como el Clasificación Industrial Norteamericana
(NAICS).
Utilizando los recursos existentes, se ofrece a los clientes el servicio Web

estándar a partir de una base para la búsqueda de nuestro servicio, facilitando a
los clientes a encontrar su servicio.
Por ejemplo, supongamos que nuestro negocio de viajes ofrece la Isla Madagascar
en los paquetes relacionados como aventura, o los Alpes como aventuras de
alpinismo.
En lugar de crear su propia taxonomía para categorizar el servicio, los clientes

pueden encontrar más fácilmente su servicio si se publica la descripción de este
servicio con dos taxonomías estándar diferentes: una taxonomía para la isla de
aventuras y otra de aventuras alpinas y de montaña.
Podemos publicar nuestro servicio Web en más de un registro. A fin de

ayudar a los clientes a encontrar nuestro servicio, también es una buena idea
publicar en tantas categorías aplicables como sea posible.
Por ejemplo, una empresa de viajes que vende paquetes de aventura puede
inscribirse utilizando una taxonomía de categoría de productos, así como una
taxonomía geográfica.
Esto da a los clientes la oportunidad de utilizar las estrategias óptimas para la

localización de nuestro servicio.
Por ejemplo, si varias instancias de un servicio existen para un determinado

producto, el cliente podría refinar aún más su selección, considerando la ubicación
geográfica y la elección de un servicio cerca de su oficina.
15
Por ejemplo utilizando el servicio de viajes de negocios, este tipo de servicio podría
colocarse en las taxonomías de los tipos de paquetes de aventura (isla y
alpinismo), así como en las taxonomías para los locales en los que los paquetes de
aventura se proporcionan (Monte Kilimanjaro o Tahití), haciendo lo más fácil posible
la localización de un servicio para un cliente potencial.
2. ESCENARIOS DEL REGISTRO DE IMPLEMENTACIÓN
Una vez que hemos decido publicar nuestro servicio y establecer las taxonomías
que mejor lo identifican, estaremos listos para poner en práctica nuestras
decisiones. Antes de hacerlo, podemos encontrar útil examinar algunos de los
escenarios de registro de aplicación que podemos encontrar.
Cuando se utiliza un registro, hemos visto que el proveedor de servicios publica la

descripción de servicios Web en un registro y los clientes descubren y enlazan
con el servicio Web para utilizar nuestros servicios.
En general, el cliente debe realizar tres pasos para utilizar un servicio Web:
1. El cliente debe determinar la forma de acceder a los métodos del

servicio, tales como la determinación de los parámetros de servicio método, los
valores de retorno... Esto se conoce como el descubrimiento de la interfaz de
definición de servicio.
2. El cliente debe localizar el servicio Web real, es decir, encontrar la dirección

del servicio. Esto se conoce como el descubrimiento de la implementación del
servicio.
3. El cliente debe estar vinculado a la ubicación específica del servicio, y

esto puede ocurrir en uno de las tres ocasiones:
• Cuando se desarrolla el cliente (llamado el vínculo estático).
• Cuando se implementa el cliente (también llamado vínculo estático).
• Durante el tiempo de ejecución (llamado enlace dinámico).
Estos tres pasos pueden producir tres escenarios. El escenario en particular

depende de cuándo se produce la unión y si el cliente se lleva a cabo únicamente
para un servicio específico o es un cliente genérico.
• Escenario 1: El servicio Web tiene un acuerdo con sus socios y publica su

descripción WSDL y esquemas XML haciendo referencia en un lugar
bien conocido.
Se espera que los clientes conozcan este lugar. Cuando este es el caso, el
cliente se lleva a cabo con la interfaz de servicio que se tenía en mente, es
16
decir, cuando se construyó, el cliente ya estaba diseñado para buscar la

interfaz de servicio directamente en lugar de utilizar un registro para
encontrar el servicio.
• Escenario 2: igual que en el escenario 1, el servicio Web publica su

descripción WSDL y esquemas XML en un lugar bien conocido, y espera
que sus socios conozcan esta ubicación o sean capaces de
descubrirla fácilmente.
O bien, cuando se construye, el socio puede usar una herramienta para

descubrir de forma dinámica e incluir tanto la aplicación específica del
servicio o la definición de la interfaz del servicio, junto con su aplicación
específica.
En este caso, la unión es estática, porque el socio se construye cuando la

definición de interfaz del servicio y la aplicación ya lo conocen, a pesar de
que esta información se encuentra de forma dinámica.
• Escenario 3: El servicio implementa una interfaz en un lugar bien conocido,

o espera a sus clientes para utilizar herramientas para encontrar la
interfaz en tiempo de compilación.
Ya que los clientes del servicio Web son clientes genéricos, es decir, que
no son clientes diseñados exclusivamente para utilizar este servicio de
Internet, se debe diseñar el servicio para que se pueda inscribir en un
registro. Estos clientes genéricos encuentran dinámicamente una aplicación
específica de un servicio en tiempo de ejecución utilizando los registros.
Tabla:
DEFINICIÓN DE LA IMPLEMENTACIÓN UNIÓN PARA
ESCENARIOS INTERFAZ DEL DEL SERVICIO ESPECIFICAR LA
SERVICIO DISCOVER DISCOVER LOCALIZACIÓN
1 Ninguno Ninguno Estático
Dinámico en
Ninguno o dinámico en
2 tiempo de Estático
tiempo de construcción
construcción
Dinámico en
Ninguno o dinámico en Dinámico en tiempo
3 tiempo de
tiempo de construcción de ejecución
construcción
3. DISTRIBUIR Y EMPAQUETAR UN SERVICIO ENDPOINT
Hasta ahora, hemos examinado los servicios Web en términos de diseño, desarrollo
y aplicación. Una vez que completemos la implementación de servicios Web,
17
tendremos que escribir su descriptores de distribución, el paquete de

servicios con todos sus componentes, y distribuir el servicio.
Si es posible, utilizaremos herramientas o IDEs para desarrollar un servicio

Web. Estas herramientas de desarrollo de servicios Web e IDEs crean
automáticamente los descriptores de distribución adecuados para el servicio y
manejar correctamente las medidas necesarias para que un servicio funcione
correctamente. Además, las herramientas e IDEs ocultan estos detalles a los
desarrolladores.
Aunque las herramientas de desarrollo realizan estas tareas por nosotros, es bueno
tener una comprensión conceptual de los descriptores de distribución y la
estructura de los paquetes, ya que determinan cómo se implementa un servicio en
un servidor y la disponibilidad del servicio para los clientes.
3.1 SERVICIOS DE INFORMACIÓN EN LOS DESCRIPTORES DE

DISTRIBUCIÓN
Para implementar correctamente un servicio, nosotros como desarrolladores

deberemos ofrecer la siguiente información.
• Descriptores relacionados con los detalles de la implementación del

servicio, incluida la interfaz de servicios Web, las clases que implementan
la interfaz de servicios Web etc.
• Detalles acerca de los servicios Web que se distribuyen, como los puertos y
las asignaciones de memoria.
• Detalles sobre el puerto correspondiente al componente WSDL. Más

concretamente, el descriptor de distribución que contiene información
acerca de un puerto de servicio asociado y WSDL.
• Un puerto del componente da una visión del servicio a los clientes de tal
manera que el cliente no necesita preocuparse de cómo el servicio ha sido
implementado.
• Cada puerto tiene un WSDL correspondiente.
• Cada puerto tiene un servicio “endpoint” asociado (y su implementación).

Los servicios endpoint de todas las peticiones pasan por la ubicación
definida en la dirección del puerto WSDL.
Para empezar, la implementación del servicio declararemos los detalles de

distribución en el módulo adecuado de descriptores.
18
Ejemplos:
1. Una aplicación de servicio que utiliza un servicio endpoint JAX-RPC declara
sus detalles en el archivo de WEB-INF/web.xml utilizando el servlet como
elemento de clase.
Código:
<web-app ...>
...
<servlet>
<description>Endpoint for Some Web Service</description>
<display-name>SomeWebService</display-name>
<servlet-name>SomeService</servlet-name>
<servlet-class>com.a.b.c.SomeServiceImpl</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>SomeService</servlet-name>
<url-pattern>/webservice/SomeService</url-pattern>
</servlet-mapping>
...
</web-app>
NOTA:
Hay que tener en cuenta que cuando tenemos un servicio que funciona
exclusivamente como un servicio Web utilizando servicios endpoint JAX-RPC,
algunas especificaciones en el archivo web.xml, como <error-page> y
<welcome-file-list>, no tienen efecto.
2. La implementación del servicio que utiliza un servicio endpoint EJB declara

los detalles de distribución en el archivo de META-INF/ejb-jar.xml mediante
el elemento de sesión.
Código:
<ejb-jar ...>
<display-name>Some Enterprise Bean</display-name>
<enterprise-beans>
<session>
<ejb-name>SomeBean</ejb-name>
<service-endpoint>com.a.b.c.SomeIntf</service-endpoint>
<ejb-class>com.a.b.c.SomeServiceEJB</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
...
</ejb-jar>
A continuación, especificamos los detalles del puerto. El descriptor de distribución

de servicios Web, llamado webservices.xml, define y declara los detalles
estructurales para el puerto de un servicio Web.
Este archivo contiene la siguiente información:
19
• Un nombre lógico para el puerto que también es único entre todos los
componentes del puerto (elemento port-component-name).
• La interfaz del servicio endpoint para el puerto (elemento service-

endpoint-interface).
• El nombre de la clase que implementa la interfaz de servicio

(elemento service-impl-bean).
La referencia al servicio de implementación del componente bean se

especifica con el elemento service-impl-bean en webservices.xml, en
un servlet-Link o en un ejb-link, dependiendo de si el servicio endpoint es
un JAX-RPC o un EJB.
Este elemento de enlace asocia el puerto del servicio Web a la

implementación del endpoint actual definido en web.xml o en el archivo
ejb-jar.xml.
• El archivo WSDL para el servicio (elemento wsdl-file).
• Un QName para el puerto (elemento wsdl-port).
• Una correlación entre las definiciones WSDL y las definiciones de las

interfaces de Java utilizando el archivo de asignación (elemento jaxrpc-
mapping-file).
El archivo de asignación JAX-RPC, que se especifica mediante el elemento

jaxrpc-mapping-file en el fichero webservices.xml, mantiene los detalles
sobre las relaciones entre las definiciones de las asignaciones WSDL
correspondientes y las interfaces de Java y sus definiciones.
La información contenida en este archivo, junto con la información en el

WSDL, se utiliza para crear esquemas y vínculos de los servicios
implementados.
• Detalles opcionales de cualquier manejador.

Ejemplo:
Este es un ejemplo de un descriptor de implantación de servicios Web en un
servicio llamado Weather Web, que utiliza un servicio endpoint JAX-RPC.
<webservices ...>
<description>Web Service Descriptor for weather service
</description>
<webservice-description>
<webservice-description-name>
WeatherWebService
</webservice-description-name>
<wsdl-file>
20
WEB-INF/wsdl/WeatherWebService.wsdl
</wsdl-file>
<jaxrpc-mapping-file>
WEB-INF/WeatherWebServiceMapping.xml
</jaxrpc-mapping-file>
<port-component>
<description>port component
description</description>
<port-component-name>
WeatherServicePort
</port-component-name>
<wsdl-port xmlns: weatherns="urn: WeatherWebService">
weatherns: WeatherServicePort
</wsdl-port>
<service-endpoint-interface>
endpoint.WeatherService
</service-endpoint-interface>
<service-impl-bean>
<servlet-link>WeatherService</servlet-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
3.2 ESTRUCTURA DEL PAQUETE
Una vez que se finalizó la implementación de servicios y descriptores de

distribución, se tiene que empaquetar los siguientes archivos en el módulo J2EE
apropiado:
• El archivo WSDL.
• La interfaz del servicio endpoint, incluyendo su aplicación y las

dependencias de las clases.
• El archivo de asignación de JAX-RPC, que especifica el nombre del paquete

que contiene las clases de tiempo de ejecución genera y define el URI de
espacio para el servicio.
• El descriptor de distribución del servicio web.
El tipo de criterio de valoración utilizado para la implementación del servicio

determina el tipo de módulo J2EE que tenemos que utilizar.
21
El módulo de J2EE adecuado para un servicio endpoint JAX-RPC es un archivo

WAR y un servicio endpoint EJB deben empaquetarse en un archivo EJB-JAR.
La estructura del paquete es la siguiente:
• Los archivos WSDL tienen una ubicación relativa a la raíz del módulo.
• La interfaz del servicio, las clases de implementación del servicio, y las

clases dependientes están empaquetadas igual que cualquier componente de
J2EE.
• El archivo de asignación de JAX-RPC se encuentra en una ruta relativa a

la raíz del módulo (normalmente en el mismo lugar que el descriptor de
distribución del módulo).
• La ubicación del descriptor de distribución de servicios depende del tipo

de servicio endpoint que tenga:
1. Para un servicio endpoint EJB está empaquetado en un EJB-JAR en el directorio

META-INF como META-INF/webservice.xml
Figura 2
2. Para un servicio endpoint JAX-RPC, está empaquetado en un archivo WAR en el
directorio WEB-INF como WEB-INF/webservices.xml.
22
Figura 3
23
EJERCICIOS DE REPASO DEL TEMA 1: APRENDIENDO LA BASE DE LOS

SERVICIOS WEB
ENUNCIADOS.
1. _________ puede convertir nuestra aplicación en Aplicaciones web.
2. Los servicios web definen una plataforma independiente estándar

basada en XML para comunicarse dentro de sistemas distribuidos.
3. SOAP se usa para transferir ...
4. Un ________ es la nueva generación de aplicaciones web.
5. Los servicios web no pueden ofrecer componentes de aplicación tipo:
24
SOLUCIONES A LOS EJERCICIOS DE REPASO. TEMA 1
1. La Respuesta Correcta es: La 2, Web Services.

2. La Respuesta Correcta es: La 1, Verdadero.
3. La Respuesta Correcta es: La 3, Los datos.
4. La Respuesta Correcta es: La 2, Servicio web.
5. La Respuesta Correcta es: La 4, Navegadores Web.
25
TEMA 2. TECNOLOGÍAS DE SERVICIOS WEB
LECCION 1. JAX-WS 2.0 JAVA API PARA SERVICIOS WEB XML
Dentro de las tecnologías existentes para los servicios web tenemos JAX-WS 2.0
que consiste en una serie de módulos que forman una arquitectura.
Figura 1
• Runtime - Tiempo de ejecución. Este módulo está disponible en tiempo

de ejecución de aplicaciones y proporcionan la base real del Web Services
Framework.
• Herramientas para la conversión de WSDL’s y archivos fuente de clases
en Java para servicios web.
• APT Una herramienta de Java SE y el marco para las anotaciones de
procesamiento.
O Anotación de procesador para el procesamiento de archivos fuente

de Java con javax.jws.* para ponerlos en servicios web.
O Runtime - Tiempo de ejecución SPI. Parte de JAX-WS, que
define el contrato entre el JAX-WS RI y tiempo de ejecución de Java
EE.
26
O Herramientas de SPI. Parta de JAX-WS, que define el contrato

entre las herramientas de JAX-WS RI y Java EE.
O JAXB XJC-API. El compilador del esquema.
O Runtime - Tiempo de ejecución JAXB-API. Parte del runtime de
JAXB que define el contrato entre el JAXB-RI y JAX-WS RI.
1. CONSTRUIR SERVICIOS WEB CON JAX-WS
JAX-WS significa Java API de Servicios Web XML. JAX-WS es una tecnología
para la creación de servicios web y los clientes que se comunican utilizando XML.
JAX-WS permite a los desarrolladores escribir códigos orientados a mensajes, así
como RPC- orientados a servicios web.
En JAX-WS, la operación de invocación de servicios Web está representada por un

protocolo basado en XML, como SOAP. La especificación SOAP define la
estructura de dotación, la codificación de las normas y las convenciones de
representación de las invocaciones de servicios web y las respuestas. Estas
llamadas y respuestas se transmiten como mensajes SOAP (archivos XML) a
través de HTTP.
Aunque los mensajes SOAP son complejos, el API JAX-WS oculta esta complejidad a
los desarrolladores de aplicaciones. Por el lado del servidor, especificaremos las
operaciones de servicio Web mediante la definición de métodos de una interfaz
escrita en el lenguaje de programación Java, además del código la/s
clase/s que implementa/n esos métodos.
Los programas del cliente también son fáciles de codificar. Un cliente crea un proxy
(un objeto local que representa el servicio) y luego simplemente invoca los
métodos en el proxy. Con JAX-WS, no tenemos que generar o analizar mensajes
SOAP sino que es el sistema del runtime de JAX-WS quien convierte las llamadas
de la API y las respuestas y de los mensajes SOAP.
Con JAX-WS, los clientes y los servicios web tienen una gran ventaja ya que son
independientes de la plataforma del lenguaje de programación Java. Además,
JAX-WS no es restrictiva: un cliente JAX-WS puede acceder a un servicio web que
no se ejecuta en la plataforma Java, y viceversa. Esta flexibilidad es posible gracias
a que JAX-WS utiliza tecnologías definidas por el World Wide Web Consortium
(W3C) como HTTP, SOAP, y el Lenguaje de Descripción de Servicios Web
(WSDL). WSDL especifica un formato XML para describir un servicio como un
conjunto de variables que operan en los mensajes.
27
2. CREAR UN SERVICIO WEB Y UN CLIENTE SENCILLO CON JAX-WS
El punto de partida para el desarrollo de un servicio Web JAX-WS es una clase Java
con la anotación javax.jws.WebService. La anotación @ WebService define la
clase como un servicio web endpoint.
Figura 2
Una interfaz de un servicio endpoint o la implementación de ese servicio (SEI)

es una interfaz o clase de Java, respectivamente, en la que se declara los métodos
que un cliente puede invocar en el servicio. Una interfaz NO es necesaria cuando se
construye un endpoint JAX-WS. La implementación de la clase en los servicios
web implícitamente define un SEI.
Podemos especificar una interfaz explícita añadiendo el elemento

endpointInterface a la anotación @ WebService en clase de implementación. A
continuación, tenemos que proporcionar una interfaz que define los métodos
públicos disponibles en la clase de implementación del endpoint.
Utilizaremos la clase de implementación del servicio endpoint y la herramienta

wsgen para generar los artefactos de servicios web que conectan a un cliente de
servicios web al runtime de JAX-WS. En definitiva, la herramienta wsgen y el
servidor de aplicaciones proporcionan la implementación del servidor de
aplicaciones de JAX-WS.
Estos son los pasos básicos para crear el servicio web y el cliente:
1. Codificar de la clase de implementación.
2. Compilar la clase de implementación.
3. Utilizar la herramienta Wsgen para generar los artefactos necesarios para
implementar el servicio.
4. Empaquetar los ficheros en un archivo WAR.
28
5. Distribuir el archivo WAR. Los artefactos del servicio Web (que se utilizan
para comunicarse con los clientes) son generados por el servidor de
aplicaciones durante la distribución.
6. Codificar la clase de cliente.
7. Utilizar wsimport para generar y compilar los artefactos de servicios web
necesarios para conectarse al servicio.
8. Compilar la clase de cliente.
9. Ejecutar el cliente.
3. REQUERIMIENTOS DE UN JAX-WS ENDPOINT
Los endpoint JAX-WS deben tener los siguientes requisitos:
• La clase de implementación debe ser anotado con javax.jws.WebService o

bien la anotación javax.jws.WebServiceProvider.
• La clase de implementación puede referenciar explícitamente a un SEI a

través del elemento endpointInterface de la anotación @ WebService,
pero no está obligado a hacerlo. Si no se especifica en endpointInterface
@ WebService, un SEI es implícitamente definido para la implementación
de dicha clase.
• Los métodos de negocios de la implementación de la clase deben ser

públicos, y no deben ser declarados static o final.
• Los métodos de negocio que están expuestos a los clientes de servicios web
deben ser anotados con javax.jws.WebMethod.
• Los métodos de negocio que están expuestos a los clientes de servicios web
deben tener parámetros JAXB compatibles y devolver tipos también
compatibles.
• La clase de implementación no debe declararse como final y no debe ser

abstract.
• La clase de implementación debe tener un constructor público

predeterminado.
• La clase de aplicación no debe definir el método finalize.
• La clase de implementación puede utilizar las anotaciones

javax.annotation.PostConstruct o javax.annotation.PreDestroy sobre
sus métodos de devolución de llamada de eventos del ciclo de vida.
29
Al método @ PostConstruct lo llama el contenedor antes que la clase de

implementación empiece a responder a los clientes de servicios web.
Al método @ PreDestroy lo llama el contenedor antes de que el endpoint se

elimine de la operación.
4. CODIFICAR LA CLASE DE IMPLEMENTACIÓN DEL SERVICIO ENDPOINT
Para ejecutar este ejemplo utilizaremos una herramienta portátil que está en el
servidor de aplicaciones que tengamos y que se llama “asant”. Esta herramienta
es una extensión de la herramienta Ant desarrollada por Apache Software
Foundation (http://ant.apache.org).
La utilidad asant contiene tareas adicionales que invocan la utilidad de

administración de Application Server asadmin.
En este ejemplo, la clase de implementación, Hola, está anotada como un servicio

endpoint mediante la anotación @ WebService. Hola declara un método único
llamado “sayHello”, anotado con la anotación @ WebMethod, esta anotación
expone el método a los clientes del servicio web. “sayHello” devuelve un saludo
para el cliente, utilizando el nombre que se pasó a “sayHello” para componer el
saludo. La clase de implementación también debe definir un valor predeterminado,
público y un constructor sin argumentos.
package helloservice.endpoint;
import javax.jws.WebService;
@WebService
public class Hello {
private String message = new String ("Hello, ");
public void Hello () {}
@WebMethod
public String sayHello (String name) {
return message + name + ".";
}
}
5. EMPAQUETAR Y DISTRIBUIR EL SERVICIO
Para construir el servicio HelloService iremos a una ventana terminal a

<INSTALL>/ruta/jaxws/helloservice/ y ejecutaremos:
asant build.
El comando de generación de tareas ejecuta estas subtareas asant:
30
• Compilación de servicio:
La compilación de tareas de servicio. Esta tarea asant compila Hello.java,
escribe ficheros class para construir los subdirectorios.
A continuación, llama a la herramienta “wsgen” para generar los artefactos

JAX-WS que utiliza el servicio Web. El comando equivalente de línea de
comandos es la siguiente:
wsgen –d build –s –classpath build helloservice.endpoint.Hello
a. El parámetro -d específica la ubicación de salida de los archivos de clase

generados.
b. El parámetro -s especifica la ubicación de salida de los archivos fuente
generados.
c. El parámetro -classpath específica la ubicación de los archivos de
entrada, en este caso la clase de implementación del endpoint
helloservice.endpoint.Hello.
• Empaquetado y distribución del servicio:
Durante la implementación, el servidor de aplicaciones y el runtime de

JAX-WS generan cualquier artefactos adicionales necesarios para la
invocación de servicios Web, incluyendo el WSDLarchivo.
Para empaquetar y distribuir el ejemplo HelloService, seguiremos estos

pasos:
1. En una ventana de terminal, iremos a <install> ruta/jaxws/helloservice

/.
2. Asant Run crear el fichero WAR.
3. Nos aseguraremos de que se inicie el servidor de aplicaciones.
4. Ponemos nuestro nombre usuario y contraseña en <install>

/ruta/common/build.properties.
5. Ejecutamos asant deploy.
Podemos ver el archivo WSDL del servicio implementado mediante la solicitud de la

dirección http://localhost:8080/helloservice/hello?wsdl en un navegador web.
31
6. TIPOS SOPORTADOS POR JAX-WS
JAX-WS delega las asignaciones de tipos de lenguaje de programación Java y

las definiciones XML para JAXB.
Nosotros como desarrolladores de aplicaciones no necesitamos conocer la detalles

de estas asignaciones, pero tenemos que ser conscientes de que no todas las
clases en el Lenguaje Java es pueden utilizar como un parámetro de método o tipo
de retorno en JAX-WS.
TIPO ESQUEMA XML TIPO DATO JAVA

xsd:string java.lang.String
xsd:integer java.math.BigInteger
xsd:int int
xsd.long long
xsd:short short
xsd:decimal java.math.BigDecimal
xsd:float float
xsd:double double
xsd:boolean boolean
xsd:byte byte
xsd:QName javax.xml.namespace.QName
xsd:dateTime javax.xml.datatype.XMLGregorianCalendar
xsd:base64Binary byte[]
xsd:hexBinary byte[]
xsd:unsignedInt long
xsd:unsignedShort int
xsd:unsignedByte short
xsd:time javax.xml.datatype.XMLGregorianCalendar
7. UN CLIENTE JAX-WS SIMPLE
HelloClient es un programa independiente de Java que accede al método sayHello

de HelloService. Se hace este llamamiento a través de un puerto, un objeto local
que actúa como un proxy para el servicio remoto. El puerto se crea en tiempo
de desarrollo con la herramienta de “wsimport”, que genera artefactos
portátiles JAX-WS basados en un archivo WSDL.
Al invocar los métodos remotos en el puerto, el cliente realiza estos pasos:
• Utiliza la anotación javax.xml.ws.WebServiceRef al declarar una referencia a

un servicio web. @ WebServiceRef utiliza el elemento wsdlLocation para
especificar el URI del archivo WSDL del servicio desplegado en.
32
@ WebServiceRef (wsdlLocation = "http://localhost:8080/helloservice/hello?wsdl")

static HelloService service
• Recupera un proxy para el servicio, también conocido como “port” puerto,

invocando getHelloPort en el servicioHello port = service.getHelloPort();
El puerto implementa el SEI definido por el servicio.
• Invoca al método sayHello de “port” pasando el nombre del servicio String

response = port.sayHello (name);
Código:
package simpleclient;
import javax.xml.ws.WebServiceRef;
import helloservice.endpoint.HelloService;
import helloservice.endpoint.Hello;
public class HelloClient {
@WebServiceRef (wsdlLocation="http://localhost:8080/
helloservice/hello? wsdl")
static HelloService service;
public static void main (String[] args) {
try {
HelloClient client = new HelloClient ();
client.doTest (args);
} catch (Exception e) {
e.printStackTrace ();
}
}
public void doTest (String[] args) {
try {
System.out.println ("Retrieving the port from
the following service: " + service);
Hello port = service.getHelloPort ();
System.out.println ("Invoking the sayHello operation
on the port.");
String name;
if (args.length > 0) {
name = args[0];
} else {
name = "No Name";
}
String response = port.sayHello (name);
System.out.println (response);
} catch (Exception e) {
e.printStackTrace ();
}
}
}
33
LECCION 2.JAXB VINCULACIÓN ENTRE LOS ESQUEMAS XML Y CLASES JAVA
INTRODUCCION
La arquitectura de Java para XML Binding (JAXB) proporciona una manera
rápida y conveniente para enlazar entre esquemas XML y las representaciones de
Java, haciendo más fácil para los desarrolladores de Java incorporar datos XML y
las funciones de procesamiento en aplicaciones Java.
Como parte de este proceso, JAXB proporciona métodos para unmarshalling

documentos de instancia XML en los árboles de contenido Java, y los árboles de
clasificación de contenido Java en documentos de instancia XML. JAXB también
proporciona una manera de generar esquemas XML a partir de objetos Java.
JAXB 2.0 incluye varias mejoras importantes sobre JAXB 1.0:
• Soporte para todas las características del W3C XML Schema. (JAXB 1.0 no
especifica los enlaces de algunas de las características del W3C XML Schema).
• Apoyo para la unión de Java a XML, con la adición del paquete de

javax.xml.bind.annotation para controlar este enlace. (JAXB 1.0 especifica el
mapeo de esquemas XML a Java, pero no de Java a XML Schema).
• Una reducción significativa en el número de esquemas generados

derivados de las clases.
• Las funciones de validación adicional a través de la API de JAXP 1.3 de

validación.
• Pequeñas bibliotecas de tiempo de ejecución.
34
1. ARQUITECTURA JAXB
Figura 3
Una aplicación JAXB consta de los componentes arquitectónicos siguientes:

• Compilador de esquema: Enlaza un esquema de origen a un conjunto de
esquemas derivados de los elementos del programa. La unión se describe con
un lenguaje XML basado en vínculos.
• Generador de esquema: Asigna un conjunto de elementos de programa

existentes a un esquema de derivados. La cartografía es descrita por las
anotaciones del programa.
• Marco vinculante de tiempo de ejecución (runtime): Proporciona

unmarshalling (lectura) y clasificación (por escrito) de las operaciones para
acceder, manipular, validar el contenido XML utilizando cualquiera de los
esquemas derivados o elementos de programa existentes.
35
1.1 PROCESOS DE VINCULACIÓN (UNION) DE JAXB
Figura 4
Los pasos generales en los datos JAXB en un proceso de vinculación son:
1. Generar clases: de un esquema XML que se utiliza como entrada para el

compilador de JAXB vinculante para generar clases JAXB sobre la base de ese
esquema.
2. Compilar las clases: Las clases generadas, los archivos de origen y código de
aplicación se tienen que compilar.
3. Unmarshal (Proceso de conversión de la secuencia de bytes a us dator u

objetos originales): Los documentos XML escritos de acuerdo a las restricciones
en el esquema de origen son “unmarshalizados” por el marco JAXB
vinculante. Hay que tener en cuenta que JAXB también soporta unmarshalling
de datos XML a partir de fuentes distintas de los archivos y documentos, tales
como nodos DOM, Fuentes de SAX etc.
4. Generar el árbol de contenido: El proceso de unmarshalling genera un árbol

de contenido de objetos de datos instancia de las clases JAXB generados;
contenido de este árbol representa la estructura y el contenido de los
documentos fuente XML.
5. Validar (opcional): El proceso de unmarshalling opcionalmente incluye la

validación de los documentos XML de origen antes de generar el árbol de
contenido. Tenga en cuenta que si modifica el árbol de contenido en el paso 6, a
36
continuación, también puede utilizar la operación JAXB Validar para validar los
cambios antes de clasificación del contenido de nuevo a un documento XML.
6. El contenido del proceso: La aplicación cliente puede modificar los datos XML
representado por el árbol de contenido Java por medio de interfaces generados
por el compilador vinculante.
7. Marshal (Clasificación) (Proceso de conversión de un objeto o un dato a una

secuencia de bytes): El árbol de contenido procesado es “Marshaleado” a uno
o más documentos de salida XML. El contenido se puede validar antes de la
clasificación.
Unmarshalling proporciona una aplicación cliente con la capacidad de convertir

datos XML en JAXB derivados de objetos Java. Por defecto, el Marshaller utiliza
codificación UTF-8, cuando genera datos XML.
En las aplicaciones de cliente no se requiere validar el árbol de contenido de Java

antes de realizar el Marshal. También hay algún requisito cómo que el árbol de
contenido Java sea válido con respecto a su esquema original para reunir de nuevo
los datos XML.
JAXB 2.0 permite la validación en Unmarshal y el tiempo Marshal. Un

modelo de procesamiento de un servicio Web de procesamiento tiene que ser más
permisivo en la lectura de los datos y más estricto en la escritura.
Para cumplir con este modelo, se añadió la validación en tiempo de Marshal por lo
que se puede confirmar que no invalida el documento XML cuando se modifique el
documento en forma de JAXB, ya que esto no pasaba en JAXB 1.0.
2. REPRESENTACIÓN DEL CONTENIDO XML
JAXB soporta la agrupación de clases generadas en los paquetes de Java. Un

paquete se compone de lo siguiente:
• Un nombre de clase Java que se deriva del nombre del elemento XML, o
especificado por un vínculo personalizado.
• Una clase ObjectFactory, que es una fábrica que se utiliza para devolver
instancias de la clase Java envolvente. Es conveniente utilizar los métodos de
esta clase, porque proporcionan una manera fácil de crear los elementos que se
tienen que representar por un JAXBElement <? Object>.
ObjectFactory objFact = new ObjectFactory ();

RulebaseType rulebase = objFact.createRulebaseType ();
JAXBElement <RulebaseType> doc = objFact.createRulebase (rulebase);
37
3. VINCULAR LOS ESQUEMAS XML
Un esquema describe los tipos de datos, con la intención de definir uno o más
tipos jerárquicos en la definición de los documentos XML. El tipo de información
se refiere a la definición de la estructura, es decir, la composición de los nodos
del documento, y la clasificación de escalar (o lista) para el contenido de los
valores y atributos.
El lenguaje de esquemas XML ofrece un buen conjunto de características para

lograr la estructuración necesaria. Una buena introducción al lenguaje XML
Schema es el XML Schema Parte 0: Introducción, suministrado por el World
Wide Web Consortium (W3C).
Aunque todos los datos en XML son texto, en general, no se deberían definir
como String de las clases Java que derivan de un esquema. El lenguaje de esquema
XML proporciona los tipos de datos elementales para los números, booleanos,
cadenas, URI, fechas y horas, las referencias y otras construcciones XML.
Sólo mediante el uso de estas características podremos obtener el beneficio

completo de JAXB, que no sólo se ocupará de todas las conversiones necesarias o
de la representación textual en XML, sino también con la transformación de las
estructuras de datos Java XML a patrones, como listas o mapas.
Los tipos de datos definidos por el usuario se pueden derivar de cualquier

tipo elemental mediante la adición de una o más restricciones.
Esto se hace mediante la adición llamada “facets”, que están disponibles para
establecer límites superiores o inferiores a los valores o longitud de las cadenas,
para limitar la precisión, para enumerar todos los valores justos, y definir un
modelo para un tipo de cadena. JAXB utiliza enumeraciones restringiendo cadenas
para definir un tipo enum. Sin embargo, otras facetas, son ignoradas por el
compilador de esquemas.
Los conceptos de estructuración de datos se expresan mediante el tipo

complejo constructor del lenguaje de esquema.
Un elemento XML de un tipo complejo puede tener elementos secundarios o

atributos o ambos. Para elementos secundarios, la agrupación de elementos en el
esquema son <xsd:all>, <xsd:union>, <xsd:choice> <xsd:sequence> y en
combinación con la repetición de atributos permiten definir las estructuras XML que
son el equivalente del clásico conceptos de matriz, lista, estructura (o registro) y la
unión.
38
Hay que tener en cuenta que las etiquetas de los elementos de esquema se
presentan en forma cualificada, con xsd como el identificador de espacio de
nombres.
Este (o algún otro nombre, por ejemplo, xs) identificador debe estar vinculado a la
URI que identifica el lenguaje XML Schema. Si se utiliza, también el prefijo de
espacio JXB deben estar vinculado. Ambos se hacen en el elemento schema del
esquema XML.
Un componente de esquema que utiliza una definición de tipo simple

normalmente se une a una propiedad de Java.
Puesto que hay diferentes tipos de componentes de esquema tantos como atributos
de propiedad Java (común a los componentes del esquema) incluyen:
• Tipo base.
• Tipo collection.
• Predicado.
El resto de los atributos de propiedad Java se especifican en el componente de

esquema utilizando la definición de tipo simple.
3.1 TIPO DE DATOS POR DEFECTO
Relación entres datos Schema y tipo de dato Java.
TIPO SCHEMA XML TIPO DE DATO JAVA

xsd:string java.lang.String
xsd:integer java.math.BigInteger
xsd:int int
xsd.long long
xsd:short short
xsd:decimal java.math.BigDecimal
xsd:float float
xsd:double double
xsd:boolean boolean
xsd:byte byte
xsd:QName Javax.xml.namespace.QName
xsd:dateTime javax.xml.datatype.XMLGregorianCalendar
xsd:base64Binary byte[]
xsd:hexBinary byte[]
xsd:unsignedInt long
xsd:unsignedShort int
xsd:unsignedByte short
xsd:time javax.xml.datatype.XMLGregorianCalendar
xsd:date javax.xml.datatype.XMLGregorianCalendar
xsd:g javax.xml.datatype.XMLGregorianCalendar
39
xsd:anySimpleType java.lang.Object
xsd:anySimpleType java.lang.String
xsd:duration Javax.xml.datatype.Duration
xsd:NOTATION Javax.xml.namespace.QName
Relación entre Tipo de Java y Tipo Schema.
TIPO DE DATO JAVA TIPO SCHEMA XML

java.lang.String xs:string
java.math.BigInteger xs:integer
java.math.BigDecimal xs:decimal
java.util.Calendar xs:dateTime
java.util.Date xs:dateTime
javax.xml.namespace.Qname xs:QName
java.net.URI xs:string
javax.xml.datatype.XMLGregorian-
xs:anySimpleType
Calendar
javax.xml.datatype.Duration xs:duration
java.lang.Object xs:anyType
java.awt.Image xs:base64Binary
javax.activation.DataHandler xs:base64Binary
javax.xml.transform.Source xs:base64Binary
java.util.UUID xs:string
4. PERSONALIZACIÓN DE LAS VINCULACIONES
La declaración de vinculaciones JAXB también se pueden personalizar para

generar las clases JAXB más allá de las limitaciones específicas de XML en un
esquema XML que se incluyen en las mejoras específicas de Java, tales como
asignaciones de clase y nombre del paquete.
JAXB proporciona dos formas de personalizar un esquema XML:
• Con anotaciones integradas en una fuente de esquema XML.
• Con declaraciones en un archivo de personalización exterior vinculante que

se pasa al compilador de JAXB vinculado.
4.1 ANOTACIONES
Las anotaciones JAXB definidas en el paquete de javax.xml.bind.annotations se
pueden utilizar para personalizar los elementos del programa de Java para el
mapeo de esquemas XML.
El código Java generado por el compilador de esquema JAXB contiene

anotaciones de metadatos que ofrecen paquetes, clases, campos y métodos.
40
Juntos, estos metadatos pretenden reflejar la información contenida en un esquema

XML, de las cuales sólo una parte muy pequeña puede ser expresada por el código
Java real.
Las anotaciones se pueden recuperar fácilmente de su objetivo de construir con los

métodos que figuran en las clases como java.lang.Class o
java.lang.reflect.Field.
Cada tipo de anotación tiene su propio conjunto de atributos, que se puede acceder
de la forma habitual. Habida cuenta de alguna clase, una anotación de tipo
XmlType se puede recuperar con:
Class clazz = ...;
XmlType typeAnn = clazz.getAnnotation (XmlType.class);
Si el resultado de la anotación no es nulo, se puede obtener los valores de los

elementos de anotación llamando a los métodos devueltos por el objeto XmlType.
Para recuperar el nombre del tipo correspondiente de esquema XML deberíamos

escribir
String schemaName = typeAnn.name ();
Las clases que pueden ser utilizar para la clasificación y la unmarshalización XML
NO tienen que generarse con el compilador de esquema JAXB. También es
posible escribir estas clases a mano, añadiendo las anotaciones JAXB.
A continuación veremos una serie de tablas con las anotaciones asociadas a

distintos elementos Java.
Tabla 1- Anotaciones asociadas a un paquete Java.
ANOTACIÓN
ASOCIADA A UN DESCRIPCIÓN Y PARÁMETROS POR DEFECTO
PAQUETE JAVA
Mapea un paquete en una etiqueta XML de tipo namespace.
@XmlSchema (
xmlns = {},
@XmlSchema namespace = "",
elementFormDefault = XmlNsForm.UNSET,
attributeFormDefault = XmlNsForm.UNSET
)
Controles de serialización por defecto de los campos y propiedades.

@XmlAccessorType (
@XmlAccessorType
value = AccessType.PUBLIC_MEMBER
)
Controla la ordenación predeterminada de las propiedades y campos

asignados a los elementos
@XmlAccessorOrder XML@XmlAccessorOrder (
value = AccessorOrder.UNDEFINED
)
41
Permite una asignación personalizada a un tipo esquema XML

integrado.
@XmlSchemaType (
@XmlSchemaType
namespace = "http://www.w3.org/2001/XMLSchema",
type = DEFAULT.class
)
Una anotación de contenedores para la definición de múltiples

@XmlSchemaTypes anotaciones @XmlSchemaType.
Parámetros por defecto: Ninguno
Tabla 2- Anotaciones asociadas a una clase Java.
ANOTACIÓN
ASOCIADA A UNA DESCRIPCIÓN Y PARÁMETROS POR DEFECTO
CLASE JAVA
Maps a Java class to a schema type.
@XmlType (
name = "##default",
propOrder = {""},
@XmlType
namespace = "##default",
factoryClass = DEFAULT.class,
factoryMethod = ""
)
Associates a global element with the schema type to which the class
is mapped.
@XmlRootElement (
@XmlRootElement
name = "##default",
namespace = "##default"
)
Tabla 3- Anotaciones asociadas a un tipo enum de Java.
ANOTACIÓN
ASOCIADA A UN
DESCRIPCIÓN Y PARÁMETROS POR DEFECTO
TIPO ENUM DE
JAVA
Mapas de un tipo Java a un tipo simple XML.
@XmlEnum
@XmlEnum ( value = String.class )
Mapas de un tipo Java a un tipo simple XML.

@XmlEnumValue
Parámetros por defecto: Ninguno.
Mapas de una clase de Java a un tipo Schema.

@XmlType (
name = "##default",
propOrder = {""},
@XmlType
factoryClass = DEFAULT.class,
factoryMethod = ""
)
Asocia un elemento global con el tipo de esquema al que se asigna a

la clase
@XmlRootElement (
@XmlRootElement
name = "##default",
)
42
Tabla 4- Anotaciones asociadas a propiedades y campos de Java.
ANOTACIONES
ASOCIADAS A
DESCRIPCIÓN Y PARÁMETROS POR DEFECTO
PROPIEDADES Y
CAMPOS DE JAVA
Asigna un JavaBeans propiedad/campo a un elemento XML
derivados de una propiedad o nombre de campo
@XmlElement (
name = "##default",
@XmlElement nillable = false,
type = DEFAULT.class,
defaultValue = "\u0000"
)
Un contenedor de anotaciones para la definición de múltiples

@XmlElements anotaciones @ XmlElement.
Mapas de una propiedad/campo de JavaBean a un elemento XML

derivados de una propiedad o campo
@XmlElementRef (
@XmlElementRef name = "##default",
type = DEFAULT.class
)
Un contenedor de anotaciones para la definición de múltiples

@XmlElementRefs anotaciones @XmlElementRef.
Genera un elemento contenedor en torno a una representación

XML. Normalmente, un elemento XML envuelto alrededor de las
colecciones
@XmlElementWrapper (
@XmlElementWrapper
name = "##default",
nillable = false
)
Asigna una propiedad JavaBeans a una representación del

conjunto de información XML y / o elemento JAXB.
@XmlAnyElement (
@XmlAnyElement
lax = false,
value = W3CDomHandler.class
)
Asigna una propiedad JavaBeans a un Atributo XML

@XmlAttribute (
name = ##default,
@XmlAttribute
required = false,
)
Asigna una propiedad JavaBeans a un mapa de atributos comodín.

@XmlAnyAttribute
Evita la asignación de una propiedad del JavaBean a una

@XmlTransient representación XML.
43
Define la asignación de una clase de tipo de esquema XML

@XmlValue complejo con un simpleContent o un tipo de esquema XML simple.
Asigna una propiedad JavaBeans a un XML ID.

@XmlID
Asigna una propiedad JavaBeans a un XML IDREF. Default

@XmlIDREF Settings:
Mapas de una propiedad a una lista de tipo simple.

@XmlList
Marca a un JavaBeans con propiedad multivalue para soportar

@XmlMixed contenido mixto.
Asocia el tipo MIME que controla la representación XML de la

@XmlMimeType propiedad.
Marca a un campo / propiedad de que su forma de XML es una

@XmlAttachmentRef referencia URI a contenido MIME.
Desactiva la opción de codificación XOP para tipos de datos que

@XmlInlineBinaryData están obligados a codificarse en base64 datos binarios en XML.
Tabla 5- Anotaciones asociadas a objetos Factory.
ANOTACIONES
ASOCIADAS A DESCRIPCIÓN Y PARÁMETROS POR DEFECTO
OBJETOS FACTORY
Mapas de un método factory a un elemento XML
@XmlElementDecl (
scope = GLOBAL.class,
@XmlElementDecl namespace = "##default",
substitutionHeadNamespace = "##default",
substitutionHeadName = ""
)
Tabla 6- Anotaciones asociadas con adaptadores.
ANOTACIONES
ASOCIADAS CON DESCRIPCIÓN Y PARÁMETROS POR DEFECTO
ADAPTADORES
Utilizamos el adaptador que se aplica la anotación @
XMLAdapter para personalizar la Marshalización.
@XmlJavaTypeAdapter
@XmlJavaTypeAdapter ( type = DEFAULT.class )
Una anotación de contenedores para la definición de múltiples

@XmlJavaTypeAdapters anotaciones @XmlJavaTypeAdapter.
44
5. UTILIZAR JAXB
Vamos a seguir con la “tradición” y el uso del ejemplo de documento XML "Hello
World" para mostrar un escenario típico para la creación de las clases Java y su
utilización para realizar un Marshal de documento.
• Paso 1.
El esquema XML en hello.xsd define la estructura de nuestro documento, que
contendrá una serie de saludos, cada uno de los cuales contiene un saludo (como
"Hola mundo") y un atributo para el registro de la lengua en la que se salude.
<xsd: schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
jxb: version="2.0">
<xsd: element name="Greetings" type="GreetingListType"/>
<xsd: complexType name="GreetingListType">

<xsd: sequence>
<xsd: element name="Greeting" type="GreetingType"
maxOccurs="unbounded"/>
</xsd: sequence>
</xsd: complexType>
<xsd: complexType name="GreetingType">

<xsd: sequence>
<xsd: element name="Text" type="xsd: string"/>
</xsd: sequence>
<xsd: attribute name="language" type="xsd: language"/>
</xsd: complexType>
</xsd: schema>
• Paso 2.
Ahora podemos llamar el compilador de esquema JAXB, definiendo el nombre del
paquete hello para las clases generadas.
xjc -p hello hello.xsd
Esto genera varias clases en el subdirectorio Hello. La clase Hello muestra cómo
usarlos.
import java.util.*;
import javax.xml.bind.*;
import hello.*;
public class Hello {
private ObjectFactory of;

private GreetingListType grList;
45
public Hello (){

of = new ObjectFactory ();
grList = of.createGreetingListType ();
}
public void make (String t, String l) {

GreetingType g = of.createGreetingType ();
g.setText (t);
g.setLanguage (l);
grList.getGreeting ().add (g);
}
public void marshal () {

try {
JAXBElement<GreetingListType> gl =
of.createGreetings ( grList );
JAXBContext jc = JAXBContext.newInstance ( "hello" );
Marshaller m = jc.createMarshaller ();
m.marshal ( gl, System.out );
} catch ( JAXBException jbe ){
// ...
}
}
}
• Paso 3.
El constructor utiliza un método de la fábrica de objetos para crear un objeto de la
parte superior del documento el nivel de tipo de elemento XML, es decir,
GreetingListType.
El método que añade otro saludo con su elemento de texto y el atributo del
lenguaje. Por último, con una llamada al mariscal, la lista se envuelve en su
elemento XML, y el documento XML resultante se escribe en la secuencia de salida
estándar. He aquí una secuencia de estas llamadas:
Hello h = new Hello ();

h.make ( "Bonjour, madame", "fr" );
h.make ( "Hey, you", "en" );
h.marshal ();
La salida se muestra a continuación, el formato, para una mejor legibilidad:
<? xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Greetings>
<Greeting language="fr">
<Text>Bonjour, madame</Text>
</Greeting>
<Greeting language="en">
46
<Text>Hey, you</Text>
</Greeting>
</Greetings>
47
LECCION 3. StAX (STREAMING API para XML)
INTRODUCCION
StAX nos permite crear analizadores XML bidireccionales que son rápidos,
relativamente fáciles de programar.
StAX proporciona la API más reciente en la familia JAXP, y es una

alternativa a SAX, DOM, TRAX, y DOM para los desarrolladores que quieran
realizar un alto rendimiento flujo de filtrado, procesamiento, modificación,
utilizando poca memoria y requisitos de extensibilidad limitada.
En resumen, Stax proporciona un estándar de interfaz bidireccional “pull parser”

o analizador pull para el streaming de procesamiento XML, ofreciendo un
modelo de programación más sencillo que SAX y la gestión de memoria más
eficiente que DOM.
StAX nos permite a los desarrolladores analizar y modificar las secuencias (stream)
XML como eventos, y para ampliar los modelos de información XML para permitir la
aplicación adiciones específicas.
1. STREAMING VS DOM
En términos generales, hay dos modelos de programación para trabajar con XML
InfoSets: documento de streaming y el Document Object Model (DOM).
• El modelo DOM implica la creación de objetos en memoria que

representa la totalidad de un árbol del documento y el conjunto de
información completo para un documento XML.
Una vez en la memoria, los árboles DOM pueden navegar libremente y
analizar la información de manera arbitraria, y como tal, proporcionar la
máxima flexibilidad para los desarrolladores.
Sin embargo, el costo de esta flexibilidad es un espacio en la memoria

potencialmente grande y los requisitos del procesador significativos,
como la representación de todo el documento debe ser creada en la
memoria, como objetos que duren toda la tramitación de documentos.
Esto no llega a ser un problema cuando se trabaja con documentos

pequeños, pero la memoria y el procesador de requisitos puede aumentar
rápidamente con el tamaño del documento.
• Streaming hace referencia a un modelo de programación en la que se

transmiten “infoSets” hojas de informe XML y analiza en tiempo de
48
ejecución de aplicación en serie, a menudo en tiempo real y de fuentes

dinámicas cuyo contenido no se conoce con precisión de antemano.
Además, esto implica la reducción de los requisitos de procesador, y un

mayor rendimiento en determinadas situaciones, como ver las infoSets en
un solo lugar en el documento.
Es decir estamos limitados a la vista de un documento, lo que implica que

necesitamos saber qué tratamiento deseamos hacer antes de leer el
documento XML.
Los modelos Streaming de procesamiento de XML son particularmente útiles

cuando nuestra aplicación tiene estrictas limitaciones de memoria, como con un
teléfono móvil funcionando con J2ME, o cuando nuestra aplicación necesita
procesar simultáneamente varias solicitudes, como con un servidor de aplicaciones.
De hecho, podríamos afirmar que la mayoría de la lógica de los negocios en XML

puede beneficiarse de procesamiento de flujo, y no requiere memoria para el
mantenimiento de los árboles DOM.
1.1. PULL PARSING VS PUSH PARSING
• Streaming Pull Parsing se refiere un modelo de programación en el que

una aplicación cliente llama a los métodos de una biblioteca de análisis XML
cuando se necesita interactuar con un infoSets XML, es decir, el cliente sólo
recibe los de datos XML de manera explícita cuando los pide.
• Streaming Push Parsing se refiere a impulsar un modelo de programación

en el que un analizador de XML envía (empuja) los datos XML al cliente
cuando el analizador encuentra elementos de una infoSets XML, es decir, el
analizador envía los datos si el cliente está listo para utilizarlos en ese
momento.
Pull Parsing ofrece varias ventajas sobre Push Parsing cuando se trabaja con
Secuencias XML:
1. El cliente controla el subproceso de la aplicación, y puede llamar a

métodos en el analizador cuando sea necesario. Por el contrario, con el proceso
push, el analizador controla el subproceso de la aplicación, y el cliente sólo
puede aceptar llamadas desde el analizador.
2. Las librerías de Pull Parsing pueden ser mucho más pequeñas y el

código de cliente que necesitemos para interactuar con las bibliotecas sea mucho
más sencillo que con las bibliotecas de Push, incluso para los más documentos
complejos.
49
3. Los clientes Pull pueden leer varios documentos al mismo tiempo con un
único subproceso.
4. Un analizador Pull puede filtrar documentos XML de tal manera que los
elementos innecesarios para el cliente se pueden ignorar, y además puede soportar
vistas XML de datos que no sean XML.
1.2. CASOS DE USO STAX
La especificación STAX define una serie de casos de uso para la API:
• El enlace de datos.
o Unmarshalling un documento XML.
o Marshalling un documento XML.
o Procesamiento de documentos en paralelo.
o Comunicación inalámbrica.
• Procesamiento de mensajes SOAP.

o Analizar las estructuras simples predecibles.
o Representación gráfica de análisis con las referencias hacia delante
(Forward).
o Análisis de WSDL.
• Fuentes de datos virtual.

o Visualización de datos XML almacenados en bases de datos.
o Visualización de datos en los objetos de Java creado por enlace de datos
XML.
o Navegar a un árbol DOM como una secuencia de eventos.
• Análisis de XML vocabularios específicos.

• Operaciones con "pipeline" de procesamiento de XML.
2. LA API STAX
La API de STAX tiene métodos para iterar el procesamiento basado en eventos de

de los documentos XML. Los documentos XML son tratados como una serie filtrada
de eventos, e infoSets de estado que se pueden almacenar en forma de
procedimiento.
Además, a diferencia de SAX, como ya hemos dicho la API de Stax es

bidireccional, por lo que permite tanto la lectura y la escritura de documentos
XML.
La API de STAX en realidad son dos distintos conjuntos de API: un cursor API y
un iterador API.
50
2.1. CURSOR API

Como su nombre indica, el cursor STAX API representa un cursor con el que se
puede caminar por un documento XML de principio a fin. Este cursor puede apuntar
solamente a una cosa a la vez, y siempre se mueve hacia adelante, nunca
hacia atrás, generalmente existe un infoSet de elemento a la vez.
Las dos principales interfaces cursor son XMLStreamReader y MLStreamWriter.

• XMLStreamReader incluye métodos de acceso para toda la información
posible accesible a partir del modelo de información XML, incluyendo la
codificación del documento, los nombres de elementos, atributos, espacios
de nombres, los nodos de texto, las etiquetas de inicio, los comentarios, el
procesamiento instrucciones, los límites de documento, etc.
Podemos llamar a métodos en XMLStreamReader, como getText y

getName, para obtener datos en la ubicación actual del cursor.
public interface XMLStreamReader {
public int next () throws XMLStreamException;
public boolean hasNext () throws XMLStreamException;
public String getText ();
public String getLocalName ();
public String getNamespaceURI ();
// ... other methods not shown}
• XMLStreamWriter proporciona métodos que corresponden a los tipos de

eventos startElement y EndElement, por ejemplo:
public interface XMLStreamWriter {
public void writeStartElement (String localName) \
throws XMLStreamException;
public void writeEndElement () \
public void writeCharacters (String text) \
// ... other methods not shown}
2.2. ITERADOR API

El iterador STAX API representa un flujo de documento XML como un conjunto de
discretos objetos de evento. Estos eventos son dados por la aplicación y
proporcionados por el analizador en el orden en que se lee en el documento XML
de origen.
51
La interfaz de iterador base se llama XMLEvent, hay subinterfaces para

cada tipo de evento. La interfaz del analizador primordial XMLEventReader, y la
interfaz principal para escribir el iterador de eventos es XMLEventWriter.
• La interfaz de XMLEventReader contiene cinco métodos, el más

importante es nextEvent (), que devuelve el siguiente evento en una
secuencia XML. XMLEventReader implementa java.util.Iterator, lo que
significa que los rendimientos de XMLEventReader se pueden almacenar
en la caché o pasarlos a las rutinas que pueden trabajar con el Iterator
estándar de Java.
Ejemplo:
public interface XMLEventReader extends Iterator {
public XMLEvent nextEvent () throws XMLStreamException;
public boolean hasNext ();
public XMLEvent peek () throws XMLStreamException;
...
}
Similarly, on the output side of the iterator API, you have:
public interface XMLEventWriter {
public void flush () throws XMLStreamException;
public void close () throws XMLStreamException;
public void add (XMLEvent e) throws XMLStreamException;
public void add (Attribute attribute) \
...
}
Tipos de Eventos del Iterador
• StartDocument: Informa del comienzo de una serie de eventos XML,

incluyendo la codificación, versión de XML, y propiedades independientes.
• StartElement: Informa del comienzo de un elemento, incluidos los atributos

y las declaraciones de espacio de nombres; también proporciona acceso al
prefijo URI de espacio de nombres, y nombre local de la etiqueta de inicio.
• EndElement: Informa de la etiqueta de cierre de un elemento. Los espacios

de nombres que han salido de ámbito de aplicación se pueden recordar aquí
si se han fijado explícitamente en sus correspondientes StartElement.
52
• Characters: Corresponde a las secciones XML CDATA y las entidades

CharacterData.
• EntityReference: Entidades de caracteres que se pueden reportar como

eventos discretos, una solicitud de desarrollador puede optar por resolver o
no resolver. De forma predeterminada, las entidades se resuelven.
Alternativamente, si queremos que el informe de la entidad sea tratado
como un evento, reemplazaremos el texto que puede sustituirse e
informaremos como Characters.
• ProcessingInstruction: Informa de la etiqueta y los datos para una

instrucción de procesamiento subyacente.
• Comment: Devuelve el texto de un comentario.
• EndDocument: Informa del final de un conjunto de eventos XML.
• DTD: Informa como java.lang.String nos da información sobre la DTD, si

están asociados con la secuencia (stream), y proporciona un método para
el retorno de objetos personalizados encontrados en la DTD.
• Atributo: Los atributos son generalmente reportados como parte de un

evento startElement. Sin embargo, hay ocasiones en que es conveniente
devolver un atributo como un atributo independiente, por ejemplo, cuando
un espacio de nombres se obtiene como resultado de una expresión XPath
o XQuery.
• Espacio de nombres: Al igual que con los atributos, los espacios de

nombres generalmente se reportan como parte de un StartElement, pero
hay veces que es mejor que un informe de espacio de nombre se reporte
como un evento de espacio de nombres discreto.
NOTA: La DTD, EntityDeclaration, EntityReference, NotationDeclaration, y eventos

ProcessingInstruction sólo se crean si el documento que se procesa, contiene una
DTD.
Ejemplo de cómo transmitir el evento iterador Maps API XML:
Considerando siguiente documento XML.
<? xml version="1.0"?>

<BookCatalogue xmlns="http://www.biblioteca.org">
<Book>
<Title>La Reina Del Yoga: the Science of Yoga</Title>
<ISBN>81-40-34319-4</ISBN>
<Cost currency="INR">11.50</Cost>
53
</Book>
</BookCatalogue>
Este documento se analiza en dieciocho eventos de primaria y secundaria, como se

muestra a continuación. Tengamos en cuenta que a los eventos secundarios, que se
muestra entre llaves ({}), se accede desde un evento primario en vez de
directamente.
ORDEN ELEMENTO/ATRIBUTO EVENTO

1 version="1.0" StartDocument
isCData = false
2 data = “\n” Characters
IsWhiteSpace = true
qname = BookCatalogue: http://www.biblioteca.org
attributes = null
3 StartElement
namespaces = {BookCatalogue” ->
http://www.biblioteca.org”}
qname = Book
4 attributes = null StartElement
namespaces = null
qname = Title
namespaces = null
isCData = false
6 data = “La Reina del Yoga: the Science of Yoga\n\t” Characters
IsWhiteSpace = false
qname = Title
7 EndElement
namespaces = null
qname = ISBN
namespaces = null
isCData = false
9 data = “81-40-34319-4\n\t” Characters
qname = ISBN
10 EndElement
namespaces = null
qname = Cost
11 attributes = {“currency” -> INR} StartElement
namespaces = null
isCData = false
12 data = “11.50\n\t” Characters
qname = Cost
13 EndElement
namespaces = null
isCData = false
IsWhiteSpace = true
qname = Book
15 EndElement
namespaces = null
isCData = false
IsWhiteSpace = true
54
qname = BookCatalogue: http://www.biblioteca.org

17 namespaces = {BookCatalogue” -> EndElement
http://www. biblioteca.org”}
18 EndElement
Hay varias cosas que destacar en el ejemplo anterior:
• Los eventos se crean en el orden en que los elementos correspondientes

se encuentran en el documento XML.
• Cómo debe ser la sintaxis XML adecuada, todos los elementos de contenedores
disponen de sus correspondientes eventos de inicio y fin acontecimientos, por
ejemplo, cada startElement tiene su correspondiente EndElement, incluso
para los elementos vacíos.
• Los eventos del atributo son tratados como eventos secundarios, y se accede
desde su evento startElement correspondiente.
• Similar a los eventos de atributos, los eventos de espacio de nombres se

consideran como secundarios, pero aparecen dos veces y se puede acceder en
dos ocasiones en la secuencia de eventos, primero desde de sus startElement
correspondientes y de sus correspondientes EndElement.
• Los eventos Character se especifican para todos los elementos, incluso si esos
elementos no tienen datos de carácter.
3. UTILIZAR STAX
En general, los programadores de STAX Streaming crean secuencias XML de
lectura y escritura, mediante los eventos de las clases XMLInputFactory,
XMLOutputFactory y XMLEventFactory.
La configuración se realiza mediante el establecimiento de las propiedades, cuando

se han realizado los ajustes específicos en la aplicación se pueden pasar a la
implementación subyacente utilizando el método setProperty ().
Del mismo modo, la configuración de una implementación específica se puede

consultar mediante el método getProperty () de Factory.
3.1. CLASES STAX FACTORY

Existen 3 clases Factory para StAX:
• XMLInputFactory.
• XMLOutputFactory.
• XMLEventFactory.
55
XML InputFactory
La clase XMLInputFactory permite configurar la implementación de las instancias

de las secuencias XML de procesos de lectura creados por el Factory.
Las nuevas instancias de la clase abstracta XMLInputFactory se crean llamando

al método newInstance () dentro de la clase. Es entonces cuando se utiliza el
método estático XMLInputFactory.newInstance () para crear una nueva
instancia Factory.
Derivando desde JAXP, el método XMLInputFactory.newInstance () determina

la implementación específica de la clase XMLInputFactory para cargar mediante
los siguientes procedimientos de búsqueda:
1. La propiedad del sistema javax.xml.stream.XMLInputFactory.

2. El fichero lib / xml.stream.properties en el directorio del JRE.
3. Los servicios API, si están disponibles, determinan el nombre de la clase mirando
en los archivos de META-INF/services/javax.xml.stream.XMLInputFactory
en los ficheros jars disponibles para JRE.
4. Usar la plataforma predeterminada XMLInputFactory.
Después de obtener una referencia a un XMLInputFactory apropiado, una aplicación

puede utilizar el objeto Factory para configurar y crear instancias de secuencia.
Tabla. Propiedades de XMLInputFactory.
PROPIEDAD DESCRIPCIÓN
Devuelve la validación de una
javax.xml.stream.isValidating
implementación.
(Requerido) Requiere el procesador
javax.xml.stream.isCoalescing datos que se unen con carácter
adyacente.
Devuelve el soporte del espacio de
Javax.xml.stream.isNamespaceAware
nombre.
(Requerida) Requiere el procesador
para reemplazar internamente las
referencias a las entidades con su
javax.xml.stream.isReplacingEntityReferences
valor reemplazado y reportarlas como
caracteres o conjunto de eventos que
describe la entidad.
(Requerida) Requiere el procesador
javax.xml.stream.isSupportingExternalEntities para resolver entidades analizadas
externamente.
(Requerida) Asignar y recoger la
javax.xml.stream.reporter implementación de la interfaz
XMLReporter.
javax.xml.stream.resolver implementación de la interfaz
XMLResolver.
56

javax.xml.stream.allocator implementación de la interfaz
XMLEventAllocator.
XML OutputFactory
Las nuevas instancias de la clase abstracta XMLOutputFactory se crean

llamando al método newInstance () en la clase. El método estático
XMLOutputFactory.newInstance () se utiliza para crear una nueva instancia
nueva factory.
El algoritmo utilizado para obtener la instancia es el mismo que para

XMLInputFactory pero referenciando a la propiedad del sistema
javax.xml.stream.XMLOutputFactory.
XMLOutputFactory admite sólo una propiedad,

javax.xml.stream.isRepairingNamespaces.
XML EventFactory
Las nuevas instancias de la clase abstracta XMLEventFactory se crean llamando

al método newInstance () en la clase.
El método estático XMLEventFactory.newInstance () se utiliza para crear una

nueva instancia factory. Esta instancia referencia a la propiedad
javax.xml.stream.XMLEventFactory.
El algoritmo utilizado para obtener la instancia es el mismo que para

XMLInputFactory y XMLOutputFactory pero las referencias es a la propiedad
del sistema javax.xml.stream.XMLEventFactory.
No hay propiedades por defecto para XMLEventFactory.
3.2. RECURSOS, ESPACIOS DE NOMBRE Y ERRORES
La especificación STAX maneja la asignación de recursos, atributos y espacio de

nombres, y los errores y excepciones que se describen a continuación.
Resolución de recursos
La interfaz XmlResolver proporciona un medio para establecer el método que

resuelve los recursos durante el procesamiento de XML. Una aplicación establece la
interfaz en XMLInputFactory, a continuación, establece la interfaz en todos los
procesadores creados por la instancia factory.
Los atributos y los espacios de nombres
57
Los atributos son reportados por un procesador de STAX utilizando métodos de

búsqueda, las cadenas en la interfaz del cursor, los eventos de atributos y Espacio
de nombres en la interfaz del iterador.
Informe de errores y manejo de excepciones
Todos los errores fatales son reportados por medio de

javax.xml.stream.XMLStreamException; y juntos con las advertencias se
registran utilizando la interfaz javax.xml.stream.XMLReporter.
3.3. LECTURA DE SECUENCIAS XML
Para leer los canales XML con un STAX lo más importante es el procesador, lo que
recibe varía considerablemente dependiendo de si está utilizando el cursor STAX
API o el iterador API.
XML StreamReader
La interfaz XMLStreamReader en el cursor STAX API le permite leer las

secuencias XML o documentos en un sólo sentido de avance, un ítem en la infoSet
de una vez.
Los siguientes métodos están disponibles para extraer datos de la secuencia o

saltarse los eventos no deseados:
• Obtener el valor de un atributo.

• Leer contenido XML.
• Determinar si un elemento tiene contenido o está vacío.
• Obtener acceso indexado a una colección de atributos.
• Obtener acceso indexado a una colección de espacios de nombres.
• Obtener el nombre del evento actual (si procede).
• Obtener el contenido del evento actual (si procede).
Cuando se crea una instancia de XMLStreamReader en

una secuencia, el evento inicial es el estado START_DOCUMENT. El método
XMLStream-Reader.next () se puede utilizar para pasar al siguiente evento en la
secuencia.
Leer propiedades, atributos y nombres de espacio
El método XMLStreamReader.next () carga las propiedades del próximo evento

en la secuencia. A continuación, podremos acceder a las propiedades mediante una
llamada a los métodos XMLStream-Reader.getLocalName () y
XMLStreamReader.getText ().
58
Cuando el cursor XMLStreamReader se encuentra sobre un evento

startElement, lee el nombre y los atributos para el evento, incluyendo el espacio
de nombres. Se puede acceder a los atributos de un evento con un valor de índice,
consultar los espacios de nombre URI y el nombre local.
Pero sólo están disponibles los espacios de nombres declarados en StartEvent

actual; si están previamente declarados no se mantienen, y los redeclarados no se
quitan.
Métodos XMLStreamReader
XMLStreamReader proporciona los siguientes métodos para recuperar información

sobre espacios de nombres y atributos.
int getAttributeCount ();

String getAttributeNamespace (int index);
String getAttributeLocalName (int index);
String getAttributePrefix (int index);
String getAttributeType (int index);
String getAttributeValue (int index);
String getAttributeValue (String namespaceUri, String localName);
boolean isAttributeSpecified (int index);
También se puede acceder a los Namespaces usando tres

métodos adicionales:
int getNamespaceCount ();

String getNamespacePrefix (int index);
String getNamespaceURI (int index);
Instanciando un XMLStreamReader
Este ejemplo, tomado de la especificación de Stax, muestra cómo una instancia de

un objeto InputFactory, crear un lector, e itera sobre los elementos de una
secuencia XML.
XMLInputFactory f = XMLInputFactory.newInstance ();

XMLStreamReader r = f.createXMLStreamReader ( ... );
while (r.hasNext ()) {
r.next ();
}
XML EventReader
La API de XMLEventReader proporciona los medios para mapear los eventos en

una secuencia XML de objetos de evento asignados que se pueden reutilizar
59
libremente, y la API en sí misma se puede extender para manejar eventos

personalizados.
XMLEventReader ofrece cuatro métodos para analizar de forma iterativa secuencias

XML:
• next (): Devuelve el evento siguiente en el Stream.
• nextEvent (): Devuelve el siguiente XMLEvent.
• hasNext (): Devuelve true si hay más eventos para procesar en el Stream.
• peek (): Devuelve el evento pero no itera al siguiente evento.
Ejemplo.
package javax.xml.stream;
import java.util.Iterator;
public interface XMLEventReader extends Iterator {
public Object next ();
public XMLEvent nextEvent () throws XMLStreamException;
public boolean hasNext ();
public XMLEvent peek () throws XMLStreamException;
...
}
Para leer todos los eventos en una secuencia e imprimirlos utilizaríamos el siguiente
código:
while (stream.hasNext ()) {

XMLEvent event = stream.nextEvent ();
System.out.print (event);
}
Leer Atributos
Podemos acceder a los atributos desde su asociado

javax.xml.stream.StartElement de la siguiente manera:
public interface StartElement extends XMLEvent {

public Attribute getAttributeByName (QName name);
public Iterator getAttributes ();
}
Podemos usar el método getAttributes () en la interface StarElement para

utilizar un Iterador de todos los atributos declarados en StartElement.
Leer Namespaces
Similares a los atributos de lectura, los espacios de nombres se leen mediante un

Iterador llamando al método getNamespaces () en la interfaz startElement.
60
Sólo devuelve el espacio de nombres para la startElement actual, de tal manera

que una aplicación puede obtener el contexto del actual espacio de nombres
mediante el método StartElement.getNamespaceContext ().
3.4. ESCRIBIR SECUENCIAS XML
STAX es una API bidireccional, y tanto el cursor API como el iterador de evento
tienen sus propios conjuntos de interfaces para escribir secuencias XML. Al igual
que con las interfaces para la lectura de secuencias, hay diferencias significativas
entre las API de escritura para el cursor y el iterador de eventos.
Interfaz XML StreamWriter
La interfaz de XMLStreamWriter permite a las aplicaciones escribir de nuevo una

secuencia XML o crearla totalmente nueva. XMLStreamWriter tiene métodos que
permiten:
• Escribir XML bien formado.
• Flush o cierre de salida.
• Escribir nombres calificados.
Las implementaciones de XMLStreamWriter no son requeridas para realizar

comprobaciones de su validez en la entrada.
Mientras que algunas implementaciones tienen que realizar la comprobación de

errores estrictos, otras no.
Las normas que se decidan para implementar se establecen en las propiedades

proporcionadas por la clase XMLOutputFactory.WriteCharacters (...).
El siguiente ejemplo, tomado de la especificación de Stax, muestra cómo crear

una instancia de objeto Factory, crear un writer y escribir código XML:
XMLOutputFactory output = XMLOutputFactory.newInstance ();

XMLStreamWriter writer = output.createXMLStreamWriter ( ... );
writer.writeStartDocument ();
writer.setPrefix ("c","http://c");
writer.setDefaultNamespace ("http://c");
writer.writeStartElement ("http://c","a");
writer.writeAttribute ("b","blah");
writer.writeNamespace ("c","http://c");
writer.writeDefaultNamespace ("http://c");
writer.setPrefix ("d","http://c");
writer.writeEmptyElement ("http://c","d");
writer.writeAttribute ("http://c","chris","fry");
writer.writeNamespace ("d","http://c");
61
writer.writeCharacters ("foo bar foo");

writer.writeEndElement ();
writer.flush ();
Este código genera el siguiente XML.
<? xml version='1.0' encoding='utf-8'?>

<a b="blah" xmlns: c="http://c" xmlns="http://c">
<d: d d: chris="fry" xmlns: d="http://c"/>foo bar foo</a>
XML EventWriter
La interface XMLEventWriter permite a las aplicaciones escribir una secuencia

XML o crear nuevas secuencias enteras.
Esta API se puede extender, pero lo importante de la API es el siguiente código:
public interface XMLEventWriter {

public void flush () throws XMLStreamException;
public void close () throws XMLStreamException;
public void add (XMLEvent e) throws XMLStreamException;
//... other methods not shown.
}
Los casos de XMLEventWriter son creados por una instancia de

XMLOutputFactory. Los eventos Stream se añaden de forma iterativa, y un
evento no puede ser modificado después de que se ha añadido a una instancia del
evento.
Atributos, Caracteres de escape, Prefijos de enlace
Las implementaciones STAX se requieren para almacenar en el buffer el último

startElement hasta que un evento, atributo o espacio de nombres se agrega o se
encuentran en el stream. Esto significa que cuando se agrega un atributo o un
espacio de nombres a un stream, se anexa el evento startElement actual.
Podemos utilizar métodos Characters para los caracteres de escape como &, <,
>, y “.
El método setPrefix (...) se puede utilizar para obligar a un prefijo de forma

explícita su uso durante la salida, y el método getPrefix (...) se puede utilizar para
obtener el prefijo actual.
Por defecto, XMLEventWriter añade enlaces de espacio de nombres para su

mapeo de espacio de nombres interno.
62
EJERCICIOS DE REPASO DEL TEMA 2: TECNOLOGÍAS DE SERVICIOS WEB
ENUNCIADOS.
1. API Java para vinculación XML (JAX-B) ...
2. WSDL se usa para describir los servicios disponibles.
3. ¿Cuál de estos no son elementos WSDL?
4. Schema es una alternativa basada en:
5. La API StAX es:
63
1. La Respuesta Correcta es: La 2, Se puede utilizar para leer y escribir XML

mediante clases Java generadas a partir de un esquema XML.
2. La Respuesta Correcta es: La 1, Verdadero.
3. La Respuesta Correcta es: La 4, Destino.
4. La Respuesta Correcta es: La 3, XML.
5. La Respuesta Correcta es: La 2, Bidireccional.
64
TEMA 3. OTRAS TECNOLOGÍAS DE SERVICIOS WEB
LECCION 1. SAAJ. SOAP CON ATTACHMENTS API PARA JAVA
INTRODUCCION
SOAP with Attachments API for Java (SAAJ) se utiliza principalmente para la
mensajería SOAP que sucede detrás de las escenas de los controladores de JAX-
WS y de las implementaciones de JAXR.
También, es una API que los desarrolladores podemos utilizar cuando queramos
escribir aplicaciones de mensajería SOAP directamente en lugar de utilizar JAX-
WS. El API SAAJ nos permite hacer mensajería XML en la plataforma Java.
La API de SAAJ se ajusta a las especificaciones de Simple Object Access

Protocol (SOAP) 1.1 y 1.2. y a la especificaciones de SOAP Attachments
(datos adjuntos).
La especificación SAAJ 1.3 define el paquete de javax.xml.soap, que contiene

la API para crear y llenar un mensaje SOAP. Este paquete tiene todas las API
necesarias para el envío de mensajes de petición y de respuesta.
1. MENSAJES
Los mensajes de SAAJ siguen los estándares SOAP, que determinarán el

formato de los mensajes y también precisan algunas cosas que son requeridos,
opcionales o no permitidas.
Con la API de SAAJ, podemos crear mensajes XML que se ajusten a las
especificaciones SOAP 1.1 o 1.2 y la especificación WS-I Basic Profile 1.1
simplemente por hacer llamadas a la API de Java.
1.1. ESTRUCTURA DE UN DOCUMENTO XML
Un documento XML tiene una estructura jerárquica compuesta de elementos,

subelementos, subsubelementos, y así sucesivamente.
Notaremos que muchas de las clases e interfaces SAAJ representan elementos XML
en un mensaje SOAP y tienen la palabra “element” o “SOAP” (o ambos) en sus
nombres.
Un elemento también se conoce como nodo. Por lo que, la API SAAJ tiene la
interfaz Node, que es la clase base para todas las clases e interfaces que
representan los elementos XML en un mensaje SOAP. También hay métodos como
la SOAPElement.addTextNode, Node.detachNode, y Node.getValue.
65
1.2. QUE ES UN MENSAJE
Los dos tipos principales de mensajes SOAP son los que tienen datos adjuntos y
los que no lo tienen.
Los mensajes que no tienen archivos adjuntos (No Attachments)
El siguiente esquema muestra la estructura a muy alto nivel de un mensaje

SOAP sin archivos adjuntos. A excepción de la cabecera SOAP, se necesitan
todas las partes enumeradas en cada mensaje SOAP.
I. Mensaje SOAP
A. Parte de SOAP
1. Sobre SOAP
a. Cabecera SOAP (opcional)
b. Cuerpo SOAP
La API de SAAJ proporciona la clase SOAPMessage para representar a un

mensaje SOAP, la clase SOAPPart para representar a la parte de SOAP, la
interfaz de SOAPEnvelope para representar a la envoltura SOAP, y así
sucesivamente.
Cuando se crea un objeto nuevo SOAPMessage, automáticamente se dispone de

las partes que se necesitan para un mensaje SOAP. En otras palabras, un nuevo
SOAPMessage objeto tiene un objeto SOAPPart que contiene un objeto
SOAPEnvelope.
El SOAPEnvelope objeto a su vez automáticamente contiene un objetos vacío

SOAPHeader seguido por un objeto SOAPBody vacío.
Si no necesitamos el objeto SOAPHeader, que es opcional, lo podemos eliminar. El

objeto SOAPHeader puede incluir una o más cabeceras que contienen metadatos
sobre el mensaje (por ejemplo, información sobre el envío y recepción
de las partes del mensaje).
El objeto SOAPBody, que siempre sigue el objeto SOAPHeader si hay uno,

contiene el contenido del mensaje. Si hay un objeto SOAPFault, debe ser en el
objeto SOAPBody.
En la siguiente imagen vemos la estructura de un mensaje SOAP sin archivos

adjuntos.
66
Figura 1
Mensajes con archivos adjuntos (Attachment)
Un mensaje SOAP puede incluir una o más partes de archivos adjuntos, además de
la parte de SOAP. La parte de SOAP debe contener sólo el contenido XML,
como resultado, si cualquier parte del contenido del mensaje no está en formato
XML, debe ir en un archivo adjunto parte.
Así que si, por ejemplo, queremos que nuestro mensaje contenga un archivo
binario, el mensaje debe tener una parte adjuntada para ello. Tengamos en cuenta
que la parte adjuntada puede tener cualquier tipo de contenido, ya que puede
contener datos en formato XML.
Si un objeto SOAPMessage tiene uno o más archivos adjuntos, cada objeto

AttachmentPart tiene que tener un encabezado MIME para indicar el tipo de
datos que contiene.
También se puede tener encabezados MIME adicionales para identificar o dar su

ubicación. Estas cabeceras son opcionales, pero puede ser útil cuando hay varios
archivos adjuntos.
67
Cuando un objeto SOAPMessage tiene uno o más objetos AttachmentPart, su

objeto SOAPPart puede o no contener el contenido del mensaje.
La siguiente imagen muestra la estructura de un mensaje con archivos adjuntos.
Figura 2
2. OBJETOS DE CONEXIÓN SOAP
Todos los mensajes SOAP son enviados y recibidos a través de una conexión. Con
la API SAAJ, la conexión se representa por el objeto SOAPConnection, que va
desde el remitente directamente a su destino.
Este tipo de conexión se denomina conexión de punto-a-punto, porque va de

un extremo a otro extremo.
68
Los mensajes enviados utilizando el API de SAAJ se llaman los mensajes de

solicitud de respuesta.
Estos se envían a través de un objeto SOAPConnection con el método Call, que

envía un mensaje (request) y se bloquea hasta que se recibe la respuesta
(response).
2.1. OBJETO SOAPConnection
En el siguiente fragmento de código se crea el objeto de conexión

SOAPConnection y luego, después de crear y llenar el mensaje, utiliza la conexión
para enviar el mensaje. El valor de retorno para el método Call es el
Objeto SOAPMessage que es la respuesta al mensaje que se envió.
El parámetro de solicitud es el mensaje que se envía; representa el punto final

donde se envían.
SOAPConnectionFactory factory =
SOAPConnectionFactory.newInstance ();
SOAPConnection connection = factory.createConnection ();
. . . // create a request message and give it content
java.net.URL endpoint =
new URL ("http://ejemplos.com/ejem/order");
SOAPMessage response = connection.call (request, endpoint);
Notar que en el segundo argumento del método Call, que identifica el

mensaje se está enviando, puede ser un objeto String o un objeto URL. Así, las
dos últimas líneas de código del ejemplo anterior también podrían haber sido de la
siguiente manera:
String endpoint = "http://ejemplos.com/ejem/order";

SOAPMessage response = connection.call (request, endpoint);
Un servicio web implementado para la mensajería de request-response tiene

que devolver un respuesta a cualquier mensaje que reciba. La respuesta y la
petición son objetos SOAPMessage.
Cuando el mensaje de petición es una actualización, la respuesta es una

confirmación de que se ha recibido la actualización y que se realizó correctamente.
Puede que algunos mensajes no necesiten ninguna respuesta.
El servicio que recibe ese mensaje es todavía necesario para devolver una
respuesta, porque se necesita para desbloquear el método Call.
69
En este caso, la respuesta no está relacionada con el contenido del mensaje, sino
que es simplemente un mensaje para desbloquear dicho método.
2.2. CREACIÓN DE UN MENSAJE
El primer paso es crear un mensaje utilizando un objeto MessageFactory. La

API SAAJ proporciona una implementación por defecto de la clase
MessageFactory, lo que hace que sea fácil obtener una instancia.
El fragmento de código siguiente nos muestra cómo conseguir una

instancia de un mensaje Factory predeterminado y luego usarla para crear un
mensaje.
MessageFactory factory = MessageFactory.newInstance ();

SOAPMessage message = factory.createMessage ();
Como es true el método newInstance para SOAPConnectionFactory, el

método newInstance para MessageFactory es estático, por lo que se invoca
llamando MessageFactory.newInstance.
Si no especifica ningún argumento al método newInstance, crea un mensaje

Factory para mensaje SOAP 1.1. Para crear un mensaje Factory que nos permita
crear y procesar mensajes SOAP 1.2, utilizaremos la llamada al método siguiente:
MessageFactory factory =
MessageFactory.newInstance (SOAPConstants.SOAP_1_2_PROTOCOL);
Para crear un mensaje Factory que pueda crear mensajes SOAP 1.1 o SOAP 1.2,
realizaremos de la llamada al método siguiente:
MessageFactory factory =
MessageFactory.newInstance (SOAPConstants.DYNAMIC_SOAP_PROTOCOL);
Este tipo de Factory nos permite procesar un mensaje de entrada que podría ser
de cualquier tipo.
Partes de un Mensaje
Un objeto SOAPMessage tiene que tener ciertos elementos, y, como se dijimos

anteriormente, la API SAAJ nos simplifica las cosas gracias al retorno de un nuevo
objeto SOAPMessage ya contiene estos elementos.
Cuando llamamos a createMessage sin argumentos, el mensaje se crea

automáticamente con los siguientes elementos:
I. Un objeto que contiene SOAPPart:
70
A. Un objeto que contiene SOAPEnvelope:

1. Un objeto SOAPHeader vacío.
2. Un objeto SOAPBody vacío.
El objeto SOAPHeader es opcional y se puede eliminar si no se necesita. Sin

embargo, si lo hay, debe preceder el objeto SOAPBody, este objeto puede llevar
el contenido del mensaje o un mensaje fault que contiene el estado de la
información o detalles acerca de un problema con el mensaje.
2.3. ACCESO A LOS ELEMENTOS DE UN MENSAJE
El siguiente paso en la creación de un mensaje es acceder a sus partes de manera

que el contenido pueda ser agregado. Hay dos maneras de hacer esto:
• La primera forma de acceder a las partes del mensaje mediante la

estructura del mensaje. El mensaje contiene un objeto SOAPPart, por lo que
utilizaremos el método getSOAPPart de mensaje para recuperarlo.
SOAPPart soapPart = message.getSOAPPart ();
A continuación, podemos utilizar el método getEnvelope de soapPart

para recuperar el objeto SOAPEnvelope que contiene.
SOAPEnvelope envelope = soapPart.getEnvelope ();
Ahora podemos utilizar los métodos getHeader y getBody de envelope

para recuperar su objeto vacío SOAPHeader y el objeto SOAPBody.
SOAPHeader header = envelope.getHeader ();

SOAPBody body = envelope.getBody ();
• La segunda forma de acceder a las partes del mensaje es recuperar el

mensaje de encabezado y el cuerpo directamente, sin recuperar el SOAPPart
o SOAPEnvelope.
Para hacerlo, utilizaremos los métodos getSOAPHeader y getSOAPBody de

SOAPMessage:
SOAPHeader header = message.getSOAPHeader ();

SOAPBody body = message.getSOAPBody ();
Hasta ahora hemos visto un cliente SAAJ que no utiliza un encabezado SOAP, por lo
que se puede borrar. Cómo todos los objetos SOAPElement, incluyendo objetos
SOAPHeader, se derivan de la interfaz Node, se utiliza el método Node.detachNode
método para eliminar cabecera.
71
header.detachNode ();
2.4. AÑADIR CONTENIDO AL CUERPO DEL MENSAJE
Para añadir contenido al cuerpo, normalmente crearemos uno o más objetos

SOAPBodyElement, también podemos añadir subelementos con el método
addChildElement.
Para cada elemento o elemento hijo, añadiremos contenido utilizando el método

addTextNode.
El fragmento de código siguiente recupera el objeto SOAPBody del mensaje,

construye un objeto QName para el elemento que se añade, y añade un nuevo
objeto SOAPBodyElement al cuerpo.

QName bodyName = new QName ("http:// prueba.ejemplos.com ",
"GetLastTradePrice", "m");
SOAPBodyElement bodyElement = body.addBodyElement (bodyName);
En este punto, el cuerpo contiene un SOAPBodyElement objeto identificado por

el objeto QName bodyName, pero aún no hay contenido en bodyElement.
QName name = new QName ("symbol");

SOAPElement symbol = bodyElement.addChildElement (name);
symbol.addTextNode ("SUNW");
El contenido que acabamos de agregar al objeto SOAPBody se verá así

cuando se envíe:
Código:
<SOAP-ENV: Envelope
xmlns:SOAP-ENV="http://esquemas.xmlsoap.com/soap/envelope/">
<SOAP-ENV: Body>
<m: GetLastTradePrice xmlns:m="http://prueba.ejemplos.com">
<symbol>SUNW</symbol>
</SOAP-ENV: Body>
Este sería el código SAAJ:

SOAPMessage message = messageFactory.createMessage ();
SOAPHeader header = message.getSOAPHeader ();
Este es el XML que se produce:
72
<SOAP-ENV: Envelope
xmlns: SOAP-ENV="http:// esquemas.xmlsoap.com/soap/envelope/">
<SOAP-ENV: Header/>
<SOAP-ENV: Body>
...
</SOAP-ENV: Body>
Este sería el código SAAJ:
QName bodyName = new QName ("http:// prueba.ejemplos.com",

"GetLastTradePrice", "m");
SOAPBodyElement bodyElement = body.addBodyElement (bodyName);
Here is the XML it produces:
<m: GetLastTradePrice
xmlns: m="http:// prueba.ejemplos.com">
....
QName name = new QName ("symbol");
SOAPElement symbol = bodyElement.addChildElement (name);
symbol.addTextNode ("SUNW");
Este es el XML que se produce:

<symbol>SUNW</symbol>
2.5. ENVIAR UN MENSAJE

Un cliente SAAJ llama al método SOAPConnection en un objeto
SOAPConnection para enviar un mensaje.
El método Call toma dos argumentos: el mensaje a enviar y el destino al que el
mensaje debería ir.
Este mensaje va a la cuota de servicio indicada en el objeto URL endpoint.
java.net.URL endpoint = new URL ("http:// prueba.ejemplos.com/quotes");

SOAPMessage response = connection.call (message, endpoint);
Una conexión utiliza muchos recursos, por lo que es una buena idea cerrar una
conexión tan pronto como hayamos terminado de utilizarla con:
connection.close ();
2.6. OBTENER EL CONTENIDO DE UN MENSAJE

Los primeros pasos para recuperar el contenido de un mensaje son los mismos que
para añadir contenido a un mensaje: o se utiliza el objeto Message para obtener
el objeto SOAPBody, o tenemos acceso al objeto SOAPBody a través de los
objetos SOAPPart y SOAPEnvelope.
73
Para obtener el contenido, que se agregó con el método de

SOAPElement.addText - Nodo, se llama al método Node.getValue. Hay que
tener en cuenta que devuelve el valor getValue del hijo del elemento que llama al
método.
Para acceder a bodyElement, se llama al método getChildElements en

SOAPBody. Si se pasa bodyName a getChildElements devuelve un objeto
java.util.Iterator que contiene todos los elementos secundarios identificados por
el objeto Name de bodyName.
SOAPBody soapBody = response.getSOAPBody ();

java.util.Iterator iterator =
soapBody.getChildElements (bodyName);
SOAPBodyElement bodyElement =
(SOAPBodyElement) iterator.next ();
String lastPrice = bodyElement.getValue ();
System.out.print ("El ultimo precio de SUNW es ");
System.out.println (lastPrice);
Si tuviéramos más de un elemento con el nombre bodyName, tendríamos que

usar un el bucle while con el método Iterator.hasNext para asegurarnos de que
tenemos todos.
while (iterator.hasNext ()) {

SOAPBodyElement bodyElement =
(SOAPBodyElement) iterator.next ();
String lastPrice = bodyElement.getValue ();
System.out.print ("El ultimo precio de SUNW es ");
System.out.println (lastPrice);
}
74
LECCION 2. JAXR JAVA API FORM XML REGISTRIES
1. ¿QUÉ ES UN REGISTRO?
Un registro de XML es una infraestructura que permite la creación,

implementación y descubrimiento de servicios web. Un registro está disponible para
las organizaciones como un recurso compartido, a menudo en forma de servicio
web.
Actualmente hay una variedad de especificaciones para los registros XML.

Estos incluyen:
• El Registro webXML y el nivel del repositorio, que es patrocinado por la

Organización para el Avance de las Normas de Información
Estructurada (OASIS) y el Centro de las Naciones Unidas para la
Facilitación de Procedimientos de y prácticas en administración,
comercio y transporte (UN / CEFACT).
• El proyecto Universal, Discovery, and Integration (UDDI), que está

siendo desarrollado por un consorcio de proveedores. Un proveedor de registro
es una implementación de un registro de empresas que se ajusta a un pliego de
condiciones para los registros XML.
2. ¿QUÉ ES JAXR?
JAXR nos permite a los programadores de software de Java utilizar una única y
fácil abstracción API para acceder a una variedad de registros XML. El modelo
unificado de información JAXR describe el contenido y los metadatos en los
registros XML.
JAXR ofrece a los desarrolladores la capacidad de escribir programas cliente de

registro que son portátiles a través de los registros de los distintos
destinatarios.
Service Registry, es un registro y repositorio ebXML con un proveedor de

JAXR, que está disponible como parte de la Sun Java Enterprise System.
3. ARQUITECTURA JAXR
La arquitectura de alto nivel de JAXR consta de las siguientes partes:
• Un cliente JAXR: Este es un programa cliente que utiliza la API JAXR para
acceder a un registro de negocios a través de un proveedor de JAXR.
75
• Un proveedor de JAXR: Esta es una implementación de la API JAXR que

proporciona el acceso a un proveedor de registro específico o una clase de
registro de proveedores que se basan en una especificación común.
Un proveedor de JAXR implementa dos paquetes principales:
1. javax.xml.registry, que consta de las interfaces y las clases API

que definen la interfaz de acceso al registro.
2. javax.xml.registry.infomodel, que consta de interfaces que definen
el modelo de información para JAXR. Estas interfaces determinan los
tipos de objetos que residen en un registro y cómo se relacionan entre
sí. La interfaz base en este paquete es la interfaz de RegistryObject.
Su subinterfaces incluyen Organization, Service y ServiceBinding.
Las interfaces más básicas en el paquete javax.xml.registry son:

• Connection. Representa una sesión de cliente con un
proveedor de registro. El cliente debe crear una conexión con el proveedor
de JAXR con el fin de utilizar un registro.
• RegistryService. El cliente obtiene un objeto de su conexión. El objeto
RegistryService a su vez permite al cliente obtener las interfaces que utiliza
para acceder al Registro.
Las interfaces primarias, también forman parte del paquete de

javax.xml.registry, y son:
• BusinessQueryManager, permite al cliente buscar un registro de

información de acuerdo con las interfaces javax.xml.registry.infomodel.
La interfaz opcional, DeclarativeQueryManager, permite al cliente utilizar
la sintaxis SQL para las consultas. (La aplicación de JAXR en el Application
Server no aplica DeclarativeQueryManager).
• BusinessLifeCycleManager, permite al cliente modificar la información

en un registro guardarlo (actualización), o bien borrarlo.
Cuando ocurre un error, los métodos la API JAXR lanzan una JAXRException o
una de sus subclases.
Muchos métodos de la API JAXR utilizan un objeto Collection como un argumento

o un valor de retorno. Al utilizar este objeto nos permite realizar operaciones en el
registro de varios objetos a la vez.
La siguiente imagen nos muestra la arquitectura de JAXR. En el servidor de

aplicaciones, un cliente JAXR utiliza el nivel 0 interfaces de la API JAXR para
acceder al proveedor JAXR.
76
El proveedor de JAXR a su vez tiene acceso a un registro. El servidor de

aplicaciones suministra un proveedor de JAXR para los registros UDDI.
Figura 3
4. IMPLEMENTAR UN CLIENTE JAXR
Un cliente JAXR es un programa cliente que puede acceder a los registros usando
la API JAXR. Los pasos básicos a seguir para implementar un cliente JAXR que
permite realizar consultas y actualizaciones a un registro UDDI son:
• Establecer una conexión.

• Consultar un registro.
• Gestión de datos del Registro.
• Uso de las taxonomías en los clientes JAXR.
Un proveedor de JAXR proporciona una implementación de la especificación de

JAXR que permite el acceso a un proveedor de registro existente, tales como un
registro UDDI o ebXML.
La aplicación de JAXR en el servidor de aplicaciones en sí es un ejemplo de un

proveedor de JAXR. El servidor de aplicaciones proporciona JAXR en la forma de un
adaptador de recursos utilizando la arquitectura Java EE Connector.
77
4.1. ESTABLECER UNA CONEXIÓN
La primera tarea que un cliente JAXR debe completar es establecer una conexión a
un registro. Esta conexión implica las siguientes tareas:
• Preliminares: Obtener acceso a un registro. Para utilizar el Servidor de

Registro de Java WSDP que es un registro privado versión UDDI 2,
necesitamos descargar e instalar Java WSDP 2.0 y luego instalar el Registry
en el servidor de aplicaciones.
• Obtener conexión Factory. Un cliente crea una conexión Factory. Un

proveedor JAXR suministra una o varias conexiones Factory
preconfiguradas.
Los clientes pueden obtener estas conexiones mediante la inyección de

recursos.
El servidor de aplicaciones, suministra a JAXR una conexión Factory a

través de JAXR RA pero es necesario utilizar un conector de recursos cuya
nombre JNDI es eis/JAXR para acceder a esta conexión desde una
aplicación Java EE.
Para inyectar este recurso en un componente de Java EE, utilizaremos un

código como el siguiente:
import javax.annotation.Resource; .*;
import javax.xml.registry.ConnectionFactory;
...
@ Resource (mappedName = "eis/JAXR")
Public ConnectinFactory Factory;
Para utilizar JAXR en un programa cliente independiente, deberemos crear

una instancia de la clase abstracta ConnectionFactory:
Importe javax.xml.registry.ConnectionFactory;
...
ConnectionFactory connFactory = ConnectionFactory.newInstance ();
• Crear una conexión. Para crear una conexión, un cliente crea primero un
conjunto de propiedades que especifican la URL o URL´s del registro
al que se accede.
Por ejemplo, el siguiente código proporciona las direcciones URL del servicio
de consulta y servicio de publicación de un Registro hipotético. (No debe
haber ningún salto de línea en las cadenas).
78
Properties props = new Properties ();

props.setProperty ("javax.xml.registry.queryManagerURL",
"http://localhost:8080/RegistryServer/");
props.setProperty ("javax.xml.registry.lifeCycleManagerURL",
"http://localhost:8080/RegistryServer/");
Con la implementación de Application Server de JAXR, si el cliente tiene acceso

a un registro que está fuera de un cortafuegos, también debe especificar el host del
proxy e información del puerto para la red en la que se está ejecutando.
Para las consultas se necesita especificar sólo el host del proxy HTTP y el
puerto y para las actualizaciones se debe especificar el HTTPS de host del
proxy y el puerto.
props.setProperty ( "com.sun.xml.registry.http.proxyHost", "myhost.mydomain" );

props.setProperty ( "com.sun.xml.registry.http.proxyPort", "8080" );
props.setProperty ( "com.sun.xml.registry.https.proxyHost", "myhost.mydomain" );
props.setProperty ( "com.sun.xml.registry.https.proxyPort", "8080" );
Luego, el cliente establece las propiedades de las conexiones Factory y crea la

conexión:
connFactory.setProperties (props);
Connection connection = connFactory.createConnection ();
• Configuración de propiedades de la conexión. La implementación de

JAXR en el servidor de aplicaciones nos permite establecer un número de
propiedades de una conexión JAXR. Algunos son propiedades estándar
definidas en la especificación JAXR. Otras propiedades son específicas
para la aplicación de JAXR en el servidor de aplicaciones.
• Obtención y utilización de un objeto RegistryService. Después de crear

la conexión, el cliente utiliza esa conexión para obtener el objeto
RegistryService y entonces podremos utilizar la interfaz o interfaces:
RegistryService rs = connection.getRegistryService ();

BusinessQueryManager bqm = rs.getBusinessQueryManager ();
BusinessLifeCycleManager blcm =
rs.getBusinessLifeCycleManager ();
4.2. CONSULTAR UN REGISTRO
La forma más sencilla para que un cliente use un registro es consultar la

información acerca de las organizaciones que le han enviado datos.
79
La interfaz BusinessQueryManager es compatible con una serie de métodos de

búsqueda que permiten a los clientes la búsqueda de datos utilizando el modelo
de información JAXR.
Muchos de estos métodos devuelven un Bulk-Response (una colección de

objetos), que reúne un conjunto de criterios especificados en los argumentos del
método.
Los métodos más útiles de esta colección son:
• findOrganizations, que devuelve una lista de organizaciones que

cumplan los criterios específicos, a menudo se trata de un patrón de nombre
o de una clasificación dentro de un esquema de clasificación.
• findServices, que devuelve un conjunto de servicios ofrecidos por una

organización específica.
• findServiceBindings, que devuelve los enlaces de servicio (información

acerca de cómo acceder al servicio) que son apoyados por un servicio
específico.
Todos los proveedores de JAXR soportan al menos las siguientes taxonomías para
las clasificaciones:
• Norteamericana Clasificación Industrial (NAICS).

• El Estándar Universal de Productos y Servicios de Clasificación
(UNSPSC).
• La norma ISO 3166 códigos de países del sistema de clasificación
gestionada por la Organización Internacional de Normalización (ISO).
Las empresas que buscan por nombre
Para buscar organizaciones por su nombre, normalmente utilizan una combinación

de encontrar calificadores (que afectan a la clasificación y comparación de
patrones) y los patrones de nombre (que especificar las cadenas a buscar).
El método findOrganizations tiene una colección de objetos findQualifier como

primer argumento y una colección de objetos namePattern como su segundo
argumento.
El siguiente fragmento de código nos muestra cómo encontrar todas las

organizaciones en el registro cuyos nombres comienzan por una determinada
cadena, QString, y los ordenamos alfabéticamente.
80
// Define los calificadores de búsqueda y los nombres de los patrones

Collection <String> findQualifiers = new ArrayList <String> ();
findQualifiers.add (FindQualifier.SORT_BY_NAME_DESC);
Collection <String> namePatterns = new ArrayList <String> ();
namePatterns.add (qString);
// Encuentran las organizaciones que empiecen por qString
BulkResponse response =
bqm.findOrganizations (findQualifiers, namePatterns, null,
null, null, null);
Collection orgs = response.getCollection ();
Empresas que buscan por clasificación
Para encontrar las organizaciones por clasificación, estableceremos la clasificación

dentro de un sistema de clasificación en particular y luego especificaremos la
clasificación como un argumento con el método findOrganizations.
El fragmento de código siguiente encuentra todas las organizaciones que

corresponden a una clasificación particular dentro de la taxonomía NAICS. La
taxonomía NAICS tiene un identificador único universal conocido (UUID) que se
define por la Especificación UDDI. El método getRegistryObject encuentra un
objeto a partir de su clave.
Ejemplo:
String uuid_naics = "uuid: C0B9FE13-179F-413D-8A5B-5004DB8E5BB2";
ClassificationScheme cScheme =
(ClassificationScheme) bqm.getRegistryObject (uuid_naics,
LifeCycleManager.CLASSIFICATION_SCHEME);
InternationalString sn = blcm.createInternationalString (
"All Other Specialty Food Stores"));
String sv = "445299";
Classification classification = blcm.createClassification (cScheme, sn, sv);
Collection<Classification> classifications =new ArrayList <Classification> ();

classifications.add (classification);
BulkResponse response = bqm.findOrganizations (null, null, classifications, null, null, null);
Collection orgs = response.getCollection ();
String schemeName = "uddi-org: types";
ClassificationScheme uddiOrgTypes =
bqm.findClassificationSchemeByName (null, schemeName);
/*
* Crear una clasificación, especificando el esquema y el nombre y valor de la
*taxonomía definida para documentos WSDL por la especificación UDDI
*/
81
Classification wsdlSpecClassification = blcm.createClassification (uddiOrgTypes,

"wsdlSpec","wsdlSpec");
Collection<Classification> classifications =new ArrayList <Classification> ();
classifications.add (wsdlSpecClassification);
// Encuentra los conceptos

BulkResponse br = bqm.findConcepts (null, null,
classifications, null, null);
// Visualiza la información sobre los conceptos encontrados

Collection specConcepts = br.getCollection ();
Iterator iter = specConcepts.iterator ();
if (! iter.hasNext ()) {
System.out.println ("No WSDL specification concepts found");
} else {
while (iter.hasNext ()) {
Concept concept = (Concept) iter.next ();
String name = getName (concept);
Collection links = concept.getExternalLinks ();
System.out.println ("\nSpecification Concept: \n\tName: " +
name + "\n\tKey: " + concept.getKey ().getId () +
"\n\tDescription:” + getDescription (concept));
if (links.size () > 0) {
ExternalLink link = (ExternalLink) links.iterator ().next ();
System.out.println ("\tURL of WSDL document: '" +
link.getExternalURI () + "'");
}
// Encuentra organizaciones que usan este concepto
Collection <Concept> specConcepts1 =new ArrayList <Concept> ();
specConcepts1.add (concept);
br = bqm.findOrganizations (null, null, null,
specConcepts1, null, null);
//Visualiza la información sobre las organizaciones...
}
}
Cuando un cliente tiene localizada una organización, puede encontrar los servicios
de esa organización y los enlaces de servicio relacionados con dichos servicios.
Iterator orgIter = orgs.iterator ();
while (orgIter.hasNext ()) {
Organization org = (Organization) orgIter.next ();
Collection services = org.getServices ();
Iterator svcIter = services.iterator ();
while (svcIter.hasNext ()) {
Service svc = (Service) svcIter.next ();
Collection serviceBindings =svc.getServiceBindings ();
Iterator sbIter = serviceBindings.iterator ();
82
while (sbIter.hasNext ()) {

ServiceBinding sb = (ServiceBinding) sbIter.next () ;}
}
}
4.3. MANTENIMIENTO DE LOS DATOS DEL REGISTRO

Si un cliente tiene autorización puede enviar datos a un registro, modificarlo, y
borrarlos. Para realizar estas tareas utilizaremos la interfaz de
BusinessLifeCycleManager.
Los registros suelen dar permisos a un cliente para modificar o eliminar datos sólo
si el usuario es el mismo que presentó por primera vez los datos. La gestión de
datos de Registro incluye las siguientes tareas:
• Obtener la autorización del registro.

String username = "testuser";
String password = "testuser";
// Coger autorización desde el registro
PasswordAuthentication passwdAuth =
new PasswordAuthentication (username,
password.toCharArray ());
HashSet<PasswordAuthentication> creds =
new HashSet <PasswordAuthentication> ();
creds.add (passwdAuth);
connection.setCredentials (creds);
• Creación de una organización.

El cliente crea la organización y la rellena con datos antes de publicarla. Un
objeto de organización es uno de los elementos de datos más complejos en el
JAXR API normalmente incluye lo siguiente:
o Objeto Name.
o Objeto Description.
o Objeto Key, en representación de la ID por el que se conoce la
organización en el Registro. Esta clave la crea el registro, no el usuario.
o Objeto PrimaryContact, es un objeto User con el que se refiere a una
autorización del usuario del Registro. Un objeto User normalmente
incluye un objeto PersonName y colecciones de objetos
TelePhoneNumber, EmailAddress y PostalAddress.
o Una colección de objetos Clasification.
o Objetos Service y sus objetos asociados ServiceBinding.
Ejemplo:
// Crear el nombre de una organización y su descripción
InternationalString s =
83
blcm.createInternationalString ("The Coffee Break");

Organization org = blcm.createOrganization(s);
s = blcm.createInternationalString ("Purveyor of the " +
"finest coffees. Established 1950");
org.setDescription (s);
//Crea el primer contacto y configura el nombre
User primaryContact = blcm.createUser ();
PersonName pName = blcm.createPersonName ("Jane Doe");
primaryContact.setPersonName (pName);
// Configura el primer contacto del número de teléfono
TelephoneNumber tNum = blcm.createTelephoneNumber ();
tNum.setNumber ("(800) 555-1212");
Collection<TelephoneNumber> phoneNums =
new ArrayList <TelephoneNumber> ();
phoneNums.add (tNum);
primaryContact.setTelephoneNumbers (phoneNums);
// Configura el primer contacto la dirección email

EmailAddress emailAddress = blcm.createEmailAddress
("[email protected]");
Collection<EmailAddress> emailAddresses =
new ArrayList <EmailAddress> ();
emailAddresses.add (emailAddress);
primaryContact.setEmailAddresses (emailAddresses);
// Configura el primer contacto para la organización

org.setPrimaryContact (primaryContact);
• Añadir clasificaciones. Las organizaciones suelen pertenecer a una o varias

clasificaciones basadas en uno o más planes de clasificación (taxonomía).
Para establecer una clasificación de una organización por medio de una

taxonomía, el primer cliente localiza la taxonomía que quiere usar. Utiliza el
objeto businessQueryManager para encontrar la taxonomía.
El método findClassificationSchemeByName toma un conjunto de objetos

FindQualifier como primer argumento, aunque este argumento puede ser nulo.
Ejemplo:
//Configura el esquema de clasificación a NAICS
ClassificationScheme cScheme =
bqm.findClassificationSchemeByName (null,
"ntis-gov: naics: 1997");
// Crea y añade la clasificación

InternationalString sn =
blcm.createInternationalString (
“All Other Specialty Food Stores“));
84
String sv = “445299“;
Classification classification =
blcm.createClassification (cScheme, sn, sv);
Collection<Classification> classifications =
new ArrayList <Classification> ();
classifications.add (classification);
org.addClassifications (classifications);
4.4. SERVICIOS DE ADICIÓN Y ENLACE A UNA ORGANIZACIÓN
La mayoría de las organizaciones se suman a un registro con el fin de ofrecer

servicios, por lo que la API JAXR cuenta con instalaciones para agregar servicios y
enlaces de servicio a una organización.
Al igual que un objeto Organization, el objeto Service tiene un nombre, una

descripción y una clave única que es generada por el registro cuando se registra
el servicio. También pueden tener clasificaciones asociadas a ella.
Este servicio normalmente tiene enlaces de servicio, que proporcionan información

acerca de cómo acceder al servicio.
Un objeto ServiceBinding normalmente tiene una descripción, de un acceso

URI, y un enlace, el cual suministra el vínculo entre un servicio obligatorio y una
especificación técnica que describe cómo utilizar el servicio.
Ejemplo:
// Crear servicios y servicio
Collection<Service> services = new ArrayList <Service> ();
InternationalString s =
blcm.createInternationalString ("My Service Name"));
Service service = blcm.createService(s);
s = blcm.createInternationalString ("My Service Description");
service.setDescription (is);
// Crear servicio de enlace

Collection<ServiceBinding> serviceBindings =
new ArrayList <ServiceBinding> ();
ServiceBinding binding = blcm.createServiceBinding ();
s = blcm.createInternationalString ("My Service Binding " +
"Description");
binding.setDescription (is);
// Permitir publicar una URI ficticia sin un error

binding.setValidateURI (false);
binding.setAccessURI ("http://TheCoffeeBreak.com:8080/sb/");
serviceBindings.add (binding);
85
// Añadir servicios de enlace para el servicio

service.addServiceBindings (serviceBindings);
// Add service to services, then add services to organization

services.add (service);
org.addServices (services);
4.5. PUBLICACIÓN DE UNA ORGANIZACIÓN

El primer método utiliza un cliente para añadir o modificar datos de la organización
es el método saveOrganizations, que crea una o varias organizaciones nuevas
en un Registro en caso de que no existieran anteriormente.
Si una de las organizaciones existe, pero algunos de los datos han cambiado, el
método saveOrganizations las actualiza y sustituye los datos.
Cuando un cliente rellena una organización con la información que quiere hacer
pública, se salva la organización. El registro devuelve la clave en su respuesta, y el
cliente lo recupera.
Ejemplo:
//Añade una organización y la envía al registro
//Devuelve la clave si es correcta
Collection<Organization> orgs = new ArrayList <Organization> ();
orgs.add (org);
BulkResponse response = blcm.saveOrganizations (orgs);
Collection exceptions = response.getException ();
if (exceptions == null) {
System.out.println ("Organization saved");
Collection keys = response.getCollection ();
Iterator keyIter = keys.iterator ();
if (keyIter.hasNext ()) {
Key orgKey = (Key) keyIter.next ();
String id = orgKey.getId ();
System.out.println ("Organization key is " + id);
}
}
4.6. PUBLICACIÓN DE UN CONCEPTO DE ESPECIFICACIÓN

Un servicio de enlace puede tener una especificación técnica que describe cómo
tener acceso a ese servicio. Un ejemplo de esta especificación es el documento
WSDL.
Para publicar la ubicación de la especificación de un servicio (si la especificación es

un documento WSDL), crearemos un objeto Concept, y luego añadiremos la URL
del documento WSDL al objeto Concept como un objeto ExternalLink.
86
El siguiente fragmento de código muestra cómo crear un concepto para el

documento WSDL.
Concept specConcept = blcm.createConcept (null, "HelloConcept", "");
InternationalString s =blcm.createInternationalString ("Concept for Hello Service");
specConcept.setDescription (s);
ExternalLink wsdlLink =blcm.createExternalLink (
"http://localhost:8080/hello-jaxws/hello?WSDL",
"Hello WSDL document");
specConcept.addExternalLink (wsdlLink);
Entonces se crea una clasificación utilizando el nombre y el valor wsdlSpec. Por

último, se agrega a la clasificación para el concepto.
String uuid_types =
"uuid: c1acf26d-9672-4404-9d70-39b756e62ab4";
ClassificationScheme uddiOrgTypes =
(ClassificationScheme) bqm.getRegistryObject (uuid_types,
LifeCycleManager.CLASSIFICATION_SCHEME);
Classification wsdlSpecClassification =
blcm.createClassification (uddiOrgTypes,
"wsdlSpec", "wsdlSpec");
specConcept.addClassification (wsdlSpecClassification);
Por último, se guarda el concepto utilizando el método saveConcepts, de igual

manera que guardábamos una organización.
Collection<Concept> concepts = new ArrayList <Concept> ();
concepts.add (specConcept);
BulkResponse concResponse = blcm.saveConcepts (concepts);
String conceptKeyId = null;
Después tenemos que publicar el concepto, normalmente añadimos el concepto

para el documento WSDL a un servicio de enlace. Al hacer esto, podemos
recuperar la clave para el concepto desde la respuesta devuelta por el método
savaConcepts; usaremos una secuencia de código muy similar a la que utilizamos
para encontrar la clave para guardar una organización.
Collection concExceptions = concResponse.getExceptions ();

Key concKey = null;
if (concExceptions == null) {
System.out.println ("WSDL Specification Concept saved");
Collection keys = concResponse.getCollection ();
Iterator keyIter = keys.iterator ();
concKey = (Key) keyIter.next ();
conceptKeyId = concKey.getId ();
System.out.println ("Concept key is " + conceptKeyId);
}
}
Concept specConcept =
87
(Concept) bqm.getRegistryObject (conceptKeyId,

LifeCycleManager.CONCEPT);
SpecificationLink specLink =
blcm.createSpecificationLink ();
specLink.setSpecificationObject (specConcept);
binding.addSpecificationLink (specLink);
// Define nombre del patrón
Collection namePatterns = new ArrayList ();
namePatterns.add ("HelloConcept");
BulkResponse br = bqm.findConcepts (null, namePatterns,
classifications, null, null);
4.7. EXTRACCIÓN DE DATOS DEL REGISTRO

Un registro nos permite eliminar de él todos los datos que le hayamos enviado.
Podemos utilizar la clave devuelta por el registro como argumento de uno de los
métodos delete de Business-LifeCycleManager: deleteOrganizations,
deleteServices, deleteServiceBindings, deleteConcepts…
String id = key.getId ();
System.out.println ("Deleting organization with id " + id);
Collection<Key> keys = new ArrayList<Key> ();
keys.add (key);
BulkResponse response = blcm.deleteOrganizations (keys);
Collection exceptions = response.getException ();
if (exceptions == null) {
System.out.println ("Organization deleted");
Collection retKeys = response.getCollection ();
Iterator keyIter = retKeys.iterator ();
Key orgKey = null;
orgKey = (Key) keyIter.next ();
id = orgKey.getId ();
System.out.println ("Organization key was " + id);
}
}
88
LECCION 3. SEGURIDAD EN LOS SERVICIOS WEB
INTRODUCCION
El modelo de seguridad que se utiliza para los servicios web se basa en las
especificaciones y recomendaciones de diversas organizaciones de
normalización.
El reto que hay detrás de la seguridad en los servicios web basados en modelo para
Java EE es comprender y evaluar el riesgo implicados en garantizar un servicio web
actual y, al mismo tiempo, seguir la pista de los estándares que salgan y entender
la forma en que se distribuirán para controlar el riesgo que pueda existir en un
futuro.
Los servicios web se pueden distribuir como EJB endpoints o como web
endpoints (servlets).
1. MENSAJE DE SEGURIDAD
La seguridad de Java EE es fácil de implementar y configurar, pudiendo ofrecer un
control de acceso a las funciones de aplicación y de datos.
Sin embargo, como la seguridad se aplica a la capa Aplication, las propiedades

de seguridad no son transferibles a datos los de aplicaciones que se ejecuten
en otros entornos y sólo se puede proteger los datos que residen en el entorno de
aplicación.
En el contexto de una aplicación tradicional, esto no supondría un problema, pero

cuando se aplica a una aplicación de servicios web, los mecanismos de seguridad
en Java EE sólo sirve como una solución parcial.
Las características de un servicio web hacen que sus necesidades de seguridad

sean diferentes de los de otras aplicaciones de Java EE:
• Acoplamiento flexible entre el proveedor y el consumidor de servicios.
• Basado en estándares.
• Utiliza los mensajes en formato XML y metadatos.
• Se centra en la prestación de interoperabilidad.
• Plataforma y lenguaje de programación neutral.
• Puede usar una variedad de protocolos de transporte, a pesar de que
HTTP es el que se utiliza más a menudo.
• Soporta la interacción con múltiples saltos entre el servicio de los
consumidores y el proveedor de servicios.
Algunas de las características de un servicio web que lo hacen especialmente

vulnerable a la los ataques de seguridad son las siguientes:
89
• Interacciones que se realizan a través de Internet utilizando los protocolos

de transporte.
• La comunicación a menudo es iniciada por los consumidores de servicios

que no han tenido antes ninguna relación con el proveedor de servicios.
• El formato del mensaje está basado en texto.
Además, la naturaleza de distribución de la interacción de servicios web y las

dependencias podrían requerir una forma estándar para propagar la identidad y la
confianza entre los dominios de la aplicación.
Hay aspectos definidos para la seguridad de la aplicación, estos incluyen

autenticación, autorización, integridad, confidencialidad y no rechazo…
Uno de los métodos que se pueden utilizar para hacer frente a los desafíos de la
seguridad en los servicios web es la seguridad de mensajes.
1.1. VENTAJAS DEL MENSAJE DE SEGURIDAD

Antes de llegar a la seguridad de mensajes, es importante entender por qué la
seguridad en la capa de transporte no siempre es suficiente para atender las
necesidades de seguridad de una red de servicios. La seguridad en la capa de
transporte se proporciona por los mecanismos de transporte utilizados para
transmitir información por la red entre los clientes y proveedores, por lo tanto el
transporte de seguridad de la capa de transporte se basa en HTTP seguro
(HTTPS) usando Secure Sockets Layer (SSL).
La seguridad del transporte es un punto en el mecanismo de seguridad para la

autenticación, la integridad del mensaje, y la confidencialidad. Cuando se
ejecuta una sesión protegida con SSL, el servidor y el cliente puede autenticar a los
dos y negociar un algoritmo de cifrado y de claves criptográficas antes de que
el protocolo de aplicación transmita o reciba su primer byte de datos.
La seguridad está "viva" desde el momento en que deja el consumidor hasta que
llega al proveedor, o viceversa, incluso a través de intermediarios. El problema es
que no se está protegido una vez que el mensaje llega a su destino. Una solución
consiste en encriptar el mensaje antes de enviarlo utilizando el mensaje de
seguridad.
En la capa del mensaje de seguridad, la seguridad de la información está contenida

en el mensaje SOAP y/o en los datos adjuntos de mensajes SOAP, que permiten
que la información viaje segura junto con el mensaje o archivo adjunto. Por
ejemplo, una parte del mensaje puede ser firmada por un emisor y un
receptor de cifrado para particulares.
90
Cuando el mensaje se envía desde el remitente inicial, es posible pasar a través de

nodos intermediarios antes de llegar a su destinatario previsto.
En este escenario, el cifrado de partes sigue siendo opaco a los nodos intermedios y
sólo puede ser descifrado por el receptor previsto. Por esta razón, la capa de
seguridad de los mensajes a veces se denomina seguridad end-to-end.
Las ventajas de la capa de mensaje de seguridad son los siguientes:
• La seguridad permanece con el mensaje a través de todos los saltos y

después llega el mensaje a su destino.
• Puede aplicarse de forma selectiva a diferentes partes de un mensaje (y

los archivos adjuntos si utiliza XWSS).
• Se puede usar junto con los intermediarios en varios saltos.
• Es independiente del entorno de aplicación o protocolo de transporte.
La desventaja de usar la capa de mensaje de seguridad es que es relativamente

complejo y añade algo de sobrecarga a la transformación.
El servidor de aplicaciones y los servicios de JavaWeb Developer Pack (Java

WSDP) soportan los mensajes de seguridad:
• El Sun Java System Application Server utiliza los servicios Web de

Seguridad (WSS) para proteger los mensajes.
• El Java Web Services Developer Pack (Java WSDP) incluye XML y Web
Services Security (XWSS), un marco para asegurar JAX-RPC, JAX-WS, y
las aplicaciones SAAJ, así como datos adjuntos de mensajes.
1.2. MECANISMOS DE LOS MENSAJES DE SEGURIDAD
El cifrado es la transformación de datos en una forma que es casi imposible leer

sin el conocimiento adecuado, está contenida en una clave. Su propósito es
asegurar la privacidad manteniendo la información oculta, incluso a los que
tienen acceso a los datos cifrados. El descifrado es el inverso de la codificación, es
la transformación de los datos cifrados de nuevo en una forma legible.
El cifrado y descifrado, requieren el uso de alguna información secreta,

a la que se refiere como clave. Para algunos mecanismos de cifrado, la misma clave
se utiliza tanto para el cifrado como para el descifrado, en otros mecanismos, las
claves utilizadas para el cifrado y el descifrado son diferentes.
La autenticación es una parte fundamental de nuestras vidas como la privacidad.

Usamos la autenticación lo largo de nuestra vida cotidiana, por ejemplo cuando
firmamos nuestro nombre en algún documento, y a medida que avanzamos hacia
91
un mundo donde nuestras decisiones y acuerdos se comunicarán por vía

electrónica, tenemos que tener las técnicas electrónicas para la autenticación de
proveedor.
El "crypt" en el cifrado y descifrado es la criptografía. La criptografía proporciona

mecanismos para darnos autenticación, que incluyen el cifrado y el descifrado, así
como las firmas digitales y marcas de tiempo digital.
Una firma digital se une a un documento que tiene una clave particular, mientras
que un sello de tiempo digital se une a un documento en su creación, en un
momento determinado.
Estos mecanismos criptográficos pueden utilizarse para controlar el acceso a una

unidad de disco compartido, para dar una alta seguridad de la instalación, o un
pago por canal de televisión privada.
La autenticación es un proceso mediante el cual se comprueba y verifica como

cierta la información. Podemos verificar el origen de un documento, la identidad del
remitente, la hora y la fecha de un documento que se envió y/o firma la identidad
de un equipo o usuario, etc.
Una firma digital es un cifrado medio por el cual muchos de estos datos pueden
ser verificados, es una pieza de información basada en el documento y el firmante
de la clave privada.
Normalmente se crea mediante el uso de una función “hash” y funciones de firma
privada (cifrado con la clave privada del firmante), pero hay otros métodos.
2. ESPECIFICACIONES DE SEGURIDAD
Las siguientes organizaciones trabajan en las especificaciones de seguridad de
servicios web, dando directrices, y herramientas:
• El World Wide Web Consortium (W3C).
• Organización para el Avance de las Normas de Información Estructurada
(OASIS).
• Organización de Interoperabilidad de Servicios Web (WS-I).
• Java Community Process (JCP).
Básicamente, la JCP, W3C, OASIS desarrollan especificaciones relacionadas

con la seguridad de servicios web. WS-I crea perfiles recomendados que
implementan varias especificaciones y proporciona orientación sobre cómo aplicar
dichas especificaciones.
92
2.1. ESPECIFICACIONES DEL W3C

La misión de la World Wide Web Consortium (W3C), de acuerdo a su Web
sitio en http://www.w3.org/, es llevar a la World Wide Web hacia su máximo
potencial mediante el desarrollo de protocolos y pautas que aseguren el crecimiento
a largo plazo para el web.
W3C lleva a cabo su misión mediante la creación de estándares Web y

directrices.
El W3C está trabajando en las siguientes especificaciones relacionadas con la

seguridad de los servicios web:
• Cifrado de XML (XML-Enc).

Esta especificación establece los requisitos para la sintaxis XML y la
transformación para cifrar el contenido digital, incluyendo partes de documentos
XML y mensajes de protocolo.
• Firma digital XML (XML-Sig).

Esta especificación desarrolla una sintaxis compatible con XML utilizada para
representar la firma de los recursos web y porciones de mensajes de protocolo
(Referenciable nada por un URI) y los procedimientos para calcular y verificar
dichas firmas.
• Especificación XML de administración de claves (XKMS).

El pliego de condiciones establece protocolos para la distribución y el
registro de claves públicas, adecuado para su uso en relación con las
recomendaciones W3C para la firma y el cifrado XML.
2.2. ESPECIFICACIONES OASIS

Según su sitio web en http://www.oasis-open.org/, la Organización para la
Promoción de Normas de Información Estructurada (OASIS) impulsa el
desarrollo de convergencia y la adopción de estándares de e-business.
OASIS está trabajando con las siguientes especificaciones relacionadas con la

seguridad de servicios web:
• Web Services Security (WSS): SOAP Message Security.

Esta especificación describe mejoras en la mensajería de SOAP para
proporcionar la integridad del mensaje, confidencialidad del mensaje y el
mensaje de autenticación mientras acoge un gran variedad de modelos de
seguridad y cifrado de tecnologías.
Esta especificación también define un mecanismo extensible de uso general

para la asociación de tokens de seguridad con el contenido del mensaje, así
93
como la forma de codificar los tokens de seguridad binaria, un marco para

fichas XMLbased, y cómo incluir opacidad en claves cifradas.
• Security Assertion Markup Language (SAML).

La especificación SAML define un mecanismo basado en XML para garantizar
la Business-to-Business (B2B) y Business-to-Consumer (B2C), y
transacciones e-commerce.
SAML define un marco de XML para el intercambio de autenticación y

autorización de información. SAML utiliza afirmaciones de la seguridad
codificadas en XML y el protocolo petición/respuesta también codificada en XML
y especifica las reglas para el uso de afirmaciones con transporte estándar de y
mensajería con marcos (frameworks).
También permite la interoperabilidad entre la seguridad de sistemas dispares,

puede aplicarse para facilitar tres casos de uso: inicio de sesión único,
transacciones distribuidas, y los servicios de autorización.
• eXtensible Access Control Markup Language (XACML).

La especificación XACML define un lenguaje común para expresar
la política de seguridad. Define una estructura extensible al núcleo
del esquema y el espacio para expresar las directivas de autorización en XML.
Un lenguaje política común, cuando se implementa en una empresa, permite a

la empresa gestionar el cumplimiento de todos los elementos de su política de
seguridad en todos los componentes de sus sistemas de información.
2.3. ESPECIFICACIONES JCP
De acuerdo con el sitio web de Java Community Process (JCP), JCP es el titular
de la responsabilidad para el desarrollo de la tecnología Java.
El JCP, principalmente guía la elaboración y aprobación de las especificaciones

técnicas de Java.
• JSR 104: XML Trust Service API.
JSR-104 define un conjunto estándar de APIs y un protocolo para un servicio

de confianza.
Un objetivo clave en el diseño del protocolo es reducir al mínimo la complejidad de

las aplicaciones utilizando XML Signature.
Al convertirse un cliente del servicio de confianza, la aplicación se libera de la

complejidad y la sintaxis de la subyacente PKI que se utiliza para establecer
94
relaciones de confianza, que puede basarse en especificaciones diferentes, como

X.509/PKIX, SPKI o PGP.
• JSR 105: XML Digital Signature API.
JSR-105 define un conjunto estándar de APIs para servicios de firma digital

XML.
La especificación XML Digital Signature es definida por el W3C. La presente

propuesta es definir e incorporar una implementación a alto nivel independiente de
la API Java.
• JSR 106: el cifrado XML API.
JSR-106 define un conjunto estándar de APIs para servicios de cifrado XML

digital.
El cifrado de XML Encryption se puede utilizar para llevar a cabo el trabajo fino con
los elementos basados en el cifrado de los fragmentos de un documento XML, así
como cifrar los datos binarios arbitrarios e incluir esto en un documento XML.
• JSR 155: Afirmaciones de seguridad de servicios web.
JSR-155 proporciona un conjunto de APIs, los patrones de cambio, y la

implementación de forma segura (integridad y confidencialidad), las
afirmaciones entre los servicios web están basados en OASIS SAML.
• JSR 183: API’s de seguridad de los mensajes de servicios web.
JSR-183 define un conjunto API estándar para seguridad de los mensajes de

servicios web. El objetivo es permitir la construcción de aplicaciones seguras
mediante intercambio de mensajes SOAP.
• JSR 196: Java Authentication Service Provider Interface para

contenedores.
Define una interfaz estándar de proveedores de servicios en la cual dichos

proveedores tengan un mecanismo de autenticación donde esté ser integrado en
contenedores.
Los proveedores integrados a través de esta interfaz se utilizan para establecer la
identidad de autenticación que se utiliza al decidir el acceso de los contenedores,
incluidos los utilizados por el propio contenedor en las llamadas a los componentes
en otros contenedores.
2.4. ESPECIFICACIONES WS-I
La Organización de Interoperabilidad de Servicios Web (WS-I), es una

organización industrial abierta constituida para promover los servicios Web con
95
interoperabilidad entre plataformas, sistemas operativos y lenguajes de

programación.
En concreto, WS-I crea, promueve y apoya los protocolos genéricos para

el intercambio de mensajes de interoperabilidad entre los servicios Web, crea
perfiles, lo que se recomienda usar para diversos servicios de especificaciones
creados por el W3C, OASIS, y el JCP.
• Basic Security Profile (BSP).
El perfil de seguridad base proporciona orientación sobre el uso de WS-

Security y el nombre de usuario y formatos de seguridad X.509 simbólico.
• REL Token Profile.
El perfil Token REL es el perfil de la interoperabilidad para los Rights

Expression Language (REL) que se utiliza con WS-Security.
• SAML Token Profile.
Este es el perfil de interoperabilidad para (SAML) que se utiliza con WS-

Security.
• Seguridad de desafíos, amenazas y contramedidas.
Este documento identifica los problemas potenciales de seguridad y las

amenazas en una aplicación de servicios Web, e identifica las tecnologías
adecuadas para hacer frente a estos desafíos.
3. UTILIZAR EL MENSAJE DE SEGURIDAD CON JAVA EE
Por defecto, la capa de seguridad de mensajes está deshabilitada en el servidor de

aplicaciones. Para configurarla a nivel de servidor de aplicaciones, veremos los
siguientes pasos que explican brevemente cómo configurar el servidor de
aplicaciones para la seguridad de los mensajes.
Para configurar los proveedores de seguridad de mensajes SOAP en el cliente y

Serverside contenedores de Application Server, seguiremos estos pasos:
1. Iniciar el servidor de aplicaciones.

2. Iniciar la consola de administración.
3. En el componente del árbol de consola, expandir el nodo Configuración.
4. Expandir el nodo de Seguridad.
5. Expandir el nodo de seguridad de los mensajes.
6. Seleccionar el nodo SOAP.
96
7. Seleccionar la pestaña de seguridad de los mensajes.

8. En la página Editar configuración de seguridad de los mensajes, especificar
el proveedor que se va a utilizar en el lado del servidor y / o un proveedor
que se utilizará en el lado del cliente para todas las aplicaciones para las que
el proveedor especificado no se está obligado.
9. Seleccionar Guardar.
10. Para modificar el mensaje de las políticas de protección de los proveedores
activado, seleccionar en la ficha Proveedores.
11. Seleccionar el proveedor para el que se quiera modificar las políticas de
protección de mensajes.
12. Hacer clic en Guardar y reiniciar el servidor de aplicaciones si así nos lo
indicara.
3.1. CONFIGURAR UN MENSAJE DE SEGURIDAD PARA UNA APLICACIÓN

ESPECÍFICA
La configuración de un mensaje de seguridad para una aplicación específica se

configura añadiendo elementos de mensaje de seguridad de enlace al servicio
web endpoint.
Este mensaje de seguridad de enlace se agrega los descriptores de distribución en

tiempo de ejecución de la solicitud (sun-ejb-jar.xml, sun-web.xml, o sun-
application-client.xml).
Estos elementos se utilizan para asociar un proveedor específico o la política de

protección de mensaje con un criterio de valoración de servicios web o servicio de
referencia, y se puede calificar de manera que se aplique a un puerto específico o
método del correspondiente endpoint o a la referencia de un servicio.
En el siguiente ejemplo vemos un archivo descriptor de distribución

sun-ejb-jar.xml en el que se ha añadido un elemento mensaje de seguridad de
enlace:
Ejemplo:
<sun-ejb-jar>
<enterprise-beans>
<unique-id>1</unique-id>
<ejb>
<ejb-name>HelloWorld</ejb-name>
<jndi-name>HelloWorld</jndi-name>
<webservice-endpoint>
<port-component-name>HelloIF</port-component-name>
<endpoint-address-uri>service/HelloWorld</endpointaddress-
97
uri>
<message-security-binding auth-layer="SOAP">
<message-security>
<message>
<java-method>
<method-name>ejbTaxCalc</method-name>
</java-method>
</message>
<message>
<java-method>
<method-name>sayHello</method-name>
</java-method>
</message>
<request-protection auth-source="content" />
<response-protection auth-source="content"/>
</message-security>
</message-security-binding>
</webservice-endpoint>
</ejb>
</enterprise-beans>
</sun-ejb-jar>
98
EJERCICIOS DE REPASO DEL TEMA 3: OTRAS TECNOLOGIAS DE SERVICIOS

WEB
ENUNCIADOS.
1. (SAAJ) es:
2. UDDI es un registro y un repositorio.
3. XML Digital Signature especificación se utiliza para:
4. La especificación XML de cifrado se utiliza para:
5. Un <puerto> WSDL se refiere a:
99
1. La Respuesta Correcta es: La 2, Una API para mensajería XML.

2. La Respuesta Correcta es: La 2, Falso, porque el contenido real no se almacena
en UDDI.
3. La Respuesta Correcta es: La 4, Todas las anteriores.
4. La Respuesta Correcta es: La 4, B y C.
5. La Respuesta Correcta es: La 3, Expone un <service> utilizando un protocolo
vinculante específico.
100
PRÁCTICAS
1. ¿Qué define SOAP?
2. API Java para Registros XML (JAX-R) es una API:
3. UDDI se usa para listar que ______ están disponibles.
4. XML proporciona el ________ en el que se puede escribir los lenguajes
especializados para expresar las interacciones complejas entre los

clientes y los servicios, o entre los componentes de un servicio
compuesto.
5. Un servicio web se puede crear con independencia del:
101
6. Para hacer el intercambio de datos entre las diferentes aplicaciones y

plataformas diferentes se utilizan:
7. El Paquete de Servicios Web en Java para desarrolladores (Java WSDP)

es:
8. UDDI es:
102
SOLUCIONES A LOS EJERCICIOS DE REPASO. PRACTICAS
1. La Respuesta Correcta es: La 5, Todas las anteriores.

2. La Respuesta Correcta es: La 3, A y B.
3. La Respuesta Correcta es: La 3, Servicios.
4. La Respuesta Correcta es: La 2, Metalenguaje.
5. La Respuesta Correcta es: La 2, Lenguaje de programación.
6. La Respuesta Correcta es: La 3, Servicios Web.
7. La Respuesta Correcta es: La 5, B y C.
8. La Respuesta Correcta es: La 1, Universal Description, Discovery and the
Integration Service.
103
GLOSARIO
API (Application Program Interface)
Un conjunto de programas o interfaces para que los desarrolladores puedan

interactuar con la red o el sistema operativo.
Autenticación
Proceso que verifica la identidad de un usuario, dispositivo u otra entidad en un

sistema informático, habitualmente como requisito previo a permitir el acceso a los
recursos de un sistema.
B2B (Business-to-Business)
Proporciona el intercambio de información y otros servicios entre empresas.
Binding
Asociar una interfaz, un formato de datos válidos, y un protocolo para garantizar la

transmisión de mensajes sin problemas.
Cifrado
Proceso mediante el cual se protege información de una utilización no autorizada y

que consiste en convertir la información en un código ininteligible. Algunos métodos
de cifrado emplean códigos, llamados "claves", que se utilizan para cifrar la
información.
Cifrado de clave pública
Método criptográfico que utiliza una clave de dos partes (código) que se compone
de un componente público y otro privado.
104
Clave pública
Estructura de datos que contiene la clave pública de un usuario, así como la

información acerca de la fecha y la hora en la que el certificado tiene validez. Se
usa en la autenticación cliente-certificado para permitir al servidor y opcionalmente
al cliente que se autentiquen entre sí. El certificado de clave pública es el
equivalente digital a un pasaporte.
Cliente
En cualquier sistema cliente / servidor, el software y la información que solicitan los

servicios del servidor.
COM (Component Object Model)
Arquitectura de software desarrollado por Microsoft para desarrollar aplicaciones de

componentes de software binarios.
Connection factory (fábrica de conexiones)
En el caso de un resource manager (administrador de recursos), objeto que se

utiliza para crear una conexión del administrador de recursos.
CORBA (Common Object Request Broker Architecture)
Interfaz genérica desarrollada por el Object Management Group (OMG) para

permitir que los objetos se comuniquen entre sí en una red, independientemente de
su lenguaje y sistema operativo.
Criptografía de clave pública
Método de cifrado. En los criptosistemas de clave pública, cada uno posee dos
claves complementarias relacionadas: una clave pública conocida y una clave
secreta (también conocida como "clave privada"). Cada clave desbloquea el código
de la otra. Aunque se conozca la clave pública no se puede deducir la clave secreta
correspondiente.
105
Datos
Contenido de un elemento dentro de un flujo XML, normalmente utilizado cuando el

elemento no contiene ningún subelemento. En caso de contenerlo, suele utilizarse
el contenido del término.
DCOM (Distributed Component Object Model)
Arquitectura desarrollada por Microsoft para extender COM, permitiendo así que los
objetos situados en diferentes LANs, WANs, o en Internet para comunicarse entre
sí.
Declaración
El primer elemento de un documento XML, que lo declara como XML. La declaración

mínima es <?xml versión="1.0"?>. La declaración es parte del documento prólogo.
Descifrado
Proceso mediante el cual se convierte información cifrada en inteligible.
DOM (Document Object Model)
Una interfaz genérica (plataforma y lenguaje neutral) que permite a los programas
externos editar el contenido de un documento, la estructura y estilo.
DTD (Document Type Definition)
Un documento que define el formato de los contenidos que están presentes entre
las etiquetas en un documento XML, y la forma en la que deben ser interpretados
por la aplicación al leer el documento XML.
ebXML (electronic business XML)
Un conjunto de especificaciones definidas para que las empresas puedan

comunicarse entre sí, independientemente de su ubicación y de dominio, a través
de Internet, el intercambio de mensajes en un formato XML.
106
Elemento
En un archivo XML, un elemento es la unidad estructural básica.
Endpoint (punto final)
La dirección IP o nombre host de una máquina en un clúster de carga equilibrada.

Clase de Java, normalmente un servlet o bean de sesión sin estado, anotado con la
anotación javax.jws.WebService. Esta anotación define la clase como un punto final
de web service (servicio web), que recibe mensajes de clientes de servicios web.
Entidad
En archivos XML, un elemento distinto e individual que puede incluirse en un

documento XML haciendo referencia a él. Este tipo de referencia a una entidad
puede asignar un nombre a una entidad del tamaño de un carácter (por ejemplo,
<, que hace referencia a un símbolo menor que o a un corchete al ángulo izquierdo,
<). Una referencia a una entidad puede hacer referencia también a todo un
documento, a una entidad externa o a una colección de definiciones DTD.
Entidad emisora de certificados
Organización interna o externa en la que se confía que emite certificados de clave

pública que se utilizan para transcripciones cifradas y proporciona al portador la
identificación.
Espacio de nombre
Norma que permite especificar una etiqueta exclusiva para un conjunto de nombres
de elementos definido por un DTD. Un documento que utiliza esta definición DTD
puede incluirse en otro documento sin que surjan conflictos entre los nombres de
los elementos. Los elementos definidos en el DTD posteriormente se identificarán
de forma exclusiva de modo que, por ejemplo, el analizador pueda indicar en qué
momento un elemento <name> debe interpretarse en función del DTD en lugar de
utilizar la definición de un elemento <name> en un DTD diferente.
Esquema – Schema
Definiciones que describen qué tipos de información se pueden almacenar como

entradas en el directorio. Cuando la información que no se ajusta al esquema se
107
almacena en el directorio, es posible que los clientes que intentan acceder al

directorio no puedan mostrar los resultados correctos.
Evento
Acción con nombre que genera una respuesta procedente de un módulo o un

recurso externo de JavaNaming and Directory Interface (JNDI).
Factory class (clase de fábrica)
Clase que crea PersistenceManager.
Firewall
También conocido como cortafuegos. Configuración de red, normalmente de

hardware y software, que protege a los equipos de una organización que están
conectados en red de un posible acceso exterior.
HTML (lenguaje de marcador de hipertexto)
Lenguaje de marcado para documentos de hipertexto en Internet. HTML permite la

integración de imágenes, sonidos, emisiones de vídeo, campos de formulario,
referencias a otros objetos con URL y formato de texto básico. Cada bloque de
texto está rodeado de códigos que indican la naturaleza del texto.
HTTP (Hyper Text Transfer Protocol)
Un protocolo que define cómo deben tener el formato los mensajes y lo que los
servidores tienen que hacer sobre ellos. Para los mensajes basados en la Web.
HTTPS (protocolo de transferencia de hipertexto seguro)
Versión segura de HTTP implementada por medio del protocolo Secure Socket Layer
(SSL).
108
Instrucción de procesamiento
Información que contiene una estructura XML destinada a que la interprete una
aplicación en concreto.
JAX-RPC (Java API para RPC basado en XML)
API Java que permite a los desarrolladores crear aplicaciones y servicios web
interoperativos basados en protocolos RPC basados en XML.
JAXP (Java API for XML Processing)
Convierte XML a un formato independiente de cualquier aplicación comercial en

particular.
JAXR (Java API para registros XML)
API Java estándar y uniforme para acceder a diferentes tipos de registros XML.
Permite a los usuarios crear, implementar y descubrir servicios web.
JAXR client (cliente JAXR)
Programa cliente que emplea la API JAXR para acceder a un registro empresarial a
través de un proveedor JAXR.
Mensaje
Unidad fundamental del correo electrónico que consta de un header (encabezado) y

un body (cuerpo) y a menudo está contenido en un envelope (sobre) en su
recorrido del emisor al destinatario.
Metadatos
Información acerca de un componente; por ejemplo, el nombre y las

especificaciones del componente para su funcionamiento.
109
OASIS (Organización para el Avance de las Normas de Información

Estructurada)
Consorcio que gestiona el desarrollo, la convergencia y la adopción de los

estándares del comercio electrónico.
Organización
Objeto que representa el nivel superior de una estructura jerárquica que utiliza una
empresa para gestionar sus departamentos y recursos.
P2P (Peer to Peer)
Permite a un grupo de programas que tengan atributos similares a comunicarse

entre sí.
Parsed entity (entidad analizada)
Entidad general que contiene XML y que, por lo tanto, se analiza al insertarla en el
documento XML, en contraposición a una entidad no analizada.
Parser (analizador)
Módulo que lee en datos XML desde una fuente de entrada y se divide en
fragmentos, de forma que el programa sepa cuándo está trabajando con una
etiqueta, un atributo o datos de un elemento. Un analizador no validador garantiza
que los datos XML no están bien formados, pero no comprueba que sea válido.
Proveedor de registros
Implementación de un registro empresarial conforme a una especificación de

registros XML (por ejemplo, ebXML o UDDI).
110
Proveedor JAXR
Implementación de la API JAXR que proporciona acceso a un proveedor de registro

determinado o a una clase de proveedores de registro basados en una
especificación común.
Puerto
La ubicación (socket) en la que se realizan las conexiones de Transmisión Control

Protocol/Internet Protocol. Los servidores web suelen utilizar el puerto 80, FTP
utiliza el puerto 21 y telnet utiliza el puerto 23. Java Enterprise System Portal
Server utiliza puertos especiales, sobre todo, en sistemas de cliente, para
establecer una comunicación segura con los servidores a través de la sesión de
Portal Server.
Registro
Infraestructura que permite la creación, implementación y descubrimiento de web

service.
SAAJ (SOAP with Attachments API for Java)
El paquete básico de mensajería de SOAP, SAAJ contiene las API de creación y

llenado de un mensaje SOAP.
SAX (Simple API for XML)
Interfaz gestionada por eventos en la que el parser (analizador) invoca uno de los
diversos métodos que suministra el llamador cuando tiene lugar un evento de
análisis.
Servicio
Función proporcionada por un servidor.
111
Servicio web
Servicio que se ajusta a los protocolos de Internet estandarizados para la

accesibilidad, la encapsulación de servicio y el descubrimiento. Los estándares
incluyen el protocolo de mensajería SOAP, la definición de interfaz WSDL y el
estándar de registro UDDI.
SOA (arquitectura orientada a servicios)
Describe una aplicación compleja compuesta por consumidores y proveedores de

servicios. Los consumidores y proveedores pueden intercambiar mensajes sin
referencia a la ubicación concreta de otro. La arquitectura aísla también los
procesos principales de una aplicación de otros proveedores y consumidores de
servicios.
SOAP (Simple Object Access Protocol)
(Protocolo simple de acceso a objetos) Es un protocolo estándar que define cómo

dos objetos en diferentes procesos pueden comunicarse por medio de intercambio
de datos XML.
SOAP message (mensaje SOAP)
Unidad básica de comunicación entre nodos SOAP.
SSL (capa de socket segura)
Una forma de cifrado segura de bajo nivel que utilizan otros protocolos como HTTP
y FTP.
Tag (etiqueta)
En documentos XML, un fragmento de texto que describe una unidad de datos o un

elemento. La etiqueta puede distinguirse como marcado, en contraposición a los
datos, dado que está rodeada por corchetes angulares (< y >).
112
Taxonomía
Sistema de categorías para los recursos del motor de búsqueda de Java Enterprise
System Portal Server.
UDDI (Descripción universal, descubrimiento e integración)
Proporciona un registro mundial de servicios web para el descubrimiento y la

integración. Iniciativa del sector para crear un marco de trabajo abierto y no
dependiente de plataformas para la descripción de servicios, descubrimiento de
empresas y la integración de servicios empresariales por medio de Internet, así
como un registro.
URI (identificador de recursos uniforme)
Identificador exclusivo de forma global de un recurso abstracto o físico.
WSDL (lenguaje de descripción de servicios web)
Un lenguaje basado en XML utilizado para definir los servicios web de forma
estándar.
XML (eXtensible Markup Language)
(Lenguaje de marcado extensible) Un lenguaje especializado de documentos web,

que permite la creación de etiquetas personalizadas dependiendo de las
necesidades de la empresa y la lógica empresarial. No sólo tiene datos, sino que
también contiene los metadatos.
XSD (XML Schema Definition)
Define la estructura de un documento XML.
113
XSL (eXtensible Stylesheet Language)
Un lenguaje creado para describir hojas de estilo para documentos XML.
XSLT (eXtensible Stylesheet Language Transformation)
Lenguaje para transformar el formato de datos XML en los datos de otros formatos,
sobre la base de un conjunto de reglas bien definidas.
114

Manual de WebServicesJava EE5

Cargado por

Copyright:

Formatos disponibles

Manual de WebServicesJava EE5

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual de WebServicesJava EE5

Cargado por

Copyright:

Formatos disponibles

MANUAL DE

WEB SERVICES JAVA EE5

UNIDAD DIDACTICA 1. APRENDIENDO LA BASE DE LOS SERVICIOS WEB 1

LECCIÓN 2. Publicación de un servicio web 13

EJERCICIOS DE REPASO DEL TEMA 1 24

UNIDAD DIDÁCTICA 2. TECNOLOGÍAS DE SERVICIOS WEB 26

LECCION 1. JAX-WS 2.0. JAVA API PARA SERVICIOS WEB XML 26

LECCION 3. StAX (STREAMING API para XML) 48

EJERCICIOS DE REPASO DEL TEMA 2 63

UNIDAD DIDÁCTICA 3. OTRAS TECNOLOGIAS DE SERVICIOS WEB 65

LECCION 1. SAAJ. SOAP WITH ATTACHMENTS API PARA JAVA 65

LECCION 2. JAXR. JAVA API FOR XML REGISTRIES 75

LECCIÓN 3. SEGURIDAD EN LOS SERVICIOS WEB 89

EJERCICIOS DE REPASO DEL TEMA 3 99

TEMA 1. APRENDIENDO LA BASE DE LOS SERVICIOS WEB

Los servicios web - componentes de software de programación que son accesibles

LECCION 1. INTRODUCCIÓN A LOS SERVICIOS WEB

1. QUÉ ES UN SERVICIO WEB Y SUS BENEFICIOS

Los servicios Web son el resultado de la evolución natural de la Web.

En cambio, el servicio se representa en XML y está disponible a través de Internet

Los servicios Web, o simplemente los servicios, se basan en los conocimientos

Hay tres tipos de arquitecturas básicas:

• Un servicio Web permite una arquitectura orientada a servicios, que es

Las arquitecturas orientadas a servicios pueden resolver estos problemas

Estos servicios se comunican entre sí y con los clientes finales a través de

La comunicación puede ir desde un simple paso de mensajes entre los servicios a

En una arquitectura orientada a servicios, tenemos lo siguiente:

• Un servicio que implementa la lógica de negocio y expone esta lógica

• Un registro en el servicio que publica sus interfaces para permitir a los

• Los clientes (incluyendo clientes que pueden ser los propios

Una ventaja importante de una arquitectura orientada a servicios es que permite el

Para habilitar esta arquitectura, se necesita lo siguiente:

• Un mecanismo que permita a los clientes acceder a un servicio y el

• Un mecanismo para permitir a los diferentes servicios registrar su

• Un mecanismo de servicios para exponer las interfaces bien definidas y

• Interoperabilidad en un entorno heterogéneo:

A medida que las empresas desarrollan sus aplicaciones van añadiendo

• Servicios a las empresas a través de la Web:

• Integración con los sistemas existentes:

Los servicios Web permiten a los desarrolladores de aplicaciones empresariales

Los desarrolladores podemos mejorar nuestra productividad, ya que, en lugar

Los servicios Web también garantizan la estandarización de las herramientas, de

• Soporte más tipos de clientes:

Esto ocurre independientemente de la plataforma en la que se basa el cliente:

En resumen, un servicio Web puede ayudarnos a ampliar nuestras aplicaciones

La productividad es mayor cuando los equipos de desarrollo de aplicaciones

Antes de la llegada de los servicios Web, los desarrolladores de programación

El desarrollo de aplicaciones también se ha visto complicado por el requisito de

2. ESTÁNDARES PARA EL DESARROLLO DE SERVICIOS WEB

Los desarrolladores haremos nuestras propias implementaciones de cada estándar.

• Un servicio Web debe ser capaz de atender las solicitudes de

• El cliente debe ser capaz de encontrar y utilizar cualquier servicio

Estas normas abarcan áreas tales como:

• Lenguaje de marcado común para la comunicación (XML). Para

Esta comunicación exige el uso de una terminología común, o el idioma, a

Aunque los proveedores y los solicitantes pueden comunicarse mediante los

<? xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

1. DTD que describe la estructura del documento XML.

<! ELEMENT ContactInformation (Nombre, Direccion, Telefono, EMail)>