ÍNDICE

INTRODUCCIÓN 3
OBJETIVO GENERAL 4
OBJETIVO ESPECIFICO 4

UNIDAD 4: SERVICIOS WEB CON SOAP 5

4.1. SOAP 5
4.2. Creación de servicios web 6
4.3. SOAP para e-bussiness 7
4.4. WSDL Y JAVA 8
4.5. UDDI 5
4.6. FRAMEWORK CFX 6
4.7. Servicios web XML avanzados 7
4.8. Seguridad WS 8

CONCLUSIÓN 9
BIBLIOGRAFIA 10
 INTRODUCCIÓN

Vamos a crear nuestros propios Servicios Web, que ofrecerán una serie de métodos
a los que se podrá llamar mediante RPC desde cualquier lugar de Internet mediante
protocolos estándar (mensajes SOAP).

Deberemos por lo tanto ser capaces de interpretar en nuestras aplicaciones los

mensajes SOAP entrantes de petición para la invocación de un método.
Posteriormente, invocaremos el método solicitado, y con el resultado que nos
devuelva deberemos construir un mensaje SOAP de respuesta y devolvérselo al
cliente.

Si tuviésemos que introducir nosotros el código para interpretar este mensaje de

entrada, y generar manualmente el mensaje de respuesta, el desarrollo de Servicios
Web sería una tarea altamente costosa.

Es más, si se forzase al programador a componer el mensaje SOAP manualmente

cada vez que desarrolle un Servicio Web, es muy probable que cometa algún error
y no respete exactamente el estándar SOAP. Esto sería un grave problema para la
interoperabilidad de los Servicios Web, que es una de las características que
perseguimos con esta tecnología.

Para evitar estos problemas, utilizaremos librerías que nos permitan leer o generar
mensajes SOAP para la invocación de métodos remotos, como es el caso de la API
JAX-WS.

Además, para facilitar aún más la tarea de desarrollar Servicios Web, normalmente
contaremos con herramientas que a partir de las clases que implementan nuestro
servicio generen automáticamente todo el código necesario para leer el mensaje
SOAP de entrada, invocar el método, escribir el mensaje SOAP de salida, y
devolverlo al cliente.

Por lo tanto, nosotros deberemos centrarnos únicamente en la tarea de programar

la funcionalidad que implementan nuestros servicios, olvidándonos del mecanismo
de invocación de éstos.

JAX-WS es una especificación estándar de Sun Microsystems, pero no todos los

servidores de aplicaciones utilizan esta librería para gestionar los Servicios Web.
Por ejemplo, es el caso de Weblogic, que aunque está basado en JAX-WS,
mantiene algunas extensiones propietarias sobre dicha API. Nos centraremos por
lo tanto en el desarrollo de servicios con Netbeans y Glassfish, que incorpora las
últimas versiones de las librerías estándar.
 OBJETIVO GENERAL

Mostrar en una guía de estudio todo lo aprendido en la unidad 4 de la materia de

Servicios Web.

OBJETIVOS ESPECIFICOS

 Presentar conceptos claros y concisos de cada subtema.

 Exponer la aplicación que se puede tener de cada uno de ellos.
 Resumir una unidad en un documento, para el análisis de estos datos.
 4.1 SOAP:
4.1 SOAP: Protocolo
Protocolo simple
simple de
de acceso
acceso aa objetos
objetos

Son las siglas de Simple Object Access
Protocol. Con este protocolo se pedían realizar
RPC o remote procedure calls, es decir,
podíamos bien en cliente o servidor realizar
peticiones mediante http a un servidor web.
 No está asociado con ningún lenguaje:
los desarrolladores involucrados en nuevos
proyectos pueden elegir desarrollar con el
ultimo y mejor lenguaje de programación
que exista.
 No se encuentra fuertemente asociado a
ningún protocolo de transporte: La
especificación de SOAP no describe como
se deberían asociar los mensajes de SOAP
con HTTP.
 No está atado a ninguna infraestructura
de objeto distribuido La mayoría de los
sistemas de objetos distribuidos se pueden
extender, y ya lo están alguno de ellos para
que admitan SOAP.
 Aprovecha los estándares existentes en
la industria: Los principales contribuyentes
a la especificación SOAP evitaron,
intencionadamente, reinventar las cosas.
1. Las aplicaciones deben ser independientes
del lenguaje de desarrollo, por lo que las
aplicaciones cliente y servidor pueden estar
escritas con HTML, DHTML, Java, Visual
Basic u otras herramientas y lenguajes
disponibles.
2. Las peticiones con el uso del protocolo
HTTP emplean el comando POST para
transmitir información entre el cliente y el
servidor.
3. Los procedimientos de llamadas remotas
pueden ser modelados en la forma de varios
mensajes SOAP interactuando entre sí.
 envelope (envoltura): Es el elemento raíz
del mensaje para describir su contenido y la
forma de procesarlo.
 header (encabezado): Es la información de
identificación del contenido. Un grupo de
reglas de codificación para expresar las
instancias de tipos de datos definidos por la
aplicación.
 body (cuerpo): Es el contenido del
mensaje. Una convención para representar
las llamadas y las respuestas a
procedimientos remotos.

1. Identificar 2. Aceptar las 3. Si la

las partes del partes aplicación
mensaje identificadas y SOAP no es el
SOAP dirigido procesarlas de destino final del
a dicha la forma mensaje, quitar
aplicación. adecuada. todas las partes
identificadas en
el paso 1 antes
de reenviar el
mensaje.
 4.2 Creación de servicios web
Un documento WSDL define la interoperabilidad de los servicios Web e incluye la
especificación sobre requerimientos de transporte y formato de los datos a través
de la red. En general, un WSDL no impone ningún requerimiento sobre el modelo
de programación del cliente o del servidor.

el componente Port "pospone" la definición de los

requerimientos del contenedor del servicio a la fase de
despliegue, indicando dichos requerimientos en el
descriptor de despliegue del componente. Un
contenedor proporciona un listener en la dirección del
puerto (port address de un WSDL) y un mecanismo
para "enviar" la petición a la implementación del
servicio Web.

1. El ciclo de vida del Port está 2. Un Port es creado e inicializado por el contenedor antes
completamente controlado por de que la primera llamada recibida en la dirección del
el contenedor, pero en general <port> del WSDL sea servida.
sigue el mismo ciclo de vida
que el del propio contenedor.
3. Un Port es destruido por el 4. Una implementación de un servicio Web JAX-WS reside
contenedor cuando éste en un contenedor Web, y por lo tanto puede desplegarse
considera que sea necesario en un servidor Web o un servidor de aplicaciones, una
hacerlo, como por ejemplo implementación EJB, en cambio, reside en un
cuando el propio contenedor es contenedor EJB y sólo podrá desplegarse en un servidor
sutting down. de aplicaciones.
5. Un componente Port asocia
una dirección de puerto (port
address de un WSDL) con la
implementación del servicio
(Service Implementation
Bean).

Un contenedor proporciona un listener en la dirección del puerto (port address de un WSDL) y un

mecanismo para "enviar" la petición a la implementación del servicio Web. Un contenedor también
proporciona servicios en tiempo de ejecución, tales como restricciones de seguridad y mapeados de
referencias lógicas a referencias físicas de objetos distribuidos y recursos.
 Un desarrollador declara un componente Port en un descriptor de despliegue de
servicios Web.
El descriptor de despliegue incluye el documento WSDL que describe el PortType y
binding del servicio Web.
Cuando se usa JAX-WS, no es necesario proporcionar dicho descriptor de
despliegue.
La mayor parte de la información del descriptor de despliegue se incluye en las
anotaciones de la implementación del servicio. Podríamos utilizar el descriptor de
despliegue para "sobreescribir" o mejorar la información proporcionada por las
anotaciones de la implementación del servicio.

Anotaciones

Podemos especificar la forma en la que se crea el servicio mediante diferentes

anotaciones. Las principales anotaciones disponibles son:

@WebService Indica que la clase define un servicio web. Se pueden especificar como parámetros los
nombres del servicio (serviceName), del componente Port (portName), del SEI del
servicio (name), de su espacio de nombres (targetNamespace), y de la ubicación del
WSDL (wsdlLocation), que figurarán en el documento WSDL del servicio:
@WebService(name="ConversionPortType",
serviceName="ConversionService",
portName="ConversionPort",
targetNamespace="http://jtech.ua.es",
wsdlLocation="resources/wsdl/")
@SOAPBinding Permite especificar el estilo y la codificación de los mensajes SOAP utilizados para
invocar el servicio. Por ejemplo:
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=
SOAPBinding.ParameterStyle.WRAPPED)
@WebMethod Indica que un determinado método debe ser publicado como operación del servicio. Si
no se indica para ningún método, se considerará que deben ser publicados todos los
métodos públicos. Si no, sólo se publicarán los métodos indicados. Además, de forma
opcional se puede indicar como parámetro el nombre con el que queramos que
aparezca la operación en el documento WSDL:
@WebMethod(operationName="eurosAptas")
public int euro2ptas(double euros) {
...
}
@Oneway Indica que la llamada a la operación no debe esperar ninguna respuesta. Esto sólo lo
podremos hacer con métodos que devuelvan void. Por ejemplo:
@Oneway()
@WebMethod()
public void publicarMensaje(String mensaje) {
...
}
@WebParam Permite indicar el nombre que recibirán los parámetros en el fichero WSDL:
@WebMethod(operationName="eurosAptas")
public int euro2ptas(
@WebParam(name="CantidadEuros",
targetNamespace="http://jtech.ua.es")
double euros) {
...
}
@WebResult Permite indicar el nombre que recibirá el mensaje de respuesta en el fichero WSDL:
@WebMethod(operationName="eurosAptas")
@WebResult(name="ResultadoPtas",
targetNamespace="http://jtech.ua.es")
public int euro2ptas(double euros) {
...
}
@WebFault Se utiliza para anotar excepciones Java. Cuando utilizamos esta anotación en una
excepción estamos indicando que cuando sea lanzada por una operación del servicio
web debe generar un mensaje SOAP de respuesta con un SOAP Fault que nos indique
el error producido. En el lado del cliente la clase con dicha excepción se habrá
generado en el stub para el acceso al servicio, y al recibir el mensaje SOAP con el
error el stub lanzará la excepción correspondiente. Es decir, para el desarrollador será
como si la excepción saltase directamente desde el servicio hasta el cliente.
@WebFault
public class ConversionFaultException extends Exception {
public ConversionFaultException(String msg) {
super(msg);
}
}

Requerimientos de un servicio Web JAX-WS

Tipos de datos compatibles

Cuando trabajamos con JAX-WS, los tipos de datos que podremos utilizar como tipo
de los parámetros y de valor de retorno de los métodos de nuestro servicio serán
los tipos soportados por JAXB.

Podremos utilizar cualquiera de los tipos básicos de Java:

1 boolean
2 byte
3 double
4 float
5 int
6 long
7 short
8 char
Además, también podremos utilizar cualquiera de los wrappers de estos tipos
básicos:

1 java.lang.Boolean
 2 java.lang.Byte
3 java.lang.Double
4 java.lang.Float
5 java.lang.Integer
6 java.lang.Long
7 java.lang.Short
8 java.lang.Character
Las siguientes clases de Java también son aceptadas como tipos válidos por JAX-
WS:

1 java.lang.String
2 java.math.BigDecimal
3 java.math.BigInteger
4 java.util.Calendar
5 java.util.Date
6 javax.xml.namespace.QName
7 java.net.URI
Además de estos datos, se permitirá el uso de colecciones cuyos elementos podrán
ser de cualquiera de los tipos admitidos. Estas colecciones podrán ser arrays, tanto
unidimensionales como multidimensionales, o clases del marco de colecciones de
Java:

1 Listas: List
2 ArrayList
3 LinkedList
4 Stack
5 Vector
6 Mapas: Map
7 HashMap
8 Hashtable
9 Properties
10 TreeMap
11 Conjuntos: Set
12 HashSet
13 TreeSet

Implementación del servicio Web con el modelo EJB

Se puede utilizar un Stateless Session Bean, tal y como se define en la

especificación de Enterprise Java Beans, para ser desplegado en un contenedor
EJB. También se puede utilizar un Singleton Session Bean tal y como se define en
la especificación EJB 3.1, para implementar un servicio Web JAX-WS para ser
desplegado en un contenedor EJB.
Los requerimientos para crear una implementación de un servicio como un EJB de
sesión sin estado y singleton, son las mismas que hemos visto en el apartado
anterior para el modelo de programación con servlets.

Podemos anotar un bean de sesión sin estado con la anotación javax.ejb.Stateless.

En este caso, la clase del bean ya no debe implementar la
interfaz javax.ejb.SessionBean.

Un EJB de sesión sin estado y singleton que implementen un servicio Web

utilizando la API de JAX-WS debería utilizar javax.xml.ws.WebServiceContext, el
cual puede inyectarse utilizando la anotación @Resource, tal y como hemos visto
en el ejemplo de la sección anterior.

En el caso de utilizar un bean de sesión singleton se utiliza la

anotación javax.ejb.Singleton.

Por ejemplo, podemos implementar nuestro servicio Web como un Stateless

Session Bean de la siguiente forma:

1 package jaxwsHelloServer;
2
3 import javax.jws.WebService;
4 import javax.jws.WebMethod;
5 import javax.ejb.Stateless;
6
7 @WebService
8 @Stateless
9 public class Hello {
10 private String message = new String("Hola, ");
11
12 public void Hello() {}
13
14 @WebMethod
15 public String sayHello(String name) {
16 return message + name + ".";
17 }
18 }
 4.3 SOAP para e-bussiness
e-bussiness.

Es un protocolo
Recoge todo el conjunto de actividades económicas que se independiente de la
realizan por Internet, ya sean de compraventa de productos plataforma y funciona con el
o prestación de servicios. lenguaje XML. XML puede
crear secuencias de
El único requisito universal para el e-business es un comandos Perl, código C ++
ordenador y una conexión a Internet. y mucho más. Esto significa
que tiene muchas más
Ventajas opciones, y podrá usarlo con
un sitio de comercio
 La realización del negocio es en el mismo instante electrónico existente cuando
 Relación directa y en el momento entre cliente y tenga la integración
vendedor adecuada .
 No hay necesidad de movilidad para realizar el
Es una forma sencilla de
negocio
interactuar con
 No existe límite geográfico de actuación comunicaciones de servicio
 Ahorro de tiempo y dinero remoto, componentes,
 Servicio 24 horas, 7 días a la semana objetos y más. En
 No hay necesidad de una localización física comparación con otros
protocolos, la mayoría de las
personas encuentran que
Aquellos que tienen sitios de comercio electrónico deberían SOAP es muy fácil de
encontrar estas características de SOAP bastante aprender para cualquiera
impresionantes . Una de las grandes ventajas de SOAP es que ya tenga conocimientos
que puede usar el protocolo HTTP, lo que significa que de XML .
funcionará bien con más firewalls de red. Otros protocolos,
como DCOM , a menudo tienen problemas para pasar los
filtros de firewall. La versatilidad de poder utilizar varios
protocolos diferentes, incluidos JMS y SMTP, así como
HTTP, ayuda a que SOAP sea muy popular y útil. También
es fácil usar SOAP con una infraestructura existente. Esto
significa que no tendrá que hacer los cambios drásticos y
lentos que haría si tuviera que usar otra opción.
 4.4 WSDL y Java
En este apartado se resumen las reglas de
correlación de Java con WSDL. El mandato
Java2WSDL utiliza las reglas de correlación
Java-to-WSDL para el proceso ascendente. En el
proceso ascendente, se utiliza la implementación
de un servicio Java existente para crear archivos
WSDL que definen el servicio web. Es posible
que sea necesario editar, manualmente, el
archivo WSDL generado, por los siguientes
motivos:
 No todas las clases y constructores Java
se correlacionan con archivos WSDL. Por
ejemplo, las clases Java que no cumplen
con las reglas de especificación de beans
Java podría ser que no se correlacionen
con constructores WSDL.
 Algunos constructores y clases Java
tienen varias correlaciones con un archivo
WSDL. Por ejemplo, una clase
java.lang.String puede correlacionarse
con un constructor xsd:string o una
soapenc:string. El mandato Java2WSDL
selecciona una de estas correlaciones,
aunque debe editarse el archivo WSDL si
se desea una correlación distinta.
 Hay varios modos de generar
constructores WSDL. Por ejemplo, puede
generar wsdl:part en wsdl:message con
un atributo de tipo o elemento. El mandato
Java2WSDL realiza una selección en
función de los valores de las opciones -
style y -use.
 Para servicios sencillos, es suficiente
el archivo WSDL generado.
 Para servicios complicados, es un
buen punto de partida el archivo WSDL
generado.
1. Correlación de paquetes con
espacios de nombres.
La especificación JAX-RPC no indica la
correlación predeterminada de nombres
de paquetes Java con espacios de
nombres XML.
2. Correlación de identificador:
Los identificadores Java se
correlacionan directamente con
identificadores WSDL y XML.
3. Muchos tipos Java se correlacionan
directamente con tipos XML estándar.
Por ejemplo, un java.lang.String se
correlaciona con un xsd:string. Estas
correlaciones se describen en la
especificación JAX-RPC.
4. Los tipos Java que no se pueden
correlacionar directamente con tipos
XML estándar se generan en la sección
wsdl:types. Las clases Java que
coinciden con el patrón de beans Java
se correlacionan con xsd:complexType.
Revise la especificación JAX-RPC para
obtener una descripción de todas las
reglas de correlación. En el siguiente
ejemplo se muestra la correlación clases
Java base y derivadas de muestra.
5. Clases no soportadas:
Si una clase no se puede asignar a un
tipo XML, el mandato Java2WSDL emite
un mensaje y se genera una referencia
xsd:anyType en el archivo WSDL. En
estas situaciones, modifique la
implementación del servicio web para
utilizar las clases compatibles con JAX-
RPC.
SDL y XML Construcción Java
xsd:complexType Clase de bean Java, clase de excepción
Java o matriz Java
nested xsd:element/xsd:attribute Propiedad de bean Java
xsd:simpleType (enumeration) Clase de enumeración JAX-RPC
wsdl:message: la signatura de parámetro de Signatura del método de interfaz de punto
método viene determinada generalmente por el final de servicio
mensaje wsdl:message.
wsdl:portType Interfaz de punto final de servicio
wsdl:operation Método de interfaz de punto final de
servicio
wsdl:binding Stub
wsdl:service Interfaz de servicio
wsdl:port Método de acceso de puerto de la
interfaz de servicio

XML:

<xsd:complexType name="Sample">
<xsd:sequence>
<xsd:element name="a" type="xsd:string"/>
<xsd:element name="b" maxOccurs="unbounded"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

Java:

public class Sample {

public Sample() {}

// Propiedad de Bean a
public String getA() {...}
public void setA(String value) {...}

// Propiedad de bean indexado b

public String[] getB() {...}
public String getB(int index) {...}
public void setB(String[] values) {...}
public void setB(int index, String value) {...}

}
 4.5 UDDI
4.5 UDDI

Un registro público
 es una colección de
La especificación UDDI (Universal Description, Discovery, directorios iguales que
and Integration) define un modo de publicar y encontrar contienen información
información sobre servicios Web. sobre empresas y
servicios.
 Localiza servicios que
se registran en uno de
UDDI tiene dos funciones: sus nodos iguales y
 Es un protocolo basado en SOAP que define cómo facilita el
se comunican los clientes con los registros UDDI. descubrimiento de
 Es un conjunto de registros duplicados globales en servicios Web
particular. publicados. Se
duplican los datos en
UDDI incluye un esquema XML para mensajes SOAP que todos los registros de
define un conjunto de documentos para describir forma regular.
información de empresas y servicios, un conjunto común de
API para consultar y publicar información en los directorios y Los registros privados
una API para duplicar entradas de directorio entre nodos  permiten publicar y
UDDI iguales. probar las
aplicaciones internas
en entornos privados
seguros.
UDDI gestiona el descubrimiento de servicios Web, que
confía en un registro distribuido de empresas y sus
descripciones de servicio implementado en un formato XML
común. Antes de poder publicar la entidad de empresa y el
servicio Web a un registro público, primero debe registrar la
entidad de empresa con un registro UDDI
 4.6 Framework CFX
CXF es otra pila de servicios web de Apache Software Foundation, el mismo grupo
que desarrolló la pila Axis2. Si bien pertenecen a la misma fundación, Axis 2 y CXF
tienen enfoques muy diferentes en cuanto a la forma de configurar y entregar
servicios web. En este artículo, se analizarán los fundamentos del uso de JAXB 2.x
y JAX-WS 2.x para servicios web con CXF y se establecerá una comparación entre
CXF y las otras pilas para JAXB/JAX-WS — Axis2 y Metro —, que se analizaron en
los artículos anteriores.
Acerca de esta serie
Los servicios web son una parte fundamental del rol
de la tecnología Java en la computación
empresarial. En esta serie de artículos, el consultor
de servicios web y XML Dennis Sosnoski trata de
los marcos y tecnologías más importantes para los
desarrolladores de Java que usan servicios web.
Siga de cerca la serie para mantenerse informado
acerca de las últimas novedades del campo y de la
manera de usarlas para mejorar sus proyectos de
programación.

Características:
 CXF usa flujos de procesamiento de solicitudes y respuestas formados por
componentes configurables.
 CXF denomina estos componentes interceptores, en lugar de controladores,
pero, dejando de lado la terminología, los componentes son equivalentes.
 Al igual que Metro, CXF trae soporte para WS-Security y otras tecnologías
de extensión en la descarga básica. Pero, a diferencia de Metro, los archivos
JAR de CXF son modulares, lo que significa que usted podrá elegir los
archivos JAR que desee incluir en su aplicación en función de las tecnologías
usadas (el archivo /lib/WHICH_JARS de la instalación de CXF le informa los
archivos JAR específicos que se necesitan para diversos casos de uso
habituales).
 La desventaja de este modularidad es que la lista de archivos JAR
específicos necesarios puede llegar a ser muy extensa; la ventaja, que
permite contener el tamaño de su implementación evitando su ampliación.

Aplicación de muestra
Uso del lado cliente Uso del lado servidor
El código del lado cliente de la aplicación de El código del lado servidor de la
muestra en CXF equivale al uso de JAX-WS aplicación de muestra en CXF
con Axis2 o Metro, y los pasos de generación también equivale al uso de JAX-
son similares: simplemente use la herramienta
wsdl2java de CXF en lugar de la herramienta
wsimport de la implementación de referencia
JAX-WS. Ver "JAXB and JAX-WS in Axis2"
para obtener información sobre el código y el
manejo.
Si bien el código del cliente es el mismo, existe
una diferencia significativa en el
comportamiento del cliente en CXF. De manera
predeterminada, CXF imprime una insoportable
cantidad de datos de registro en la consola.
Como CXF usa Java Logging, para evitar estos
datos de salida, es necesario establecer una
propiedad del sistema que señale un archivo de
propiedades de registro con la configuración
cambiada de manera de producir solamente
información WARNING o SEVERE. Esto se
puede hacer con el archivo de Ant build.xml de
la aplicación de muestra, usando la línea de
parámetros de la JVM <jvmarg value="-
Djava.util.logging.config.file=${build-
dir}/logging.properties"/>.
WS con Axis2 o Metro, y el
proceso de generación es muy
similar al de Metro. Con Axis2,
prepare el servicio para su
implementación creando un
archivo JAR que contenga las
clases de servicios y de
modelos de datos y luego
implemente el servicio
colocando ese archivo JAR en
el directorio WEB-
INF/servicejars en una
instalación de servidor Axis2.
En cambio, con Metro y CXF, es
necesario crear un archivo
WAR que contenga las clases
de servicios y de modelos de
datos, los archivos JAR de la
biblioteca Metro o CXF y un par
de archivos de configuración (el
nombre de uno ellos varía
según la pila en cuestión).

Listado 1. Archivo web.xml de la aplicación de muestra

<web-app
1 version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee">
<display-name>CXFLibrary</display-name>
2 <description>CXF Library Service</description>
3 <listener>
4 <listener-
5 class>org.springframework.web.context.ContextLoaderListener</listene
6 r-class>
</listener> <context-param>
7 <param-name>contextConfigLocation</param-name>
8 <param-value> classpath:META-INF/cxf/cxf.xml
9 classpath:META-INF/cxf/cxf-extension-soap.xml classpath:META-
10INF/cxf/cxf-servlet.xml
11</param-value> </context-param> <servlet>
<servlet-name>CXFServlet</servlet-name>
12<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-
13class>
14<load-on-startup>1</load-on-startup>
15</servlet> <servlet-mapping>
16<servlet-
name>CXFServlet</serv
17let-name>
18<url-pattern>/*</url-pattern>
</servlet-mapping> </web-app>
 4.7 Servicios web XML avanzados
Un servicio Web es una colección de protocolos
y estándares empleados para intercambiar datos
entre aplicaciones y sistemas.
 Están basados en protocolos estándar
para la Web.
 Comunicación de aplicación a aplicación
basada en Internet.
 Independencia del lenguaje.
 Las aplicaciones intercambian datos
entre sí en un medio ambiente seguro
usando XML signature y XML encryption,
XML signature ofrece servicios de
integridad y autenticación de mensajes
para los datos, XML encryption es el
proceso para codificar datos de tal manera
que usuarios no autenticados no puedan
entenderlos.
 Cuando se requiere compartir
funcionalidad libre de interfaz de usuario.
Los servicios Web son útiles en cuando se
desea consumir la funcionalidad de un
componente, sin la intermediación de una
interfaz de usuario.
 Cuando se quiere comercializar un
servicio de uso de software, y no un
producto de software.
 Cuando el equipo cliente y servidor
requieren compartir funcionalidad en
Internet, pero difieren en su plataforma
operativa.
SOAP especifica lo siguiente:
Un formato de mensaje para una
comunicación unidireccional, describiendo
cómo se empaqueta la información en
documentos XML.
WSDL es un lenguaje estándar basado en
XML, que define como los servicios Web
XML son descritos cuando son publicados
en un registro. La información del servicio
Web XML es publicada en registros como
documentos WSDL. El documento WSDL es
un archivo XML que incluye el esquema de
interfaz del servicio Web XML. WSDL
reconoce los métodos que son
intercambiados entre el proveedor del
servicio Web XML y el consumidor del
servicio Web XML. Un documento WSDL
proporciona información a los clientes de
cómo acceder a los servicios Web XML.
La especificación UDDI tiene dos objetivos
esenciales: (1) ser un soporte a los
desarrolladores para encontrar información
sobre servicios web y poder construir
clientes, (2) facilitar el Enlace Dinámico de
Servicios Web, permitiendo consultar
referencias y acceder a servicios de interés.
Los servicios Web XML pueden ser
consumidos de dos maneras, directamente
desde un navegador o desde una aplicación de
forma programática.
 4.8
4.8 Seguridad
Seguridad WS
WS

UsernameToken: se utiliza un
nombre de usuario junto con una
contraseña para validar al
El WS-Security (WSS) es una extensión del protocolo SOAP cliente. En este caso, el cliente
que define mecanismos para proteger la integridad y debe signar el mensaje y el
confidencialidad en los mensajes mediante el uso de SAML, servidor puede comprobar la
Kerberos, tokens o los certificados X.509, además de la veracidad calculando la firma del
encriptación y las signaturas XML. En primer lugar, tenemos mensaje recibido y
que tener en cuenta que WS-Security no es un nuevo tipo de comparándola con el valor
servicios web ni de seguridad. recibido.
En el caso de utilizar certificados
X.509, el mensaje puede ser
firmado utilizando una clave
privada. Entonces, el mensaje
debe contener el certificado en
un BinarySecurityToken. Se
recomienda firmar también el
certificado con la clave privada.

Dado que WS-Security no define

nuevos estándares sino que se
basa en los ya existentes, para
la encriptación se puede usar
El Security Token Service es el servicio de validación criptografía de clave pública o
empleado, es decir, Kerberos, certificados X.509 o un privada, simétrica o asimétrica.
sistema consistente en user/password. El procedimiento Normalmente, se realiza a través
consiste en un cliente que solicita los tokens necesarios para del ya antes mencionado XML
dar seguridad a la transmisión y, a partir de aquí, los añade Encription, que permite cifrar
convenientemente al mensaje y los manda al servidor. tanto partes de un documento
como su totalidad y que se
caracteriza por cifrar contenido,
Este es capaz de validar la integridad, confidencialidad y no por lo que se puede mantener la
repudio del mensaje. estructura de XML FIRMA Para
firmar los documentos se
pueden utilizar los tres métodos
de autenticación mencionados
anteriormente.
 CONCLUSIÓN

Un Servicio Web es un componente al que podemos acceder mediante protocolos

Web estándar, utilizando XML para el intercambio de información.
Normalmente nos referimos con Servicio Web a una colección de procedimientos
(métodos) a los que podemos llamar desde cualquier lugar de Internet o de nuestra
intranet, siendo este mecanismo de invocación totalmente independiente de la
plataforma que utilicemos y del lenguaje de programación en el que se haya
implementado internamente el servicio.
Cuando conectamos con un servidor web desde nuestro navegador, el servidor nos
devuelve la página web solicitada, que es un documento que se mostrará en el
navegador para que lo visualice el usuario, pero es difícilmente entendible por una
máquina. Podemos ver esto como web para humanos. En contraposición, los
Servicios Web ofrecen información con un formato estándar que puede ser
entendido fácilmente por una aplicación. En este caso estaríamos ante una web
para máquinas.
Los servicios Web son componentes de aplicaciones distribuidas que están
disponibles de forma externa. Se pueden utilizar para integrar aplicaciones escritas
en diferentes lenguajes y que se ejecutan en plataformas diferentes. Los servicios
Web son independientes de lenguaje y de la plataforma gracias a que los
vendedores han admitido estándares comunes de Servicios Web.
El WC3 (World Wide Web Consortium) define un servicio Web como un sistema
software diseñado para soportar interacciones máquina a máquina a través de la
red. Dicho de otro modo, los servicios Web proporcionan una forma estandar de
interoperar entre aplicaciones software que se ejecutan en diferentes plataformas.
Por lo tanto, su principal característica su gran interoperabilidad y extensibilidad así
como por proporcionar información fácilmente procesable por las máquinas gracias
al uso de XML. Los servicios Web pueden combinarse con muy bajo acoplamiento
para conseguir la realización de operaciones complejas. De esta forma, las
aplicaciones que proporcionan servicios simples pueden interactuar con otras para
"entregar" servicios sofisticados añadidos.
 BIBLIOGRAFIA

(s.f.). Recuperado el 21 de 11 de 2019, de

https://www.ecured.cu/Protocolo_simple_de_acceso_a_objetos_(SOAP)

(s.f.). Recuperado el 23 de 11 de 2019, de http://www.jtech.ua.es/j2ee/publico/servc-web-2012-

13/sesion02-apuntes.html#Creaci%C3%B3n+de+un+servicio+Web+con+JDK+1.6

(s.f.). Recuperado el 23 de 11 de 2019, de

https://www.dtic.ua.es/grupoM/recursos/articulos/JDARE-05-C.pdf

(s.f.). Recuperado el 23 de 11 de 2019, de

https://www.ibm.com/support/knowledgecenter/es/SSEQTP_9.0.5/com.ibm.websphere.b
ase.doc/ae/rwbs_map.html

(s.f.). Recuperado el 23 de 11 de 2019, de https://es.wikipedia.org/wiki/UDDI

(s.f.). Recuperado el 23 de 11 de 2019, de https://desarrolloweb.com/articulos/1589.php

(s.f.). Recuperado el 23 de 11 de 2019, de

https://www.ibm.com/developerworks/ssa/webservices/library/j-jws12/j-jws12.html

(s.f.). Recuperado el 23 de 11 de 2019, de https://desarrolloweb.com/articulos/1664.php

(s.f.). Recuperado el 22 de 11 de 2019, de

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/211