Вы находитесь на странице: 1из 141

Profesional en Plataforma

Java
Mdulo 7. Creando servicios web usando la
tecnologa Java. Puesta en marcha de redes VLAN
y trunks
Contenido

Mdulo 7. Creando servicios web usando la


tecnologa Java. Puesta en marcha de redes VLAN
y trunks

Unidad 1 - Idificando la construccin de bloques de servicios Web


Unidad 2 - Analizando la tecnologa y plataforma de servicios Web
Unidad 3 - Aplicando XML
Unidad 4 - Examinando mensajes SOAP
Unidad 5 - Desarrollando Servicios Web usando SOAP con adjuntos
Unidad 6 - Explicando el lenguaje de Servicios Web (WSDL)
Unidad 7 - Reconociendo el papel del servicios de registro
Unidad 8 - Implementando servicios web con Java API para servicios
web XML con tecnologa (JAX-WS)
(JAX
Unidad 9 - Desarrollando servicios Web cliente

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 1: Identificando la construccin de bloques
de servicios Web

Objetivos
x Conocer toda la estructura de elementos que conforman un Servicio Web.
x Aprender los conceptos esenciales para cada bloque incluido dentro de un Web Service.

Introduccin
Desde que apareci el World Wide Web, internet ha experimentado una gran evolucin.
En un principio, internet estaba formado por pginas estticas escritas en HTML. stas
s no eran
actualizadas muy a menudo y los usuarios no tenan posibilidad de participar en la creacin de los
contenidos que se mostraban por la red.
A este tipo de servicios nos referimos cuando hablamos de Web 1.0.
El diseo de este tipo de sitios estticos,
stticos, se limitaba a la edicin de etiquetas, y predominaban las
imgenes GIF, los formularios va email y en su conjunto componan sitios web que a menudo eran
pginas personales y otros servicios de contenidos en los que no sola interactuar directamente
directa el
usuario sino un administrador que iba creando sus contenidos mediante la edicin manual de cdigo
HTML.
Progresivamente aparecieron las pginas web dinmicas en las que una simple consulta o insercin en
la base de datos le permitan al administrador
administrador modificar fcilmente el contenido de sus pginas.
stas han sido conocidas menos popularmente como Web 1.5.
Pero la verdadera revolucin de internet lleg con la creacin de espacios dinmicos en los que el
usuario era el protagonista de la informacin,
informacin, permitindole la posibilidad de crear, modificar y borrar
contenidos.
ste es el principio en el que se sustenta la Web 2.01 tal y como la present por primera vez Tim OReilly
en una conferencia en el ao 2004.
Esta actualizacin est relacionada con con un fenmeno social en el que el predomina el aporte del
usuario, nutrindose as de la inteligencia colectiva.
El creador de este concepto incluso llega a comparar la Web 1.0 con la 2.0 de forma anloga a como
compararamos las webs personales con los blogs, la publicacin con la participacin, los sistemas de
gestin de contenidos con las wikis o la Enciclopedia Britnica con la Wikipedia.
Actualmente existen multitud de aplicaciones con estas caractersticas como pueden ser wikis, blogs y
dems servicios
ios de red donde compartir todo tipo de informacin multimedia.
Igualmente existen muchos mbitos profesionales en los que esta evolucin puede incorporarse en el
da a da, como pueden ser las aplicaciones educativas con una intranet donde el profesorado
profesorad y el
alumnado comparten material didctico y conocimientos, o mdicas, donde aplicaciones como
Google Health permiten organizar informacin mdica con la que interacta el propio usuario, aunque
esta ltima con la privacidad necesaria.
Siguiendo el desarrollo
rrollo que est experimentando constantemente la red, podemos observar
caractersticas que van ms all de la simple interaccin de usuario con las aplicaciones web.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Nuevos frentes se estn abriendo en los que la interoperabilidad de la red con procesadores o agentes
inteligentes permiten procesar de forma eficiente multitud de informacin.
Siguiendo la dinmica del proceso evolutivo de internet surge la Web 3.0, en la cual se extiende el
concepto de web semntica, en el que se le dota de significado a los elementos de cualquier web
para que sea ms fcil y directa su localizacin, tambin se apuesta por evolucionar en el campo de
las 3D y en el de la inteligencia artificial.
ificial.
Grandes compaas como Google estn aportando tecnologa que permite directamente trabajar en
este aspecto, permitiendo la creacin de modelos predictivos que utilicen tcnicas de inteligencia
artificial va web.
En este entorno de comunicacin
n en el que ha evolucionado la red, aparecen los servicios web, que
son sistemas de informacin que permiten comunicar clientes con cualquier tipo de informacin,
independientemente del lenguaje que vaya a utilizar el cliente para el acceso.

Definicin de
e Servicios Web
Un servicio Web es un servicio, con un interfaz definido y conocido, al que se puede acceder a travs
de Internet.
Se puede definir los servicios web como un conjunto de servicios que proporcionan mecanismos de
comunicacin estndares entre re diferentes aplicaciones, que interactan entre s para presentar
informacin dinmica al usuario.
Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea
posible su combinacin para realizar operaciones complejas, es necesaria una arquitectura de
referencia, adoptando el uso de protocolos y estndares abiertos.
El World Wide Web Consortium (W3C) y la Organization for the Advancement of Structured Information
Standards son las organizaciones responsables de la estandarizacin y la arquitectura de los servicios
Web.
Igual que una pgina Web est definida por un URL (Uniform Resource Locator), un servicio Web est
definido por un URI (Uniform Resource Identification) y por su interfaz, a travs del cual se puede
acceder a l, ocultando as los detalles de su implementacin.
Estos servicios pretenden ser independientes del hardware y software utilizado para acceder a ellos.
Las aplicaciones Web se convierten en clientes que integran servicios Web procedentes
proced de diferentes
proveedores de manera que puede ofrecerse al usuario una funcionalidad ms completa.
Con el desarrollo que ha tenido Internet y el avance de componentes software se puede llegar a
construir grandes aplicaciones distribuidas que pueden
pueden residir en uno o ms servidores y poder as
reducir el software cliente.
De esta forma, las empresas pueden ofrecer a sus usuarios tener un acceso sencillo y casi universal a sus
aplicaciones sin tener que preocuparse de los gastos derivados del mantenimiento.
mantenimiento.
Los servicios Web normalmente utilizan como base para la creacin de sus mensajes de intercambio
XML (Extensible Markup Language), que es un estndar para la descripcin de datos (metadatos).
XML tiene la propiedad de utilizar una gramtica sencilla
sencilla y compatible con la mayor parte de los
sistemas conectados a la red.
Esta propiedad permite a los servicios Web poder ser accesible desde diferentes plataformas software o
sistemas hardware.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Protocolos de Servicios Web
La comunicacin entre los servicios
ervicios Web y las aplicaciones se realiza mediante protocolos que pueden
clasificarse en 4 tipos:
x Servicios de transporte:
Son los protocolos de ms bajo nivel que codifican la informacin independientemente de su formato, y
que pueden ser comunes a otross servicios como HTTP, FTP, SMTP o utilizar alguno especfico como BEEP
(Block Extensible Exchange Protocol).
x Servicios de mensajera
Especifican como se deben codificar los mensajes que contienen los datos que se intercambian.
Los ms utilizados son SOAP
P (Protocolo Simple de Acceso a Objetos) y XML-RPC
XML RPC (Remote Procedure Call
mediante XML).
Mientras ste ltimo utiliza HTTP como protocolo de transporte, SOAP puede funcionar con varios (SMTP,
FTP, HTTP, etc.).
Estos protocolos utilizan XML como base para el intercambio de informacin.
x Servicios de descripcin
Para que una aplicacin sepa de manera automtica que formato usar para comunicarse con un
servicio, ste ha de especificarse.
Esto se hace mediante WSDL
DL (Web Services Description Language).
Mediante dicho protocolo se obtiene la direccin y la interfaz de un servicio.
x Servicios de descubrimiento
Es la capa ms alta. Permite llevar WSDL ms all, describiendo productos, la empresa y cmo se
realizan las transacciones.
UDDI (Universal Description, Discovery and Integration) es el protocolo que se utiliza para buscar servicios
Web y obtener informacin de cmo acceder a ellos.
La arquitectura de los servicios web incluye distintas tecnologas y capas de protocolos
interrelacionados cuya interpretacin y desarrollo no es nico.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Los estndares de mayor importancia para la comprensin de la arquitectura de Servicios Web son XML,
SOAP y WSDL.
Dichos estndares conforman toda la tecnologa asociada a cualquier
cualquier servicio, independientemente
del lenguaje en el que se haya desarrollado dicho servicio.

Aqu tenemos una imagen que nos muestra los diferentes bloques que conforman un Web Service:

Servicios XML
XML (eXtensible Markup Language) es un metalenguaje extensible de etiquetas desarrollado por el
W3C cuyo propsito es la definicin de datos contenidos en un documento.
La palabra Extensible en su definicin hace referencia al hecho de que XML no es un lenguaje en
particular, sino un estndar para la definicin
definicin de nuevos lenguajes que se utilizarn para el intercambio
de informacin entre diferentes plataformas, de forma que el desarrollador puede definir y extender sus
propias etiquetas y crear su propio lenguaje para adaptarse a las necesidades de la aplicacin.
a
Existen dos tipos de documentos XML: aquellos que contienen la informacin propiamente dicha y los
documentos de especificacin del lenguaje.

Documentos de Datos XML


El componente principal de los documentos XML son las etiquetas representadas
representa en el formato
y entre las cuales se encuentran los datos.
Los tres principales tipos de elementos etiqueta son diferenciables:
x Elementos que contienen otros elementos anidados, como
<Informacion>
<Nombre>
</Informacion>

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
x Elementos que contienen cadenas de datos, como por ejemplo que contiene la
informacin sobre el nombre de la informacin.
<Informacion>
<Nombre>dato</Nombre>
</Informacion>
x Elementos que estn vacos pero que aportan informacin con su presencia o con sus
s atributos,
como en el ejemplo con el atributo id del nodo informacin:
<Informacion id=identificador>
<Nombre>dato</Nombre>
</Informacion>
Los documentos XML han de ser vlidos y bien formados, es decir, deben ajustarse a las reglas
semnticas definidas
as por su XML Schema o su DTD correspondiente y han de ajustarse a las normas de
sintaxis XML.
Debemos diferenciar entre un documento XML bien formado y un documento XML vlido.
Un documento xml bien formado es un documento que mantiene las reglas sintcticas
sintcti del lenguaje xml,
diferenciando mayculas y minsculas en su sintaxis, por ejemplo.
Un documento xml vlido es un documento que mantiene una estructura asociada a otro tipo de
documento que indicar los nodos que representar o el nmero de elementos que
q contendr cada
nodo. A dicho documento asociado se le conoce por XML Schema o DTD.
Los servicios Web tienen una estructura de documento XML y envan la informacin al cliente-
cliente
consumidor mediante SOAP, que es un esquema.
Por ejemplo, imaginemos que tenemos
mos la siguiente clase que representa un servicio web en java:
package paquetees;

import javax.jws.WebMethod;
import javax.jws.WebService;

@WebService()
public class NewWebService {

/**
* Web service operation
*/
@WebMethod(operationName = "operation")
public Integer operation() {
int numero = 20;
return numero;
}
}
Cuando hagamos una solicitud en el cliente, veremos las operaciones devueltas en formato XML:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Como podemos comprobar en la imagen, uno de los bloques ms importantes dentro de la
arquitectura de los Web Services es la arquitectura SOAP.
Las Arquitecturas Orientadas a Servicios, estn motivadas por la creciente necesidad de los negocios de
responder con rapidez a los cambios en el entorno comercial en que se desenvuelven.
Esto los lleva a tener que cambiar sus sistemas tecnolgicos con esa misma rapidez y para lograrlo es
necesario que los componentes de esta infraestructura, sean tan reutilizables y poco interdependientes
que permitan una rpida reestructuracin de los mismos.
Los elementos bsicos que conforman SOA son:
x Proveedores de Servicios
x Consumidores de Servicios
x Bus Empresarial de Servicios
Adems podemos definir otros elementos participantes dentro de una arquitectura
arquitect SOA tales como:

Cliente
Se entiende Cliente como el componente que invoca un servicio provisto por un proveedor.

Concepto de servicio
Un servicio es una unidad de trabajo realizada por un componente de software a fin de conseguir un
resultado especfico.
El servicio debe ser alcanzable por parte de los consumidores a travs de una interfaz programtica.

Utilizacin de web services


La arquitectura orientada a servicios, no especifica necesariamente que los servicios deben ser
brindados a travs de un protocolo
otocolo especfico.
Los Web Services son en realidad un conjunto de estndares que definen un protocolo de invocacin
remota de servicios, basados en HTML y XML.
Si bien, son tambin un mecanismo adecuado y en muchos casos recomendable para implementar
servicios no son el nico.
Es importante que las arquitecturas orientadas a servicios soporten mltiples protocolos a fin de cumplir
al mximo su visin de brindar un modelo de integracin para toda la plataforma tecnolgica.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
El fichero WSDL (Web Services Description Language), en formato XML, describe al ordenador que lo
consulta, la forma de comunicacin, es decir, los requisitos del protocolo y los formatos de los mensajes
necesarios para interactuar con los servicios listados
lis en su catlogo.
Del mismo modo, al igual que en la Web tenemos buscadores como Google, que nos llevan a las
pginas que nos interesan, existe el concepto equivalente a nivel de Servicios Web, que es UDDI
(Universal Description Discovery Integration).
Integration)
UDDI es un repositorio en lnea que se puede utilizar desde las aplicaciones para descubrir de forma
dinmica otros servicios en lnea, todos ellos perfectamente integrados en una interfaz XML simple.
La funcionalidad de los protocolos y lenguajes empleados
empleados en estos servicios es la siguiente:
x XML (eXtensible Markup Language): Un servicio Web es una aplicacin Web creada en XML.
x WSDL (Web Services Definition Service): Este protocolo se encarga de describir el servicio Web
cuando es publicado.
x Es el lenguaje XML que los proveedores emplean para describir sus servicios Web.
x SOAP (Simple Object Access Protocol): Permite que programas que corren en diferentes sistemas
operativos se comuniquen. La comunicacin entre las diferentes entidades se realiza mediante
med
mensajes que son rutados en un sobre SOAP.
x UDDI (Universal Description Discovery and Integration): Este protocolo permite la publicacin y
localizacin de los servicios. Los directorios UDDI actan como una gua telefnica de servicios
Web.

Ventajas e inconvenientes de los servicios Web


Ventajas
Los servicios Web en todo su conjunto ofrecen las siguientes ventajas tecnolgicas que han provocado
que hayan tenido mucho xito:
Interoperabilidad
Cualquier servicio Web puede interactuar con cualquier otro servicio
serv Web.
El protocolo SOAP permite que cualquier servicio pueda ser ofrecido o utilizado independientemente
del lenguaje o ambiente en que se haya desarrollado.
Omnipresencia
Los servicios Web se comunican utilizando HTTP y XML.
Cualquier dispositivo que trabaje con stas tecnologas puede tanto ser un cliente del servicio como
servidor en algunas circunstancias.
Mnimo Esfuerzo
Los conceptos detrs de los servicios de Web son fciles de comprender y se ofrecen Herramientas de
Desarrollo especficas por [WebLogic], Sun, Apache los que permiten a los programadores implementar
rpidamente servicios Web con SOAP.
Uno de los problemas a solucionar para los servicios Web es la gestin de sistemas altamente
distribuidos ya que algunos servicios Web delegan
delegan funcionalidades a otras de ms bajo nivel.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Seguridad de los Servicios Web
Las expectativas alrededor de la tecnologa de servicios Web son grandes, tambin puede tener sus
riesgos ya que los servicios Web hacen uso de las mismas tecnologas que han sido
s atacadas en tantas
ocasiones.
Si los usamos, la seguridad de una empresa puede verse comprometida. La ausencia de tcnicas de
seguridad estndar es un obstculo para la adopcin de la tecnologa.
La calidad de un Servicio Web es un parmetro que no est demasiado claro, pero cuya medida es
fundamental a la hora de desarrollar un servicio estable y maduro.
Esta tecnologa est en desarrollo y la mayora de los protocolos en los que se basa, son
recomendaciones a seguir.
Actualmente, los servicios Web estn siendo ampliamente aceptados por las empresas para el
desarrollo de software de uso interno.
De esta forma, los servicios pueden implementar toda su funcionalidad y permanecer seguros tras el
firewall de la empresa.
Los desarrollos actuales no ayudan a la cooperacin entre las empresas ya que no hay ningn estndar
establecido sobre las tcnicas de seguridad.
Debido a la tecnologa que es usada por los servicios Web, y en concreto, al uso de SOAP, las tcnicas
de seguridad
eguridad convencionales que se han venido usando en Internet, ya no son suficientes.
Con SOAP, cada mensaje simple que se intercambia realiza mltiples saltos y es enrutado a travs de
numerosos puntos antes de que alcance su destino final.
Es por ello que los servicios Web necesitan tecnologas que protejan los mensajes desde el principio
hasta el final.
Existen un conjunto de tcnicas que se pueden usar para garantizar la seguridad a nivel de mensaje
SOAP.
x Cifrado de XML: Evita que los datos se vean expuestos a lo largo de su recorrido.
x Firma Digital XML: Asocia los datos del mensaje al usuario que emite la firma, de forma que este
usuario es el nico que puede modificar dichos datos.
x SAML y la Autorizacin: SAML (Security Assertion Mark-up
Mark Language)
age) hace posible que los
servicios Web intercambien informacin de autentificacin y autorizacin entre ellos, de modo
que un servicio Web confe en un usuario autentificado por otro servicio Web.
x Validacin de datos: Permite que los servicios Web reciban
reciban datos dentro de los rangos
esperados.
x Ttambin existen tcnicas que permiten mantener la seguridad a otros niveles.
x La seguridad en UDDI permite autentificar todas las entidades que toman parte en la
publicacin de un servicio Web: proveedor, agente
agente y consumidor del servicio.
x De esta forma, nadie podr registrar servicios en el papel de un proveedor o hacer uso de ellos
sin contar con los permisos adecuados.

Ver Video: Visualizar los bloques de un Servicio Web,


Web
en el Mdulo 7. Unidad 1, en la plataforma elearning.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Laboratorio: Servicio Web DNI
Objetivo
Comprender el funcionamiento de los servicios Web dentro de la tecnologa de Java.

Enunciado
Vamos a realizar un Servicio Web que nos devolver la letra del correspondiente a un DNI que
enviaremos como parmetro.
Comenzaremos crendonos un nuevo proyecto Web en NetBeans.

.
Llamaremos al proyecto ProyectoServicios

Utilizaremos el servidor de aplicaciones GlassFish y no utilizaremos Frameworks.


Sobre el proyecto, vamos a agregar un nuevo Servicio Web.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Lo llamaremos ServicioDNI

Vamos a agregar una nueva operacin:

Aadimos un mtodo llamado getLetraNif() que recibir el nmero del DNI y devolver la letra
correspondiente a dicho DNI.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Para conseguir averiguar la letra del NIF respecto
respecto a su nmero debemos seguir las siguientes
instrucciones:
La frmula para calcular la letra del nmero del DNI se recupera de la siguiente forma:
(n DNI - ((n DNI / 23) * 23))
Se mira la equivalencia en la siguiente tabla:
tabla

0=T 4=G 8=P 12=N 16=Q 20=C


1=R 5=M 9=D 13=J 17=V 21=K
2=W 6=Y 10=X 14=Z 18=H 22=E
3=A 7=F 11=B 15=S 19=L 23=T

Ahora vamos a implementar la lgica para poder realizar las acciones del ServicioDNI. Para ello
implementaremos el mtodo de la siguiente forma:
package paquete;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

@WebService()
public class ServicioDNI {

/**
* Web service operation
*/
@WebMethod(operationName = "getLetraNif")
public String getLetraNif(@WebParam(name
getLetraNif(@WebPar = "numerodni")

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
int numerodni) {
String letrasdni = "TRWAGMYFPDXBNJZSQVHLCKET";
int resultado = (numerodni - ((numerodni / 23) * 23));
Character letra = letrasdni.charAt(resultado);
return letra.toString();
}
}

Una vez que lo tengamos, ser el momento de probar el servicio y su funcionamiento:

Veremos la pantalla de presentacin del servicio:

Si invocamos el servicio, comprobaremos que el dato de la letra es devuelto:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 2: Analizando la tecnologa y plataforma de
servicios Web

Objetivos
x Conocer la arquitectura de los Servicios Web en diferentes entornos de trabajo.
x Comparar las arquitecturas de los Servicios Web en los lenguajes ms potentes del mercado.

Introduccin
Como hemos podido comprobar, los servicios Web no son una tecnologa nica del lenguaje java J2EE,
a pesar de encontrarnos dentro de dicho entorno.
Cuando utilizamos servicios web, el propsito de dichos servicios es encontrar una arquitectura que sea
capaz de comunicarse entre diferentes plataformas, independientemente del lenguaje de
programacin en el que se hayan creado los servicios.
La tecnologa que permite que los servicios web se comuniquen entre diversos lenguajes tiene que ver
con el formato de los datos
atos enviados en el servicio y con el esquema generado para dicho servicio
web.
Mediante los esquemas SOAP cualquier lenguaje es capaz de entender los objetos y mtodos que sern
devueltos en un servicio web.
Lo que veremos en este captulo es la comparativa
comparativa entre las dos grandes plataformas sobre las que se
pueden desarrollar los servicios web, Visual Studio Net y Java.

Arquitectura SUN Web Services


En la actualidad Sun ofrece tres ediciones
edi de la plataforma Java 2. Cada una de ellas tiene una
finalidad.
Estas plataformas
ormas son slo especificaciones, lo que quiere decir que no son productos terminados listos
para usar, sino que son documentos que definen cmo deben ser esos productos, cmo deben
comportarse y qu requisititos deben cumplir.
A los productos que cumplen las especificaciones se les llama implementaciones.
Las tres ediciones de la plataforma Java 2 son:
x Standard Edition (J2SE)
x Enterprise Edition (J2EE)
x Micro Edition (J2ME)
La Standard Edition es la plataforma bsica y ms extendida, la que se suele conocer como Java
Development Kit o JDK.
Con ella se pueden hacer applets y cualquier clase de aplicacin no distribuida.
La Enterprise Edition recubre la Standard Edition aadindole
aadindole una serie de APIs que permiten crear
aplicaciones de empresa
mpresa en el lado del servidor, es decir, aplicaciones para ser utilizadas en Internet.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
La Micro Edition ofrece un entorno de ejecucin altamente optimizado para todo tipo de dispositivos
con recursos
rsos limitados, como mviles, PDAs, etc.
Segn Sun MicroSistem J2EE (Java 2 Platform Entreprise Edition) es un conjunto de estndares y
especificaciones para el desarrollo de aplicaciones empresariales basado en la tecnologa Java.
Las llamadas aplicaciones
es empresariales son aplicaciones del lado del servidor, aplicaciones grandes y
complejas que proporcionan servicios a travs de Internet o redes privadas.
J2EE proporciona un modelo de programacin que consiste en un conjunto de APIs y que dirige la
manera de construir aplicaciones.
La idea principal de J2EE es la de proveer un estndar simple y unificado para aplicaciones distribuidas
a travs de un modelo de aplicaciones basado en componentes.
Para la construccin de un servicio Web bajo la arquitectura
arquitectura J2EE, deberemos utilizar Java como
lenguaje de programacin.
El modelo que sigue J2EE es el siguiente:
La aplicacin est asociada a un conjunto de clases con las cuales podemos definir objetos.
Gracias a estos objetos se ocultan al programador las dificultades
dificultades de desarrollar una aplicacin capaz
de responder y aceptar peticiones a travs de la red, as como la interpretacin de estas peticiones, su
envo y recepcin.
Este conjunto de clases se obtiene como paquete complementario al conjunto de clases
clase que en
principio ofrece directamente java para implementar y consumir servicios Web.
La funcionalidad de la aplicacin en si es construida utilizando componentes EJB (Enterprise JavaBeans).
Estos componentes proporcionan acceso a base de datos mediante JDBC (Java DataBase
Connectivity) o SQL/J (Lenguaje de consultas para bases de datos),
datos), acceso a otros sistemas gracias a
JCA (Java Conector Architecture) o acceso a servicios Web utilizando JAX (Java APIs for XML).
En general, la lgica de la aplicacin est construida gracias al conjunto de clases que proporciona el
lenguaje Java.
Cualquier aplicacin puede conectarse a una aplicacin J2EE utilizando la tecnologa de servicios Web
(por ejemplo XML).
Un objeto es capaz de recibir peticiones y contestar a estas, utilizando directamente JAX APIs para
ejecutar las operaciones.
En definitiva todas las clases y aplicaciones Java pueden convertirse
convertirse en servicios Web utilizando Java

API for XML.
J2EE define un estndar para el desarrollo de aplicaciones empresariales
empresariales y simplifica las aplicaciones.
Dichas aplicaciones se basan en componentes modulares y estandarizados, dando un completo
conjunto de servicios a estos componentes, y manejando muchas de las funciones de la aplicacin de
forma automtica, sin necesidad
ecesidad de una programacin compleja.
Como hemos comentado, las aplicaciones empresariales para web de la tecnologa Java estn
compuestas por los siguientes componentes:
Las aplicaciones J2EE estn formadas por los siguientes componentes:
x Componentes Clientes
x Clientes Web
x Applets

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
x Aplicaciones Cliente
x Componentes Web
x Servlets
x Pginas JavaServer Pages (JSP)
x Componentes de Negocios
x Entreprise Java Beans
x Session Beans
x Entity Beans
x Message Driven Bean

Arquitectura NET Web Services


De acuerdo con la definicin de Microsoft,
Microsoft Visual Studio Net es una plataforma que comprende
servidores, clientes y servicios.
Desde el punto de vista de la arquitectura de servicios web para esta plataforma, net utiliza una
implementacin basada en estndares abiertos
abier como SOAP o WSDL.
Desde el punto de vista del programador, el entorno .NET ofrece un solo entorno de desarrollo para
todos los lenguajes que soporta (Visual Basic, C++, C#, Visual J#, Fortran, Cobol, etc).
Esta plataforma utiliza los Servicios Web como
como un medio para poder comunicar distintas tecnologas.
Permite conectar distintos sistemas operativos, dispositivos fsicos, informacin y usuarios.
La idea central de .NET es la de servicio final a los clientes, y ms concretamente software como servicio
servi
y de cmo construir, instalar, consumir, integrar o agregar estos servicios para que puedan ser
accedidos mediante Internet.
La plataforma .NET utiliza Internet y su capacidad de distribucin para que los usuarios accedan desde
cualquier dispositivo, en cualquier sistema operativo y lugar a la funcionalidad que los servicios Web
proveen.
NET Framework es la parte ms importante de la plataforma .NET.
Incluye COM+, un.entorno de ejecucin comn, un compilador JIT, y un conjunto de libreras de sistema
sistem
que dan acceso a un amplio conjunto de servicios .NET.
Los componentes ms importantes de la arquitectura NET son:
x CLR (Common Language Runtime)

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
x El conjunto de clases del .NET Framework
x ASP.NET
x Remoting
x Windows Forms
La estrategia .Net es innovadora respecto a los productos anteriores de Microsoft, en el sentido de que
no compila aplicaciones en cdigo nativo, es decir, no compila aplicaciones en cdigo especfico.
La compilacin, al igual que sucede con Java, se realiza
realiza en dos pasos sucesivos.
El cdigo escrito por el programador se compila en MSIL (Microsoft Intermediate Language), del mismo
modo que las instrucciones en Java se convierten en bytecodes.
Despus el CLR (Common Language Runtime) de Microsoft compila en tiempo de ejecucin las
aplicaciones en cdigo nativo de la plataforma.
Esto se realiza mediante el compilador JIT (Just in Time).
El CLR tambin revisa el cdigo, verificando la seguridad del mismo y recolectando los objetos para los
cuales no existe ya ninguna referencia (recoleccin de basura), adems de gestionar las excepciones
entre otras tareas.
En principio, cualquier programa escrito en MSIL puede ejecutarse en cualquier sistema operativo
o
donde funcione un CLR, aunque en realidad, las aplicaciones
aplicaciones para la plataforma Net estn creadas
para sistemas operativos de Microsoft.

NET Framework es la base de cualquier desarrollador de .NET.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Es un conjunto de clases, interfaces y tipos que simplifican y optimizan el desarrollo de aplicaciones .NET,
.NET
adems
dems de proporcionar acceso a la funcionalidad del sistema.
ASP.NET es la parte de .NET dedicada al desarrollo Web.
A travs del servidor Web IIS (Internet Information Services) las aplicaciones ASP.NET se ejecutarn bajo el
CLR pudindose usar el conjuntounto de clases del NET Framework para desarrollarlas, obteniendo as una
versatilidad
idad y una potencia nunca antes conseguida en las aplicaciones asp.
NET Remoting nos permite tener objetos en mquinas remotas e invocarlos desde otras.mquinas.
La tecnologa Windows Forms, permite desarrollar clientes grficos independientes al navegador.
Otra innovacin de .NET es el lenguaje C# (C Sharp) incluido en esta plataforma por primera vez en la
versin 2003.
Es un lenguaje orientado a objetos fuertemente tipado,
tipado, diseado por Microsoft para obtener un
elevado rendimiento con una relativa simplicidad del lenguaje.
C# juega un importante papel en .NET porque ha sido diseado para trabajar de forma ptima con
esta plataforma y ciertas caractersticas de .NET se implementaron
implementaron pensando en que su rendimiento
fuera ptimo con C# (de hecho, algunas bibliotecas de .NET como Collection, XML, ADO+, ASP+, GDI+ y
otras fueron escritas en C#).
En esta tabla podemos observar a comparativa entre las tecnologas de Sun y Microsoft
Micro que permiten
poder obtener una arquitectura de comunicacin estndar entre los servicios web.

Caractersticas .NET J2EE


Tipos de tecnologa Producto Estndar

Empresas que lo Microsoft Existen mltiples proveedores


ofrecen
para ofrecer la tecnologa de
J2EE, no existe una empresa
oficial sobre la que
implementar las
caractersticas de Sun.
Libreras de desarrollo NET Framework SDK Java Core API

Intrprete CLR (Common Language JRE (Java Runtime)


Runtime)

Pginas dinmicas ASP .NET Servlets, JSP


Componentes .NET Components EJB
Managed
Acceso a bases de ADO .NET, LINQ JDBC, SQL/J
datos
Servicios Web SOAP, WSDL, UDDI, SOAP, WSDL, UDDI, RestFul
Windows Communication

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Foundation
Interfaces grficas Windows Forms y Web AWT y Java Swing
Forms
Herramientas de Visual Studio .NET Depende del fabricante, las
programacin
ms conocidas son NetBeans
y Eclipse.
Transacciones MS DTC JTS
distribuidas
Servicios de ADSI JNDI
directorios
Librera de encolado MSMQ JMS
y mensajes
Lenguajes utilizados C#, Visual Basic, Java
C++otros
Lenguaje intermedio IL Bytecodes

Comparacin en las arquitecturas de Servicios Web


El propsito tanto de J2EE como de la plataforma .NET es facilitar y simplificar el desarrollo de
aplicaciones empresariales o corporativas.
Las pginas JSP (Java Server Pages) son muy similares a ASP (Active Server Pages) o a su descendiente
ASP .Net, y los EJB (Enterprise JavaBeans) son muy similares a los COM/COM+ de Microsoft.
Los servidores de aplicaciones J2EE y .Net proporcionan un modelo de acceso de componentes a datos
y de lgica del negocio, separados por una capa intermedia de presentacin implementada
im mediante
ASP .Net o Servlets si hablamos de la tecnologa J2EE.
J2EE
Visual Basic .Net y C# son lenguajes orientados a objetos, al igual que Java, y en su diseo ha tenido
mucha importancia la existencia de Internet.
Desde la perspectiva de los desarrolladores,
esarrolladores, J2EE y .Net proporcionan las herramientas para crear
Servicios Web.
Al usar .Net una compilacin en dos pasos le permitir tericamente proporcionar entornos de
ejecucin para diferentes plataformas de forma similar
s a Java y sus JREs y SDKs,
Ks, aunque Java soporta
cualquier plataforma y Net funciona bajo sistemas operativos Microsoft.
Una ventaja muy importante del entorno .Net frente a J2EE es la posibilidad de emplear mltiples
lenguajes de programacin, mientras que J2EE slo trabaja con Java.
La realidad es que la diversidad de lenguajes es obligatoria por la misma variedad de las necesidades
de los programadores.
Un lenguaje moderno y orientado a objetos como Java puede resultar inadecuado a la hora de
abordar problemas que involucren clculos matemticos masivos y complejos, mientras que esos
mismos clculos pueden ser abordados mucho ms adecuadamente con un lenguaje primitivo como
Fortran.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Por otro lado, .Net posibilita as que programadores de terceros lenguajes pasen a esta plataforma
pla
reduciendo el tiempo de aprendizaje y entrenamiento.
Las herramientas de desarrollo incluidas por Microsoft en Visual Studio .Net son mucho ms simples,
intuitivas y sencillas de manejar que las herramientas de desarrollo equivalentes en J2EE suministradas
sum
por otras empresas (entre ellas la propia Sun).
Cualquier programador medio-avanzado
avanzado se manejar rpidamente con la programacin del interface
de usuario en Visual Studio .Net, al igual que suceda con versiones anteriores de Visual Studio.
C# es un lenguaje interesante, fcil de aprender por los programadores de Java (de hecho, Microsoft
ofrece un conversor de Java a C#), que en caso de estandarizarse podra resultar un lenguaje muy
conveniente para ciertas tareas de programacin en diferentes
diferent plataformas.
Las implementaciones de J2EE pueden adquirirse a distintas compaas, mientras que .Net slo a
Microsoft.
El hecho de que haya distintas organizaciones implementando J2EE ofrece mayor variedad para los
usuarios finales y permite la existencia de una cierta competencia entre ellas para obtener mejores
productos que no existe
te en el caso de Microsoft y Visual Studio .Net.
Debido al proceso evolutivo de los productos de Microsoft, y en muchos casos, por motivos de
compatibilidad, la seguridad
guridad frente a virus informticos de los productos de Microsoft es menor que los
basados en Java, pues desde un comienzo Java se fundament en un estricto modelo de seguridad.
Como se ha escrito ya, las aplicaciones Java pueden correr en una amplia gama gam de sistemas
operativos (desde sistemas empresariales como Windows 2000, OS/390, Solaris, HP-UX, HP IRIX u otras
versiones de Unix hasta en sistemas orientados ms a ordenadores personales como Mac OS, Windows
9x Linux, y en sistemas operativos para dispositivos
dispositivos mviles) y de arquitecturas hardware.
Hasta la fecha, .Net corre solamente sobre sistemas operativos de Microsoft (aunque esta situacin
podra cambiar en el futuro), siendo J2EE el nico entorno de desarrollo que ofrece una independencia
real de la plataforma.
La tecnologa Java es una tecnologa abierta, en el sentido de que el cdigo de la plataforma
completa puede ser obtenido, revisado y estudiado por cualquiera que est interesado, y se basa en
gran parte en estndares de organizaciones de normalizacin y estndares empresariales. Esto
posibilita que los desarrolladores puedan conocer y entender completamente cmo hace las cosas
Java y aprovecharlo para sus aplicaciones.
Por otro lado, al basarse en estndares empresariales, simplifica la integracin con productos de
mltiples compaas.
En contraposicin, solo el cdigo fuente del lenguaje C# de la plataforma .Net ha sido abierto al
pblico general.
Aunque Java fue creado originalmente por Sun MicroSystems, lo cierto es que J2EE es ahora
ahor el producto
de la colaboracin de muchas empresas y organizaciones de todo tipo.
La plataforma .Net es el producto de una sola compaa, que aunque haya implementado algunos
estndares en .Net y est intentando conseguir que ciertas tecnologas se conviertan
conv en estndares
"oficiales", no puede tener el mismo consenso que J2EE,
J2EE sobre todo porque casi todo su cdigo no es
pblico.
La tecnologa Java goza
oza ya de una cierta veterana, J2EE y ha probado su eficacia en muchos entornos
y situaciones empresariales
ales distintas, mientras que .Net ha visto oficialmente la luz de una forma
relativamente reciente.
Podemos perfectamente comparar un servicio web creado bajo la plataforma Visual Studio y un
Servicio web creado bajo la plataforma J2EE.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Al compararlos, veremos
emos que los esquemas SOAP son los mismos y que la arquitectura de comunicacin
es la misma.
Si visualizamos el cdigo de un servicio web creado en Net, veremos lo siguiente:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Services;

namespace WebService1
{
/// <summary>
/// Descripcin breve de Service1
/// </summary>
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
// Para permitir que se llame a este servicio Web desde un script, usando ASP.NET AJAX, quite la
marca de_
comentario de la lnea siguiente.
// [System.Web.Script.Services.ScriptService]
public class Service1 : System.Web.Services.WebService
{

[WebMethod]
public string HelloWorld()
{
return "Hello World";
}
}
}

Cuando probemos el servicio, veremos una pantalla en el explorador web y que nos mostrar los
mtodos que utiliza dicho servicio.

Como podremos comprobar, los servicios creados en la plataforma de Visual Studio utilizan la extensin
de archivo asmx y no vemos el esquema WSDL.
Si queremos visualizar el esquema WSDL bastara con
con escribir lo siguiente en el explorador web para
poder representarlo.
http://localhost:7722/Service1.asmx?wsdl
Este es el esquema resultante de un servicio web en NET:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Si invocamos el mtodo HelloWorld del servicio, veremos el resultado expresados en datos XML.

Ahora vamos a visualizar la arquitectura de un servicio web creado en Java. Realizaremos el mismo tipo
de servicio con un mtodo tambin llamado HelloWorld y que devolver un mensaje del tipo String.
package paquete;
import javax.jws.WebService;
import javax.jws.WebMethod;

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
import javax.jws.WebParam;

@WebService(serviceName = "NewWebService1")
public class NewWebService1 {

/** This is a sample web service operation */


@WebMethod(operationName = "helloworld")
public String helloworld(@WebParam(name = "name") String txt) {
return "Hello " + txt + " !";
}
}

Cuando probemos el servicio, (como en net) veremos


veremos una pantalla en el explorador web y que nos
mostrar los mtodos que utiliza dicho servicio.

La informacin del esquema WSDL ser la misma que en una aplicacin realizada con Visual Studio.
La extensin para un Servicio Web creado en Java ser wsdl.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Si invocamos el mtodo, la visualizacin es diferente, pero el XML generado en la salida ser el mismo
que un servicio web realizado en otro lenguaje.

Podemos visualizar la solicitud SOAP

Y podremos visualizar la respuesta que nos ofrece el servicio.


servici

Ver Video: Arquitectura Web Services,


en el Modulo 7. Unidad 2, en la plataforma elearning.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 3: Aplicando XML

Objetivos
x Conocer los conceptos de los documentos XML.
x Analizar las caractersticas de XML con documentos bien formados y su validacin.
x Comprender la utilizacin de documentos XML y Schemas para la representacin y estructura de
datos dentro de los Servicios Web.

Introduccin
XML significa eXtensible Markup Language, o lenguaje de anotacin extensible. Ya conocemos el
lenguaje
e HTML (hypertext markup language), lenguaje de anotacin para pgina webs que permite
navegacin tipo hipertexto, sin embargo, XML no es slo un lenguaje, es una forma de especificar
lenguajes, de ah lo de extensible.
Todo lenguaje que se exprese de una forma determinada puede ser XML. Por lo tanto, XML no es un
lenguaje para hacer mejores pginas web, sino un lenguaje para informacin auto-descrita,
auto o al menos,
auto-descrita
descrita si las etiquetas estn correctamente creadas.
XML se inici como un subconjunto
o de SGML (Structured Generalized Markup Language), un standard
ISO para documentos estructurados que es sumamente complejo y que se utilizaba para poder servir
documentos en internet.
XML es una implementacin de SGML simplificado, de manera que una aplicacin
apli no necesita
comprender SGML completo para interpretar un documento, sino slo el subconjunto que se defina.
Los editores SGML, sin embargo, pueden comprender XML.
No debemos pensar que XML se utiliza para la creacin de pginas web, o algo parecido a las pginas
web.
XML es un lenguaje que cambia el paradigma de programacin, que como ya sabemos, est basada
en funciones u objetos, y dicha programacin utiliza los documentos para representar la informacin.
XML se puede utilizar para cambiar totalmente
totalmente el paradigma de publicacin de informacin. Podemos
pensar en un programa que recibe unas entradas y produce unas salidas, se envia un documento que
genera otro documento, o bien programas que toman documentos y producen otros documentos.
Por eso, en general, exceptuando los entornos de servicios web, lo normal es que el documento XML se
use en el servidor, y se sirva otro tipo de documentos traducidos a HTML, por ejemplo, que se obtienen a
base de una serie de transformaciones.
Precisamente, todo este planteamiento hace que los documentos XML se usen dentro de entornos de
aplicaciones.
Este entorno de aplicaciones permite publicar documentos XML, que, antes de ser enviados al cliente,
sufrirn una serie de transformaciones para adaptarlo a los requisitos
requisitos del entorno.
Algunos ejemplos de entorno de aplicaciones son el Cocoon, un entorno basado en Java libre, que
permite no slo publicar pginas XML, sino tambin incluir programas dentro de las pginas (XSP). No se
caracteriza por su velocidad ni amigabilidad, pero es excelente como entorno de desarrollo. Otra
alternativa gratuita es el AxKit, escrito en Perl.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Como alternativas de pago estn el Bea Weblogic y el IBM WebSphere Transcoding Publisher. Podemos
incluir multitud de ejemplos basados en otros lenguajes tales como Krysalis, un entorno de publicacin
basado en PHP, que incluye facilidades para ser usado a travs del protocolo SOAP, un protocolo de
acceso remoto a documentos basado en XML.
Lo ms normal es que la informacin est almacenada en una base de datos, se convierta a XML y
luego se transforme para servirlo al cliente.
Dentro de estos entornos de desarrollo y/o publicacin, o usndolo de cualquier otra forma, XML tiene
gran nmero de aplicaciones.
La mayor parte de los portales y sitios de noticias ya estn basados en XML, porque permite estructurar
la informacin y luego aplicarle fcilmente transformaciones para su presentacin.
Podemos poner como ejemplo las noticias RSS que incluyen
incluyen la mayora de medios de publicacin de
internet. Es un ejemplo muy claro sobre la utilizacin de XML en internet y la facilidad que puede ofrecer
para la tecnologa.
RSS es una forma muy sencilla para que podamos recibir, directamente en el ordenador
ordenad o en una
pgina web online (a travs de un lector RSS) informacin actualizada sobre pginas web, sin
necesidad de tener que visitarlas una a una.
RSS utiliza una estructura especfica y que no puede variar, por lo tanto, podemos afirmar que cualquier
rss tiene la misma serie de etiquetas, pero su contenido cambiar respecto al resto.
Esta informacin se actualiza automticamente, sin incluir ninguna accin posterior y sin coste de
programacin, simplemente se debe seguir la estructura y cambiar el contenido.
contenido.
Para recibir las noticias RSS, el portal web deber tener disponible el servicio RSS y podremos utilizar
pginas web o lectores Rss.
Gracias al RSS, no tendremos que visitar una a una todas las pginas web que ofrezcan informacin que
nos interesa para ver si han cambiado los contenidos o visualizar si se ha aadido algn artculo
interesante.
Estas pginas nos informarn a nosotros a travs de un lector de RSS.
Cuando ingresemos una direccin a un lector RSS (o Rss Reader), estaremos automticamente
automticame
informados sobre todas las novedades que se han producido en todas las pginas web que hayamos
dado de alta.
Gracias al RSS, tendremos reunidas en un mismo lugar y a un solo clic de distancia, toda la informacin
actualizada de las pginas web (Fuentes o canales RSS) que ms nos interesan.
Podemos poner como ejemplo cualquier publicacin de prensa via web. Por ejemplo, podemos
visualizar los rss de un peridico digital como El Pais y veremos lo siguiente:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Si entramos en cualquiera de los enlaces (documentos
(documentos RSS), veremos la informacin con un formato
especfico para una pgina web:

En realidad, lo que estamos visualizando es un documento XML con una estructura especfica. Dicha
estructura est basada en un esquema que indica como debe formarse dicho
dicho documento.
Si visualizamos el cdigo fuente, podremos comprobar que tiene una estructura xml:
<?xml version="1.0" encoding="iso-8859
8859-1"?>
<rss version="2.0">
<channel>
<title>Titulo del RSS</title>
<link>Vinculo de acceso al RSS</link>
<description>Descripcion del conjunto</description>
<lastBuildDate>Fecha de actualizacin</lastBuildDate>
<language>es-es</language>
<image>
<url>Vinculo de la imagen</url>
<title>Titulo de la imagen</title>
</image>
<item>
<title>Noticia 1</title>
<link>Vinculo 2</link>

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
<description>Descripcion de la noticia</description>
<author>Nombre del autor</author>
<pubDate>Fecha de publicacin</pubDate>
</item>
<item>
<title>Noticia 2</title>
<link>Vinculo 2</link>
<description>Descripcion de la noticia</description>
<author>Nombre del autor</author>
<pubDate>Fecha de publicacin</pubDate>
</item>
</channel>
</rss>

La estructura es la misma para cualquier documento


documento rss, por lo tanto, cualquier publicacin de noticias
rss tendr los mismos elementos pero con diferente informacin. Gracias a esta estructura, podemos
afirmar que todos los documentos rss sern leidos de la misma forma, porque su estructura no cambiar.
cambi
Si probamos a visualizar cualquier otro artculo RSS, podremos comprobar que tendr la misma
estructura, aunque con diferentes noticias.
Lo importante de la afirmacin de lo que acabamos de analizar con las noticias rss es su importancia
para poder ofrecer
recer informacin en un formato accesible y que est compuesto simplemente por
etiquetas ilustrativas.

Estructura de documentos XML


XML no tiene un formato cerrado ni un entorno sobre el cual se deba crear. Para editar documentos
XML, al igual que para hacerlo
cerlo con HTML, se puede hace de dos formas: editndolos como cualquier
otro fichero ASCII (el bloc de notas de Windows, por ejemplo), utilizando cualquier editor estructurado
como UltraEdit, o bien usar un editor especfico para XML, que entiende las particularidades
part del
lenguaje y ofrece ayuda en el momento de escribir el documento como puede ser el cierre de
etiquetas de jerarquia.
Un ejemplo de la estructura de un documento XML sera el siguiente:

En el momento de definir las etiquetas XML, debemos de saber que el lenguaje esw casesensitive, es
decir, diferencia maysculas de minsculas en los elementos y en los atributos del documento.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Los mismos entornos incluyen facilidades para validar el cdigo XML resultante, pero esto se puede
hacer tambin usandodo analizadores XML, de los cuales hay muchos, de bastante buena calidad, y la
mayor parte de ellos gratuitos.
Uno de los ms conocidos y usados es el Xerces, del cual hay versiones en Java, en Perl y en C++. Es
adecuadamente rpido, y adems incorpora todostodos los ltimos estndares del W3. Otra opcin, que
adems se puede usar desde Internet, es el XParse de Jeremie, que analiza directamente el documento
y te lo presenta en forma de rbol, aunque elementos como exploradores web tambin incorporan
validaciones
ones de documentos XML, como por ejemplo, Internet Explorer.
La mayor parte de los validadores trabajan de forma independiente, y se pueden utilizar como libreras
desde el lenguaje de programacin de propia eleccin.
En muchos casos, como en el caso de C#,C#, el XML se puede generar automticamente a partir de la
definicin de una clase, o bien, al revs, una clase o un objeto de una clase se puede generar
automticamente a partir de XML o a partir de un fichero.
Si nos centramos en los servicios web, podemos generar documentos xml que se basan en las clases
creadas para ser expuestas hacia el cliente.
Podemos visualizar en ste cdigo una respuesta de un documento XML generado a partir de un
servicio web realizado en Java.
<?xml version="1.0" encoding="UTF-8"
8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:MensajeResponse xmlns:ns2="http://paquetewebservice/">
<return>Servicio Web de Java</return>
</ns2:MensajeResponse>
</S:Body>
</S:Envelope>
Como lenguaje de anotacin, las sentencias en XML consisten en una serie de etiquetas (llamadas
elementos o nodos) con una serie de modificadores (llamados atributos).
Las etiquetas pueden estar anidadas unas dentro de otras, pero toda etiqueta que se abra
a se tiene que
cerrar de una forma jerarquica, es decir, siempre en el mismo orden.
En caso de que un elemento no tenga pareja (por no tener ningn contenido dentro), se le denomina
elemento vaco y se indica con un simbolo / al final. Los elementos se agrupan en documentos, como
por ejemplo el siguiente cdigo:
<?xml version="1.0" encoding='iso-8859
8859-1' ?>
<listacompra>
<productos id='limpieza'>
<producto>Fairy</producto>
<producto>Lavavajilla</producto>
</productos>
<productos id='alimentacion'>
<producto>huevos</producto>
<producto>mantequilla</producto>
<producto></producto>
</productos>
</listacompra>

Todos los documentos XML deben estar bien formados, y este es el requisito mnimo que deben cumplir
los documentos.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Esta afirmacin significa que debemos cumplor una serie de requisitos:
x Debemos indicar la codificacin de caracteres que el documento XML utilizar, eso se realiza
mediante la primera etiqueta del documento y que tiene como atributo encoding. Dicha
codificacin
n indicar los caracteres que podremos incluir dentro de las etiquetas del
documento.
x Todas las etiquetas deben tener una jerarqua, es decir, todos los elementos que contengan
datos de tipo carcter deben tener etiquetas de principio y fin.
x Todos los valores res de los atributos deben ir entrecomillados (el carcter comilla simple puede
utilizarse si el valor contiene caracteres comillas dobles, y viceversa.
x Cualquier elemento VACO (por ejemplo aquellos que no tienen etiqueta final como
y otros tipos de HTML)
HTM deben terminar con o debemos crearlos como no
vacos aadindo una etiqueta de fin, tal como vemos en uno de los elementos producto.
x No podemos utilizar caracteres especiales que formen la estructura del documento, como por
ejemplo si necesitamos incluir
incluir dichos caracteres, se utilizan entidades que representan
dichos caracteres, como por ejemplo &lt; o &amp;.
x Los elementos deben anidar dentro de s sus propiedades (no se deben sobreponer etiquetas,
como en documentos SGML).
x Los nombres de las etiquetas pueden ser alfanumricos, comenzando con una letra, e
incluyendo los caracteres - y :, aunque este ltimo tiene un significado especial.
Todo documento XML debe estar bien formado para poder ser utilizado y que sea funcional.

XML Namespace
Los espacios de
e nombres de un documento nos permiten poder definir la procedencia de un
documento como tambin la estructura que sigue un documento.
Si en cualquier documento fueramos definiendo etiquetas sin sentido, a pesar de estar bien formado, el
documento acabara a siendo un caos de diferentes etiquetas procedentes de diferentes sitios, y, lo que
es peor, de etiquetas con el mismo nombre que, en realidad, significan cosas diferentes.
El concepto de espacios de nombres (namespaces) permite particionar el conjunto de todos los
nombres posibles, de forma que se pueda definir a qu zona de ese espacio corresponde una etiqueta.
De esta forma, etiquetas con el mismo nombre, pero definidas por dos autores diferentes, pueden
diferenciarse en el espacio de nombres.
El espacio
pacio de nombres no es esencial en todos los documentos, pero resulta til cuando se usan
etiquetas procedentes de diferentes procedencias (por ejemplo, etiquetas nuevas dentro de un
documento XML), o etiquetas que se quieren procesar de forma diferente.
El espacio de nombres de una etiqueta se indica como
Por ejemplo, se usan espacios de nombres en el documento siguiente:
<?xml version="1.0" encoding='iso-8859
8859-1' ?>
<milista:listacompra xmlns:milista='http://www.ejemploxml/listacompra'>
<milista:productos id='limpieza'>
<milista:producto>Fairy</milista:producto>
<milista:producto>Lavavajilla</milista:producto>
</milista:productos>
<milista:productos id='alimentacion'>

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
<milista:producto>huevos</milista:producto>
<milista:producto>mantequilla</milista:producto>
>mantequilla</milista:producto>
</milista:productos>
</milista:listacompra>

No es necesario especificar un prefijo para las etiquetas, tambin podemos crear el documento sin
necesidad de hacerlo, y el espacio de nombres indicar la procedencia del documento
docum y las reglas
que debe seguir:
<?xml version="1.0" encoding='iso-8859
8859-1' ?>
<listacompra xmlns='http://www.ejemploxml/listacompra'>
<productos id='limpieza'>
<producto>Fairy</producto>
<producto>Lavavajilla</producto>
</productos>
<productos id='alimentacion'>
<producto>huevos</producto>
<producto>mantequilla</producto>
</productos>
</listacompra>

Un documento XML puede tener tantos espacios de nombres como se quieran declarar, y se pueden
mezclar elementos de diferentes espacios
espacio de nombres.
Por ejemplo, si visualizamos el resultado del mensaje SOAP de un documento XML, podremos comprobar
que utiliza los espacios de nombres para definir la estructura y los prefijos para las etiquetas que utilizar
en el momento de devolver la informacin
ormacin a un cliente:

Validacin de documentos XML


Cuando utilizamos documentos XML, una de las caractersticas que hemos analizado es su estructura, es
decir, que el documento est bien formado, que las etiquetas tengan una apertura y un cierre, se
utilicen caracteres adecuados, etc.
Pero otra caracterstica muy importante es la validacin del documento, lo que quiere decir que la
estructura que hemos creado siga unos pasos determinados, es decir, que las etiquetas sean las
correctas o estn en el orden
den adecuado.
Dentro de la validacin de documentos XML nos encontramos con dos tipos de elementos: DTD y
Schema.
Las DTDs son los documentos que definen las etiquetas vlidas dentro de un documento XML.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Un documento XML, usualmente puede tener asociado otro otro documento llamado DTD, que indicar las
etiquetas que contendr y el orden de las etiquetas en el documento.
Uno de los problemas de las DTDs es, que no son documentos XML en s mismos, no son demasiado
extensibles y adems, no nos permite establecer validaciones
validaciones ms complejas que la propia existencia y
orden de los elementos y atributos.
Una DTD es un archivo que encierra una definicin formal de un tipo de documento y, al mismo tiempo,
especifica la estructura lgica de cada documento.
Define tanto los
os elementos de un documento XML, como sus atributos.
Utilizar una DTD en un documento XML es opcional.
Un documento DTD permite poder diferenciar entre el concepto de documento "bien formado" y un
documento "vlido".
Por ejemplo, podemos visualizar un documento
documento DTD basado en el documento XML de la lista de la
compra que hemos visto anteriormente:

<?xml version='1.0' encoding='UTF-8'?>


8'?>
<!ELEMENT listacompra (productos)*>
<!ATTLIST listacompra xmlns CDATA #IMPLIED>
<!ELEMENT productos (producto)*>
<!ATTLIST
IST productos id CDATA #IMPLIED>
<!ELEMENT producto (#PCDATA)>

Dicha DTD indica el orden de los elementos del documento y el contenido (Atributos) de dichos
elementos, pero por ejemplo, no puede indicar el tipo de dato de los elementos o crear relaciones
relacione
entre dichos elementos.
Los documentos DTD son antiguos, era algo previsible que las DTDs evolucionasen, debido a temas
como tipos de datos o relacin entre las etiquetas de los documentos. Esta evolucin son los schemas
(Esquemas XML).
Al igual que las
as DTD, los Schemas describen el contenido y la estructura de la informacin, pero de una
froma ms precisa.
Los esquemas indican tipos de dato, nmero mnimo y mximo de ocurrencias y otras caractersticas
ms precisas.
Los esquemas expresan vocabularios
vocabularios compartidos que permiten a las mquinas extraer las reglas
hechas por las personas.
Los esquemas proveen un significado para definir la estructura, contenido y semntica de los
documentos XML.
Un esquema XML (XML Schema) es algo similar a un DTD, es decir, decir, define qu elementos puede
contener un documento XML, cmo estn organizados y qu atributos y de qu tipo pueden tener sus
elementos, pero la utilizacin de Schemas ofrece muchas ms posibilidades a los documentos.
Los esquemas utilizan sintaxis XML, al
al contratio que los DTD, permiten especificar los tipos de datos y son
exgtensibles, es decir, permiten crear nuevos elementos.
Un Schema nos permite definir el tipo de contenido de elementos o atributos precisando si debe ser un
nmero entero, una cadena de texto, una fecha, etc.
Un ejemplo de Schema respecto al documento XML lista de la compra es el siguiente:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
<?xml version="1.0" encoding="iso-8859
8859-1"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"_
elementFormDefault="qualified"_
targetNamespace="http://www.ejemploxml/listacompra"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="listacompra">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="productos">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="producto" type="xs:string" />
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Como podemos observar, no solamente indica el orden de los elementos o el nmero de apariciones en
el documento, sino que tambin representa el tipo de datos de los atributos y los elementos.
Es necesario comenzar el esquema definiendo los elementos ms profundamente anidados dentro de
la estructura jerrquica de elementos del documento xml.
Las declaraciones de tipo ElementType y AttributeType deben preceder a las declaraciones de
contenido element y attribute correspondiente.
Un esquems tambin puede verse como una coleccin (vocabulario) de definiciones de tipos y
declaraciones de elementos cuyos nombres pertenecen a un determinado espacio de nombres.
Los espacios de nombres de
e destino hacen posible la distincin entre definiciones y declaraciones de
diferentes vocabularios.
La estructura de un documento XML aplicada a los servicios se define mediante SOAP.
La respuesta de cualquier servicio web viene ofrecida mediante datos xml, y la estructura que definir el
tipo de datos, el orden de los elementos ofrecidos por el servicio y el nmero de elementos se expresa
en un esquema definido como documento WSDL.
Podemos visulizar un ejemplo de WSDL a partir de un servicio web:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ahora que ya conocemos algo ms sobre elementos XML, nos queda responder a la utilizacin de
dichos servicios dentro del entorno de los Servicios Web.

Las razones de la utilizacin de XML en los Servicios Web son las siguientes:
x Es un estndar abierto, es decir, es reconocido mundialmente ya que muchas compaas
tecnolgicas integran en su software compatibilidad con dicho lenguaje de marcado.
Esto quiere decir que la gran mayora de software de escritorio, de sistema operativo, software de
internet o aplicaciones
icaciones mviles permiten la compatibilidad con XML.
Esto lo hace muy potente a la hora de permitir la comunicacin entre distintas plataformas de software
y hardware, lo que es el producto final de los Servicios Web.

x La simplicidad de sintaxis XML, lo que quiere decir que es muy fcil de escribir cdigo en XML, y
la representacin de los datos es casi entendible por cualquier ser humano.
Esto lo hace muy flexible a la hora de querer representar datos de cualquier tipo, con lo que
unicamente bastara con
on contar con cualquier editor de texto y aprender unas cuantas instrucciones
bsicas.
El hecho de que XML sea tan fcil de codificar y de entender lo hace el lenguaje ideal para utilizarlo en
los servicios Web.

x Independencia del protocolo de Transporte. El hecho de que XML sea un lenguaje de Marcado
de Texto significa que no necesita de ningn protocolo de transporte especial, solo necesita de
un protocolo que pueda trasferir texto o documentos simples.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Podemos compararlo con protocolos conocidos y que si necesitan de un transporte especial y un
marcado especial, como son HTTP o SMTP, por nombrar algunos.
Una de las caractersticas ms importantes de los Servicios Web es su independencia del protocolo de
transporte.

Ver Video: Estructura y Validacin de documentos XML,


XML
en el Mdulo 7. Unidad 4, en la plataforma elearning.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 4: Examinando mensajes SOAP

Objetivos
x Comprender la arquitectura de protocolo de mensajes SOAP en los Servicios Web
x Entender el uso de SOAP dentro de los mensajes cliente en Web Service.
x Analizar las caractersticas de SOAP en el envo y la recepcin de datos en Web Services.

Introduccin
SOAP (Simple Object Access Protocol) es un protocolo basado en XML para el intercambio de
informacin.
Implementar una arquitectura orientada
entada a servicio (SOAP) comprende
omprende el desarrollo de aplicaciones que
usen los servicios, aplicaciones disponibles
isponibles como servicios para otras o ambas aplicaciones.
aplicaciones

Un servicio web SOAP es una funcin de aplicacin empaquetada como un componente reutilizable
reutilizab
para ser usado en proceso de negocio.
El servicio proporciona informacin o facilita el cambio de datos de negocio en un estado vlido y
consistente a otro.
La caracterstica principal de SOA es que es una arquitectura con acoplamiento dbil.
Acoplamientoto dbil significa que el cliente de un servicio es casi completamente independiente de la
construccin de ese servicio.
Un Web Service es un servicio que se comunica con los clientes a travs de un conjunto estndar de
protocolos y tecnologa.
Estos estndares
stndares estn implementados en las plataformas y productos de los principales proveedores de
software, lo que hace de los Web Services la principal opcin para lo construccin de arquitecturas
SOAP
Existen varias razones por las que una empresa adopte un desarrollo de arquitectura SOAP basado en
Web Services:
x Reutilizacin.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
El factor fundamental en el cambio a una arquitectura SOAP es la reutilizacin de los servicios de
negocio.
Las funciones de negocio dentro de una empresa pueden ser expuestos como web we services y ser
reutilizados para cubrir las diferentes necesidades de negocio de soluciones.
x Interoperabilidad
El objetivo de una arquitectura dbilmente acopada es que los clientes y servicios se comunican
independientemente de la plataforma en la que residan.
r
Los protocolos de comunicacin con Web Services son independientes de la plataforma, lenguaje de
codificacin y sistema operativo, por lo que facilitan la comunicacin con los procesos de negocio.
x Escalabilidad
Como los servicios de SOAP estn dbilmente
dbilmente acoplados, las aplicaciones que usan dichos servicios se
escalan fcilmente.
Esto se puede realizar porque existe una mnima dependencia entre las aplicaciones clientes y los
servicios que las utilizan.
x Flexibilidad
Es otra de las caractersticas que proporciona el acoplamiento dbil entre los servicios.
Cualquier cambio en la implementacin de uno de ellos, no afectara al resto, siempre y cuando se
mantengan en la interfaz.
x Eficiencia de coste
Las arquitecturas SOAP
AP se basan en la exposicin de servicios ya existentes para ser reutilizados.
Al usar Web Services para exponer estos servicios, se reutiliza la infraestructura web existente en casi
todas las organizaciones, por lo que se limita considerablemente el coste.
cost

SOAP soporta dos modelos de intercambio:


1) Orientado a documentos
x Generalmente operan en forma asincrnica
x El mensaje de respuesta no es fundamental, y si existe,
existe acta como forma de devolver un ticket
o acuse de recibo.
x La construccin del mensaje y su carga til (payload). La carga til del mensaje es la
informacin que se transmite excluyendo aquella que es especfica del protocolo de transmisin.
Caractersticas importantes:
- Medio de transporte.
- Destino del documento (endpoint)

2) Orientado a llamadas remotas (RPC, remote procedure call)


Generalmente operan en forma sincrnica.
Las operaciones llamadas contienen parmetros de entrada y de salida.
Los parmetros de salida suelen modelarse como una estructura de retorno (mensaje de respuesta).

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Caractersticas importantes:
- La operacin particular que se invoca.
- El conjunto de valores de entrada.
- El conjunto de valores de salida.
- La correlacin entre los mensajes de pedidos (requests) con los mensajes de respuesta (response)
(

SOAP est diseado para comunicaciones punto a punto.


Fue desarrollado a finales de 1999 por DevelopMentor (http://www.develop.com), Microsoft y UserLand
(http://www.userland.com) como un protocolo especfico de Windows para ejecutar llamadas RPC con
XML.
En el ao 2000 Lotus e IBM se unieron a este esfuerzo y el objetivo se ampli a producir una
especificacin abierta, extensible e independiente de lenguaje y plataforma.
La primera versin de SOAP, 1.1, fue aprobada como estndar por la organizacin W3C (World Wide
Web Consortium) en Mayo del mismo ao.
En el interior de los servicios Web se localiza el protocolo simple de acceso a datos SOAP, que ofrece un
mecanismo estndar de empaquetar mensajes.
SOAP ha recibido una gran atencin debido a que facilita
facil el uso de una comunicacin del estilo RPC
entre un cliente y un servidor remoto.
Existen
xisten multitud de protocolos creados para facilitar la comunicacin entre aplicaciones, incluyendo
RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA.
Una de las razones ms importantes para la utilizacin y la extensin de SOAP en los Servicios Web es
que SOAP ha recibido un increble apoyo por parte de la industria.
SOAP es el primer protocolo de su tipo que ha sido aceptado prcticamente por todas las grandes
compaas de software del mundo.
Dichas compaas no suelen colaborar o cooperar entre s, pero estn ofreciendo su apoyo a este
protocolo.
Algunas de las mayores Compaas que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y
Ariba.
Ventajas de la utilizacin de SOAP
Una de las mayores ventajas en la utilizacin del protocolo SOAP es que no esta asociado a ningn
lenguaje.
SOAP no especifica ninguna API, por lo que la implementacin de la API se deja al lenguaje de
programacin elegido para desarrollar
arrollar el servicio web,
web, como en Java, y Microsoft .Net.
SOAP no est asociado a ningn protocolo de transporte.
La especificacin de SOAP no describe como se deberan asociar los mensajes de SOAP con HTTP.
Un mensaje SOAP no es ms que un documento XML, por lo que puede transportarse utilizando
cualquier protocolo capaz de transmitir texto.
SOAP no est asociado a ninguna infraestructura de objeto distribuido.
distribuido
La mayora de los sistemas de objetos distribuidos se pueden extender, y ya lo estn alguno de ellos para
que admitan SOAP.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
SOAP utiliza los estndares existentes en la industria.
industria
Los principales contribuyentes a la especificacin SOAP evitaron, intencionadamente, reinventar las
cosas. Cada uno de ellos tena unas caractersticas diferentes en su tecnologa
tecnologa y distribucin, por lo que
decidieron extender los estndares existentes para que coincidieran con sus necesidades.
SOAP aprovecha XML para la codificacin de los mensajes, en lugar de usar un sistema propio de tipo,
por lo que los tipos de datoss ya estn definidos
definido en la especificacin del esquema XML asociado al
Servicio Web.
Como ya hemos comentado, SOAP no define un modelo de transporte para los mensajes,
mensajes los mensajes
enviados por el protocolo SOAP se pueden asociar a los protocolos de transporte existentes como HTTP y
SMTP.
SOAP permite la interoperabilidad
ilidad entre mltiples entornos.
El desarrollo del protocolo se hizo bajo los estndares existentes de la industria, por lo que las
aplicaciones que se ejecuten en plataformas con dicho estndares pueden comunicarse mediante
mensajes SOAP con aplicaciones que se ejecuten en otras plataformas.
Por ejemplo, una aplicacin de escritorio
scritorio que se ejecute en un ordenador, puede comunicarse con una
aplicacin que est sirviendo informacin desde internet capaz de enviar y recibir XML sobre HTTP.
Estructura de los mensajes SOAP
a estructura de un mensaje SOAP indica como se encuentra compuesta la solicitud enviada del
La
Cliente
e hacia el web service y viceversa.
En toda solicitud a un Servicio Web, siempre tendremos la estructura de los elementos que veremos en el
cliente y los datos que visualizaremos posteriormente desde el servicio web.
Vamos a poner como ejemplo un servicio web que indica la temperatura de una regin en un mes y un
ao determinado.
Por ejemplo, lo que necesitaramos recibir desde el cliente sera la regin, el mes y el ao que desea
averiguar el cliente para el resultado.
La solicitud del cliente en el mensaje
e SOAP sera la siguiente:
<?xml version="1.0" encoding="UTF-8"?>
8"?>
<SOAP- ENVIO:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENVIO="http://schemas.xmlsoap.org/soap/envelope/"
ENVIO="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema
="http://www.w3.org/2001/XMLSchema-instance">
<SOAP- ENVIO:Body>
<ns1:temperaturas xmlns:ns1="Datos">
<op1 xsi:type="xsd:string"> Madrid </op1>
<op2 xsi:type="xsd:integer"> Julio </op2>
<op2 xsi:type="xsd:integer">
teger"> 2005 </op2>
</ns1:temperaturas>
</SOAP- ENVIO:Body>
</SOAP- ENVIO:Envelope>
Si analizamos el cdigo de la solicitud del cliente veremos los siguientes elementos:
Primeramente es definido el clsico elemento para un documento/fragmento
documento/fragmento XML:
<?xml version="1.0" encoding="UTF-8"?>
8"?>
Posteriormente, es definido el elemento raz SOAP-ENVIO:Envelope
SOAP :Envelope que como su nombre lo indica
(Envelope=Sobre), es empleado para describir el
el mensaje SOAP que ser enviado.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Dentro del elemento SOAP-ENVIO son definidos tres Namespaces, una para el mismo SOAP-ENVIO,
SOAP otro
para el Schema y uno ms para una instancia del
de Schema.
Terminada la definicin del elemento Envelope se declara el elemento SOAP-ENVIO:Body
SOAP (Como
podemos comprobar, pertenece al mismo Namespace
Namespace que Envelope) que contiene el cuerpo del
mensaje SOAP.
Dentro del elemento Body se anida el elemento ns1:temperaturas,
ns1:temperaturas que indica el inicio del mensaje
hacia el web service llamado temperaturas,
temperaturas debemos dfijarnos en que el Namespace ns1 corresponde
al nombre Datos, tal y como fue definido en el Cliente.
A continuacin, son definidos los tres elementos que contienen los parmetros de entrada para el web
service, uno de tipo string y otross dos de tipo integer. Los valores Madrid, Julio y 2005 representan los
datos proporcionados por el usuario del web service.
Finalizando la estructura, son
on definidos los elementos necesarios para cerrar las descripciones de
ns1:temperaturas, SOAP-ENVIO:Body
:Body y SOAP-ENVIO:Envelope.
SOAP
SOAP proporciona un mecanismo estndar de empaquetar un mensaje.
Un mensaje SOAP se compone de un sobre que contiene el cuerpo del mensaje y cualquier informacin
de cabecera que se utiliza para describir el mensaje.
Un mensaje debe estar dentro de sobre de SOAP bien construido.
Un sobre se compone de un nico elemento envelope,
envelope y el sobre puede contener un elemento Header
y puede contener un elemento body.
Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el cuerpo siguiendo
inmediatamente a la cabecera.
El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no
pertenecen necesariamente al cuerpo del mensaje.
Adems de definir un sobre de SOAP, la especificacin de SOAP define una forma
form de codificar los datos
contenidos en un mensaje.
La codificacin SOAP proporciona un mecanismo estndar para serializar tipos de datos no definidos en
la primera parte de la especificacin del esquema XML.
La especificacin de SOAP tambin proporciona un patrn de mensaje estndar para facilitar el
comportamiento de tipo RPC.
Se emparejan dos mensajes de SOAP para facilitar la asociacin de un mensaje de peticin con un
mensaje de respuesta.
La llamada a un mtodo y sus parmetros se serializan en el cuerpo del mensaje de peticin en forma
de una estructura.
El elemento raz tiene el mismo nombre que el mtodo objetivo, con cada uno de los parmetros
codificado como un subelemento.
El mensaje de respuesta puede contener los resultados de la llamada al
al mtodo o una estructura de
fallo bien definida.
Los resultados de la llamada a un mtodo se serializan en el cuerpo de la peticin como una estructura.
Vamos a visualizar como sera la respuesta de una peticin sobre el servicio de temperaturas que hemos
hem
puesto a modo de ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
8"?>
<SOAP-ENVIO:Envelope
ENVIO:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENVIO="http://schemas.xmlsoap.org/soap/envelope/"
ENVIO="http://schemas.xmlsoap.org/soap/envelope/"

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
xmlns:xsi="http://www.w3.org/2001/XMLSchema
/www.w3.org/2001/XMLSchema-instance">
<SOAP-ENVIO:Body>
<ns1:temperaturasResponse xmlns:ns1="Datos">
<result xsi:type="xsd:double"> 32.6 </result>
</ns1: temperaturasResponse>
</SOAP-ENVIO:Body>
</SOAP- ENVIO:Envelope>
Primeramente es definido el clsico elemento para un documento/fragmento XML:
<?xml version="1.0" encoding="UTF-8"?>
8"?>
Posteriormente, es definido el elemento raz SOAP-ENVIO:Envelope
SOAP :Envelope que como su nombre lo indica
(Envelope=Sobre), es empleado para describir el mensaje SOAP que ser enviado como respuesta.
respuesta
Dentro
entro de este elemento son definidos tres Namespaces, una para el mismo SOAP-ENVIO,
SOAP otro para
Schema y uno ms para una instancia de Schema.
Terminada la definicin del elemento Envelope se declara el elemento SOAP-ENV
ENVIO:Body que contiene
el cuerpo del mensaje SOAP.
Dentro del elemento Body se anida el elemento ns1:temperaturasResponse
ns1: Response que indica la respuesta del
web service llamado temperaturas,
temperaturas como podemos comprobar, el Namespace
Namespa ns1 corresponde al
nombre Datos tal y como fue definido en el Cliente.
A continuacin, ess definido el elemento que contiene el parmetro de respuesta del web service, el
cual es del tipo doubl con el valor 32.6, que representa el resultado procesado por
po el web service.
Por ltimo, sonon definidos los elementos necesarios para cerrar las descripciones de
ns1:temperaturasResponse, SOAP-ENV
ENVIO:Body y SOAP-ENVIO:Envelope.
Por convenio, el elemento raz tiene el mismo nombre que el mtodo original al que se aade
aa result.
Los parmetros de retorno se serializan como elementos hijo, con el parmetro de retorno en primer
lugar.
Si se encuentra un error el cuerpo del mensaje de respuesta contendr una estructura de fallo bien
definida.
Podemos comprobar fcilmente
e que la estructura de los mensajes SOAP es independiente al lenguaje
de programacin.
Por ejemplo, vamos a visualizar el mensaje SOAP de un Servicio Web creado en Java y otro realizado en
Net.
Si tenemos un Servicio Web que devuelve el doble de un nmero realizado en Java, veremos la
siguiente solicitud SOAP del servicio:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Como podemos comprobar, contiene el elemento sobre (envelope) dentro del documento, incluye
un Header y un body con el contenido que hemos enviado a la solicitud del servicio.
Si ahora visualizamos la respuesta que nos ha ofrecido el servicio:

Comprobaremos que los datos expuestos son los mismos que en la solicitud, incluyendo la respuesta
dentro de la etiqueda Return.
Si visualizamos la arquitectura SOAP de un servicio web realizado
realizado con la plataforma Visual Studio
veremos lo siguiente.
Mismo servicio web con un nmero como recepcin y devolucin del doble del nmero recibido como
parmetro:
SOLICITUD SOAP

RESPUESTA SOAP

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Podremos comprobar que la estructura es la misma, por lo que la escalabilidad y la interoperabilidad
entre servicios es muy sencilla, lo que quiere decir, que al utilizar la misma estructura en su arquitectura,
los servicios se pueden comunicar entre diferentes lenguajes intercambiando su informacin.
SOA es una
a arquitectura que permite organizar mucho mejor los sistemas IT de una compaa.
La organizacin y la utilizacin de SOAP dentro de cualquier arquitectura de negocio ofrecer las
siguientes caractersticas:
x Escalabilidad
x Robustez
x Homogeneidad
x Facilidad en la adaptacin de nuevos servicios
x Facilidad en la reestructuracin de sistemas
x Aplicar la lgica en el middleware pudiendo implementar procesos de negocios.
x Recoger informacin y procesarla para obtener resultados ms utiles
x Ahorro en tiempos de implantacin
implantac
x Ahorro en tiempos de mantenimiento y operacin

A pesar de obtener todas estas ventajas, no siempre hay que utilizar los servicios web porque tengamos
una estructura que necesitamos que sea estndar. Tambin tiene sus desventajas la arquitectura.
Por ejemplo, una de las ms importantes es la velocidad en el intercambio de informacin entre
sistemas, ya que es ms lenta que si utilizamos un intercambio de informacin directo de punto a punto
como en aplicaciones cliente-bases
bases de datos, por ejemplo.
El que
ue SOAP sea una arquitectura muy estudiada y utilizada por todos los proveedores de arquitecturas
de desarrollo, no implica que sea recomendable en cualquier escenario.

Ver Video: Estructura SOAP de un Servicio Web Java,


Java
en el Modulo 7. Unidad 4, en la plataforma
plataforma elearning

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 5: Desarrollando Servicios Web usando SOAP
con adjuntos

Objetivo
Explicar las alternativas tcnicas para el envo de documentos adjuntos en una estructura XML.

Introduccin
En aplicaciones de Arquitectura orientada a servicios (SOA) suele requerirse que los datos relacionados
con aplicaciones se encuentren asociados con los archivos XML (Lenguaje de marcado extensible)
usados en la aplicacin.
eado podra estar asociada con el currculum del empleado o una serie
Por ejemplo, la foto de un empleado
de archivos de datos financieros podran estar asociados con una aplicacin que analice los registros
de las cuentas de la empresa.
Una forma eficaz de enviar estos datos asociados es mediante
mediante un adjunto en Protocolo simple de
acceso a objetos (Simple Object Access Protocol o SOAP).
Desde el punto de vista del desarrollo, los adjuntos aportan una mayor adaptabilidad y mejoran el
rendimiento de las aplicaciones, lo cual se traduce en aplicaciones ms usables.
Los adjuntos permiten a sus aplicaciones solicitar los tipos de archivos que sus usuarios podran asociar a
su aplicacin adaptando la aplicacin al entorno especfico de cada usuario.
En realidad, al enviar informacin los datos se codifican bajo base 64, es decir se convierten los
lo datos en
binario, lo que conforma
forma que el adjunto en s se encuentra separado del cuerpo del de mensaje SOAP, por
lo tanto, no se analiza como parte del mensaje y esto elimina la costosa sobrecarga de procesamiento.
proc

Tipos de adjuntos
Un adjunto es un conjunto de datosos asociados con una aplicacin, es decir, los datos se encuentran
adjuntos al mensaje que usa la aplicacin.
En el momento de trabajar con elementos adjuntos dentro de los servicios web podemos
podem hacerlo de dos
formas diferentes:
x Adjunto con enlace implicito
Un adjunto con enlace explcito es un adjunto modelado como parte del lenguaje WSDL (Lenguaje de
Descripcin de Servicios Web) que est enlazada como parte MIME (Extensiones de Correo de Internet
Int
Multipropsito) en un enlace SOAP WSDL.
El protocolo SOAP no contiene ningn elemento que haga referencia al adjunto y el adjunto se
encuentra dentro del soporte SOAP y dentro del Schema WSDL.
Los datos son enviados en modo binario y se recuperan en el cliente de la misma forma.
x Adjunto con enlace explicito
Un adjunto referenciado mediante un elemento href (Referencia SOAP con adjuntos) es un adjunto que
usa el tipo de adjuncin definido por WS-I.
WS
El cuerpo SOAP incluye una referencia al adjunto. El adjunto se encuentra fuera del cuerpo SOAP y est
modelado fuera del archivo WSDL.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Para leer la definicin de los adjuntos referenciados, debemos acceder a elementos de terceros que se
encuentran en direcciones href.
Existen momentos de arquitectura de
d la informacin en algunos documentos XML en los que se requiere
incorporar piezas adjuntas o documentos como parte de la estructura de datos a manejar, unos de los
ejemplos ms frecuente es adjuntar documentos escaneados en formato de imagen.
Para resolver la solucin de adjuntos dentro de documentos y servicios web xml existen dos opciones:
x Incluir los documentos adjuntos en el XML. (Adjunto Implicito)
x Apuntar desde el XML a un repositorio donde se encuentren almacenados los documentos
(Adjunto Explicito)

Modelo de adjuntos implicitos


En el momento de modelar el documento XML en la etapa de creacin del esquema, se deben
considerar las caractersticas del proceso de negocio que se quiere desarrollar y de las caractersticas
de los documentos a incluir para tomar la decisin correcta.
Al incluir
cluir un documento dentro de una representacin XML se ve como una cadena de caracteres
como se muestra a continuacin:
<documentoXML>
<nombre>Usuario</nombre>
<adjunto>BJkkEI@DsERtgY.....</adjunto>
</documentoXML>
Cuando incluimos documentos adjuntos
adjuntos dentro del propio documento XML existen una serie de
ventajas y desventajas:

Ventajas de adjuntos implcitos


x El documento XML contiene todos los datos modelados. (Ej:: datos modelados+nombre+adjunto).
modelados+
x Cuando se intercambia (enviamos/recibimos) el documento XML, se transfiere un solo
documento.
x Si el documento se debe firmar con Firma Electrnica Avanzada, la aplicacin de firma tiene
todos los elementos para el procesamiento.
x Agiliza la arquitectura de repositorio y el flujo de trabajo basados en el documento XML.

Desventajas de adjuntos implcitos


x La incorporacin de archivos binarios puede aumentar el tamao del archivo XML hasta un
punto que dificulta el procesamiento o intercambio de informacin.
x La respuesta del servicio web que devuelve el documento xml con adjunto es ms lenta y la
transferencia de informacin se realiza de forma menos ptima debido a la lentitud del envo.
XML permite la inclusin de archivos binarios a travs del tipo de datos:
datos: xs: base64Binary definido por la
W3C en la direccin:
http://www.w3.org/TR/2001/REC-xmlschema
xmlschema-2-20010502/#base64Binary
El tipo de dato base64binary representa al archivo binario codificado en base64.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Se codifica en base64 para tener una cadena de caracteres
caracteres donde ningn carcter sea prohibido por
el lenguaje XML como son:
Por ejemplo, la estructura de un esquema WSDL para enviar una informacin de un contacto con una
imagen asociada dentro del documento sera la siguiente:

Y el documento XML que tendra la referencia al resultado sera el siguiente:


<Adjuntos>
<imagen>
<Nro>1</Nro>
<Nombre>Usuario</Nombre>
<MimeType>image/jpeg</MimeType>
<DataCodificada>/9j/4AAQSkZJRgABAAEAyADIAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW
5jLiBWMS4wMQD/_
2wCEAAgFBgcGBQgHBgcJCAgJDBQNDAsLDBgREg4UHRkeHhwZHBsgJC4nICIrIhscKDYoKy8xMzQzHyY4PD
gyPC4yMzEBC_
AkJDAoMFw0NFzEhHCExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMf
/EaaI_
AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEBAQEBAQAAAAAAAAECAwQF
AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI
CQoLEAACAQMDAgQD_
BQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1
Njc4OTpDREVGR0h_
JSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6w
sPExcbHyMnK0tPU1dbX2N_
na4eLj5OXm5+jp6vHy8/T19vf4+foRAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBR
CkaGxwQ
</DataCodificada>
</imagen>
</Adjuntos>
Vamos a visualizar un ejemplo para enviar un texto como adjunto dentro de un servicio web.
Vamos a a crearnos un nuevo proyecto en Netbeans del tipo Java Web y seleccionamos Web
Application:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Llamaremos al proyecto EjemploAdjuntos

Utilizaremos el servidor de aplicaciones GlasshFish y no agregaremos ningn Framework al proyecto.


Sobre el proyecto vamos a agregar un nuevo elemento:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
En la carpeta Web Services, seleccionaremos Web Service.

Lo llamaremos ServicioAdjunto

Ahora en nuestro cdigo del servicio, lo que haremos ser agregar un mtodo que nos devolver los
datos de un fichero de texto plano, en el envo, tendremos
tendremos los datos codificados, y al cliente le llegarn
filtrados y decodificados en base 64.
El mtodo que agregaremos devolver un array del tipo de dato byte:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Una vez que hemos agregado el mtodo, vamos a implementarlo para devolver un texto codificado en
binario.
Para ello, debemos utilizar la clase base64 para que en la salida del flujo binario no existan caracteres
especiales que no admitan el protocolo http de los servicios web.
El cdigo de la clase del Servicio Web quedar de la siguiente forma:
package paquetews;
import com.sun.org.apache.xerces.internal.impl.dv.util.Base64;
import javax.jws.WebMethod;
import javax.jws.WebService;

@WebService()
public class ServicioAdjunto {

/**
* Web service operation
*/
@WebMethod(operationName = "adjuntoBinario")
public byte[] adjuntoBinario() {
String texto = "java";
byte[] salida = Base64.decode(texto);
return salida;
}

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
}
Debemos agregar el espacio de nombres de apache para poder enviar
enviar la codificacin de datos
binarios:

Ahora vamos a probar el servicio web para mostrar el envo de informacin codificada y la
decodificacin en el cliente. Para ello vamos a recuperar el Tester de Netbeans para mostrar los datos
del servicio:

Veremos
os la pantalla de presentacin del servicio:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Cuando pulsemos sobre el botn para visualizar los datos en binario, veremos el resultado de enviar los
datos en binario:

Si visualizamos la respuesta, veremos que el texto llegar al cliente decodificado:

Modelo adjuntos referenciados (Explcitos)


Apuntar o referenciar un documento adjunto, significa indicar la URL en la cual se encuentra dicho
documento.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
La forma correcta de referenciar los documentos en un XML, puede ser de las siguientes formas:
x Utilizando href

<documentoXML>
<nombre>Usuario</nombre>
< adjunto href=http://www.ejemplos.com/documento.doc/>
</documentoXML>
x XLink

<documentoXML>
<nombre>Usuario</nombre>
<adjunto xmlns:xlink="http://www.w3.org/XML/XLink/0.9" _
xlink:type="simple" xlink:href=" http://www.ejemplos.com/documento.doc/>
</documentoXML>
Al igual que sucede con los documentos XML que contienen la informacin de forma implcita, los
documentos XML con adjuntos explcitos tienen sus ventajas y desventajas:
desven

Ventajas adjuntos explicitos


x Permite no cargar la instancia XML en trmino de tamao.
x Permite tener extensibilidad en caso de lista (el documento XML puede apuntar tanto a 10
documentos como a 10.000)

Desventajas adjuntos explicitos


x El documento XML no contiene todos los datos modelados.
x Cuando se intercambia (enviar/recibir) el documento XML, se transfiere un documento. Luego,
el receptor debe pedir los documentos relacionados segn necesidades.
x Si el documento se firma con Firma Electrnica Avanzada, la aplicacin de firma debe pedir
todos los documentos antes de generar una representacin del objeto a firmar.
x Esto en el caso de que los adjuntos sean parte de los datos que se requiere firmar.
x Requiere de un repositorio permanentemente disponible y de simple acceso, especialmente
cuando se intercambian estos documentos XML.
x Requiere una gestin de cambios de los adjuntos y permanencia de todas las versiones en un
repositorio.
x Si un documento en formato XML firmado con Firma Electrnica Avanzada apunta a adjuntos en
un repositorio, al momento de verificar la firma electrnica 2 aos despus de su creacin, los
adjuntos a los cuales apunta el XML deben ser los originales,
originales no modificados.

Formato de adjuntos en Servicios Web


En el proceso de intercambio de informacin entre instituciones, se debe resolver el problema de
transferir un expediente de documentacin asociado a un proceso de negocio.
Este intercambio de informacin actualmente se realiza
realiza a travs de Servicios Web con estructura SOAP.
La estructura SOAP es un documento XML, donde se pueden incluir otro documento XML como parte
del SOAP o como archivo binario.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
En un mensaje SOAP, se ocupa la misma tcnica de incorporacin del archivo binario
bin en formato
Base64binary como se indic anteriormente.
Este mtodo es el mismo que utilizan los servidores de correo cuando transfieren los archivos adjuntos de
un email,, dicha transformacin se hace a nivel del servidor y es transparente al nivel del usuario.
Al nivel de la interfaz del servicio Web, se pueden especificar los mtodos de envo que optimizan el
mensaje cuando contiene archivos.
Los estndares de optimizacin de transferencia de archivos binarios han ido evolucionando para
incorporar compatibilidad con los estndares de Web Services.

Cronolgicamente, los estndares de transferencia de archivos en servicios Web SOAP son:


x SOAP Messages with Attachments (SwA)
x Direct Internet Message Encapsulation (DIME)
x WS-Attachments
x XML-binary
binary Optimized Packaging (XOP)
x SOAP Message Transmission Optimization Mechanism (MTOM)

Se sugiere utilizar el estndar MTOM por las siguientes caractersticas:


x MTOM optimiza la transferencia de binarios (de tipo base64Binary en el XML)
x MTOM es un mecanismo implementado al nivel del servicio Web (en la prctica, es el servidor
que se encarga de implementar MTOM).
x MTOM opera al nivel de la transmisin del mensaje, eso es, entre el servicio web SOAP y el
consumidor del servicio web.
x MTOM serializa el mensaje en formato MIME Multipart/Related utilizando XOP.
XOP

Laboratorio: Adjuntos explcitos en Servicios Web

Objetivo
Visualizar el funcionamiento de los adjuntos en los servicios web.

Enunciado
Vamos a realizar un nuevo proyecto en el que enviaremos una imagen dentro del documento XML.
El servicio web ser algo muy sencillo, simplemente devolveremos el texto que hace referencia a un
fichero adjunto dentro de una pgina web.
Para ello, nos crearemos una nueva tabla en la que tendremos los datos
datos de unos usuarios y las
referencias http de dnde estn ubicadas sus imgenes.
Recibiremos el dato del usuario y devolveremos en el servicio la direccin http dnde est ubicada su
imagen.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Debemos realizar la siguiente base de datos para poder acceder a los datos de los usuarios:
CREATE TABLE USUARIOS
(ID_USUARIO INT
, USUARIO VARCHAR2(30)
, DIRECCIONIMAGEN VARCHAR2(200));
insert into usuarios values (1,'Xabi Alonso','http://3.bp.blogspot.com/-
Alonso','http://3.bp.blogspot.com/
DHheOC5uJKg/TZkK3VFRzuI/AAAAAAAAAJg/dALQcYUax4I/_
s1600/xabi-alonso-real-madrid.jpg');
insert into usuarios values (2,'Villa','http://www.noticias112.com/wp-
(2,'Villa','http://www.noticias112.com/wp
content/uploads/2010/06/07_Villa_espana_rusia_celebracion_2.jpg');
insert into usuarios values (3,'Casillas','http://4.bp.blogspot.com/_-
(3,'Casillas','http://4.bp.blogspot.com/_
Fo2nyMBaH8/TC_Ad1obWyI/AAAAAAAAAqQ/V
C_Ad1obWyI/AAAAAAAAAqQ/V-J7aScm8Hc/s1600/_
Casillas_987861.jpg');
insert into usuarios values (4,'Iniesta','http://www.experienciapersonal.es/wp-
(4,'Iniesta','http://www.experienciapersonal.es/wp
content/uploads/2010/07/Gol-de-Iniesta.jpg');
Iniesta.jpg');
COMMIT;
A continuacin, nos crearemos un nuevo proyecto en Netbeans
Netbeans de tipo Web Application.

Llamaremos al proyecto ProyectoAdjuntos

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Utilizaremos el servidor de aplicaciones GlassFish y no utilizaremos Frameworks.
Sobre el proyecto, vamos a agregar la librera para trabajar con Oracle.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Sobre el proyecto vamos a agregar un nuevo Servicio Web

Lo llamaremos ServicioAdjuntos

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Vamos a agregar una nueva operacin:

Aadimos un mtodo que recibir el Id del usuario y devolver la direccin del adjunto explicito.

Tambin crearemos un mtodo para poder devolver el


el nombre del usuario a travs de su ID.
El cdigo del Servicio Web quedar de la siguiente forma:
package paquete;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import java.sql.*;

@WebService()
public class ServicioAdjuntos {

public enum TipoConsulta


{
NOMBREUSUARIO, DIRECCIONIMAGEN
};

@WebMethod(operationName = "datosUsuarios")
public String datosUsuarios(@WebParam(name = "idusuario")
int idusuario) {
return this.getDato(idusuario, TipoConsulta.DIRECCIONIMAGEN);
}

@WebMethod(operationName = "nombreUsuarios")

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
public String nombreUsuarios(@WebParam(name = "idusuario")
int idusuario) {
return this.getDato(idusuario, TipoConsulta.NOMBREUSUARIO);
Tip
}

private String getDato(int idusuario, TipoConsulta tipo)


{
try
{
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system",
DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system",
"java");
Statement stmt = conn.createStatement();
String consulta;
consulta = "SELECT * FROM USUARIOS WHERE ID_USUARIO=?";
PreparedStatement smt = conn.prepareCall(consulta);
conn.pre
smt.setInt(1, idusuario);
ResultSet rs = smt.executeQuery();
rs.next();
String dato="";
if (tipo == TipoConsulta.NOMBREUSUARIO)
{
dato = rs.getString("USUARIO");
}else
{
dato = rs.getString("DIRECCIONIMAGEN");
}
rs.close();
return dato;
}catch (Exception ex)
{
return ex.getMessage();
}
}
}
Una vez que lo tengamos, ser el momento de probar el servicio y su funcionamiento:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Veremos la pantalla de presentacin del servicio:

Si invocamos el servicio, comprobaremos que el dato es devuelto:

Y el adjunto va en la respuesta XML del servicio

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 6: Explicando el lenguaje de Servicios Web
(WSDL)

Objetivos
x Aprender los conceptos de fundamentales de los documentos WSDL.
x Conocer la estructura de cualquier documento WSDL dentro de los Servicios Web.
x Visualizar la relacin de los esquemas XSD con los Servicios Web.

Introduccin
WSDL ess un protocolo basado en XML que describe los accesos al Web Service.
Podriamos decir que es el manual de operacin del web service, porque nos indica cuales son las
interfaces
rfaces que provee el Servicio web y los tipos de datos necesarios para la utilizacin del mismo.
WSDL es el lenguaje propuesto por el W3C para la descripcin de Servicios Web y permite describir la
interfaz de un servicio web en un formato XML.
Una de las ventajas de WSDL es que permite separar la descripcin abstracta de la funcionalidad
ofrecida por un servicio, es decir, de los detalles concretos del mismo, como puede ser el enlace a un
protocolo de red o un formato de mensaje concreto que puede ser SOAP, HTTP o MIME.
MIME
WSDL describe los servicios Web a travs de los mensajes que se intercambian entre el proveedor del
servicio y el cliente.
El intercambio de mensajes se define mediante operaciones.
Una coleccin de operaciones forma un tipo de puerto.
Un tipo de puerto constituye la descripcin completa de la interfaz del servicio de manera abstracta.
Esta descripcin abstracta es unida luego a un formato de mensaje concreto, lo cual permite describir
una interfaz concreta del servicio.
Cada servicio contiene uno o varios puertos y cada
ada puerto indica la localizacin de la interfaz concreta
del servicio.
Podemos visualizar los elementos de un documento WSDL en la siguiente figura:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Un documento WSDL contiene
ntiene un nmero de versin y un componente raz Definition,
Definition que posee un
nombre, Name y un atributo TargetNameSpace, que declara el espacio de nombres al que
pertenecern todos los nombres de componentes definidos en el documento.
Un componente Definition puede contener un componente Types y,, adems podr contener uno, cero
o ms componentes Message, Porttype,
Porttype Binding, Service e import.
Todos los componentes de WSDL pueden tener asociado un componente Documentation.
Documentation
Un componente Types se utiliza para la definicin de los tipos de datos que sern necesarios para el
envo de mensajes.
a en el estndar XML Schema.
Para esta definicin, WSDL se basa Schema
Por ello contiene un componente Schema y asociado a ste, componentes Element que describen
cada uno de los tipos de datos, de acuerdo al estndar de los esquemas XML.
WSDL permite incluir documentos XML Schemas definidos
definido previamente y para ello utiliza un componente
Include,, a travs del cual se indica la localizacin del documento.
De la misma forma, un componente Import se utiliza para reutilizar definiciones hechas en otros
documentos WSDL, indicando el nombre y localizacin del documento que se desea importar.
El componente PortType se utiliza para describir el conjunto de mensajes que sern intercambiados
interc
entre el proveedor del servicio y el cliente.
Los mensajes se agrupan en operaciones, es decir, etiquetas Operation.
Cada operacin contiene un nombre y puede tener uno, dos o tres mensajes asociados, es decir, un
mensaje de entrada, mensaje de salido o los dos al mismo tiempo,
tiempo, y opcionalmente,
opcionalmente un mensaje de
excepcin.
Un mensaje est definido con la etiqueta message y contiene una definicin similar a la de una funcin,
contiene un nombre y parmetros con la etiqueta Part.
Part
El tipo asociado a un Part puede ser un tipo base XSD de los esquemas XML (int, float, string, etc.) o un
tipo definido en la seccin de tipos creados en el propio Servicio Web y enviado en ste.
ste
En este ltimo caso, el tipo de dato puede ser asociado a travs de un atributo
atribut type o element,
dependiendo del tipo de dato que se desea asociar.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
El componente PortType describe completamente la interfaz del servicio de manera abstracta.
El componente Binding describe un formato de mensaje y protocolo de transmisin concretos (SOAP,
(SOAP
HTTP o MIME) para el enlace con un componente PortType.
WSDL define diferentes componentes para describir
describir cada uno de estos protocolos.
protocolos
El componente Port define el punto concreto de acceso al servicio.
Contiene un nombre y combina un componente Binding con la direccin donde se accede a la
implementacin del servicio.
Por ltimo, el componente Service,, contiene un nombre, que ser el nombre del servicio y uno o varios
puertos,, con la etiqueta Port, asociados.
Un ejemplo de documento WSDL es el siguiente:
siguie
<?xml version="1.0">
<definitions>
<types>
...
</types>
<message>
...
</message>
<portType>
...
</portType>
<binding>
...
</binding>
</definitions>
En esta tabla podemos visualizar el significado de cada elemento dentro del documento WSDL anterior.

Elemento WSDL Descripcin

<?xml version="1.0"> Un documento WSDL es como cualquier documento xml y se


basa en los esquemas, por lo que debe comenzar con el tag

<definitions> Comienzo del documento, este tag agrupa a todos los dems
elementos

<types> Se definen los tipos de datos utilizados en el Web Service

</types> Fin de la definicin de tipos

<message> Se definen los mtodos y parmetros para realizar la


operacin.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Cada message puede consistir en una o ms partes
(parmetros).

</message> Fin de la definicin de los parmetros

<portType> Esta seccin es la ms importante, ya que se definen las


operaciones que pueden ser realizadas, y los mensajes que
involucran (por ejemplo el mensaje de peticin y el de
respuesta).

</portType> Fin de la definicin de las operaciones y mensajes

<binding> Se definen el formato del mensaje y detalles del protocolo


para cada portType.

</binding> Fin de la definicin del formato del mensaje y detalles del


protocolo para cada PortType

Utilizacin de WSDL en los Servicios Web


En la estructura de cualquier Servicio Web, el fichero WSDL se basa en enviar la informacin y los
mensajes de entrada y respuesta al cliente que realiza la peticin.

Los pasos que se realizan al consumir el servicio son los siguientes:


1) Lo primero que realiza el cliente al hacer una solicitud al servicio es tomar la definicin del
archivo WSDL.
2) El servidor entrega el fichero WSDL. Este archivo indica a la peticin los mtodos y propiedades
de ese servicio que estn disponibles.
3) El cliente hace la peticin en el formato que espera el servidor segn las especificaciones del
fichero WSDL en el que se dice qu parmetros acepta y de qu tipo.
4) El servidor entrega el resultado de la consulta.

El fichero WSDL es del tipo XML por eso su primera lnea ser la siguiente:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
<?xml version="1.0" ?>
A continuacin se escriben las definiciones en la que se establece el namespace al que pertenece
cada uno de los formatos XML que usamos.
Un fichero tipo WSDL pertenece al namespace http://schemas.xmlsoap.org/wsdl/
El cdigo estructurado quedara de la siguiente forma:
<?xml version="1.0" ?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/">
</definitions>
Tambin nos podemos encontrar con la posibilidad de que el Servicio Web introduzca el nombre del
propio servicio en el momento de crear el WSDL, de forma que tambin podramos verlo asi:
<?xml version="1.0" ?>
<definitions name="MiServicioWeb
xmlns="http://schemas.xmlsoap.org/wsdl/">
</definitions>
En realidad, la definicin de un servicio no se realiza sobre la definicin,
definicin, sino que se utiliza la etiqueta
service para indicar el nombre del servicio, depende de la antigedad del servicio y de la tecnologa
que se haya utilizado para crearlo.
Cualquier servicio SOAP quedara con la siguiente estructura:
<?xml version="1.0" ?>
<definitions name=" MiServicioWeb
xmlns="http://schemas.xmlsoap.org/wsdl/">
<service name="MiServicioWeb">
</service>
</definitions>
Dentro del arbol del Servicio se puede abrir otra etiqueta para incluir una descripcin del servicio.
servicio
<?xml version="1.0" ?>
<definitions name="MiServicioWeb
xmlns="http://schemas.xmlsoap.org/wsdl/">
<service name=" MiServicioWeb ">
<documentation>Este es un servicio que muestra el factorial de un nmero.
</documentation>
</service>
</definitions>

En el momento de trabajar con Servicios Web, dicho servicios van alojados en puertos, dnde se
indicar la direccin del servicio y el tipo de acceso.
Estos puertos junto a la direccin propiamente dicha tienen que tener un nombre.
nombre.
<?xml version="1.0" ?>
<definitions name="MiServicioWeb
xmlns=http://schemas.xmlsoap.org/wsdl/ xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/ >
<service name="MiServicioWeb">
<documentation>Este es un servicio que muestra el factorial de un nmero.
</documentation>
<port name="MiServicioWebPort">
<soap:address location="http://localhost:8082/MiServicio/Servicio1.wsdl" />

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
</port>
</service>
</definitions>
Un Servicio Web no tiene que estar obligatoriamente
obligatoriamente expuesto mediante el uso de SOAP, tambin se
puede exponer mediante el protocolo HTTP GET, en este caso el elemento contendra un
con un cdigo de la siguiente forma:
http:address location="http://localhost:8082/MiServicio/wsdl/Servicio.jsp"/
Los mtodos y parmetros de recepcin y entrega de informacin se envan en elementos con la
etiqueta message.
todos se llaman Mensajes y, normalmente,
Los mtodos n suele haber dos mensajes, uno de entrada y otro de
salida, aunque las posibilidades de definir estrucuturas complejas por parte de cada uno de ellos es
bastante amplia.
Si tuviramos un mtodo llamado getDatos() que recibe un parmetro String con el apellido en el
Servicio Web, la forma de
e definirlo sera la siguiente:
La definicin del mtodo de entrada sera la siguiente:
<message name="getDatosRequest">
<part name="Apellido" type="xsd:string" />
</message>
Y la definicin para el mtodo de salida sera tambin parecida a la siguiente:
siguiente
<message name="getDatosResponse">
<part name="return" type="xsd:string" />
</message>
Todos los parmetros que utilizamos en nuestro ejemplo utilizan datos de la clase String, tanto en la
entrega como en la devolucin, pero podramos haber utilizado cualquier tipo de dato definido en la
estructura de Schemas XML.
<part name=numero type='xsd:int'/>
<part name='resultado' type='xsd:float'/>
Los tipos de datos que podemos definir en un XSD (Schema XML) son los mismos que podemos incluir en
cualquier
alquier WSDL. Algunos tipos de datos ms comunes dentro de los esquemas XSD son los siguientes,
con su transformacin al tipo de dato correspondiente en Java:

XSD Schema XML Tipo dato Java

anyURI String

base64Binary byte[]

boolean boolean

byte int

date java.util.Date

double double

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
float float

int int

string String

long long

Tambin podemos definir clases que sean devueltas en el servicio. Dichas clases devolvern al final de
todo, tipos de datos primitivos.
Tenemos que tener en cuenta que en el momento de definir las devoluciones de parmetros dentro de
un Servicio Web, debemos devolver siempre tipos primitivos, ya que cualquier lenguaje podr leerlos
independientemente del lenguaje en el que se haya construido.
construi
Aunque devolvamos clases personalizadas por nosotros, dichas clases devolvern primitivos en sus
mtodos y propiedades.
Si devolvierarmos, por ejemplo, un objeto ResultSet de java, Visual Studio Net no sera capaz de
traducirlo aunque viniera escrito
to en el esquema WSDL.
Lo que nos quedara para comprender completamente la estructura de los documentos WSDL es la
definicin de los parmetros de entrada y salida en los mensajes.
Para poder indicar si los parmetros son input o output, se utiliza la etiqueta
eti , dnde se indica
el input message y el message de output.
El cdigo sera de la siguiente forma:
forma
<operation name="getDatos">
<input message="namespace:getDatosRequest" />
<output message="namespace:getDatosResponse" />
</operation>
El valor de namespace va incluido en la cabecera de la definicin del servicio.
La coleccin de todas las operaciones (mtodos) expuestos por un servicio se llama portType y se
definen dentro de WSDL con la etiqueta
<portType name="MiServicioWebPortType">
<operation name="getDatos">
<input message="namespace:getDatosRequest" />
<output message="namespace:getDatosResponse" />
</operation>
</portType>
Para acabar con la definicin de un fichero WSDL, solo quedara el Binding,, que es el enlace que
establece la transicin
n desde tipos de datos abstractos a tipos de datos concretos.
<binding name="MiServicioWebBinding" type="namespace:MiServicioWebPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/" />
<operation name="getDatos">
<soap:operation soapAction="url:localhost:8082#MiServicioWeb" />
<input>
<soap:body use="encoded" namespace="url:localhost:MiServicioWeb"

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</input>
<output>
<soap:body use="encoded" namespace=" url:localhost:MiServicioWeb"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</output>
</operation>
</binding>
Despus de analizar todo el contenido de los mensajes WSDL generados por un Servicio Web, habr
quedado claro el contenido de WSDL, pero gracias a los editores tales como NetBeans o Eclipse, no es
necesario generar un WSDL, sino que bastara con crear el Servicio y el propio editor nos crear el
fichero wsdl asociado a dicho servicio.
Vamos a visualizar un ejemplo en el que mostraremos el contenido de un WSDL cuando devolvamos
una clase creada por nosotros y devuelta en el servicio.
Nos creamos un nuevo proyecto Web en NetBeans:

Lo llamaremos AgendaContactos

Utilizaremos el servidor GlassFish y no utilizaremos Frameworks.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Vamos a realizar una sencilla aplicacin en la que tendremos una Clase llamada Contacto.
Los contactos estarn formados por un nombre, un identificador y un nmero de tlefono.
Devolveremos los datos de un contacto en un mtodo en el que recibiremos su identificador.
Comenzamos creando la clase Contacto:

Implementaremos el siguiente cdigo:


package paquetews;
public class Contacto {
private int IdContacto;
private String Nombre;
private int Telefono;
public int getIdContacto() {
return IdContacto;
}
public void setIdContacto(int idcontacto) {
this.IdContacto = idcontacto;
}
public String getNombre() {
return Nombre;
}
public void setNombre(String nombre) {
this.Nombre = nombre;
}
public int getTelefono() {
return Telefono;
}
public void setTelefono(int telefono) {
this.Telefono = telefono;
}
}
Ahora nos crearemos un nuevo Servicio Web llamado ServicioContactos

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Nos crearemos una operacin llamada getContacto()

Incluiremos el siguiente cdigo en el servicio:


package paquetews;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import java.util.*;
@WebService()
public class ServicioContactos {

ArrayList<Contacto> listacontactos = new ArrayList<Contacto>();


public ServicioContactos()
{
Contacto c = new Contacto(1, "Lucia", 917654455);
this.listacontactos.add(c);

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
c = new Contacto(2, "Adrian", 687564333);
this.listacontactos.add(c);
c = new Contacto(3, "Ana", 789776655);
this.listacontactos.add(c);
c = new Contacto(4, "Carlos", 12345678);
this.listacontactos.add(c);
c = new Contacto(5, "Pedro", 4567899);
this.listacontactos.add(c);
c = new Contacto(6, "Raul", 677554433);
this.listacontactos.add(c);
}
@WebMethod(operationName = "getContacto")
public Contacto getContacto(@WebParam(name = "idcontacto")
int idcontacto) {
Contacto c = this.listacontactos.get(idcontacto);
return c;
}
}
Al visualizar el WSDL resultante, veremos que tenemos el siguiente resultado:

Y como podemos
odemos visualizar, la respuesta SOAP en el cliente devolver los tipos de datos primitivos que
son los datos de un contacto buscado.

Ver Video: Crear Servicio Web a partir de documento WSDL,


WSDL
en el Mdulo 7. Unidad 6, en la plataforma elearning

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Laboratorio: Servicio Web Datos de Empleados

Objetivo
Conocer el funcionamiento de los Servicios Web utilizando clases personalizadas y bases de datos.

Enunciado
Vamos a realizar un laboratorio en el que crearemos una clase Empleado y la devolveremos con los
datos de los empleados que encontremos en la base de datos a partir de un mtodo.
Buscaremos los empleados por su nmero de departamento.
Crearemos un nuevo proyecto
royecto web.

Llamaremos al proyecto ProyectoEmpleados


Utilizaremos el servidor de aplicaciones GlassFish y no utilizaremos Frameworks.
Sobre el proyecto, vamos a agregar la librera para trabajar con Oracle.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ahora nos crearemos una nueva clase llamada
llam Empleado

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Implementaremos los atributos de un empleado y los mtodos getter y setter de cada atributo. La clase
quedar de la siguiente forma:
package paquetews;

public class Empleado {


private String nombre;
private String oficio;
private int salario;
private int departamento;

public Empleado()
{
this.nombre = "";
this.oficio = "";
this.salario = 0;
this.departamento = 0;
}

public Empleado(String nombre, String oficio, int salario, int departamento)


{
this.nombre = nombre;
this.oficio = oficio;
this.salario = salario;
this.departamento = departamento;
}

public String getNombre() {


return nombre;
}

public void setNombre(String nombre) {

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
this.nombre = nombre;
}

public String getOficio() {


return oficio;
}

public void setOficio(String oficio) {


this.oficio = oficio;
}

public int getSalario() {


return salario;
}

public void setSalario(int salario) {


this.salario = salario;
}

public int getDepartamento() {


return departamento;
}

public void setDepartamento(int departamento) {


this.departamento = departamento;
}
}
Ahora nos crearemos el Servicio Web. Sobre el proyecto vamos a agregar un nuevo Servicio Web

Lo llamaremos ServicioEmpleados

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Vamos a agregar una nueva operacin:

Aadimos un mtodo que recibir el Id del departamento y devolver los empleados que pertenecen a
dicho departamento en objetos de la clase Empleado.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
El cdigo del Servicio Web quedar de la siguiente forma:
package paquetews;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import java.util.*;
import java.sql.*;

@WebService()
public class ServicioEmpleados {
@WebMethod(operationName = "getEmpleados")
public Empleado[] getEmpleados(@WebParam(name = "iddepartamento")
int iddepartamento) {
try
{
ArrayList<Empleado> listaempleados = new ArrayList<Empleado>();
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system",
DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system",
"java");
Statement stmt = conn.createStatement();
String consulta;
consulta = "SELECT ENAME, JOB, SAL, COMM, DEPTNO FROM EMP WHERE DEPTNO=?";
PreparedStatement smt mt = conn.prepareCall(consulta);
smt.setInt(1, iddepartamento);
ResultSet rs = smt.executeQuery();
while (rs.next())
{
Empleado emp = new Empleado();
emp.setNombre(rs.getString("ENAME"));
emp.setOficio(rs.getString("JOB"));
emp.setSalario(rs.getInt("SAL"));

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
emp.setDepartamento(rs.getInt("DEPTNO"));
listaempleados.add(emp);
}
rs.close();
int longitud = listaempleados.size();
Empleado arrayempleados[] = new Empleado[longitud];
listaempleados.toArray(arrayempleados);
return arrayempleados;
}catch (Exception ex)
{
System.out.println("Excepcion: " + ex);
return null;
}
}
}
Una vez que lo tengamos, ser el momento de probar el servicio y su funcionamiento:

Veremos la pantalla de presentacin del servicio:

Sii invocamos el servicio, comprobaremos que los datos de los empleados son devueltos:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Si nos fijamos en el documento WSDL, veremos los mensajes de Empleado en las etiquetas message:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 7: Reconociendo el papel de los servicios
de registro

Objetivo
Conocer el funcionamiento de los directorios UDDI dentro de la tecnologa de los Servicios Web.

Introduccin
Los Servicios Web en Internet estn tomando cada vez ms importancia.
Se disean como sistemas transparentes de informacin que ocultan la complejidad de los sistemas
finales y permiten una fcil comunicacin.
Los problemas que existen en el mundo de los Servicios Web no son su creacin ni su implementacin
final, problemas que se pueden resolver con sintaxis del lenguaje e implementaciones
implementacion de cdigo de los
Servicio y con la documentacin propia del lenguaje creador del servicio.
Su principal problema es el descubrimiento. Lo que quiere decir al final, es que existen multitud de
Servicios Web en internet, pero si no estn ubicados en ningn
ningn lugar ni en ningn buscador, es difcil
descubrirlos.
De ah naci UDDI (Description Discovery And Integration), que es una especie de localizador dnde se
pueden especificar las descripciones de los servicios web y su localizacin en internet.
Es algo
lgo fundamental tener un medio de localizar esos servicios, tarea ms difcil conforme crece el
nmero de servicios disponibles.
Si quiero buscar Servicios Web en internet, tendr que utilizar la tecnologa UDDI para poder acceder a
la informacin que necesito
sito encontrar.
De esta forma, si tuviramos varios Web Services tales como:
x Estado de tiempo
x Descripcin de productos comerciales,
x Operaciones de transacciones financieras
Sera posible publicarlos a un directorio UDDI, permitiendo que sean descubiertos
descubierto en un directorio
conocido y centralizado.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Directorio UDDI (Description Discovery and Integration)
UDDI apareci en el entorno tenolgico con la intencin de centralizar web services comunes, as como
ofrecer un deposito central donde se puede acudir a realizar bsquedas de web services especficos.
UDDI ha sido desarrollado por un grupo de empresas entre las que figuran principalmente Microsoft, IBM
y SAP, estas compaias as como algunos otros consorcios se encargan de mantener y ofrecer este tipo
de servicios en Internet.
UDDI es uno de los estndares bsicos de los servicios Web cuyo objetivo es ser accedido por los
mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los
formatos del mensaje solicitado para
ara interactuar con los servicios Web del catlogo de registros.
La especificacin UDDI simplifica la tarea de publicacin de Web Services, permitiendo a una
organizacin publicar informacin sobre los servicios que ofrece y localizar informacin sobre servicios
ser
web que necesita utilizar.
UDDI describe el interfaz externo de un Web Service y como debera ser utilizado.
Podemos definir un archivo WSDL como un documento XML que describe un conjunto de mensajes
SOAP y la forma en que stos se intercambian.
Puesto
sto que la notacin que utiliza WSDL es XML, esto significa que es un idioma de programacin
neutral, basado en estndares (W3C) y que puede utilizarse desde una gran variedad de plataformas y
lenguajes.
Un servicio UDDI, adems de describir el contenido WSDL, WSDL, define todos los elementos necesarios para
utilizar el servicio, es decir, interfaz, lugar en el que est disponible, protocolo de comunicaciones, etc.
UDDI es, simplemente, un repositorio de documentos XML con sus Schemas XML que define un mensaje
SOAP
AP para el registro y peticin de informacin.
Un fichero de registro es un documento XML-UDDI
XML UDDI que consta de tres elementos principales:
x Pginas blancas: Indican la direccin, contactos, e identificadores de empresa la empresa que
ofrece el Servicio Web.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
x Pginas
ginas amarillas: Ofrecen la categora industrial basada en la estructura propuesta por el
repositorio UDDI.
x Pginas verdes: Contienen la informacin tcnica que describe los servicios web.

Caractersticas de los directorios UDDI


x UDDI es un sistema ideado para describir servicios, junto con WSDL, y localizar empresas que
ofrezcan estos servicios.
x UDDI significa Descripcin, Localizacin e Integracin Universales.
x Es un directorio para almacenar informacin sobre servicios web. Entre otras caractersticas,
caracterstica
guarda las interfaces de esos servicios descritas en el documento WSDL.
x UDDI utiliza SOAP para llevar a cabo las comunicaciones.
x Est desarrollado e integrado en la plataforma .NET de Microsoft.
x UDDI ha sido propuesto por Dell, Fujitsu, HP, Hitachi, IBM,
IBM, Intel, Microsoft, Oracle, SAP y Sun, entre
otros fabricantes.

Gracias al directorio UDDI, podemos realizar una sera de operaciones que nos sera imposible sin tener
un repositorio de Web Services:
x Podemos descubrir la empresa ms adecuada a nuestra lgica de negocio de entre las muchas
presentes en Internet.
x Podemos obtener informacin sobre cmo contactar con esa empresa
x Conseguir nuevos clientes y facilitar el acceso a los actuales
x Incremento de los servicios ofertados y extendiendo el mercado al que
que se puede acceder
x Describir servicios y procesos empresariales en un entorno seguro y fcil de utilizar.
Un ejemplo de cmo se podra utilizar el repositorio UDDI sera el siguiente:
Pongamos un ejemplo en el que se creara un estndar UDDI para reserva y venta de entradas de cine.
Los cines podran registrar sus servicios en un directorio UDDI siguiendo ese estndar e interface UDDI.
De esta forma, las pginas web de reserva de entradas online, podran obtener acceso al repositorio
UDDI a travs de la interfaz,
nterfaz, y podran comunicarse con el servicio ofrecido por cualquier cine para
hacer las reservas y ventas de entradas, manteniendo la misma estructura para todos.
La estructura de UDDI para acceder a los servicios como para publicarlos es la siguiente:

El Servicio UDDI contiene seis entidades:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
x Provider
x Persona, grupo u organizacin que ofrece una serie de Servicios Web XML.
x Contact
x Persona de contacto para informar sobre los temas relacionados con los Servicios del proveedor
correspondiente.
x Service
x El propio Servicio Web
x Binding
x El punto de acceso al Servicio Web o URL del Servicio.
x Instace info
x Referencia a un tModel que contiene informacin tcnica relevante sobre un Binding.
x tModel
Informacin tcnica sobre la interfaz, incluida dentro del documento
docum WSDL.
Tambin puede representar una unidad organizativa con datos descriptivos, como un identificador.

Otros Repositorios de Servicios Web


ebXML es otro tipo de registro para Web Services que surgi previo a UDDI y fue desarrollado por OASIS
("Organization for the Advancement of Structured Information Standards") asi como la divisin de las
Naciones Unidas CEFACT ("United Nations Centre for the Facilitation of Procedures and Practices in
Administration, Commerce and Transport").
nsport").
Para accesar un directorio UDDI o ebXML generalmente se utiliza cualquier navegador de internet para
dar de alta los respectivos web services por lo que su uso es relativamente sencillo.
Aunque un Navegador sea la forma clsica de acceder a los Directorios
Directorios para web services, existen otros
mecansimos como JAXM ("Java API for XML Registries") que permiten el acceso a este tipo de directorios
de una manera programtica.

WSIL-Web
Web Service Inspection Language
WSIL es una especificacin muy reciente iniciada
iniciada por IBM y Microsoft que ofrece un mecanismo
complementario a UDDI y ebXML para encontrar web services en una red como Internet.
Existen dos razones principales por las que surgi WSIL:
x Falta de Moderacin: Debido a la misma escalabilidad con la que fue diseado UDDI, existe una
clara falta por moderar los web services que son publicados en este tipo de Directorios, lo
anterior trae consigo la publicacin de "Web Services Description Language/(WSDL)" invalidos, la
duplicidad de WSDL e incluso la publicacin
publicacin de Servicios Web que no estn disponibles.
x Falta de Calidad de Servicio (QoS) : Este punto aunque relacionado con el anterior se refiere a la
garantia del servicio ofrecido por el proveedor del web service, esto es, debido a que UDDI es un
directorio
o pblico en Internet, nadie garantiza que el web service utilizado o comprado cumpla
con determinados requisitos.
Esto nos lleva al antiguo concepto de negocios: Comprar o adquirir a quien ya conocemos, y es
precisamente en este principio en el que esta basado WSIL.

A diferencia de UDDI donde se realizan busquedas en un directorio centralizado, mediante WSIL se


inspecciona un "Web-Server"
Server" conocido realizando una bsqueda por web services y es mediante
archivos escritos en WSIL que se logra su descubrimiento.
descubrimie

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Sin embargo, es tan reciente dicha especificacin que sus implementaciones son minimas.

Publicacin de Servicios Web en UDDI


Actualmente los servicios UDDI estn desapareciendo de las pginas debido a alojamientos Web que
contienen toda la informacinin sobre servicios y se han especializado en bsquedas y alojamiento sin
utilizar la tecnologa de directorio, por lo que pondremos este caso a modo de informacin en la
unidad. Otra de las razones del desgaste en su uso es la falta de control de los servicios,
ser adems de la
aparicin de nuevas tecnologas en el momento de la creacin de Servicios Web como son los Servicios
RestFul, que son servicios que no utilizan protocolo SOAP.
Si queremos descubir sitios web SOAP, existen multitud de sitios que se han especialidado en exponer
servicios web y su disponibilidad, tales como:
http://webservices.seekda.com/
La publicacin en UDDI es un proceso relativamente sencillo.
El primer paso consiste en determinar informacin bsica sobre cmo definir la empresa y los
l servicios en
UDDI.
El siguiente paso, una vez determinada esta informacin, consiste en llevar a cabo el registro, ya sea
mediante programacin o a travs de una interfaz de usuario basada en el Web.
Por ltimo, se debe probar la entrada para asegurar que se registr correctamente y que aparece tal y
como se esperaba en diferentes tipos de bsquedas y herramientas.
Definir la entrada de UDDI
Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta informacin importante
antes de establecer una entrada de UDDI.
Determinaremos los tModels (archivos WSDL) que utilizan las implementaciones del servicio Web.
Al igual que sucede
ede en el desarrollo de un componente COM, el servicio Web se ha desarrollado a partir
de una interfaz existente o de una interfaz de diseo propio.
En el caso de un servicio Web basado en una interfaz WSDL existente, deberemos determinar si el
archivo WSDL
DL se ha registrado en UDDI.
Si es as, debemos comprobar su nombre y tModelKey, que es el identificador GUID que gener UDDI
cuando se produjo el registro.
Si el servicio Web se basa en un archivo WSDL que no se ha registrado en UDDI, debermos crear un
nuevo tModel para representar esta interfaz.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
El nombre de este tModel debera tener un formato URI (identificador de recursos uniforme), como
MiEmpresa-com:EjemploWebService
com:EjemploWebService-interface:v1,
interface:v1, y sealar la ubicacin del archivo WSDL.
Si el servicio Web es un servicio de Microsoft Visual Studio .NET, podremos generar una descripcin WSDL
utilizando una cadena de consulta desde el archivo .ASMX.
No obstante, el archivo WSDL generado por Visual Studio .NET se relaciona estrechamente con el punto
de acceso para la a invocacin del servicio Web, lo cual puede no resultar adecuado cuando la interfaz
del servicio tiene varias implementaciones.

Determinaremos el nombre de la empresa y una breve descripcin de la misma en varios idiomas, si es


necesario, as como los contactos
ontactos principales para los servicios Web que ofrece.
UDDI es compatible con el espacio de nombre xml:lang, lo que permite a las empresas ofrecer su
descripcin en varios idiomas.
Asimismo, UDDI permite enumerar los contactos, incluyendo datos como el correo electrnico, el
telfono y la direccin. Esta lista de contactos muestra los recursos de una empresa con los que se
puede poner en contacto en relacin con los servicios Web ofrecidos.
Por ejemplo, si un usuario desea comenzar a utilizar el servicio
servicio Web deber ponerse en contacto con el
responsable de relaciones comerciales correspondiente pero, cmo puede llegar a saber quin es?
Existe algn contacto para obtener asistencia tcnica a la hora de utilizar los servicios Web de la
empresa? Tambin se debera incluir en la lista a esta persona.
Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web porque
ste se haya registrado en UDDI.
A una entrada de registro UDDI le pueden acompaar medidas de seguridad, autorizacin
autori y
autenticacin.
No basta que el usuario sepa que existe un servicio Web para que pueda invocarlo. Puede existir una
comunicacin fuera de banda entre empresas antes de permitir el acceso a un servicio Web.
Registrar la entrada de UDDI
Una vez finalizada
nalizada la tarea de definicin, el siguiente paso consiste en registrar la empresa.
Debemos obtener una cuenta con un registro UDDI.
Esta operacin no se puede realizar mediante programacin, ya que deberemos mostrar nuestra
conformidad con una declaracin
in de condiciones de uso.
El nodo de Microsoft utiliza Passport para la autenticacin, as que debemos adquirir una cuenta de
Passport (http://www.passport.com/Consumer/default.asp) para continuar con el registro.
En este punto se ofrecen dos opciones: podemos utilizar la interfaz de usuario Web del nodo o realizar el
registro mediante programacin dirigiendo al propio nodo las llamadas a API de SOAP.
Si no pensamos modificar la entrada o sta es relativamente simple, bastar con la interfaz de usuario
Web.
No obstante, si pretemos actualizar la entrada con frecuencia, o bien, sta es ms compleja, resulta
recomendable realizar el proceso de registro con secuencias de comandos.
Buscar la entrada en UDDI

Es recomendable realizar tres comprobaciones una


una vez registrada la entrada en UDDI.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
En primer lugar, utilizando la interfaz de usuario Web. Existen multitud de pginas que realizan la
bsqueda de los Servicios Web en el registro UDDI.
Debemos buscar la empresa por su nombre y categorizaciones para verla entre los conjuntos de
resultados devueltos.
En segundo lugar, utilizaramos la herramienta de NetBeans para crearnos clientes para Servicios Web.
Bastara con hacer una referencia en el
e proyecto al archivo WSDL.
UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una coleccin de
software basado en servicios Web.
WSDL ofrece un modo formal de definir servicios Web, independientemente del proveedor, que
permitir realizar llamadas a procedimientos remotos de prxima generacin, mientras que UDDI
proporciona una amplia infraestructura estandarizada que permite al usuario describir y descubrir
servicios Web.
Mediante la combinacin de estos dos estndares,
estndares, se podr desarrollar todo un universo de servicios
Web

Ver Video: Test Web Service UDDI,


en el Mdulo 7. Unidad 7, en la plataforma elearning

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 8: Implementando servicios web mediante
Java API para servicios web XML usando la
tecnologa (JAX-WS)
(JAX

Objetivos
x Entender el funcionamiento de los servicios web utilizando JAVA-WS.
JAVA
x Creacin y estructura de un Servicio Web JAVA-WS
JAVA

Introduccin
Un servicio
icio es un procedimiento, un mtodo
m o un objeto con una interfaz estable y pblica
p que puede
ser invocado por un cliente.
Los Servicios Web amplian esa idea para permitir que esa invocacin pueda realizarse a travs
trav de
internet, empleando protocolos Web estndar ya existentes.
Utilizan la arquitectura
rquitectura Orientada a Servicios (SOA)
Es una aproximacin al diseo de
e aplicaciones complejas basada en:
x La identicacin
cacin de los servicios que ofrecer.
x La denicin
nicin de esos servicios
x La organizacin de las interacciones entre esos servicios
x Importancia de las interfaces
x Descripcin
n de las interfaces
x Tratamiento automtico para generar cdigo de implementacin de las interfaces mediante
clases.
La idea base de cualquier servicio web ser desarrollar el sistema a partir de las interfaces.
interfaces
La informacin de los servicios comprende un esquema basado en soap y un resultado.
Dichaa informacin utiliza el lenguaje XML para expresar los elementos de los que est compuesto el
servicio y los datos que devolver como respuesta a un consumidor de dicho servicio.

Servicios JAX-WS
JAX
API de Java EE para la publicacin y acceso a servicios web basados en WSDL y SOAP.
SOAP
Es la implementacin por defecto que se incluye en Java SE 6
La gestin de los documentos XML incluidos en las peticiones y respuestas SOAP se delegan en JAXB.
JAX-WS
WS define su propio conjunto de anotaciones para definir las clases y mtodos que actan como
puntos finales de los mensajes que conforman las invocaciones SOAP para especificar la definicicin del
fichero WSDL y del binding SOAP.
La implementacin del servicio web puede desplegarse empleando un Servlet como endpoint o un EJB
endpoint.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
En contenedores que soporten Java EE 6 el despliegue es automtico en ambos casos. Al iniciar la
aplicacin el contenedor inspecciona las clases en busca de las anotaciones @WebService y establece
establec
los mapeos de URL pertinentes.
En contenedores que no son Java EE 6, debe configurarse en el descriptor de despliegue de la
aplicacin (WEB-INF/web.xml) y en el servlet de "escucha" del API JAX-WS.
JAX
Definicin de servicios web con JAX-WS
JAX
El nico requisito es contar con un interfaz y/o una clase de implementacin anotado con
@WebService.
En el caso de EJB endpoints,, adems deben de estar anotados como @Stateless (los servicios web son
sin estado).
La clase de implementacin debe ser pblica y no puede ser final ni abstract.
abstract
La clase de implementacin debe contar con un constructor vaco.
vaco
La clase de implementacin no puede definir un mtodo finalize().
finalize()
Debe garantizarse una implementacin sin estado.
estado
La clase de implementacin no puede guardar informacin
info de estado
ado entre llamadas del cliente.
Por defecto, para la clase/interface de implementacin
implement se generar un elemento WSDL service con el
mismo nombre de la clase y el sufijo Service,
Service adems se generar un elemento WSDL portType con el
nombre de la clase.
Para cada mtodo pblico de la clase se generar
gen un elemento WSDL operation con el mismo nombre
del mtodo y dos elementos WSDL message, uno para la peticin (con el nombre del mtodo) y otro
para la respuesta (aadiendo al nombre del mtodo el sufijo respose).
respose)
Los parmetros y valores de devolucin
devoluci deben de ser tipos bsicos Java, clases anotadas con JAXB,
arrays, Map, List o Collection de los anteriores.
anteriores
Tipos de Anotaciones JAX-WS
Anotaciones que definen el mapeo WSDL (modifican el comportamiento por defecto):
x @WebService:
Seala una clase o interfaz como endpoint de un servicio web.
Incluye atributos para modificar el nombre del elemento service, portType, el name space, etc (name,
targetNamespace, serviceName, portName, wsdlLocation, endpointInterface)
x @WebMethod
in de las operaciones WSDL (atributo operationName) o excluir mtodos de
Permite modificar la definicin
la clase que no se desean exponer como operaciones del web service (con el atributo exclude=true).
x @WebResult
Permite controlar el nombre del elemento message de WSDL que contendr el
el valor de retorno (atributo
name).
x @WebParam
Permite configurar los elementos parameter de WSDL vinculados a los parmetros de una operacin
(atributos: name, mode [IN, OU, INOUT], targetNamespace, header, partName)
x @OneWay
o tendr valor de retorno.
Permite indicar que un mtodo no

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Existen tambin anotaciones que definien el binding SOAP de las operaciones y los mtodos:
x @SOAPBinding
Para un mtodo de la clase endpoint especifica el estilo de codificacin de los mensajes (RPC vs.
document) y el tipo de codificacin
ficacin de los parmetros a usar (encoded vs.literal).
Atributos: style, use, parameterStyle.
x @SOAPMessageHandler
Especifica detalles de la gestin de los mensajes (peticin y respuesta).
Atributos: name, className, initParams, roles, heards
Vamos a visualizar
ualizar un ejemplo para la creacin de un servicio web bsico.
Mostraremos una lgica en la que recibiremos una fecha (String) desde el cliente y le enviaremos el da
de la semana a la que corresponde dicha fecha.
Comenzaremos crendonos un nuevo proyecto Web Application.

Lo llamaremos AplicacionWebServices.

Vamos a utilizar el servidor GlassFish, que como hemos ledo en la documentacin, utiliza servicios web
JAX-WS.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
No seleccionaremos ningn framework aadido para la aplicacin.

A continuacin, agregaremos un nuevo objeto sobre el proyecto.


Sobre la carpeta de Web Services, seleccionamos un objeto Web Service.

Lo llamaremos PrimerWebService y lo incluiremos en un paquete llamado paqueteservicios.


Indicaremos la opcin Web Service from Scratch, lo que quiere decir que generaremos el Web Service
en una clase y no en un EJB Stateless.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Como vemos, ya ha incluido la anotacin @WebService indicando el tipo de clase que hemos
generado.
Nos marcar un error debido a que tenemos que incluir un mtodo o varios de operacin para el
servicio.

Podemos incluir operaciones de dos formas diferentes, desde el cdigo pulsando sobre la ayuda de la
izquierda del cdigo o sobre el designer del servicio web.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Vista desde el diseador del servicio (pestaa Design)
Design

Al seleccionar Add Operation, nos mostrar una nueva ventana en la que realizaremos la cabecera del
mtodo web service e incluiremos parmetros si los necesitaramos.
Llamaremos a nuestro mtodo GetDiaNacimiento y le indicaremos que recibir un parmetro
parmetr de la
clase String llamado fecha.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Una vez que pulsamos sobre OK, veremos en el diseador el mtodo de forma grfica.

Y podremos comprobar que hemos aadido un mtodo con anotaciones sobre el servicio en nuestro
cdigo.

Estas son las anotaciones que hemos utilizado para el servicio web:
x @WebService identifica a la clase como un servicio Web.
x Al incluir este descriptor en la clase el editor del netbeans nos avisa que debemos importa la
clase javax.jws.Webservice.
x @WebMethod identifica a una operacin como parte del servicio web.
x Al igual que con WebService se debe importar la clase WebMethod de mismo paquete.
x @WebParam asigna un nombre a los parametros de una operacin.
x Son opcionales pero conviene utilizarlos para que el descriptor de nuestro servicio Web sea
legible para los programadores.
programadores
Implementamos el cdigo del Web Service para devolver el da a partir de una fecha:
package paqueteservicios;
import java.text.DateFormat;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import javax.jws.WebService;

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
import java.util.*;
import javax.jws.WebMethod;
import javax.jws.WebParam;

@WebService()
public class PrimerWebService {

@WebMethod(operationName = "getDiaNacimiento")
public String getDiaNacimiento(@WebParam(name = "fecha")
String fecha) throws ParseException {
Date date;
Calendar calendario = GregorianCalendar.getInstance();
SimpleDateFormat formatoDeFecha = new SimpleDateFormat("dd/MM/yyyy");
SimpleDateFormat("dd/MM/yyyy");
date = formatoDeFecha.parse(fecha);
calendario.setTime(date);
int dia, mes, anyo;
int op1, op2, op3, op4, op5, op6, resultado;
dia = calendario.get(Calendar.DAY_OF_MONTH);
mes = calendario.get(Calendar.MONTH);
mes++;
anyo = calendario.get(Calendar.YEAR);
System.out.println("dia " +dia);
System.out.println("mes " +mes);
System.out.println("ao " +anyo);
if (mes == 1)
{
mes = 13;
anyo -= 1;
}
else if (mes == 2)
{
mes = 14;
anyo -= 1;
}

op1 = ((mes + 1) * 3) / 5;
System.out.println(op1);
op2 = anyo / 4;
System.out.println(op2);
op3 = anyo / 100;
System.out.println(op3);
op4 = anyo / 400;
System.out.println(op4);
op5 = dia + (mes * 2) + anyo + op1 + op2 + op4 + 2 - op3;
System.out.println(op5);
op6 = op5 / 7;
System.out.println(op6);
resultado = op5 - (op6 * 7);
System.out.println(resultado);

String dianacimiento = "";

switch (resultado)

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
{
case 0:
dianacimiento = "sbado";
break;
case 1:
dianacimiento = "domingo";
break;
case 2:
dianacimiento = "lunes";
break;
case 3:
dianacimiento = "martes";
break;
case 4:
dianacimiento = "mircoles";
break;
case 5:
dianacimiento = "jueves";
break;
case 6:
dianacimiento = "viernes";
break;
}
return dianacimiento;
}
}
Ahora veremos que tenemos una carpeta llamada Web Services en nuestro proyecto.
Vamos a probar el servicio para visualizar el formato de la respuesta y la entrada de datos.
Sobre nuestro servicio, seleccionaremos la opcin Test Web Service.

Se nos abrir el explorador mostrandonos la ubicacin


ubicaci web del servicio.
http://localhost:8089/AplicacionWebServices/PrimerWebServiceService?Tester

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ahora ya podemos incluir una fecha con el formato
formato que hemos elegido en el cdigo y ya tenemos el
formato soap del servicio y la respuesta xml.

SOAP Response

<?xml version="1.0" encoding="UTF-8"?>


8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:getDiaNacimientoResponse
cimientoResponse xmlns:ns2="http://paqueteservicios/">
<return>mircoles</return>
</ns2:getDiaNacimientoResponse>
</S:Body>
</S:Envelope>

Y esta es la accin que realizar


el servicio web en el servidor expresada de forma grfica:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ver Video: Servicio Web Tabla de Multiplicar,
Multiplicar
en el Mdulo 7. Unidad 8, en la plataforma elearning

Laboratorio: Servicio Validacin


Objetivos
x Conocer el funcionamiento de los servicios JAVA-WS.
JAVA
x Acceso y consumo de recursos de un servicio web.

Enunciado
En este laboratorio vamos a crearnos un Servicio
S Web que validar, mediante dos mtodos, el cdigo
ISBN y el cdigo EAN a travs JAVA--WS.

Lo primero de todo ser crearnos un nuevo proyecto Web Application.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Lo llamaremos ProyectoValidacion

Utilizaremos
ilizaremos el servidor GlassFish Server.

No agregaremos ningn Framework.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Vamos a agregar un nuevo servicio web.

Lo llamaremos ServicioValidacion

Lo primero que vamos a realizar es una operacin


operacin para validar el cdigo ISBN.
Para validar el cdigo ISBN tenemos que hacer lo siguiente:
EJEMPLO DE ISBN CORRECTO: 8441513929
Debemos descomponer la cadena y multiplicar
multiplica cada nmero por la posicin que ocupa en la cadena
8*1
4*2
4*3
1*4
5*5
9 * 10
Despus, con la suma total de todas estas multiplicaciones
mul se divide el resultado entre 11 y, si el resto es
cero, el nmero ISBN es correcto.
Agregaremos una nueva operacin sobre el Web Service llamada validarNumeroIsbn() que recibir un
String con el nmero ISBN a validar y devolver true o false:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
A continuacin, nuestro servicio contendr otro mtodo para poder validar el cdigo EAN, que es el
formato que se utiliza en los cdigos de barras.
Para validar un cdigo EAN debemos realizar los siguientes pasos:
Por ejemplo, para validar el cdigo EAN8
EAN "12345678" (Obviamente es inventado)
1. Separar el dgito de control. Nos quedamos con "1234567" y "8"
2. Sumar pares: sumapares=2+4+6=12
3. Sumar impares: sumaimpares=1+3+5+7=16
4. Multiplicamos
ultiplicamos los impares por 3.
5. sumaimpares=16*3=48
6. Sumar el resultado de pares e impares: 12+48=60
7. Hallar el resto de la division por 10: 60 mod 10 = 0
8. Hacer 10-resto: 10-0=10
9. Como nos ha salido 10, el dgito de control es 0.
10. Comparar el dgito de control que hemos calculado con el que tena el cdigo: Nos sale 0 y el
cdigo
digo tena un 8. Es incorrecto.
Nos crearemos otra nueva operacin sobre el Servicio que llamaremos validarEan() que recibir un
String con el dato del cdigo y devolver true o false.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ahora debemos implementar la lgica para cada mtodo en el servicio y para la validacin de cada
tipo de cdigo.
Escribiremos el siguiente cdigo en la clase del Web Service:
package paquetews;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
@WebService()
public class ServicioValidacion {

/**
* Web service operation
*/
@WebMethod(operationName = "validarNumeroISBN")
public boolean validarNumeroISBN(@WebParam(name = "isbn")
String isbn) {
if (isbn.length() != 10)
{
return false;
}
else
{
char letra;
int sumanumeros = 0;
for (int i = 0; i < isbn.length(); i++)
{
letra = isbn.charAt(i);
int numero = Integer.parseInt(String.valueOf(letra));
int resultado = numero * (i + 1);
sumanumeros += resultado;
}
if (sumanumeros % 11 == 0)
{
return true;

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
}
}
return false;
}

/**
* Web service operation
*/
@WebMethod(operationName = "validarEan")
public boolean validarEan(@WebParam(name = "ean")
String ean) {
char letra;
char digitocontrol;
digitocontrol = ean.charAt(ean.length()-1);
ean.charAt(ean.length()
int sumapares = 0;
int sumaimpares = 0;
for (int i = 0; i < ean.length()-1;
1; i++)
{
letra = ean.charAt(i);
System.out.println("Letra: " + letra);
int numero = Integer.parseInt(String.valueOf(letra));
if (numero%2==0)
{
sumapares += numero;
}
else
{
sumaimpares += numero;
}
}
sumaimpares = sumaimpares * 3;
int total = sumapares + sumaimpares;
int resto = total%10;
resto = 10 - resto;
if (resto == 10)
{
resto = 0;
}
int dc = Integer.parseInt(String.valueOf(digitocontrol));
if (resto == dc)
{
return true;
}else
{
return false;
}
}
}
Ahora es el momento de probar el servicio:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Veremos la pantalla de presentacin del Web Service:

Podremos visualizar los resultados de las operaciones:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 9: Desarrollando servicios Web cliente

Objetivos
x Conocer los conceptos de los clientes de Servicios Web.
x Aprender a consumir cualquier
lquier tipo de Servicio desde la plataforma Java.
x Creacin de clientes de Servicios Web SOAP y Servicios REST.

Introduccin
Dentro de toda la tecnologa de Web Services, sin ninguna duda, la parte ms importante es el
consumo de dicho servicio. Por muy bien
bien que hagamos una aplicacin, si no tenemos a nadie que sea
capaz de consumirla, no servira de nada.
Aqu es dnde entra el papel de los clientes de los Servicios Web. El consumo de los servicios web es
una tarea muy sencilla si se tienen editores tales
tales como NetBeans o Eclipse, ya que nos ofrecen
funcionalidad y herramientas grficas para poder obtener acceso a cualquier tipo de Web Service.
Tenemos que saber que no todos los Servicios Web son iguales, por lo que tampoco su consumo es el
mismo.
Depender
del tipo de servicio expuesto, que su consumo se realice de una forma determinada.
Java utiliza los servicios JAVA-WS
WS por defecto, su consumo es particularmente fcil, debido a que utiliza
el protocolo SOAP.
Como hemos aprendido, los servicios web basados en SOAP, indican al cliente mediante el fichero
WSDL cuales son sus mtodos y caractersticas, por lo que un Web Service SOAP escrito en Visual Studio
.Net ser consumido exactamente igual que un Web Service SOAP escrito en Java.
Pero existen otro tipo de Web Services que estn apareciendo ahora y cuyo consumo es diferente,
debido a que utilizan el protocolo HTTP para su comunicacin. Son los Servicios Web RestFul.

Web Services REST


Los
os servicios web RESTful han venido a simplificar el desarrollo de
de servicios web y a implementar un nuevo
modelo de interaccion con servicios web.
La Transferencia de Estado Representacional (Representational State Transfer) o REST describe una
interfaz web simple utilizando peticiones HTTP y datos XML,
XML pero sin capas adicionales
a como SOAP,
frecuentemente usadas en los servicios web.
web
Los servicios web RESTful se basan en la simplicidad de su uso debido a que estos son accesibles via
protocolo HTTP a diferencia de los servicios web basados en SOAP en donde existe un nivel de
abstraccion adicional, lo que significa que podremos consumir un servicio web con un simple formulario
html, siempre y cuando sigamos el modelo de trabajo de RESTful donde, mediante las llamadas HTTP a
sus metodos podemos acceder a los recursos de un web service, como por ejemplo hacer una solicitud
HTTP via POST a un recurso, lo cual es totalmente distinto a hacer una solicitud HTTP via DELETE a otro
metodo del mismo recurso.
La Transferencia de Estado Representacional (REST - Representational State Transfer)
T fue ganando
amplia adopcin en toda la web como una alternativa ms simple a SOAP y a los servicios web
basados en el Lenguage de Descripcin de Servicios Web (Web Services Descripcion Language - WSDL).

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Grandes
randes proveedores de Web 2.0 estn migrando
migran a esta tcnologa,
ga, incluyendo a Yahoo, Google,
Facebook, Flickr, quienes han marcado
marca como obsoletos a sus servicios SOAP y WSDL y han pasado a
utilizar un modelo ms facil de usar, orientado a los recursos.
REST define un set de principios arquitectnicos
arquitectnicos por los cuales se disean servicios web haciendo foco
en los recursos del sistema, incluyendo cmo se accede al estado de dichos recursos y cmo se
transfieren por HTTP hacia clientes escritos en diversos lenguajes.
REST ha crecido en los ltimos aos como el modelo predominante para el diseo de servicios.
De hecho, REST ha logrado un impacto tan grande en la web que prcticamente ha logrado desplazar
a SOAP y las interfaces basadas en WSDL por tener un estilo bastante ms simple de utilizar.
Los 4 principios de REST
Una implementacin concreta de un servicio web REST sigue cuatro principios de diseo fundamentales:
x Utiliza
tiliza los mtodos HTTP de manera explcita
x No mantiene estado
x Expone
xpone URIs con forma de directorios
x Transfiere XML, JavaScript Object Notation (JSON), o ambos

A continuacin vamos a ver en detalle estos cuatro principios, y explicaremos porqu son importantes a
la hora de disear un servicio web REST.
REST utiliza los mtodos HTTP de manera explcita
Una de las caratersticas
sticas claves de los servicios web REST es el uso explcito de los mtodos HTTP,
siguiendo el protocolo definido por RFC 2616.
Por ejemplo, HTTP GET se define como un mtodo productor de datos, cuyo uso est pensado para que
las aplicaciones cliente obtengan
ngan recursos, busquen datos de un servidor web, o ejecuten una consulta
esperando que el servidor web la realice y devuelva un conjunto de recursos.
REST hace que los desarrolladores usen los mtodos HTTP explcitamente de manera que resulte
consistente con
on la definicin del protocolo.
Este principio de diseo bsico establece una asociacin uno-a-uno
uno uno entre las operaciones de crear,
leer, actualizar y borrar y los mtodos HTTP.
De acuerdo a esta asociacin,, podemos exponer los mtodos del Servicio de cuatro
cua formas diferentes:
x POST para crear un recurso en el servidor
x GET para obtener un recurso
x PUT para cambiar el estado de un recurso o actualizarlo
x DELETE para eliminar
minar un recurso
Un fallo de diseo que tienen muchas APIs web es el uso de mtodos HTTP para otros propsitos.
Por ejemplo, la peticin del URI en un pedido HTTP GET, en general,
general identifica a un recurso especfico. O
el string de consulta en el URI incluye un conjunto de parmetros
parmetros que definen el criterio de bsqueda
que usar el servidor para encontrar un conjunto de recursos.
Pero hay muchos casos de APIs web poco elegantes que utilizan el mtodo HTTP GET para ejecutar
algo transaccional en el servidor; por ejemplo, agregar registros a una base de datos.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
En estos casos, no se utiliza adecuadamente el URI de la peticin HTTP, o al menos no se usa "en
" la forma
REST".
REST no mantiene estado
Los servicios web REST necesitan escalar para poder satisfacer una demanda
demanda en constante
consta crecimiento.
Se usan clusters de servidores con balanceadores de carga y alta disponibilidad, proxies, y gateways de
manera de conformar una topologa serviciable, que permita transferir peticiones de un equipo a otro
para disminuir el tiempo total de respuesta de una invocacin al servicio web.
El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de
servicios web REST envien peticiones
ones completas e independientes, es decir, se deben enviar peticiones
que incluyan todos los datos necesarios para cumplir el pedido, de manera que los componentes en los
servidores intermedios puedan redireccionar y gestionar la carga sin mantener el estado localmente
entre las peticiones.
Una peticin completa e independiente hace que el servidor no tenga que recuperar ninguna
informacin de contexto o estado al procesar la peticin.
Una aplicacin o cliente de servicio web REST debe incluir dentro del encabezado y del cuerpo HTTP de
la peticin todos los parmetros, contexto y datos
datos que necesita el servidor para generar la respuesta.
De esta forma, al no mantener el estado,
estado mejora el rendimiento de los servicios web y simplifica el diseo
e implementacin de los componentes del servidor, ya que la falta en el estado del servidor elimina la
necesidad de sincronizar los datos de la sesin con una aplicacin externa.

REST expone URIs con forma de directorios


Desde el punto de vista del cliente de la aplicacin que accede a un recurso, la URI determina lo
intuitivo que va a ser el web service REST, y si el servicio va a ser utilizado tal como fue pensado en el
momento de disearlo.
La tercera caracterstica de los servicios web REST es justamente sobre las URIs.
Las URI de los servicios web REST deben ser intuitivas, hasta
hasta el punto de que sea facil adivinarlas.
Pensemos en las URI como una interfaz auto-documentada
auto documentada que necesita de muy poca o ninguna
explicacin o referencia para que un desarrollador pueda comprender a lo que apunta, y a los recursos
derivados relacionados.
Una forma de lograr este nivel de usabilidad es definir URIs con una estructura al estilo de los directorios.
Este tipo de URIs es jerrquica, con una nica ruta raiz, y va abriendo ramas a travs de las subrutas para
exponer las reas principales dell servicio.
De acuerdo a esta definicin, una URI no es slamente una cadena de caracteres delimitada por
barras, sino ms bien un rbol con subordinados y padres organizados como nodos.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Por ejemplo, en un servicio de biblioteca de libros que contiene diversos
versos libros,
libros se podra definir una
estructura de URIs como esta:
http://www.midireccion.es/biblioteca/libros/{libro}
REST transfiere XML, JSON, o ambos
La representacin de un recurso, en general,
general refleja el estado actual del mismo y sus atributos en el
momento en que el cliente de la aplicacin realiza la peticin.
La representacin del recurso son simples "instantaneas"
" en el tiempo. Esto podra ser una
representacin de un registro de la base de datos que consiste en la asociacin entre columnas y tags
XML, donde los valores de los elementos en el XML contienen los valores de las filas. O partiendo de la
misma base, si el sistema tiene
ene un modelo de datos, la representacin de un recurso es una fotografa
de los atributos de una de las cosas en el modelo de datos del sistema. Estoss son los elementos que son
ofrecidos con los servicios web REST.
La ltima restriccin en el momento de disear un servicio web REST tiene que ver con el formato de los
datos que la aplicacin y el servicio intercambian en las peticiones/respuestas.
Los objetos del modelo de datos, generalmente,
generalmente se relacionan de alguna forma,
forma y las relaciones entre
los objetos
etos del modelo de datos (los recursos) deben reflejarse en la forma en la que se representan en
el momento de transferir los datos al cliente.
Por ltimo, es bueno construir los servicios de manera que usen el atributo HTTP Accept del encabezado,
en donde e el valor de este campo es del tipo MIME.
De esta manera, los clientes pueden pedir por un contenido en particular que pueden analizar de una
forma ms ptima.
Algunos de los tipos MIME ms usados para los servicios web REST son:

Esto permite que el servicio sea utilizado por distintos clientes escritos en diferentes lenguajes, corriendo
en diversas plataformas y dispositivos.
El uso de los tipos MIME
ME y del encabezado HTTP Accept es un mecanismo conocido como negociacin
de contenido,
ido, el cual le permite a los clientes elegir qu formato de datos pueden leer y, minimiza el
acoplamiento de datos entre el servicio y las aplicaciones que lo consumen.
Debido a su simplicidad de uso, es facil consumir estos servicios web desde otros lenguajes
leng que ofrezcan
funcionalidad para realizar solicitudes HTTP, como PHP con su libreria CURL, JAVA con su librera de
clases para ejecutar solicitudes HTTP.
Sin embargo, los desarrolladores de Jersey (que han impulsado el trabajo en la tecnologa de servicios
serv
web RESTful) han desarrollado una API mediante la cual nos facilitan el consumo de servicios web RESTful
ya que proveen funcionalidad para setear los parmetros que se le mandan en una llamada y procesar
en automatico el resultado si conocemos el tipo
tip de retorno.
Es importante reconocer que muchas empresas han implementado plataformas de web services
basadas en RESTful, taless como el servicio S3 de amazon o Google Maps.
Vamos a crearnos un Servicio Web que utiliza la tecnologa RestFul en Java.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Nos creamos
reamos un nuevo proyecto Web.

Lo llamaremos ServicioWebRestFul

No utilizaremos ningn Framework y utilizaremos el servidor Glasshfish.


Nos crearemos un Servicio Web que expondr los Empleados de nuestra base de datos en diferentes
direcciones Web via http.
Para poder realizar la accin lo haremos mediante Unidades de Persistencia que se comunicarn con la
base de datos Oracle y que nos devolver los registros.
Debemos crearnos una nueva unidad de persistencia:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Debemos crearnos una nueva fuente de datos
dato para conectarnos a Oracle

En la siguiente pantalla, debemos utilizar un nuevo proveedor Oracle que es el proporcionado en la


documentacin.
Para ello, seleccionaremos de la lista desplegable la opcin Nuevo Controlador

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Configuramos las propiedades de la conexin para poder comunicarnos con Oracle

Nos mostrar el esquema que deseamos visualizar (SYSTEM) y pulsamos en Aceptar, nos habr creado la
conexin correctamente.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Es importante seleccionar la opcin de Ninguno en la generacin de las tablas, debido a que sino, los
datos los perderamos, ya que nuestra unidad de persistencia puede crear objetos adems de
recuperarlos.
Ya nos habr creado la Unidad de persistencia:

Es el momento de crearnos un Servicio Web RestFul utilizando la unidad de persistencia y la base de datos
Oracle.

Ahora nos pedir la tabla o tablas que deseamos utilizar para nuestro Servicio Web. Seleccionamos la
tabla EMP.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Dejamos los parmetros de recursos y conversiones con los nombres de los paquetes originales
origi que nos
ofrece NetBeans.

Nos crear unos paquetes de la siguiente forma:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ahora es el momento de probar nuestro Servicio Web, para ello, pulsaremos sobre el proyecto y
seleccionaremos la opcin Test RESTful Web Services.

Veremos la pantalla para testear el Web Service Restful, en la zona de la izquierda podremos visualizar todos los
datos de empleados o hacer consultas para un empleado en concreto, depende de nuestra solicitud.

Podremos realizar consultar y visualizar que los datos nos son devueltos
devueltos correctamente.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Tambin nos puede devolver los datos en formato JSON y con una URL en la que podremos acceder a
todos los registros a travs del protocolo Http, que es el protocolo que utilizan los servicios Web Restful.

Si seleccionamos cualquier direccin Web, veremos el registro ofrecido correctamente mediante un


localhost.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Consumir Servicio Web RestFul
Crear un servicio Web RestFul no sirve de nada si no somos capaces de aprender a consumirlo.
Un servicio web Restful se consume de forma
forma diferente a un servicio web convencional, debido a que su
protocolo no es SOAP, es HTTP.
Con NetBeans ms el complemento Jersey, se nos hace muy fcil consumir servicios REST.
Para integrarlo con el IDE, necesitamos registrar el fichero WADL.
El fichero
chero WADL es la base de los Web Services REST, as como el fichero WSDL es la base del protocolo
SOAP.
La URL para el acceso al WADL la podemos obtener as:
http://host:puerto/contexto-web/resources/application.wadl
web/resources/application.wadl
El fichero WADL es el homnimo de WSDL en Servicios Web RestFul.
Vamos a consumir un Servicio Web simple que nos devolver el valor factorial de un nmero que nos
enviarn via HTTP.
Lo primero ser crearnos un nuevo proyecto Java Web Web Application y lo llamaremos
ServicioFactorial.
Utilizaremos
remos el Servidor GlasshFish Server 3 y no utilizaremos ningn Framework.
Ahora nos agregaremos una clase Java que llamaremos FactorialResource.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Crearemos un mtodo para calcular el factorial de un nmero en nuestra clase:
public class FactorialResource {
public long factorial(long base) {
if (base >= 1) {
return factorial(base - 1) * base;
}
return 1;
}
}
Cada vez que agreguemos una anotacin o un elemento sobre la clase que vamos a exponer en el
servicio web, debemos pulsar sobre el proyecto y seleccionar la opcin Limpiar y Generar.
Generar
Agregaremos la notacin @Stateless al inicio de la clase. Esto convierte
te automticamente a nuestra
clase en un EJB.. El espacio de nombre que debemos importar es javax.ejb.Stateless.

A continuacin de la anterior anotacin, aadiremos la


a anotacin @Path("/factorial") del espacio de
nombres javax.ws.rs.Path.
Esto indica que este recurso ser accesible desde la ruta "/factorial" via web.
En el momento en el que seleccionemos Limpiar y Construir sobre el proyecto,
proyecto, NetBeans detectar que
se ha creado un recurso REST, entonces pedir activar esta caracterstica en la aplicacin,
aplicacin por lo que
debemos pulsar sobre Aceptar.

La clase que ya hemos creado es un recurso REST.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ahora ser el momento de incluir mtodos en nuestro servicio RestFul.
Solo podremos
emos crear un mtodo de tipo GET, POST, PUT y DELETE. Como
omo el mtodo factorial nos
n deber
un nico valor segn el parmetro que le especificamos, usaremos el tipo GET.
Para ello agregamos la anotacin @GET antes del mtodo factorial en la clase del espacio de nombres
javax.ws.rs.GET.
Y con esto, nuestro recurso REST ya tiene un mtodo.
mtodo

Los
os valores que se reciben desde el recurso REST deben ser objetos. Por lo tanto, nuestro mtodo debe
cambiar para que no devuelva un dato long, sino un java.lang.String.
Adems, debemos indicar que el parmetro base del mtodo Java factorial ser recibido via URL con
el nombre base. Es decir, se llamar a la direccin URL de la siguiente forma:
..../resources/factorial?base=5
Para ello usaremos la notacin @QueryParam del espacio de nombres javax.ws.rs.QueryParam,
javax.ws.rs.QueryParam antes de
la declaracin del parmetro.
La clase, finalmente, quedar con el siguiente cdigo:
package paqueteservicio;
import javax.ejb.Stateless;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.QueryParam;
@Stateless
@Path("/factorial")
public class FactorialResource {
@GET
public String factorial(@QueryParam("base") long base) {

return Long.toString($factorial(base));
}

long $factorial(long base) {


if (base >= 1) {
return $factorial(base - 1) * base;

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
}
return 1;
}
}
Una vez que tenemos el proyecto listo, debemos pulsar sobre el proyecto y seleccionar Deploy.
Ahora, para acceder a nuestro proyecto como clientes y probar su funcionalidad, bastar con mostrar
la URL de acceso a nuestro Servicio RestFul.
http://localhost:8080/ServicioFactorial/resources/factorial?base=5
localhost:8080/ServicioFactorial/resources/factorial?base=5
Como podremos comprobar, se ha creado el Servicio via HTTP y el acceso nos devuelve el resultado en
la pgina:

Como nuestro recurso es va http, tambin podemos acceder mediante cualquier cliente
client HTML, por
ejemplo una pgina JSP.
Escribiremos el siguiente cdigo en la pgina index.jsp del proyecto:
<body>
<h1>Llamada factorial REST</h1>
<form action="resources/factorial">
Introduzca el nmero: <input name="base" type="text"
ty />
<input type="submit" value="Mostrar Factorial"/>
</form>
</body>
El resultado ser la llamada a nuestro servicio Rest y realizar la operacin segn nuestro cdigo.
Otra forma de acceso sera mediante el fichero WADL. Para recuperar dicho fichero, debemos pulsar
sobre el proyecto y seleccionar Test RESTful WebService.
WebService
Veremos una pgina dnde podremos probar el servicio y su resultado:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Hemos visto que podemos consumir el Servicio desde cualquier lenguaje que sea capaz de soportar
HTML y protocolo HTTP, por lo que el consumo de Servicios Rest son una alternativa que se est
extendiendo muy rpidamente por Internet.
Para consumir el Servicio RestFul desde cualquier
cualquier aplicacin de Java, debemos utilizar el archivo WADL.
Dicho fichero se genera en el momento de probar el servicio.

http://localhost:8080/ServicioFactorial/resources/application.wadl
Lo primero que tenemos que realizar para consumirlo, es registrar el servicio en el IDE de NetBeans.
Para ello, debemos ir a la ventana Prestaciones y aadir el Servicio Web.

Indicaremos la ruta al fichero WADL del servicio REST:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Ya tendremos el servicio registrado en nuestro IDE de NetBeans.

Para consumir el servicio,, vamos a hacerlo desde un Cliente en lnea de comandos. Nos crearemos un
nuevo proyecto Java Java Application llamado ClienteRestFul.
Ahora nos crearemos una clase que ser el cliente del servicio, para ello, agregamos sobre el proyecto
un nuevo elemento
to y, en la pestaa Web Services, seleccionamos la opcin RESTFul Java Client.

Como hemos registrado nuestro servicio en el IDE de NetBeans, seleccionaremos la opcin IDE
Registered y en Browse marcaremos nuestro Servicio.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Llamaremos a nuestra clase ClienteFactorial.

Nos habr creado la clase para acceder a los datos del Servicio RestFul.
Para probar su funcionalidad y acceso, nos crearemos una clase llamada ConsumoFactorial dentro del
mismo paquete del Cliente, y escribiremos el siguiente cdigo:
package clienterestful;
public class ConsumoFactorial {
public static void main(String[] args) {
ClienteRest c = new ClienteRest();
long base = 5;
String resultado = c.factorial(String.class, String.valueOf(base));
System.out.println("Resultado del factorial de 5: " + resultado);
}
}

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Como podremos comprobar, el resultado es correcto y consumimos el servicio REST desde un cliente:

Consumir Servicio Web SOAP


Para consumir un Servicio Web con protocolo SOAP es muy simple si se tiene un editor grfico estilo
NetBeans o Eclipse.
Para ello, lo primero ser localizar la direccin dnde est alojado el Servicio Web que deseamos
consumir.
Vamos a mostrar un ejemplo de consumo de Web Services basados en SOAP.
Podemos encontrar
ntrar multitud de Web Services en la siguiente direccin:
http://www.xmethods.net
Vamos a consumir el siguiente Servicio Web:
http://footballpool.dataaccess.eu/data/info.wso?WSDL
Debemos crearnos un proyecto que haga de cliente. Para ello, nos crearemos un nuevo proyecto Java
Application llamado ClienteSOAP.

Sobre el proyecto aadiremos un nuevo elemento Web Service Client.

Debemos indicar la direccin a nuestro servicio web:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Nos mostrar un listado con todos los mtodos disponibles para acceder al servicio.
Ahora bastar con dirigirnos a la clase Main.java y arrastar el mtodo que deseemos probar del Web
Service.

Nos crear un mtodo para poder consumir el Servicio.


Bastar con realizar la llamada desde el mtodo main al mtodo del Web Service y mostrar los
resultados.
package clientesoap;
import eu.dataaccess.footballpool.ArrayOfString;
import java.util.*;
public class Main {
public static void main(String[] args) {
ArrayOfString jugadores = allMidFields("Spain");
List<String>
> datos = jugadores.getString();
for (String s:datos)
{
System.out.println("Mediocentros: " + s);
}
}

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
private static ArrayOfString allMidFields(java.lang.String sCountryName) {
eu.dataaccess.footballpool.Info
.Info service = new eu.dataaccess.footballpool.Info();
eu.dataaccess.footballpool.InfoSoapType port = service.getInfoSoap();
return port.allMidFields(sCountryName);
}
}
Y el resultado ser el siguiente:

Ver Video: Creacion de un cliente


cliente para consumir servicios web,
web
en el Mdulo 7. Unidad 9, en la plataforma elearning

Laboratorio: Cliente Servicio Web Mundial

Objetivos
x Conocer el funcionamiento de acceso a clientes web utilizando la tecnologa JAVA-WS.
JAVA
x Acceso y consumo de recursos de un servicio web.

Enunciado
Para nuestra prctica vamos a utilizar un servicio web ya creado y gratuito que contiene informacin y
datos sobre el mundial 2010.
http://footballpool.dataaccess.eu/data/info.wso?WSDL
ccess.eu/data/info.wso?WSDL

Lo primero de todo ser crearnos un nuevo proyecto Web Application.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Lo llamaremos ConsumoServicioWeb

Utilizaremos el servidor GlassFish Server.

No agregaremos ningn Framework.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Vamos a agregar un cliente de servicio web. Para ello, seleccionamos sobre nuestro proyecto New
Other

Y en la carpeta Web Services, marcamos Web Service Client

Marcamos la opcin WSDL y escribimos la direccin


direccin al servicio web del mundial 2010.
El estilo del cliente ser utilizando la tecnologa JAVA-WS
JAVA

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Veremos que nos ha creado una carpeta llamada Web Service Reference en la que tenemos la
informacin
n de todos los mtodos que ofrece el servicio web.

Ahora vamos a crearnos una nueva clase para consumir los datos del
d servicio.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
La llamaremos BeanWebService.

Sobre nuestra clase, bastar con arrastrar el mtodo


mtodo que necesitemos para poder realizar la llamada al
servicio. Hemos seleccionado el mtodo AllGoalKeepers.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Si nos fijamos en la estructura, ya nos ha generado
generado la llamada al servicio y los import necesarios.
Adems, pod.0
emos comprobar que nos pide un String para poder invocar al mtodo. Tambin podemos comprobar
que devuelve un objeto del tipo ArrayOfString.
import eu.dataaccess.footballpool.ArrayOfString;
eu.dataaccess.footballpool.ArrayOfStr
import eu.dataaccess.footballpool.ArrayOftTeamInfo;
private static ArrayOfString allGoalKeepers(java.lang.String sCountryName)
{
eu.dataaccess.footballpool.Info service = new eu.dataaccess.footballpool.Info();
eu.dataaccess.footballpool.InfoSoapType
llpool.InfoSoapType port = service.getInfoSoap();
return port.allGoalKeepers(sCountryName);
}
Vamos a implementar el mtodo para visualizar todos
todos los porteros de un equipo. En nuestro ejemplo
utilizaremos Spain.
package paquetebeans;
import eu.dataaccess.footballpool.ArrayOfString;
import eu.dataaccess.footballpool.ArrayOftTeamInfo;
import java.util.List;
public class BeanWebService
{

private static ArrayOfString allGoalKeepers(java.lang.String sCountryName)


{
eu.dataaccess.footballpool.Info service = new eu.dataaccess.footballpool.Info();
eu.dataaccess.footballpool.InfoSoapType port = service.getInfoSoap();
return port.allGoalKeepers(sCountryName);
}

public void miMetodo()


{
ArrayOfString porteros = allGoalKeepers("spain");
List<String> datos = porteros.getString();
for (int i=0;i<datos.size();i++)
{
System.out.println(datos.get(i));
}
}
}
Si ejecutamos nuestra clase,, podremos comprobar que muestra los nombres de los porteros de la
seleccin Spain.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Laboratorio: Servicio RestFul Google Maps
Objetivo
Visualizar el funcionamiento de los Servicios Web REST y su consumo.

Enunciado
Realizaremos una aplicacin que nos mostrar unas direcciones mediante los Servicios Web de Google
Maps.
Lo que haremos ser un Web Service escalar, es decir, nosotros expondremos direcciones desde una
tabla a travs de un Web Service REST propio y mostraremos informacin en ese servicio mediante
med
Google Maps.
Lo primero que debemos hacer es crearnos la tabla ESTADIOS en Oracle mediante el siguiente script:
CREATE TABLE ESTADIOS
(ESTADIO_COD INT
, NOMBRE VARCHAR2(40)
, DIRECCION VARCHAR2(150)
, CONSTRUCCION INT
, AFORO INT);
INSERT INTO ESTADIOS VALUES
(1,'SANTIAGO BERNABEU'
,'Avenida de Concha Espina, 1 28036 Madrid'
,1947, 85000);
INSERT INTO ESTADIOS VALUES
(2,'MESTALLA'
, 'Av de Suecia, 46010 Valencia, Comunidad Valenciana'
,1923, 53000);
INSERT INTO ESTADIOS VALUES
(3,'MARTINEZ VALERO'
, 'MANUEL MARTNEZ VALERO, 3 03208 ELCHE'
,1976, 39000);
INSERT INTO ESTADIOS VALUES
(4,'ALFONSO PEREZ'
, 'Avenida Teresa de Calcuta, S/N, 28903 Getafe'
,1998, 14400);

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
COMMIT;
ALTER TABLE ESTADIOS
ADD CONSTRAINT PK_ESTADIOS
PRIMARY KEY (ESTADIO_COD);

SELECT * FROM ESTADIOS


Creamos un nuevo proyecto Web

Llamaremos al proyecto ProyectoGoogleMaps y utilizaremos el servidor de aplicaciones GlasshFish.

Tenemos que crearnos una nueva unidad de persistencia para recuperar la tabla de estadios de Oracle
mediante Entidades.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Nos conectamos con Oracle como hemos visto en la documentacin.

Marcamos la opcin de Ninguno para que no nos genere las tablas de nuevo.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Y ya tendremos la unidad de persistencia para conectarnos a nuestra tabla Estadios.

Ahora nos creamos un nuevo Servicio Web RestFul from Database

Seleccionaremos la tabla Estadios

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Incluimos la tabla en un paquete nuevo.

Nos dir si deseamos crear los paquetes para los recursos, dejamos todo como est por defecto.

Ahora ya podremos probar nuestro servicio y visualizar los datos de los estadios. Sobre el proyecto,
seleccionamos Test RESTful Web Services.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Veremos la pgina de presentacin y podr hacer consultas pulsando sobre Test.

Ahora vamos a integrar la funcionalidad del servicio Web Google Maps RestFul dentro de nuestro
Servicio de estadios para que nos aparezca el mapa de dnde estn ubicados cada uno de los
Estadios.
Lo primero que debemos hacer es conseguir la API KEY de Google para poder realizar la prctica.
Debemoss ir a esta direccin, validarnos con una cuenta de GMail y registrar la direccin de nuestro
Servicio, por ejemplo: http://localhost:8082
http://code.google.com/intl/es-ES/apis/maps/signup.html
ES/apis/maps/signup.html
Una vez que tenemos la API KEY, volvemos al IDE de NetBeans.
Debemos abrir la clase EstadiosResource del paquete service:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Y agregaremos un mtodo nuevo para realizar las bsquedas:
@GET
@Produces(value="text/html")
public String getGoogleMap(){

return "";
}
En nuestro IDE, presionemos
emos Ctrl+5 para ver el panel de servicios.
Abriremos el nodo Web Services, luego Google, despus Map Service:
Service

Arrastremos el nodo getGoogleMap y soltmoslo en el mtodo que acabamos de crear, justo


j antes del
return "".

El IDE nos mostrar una ventana con datos con ejemplo para ser utilizado en nuestra aplicacin.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
El IDE nos crear un cdigo de ejemplo automtico para probar la funcionalidad.
@GET
@Produces(value = "text/html")
public String getGoogleMap() {
try {
String address = "16 Network Circle, Menlo Park";
java.lang.Integer zoom = 15;
String iframe = "false";
RestResponse result = GoogleMapService.getGoogleMap(address, zoom, iframe);
//TODO - Uncomment nt the print Statement below to print result.
//System.out.println("The SaasService returned: "+result.getDataAsString());
} catch (Exception ex) {
ex.printStackTrace();
}
return "";
}
El IDE tambin ha creado
reado los paquetes org.netbeans.saas y org.netbeans.saas.google que contienen las
siguientes clases y recursos:
x RestConnection - Una clase que envuelve a HttpUrlConnection
x RestResponse - Un clase que envuelve las respuestas HTTP
x googlemapservice.properties - Un archivo de propiedades que almacenar la clave para
manejar el GoogleMap
x GoogleMapService - Un servicio que envuelve los mtodos que usa RestConnection y llama al
servicio GoogleMap.

En el bloque try de getGoogleMap() reemplacemos las lneas comentadas


comentadas con lo siguiente:
return result.getDataAsString();
Abrimos el archivo googlemapservice.properties y pegamos la clave del API que hemos recuperado al
validarnos en la pgina de Google.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Escribimos la clave que nos han proporcionado.

Todava no hemos incluido las direcciones de nuestra tabla, pero vamos a comprobar que todo est
correcto y que nos muestra la direccin de prueba que nos ha proporcionado Google Maps.
Volvemos a probar los Servicios Test RESTful.
Cuando haya cargado la pgina, pulsamos sobre el enlace Estadios del lado izquierdo.
Luego hacemos clic en el botn "Test".

Se mostrar la tabla de los Estadios con sus respectivas direcciones URI que se han creado.
Desde esta tabla de resultados, hagamos clic justo donde dice /estadioss/1/.

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Se abrir una pgina para probar el resultado de este cliente.
Seleccionamos de la lista desplegable MIME la opcin text/html.
Y le damos clic en Test.

El GoogleMap se mostrar en la calle que le indicamos.

Ahora es el momento de recuperar los


los datos y enviar la direccin de cada uno de los estadios a nuestro
Servicio Web RestFul.
Para ello, debemos modificar el mtodo getGoogleMaps()
() de la siguiente forma, dnde recuperaremos
la direccin del estadio que hayamos seleccionado.
@GET
@Produces(value = "text/html")
public String getGoogleMap() {
try {

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.
Estadios c = getEntity();
String direccion = c.getDireccion();
java.lang.Integer zoom = 15;
String iframe = "false";
RestResponse result = GoogleMapService.getGoogleMap(direccion, zoom, iframe);
return result.getDataAsString();
} catch (Exception ex) {
ex.printStackTrace();
}finally{
PersistenceService.getInstance().close();
stance().close();
}
return "";
}
Ahora volvemos a probar el Servicio RestFul y comprobaremos que nos muestra el mapa
correspondiente a cada Estadio que hayamos seleccionado:

www.ceticsa.com
Para uso exclusivo de los alumnos de CETICSA S.L.