ATLAS MUS Servicios Web-SACUZ PDF

ATLAS
MANUAL DE USUARIO
Servicios Web
Versión 2.1
Arquitectura de Software
Framework Atlas
Manual usuario de Servicios Web
Hoja de Control
Título Manual de Usuario Invocador de Servicios

Documento de Referencia NORMATIVA ATLAS
Responsable Arquitectura de Software
Versión 2.1 Fecha Versión 06/02/2017
Registro de Cambios
Versión Causa del Cambio Fecha
2.0 Reestructuración de documento 21/07/2015

Cambiado xxxxService por yyyyyService
2.1 Se añade información sobre la generación de clientes Atlas mediante clientes únicos en 06/02/2017
vez de multiThread y como activar un modo u otro.
2 de 106
Framework Atlas
Índice
1. INTRODUCCIÓN ................................................................................................................................................................ 5
1.1. AUDIENCIA OBJETIVO ...................................................................................................................................................... 5
1.2. CONOCIMIENTOS PREVIOS ............................................................................................................................................... 5
2. DESCRIPCIÓN .................................................................................................................................................................... 6
3. ¿QUE SEGURIDAD DEBO IMPLEMENTAR? ............................................................................................................... 9
3.1.1. Seguridad de lado del Servidor ............................................................................................................................... 9
3.1.2. Seguridad de lado del Cliente ............................................................................................................................... 10
4. DESARROLLO DE UN SERVICIO WEB (SERVIDOR) .............................................................................................. 12
4.1. CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP Y HTTPS SIN CERTIFICADO CLIENTE) ................. 13
4.1.1. Paso 1: Creación del módulo partiendo del Arquetipo de servicio web ............................................................... 13
4.1.2. Paso 2: Creación de la Interfaz del Servicio y clases para los parámetros ......................................................... 13
4.1.3. Paso 3: Implementación del Servicio ................................................................................................................... 15
4.1.4. Paso 4: Configuración del Servicio ...................................................................................................................... 16
4.1.5. Paso 5: Cambio del namespace del servicio (si se necesita) ................................................................................ 17
4.1.6. Paso 6: Eliminar Namespaces, Elements y Atributos (Si se necesita) .................................................................. 18
4.1.7. Paso 7: Levantar el Servidor ................................................................................................................................ 19
4.1.8. Paso 8: Obtener el wsdl del Servicio .................................................................................................................... 19
4.1.9. Paso 9: Creación de la interfaz para clientes en nuestro servidor ....................................................................... 21
4.1.10. Paso 10: Test Unitarios de nuestra libreria Cliente ............................................................................................. 23
4.2. CREACIÓN DE UN SERVIDOR CON VALIDACIÓN DE CERTIFICADO DE CLIENTE ..................................... 26
4.2.1. Paso 1: Alta de la aplicación en la plataforma ASF ............................................................................................. 26
4.2.3. Paso 3: Actualización de configuración en el fichero services.xml ...................................................................... 28
4.2.4. Paso 4: Modificación de la interfaz para clientes en nuestro servidor................................................................. 28
4.2.5. Acceso al certificado de cliente (para comprobaciones personalizadas) ............................................................. 29
4.3. CREACIÓN DE UN SERVIDOR CON SEGURIDAD EN MENSAJE – WS-SECURITY ......................................... 30
4.3.1. Paso 1: Alta de la aplicación en la plataforma ASF ............................................................................................. 31
4.4. CREACIÓN DE UN SERVIDOR CON WS-SECURITY + CERTIFICADO DE CLIENTE ..................................... 39
5. DESARROLLO DE UN SERVICIO WEB (CLIENTE) ................................................................................................. 42
5.1. ATLAS - CREACION DE UN CLIENTE (HTTP Y HTTPS SIN CERTIFICADO CLIENTE) ................................... 42
5.1.1. Paso 1: Inclusión de la dependencia .................................................................................................................... 42
5.1.2. Paso 2: Configuración del contexto de Spring ..................................................................................................... 42
5.1.3. Paso 3: Configuración del endpoint en environment.properties .......................................................................... 43
5.2. ATLAS - CREACION DE UN CLIENTE CON VALIDACIÓN DE CERTIFICADO DE CLIENTE ......................... 44
5.2.1. Paso 1: Añadir variables de environment ............................................................................................................. 44
5.2.2. Paso 2: Configuración de Spring .......................................................................................................................... 45
5.3. ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY ............................... 47
5.4. ATLAS - CREACION DE UN CLIENTE CON WS-SECURITY + CERTIFICADO DE CLIENTE .......................... 50
5.5. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP Y HTTPS).................................................. 55
5.5.1. Paso 1: Incluir fichero wsdl en el proyecto .......................................................................................................... 55
5.5.2. Paso 2: Inclusión de la dependencia y configuración del plugin.......................................................................... 55
5.5.3. Paso 3: Generación de la clases del Cliente ......................................................................................................... 58
3 de 106
Framework Atlas
5.5.4. Paso 4: Configuración y uso del Cliente .............................................................................................................. 60

5.6. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON CERTIFICADO DE CLIENTE ................... 63
5.7. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY................... 65
5.8. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY +
CERTIFICADO DE CLIENTE................................................................................................................................................. 67
6. CONFIGURACIONES ADICIONALES.......................................................................................................................... 70
6.1.1. Añadir configuración de PROXY a un cliente ...................................................................................................... 70
6.1.2. Personalizar configuración de TIMEOUT a un cliente ........................................................................................ 71
6.1.3. Llamadas a Servicios Web Con Usuario y Password usando HHTP Basic ......................................................... 72
6.1.4. Configuración de Truststore desde puesto LOCAL .............................................................................................. 74
6.2. MÓDULO DE LOG DE MENSAJES ..................................................................................................................................... 83
6.3. PERSONALIZACIÓN DE MENSAJES DE ERROR .................................................................................................................. 85
6.3.1. Especificación SoapFault SCSPv3 ........................................................................................................................ 86
6.4. CAMBIAR ENTRE CONFIGURACIONES DE CLIENTES ATLAS (MULTITHREAD, ÚNICOS..) ................................................... 87
7. OBTENCION DE LO KEYSTORES ............................................................................................................................... 89
8. CREACION DE TESTS UNITARIOS PARA SOAPUI ................................................................................................. 90
8.1.1. Proyecto SoapUI sin seguridad ............................................................................................................................ 90
8.1.2. Proyecto SoapUI con seguridad https................................................................................................................... 91
8.1.3. Proyecto SoapUI con seguridad firmado/cifrado ................................................................................................. 93
8.1.4. Tests de SoapUI WS-Security + Transporte con validación de certificado ........................................................ 100
9. ERRORES MÁS COMUNES .......................................................................................................................................... 102
9.1. NO SE ENCUENTRA EL FICHERO WSDL DE UN SERVICIO (NO AUTOGENERADO)........................................................... 102
9.2. NO SE RECONOCE EL MÉTODO EN UN CLIENTE DE AXIS2 EN LA LLAMADA A UN SERVICIO DE AXIS1 ........................... 103
9.3. ERROR AL GENERAR UN CLIENTE DE AXIS2 A PARTÍR DEL WSDL DEL SERVICIO ......................................................... 103
9.4. ERROR AL EJECUTAR PETICIONES A SERVICIOS WEB SEGURO DESDE ENTORNO LOCAL .............................................. 104
9.5. ERROR AL LLAMAR AL UN SERVICIO WEB NO SEGURO ................................................................................................. 104
9.6. GENERACIÓN DE TODAS LAS CLASES NECESARIAS CON WSDL2CODE CON AXIS2 ................................................... 104
ENLACES RELACIONADOS ................................................................................................................................................ 106
4 de 106
Framework Atlas
1. INTRODUCCIÓN
En algunas ocasiones es necesario que las aplicaciones ofrezcan determinados Servicios Web tanto a otras
aplicaciones de la Comunidad de Madrid como a agentes externos. Por otra parte muchas de las aplicaciones que
se desarrollan para la Comunidad de Madrid necesitan acceder a Servicios Web (tanto servicios que se han
desarrollado específicamente para la tramitación electrónica como otros servicios web que incluso pueden estar
fuera de los entornos de ICM).
En este manual se describe cómo crear servicios web con el framework ATLAS, así como invocar a servicios web
existentes (creados con ATLAS o no). El manual incluye documentación sobre la creación/invocación de servicios
web con seguridad o sin ella.
Para aislar la complejidad de la amplia variedad de tipos de servicios web que nos podemos encontrar y los
distintos tipos de seguridad que nos pueden requerir los citados servicios web se ha desarrollado el componente
Invocador de Servicios de Atlas. Este componente facilita la creación de los clientes de acceso a los servicios
securizados, a través de una sencilla configuración que pueda incluir los requisitos de seguridad requeridos.
1.1. Audiencia objetivo
Este documento está orientado a desarrolladores java que quieran invocar a un servicio web desde un aplicativo
que se desarrolla con Atlas o que quieren generar un servicio web.
1.2. Conocimientos Previos
Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las siguientes
tecnologías:
- Spring Framework.
- Servicios Web
- Axis2 y Rampart
- Seguridad (uso básico de certificados)
5 de 106
Framework Atlas
2. DESCRIPCIÓN
La invocación y generación de servicios web de ATLAS se basa en los siguientes elementos:

Axis2
Módulo de seguridad Rampart
Módulo de seguridad para webservices de ATLAS
Para la creación de nuevos servicios web se partirá de un arquetipo específico para servicios web. Los
servicios web desarrollados implementaran además del propio servicio web una librería cliente para dicho servicio
que facilitará la integración de este servicio web en otros proyectos Atlas. Para implementar un servicio web es
necesario:
Definir la interfaz del Servicio (Como una clase Java)
Implementar en el servicio web dicha interfaz
Implementar un cliente del servicio web
A continuación se muestra un diagrama de clases para un ejemplo de un servicio llamado MiPrimerService:
6 de 106
Framework Atlas
Para el desarrollo de un cliente de un servicio web se van a distinguir dos casos:

Servicios web desarrollados con Atlas
Servicios web externos o no desarrollados con Atlas. En este último caso se utiliza el cliente dinámico de
Axis2, que está basado en la clase RPCServiceClient y permite hacer llamadas a servicios web de forma
sencilla, sin necesidad de generación de clases compiladas (a través del descriptor WSDL del servicio y las
herramientas de Axis2).
En los servicios web podemos distinguir los distintos tipos de accesos:
 Acceso público
Servicio de acceso libre. No se realiza ningún tipo de control sobre el cliente. El canal de comunicación no está
cifrado.
Cliente WS Servidor WS
HTTP
 Acceso público securizado

Servicio de acceso libre.
No se realiza ningún tipo de control sobre el cliente.
Canal cifrado de comunicación.
Para establecer la comunicación el cliente debe confiar en el certificado del servidor.
HTTPS
Trusted CA SSL Server
 Acceso privado con certificado digital cliente

Servicio de acceso restringido. Se realiza control de acceso sobre el cliente identificado por el certificado digital
requerido. Canal cifrado de comunicación.
Para establecer la comunicación el cliente y servidor deben confiar en sus respectivos certificados. Es habitual
que el cliente utilice un tipo de certificado cliente denominado “de componente” (no personal).
7 de 106
Framework Atlas
HTTPS
SSL Client Client trusted Server trusted SSL Server
Server trusted de la CAM

Servidores Web Caché
 WS-Security: Mensaje SOAP firmado y cifrado

El mensaje SOAP se firma y cifra para garantizar la integridad de los datos enviados. Se puede realizar el
control de acceso sobre el cliente que ha firmado el mensaje. Al cifrar el mensaje no es necesario cifrar el
canal de comunicación.
Dentro del framework Atlas se soportan todos estos tipos de accesos y en este documento se describirán como
implementarlos tanto en la parte cliente como en la servidora. Cualquier otro tipo de acceso o de seguridad que se
requiera implementar que sea distinto de los anteriores ha de ser autorizado previamente por el área de
arquitectura de ICM.
Este documento se divide en dos partes bien diferenciadas:

- Desarrollo de un servicio web
- Desarrollo de un cliente de un servicio web
8 de 106
Framework Atlas
3. ¿QUE SEGURIDAD DEBO IMPLEMENTAR?
Antes de la creación de un servicio web, es importante tener claro la seguridad que debemos implementar, en caso
de tener que hacerlo.
3.1.1. Seguridad de lado del Servidor
Si debemos crear un servidor, tendremos los siguientes posibles opciones de seguridad:
HTTP + Mensajes sin seguridad: El servicio estará disponible vía http y los mensajes que viajan no van ni
cifrados ni firmados.
Para este caso, seguiremos el manual en el punto 4.1:
CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO CLIENTE)
HTTPS + Mensajes sin seguridad: El servicio estará disponible vía https sin ningún otro requerimiento
para nuestros clientes y los mensajes que viajan no van ni cifrados ni firmados.
CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO CLIENTE)
HTTPS con certificado + Mensajes sin seguridad: El servicio estará disponible vía https y, como
servidores, exigiremos que el certificado de los clientes que se conectan sea válido (y otras validaciones
opcionales) y los mensajes que viajan no van ni cifrados ni firmados.
CREACIÓN DE UN SERVIDOR CON VALIDACIÓN DE CERTIFICADO DE CLIENTE
HTTP + Mensajes con seguridad: El servicio estará disponible vía http y los mensajes viajan cifrados,
firmados o ambas.
CREACIÓN DE UN SERVIDOR CON SEGURIDAD EN MENSAJE – WS-SECURITY
HTTPS + Mensajes con seguridad: El servicio estará disponible vía https y los mensajes viajan cifrados,
firmados o ambas.
HTTPS con certificado + Mensajes con seguridad: El servicio estará disponible vía https y, como
servidores, exigiremos que el certificado de los clientes que se conectan sea válido (y otras validaciones
opcionales) y los mensajes viajan cifrados, firmados o ambas.
CREACIÓN DE UN SERVIDOR CON WS-SECURITY + CERTIFICADO DE CLIENTE
9 de 106
Framework Atlas
3.1.2. Seguridad de lado del Cliente
Si debemos crear un cliente para consumir un servicio, tendremos que diferenciar entre clientes Atlas y clientes No
Atlas (Servicios web Externos).
WS Atlas - HTTP + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través de
HTTP y los mensajes que viajan no van ni cifrados ni firmados.
ATLAS - CREACION DE UN CLIENTE (HTTP y HTTPS SIN CERTIFICADO CLIENTE)
WS Atlas - HTTPS + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través de
HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan no van ni cifrados
ni firmados.
ATLAS - CREACION DE UN CLIENTE (HTTP y HTTPS SIN CERTIFICADO CLIENTE)
WS Atlas – HTTPS con certificado + Mensajes sin seguridad: Al servicio al que nos conectamos se
accede a través de HTTPS y el servidor requiere que, como clientes, nos identifiquemos con un certificado.
Los mensajes que viajan no van ni cifrados ni firmados.
ATLAS - CREACION DE UN CLIENTE CON VALIDACIÓN DE CERTIFICADO DE CLIENTE
WS Atlas – HTTP + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través de
HTTP y los mensajes que viajan van cifrados, firmados o ambas.
ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY
WS Atlas – HTTPS + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través de
HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan van cifrados,
firmados o ambas.
ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY
WS Atlas – HTTPS con certificado + Mensajes con seguridad: Al servicio al que nos conectamos se
Los mensajes que viajan van cifrados, firmados o ambas.
ATLAS - CREACION DE UN CLIENTE CON WS-SECURITY + CERTIFICADO DE CLIENTE
10 de 106
Framework Atlas
WS Externo – HTTP + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través de
HTTP y los mensajes que viajan no van ni cifrados ni firmados.
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP y HTTPS)
WS Externo – HTTPS + Mensajes sin seguridad: Al servicio al que nos conectamos se accede a través
de HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan no van ni
cifrados ni firmados.
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP y HTTPS)
WS Externo – HTTPS con certificado + Mensajes sin seguridad: Al servicio al que nos conectamos se
Los mensajes que viajan no van ni cifrados ni firmados.
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON CERTIFICADO DE CLIENTE
WS Externo – HTTP + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través
de HTTP y los mensajes que viajan van cifrados, firmados o ambas.
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY
WS Externo – HTTPS + Mensajes con seguridad: Al servicio al que nos conectamos se accede a través
de HTTPS, como clientes no nos requieren certificado al conectar y los mensajes que viajan van cifrados,
firmados o ambas.
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY
WS Externo – HTTPS con certificado + Mensajes con seguridad: Al servicio al que nos conectamos se
Los mensajes que viajan van cifrados, firmados o ambas.
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY + CERTIFICADO
DE CLIENTE
11 de 106
Framework Atlas
4. DESARROLLO DE UN SERVICIO WEB (SERVIDOR)
En este apartado se muestra cómo crear un servicio web con el framework ATLAS, así como el procedimiento para
aportar seguridad al servicio web (integrándose con la plataforma ASF).
Para el desarrollo de servicios web el framework se apoya en las siguientes tecnologías:

Axis 2: Framework java para desarrollo de servicios web de la ASF (Apache Software Foundation).
Rampart: Módulo de seguridad de Axis 2.
Wss4j: Implementación estándar de seguridad en servicios web.
Xmlsec: Estándar de seguridad para ficheros XML en que se basa el estándar WSS (Web Services
Security).
Además de esto, el framework ATLAS aporta los siguientes elementos propios:

Arquetipo de generación de proyectos de tipo servicio web. La generación de proyectos para servicios
web es muy sencilla a través del arquetipo ATLAS destinado a tal efecto. En este manual se muestra cómo
crear un servicio web a partir del arquetipo.
Módulo de seguridad para integración con la plataforma de seguridad ASF 5. En este documento
también se muestra cómo configurar un arquetipo para integrarse con dicha plataforma.
12 de 106
Framework Atlas
4.1. CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO CLIENTE)
En los siguientes sub-apartados se muestra cómo crear un proyecto servicio web con el framework Atlas, sin
ningún tipo de seguridad a nivel de mensaje (ws-security) ni comprobaciones de certificados de cliente. Esta
configuración acepta tanto http como https siempre y cuando no exista validación de certificado de cliente (se
aceptan todos los clientes que se conecten).
4.1.1. Paso 1: Creación del módulo partiendo del Arquetipo de servicio web
El framework ATLAS tiene disponible un arquetipo preconfigurado y preparado para la creación de proyectos de
servicios web. El uso de este arquetipo genera una primera versión de proyecto con clases demostrativas del uso y
funcionalidad.
Para la creación de proyecto de servicio web partiendo de un arquetipo consultar el manual

“ATLAS_MUS_Arquetipo_WebService”. Una vez generado el arquetipo según se indica en este manual, proseguir
con los pasos indicados en este apartado.
ATENCION
La creación de servicios web debe ser realizada siempre en base al arquetipo ’atlasfrm-
arquetipos-generador-servicioweb’, según se explica en el manual
“ATLAS_MUS_Arquetipo_WebService”
El arquetipo de servicio web de ATLAS generará un proyecto modular, que contiene tres módulos:
- web: El servicio web expuesto.
- test: tests de SoapUI para el servicio web.
- lib: Librería (jar) que contiene las clases que definen el interfaz del servicio web a exponer, así como
los objetos de dominio. Se han separado estas clases en una librería aparte porque esta librería podrá
ser utilizada en otros proyectos para invocar al servicio web.
El arquetipo de servicio web contiene un ejemplo de servicio web llamado EjemploServicio.
ATENCION
Las clases de servicio que se van a crear son las mismas que las que se definen en la capa de
servicios de la normativa de Atlas, por lo tanto les aplica la misma normativa.
4.1.2. Paso 2: Creación de la Interfaz del Servicio y clases para los parámetros
La interfaz del servicio debe ser creada dentro del módulo lib, de esta forma es compartido por el servicio web y
por la aplicación cliente del servicio web. El módulo web contiene una dependencia del módulo lib de forma que
13 de 106
Framework Atlas
las clases del módulo lib estarán accesibles desde el web.
ATENCION
La creación de las clases que representan la interfaz del servicio web se realizará dentro del
módulo lib del proyecto.
Por ejemplo nos creamos la interfaz siguiente:
Clase lib/src/main/java/xxxx/services/MiPrimerService.java
package prueba123.services;
import atlas.core.exceptions.ServiceException;
public interface MiPrimerService {
String getFechaString() throws ServiceException;
Tal y como indica la normativa de Atlas con respecto a los servicios todos los métodos deben lanzan
ServiceException cuando ocurre algún problema.
Si la interfaz del servicio incluye parámetros que no son tipo básicos hay que crear una clase para cada uno de los
parámetros.
En la interfaz EjemploServicio que se incluye de ejemplo en el arquetipo, se define un objeto de entrada llamado
DatosEntrada y un objeto de salida, llamado DatosSalida. Estos objetos de datos tienen que ser creados en el
módulo lib del cliente ya que serán usados tanto por el cliente y por el servicio web.
ATENCION
La creación de las clases que representan los objetos de entrada/salida del servicio web se
realizará dentro del módulo lib del proyecto. Además estos objetos no pueden ser objetos de
dominio de Hibernate sino simples POJOS y serializables.
14 de 106
Framework Atlas
A continuación se muestra el código de alguno de estos objetos:
Clase lib/src/main/java/xxxx/domain/DatosEntrada.java
public class DatosEntrada implements Serializable {

private static final long serialVersionUID = -4672740919183330887L;
String cadena1;
Integer limite = -1;
public String getCadena1() {
return cadena1;
}
public void setCadena1(String cadena1) {
this.cadena1 = cadena1;
}
public Integer getLimite() {
return limite;
}
public void setLimite(Integer limite) {
this.limite = limite;
}
}
4.1.3. Paso 3: Implementación del Servicio
Una vez creada la interfaz del servicio, debemos proceder a crear la clase que implementa dicha interfaz.
La implementación del servicio web tendrá las siguientes características:
Se creará en el módulo web del proyecto.
Residirá en el mismo paquete que la interfaz del servicio en el módulo de cliente.
Su nombre será el de la interfaz de servicio acabado en „Impl’ siguiendo la normativa de
creación de servicios de ATLAS.
Incluirá la anotación @Service
ATENCION
La creación de las clases que implementan el servicio web se realizará dentro del módulo web
del proyecto, y pertenecerán al mismo paquete que las interfaces que implementan.
15 de 106
Framework Atlas
A continuación mostramos una implementación de ejemplo:
Clase lib/src/main/java/xxxx/services/MiPrimerServiceImpl.java
package prueba123.services;
import org.springframework.stereotype.Service;
@Service
public class MiPrimerServiceImpl implements MiPrimerService{
@Override
public String getFechaString() throws ServiceException {
return "fecha";
}
4.1.4. Paso 4: Configuración del Servicio
Para que el servicio web esté accesible será necesario realizar dos configuraciones:
Definir un bean en el contexto de Spring para la clase implementada del Servicio en el fichero
web/src/main/resources/conf/applicationContext-services.xml,
Fichero web/src/main/resources/conf/applicationContext-services.xml
<?xml version="1.0" encoding="UTF-8"?>

<beans>
[...]
<bean id="miPrimerService" class="ejpl.services.MiPrimerServiceImpl" />
</beans>
Definir el servicio en el fichero de axis web/src/main/webapp/WEB-INF/services.xml.
16 de 106
Framework Atlas
En el fichero service.xml están todas las definiciones de servicios web que necesita Axis2. Cada tag <service>
define un webservice diferente.
Fichero web/src/main/webapp/WEB-INF/services.xml
[...]
<service name="MiServicioWeb">
<parameter name="ServiceObjectSupplier" locked="false">
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier
</parameter>
<parameter name="SpringBeanName" ocked="false">miPrimerService</parameter>
<parameter name="ServiceClass"
locked="false">prueba123.services.MiPrimerService
</parameter>
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver" />
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver" />
</messageReceivers>
</service>
[...]
Se ha de incluir un tag de service como el que se muestra de ejemplo modificando los siguientes parámetros:
SpringBeanName: nombre del bean que se definió en el fichero applicationContext-services.xml.

ServiceClass: Nombre de la clase (con su paquete correspondiente) que representa el interfaz del
servicio (se utiliza para la construcción del descriptor WSDL).
4.1.5. Paso 5: Cambio del namespace del servicio (si se necesita)
Si se quiere modificar el namespace del servicio web generado por defecto se hace modificando las propiedades
xmlns:ns y targetNamespace y añadiendo el tag <schema schemaNamespace=""/>
Por ejemplo para cambiarlo a http://salud.madrid.org/IntegracionHorus
[...]
<service name="MiServicioWeb"
xmlns:ns="http://salud.madrid.org/IntegracionHorus"
targetNamespace="http://salud.madrid.org/IntegracionHorus">
<schema schemaNamespace="http://salud.madrid.org/IntegracionHorus"/>
[...]
</service>
[...]
17 de 106
Framework Atlas
4.1.6. Paso 6: Eliminar Namespaces, Elements y Atributos (Si se necesita)
ATENCION
Para hacer los cambios propuestos en este punto se deberá pedir una autorización excepcional
a Arquitectura explicando la necesidad de usarlo, ya que un cambio en la respuesta XML de un
Web Service puede hacer que los clientes no puedan leerla correctamente
Si se quiere modificar cualquier parte del xml de respuesta que se envía como respuesta del servicio se deberá
hacer uso del patrón “message exchange pattern” (MEP) creando una clase que implemente la clase abstracta
AtlasInOutMessageReceiver y hacer un Override del método “modificarRespuesta”, esta clase se deberá indicar
en el Services.xml en a nivel de todo el servicio o solo a nivel de una operación, a continuación se ponen ambos
ejemplos:
[...]


<service name="EjemploService">
. . .
<messageReceivers>
class="ws128.services.MiInterceptor" />
</messageReceivers>
</service>
[...]
[...]


<service name="EjemploService">
. . .
<messageReceivers>
</messageReceivers>
<operation name="alterar">
<messageReceiver class="ws128.services.MiInterceptor"/>
</operation>
</service>
[...]
18 de 106
Framework Atlas
La clase MiInterceptor sería de la siguiente forma:
MiInterceptor.java
package ws128.services;
import atlas.clientews.client.AtlasInOutMessageReceiver;
public class MiInterceptor extends AtlasInOutMessageReceiver {
@Override
public String modificarRespuesta(String respuesta) {
//Estos reemplazos son solo de ejemplo
respuesta = respuesta.replaceAll("<ns:", "<");
respuesta = respuesta.replaceAll("</ns:", "</");
respuesta = respuesta.replaceAll("xsi:type=\"ax23:DatosSalida\"", "");
return respuesta;
}
4.1.7. Paso 7: Levantar el Servidor
Una vez configurado el servicio web, para probarlo deberá ejecutarse el servidor Jetty según se explica en el
manual “ATLAS_MUS_Arquetipo_WebService”. Para comprobar que se ha levantado correctamente y que están
disponibles los servicios se puede acceder a la url http://localhost:9080 y nos debe aparecer una pantalla similar a
esta:
4.1.8. Paso 8: Obtener el wsdl del Servicio
Para obtener el wsdl de nuestro servicio web se puede a través de una url del siguiente tipo:
http://localhost:9080/services/MiServicioWeb?wsdl
19 de 106
Framework Atlas
Este wsdl se ha de guardar en el módulo test en la carpeta test/src/main/resources/wsdl con el nombre del
servicio y la extensión wsdl. Ej: MiServicioWeb.wsdl.
En el caso de que el servicio web se construya a partir de un wsdl predeterminado (que no hay sido generada por
Axis) al intentar acceder al wsdl se obtiene el siguiente error:
<error>
<description>Unable to generate WSDL 1.1 for this service</description>
<reason>If you wish Axis2 to automatically generate the WSDL 1.1, then please set
useOriginalwsdl as false in your services.xml</reason>
</error>
Para poder obtener correctamente el wsdl es necesario realizar lo siguiente:
1. - Si el WSDL predeterminado del servicio es un solo fichero, se ha de hacer lo

siguiente:
a.- En el fichero WEB-INF/services.xml, en la definición del servicio se coloca el siguiente

parámetro:
<parameter name="useOriginalwsdl">true</parameter>
b.- Para que el fichero WSDL pueda ser localizado y entregado, este ha de dejarse, con el
nombre del servicio en el directorio WEB-INF.
Un ejemplo, si tengo el servicio 'EjemploServicio', además del parámetro 'useOriginalwsdl'

tendrá que haber un fichero:
---->WEB-INF/EjemploServicio.wsdl
20 de 106
Framework Atlas
En este caso el wsdl se obtendría con la URL:
http://localhost:9080/services/EjemploServicio?wsdl
2. - Si el WSDL consta de varios ficheros, además del parámetro 'useOriginalwsdl' en la

definición del servicio, este ha de generarse en formato aar o 'exploded' (contenido del aar
descomprimido). La esctructura en formato 'exploded' sería la siguiente (con
EjemploServicioNoSeguro):
---->WEB-INF
-------->services
------------>EjemploServicio
---------------->META-INF
-------------------->services.xml (descriptor del servicio)
-------------------->service.wsdl
-------------------->parte1.xsd
-------------------->parte2.xsd
En este ejemplo, el fichero service.wsdl tiene sentencias:
<xs:import namespace="..." schemaLocation="parte1.xsd" />

<xs:import namespace="..." schemaLocation="parte2.xsd" />
En este caso el wsdl se obtendría con la URL:
http://localhost:9080/services/EjemploServicio?wsdl [^]
y cada una de los ficheros xsd con la URL:
http://localhost:9080/services/EjemploServicio?xsd=parte1.xsd [^]
http://localhost:9080/services/EjemploServicio?xsd=parte2.xsd [^]
En el caso de tener un WSDL predeterminado para el servicio, además será necesario editar el fichero
weblogic.xml y añadir la siguiente línea (marcada en amarillo):
Fichero web/src/main/webapp/WEB-INF/weblogic.xml
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
<wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
</wls:container-descriptor>
4.1.9. Paso 9: Creación de la interfaz para clientes en nuestro servidor
Una vez creado el servicio web ahora vamos a crear el cliente que se distribuirá con una librería para que las
aplicaciones que tengan que integrarse con nuestra aplicación lo hagan utilizando esta librería.
Los clientes de servicio web ATLAS se caracterizan por que no se generan a partir de un descriptor WSDL del
servicio sino que se parte de la clase de la interfaz del servicio y de las clases que representen a los parámetros
21 de 106
Framework Atlas
del mismo. La invocación a los métodos del servicio web va a ser dinámica. Para facilitar esta invocación dinámica
dentro del framework Atlas existen dos clases base para la creación de clientes de servicio web, en el caso actual
hablamos de clientes no seguros y clientes seguros sin validación de certificado de cliente.
AtlasUnsecuredWSClient: esta clase es la utilizada para servidores sin seguridad a nivel de mensaje o
seguridad HTTPS sin validación de certificado de cliente (Todos los clientes pueden conectar) ;
Realizamos una interfaz como el siguiente ejemplo:
ClienteMiPrimerService.java
package prueba.client;
import java.util.Properties;
import prueba.services.MiPrimerService;
import atlas.clientews.client.AtlasUnsecuredWSClient;
public class ClienteMiPrimerService extends AtlasUnsecuredWSClient implements MiPrimerService{
/** Constructor que recibe como parámetro el endpoint del servicio

Se le pasará en el fichero de contexto de Spring y lo cogerá del fichero
enviroment.properties
**/
public ClienteMiPrimerService(String endpoint) {
super(endpoint, "http://services.prueba123");
}
/** Propiedades */
private Properties properties;
@Override
return invoke("getFechaString", properties, String.class);
}
/**
* Establece el valor de las propiedades
* @param properties las propiedades
*/
public void setProperties(Properties properties) {
this.properties = properties;
}
}
La clase cliente a implementar debe cumplir las siguientes condiciones:

1) Se crea en el paquete xxxx.client dentro del módulo lib.
2) Se llama según la siguiente nomenclatura ClienteyyyyyService.java. Ejpl: ClienteMiPrimerService.
3) Extiende la clase base a utilizar, en este caso AtlasUnsecuredWSClient.
4) Implementa la interfaz del servicio para proporcionar una implementación de todos los métodos de este.
5) El constructor toma como parámetro la URL del servicio. Dejar el namespace del servicio igual que se ha
generado en los ejemplos del arquetipo, no modificar este valor.
6) Los métodos implementados de la interfaz de servicio llevan la anotación @Override para que el
compilador pueda detectar posibles errores en el nombre de estos.
22 de 106
Framework Atlas
7) Las llamadas al servicio web se realizan a través del método invoke con los parámetros definidos en su
javadoc:
Definición del método invoke

/**
* Realiza la invocación del servicio web
* @param <E> parametrización del tipo de objeto a devolver.
* @param methodName método de webservice a llamar
* @param serviceProperties propiedades de llamada del servicio web
* @param returnType tipo a retornar por la llamada
* @param parameters parametros de llamada
* @return respuesta del webservice
* @throws ServiceException si hubo algún tipo de problema en la llamada
*/
protected <E> E invoke(String methodName, Properties serviceProperties,
Class<E> returnType, Object... parameters)
throws ServiceException {
En caso de que el método de llamada acepte más de un parámetro de entrada, se deberá realizar la llamada al
método invoke de la siguiente forma:
Llamada al método invoke con varios parámetros
@Override
public DatosSalida alterar(DatosEntrada entrada1, String entrada2)
throws ServiceException {
return invoke("alterar", properties, DatosSalida.class, entrada1, entrada2);

}
1) Las propiedades del servicio se almacenan en una variable interna de la clase ya que es necesario
pasarlas en cada llamada a la clase base AtlasUnsecuredWSClient. Es necesario también que esté
implementado el método setProperties tal cuál viene en el ejemplo. En casos generales, no será necesario
especificar ningún parámetro en las propiedades del servicio, siempre que no se envíen ficheros adjuntos
(en caso afirmativo debe establecerse enableMTOM a „true’) y no se haga uso de otros módulos de Axis2
como por ejemplo „addressing‟. A continuación se muestran las propiedades que se pueden utilizar:
Parámetro Descripcion Valor por Defecto
repositoryRoot Raíz del repositorio de módulos de Axis2 "./META-INF/"
enableMTOM Habilitar optimización de envío de binarios. false
4.1.10. Paso 10: Test Unitarios de nuestra libreria Cliente
Los tests unitarios que habrán de realizarse dentro de la librería deben comprobar la correcta comunicación con el
23 de 106
Framework Atlas
webservice en cada uno de los métodos de llamada de que disponga. Para la creación de dichos tests se utilizará,
como es norma en el framework ATLAS, la librería java jUnit 4. Para facilitar la creación del contexto de Spring las
clases de test heredarán de la clase AbstractJUnit4SpringContextTests.
NOTA
Con el arquetipo recien generado todos los métodos de los test de JUnit incluyen la anotación @Ignore y no se
ejecutarán en el proceso de construcción de la librería cliente (serán ignorados). Una vez creada e instalada la
librería en el repositorio local (mvn clean install), se podrá eliminar la anotación @Ignore de cualquier método
que se desee testear, y ejecutar el test con el comando mvn test (el módulo de servidor web debe estar
arrancado también para que el test sea correcto).
El código de prueba de una clase de test de ejemplo es el siguiente (definida en lib/src/test/java):
lib/src/test/java/ClienteMiPrimerServiceTest.java
24 de 106
Framework Atlas
import static org.junit.Assert.*;
import org.junit.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests;
@ContextConfiguration(locations = {"classpath:/conf/applicationContext-test.xml"})
public class ClienteMiPrimerServiceTest extends AbstractJUnit4SpringContextTests {
// Autowired solo permitido en clases de tests unitarios

@Autowired @Qualifier("miPrimerService")
private MiPrimerService service;
public void setService(MiPrimerService service) {

this.service = service;
}
@Test
public void testGetFechaString() {
assertNotNull("El servicio es nulo", service);
String salida = null;
try {
salida = service.getFechaString();
} catch (Exception e){
e.printStackTrace();
fail("Error en la llamada");
}
assertNotNull(salida);
System.out.println("** Salida: " + salida);
}
Se ha marcado en color amarillo la llamada al invocador dinámico creado anteriormente.
En este ejemplo, se ha creado un test unitario que recoge la instancia del invocador concreto de Spring. A través
de Spring también se está pasando una URL concreta de servicio para testear. Además de implementar el test,
para probar el cliente es necesario configurar el endpoint en el contexto de Spring de los tests, modificando el
fichero lib/src/test/resources//environment.properties, según se muestra en el ejemplo incluido en el arquetipo:
25 de 106
Framework Atlas
lib/src/test/resources/environment.properties
[...]
# Datos de WS
miPrimerService.endpoint=http://localhost:9080/services/MiServicioWeb
[...]
Este test se puede ejecutar desde el propio Eclipse como cualquier test unitario, pero hay que tener en cuenta que
hay que tener levantado el servicio web.
4.2. CREACIÓN DE UN SERVIDOR CON VALIDACIÓN DE CERTIFICADO DE CLIENTE
En los servicios web en los que haya que implementar seguridad a nivel de transporte HTTPS y sea necesario la
validación de los clientes que se conectan, es necesaria configurar nuestro servidor para que verifique el cliente
conectado contra la plataforma de ASF. Para ello hay que realizar los siguientes pasos.
ATENCION
Esta configuración es para conexiones seguras HTTPS en las que el servidor verifica los
clientes conectados contra ASF.
Si se precisa una conexión segura (HTTPS) sin este tipo de validaciones (permitiendo a todos
los clientes conectarse), consultar el apartado previo:
“CREACIÓN DE UN SERVIDOR SIN SEGURIDAD (HTTP y HTTPS SIN CERTIFICADO

CLIENTE)”
4.2.1. Paso 1: Alta de la aplicación en la plataforma ASF
Antes de configurar la aplicación, debemos darla de alta en el entorno ASF y configurarla. Para el entorno de
desarrollo, esto se debe realizar mediante una consulta a la Unidad de Arquitectura de Aplicaciones en la categoría
de ASF a través de la web de soporte. Para el resto de entornos (validación, producción, etc.) se incluye dicha
información en la ficha de entrega.
La información que se ha de incluir en la solicitud es la siguiente:

- operación: WSS - seguridad servicio web
- aplicación: Nombre de aplicación que se desea dar de alta en ASF
26 de 106
Framework Atlas
- certificado de servidor a utilizar: Indicar qué certificado de servidor se desea utilizar, o si se quiere
utilizar uno genérico.
A continuación se muestra un ejemplo de solicitud:
Ejemplo de solicitud a la Unidad de Arquitectura de Aplicaciones

Operacion: WSS - seguridad servicio web
Aplicacion: EJPL_WS_SERVIDOR
Certificado de servidor: certificado genérico
Como respuesta a la solicitud, la Unidad de Arquitectura de Aplicaciones contestará con un mensaje como este:
Ejemplo de respuesta de la Unidad de Arquitectura de Aplicaciones

Se han realizado actuaciones en la plataforma ASF 5.0 para definir servidor y cliente del alta solicitada para el
módulo "EJPL_WS_SERVIDOR".
Los datos para configurar los desarrollos son los siguientes:
- SERVIDOR
> ID de aplicación ASF: EJPL_WS_SERVIDOR
> alias "localkey": servidor_ws
- CLIENTE
> ID de aplicación ASF: EJPL_WS_CLIENTE
> alias "localkey": cliente_ws
> alias "remotekey": servidor_ws_cert
En la respuesta se mostrarán los datos de configuración necesarios para el servicio web (apartado SERVIDOR) y
para las pruebas unitarias del cliente en el módulo lib (apartado CLIENTE).
Una vez que se ha dado de alta en ASF y con los de SERVIDOR tenemos que incluir en el fichero
src/main/resources/environment.properties lo siguiente:
src/main/resources/environment.properties
# Ids de aplicacion
app.id.asf=EJPL_WS_SERVIDOR
# Parametros de WS
El valor de la variable app.id.asf es el identificador de la aplicación en la plataforma ASF (debe ser igual que la
aplicación dada de alta en ASF). Este dato se corresponde con el ID de aplicación en el apartado SERVIDOR de la
27 de 106
Framework Atlas
respuesta de la Unidad de Arquitectura de Aplicaciones.
4.2.3. Paso 3: Actualización de configuración en el fichero services.xml
En la lista de parámetros:
<service name="ComunicacionApertura">
...
<parameter name="asfInvokingApp">${app.id.asf}</parameter>
Donde dicha variable se corresponde con el código ASF de nuestra aplicación registrada en ASF.
Además, se añade el transporte HTTPS dentro del mismo fichero:
…
<transports>
<transport>https</transport>
</transports>
Y por último, se importa el módulo de seguridad de atlas:
<module ref="atlasfrm-clientews-seguridad-https" />
Esta configuración en nuestro servidor, hará que los clientes que se conecten sean verificados contra ASF
4.2.4. Paso 4: Modificación de la interfaz para clientes en nuestro servidor
28 de 106
Framework Atlas
dentro del framework Atlas existen varias clases base para la creación de clientes de servicio web, en el caso
actual hablamos de clientes seguros con validación de certificado.
AtlasHttpsWSClient: esta clase es la utilizada para servidores con seguridad a nivel de transporte HTTPS
y certificado de cliente
Por lo tanto, nuestra interfaz en vez de extender de AtlasUnsecuredWSClient, extenderá de AtlasHttpsWSClient,

por ejemplo así:
import atlas.clientews.client.AtlasHttpsWSClient;
public class ClienteMiPrimerService extends AtlasHttpsWSClient implements MiPrimerService{
/** Constructor que recibe como parámetro el endpoint del servicio

Se le pasará en el fichero de contexto de Spring y lo cogerá del fichero
enviroment.properties
**/
public ClienteMiPrimerService(String endpoint) {
}
/** Propiedades */
@Override
}
/**
*/
}
}
4.2.5. Acceso al certificado de cliente (para comprobaciones personalizadas)
Hemos configurado un servicio web para que los clientes que conectan sean verificados contra ASF.. Sin embargo,
el servicio web puede tener otros requisitos de seguridad respecto del cliente, como saber si el certificado que
conecta, aun siendo aceptado por ASF, es válido para nuestro servicio.
29 de 106
Framework Atlas
Dentro del código del servicio web es sencillo recoger el certificado digital cliente de firma, tal y como se muestra a
continuación:
Obtención del certificado de cliente del mensaje entrante

@Service
public class EjemploServicioImpl implements EjemploServicio {
...
private void getClientCertificate() {
try {
String cert = AtlasRampartUtils.getSigningCert();
log.info("Certificado de firma: \n\n" + cert + "\n\n");
} catch (AtlasSecurityException e) {
log.error("Error al capturar certificado de firma.", e);
}
}
}
En el ejemplo anterior se ha marcado en amarillo la sentencia con la que se recoge el certificado de firma del
mensaje del cliente (el resto del código es solo un ejemplo de implementación). Hay que tener las siguientes
consideraciones:
Si el mensaje no contiene seguridad, se devolverá un valor null.
Si se produce algún problema en la exploración del mensaje entrante para la captura del certificado, se
devolverá una excepción AtlasSecurityException.
Si se desea obtener los datos de este certificado, será necesario realizar las llamadas correspondientes al
servicio de ASF de ATLAS (CryptService.getDatosCertificado(String)). Para más información, consultar
el documento ATLAS_MUS_Servicio_Certificados.doc.
4.3. CREACIÓN DE UN SERVIDOR CON SEGURIDAD EN MENSAJE – WS-SECURITY
En los servicios web en los que haya que implementar seguridad a nivel de mensaje, utilizaremos WS Security.
En este apartado se muestra cómo configurar un servicio web para incluir seguridad de WS-Security que consiste
en que la seguridad va dentro del mensaje SOAP.
Dentro de este modelo de seguridad existen las siguientes posibilidades:

- Firmado digital del mensaje SOAP – Garantiza la procedencia del mensaje, integridad de los datos y
no repudio.
- Cifrado del mensaje SOAP – Garantiza la confidencialidad del mensaje.
Antes de implementar la seguridad en un servicio web lo primero es crear el servicio web y probar su correcto
30 de 106
Framework Atlas
funcionamiento sin incluir seguridad tal y como se indica en los apartados anteriores.
Para cada servicio web al que se quiera incluir seguridad, ha de asociale una política de seguridad. Dentro del
arquetipo en el módulo lib podemos encontrarnos dos politicas (lib/src/main/resources/META-INF):
politicaWSSFirmado.xml
politicaWSSFirmadoCifrado.xml
En estos ficheros se definen las restricciones de seguridad a aplicar siguiendo los estándares de WS Security-
Policy.
Alguna de las características de estas politicas son las siguientes:

En el intercambio de información se utilizarán claves asimétricas, pares clave pública (certificado) +
clave privada.
El certificado a usar deberá ser del tipo X509v3 y además deberá contar con una referencia de tipo
thumbprint (tags RequireThumbprintReference y WssX509V3Token10).
La cabecera de seguridad del mensaje deberá contener una fecha de creación de este (tag
IncludeTimestamp).
Se firmará digitalmente el cuerpo del mensaje (tag SignedParts/Body).
Se cifrará el contenido del cuerpo del mensaje (tag EncryptedParts/Body).
El mensaje firmado contendrá una copia del certificado público del firmante (tag X509Token
IncludeToken=”…/Always”).
Para las operaciones de firma, cifrado y validación de firma y cifrado se utilizará la plataforma ASF.
Suponiendo que ya tenemos un Servicio creado y funcionando pasamos a incorporale WSSecurity
4.3.1. Paso 1: Alta de la aplicación en la plataforma ASF
Antes de configurar la aplicación, debemos darla de alta en el entorno ASF y configurarla. Para el entorno de
desarrollo, esto se debe realizar mediante una consulta a la Unidad de Arquitectura de Aplicaciones en la categoría
de ASF a través de la web de soporte. Para el resto de entornos (validación, producción, etc.) se incluye dicha
información en la ficha de entrega.
La información que se ha de incluir en la solicitud es la siguiente:

- operación: WSS - seguridad servicio web
- aplicación: Nombre de aplicación que se desea dar de alta en ASF
- certificado de servidor a utilizar: Indicar qué certificado de servidor se desea utilizar, o si se quiere
utilizar uno genérico.
A continuación se muestra un ejemplo de solicitud:
31 de 106
Framework Atlas
Ejemplo de solicitud a la Unidad de Arquitectura de Aplicaciones

Operacion: WSS - seguridad servicio web
Aplicacion: EJPL_WS_SERVIDOR
Certificado de servidor: certificado genérico
Como respuesta a la solicitud, la Unidad de Arquitectura de Aplicaciones contestará con un mensaje como este:
Ejemplo de respuesta de la Unidad de Arquitectura de Aplicaciones

Se han realizado actuaciones en la plataforma ASF 5.0 para definir servidor y cliente del alta solicitada para el
módulo "EJPL_WS_SERVIDOR".
Los datos para configurar los desarrollos son los siguientes:
- SERVIDOR
> ID de aplicación ASF: EJPL_WS_SERVIDOR
> alias "localkey": servidor_ws
- CLIENTE
> ID de aplicación ASF: EJPL_WS_CLIENTE
> alias "localkey": cliente_ws
> alias "remotekey": servidor_ws_cert
En la respuesta se mostrarán los datos de configuración necesarios para el servicio web (apartado SERVIDOR) y
para las pruebas unitarias del cliente en el módulo lib (apartado CLIENTE).
Una vez que se ha dado de alta en ASF y con los de SERVIDOR tenemos que incluir en el fichero
src/main/resources/environment.properties lo siguiente:
src/main/resources/environment.properties
# Ids de aplicacion
app.id.asf=EJPL_WS_SERVIDOR
# Parametros de WS
miPrimerService.localKey=servidor_ws
El valor de la variable app.id.asf es el identificador de la aplicación en la plataforma ASF (debe ser igual que la
aplicación dada de alta en ASF). Este dato se corresponde con el ID de aplicación en el apartado SERVIDOR de la
respuesta de la Unidad de Arquitectura de Aplicaciones.
Es necesario crear una variable con la siguiente nomenclatura <nombreServicio>.localKey con el valor del alias
“localkey” proporcionado (alias del certificado con el que se va a firmar la respuesta). Ejpl:
miPrimerService.localkey.
32 de 106
Framework Atlas
ATENCION
Recordar que cada vez que se modifica el valor de una variable en el fichero
src/main/resources/environment.properties es necesario también modificar todos los ficheros
war/(nombreEntorno)/environment.properties.
Para asociar una política de seguridad para un servicio web determinado, hay que incluir una serie de líneas dentro
del tag <service> asociado al servicio en el fichero services.xml. En un fichero services.xml podrá haber servicios
seguros y servicios no seguros conviviendo sin problemas.
Como hemos dicho hay dos políticas por lo tanto dos configuraciones distintas a incluir dependiendo de cual se
elija:
33 de 106
Framework Atlas
Servicio con politicaWSSFirmado

<service name="MiServicioWebWSSecurity1">
</parameter>
<parameter name="SpringBeanName" locked="false">miPrimerService</parameter>
<parameter name="ServiceClass" locked="false">
prueba123.services.MiPrimerService
</parameter>
<messageReceivers>
</messageReceivers>
<module ref="atlasfrm-clientews-seguridad" />

<wsp:Policy wsu:Id="politicaWSSFirmado"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:AsymmetricBinding
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
<wsp:Policy>
<sp:RequireThumbprintReference />
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
<wsp:Policy>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:TripleDesRsa15 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
34 de 106
Framework Atlas
<sp:SignedParts
<sp:Body/>
</sp:SignedParts>
<atlas:ASFConfig xmlns:atlas="http://atlas.madrid.org/security/policy">
<atlas:invokingApp>${app.id.asf}</atlas:invokingApp>
<atlas:operationMode>server</atlas:operationMode>
<atlas:localKey>${miPrimerService.localKey}</atlas:localKey>
<sp:Wss10
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
</wsp:Policy>
</sp:Wss10>
<atlas:wsuTsLife>300000</atlas:wsuTsLife>
</atlas:ASFConfig>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</service>
Servicio con politicaWSSFirmadoCifrado
35 de 106
Framework Atlas
<service name="MiServicioWebWSSecurity1">
</parameter>
<parameter name="SpringBeanName" locked="false">miPrimerService</parameter>
<parameter name="ServiceClass" locked="false">
prueba123.services.MiPrimerService
</parameter>
<messageReceivers>
</messageReceivers>

<wsp:Policy wsu:Id="politicaWSSFirmadoCifrado"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:AsymmetricBinding
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
<wsp:Policy>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
<wsp:Policy>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:TripleDesRsa15 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
36 de 106
Framework Atlas
<sp:SignedParts
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts
<sp:Body/>
</sp:EncryptedParts>
<atlas:ASFConfig xmlns:atlas="http://atlas.madrid.org/security/policy">
<atlas:invokingApp>${app.id.asf}</atlas:invokingApp>
<atlas:operationMode>server</atlas:operationMode>
<atlas:localKey>${miPrimerService.localKey}</atlas:localKey>
<sp:Wss10
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
</wsp:Policy>
</sp:Wss10>
<atlas:wsuTsLife>300000</atlas:wsuTsLife>
</atlas:ASFConfig>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</service>
La variable incluida en amarillo es la única que hay que configurar. El resto es igual para todos los servicios que
necesiten esta politica de firma y cifrado. Se ha de poner el nombre de la variable incluida en el fichero
enviroment.properties.
Aunque en el listado anterior se han incluido las variables de configuración básicas, si se necesita una
configuración avanzada puede utilizarse cualquiera de las variables definidas en la siguiente tabla:
Propiedad Descripción Valor
invokingApp Nombre de la aplicación en ASF 5. Parámetro Ej: EJPL_WS_SERVIDOR

obligatorio.
operationMode Modo de operación del módulo de seguridad. Solo se Ej: server

admiten dos valores: client o server. Parámetro
obligatorio.
localKey Nombre del certificado propio a usar en la Ej: servidor_ws

comunicación segura. Parámetro obligatorio.
Este certificado se utilizará para las operaciones de
firmado del mensaje de petición y desencriptado del
mensaje de respuesta.
wsuTsLife Tiempo de validez del mensaje en milisegundos. Ej: 300000 (5 minutos)
signatureOperation Nombre de la operación en ASF para el firmado digital Por defecto:

del mensaje. Parámetro no obligatorio. Será
FIRMA_SIMPLE
comunicado en la respuesta a la solicitud en ASF si es
necesario configurarlo
37 de 106
Framework Atlas
encryptionOperation Nombre de la operación en ASF para el cifrado del Por defecto: CIFRADO
mensaje. Parámetro no obligatorio. Será comunicado
en la respuesta a la solicitud en ASF si es necesario
configurarlo
decryptionOperation Nombre de la operación en ASF para el descifrado del Por defecto:

mensaje. Parámetro no obligatorio. Será comunicado
DESCIFRADO
en la respuesta a la solicitud en ASF si es necesario
configurarlo
validationOperation Nombre de la operación en ASF para la validación de Por defecto:

la firma de un mensaje. Parámetro no obligatorio. Será
VERIFICACION
comunicado en la respuesta a la solicitud en ASF si es
necesario configurarlo
applySecurityOnFault Por defecto se aplica la seguridad configurada a todos Por defecto: true
los mensajes del servicio. En algunos casos (red
SARA) es necesario no aplicar seguridad a los
mensajes que generan un <soap:fault>. Si se desea
este comportamiento se debe configurar un valor „false‟
en este parámetro
AtlasSecuredWSClient: esta clase es la utilizada para servidores con seguridad a nivel de mensaje a
través de WS-Security
Por lo tanto, nuestra interfaz en vez de extender de AtlasUnsecuredWSClient, extenderá de AtlasSecuredWSClient,

por ejemplo así:
38 de 106
Framework Atlas
package prueba123.client;
import prueba123.services.MiPrimerService;
import atlas.clientews.client.AtlasSecuredWSClient;
public class ClienteMiPrimerServiceWSS1 extends AtlasSecuredWSClient implements

MiPrimerService{
public ClienteMiPrimerServiceWSS1(String endpoint) {

}
/** Propiedades */
@Override

}
/**
*/
}
}
4.4. CREACIÓN DE UN SERVIDOR CON WS-SECURITY + CERTIFICADO DE CLIENTE
En caso de tener que realizar un servidor con seguridad a nivel de mensaje + seguridad a nivel de transporte
concertificado de cliente.
La configuración de este tipo de servicio web es la misma que la del punto anterior (Servidor con WS-Security) solo
que añadiremos también el módulo de seguridad.
ATENCION
Este apartado describe la configuración para un servidor con seguridad a nivel de mensaje y a
nivel de transporte con certificado de cliente.
En caso de la seguridad a nivel de transporte es a través de certificado de cliente, el servidor
verificará los clientes conectados.
Si no se va a comprobar los clientes conectados (si no se requiere esta validación) basta con
seguir los pasos del punto anterior:
39 de 106
Framework Atlas
Una vez seguidos los pasos del punto anterior, añadir al fichero services.xml las siguientes líneas, de tal manera
que el fichero services.xml quedaría así:
services.xml
[...]
<service name="EjemploServicioSeguroFirmadoHttps">
[...]
<parameter name="asfInvokingApp">${app.id.asf}</parameter>
<transports>
</transports>
<module ref="atlasfrm-clientews-seguridad-https" />
<wsp:Policy wsu:Id="politicaWSSFirmado" ...>

[...]
<sp:SignedParts xmlns:sp="...">
<sp:Body/>
</sp:SignedParts>
[...]
</wsp:Policy>
</service>
[...]
AtlasSecuredWSClient: esta clase es la utilizada para servidores con seguridad a nivel de mensaje a
través de WS-Security + Seguridad de transporte con certificado de cliente
40 de 106
Framework Atlas
Por lo tanto, nuestra interfaz en vez de extender de AtlasUnsecuredWSClient, extenderá de AtlasSecuredWSClient,

por ejemplo así:
package prueba123.client;
import prueba123.services.MiPrimerService;
import atlas.clientews.client.AtlasSecuredWSClient;
public class ClienteMiPrimerServiceWSS1 extends AtlasSecuredWSClient implements

MiPrimerService{
public ClienteMiPrimerServiceWSS1(String endpoint) {

}
/** Propiedades */
@Override

}
/**
*/
}
}
41 de 106
Framework Atlas
5. DESARROLLO DE UN SERVICIO WEB (CLIENTE)
En este documento se diferencian dos formas de acceder a un servicio web. Si queremos acceder a un servicio
web creado con ATLAS, es mucho más fácil ya que al crear el servicio web se generó una librería preparada para
usarla desde la parte cliente. Si no se trata de un servicio web creado con ATLAS, entonces se tendrá que partir
del fichero WSDL que describe el servicio web, y generar las clases a partir de éste.
5.1. ATLAS - CREACION DE UN CLIENTE (HTTP y HTTPS SIN CERTIFICADO CLIENTE)
Para usar un servicio web creado con ATLAS debemos disponer de la librería que se generó junto con el
servicio web. A continuación se describen los pasos para incorporar dicha librería en nuestro proyecto y definir las
propiedades de conexión al servicio web.
5.1.1. Paso 1: Inclusión de la dependencia
Para usar la librería generada en nuestro proyecto, será necesario realizar la inclusión de esta dependencia en el
fichero pom.xml, según se muestra a continuación:
ejemplo de inclusión de dependencia en pom.xml de proyecto
<dependencies>
[...]
<dependency>
<groupId>xxxx</groupId>
<artifactId>xxxx_ws_lib</artifactId>
<version>y.y.y</version>
</dependency>
[...]
</dependencies>
Los valores de las distintas variables nos los deben proporcionar los responsables de dicha librería.
5.1.2. Paso 2: Configuración del contexto de Spring
Para usar la librería correctamente debemos modificar el fichero de configuración de Spring de nuestro proyecto
denominado applicationContext-services.xml, incluyendo la línea que importa el fichero de contexto de la librería
(modificar xxxx_ws_lib por el nombre del fichero de contexto que aparece dentro de la librería):
applicationContext-services.xml de proyecto
<beans>
[...]


<import resource="classpath:/conf/applicationContext-xxxx_ws_lib.xml" />
[...]
42 de 106
Framework Atlas
5.1.3. Paso 3: Configuración del endpoint en environment.properties
El último paso para configurar la URL de conexión al servicio web es definir una nueva variable en el fichero
src/main/resources/environment.properties de nuestra aplicación, según se muestra a continuación:
src/main/resources/environment.properties de proyecto
[...]
# Definición del endpoint del servicio MiServicioWeb

miPrimerService.endpoint=http://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb
[...]
Sustituir ejemplo_ws por el módulo técnino del web servce y MiServicioWeb por el nombre del servicio web al que
se llama.
ATENCION
Recordar que cada vez que se modifica el valor de una variable en el fichero
src/main/resources/environment.properties es necesario también modificar todos los ficheros
war/<nombreEntorno>/environment.properties para incluir la nueva variable.
43 de 106
Framework Atlas
5.2. ATLAS - CREACION DE UN CLIENTE CON VALIDACIÓN DE CERTIFICADO DE CLIENTE
Para realizar llamadas a un servicio web de atlas que dispone de seguridad a nivel de transporte con certificado de
cliente, es necesario realizar los siguientes pasos:
5.2.1. Paso 1: Añadir variables de environment

Para configurar nuestro cliente correctamente, tenemos que modificar el fichero
src/main/resources/environment.properties, incluyendo las líneas marcadas en amarillo en el siguiente ejemplo:
[...]
# Ids de aplicacion
app.id.asf=EJPL_WS_CLIENTE

miServicioWeb.endpoint=http://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb
https.keystore.path=<a rellenar por Paso a Producción>

https.keystore.pass=CA655C9BB562C317811001D666CFD99B
https.secure.port=443
[...]
Los valores de las variables son los siguientes:
Parámetro Descripcion Valor por defecto
app.id.asf Nombre de la aplicación en ASF Ej.: EJPL_WS_CLIENTE
[nombreServicio].endpoint URL del servicio Ej.:

https://desarrollo.madrid.org/<ejemplo_
ws>/services/<nombreServicio>
https.keystore.path Ruta al almacén de certificados con Ej.: ssl/keystore.keystore

el certificado de cliente de conexión
https.keystore.pass Contraseña de acceso al almacén Ej.: desarrollo

del certificado de cliente (configurar
cifrada)
https.secure.port Puerto seguro de conexión Ej.: 443
44 de 106
Framework Atlas
5.2.2. Paso 2: Configuración de Spring
Además es necesario modificar en el fichero de contexto de Spring del modulo lib (applicationcontext-
xxxx_ws_lib.xml) el bean del cliente para añadirles las propiedades relacionadas con la seguridad tal y como se
puede ver en este ejemplo:
applicationContext-xxxx_ws_lib.xml
<beans>
…
<bean id="miPrimerService" class="prueba123.client.ClienteMiPrimerService">
<constructor-arg value="${miPrimerService.endpoint}" />
<property name="properties">
<props>
<prop key="keyStorePath">${https.keystore.path}</prop>
<prop key="keyStorePassword">${https.keystore.pass}</prop>
<prop key="securePort">${https.secure.port}</prop>
</props>
</property>
</bean>
</beans>
El bloque marcado en amarillo tendrá que añadirse tal cual pero modificando los nombre de las variables:
El bloque marcado en amarillo tendrá que añadirse sin modificaciones a la definición del cliente. Y por último,
deberán añadirse al fichero environment.properties para los test unitarios las propiedades definidas en el
fichero de Spring para el servicio:
src/test/resources/environment.properties
# Ids de aplicacion
# Definición del endpoint del servicio EjemploServicioHttps

miServicioWeb.endpoint=https://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb

Obtención de los keyStores
Ver el apartado “7.- Obtención de los keystores” para ver como obtener
y configurar los keystores de la aplciación
45 de 106
Framework Atlas
Las variables a configurar son:



cifrada)
46 de 106
Framework Atlas
5.3. ATLAS - CREACION DE UN CLIENTE CON SEGURIDAD EN MENSAJE WS-SECURITY
Para realizar llamadas a un servicio web de atlas que dispone de seguridad a nivel de mensaje, tenemos que
realizar las siguientes modificaciones en nuestro cliente.

Para configurar nuestro cliente para conectar con WS-Security tenemos que añadr el módulo de seguridad,
modificando el fichero src/main/resources/environment.properties, incluyendo las líneas marcadas en amarillo
en el siguiente ejemplo:
[...]
# Ids de aplicacion

miServicioWeb.localKey=cliente_ws
miServicioWeb.remoteKey=servidor_ws_cert
[...]
app.id.asf Nombre de la aplicación Ej.: EJPL_WS_CLIENTE

en ASF

http://desarrollo.madrid.org/ejempl
o_ws/services/MiServicioWeb
[nombreServicio].localKey Alias de la clave del cliente Ej.: cliente_ws

usada para firmar el
mensaje. Se corresponde
con el alias del certificado
dado de alta en asf para la
operación de firma.
47 de 106
Framework Atlas
[nombreServicio].remoteKey Alias del certificado del Ej.: servidor_ws_cert

servidor utilizado para
cifrar el mensaje. Se
corresponde con el alias
del certificado dado de alta
en asf para la operación
de firma.
<beans>
…
<props>
<prop key="policyPath">META-INF/politicaWSSFirmado.xml</prop>
<prop key="invokingApp">${app.id.asf}</prop>
<prop key="operationMode">client</prop>
<prop key="localKey">${miPrimerService.localKey}</prop>
<prop key="remoteKey">${miPrimerService.remoteKey}</prop>
<prop key="wsuTsLife">300000</prop>
</props>
</property>
</bean>
</beans>
En el campo policyPath se ha de indicar el fichero de politica de firma:

Sustituir las siguientes variables por las correspondientes de nuestro servicio.

- miServicioWeb.localKey
- miServicioWeb.remoteKey.
El siguiente paso es definir las propiedades de ASF indicadas para el CLIENTE en el fichero de configuración del
módulo lib para poder hacer las pruebas con los Test Unitarios.
48 de 106
Framework Atlas
Fichero lib/src/test/resources/environment.properties
[...]
# Ids de aplicacion
app.id.asf= ejpl_ws_cliente
# Datos de WS
miPrimerService.localKey=cliente_ws
miPrimerService.remoteKey=servidor_ws_cert
[...]
En amarillo se han marcado las nuevas variables que se han de incluir.
A continuación se describen cada una de las variables:

http://localhost:9080/services/
<nombreServicio>
[nombreServicio].localKey Alias de la clave del cliente usada para Ej.: cliente_ws

firmar el mensaje. Se corresponde con el
alias del certificado dado de alta en asf para
la operación de firma.
[nombreServicio].remoteKey Alias del certificado del servidor utilizado Ej.: servidor_ws_cert

para cifrar el mensaje. Se corresponde con
el alias del certificado dado de alta en asf
para la operación de firma.
49 de 106
Framework Atlas
5.4. ATLAS - CREACION DE UN CLIENTE CON WS-SECURITY + CERTIFICADO DE CLIENTE
Para realizar llamadas a un servicio web de atlas que dispone de seguridad a nivel de mensaje más seguridad a
nivel de transporte con certificado de cliente, tenemos que realizar las siguientes modificaciones en nuestro cliente.
ATENCION
Esta configuración de cliente es solo para Servicios Web ATLAS que dispongan de seguridad
tanto a nivel de mensaje como a nivel de transporte CON certificado de cliente.
En caso de no tener que certificar nuestro acceso con un certificado, seguir los pasos del punto
anterior.

Para configurar nuestro cliente para conectar con WS-Security tenemos que añadr el módulo de seguridad,
modificando el fichero src/main/resources/environment.properties, incluyendo las líneas marcadas en amarillo
en el siguiente ejemplo:
[...]
# Ids de aplicacion


[...]
50 de 106
Framework Atlas
app.id.asf Nombre de la aplicación Ej.: EJPL_WS_CLIENTE

en ASF

http://desarrollo.madrid.org/ejempl
o_ws/services/MiServicioWeb

usada para firmar el
mensaje. Se corresponde
con el alias del certificado
dado de alta en asf para la
operación de firma.
[nombreServicio].remoteKey Alias del certificado del Ej.: servidor_ws_cert

servidor utilizado para
cifrar el mensaje. Se
corresponde con el alias
del certificado dado de alta
en asf para la operación
de firma.
https.keystore.path Ruta al almacén de Ej.: ssl/keystore.keystore

certificados con el
certificado de cliente de
conexión
https.keystore.pass Contraseña de acceso al Ej.: desarrollo

almacén del certificado de
cliente (configurar cifrada)
51 de 106
Framework Atlas
<beans>
…
<props>
<prop key="policyPath">META-INF/politicaWSSFirmado.xml</prop>
<prop key="localKey">${miPrimerService.localKey}</prop>
<prop key="remoteKey">${miPrimerService.remoteKey}</prop>
</props>
</property>
</bean>
</beans>
En el campo policyPath se ha de indicar el fichero de politica de firma:


El siguiente paso es definir las propiedades de ASF indicadas para el CLIENTE en el fichero de configuración del
módulo lib para poder hacer las pruebas con los Test Unitarios.
52 de 106
Framework Atlas
Fichero lib/src/test/resources/environment.properties
[...]
# Ids de aplicacion
app.id.asf= ejpl_ws_cliente
# Datos de WS
miPrimerService.localKey=cliente_ws
miPrimerService.remoteKey=servidor_ws_cert

[...]
En amarillo se han marcado las nuevas variables que se han de incluir.
A continuación se describen cada una de las variables:

http://localhost:9080/services/
<nombreServicio>
[nombreServicio].localKey Alias de la clave del cliente usada para Ej.: cliente_ws

firmar el mensaje. Se corresponde con el
alias del certificado dado de alta en asf para
la operación de firma.
[nombreServicio].remoteKey Alias del certificado del servidor utilizado Ej.: servidor_ws_cert

para cifrar el mensaje. Se corresponde con
el alias del certificado dado de alta en asf
para la operación de firma.
https.keystore.path Ruta al almacén de certificados con el Ej.: ssl/keystore.keystore

certificado de cliente de conexión
53 de 106
Framework Atlas
https.keystore.pass Contraseña de acceso al almacén del Ej.: desarrollo

certificado de cliente (configurar cifrada)
54 de 106
Framework Atlas
5.5. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP y HTTPS)
Cuando se necesite conectar a un servicio web externo, se utilizarán los siguientes pasos para la creación de un
cliente de servicio web. Los clientes de servicio web NO ATLAS se caracterizan por ser de código generado a partir
de un descriptor WSDL. A diferencia del cliente de servicio web ATLAS, este cliente debe generarse en cada
proyecto en que se quiera establecer comunicación con un servicio web. Para generar un cliente a partir de un
fichero WSDL será necesario hacer uso del módulo maven de ATLAS llamado altasfrm-clientews-wsdl2code-
maven-plugin.
ATENCION
Este tipo de cliente de servicio web, es para los clientes que no requieran seguridad a nivel de
mensaje ni seguridad a nivel de transporte con certificado de cliente.
Esta configuración es apta tanto para HTTP como para HTTPS. Siempre y cuando el transporte
NO requiera certificado de cliente.
5.5.1. Paso 1: Incluir fichero wsdl en el proyecto
El fichero wsdl que nos hayan proporcionado hay que incluirlo en el proyecto en la carpeta
src/main/resources/wsdl. Del módulo lib del arquetipo generado
5.5.2. Paso 2: Inclusión de la dependencia y configuración del plugin
Añadir en la siguiente dependencia en el fichero pom.xml (del modulo lib) del proyecto donde se vaya a generar el
cliente compilado:
pom.xml
<dependency>
<groupId>atlasfrm</groupId>
<artifactId>atlasfrm-clientews-lib</artifactId>
<version>${atlasfrm-clientews-lib.version}</version>
<scope>provided</scope>
</dependency>
Dentro de la sección de plugins del fichero pom.xml de nuestro proyecto es necesario incluir el plugin de Maven
atlasfrm-clientews-wsdl2code-maven-plugin. Este plugin generará tanto las clases de cliente del webservice
como las clases de tests para las pruebas contra dicho servicio. A continuación se muestra un ejemplo de
configuración del plugin:
pom.xml (módulo lib)
55 de 106
Framework Atlas

<plugin>
<artifactId>atlasfrm-clientews-wsdl2code-maven-plugin</artifactId>
<version>${atlasfrm-clientews-wsdl2code-plugin.version}</version>
<configuration>
<packageName>xxxx.ws.client</packageName>
<serviceNameAsPackage>true</serviceNameAsPackage>
<overWrite>false</overWrite>
</configuration>
<executions>
<execution>
<id>yyyyyService</id>
<configuration>
<wsdlFile>src/main/resources/wsdl/yyyyyService.wsdl</wsdlFile>
</configuration>
<goals>
<goal>wsdl2code</goal>
</goals>
</execution>
</executions>
</plugin>
ATENCION
Si se ha partido de uno de los arquetipos de Atlas, el plugin se encuentra comentado en el

fichero pom.xml del arquetipo, sólo será necesario descomentarlo.
Según la configuración anterior a partir del fichero yyyyyService.wsdl se generarán las clases cliente del servicio
yyyyyService en el directorio src/main/java en el paquete xxxx.ws.client.yyyyyService (suponiendo que
yyyyyService sea el nombre del servicio). También se generará un fichero applicationContext-
yyyyyService.xml en el directorio src/main/resources, para que el cliente esté dado de alta en el contexto de
Spring. Puede ser necesario incluir manualmente en los configLocations del fichero web.xml este nuevo archivo
de definiciones.
Además se generarán los test unitarios del servicio en el directorio src/test/java, en el mismo paquete en que se
han generado las clases del cliente. El test unitario contendrá el fichero de definiciones de Spring creado para el
servicio.
En caso de tener que generar varios clientes de servicio web, se deberán generarse tantos tags <execution>
como clientes deban generarse, cada uno con su configuración.
Los parámetros que se pueden configurar en este plugin son, además de los propios del plugin wsdl2code-
maven-plugin (y que podemos encontrar descrita en la siguiente url: http://ws.apache.org/axis2/tools/1_4/maven-
plugins/maven-wsdl2code-plugin.html), los incluidos en la siguiente tabla:
56 de 106
Framework Atlas
Propiedad Descripción Valor
wsdlFile Esta etiqueta indica la ruta dentro del Ej:

proyecto al fichero de descripción del servicio
src/main/resources/wsdl/xxxx_ws.
web del que se va a generar el cliente.
wsdl
Por defecto:
src/main/resources/rservice.wsdl
packageName Nombre del paquete base donde se Ej: xxxx.ws.client

generarán las clases java del cliente de
servicio web (en src/main/java)
serviceNameAsPackage Si es „true‟ se añadirá el nombre del servicio Por defecto: true

como paquete al final de packageName. El
nombre del servicio se modificará para
cumplir la normativa de nomenclatura de
paquetes.
overWrite Si es „false‟ se comprueba si ya existe el Por defecto: false

fichero y en caso afirmativo, no se generará
de nuevo. Se recomienda siempre este valor
para que los ficheros se generen solo una
vez y no se pierdan modificaciones manuales
en las clases generadas.
skipGeneratioin Si es „true‟ el plugin no intentará generar Por defecto: false

ningún cliente. Se recomienda usar este
parámetro cuando se modifiquen los nombres
de los ficheros generados, de lo contrario se
generarán ficheros nuevos con los nombres
originales.
outputDirectory Directorio de fuentes donde se generarán las Por defecto: src/main/java

clases del cliente de servicio web
resourceOutputDirectory Directorio de recursos donde se generarán Por defecto:

los ficheros de spring del cliente.
src/main/resources/conf
testOutputDirectory Directorio de fuentes donde se generarán los Por defecto: src/test/java

tests unitarios
testResourceOutputDirec Directorio de recursos de test donde se Por defecto:

generarán los ficheros de configuración de
tory src/test/resources/conf
Spring necesarios (si los hubiere)
syncMode Modo de conexión al webservice Por defecto: sync (síncrono)
generateTestcase Indica si generar o no una clase de test para Por defecto: true
el cliente de webservice.
unpackClasses Genera las clases en distintos ficheros Por defecto: true
generateServerSideInterf Genera el intefaz java del servicio web Por defecto: true
ace
57 de 106
Framework Atlas
unwrap Desempaqueta los parámetros de entrada y Por defecto: true

salida de los métodos del webservice
namespaceToPackages Lista de Namespaces del fichero WSDL Por defecto: todas las clases se
relacionandolos con nombres de paquete generan en el mismo paquete
para generar en estas ubicaciones los datos del cliente del servicio web.
asociados a cada Namespace.
Una vez que este plugin está configurado se puede pasar a la generación de las clases del cliente del servicio web.
5.5.3. Paso 3: Generación de la clases del Cliente
La generación a partir del plugin atlas-wsdl2code-maven-plugin se basa en el documento WSDL para generar el
cliente. A continuación de muestra un ejemplo de generación en el módulo lib para el servicio MiServicioWeb. La
configuración del plugin es:
pom.xml
<plugin>
<configuration>
<packageName>prueba123.ws.client</packageName>
</configuration>
<executions>
<execution>
<id>miPrimerService</id>
<configuration>
<wsdlFile>src/main/resources/wsdl/miPrimerService.wsdl</wsdlFile>
</configuration>
<goals>
</goals>
</execution>
</executions>
</plugin>
Para que se generen las clases del cliente simplemente hay que compilar el proyecto. Para que las clases
generadas aparezcan en Eclipse es necesario refrescar el proyecto.
A continuación se muestra un ejemplo de los ficheros generados para el servicio MiServicioWeb:
58 de 106
Framework Atlas
Clases del cliente generadas en src/main/java:

Paquete base: xxxx.ws.client
Nombre del Servicio: MiServicioWeb
Nombre de servicio como paquete: Si
Interfaz del servicio: MiServicioWeb.java
Implementación del cliente:
MiServicioWebStub.java
Mapeo de datos:paquete .domain.
Configuración de Spring generada en

src/main/resources:
Configuración de Spring:
applicationContext-MiServicioWeb.xml
Clases de test generadas en src/test/java:

Test unitario: MiServicioWebTest.java
Una vez generadas las clases del cliente, el fichero de Spring y el test unitario, habrá que editar este último para
proporcionar datos para las llamadas que reciban parámetros. Si no se modifica el fichero de test para añadir estos
datos, el test unitario fallará. En cada método de test en que sea necesario aportar datos para hacer la llamada, se
generará un comentario como el siguiente para indicar el sitio donde introducir estos:
TestCase.java
// TODO : Rellenar aquí los valores de xxxxxxxxxxxxxx
// El test unitario no ejecutara correctamente hasta que no se
// rellenen valores correctos
Es importante revisar los ficheros de contexto de String incluidos en el test a ver si son los correspondientes a los
de la aplicación en la que se está generando el cliente para ver si son los correctos y en su caso modificarlos para
que funcione correctamente.
59 de 106
Framework Atlas
5.5.4. Paso 4: Configuración y uso del Cliente
En este apartado se demostrará el uso del cliente generado. Se utilizará como ejemplo el cliente del servicio
MiServicioWeb generado en apartados anteriores.
ATENCION
Esta configuración, es para clientes que necesiten conectarse a un servicio web no altas
(externo) mediante:
HTTP
HTTPS sin certificado de cliente.
El certificado del servidor para los transportes HTTPS se encuentra en los almacenes de
confianza utilizados por ICM. En caso de que el servidor al que queramos conectar disponga de
un certificado que ICM no contempla, pedid a la unidad de arquitectura la incorporación de dicho
certificado a su almacen.
La primera modificación que habrá que hacer al código generado será parametrizar el endpoint por defecto en el
fichero „environment.properties‟ (marcado en amarillo). Para ello habrá de consultarse el fichero de Spring
generado para el servicio. En los comentarios de la definición de este servicio se indicará que variable ha de darse
de alta:

<bean id="miServicioWeb" class="atlas.clientews.client.ClientFactory" ...>
<constructor-arg value="atlas.ws...MiServicioWebStub" />
<constructor-arg type="..." value="${miServicioWeb.endpoint}" />
</bean>
environment.properties del módulo donde se usará el cliente

[...]
# Endpoints de webservice
miPrimerService.endpoint=http://desarrollo.madrid.org/ejemplo_ws/services/MiServicioWeb
Sustituir ejemplo_ws por el módulo técnino del web servce y MiServicioWeb por el nombre del servicio web al que
se llama.
ATENCIÓN
60 de 106
Framework Atlas
Es OBLIGATORIO parametrizar el endpoint de servicio en los ficheros environment.properties,

independientemente del valor que figure en el descriptor WSDL a partir del que se ha creado el cliente.
Los parámetros „endpoint’ han de crearse en TODOS los ficheros environment.properties del proyecto donde se
usará la librería cliente, aunque no se sepan las URLs en los distintos entornos.
A continuación se ha de incluir la definición del invocador en el contexto de Spring en el proyecto donde se hará
uso de la librería cliente. La forma recomendada de cargar el fichero de Spring es mediante una sentencia include
en el fichero de servicios.
applicationContext-services.xml
<beans>
<import resource="applicationContext-MiServicioWeb.xml"/>




[...]
</beans>
En este mismo fichero applicationContext-services.xml están las definiciones de los servicios del proyecto. Debe
añadirse la dependencia como se haría con cualquier otro servicio del proyecto. Una vez añadida, podrán
implementarse métodos de uso en esta que utilicen el invocador creado.
applicationContext-services.xml
<beans>
<import resource="applicationContext-MiServicioWeb.xml"/>



<bean id="miServicio" class="atlasfrm...services.MiServicioImpl"
p:miServicioWeb-ref="MiServicioWeb"
/>
[...]
</beans>
MiServicioImpl.java
61 de 106
Framework Atlas
@Service
public class MiServicioImpl implements MiServicio {
private MiServicioWeb miServicioWeb;
public void setMiServicioWeb(MiServicioWeb miServicioWeb) {

this.miServiciWeb = miServicioWeb;
}
/**
* Llamada al WS de Ejemplo
* @return String
*/
public String getFechaString() throws java.lang.Exception {
String result = miServicioWeb.getFechaString();
// Imprimir el resultado si se necesita comprobacion visual (solo en test)

System.out.println("Resultado de la llamada: " + result);
assertNotNull(result);
return null;
ATENCION
Para simplificar el uso de clientes compilados, estos pueden ser inyectados en un servicio si
requieren de lógicas de proceso y manipulación de los objetos del cliente compilado (objeto
DatosEntrada en el ejemplo anterior).
62 de 106
Framework Atlas
5.6. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON CERTIFICADO DE CLIENTE
En ocasiones necesitaremos la creación de un cliente de servicio web que conecte con el servidor externo usando
un certificado de cliente. Esto significa que el servidor, comprobará los clientes que se conecten a través de
HTTPS, y requerirá un certificado al cliente que verificará si es correcto o no.
En este apartado se demostrará el uso del cliente generado. Se utilizará como ejemplo el cliente del servicio
MiServicioWeb generado en apartados anteriores.
ATENCION
(externo) mediante:
HTTPS con certificado de cliente.
La seguridad a nivel de transporte (HTTPS) puede llevar o no verificación de cliente.
Esto significa que los clientes que conectan al servicio web requieren de un certificado que el
servidor comprobará.
Esta configuración es solo para los casos descritos, si se necesita un cliente de servicio web con
seguridad a nivel de transporte (HTTPS) sin certificado de cliente, consultar el punto anterior:
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE (HTTP y HTTPS SIN
CERTIFICADO CLIENTE)
La primera modificación que habrá que hacer al código generado será parametrizar el endpoint por defecto en el
fichero „environment.properties‟ (marcado en amarillo). Para ello habrá de consultarse el fichero de Spring
generado para el servicio. En los comentarios de la definición de este servicio se indicará que variable ha de darse
de alta:
applicationContext-MiServicioWebHttps.xml
<beans>
[...]
<bean id="MiServicioWebHttps" class="atlas.clientews.client.HttpsClientFactory">
<constructor-arg value="ejpl.services.MiServicioWebHttpsStub" />
<constructor-arg type="java.lang.String" value="${miServicioWebHttps.endpoint}" />
</bean>
[...]
</beans>
63 de 106
Framework Atlas
Además de este cambio, también tendrán que definirse las credenciales de seguridad, especificando donde se
encuentra nuestro certificado de cliente:
applicationContext-EjemploServicioHttps.xml
<beans>
[...]
<bean id="MiServicioWebHttps" class="atlas.clientews.client.HttpsClientFactory">
<constructor-arg value="ejpl.services.MiServicioWebHttpsStub" />
<constructor-arg type="java.lang.String" value="${MiServicioWebHttps.endpoint}" />
<props>
</props>
</property>
</bean>
[...]
</beans>
deberán añadirse al fichero environment.properties las propiedades definidas en el fichero de Spring para el
servicio:
# Ids de aplicacion


ATENCION
Los valores de los parametros de contraseñas (https.keystore.pass) han de ser cifrados antes
de configurarlos en el fichero environment.properties.

64 de 106
Framework Atlas


cifrada)
5.7. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY
Para la creación de un cliente de servicio web con seguridad a nivel de mensaje, utilizaremos WS-Security, cuya
configuración es sencilla.
ATENCION
(externo) mediante:
HTTP + seguridad a nivel de mensaje WS-Security Firmado o Firmado y Cifrado
HTTPS sin certificado de cliente + seguridad a nivel de mensaje WS-Security Firmado o
Firmado y Cifrado
La seguridad a nivel de mensaje significa que el canal (el transporte) puede ser o no seguro, en
ambos casos, si no requiere de certificado de cliente, no hay que configurar nada más que los
siguientes pasos, es decir, solo hay que configurar la seguridad WS-Security, tanto como si el
canal es HTTP como HTTPS
applicationContext-EjemploServicioSeguro.xml
65 de 106
Framework Atlas
<beans>
[...]
<bean id="miServicioWeb" class="atlas.clientews.client.SecureClientFactory">
<constructor-arg value="ejpl.services.MiServicioWebStub" />
<constructor-arg type="java.lang.String" value="${miServicioWeb.endpoint}" />
[...]
</beans>
Además de este cambio, también tendrán que definirse las credenciales de seguridad:
applicationContext-.xml
<beans>
[...]
<bean id=" miServicioWeb " class="atlas.clientews.client.SecureClientFactory">

<constructor-arg index="0" value="ejpl.services. MiServicioWebStub " />
<constructor-arg index="1" type="java.lang.String"
value="${ miServicioWeb.endpoint}" />
<constructor-arg index="2" value="ejpl_ws_lib” ></constructor-arg>
<constructor-arg index="3" value="META-INF/politicaWSSFirmadoCifrado.xml" />
<props>
<prop key="localKey">${miServicioWeb.localKey}</prop>
<prop key="remoteKey">${miServicioWeb.remoteKey}</prop>
</props>
</property>
</bean>
[...]
</beans>
ATENCION
El bloque marcado en azul dispone de un value (constructor-arg index=”2”) que no se encuentra

en el enviroment.properties, su valor ha de ser el nombre del módulo lib de nuestro proyecto
(artifactId del módulo lib), por ejemplo ejpl_ws_lib. Este es necesario para que el plugin de
maven de tomcat sepa diferenciar entre los módulos .mar de un jar y los módulos del jar de
nuestro proyecto. Este comportamiento es diferente utilizando el plugin de maven de jetty
(anteriormente se enviaba “null” o “./META-INF/modules”), pero si utilizamos tomcat7:run es
necesario incluir el valor indicado.
En el campo index=”3” se ha de indicar el fichero de política de firma:

66 de 106
Framework Atlas

Y por último, deberán añadirse al fichero environment.properties las propiedades definidas en el fichero de
Spring para el servicio:
# Ids de aplicacion
# Datos de WS
miServicioWeb.endpoint=http://localhost:9080/services/MiServicioWeb

http://localhost:9080/services/<nombr
eServicio>
[nombreServicio].remoteKey Alias del certificado del servicio Ej.: servidor_ws_cert
ATENCION
Para poder incluir WS en un cliente de un servicio web es necesario previamente dar de alta la aplicación en ASF
tal y como se describe en el apartado 3.2 Los valores de localKey y remoteKey serán los alias de los certificados
asociados a la aplicación en ASF.
5.8. WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD WS-SECURITY +

CERTIFICADO DE CLIENTE
Para la creación de un cliente de servicio web con seguridad a nivel de mensaje, utilizaremos WS-Security,
además si el servidor requiere certificado de cliente, añadiremos también la configuración para el canal HTTPS con
certificado.
67 de 106
Framework Atlas
ATENCION
(externo) mediante:
HTTPS con certificado de cliente + seguridad a nivel de mensaje WS-Security Firmado o
Firmado y Cifrado
Esta configuración es seguridad a nivel de transporte con certificado de cliente y seguridad a
nivel de mensaje con WS-Security.
Debemos configurar ambas opciones de seguridad. Si el cliente que debemos realizar es con
seguridad a nivel de mensaje a través de canal seguro (HTTPS), debemos saber si el servidor
comprobará los clientes que intenten contectarse. Si el servidor acepta todas las conexiones
HTTPS, la configuración a elegir es la del punto anterior:
WS EXTERNOS (NO ATLAS) - CREACIÓN DE UN CLIENTE CON SEGURIDAD EN MENSAJE
WS-SECURITY
La configuración de WS-Secrurity es la misma que el punto anterior, solo que en la configuración de Spring,
realizaremos el siguiente cambio:
applicationContext-.xml
<beans>
[...]
<bean id=" miServicioWeb " class="atlas.clientews.client.SecureClientFactory">

<constructor-arg index="0" value="ejpl.services. MiServicioWebStub " />
<constructor-arg index="1" type="java.lang.String"
value="${ miServicioWeb.endpoint}" />
<constructor-arg index="2" value="ejpl_ws_lib” ></constructor-arg>
<constructor-arg index="3" value="META-INF/politicaWSSFirmadoCifrado.xml" />
<props>
<prop key="localKey">${miServicioWeb.localKey}</prop>
<prop key="remoteKey">${miServicioWeb.remoteKey}</prop>
</props>
</property>
</bean>
[...]
</beans>
68 de 106
Framework Atlas
deberán añadirse al fichero environment.properties las propiedades definidas en el fichero de Spring para el
servicio:
# Ids de aplicacion


69 de 106
Framework Atlas
6. CONFIGURACIONES ADICIONALES
En los siguientes apartados, se explica cómo agregar opciones extras en los servicios web si fuera necesario.
6.1.1. Añadir configuración de PROXY a un cliente
Es muy probable que para llamar a un servicio web externo sea necesaria la configuración del proxy para que
nuestro cliente pueda conectar a la URL indicada por el servidor.
El proxy solo será necesario para clientes NO atlas (generados a partir de WSDL) ya que para clientes atlas no es
necesario proxy.
Lo único que tenemos que hacer es añadir los siguientes parámetros en nuestra configuración de Spring del cliente
del servicio Web:

<bean id="miServicioWeb" class="atlas.clientews.client.ClientFactory" ...>
<constructor-arg value="atlas.ws...MiServicioWebStub" />
<constructor-arg type="..." value="${miServicioWeb.endpoint}" />
<props>
…
<prop key="proxy.activo">${http.proxyActivo}</prop>
<prop key="proxy.host">${http.proxyHost}</prop>
<prop key="proxy.port">${http.proxyPort}</prop>
<prop key="proxy.user">${http.proxyUser}</prop>
<prop key="proxy.password">${http.proxyPassword}</prop>
…
</props>
</property>
</bean>
ATENCION
La clase marcada en azul puede ser diferente dependiendo del cliente generado, en el ejemplo
es un cliente No seguro HTTP o HTTPS sin certificado de cliente, pero podría ser otro de los
casos descritos en el manual.
Tan solo tendremos que parametrizar la variables del proxy en el fichero „environment.properties‟, ingresar los
valores correctos para host, puerto, usuario y clave de acceso al proxy:
70 de 106
Framework Atlas
environment.properties del módulo donde se usará el cliente

[...]
#Propiedades del proxy
http.proxyActivo=true
http.proxyHost=icmupx01.madrid.org
http.proxyPort=80
http.proxyUser=prueba
http.proxyPassword=prueba
6.1.2. Personalizar configuración de TIMEOUT a un cliente
Para agregar un timeout a un cliente de un servicio web se deberá agregar dicho tiempo al constructor del stub del
servicio web. A continuación se muestra un ejemplo, las líneas que hay que agregar están resaltadas en color
amarillo, concretamente el método setTimeOutInMilliSeconds.
MiServicioImpl.java
71 de 106
Framework Atlas
@Service
public class MiServicioImpl implements MiServicio {
[. . .]
/**
* Constructor that takes in a configContext and useseperate listner
*/
public MiServicioWebStub(org.apache.axis2.context.ConfigurationContext
configurationContext, String targetEndpoint, boolean useSeparateListener)
throws org.apache.axis2.AxisFault {
//To populate AxisService
populateAxisService();
populateFaults();
_serviceClient = new
org.apache.axis2.client.ServiceClient(configurationContext,_service);
_serviceClient.getOptions().setTo(new org.apache.axis2.addressing.EndpointReference(
targetEndpoint));
_serviceClient.getOptions().setUseSeparateListener(useSeparateListener);
//Set the soap version

_serviceClient.getOptions().setSoapVersionURI(
org.apache.axiom.soap.SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI);
//El tiempo se establece en milisegudos, en este ejemplo se establece 5 minutos

int timeOutInMilliSeconds = 300000;
_serviceClient.getOptions().setTimeOutInMilliSeconds(timeOutInMilliSeconds);
[. . .]
6.1.3. Llamadas a Servicios Web Con Usuario y Password usando HHTP Basic
En caso de que dispongamos de la necesidad de llamar a un Servicio Web que requiere una autenticación de
usuario y password mediante transporte http Básico, con un cliente NO ATLAS, será necesario modificar el código
generado en nuestra clase Stub, de tal manera que al realizar la llamada al constructor desde Spring se incluya la
seguridad requerida.
Al crear el objeto con Spring, utilizamos el constructor ya autogenerado de 3 parámetros, endpoint, username y
password (obtenidos de nuestro enviroment.properties):
applicationContext(nombreWS)Service.xml
72 de 106
Framework Atlas
=============================================================================== -->
<bean id="SI_ConsultasGastos_OutService"
class="gtri.client.nexus.si_consultasgastos_outservice.SI_ConsultasGastos_OutServiceStub">
<constructor-arg type="java.lang.String"
value="${sI_ConsultasGastos_OutService.endpoint}" />
value="${sI_ConsultasGastos_OutService.username}" />
value="${sI_ConsultasGastos_OutService.password}" />
</bean>
Y en la clase autogenerada Stub, localizamos nuestro constructor
Clase autogenerada Stub

/**
*/
public SI_ConsultasGastos_OutServiceStub(java.lang.String targetEndpoint,
java.lang.String userName, java.lang.String password)
En este constructor, observaremos el siguiente código:

/**
*/
//Resto de codigo
_serviceClient.getOptions().setUserName(userName);
_serviceClient.getOptions().setPassword(password);
}
El cual, debe ser sustituido por lo siguiente para habilitar la autenticación Básica:
73 de 106
Framework Atlas
/**
*/
//Resto de codigo
HttpTransportProperties.Authenticator auth = new

HttpTransportProperties.Authenticator();
auth.setUsername(userName);
auth.setPassword(password);
ArrayList<String> authSchemes = new ArrayList<String>();
authSchemes.add(HttpTransportProperties.Authenticator.BASIC);
auth.setAuthSchemes(authSchemes);
auth.setPreemptiveAuthentication(true);
_serviceClient.getOptions().setProperty(HTTPConstants.CHUNKED, false);
_serviceClient.getOptions().setProperty(HTTPConstants.AUTHENTICATE,
auth);
}
6.1.4. Configuración de Truststore desde puesto LOCAL
Como ya hemos explicado en el resto de apartados, no se debe configurar en los clientes de Axis, tanto atlas como
externos, ningún almacén de confianza a la hora de llamar a los servicios web.
No obstante, esta configuración es sólo válida para los entornos de ICM (desarrollo, validación, producción, etc),
para el correcto funcionamiento en local, hay que seguir los siguientes pasos:
ATENCION
74 de 106
Framework Atlas
Por defecto, axis utiliza el almacén de la máquina virtual de java (cacerts) al ejecutarse. A partir
de la versión 1.2.9 de atlas se cambia este comportamiento, en caso de disponer una versión
anterior, es necesario incluir el siguiente código (versión mínima 1.2.7) sobre el fichero pom.xml
del módulo Web de nuestra aplicación, sobre el plugin de Tomcat, en el tag “systemProperties”
añadir las 2 siguientes propiedades
…
<systemProperties>
<log4j.configuration>log4j.xml</log4j.configuration>
<javax.net.ssl.trustStore>
${project.build.testOutputDirectory}/ssl/truststore.keystore
</javax.net.ssl.trustStore>
<javax.net.ssl.trustStorePassword>
desarrollo
</javax.net.ssl.trustStorePassword>
</systemProperties>
…
(La propiedad de log4j.xml ya existe, se ha incluido como referencia).
En caso de necesitar incluir un almacén de certificado como cliente,

existen también las variables keyStore:
…
<systemProperties>
<log4j.configuration>log4j.xml</log4j.configuration>
<javax.net.ssl.trustStore>
${project.build.testOutputDirectory}/ssl/truststore.keystore
</javax.net.ssl.trustStore>
<javax.net.ssl.trustStorePassword>
desarrollo
</javax.net.ssl.trustStorePassword>
<javax.net.ssl.keyStore>
${project.build.testOutputDirectory}/ssl/keystore.keystore
</javax.net.ssl.keyStore>
<javax.net.ssl.keyStorePassword>
desarrollo
</javax.net.ssl.keyStorePassword>
</systemProperties>
…
Los almacenes que generan los arquetipos están preparados con las CA‟s de prueba de ICM, no obstante, en caso
de necesitar agregar más entradas a dichos almacenes, lo haremos siguiendo los siguientes pasos:
Haremos uso de la utilidad proporcionada por Java, Keytool, para realizar esta operación.
Paso 1
Copiamos el almacén utilizado por las aplicaciones de atlas, localizado en la carpeta “test”:
75 de 106
Framework Atlas
Ejemplo de estructura de aplicación Web atlas.
A la ruta donde se encuentra la utilidad Keytool
Ejemplo de instalación Java sobre c:/Archivos de programa/Java/xxxx
Paso 2
Recuperamos certificado de servidor
Para recuperar el certificado del servidor, podemos hacerlo a través del navegador:
76 de 106
Framework Atlas
Copiamos la url en un navegador:
Pulsamos en Datos del certificado, en la pestaña Detalles hacemos click en botón “Copiar en Archivo”
Seleccionamos el siguiente formato de exportación y escribimos un nombre para el fichero:
77 de 106
Framework Atlas
Copiamos el fichero del certificado de servidor, para que se ubique en la misma ruta:
ATENCION
78 de 106
Framework Atlas
Los certificados de desarrollo se encuentran en la web de arquitectura

http://www.madrid.org/arquitecturasw/otras-tecnologias/seguridad/certificados
Una vez estemos posicionados en dicha ruta con el almacén y el certificado a importar, podremos ejecutar la
utilidad java para importar certificados, abrimos consola de comandos y nos posicionamos en la carpeta bin:
Inicio -> Ejecutar -> escribimos cmd
La consola de comandos se abrirá y nos posicionamos sobre la carpeta con el comando “cd”
cd C:\Archivos de programa\Java\jdk1.6.0_45\bin
ATENCION
79 de 106
Framework Atlas
Es probable que la ruta por defecto al ejecutar cmd sea una unidad diferente de donde está
instalado Java, para cambiar de unidad tan solo tenemos que escribir la letra de la unidad
seguido de :
Tal que así:
C:
Una vez posicionados en la carpeta donde tenemos nuestro almacén y certificado, realizamos el siguiente
comando:
keytool -import -file desaCertificado.cer -keystore truststore.keystore
La contraseña del almacén de certificados incluido con las aplicaciones de altas es: desarrollo
Escribiendo desarrollo y pulsando intro nos importará el certificado al almacén, como último paso solo nos queda
copiar el fichero truststore.keystore a su ruta original:
Copiamos a ruta Destino:
80 de 106
Framework Atlas
Ruta Destino: Ruta Workspace/nombre Aplicación / web/src/test/resources/ssl
81 de 106
Framework Atlas
UTILIDADES
A continuación se muestran las distintas utilidades del framework para facilitar los desarrollos de servicios web.
82 de 106
Framework Atlas
6.2. Módulo de log de mensajes
Este módulo de log permitirá visualizar en trazas todos los mensajes enviados y recibidos por un cliente o servicio
web. A continuación se muestra un ejemplo de la salida de este módulo:
salida log consola

13:20:16,625 DEBUG - Servicio creado. Devolviendo instancia.
13:20:16,766 DEBUG - *************************************************
13:20:16,766 DEBUG - ** Mensaje de SALIDA
13:20:16,766 DEBUG - ** Accion: urn:alterar
13:20:16,766 DEBUG - ** Hacia: Address: http://.../EjemploServicioNoSeguro.../
13:20:16,781 DEBUG - *************************************************
13:20:16,938 DEBUG -
<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope

xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><ns3:alterar
xmlns:ns3="http://services.ws163.atlas"><ns3:args0><ns2:cadena1
xmlns:ns2="http://domain.ws163.atlas/xsd">Ejemplo de cadena de
entrada</ns2:cadena1><ns2:limite xmlns:ns2="http://domain.ws163.atlas/xsd">-
1</ns2:limite></ns3:args0></ns3:alterar></soapenv:Body></soapenv:Envelope>
ATENCION
El uso de este módulo solo es recomendable para entornos de desarrollo.

En ningún caso se permite su uso en entornos de producción, ya que genera
en el servidor una gran cantidad de ficheros .mar y hace que ralentize la aplicación,
además de poder producir problemas de número máximo de ficheros abiertos
Para poder activar la salida de log tanto en clientes como en servicios web, será necesario realizar las siguientes
acciones:
Paso 1: incluir la dependencia en el fichero pom.xml (en los arquetipos de servicio web ya está incluida).
pom.xml
<dependencies>
[...]

<dependency>
<artifactId>atlasfrm-clientews-message-logger-lib</artifactId>
<version>${atlasfrm-clientews-message-logger-lib.version}</version>
<type>mar</type>
</dependency>
[...]
</dependencies>
83 de 106
Framework Atlas
84 de 106
Framework Atlas
Paso 2: activar trazas de debug para el paquete „atlas.ws.util.MESSAGE‟.
log4j.xml
<category name="atlas.ws.util.MESSAGE" class="atlas.core.log.AtlasLogger">

<level value=”debug” />
</category>
Paso 3: solo en el caso del servicio web (los clientes activarán el módulo si está disponible como
dependencia), habrá que activar el módulo en el fichero services.xml para cada servicio.
services.xml
<service name="EjemploServicioNoSeguro">
[...]
<messageReceivers>
[...]
</messageReceivers>
<module ref="atlasfrm-clientews-message-logger" />
</service>
6.3. Personalización de mensajes de error
En algunas situaciones es necesario personalizar los mensajes Soap Fault que se retornan como resultado de un
error de aplicación o de seguridad. Las excepciones de seguridad pueden producir mensajes Soap Fault
personalizados a las necesidades funcionales con las siguientes instrucciones:
1. Implementar la interfaz atlas.clientews.fault.SoapFaultProvider
atlas.clientews.fault.SoapFaultProvider
85 de 106
Framework Atlas
public interface SoapFaultProvider {
/**
* Método al que se llamará desde el Framework cuando se
* produzca una excepción
*
* @param msgCtx contexto del mensaje de Axis2
* @param t excepcion producida durante la validación o
* procesamiento del mensaje
* @throws AxisFault
*/
void processException(MessageContext msgCtx, AtlasSecurityException t)
throws AxisFault;
}
Esta interfaz solo contiene un método processException al que se le pasan dos parámetros: el contexto del
mensaje de Axis 2 y la excepción de seguridad lanzada. La implementación de este método deberá lanzar una
excepción AxisFault personalizada con la que Axis 2 generará el mensaje Soap Fault.
2. Configurar la implementación de SoapFaultProvider en el fichero services.xml.
Para que ATLAS pueda delegar la gestión del error a la implementación de SoapFaultProvider, se deberá
configurar el parámetro errorTranslator en el fichero services.xml como un parámetro del servicio:
services.xml
<service name="EjemploServiceWSS2">
<parameter name="...</parameter>
...
<parameter name="errorTranslator">mi.gestor.de.excepciones</parameter>
<messageReceivers>
...
El gestor de errores Soap Fault por defecto del framework es la clase atlas.clientews.fault.
DefaultSoapFaultProvider.
6.3.1. Especificación SoapFault SCSPv3
La especificación SCSPv3 se encarga de definir las comunicaciones de servicios web entre las distintas
administraciones públicas. En ATLAS se ha dado soporte a la especificación de Soap Fault a través de la
implementación atlas.clientews.fault.SCSP3SoapFaultProvider. La configuración debe realizarse según el apartado
anterior:
86 de 106
Framework Atlas
Configuarción SCSPv3 en services.xml
<service name="EjemploServiceWSS2">
<parameter name="...</parameter>
...
<parameter name="errorTranslator">atlas.clientews.fault.SCSP3SoapFaultProvider</parameter>
<messageReceivers>
...
Con esta configuración, se generarán errores de seguridad con la siguiente forma:
Ejemplo de SoapFault SCSPv3 (Soap 1.1)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-secext-1.0.xsd">wsse:InvalidSecurity</faultcode>
<faultstring>[0302] Certificado caducado</faultstring>
<detail>
<Atributos
xmlns="http://intermediacion.redsara.es/scsp/esquemas/V3/soapfaultatributos">
<IdPeticion>001_DIR_MINHAP_FNUX0_9CC4</IdPeticion>
<NumElementos>1</NumElementos>
<TimeStamp>2014-04-07T14:25:53.422+0200</TimeStamp>
<Estado>
<CodigoEstado>0302</CodigoEstado>
<LiteralError>Certificado caducado</LiteralError>
<TiempoEstimadoRespuesta>0</TiempoEstimadoRespuesta>
</Estado>
<CodigoCertificado>SDVSTCFWNS10</CodigoCertificado>
</Atributos>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
6.4. Cambiar entre configuraciones de clientes Atlas (multithread, únicos..)

A partir de la versión 1.2.9 de los proyectos atlas, podremos especificar como queremos que se generen nuestros
clientes Atlas.
Por defecto, la generación de dichos clientes hasta la versión 1.2.9 se realizaba mediante clientes multiThread,
dicha configuración podía desactivarse con la variable del fichero application.propertites:
Application.properties
atlas.configurationcontext.multithread=false
Esta configuración queda relegada como la opción por defecto en caso de desactivar la generación de clientes
única, que se activa con la siguiente propiedad del mismo fichero:
87 de 106
Framework Atlas
Application.properties
#Modo de generación de clientes atlas de forma Unica
atlas.clientesunicos.activado=true
Por lo tanto, en caso de activar este nuevo parámetro (En versiones de atlas 1.3.0 y posteriores está activada por
defecto), la configuración de multiThread (Activado o desactivado) no tendrá efecto.
88 de 106
Framework Atlas
7. OBTENCION DE LO KEYSTORES
Los keystores (tanto los de pruebas como el de producción) se deben solicitar a la Unidad de Seguridad de
Sistemas que los generará e indicará una ruta de subversión donde se encuentra dicho keystore y una password
encriptada del keystore. (A esta ruta de subversión sólo tendrá acceso paso a producción)
En la ficha de Paso a Producción, en la casilla “Nombre del Keystore” hay que poner esta ruta para cada uno de los
entornos. Será paso a producción quien configure la variable https.keystore.path del fichero
environment.properties
(Recordar que cuando se pase ha producción habrá que indicar la ruta del entorno de pre-producción y del de
producción)
La password encriptada habrá que ponerla en la propiedad https.keystore.pass del fichero

environment.properties
89 de 106
Framework Atlas
8. CREACION DE TESTS UNITARIOS PARA SOAPUI
En la creación de un proyecto de servicio web, se crean tres módulos: el módulo web para generar un servicio web,
el módulo lib para la generación del cliente de dicho servicio web, y el módulo test que contiene proyectos de
SoapUI para realizar tests del servicio web sin utilizar el cliente Java del módulo lib.
En el proyecto de servicio web inicial, se incluyen ejemplos de proyectos sin seguridad, con seguridad https y con
seguridad de cifrado y firmado en el mensaje SOAP. A continuación se muestra como crear proyectos nuevos para
los servicios web a implementar.
8.1.1. Proyecto SoapUI sin seguridad
En este caso, se importará el proyecto desde el WSDL del servicio web. Para ello, deberá ejecutarse primero el
servicio web con el comando:
mvn clean install jetty:run
Una vez arrancado el servidor Jetty, se accederá a la URL: http://localhost:9080/index.html para listar los servicios
disponibles. Pulsar con el botón derecho en el nombre del servicio y guardar el enlace con extensión .wsdl en el
módulo test, directorio src/main/resources/wsdl.
Una vez guardado el descriptor WSDL del servicio, abrir el programa SoapUI y generar un nuevo proyecto.
90 de 106
Framework Atlas
Project Name: nombre del servicio.

Initial WSDL/WADL: buscar el fichero WSDL del servicio guardado.
Marcar elementos en rojo en la imagen.
Guardar el proyecto en la carpeta „soapui‟.
Antes de ejecutar operaciones, comprobar que la URL del servicio está correctamente configurada (puede faltar el
puerto).
8.1.2. Proyecto SoapUI con seguridad https
91 de 106
Framework Atlas
Generar un proyecto nuevo siguiendo las instrucciones del apartado anterior. Como en el caso anterior, comprobar
que las URLs del servicio están correctamente configuradas con el protocolo HTTPS (y el puerto, que en jetty es
9443).
Hacer doble click en el nombre del proyecto para abrir sus propiedades. Pulsar en la pestaña „WS-Security
Configurations‟ y en la pestaña inferior „Keystores/Certificates‟. Pulsar el botón „+‟ y añadir el almacen client_ssl.jks
(o cualquier otro de que se disponga en el proyecto). Introducir la contraseña del almacén.
Una vez hecho esto solo es necesario asignar el almacén de certificados a cada petición y asegurarse que la URL
del servicio web es correcta:
92 de 106
Framework Atlas
8.1.3. Proyecto SoapUI con seguridad firmado/cifrado
Ya que la configuración de seguridad en este apartado es compleja, a continuación se muestran los pasos
necesarios para configurar un proyecto nuevo tomando como referencia el proyecto de EjemploServicioSeguro ya
existente.
Como en el caso del servicio sin seguridad, ha de guardarse a disco el descriptor WSDL del servicio seguro. A
continuación, cargar el proyecto de ejemplo EjemploServicioSeguro-soapui-project.xml en la carpeta
src/main/resources/soapui del módulo test.
93 de 106
Framework Atlas
Pulsar con el botón derecho en las entradas Soap11Binding y Soap12Binding y eliminarlas.
94 de 106
Framework Atlas
A continuación, pulsar con el botón derecho en el nombre de proyecto y seleccionar la opción „Add WSDL’.
Seleccionar el fichero WSDL del proyecto guardado y asegurarse de marcar la opción „Create sample requests for
all operations?‟.
95 de 106
Framework Atlas
Cambiar el nombre de proyecto por el nombre del servicio web implementado.
Por último, solo es necesario seleccionar la seguridad en cada operación del proyecto. Para ello, una vez abierta la
pantalla de la operación, pulsar en „Aut‟ y establecer los valores de Outgoing WSS e Incoming WSS.
96 de 106
Framework Atlas
En el caso de Outoing WSS, se seleccionara politicaWSSFirmadoCifrado_salida para operaciones Soap12 y

politicaWSSFirmadoSoap11_salida para operaciones Soap11. Para Incoming WSS se seleccionará siempre
politicaWSSFirmadoCifrado_entrada.
Por último solo quedará ejecutar la operación para comprobar que la configuración es correcta.
97 de 106
Framework Atlas
8.1.3.1. Utilizar otro certificado de cliente
En este apartado se mostrarán las modificaciones a la configuración de seguridad del proyecto SoapUI si se quiere
utilizar otro certificado de cliente. En el ejemplo mostrado a continuación se utilizará el fichero pf-5m.p12
descargado de la web de certificados de ICM.
Abrimos el proyecto SoapUI y hacemos doble click en el nombre para abrir las propiedades y tener acceso a la
configuración de seguridad.
98 de 106
Framework Atlas
Seleccionamos la pestaña „WS-Security Configurations’, y en ella la pestaña „Keystores / Certificates’. En esta

pantalla, añadimos el almacén .p12 que contiene el certificado de cliente que se quiere utilizar.
En la pestaña „Incoming WS-Security Configurations’, en la columna „Decrypt Keystore’ seleccionamos el nuevo

almacén que contiene el certificado de cliente. Configuramos la contraseña del almacén.
Por último, en la pestaña „Outgoing WS-Security Configurations’, en cada una de las dos entradas
(politicaWSSFirmadoCifrado_salida y politicaWSSFirmadoCifradoSoap11_salida), en la pestaña „Signature’,
modificamos las entradas Keystore, Alias y Password con los datos del nuevo certificado cliente.
99 de 106
Framework Atlas
Con estos cambios, el certificado cliente que se utilizará en la seguridad corresponderá al fichero pf-5m.p12 usado
para el ejemplo.
8.1.4. Tests de SoapUI WS-Security + Transporte con validación de certificado
Partiendo del proyecto del apartado anterior (7.1.4) simplemente habrá que añadir el almacén de certificados para
la conexión y configurarla en cada petición:
En primer lugar, se añadirá el nuevo almacén de certificados para la conexión HTTPS:
Haciendo doble click en el nombre del proyecto se abrirán las propiedades de este. En la pestaña „WS-Security
100 de 106
Framework Atlas
Configurations‟ iremos a „Keystores / Certificates’ y añadiremos el almacén de certificados.
Después iremos añadiendo a cada petición el almacén de seguridad, asegurándonos que el endpoint del servicio
apunta a una dirección HTTPS:
101 de 106
Framework Atlas
9. ERRORES MÁS COMUNES
9.1. No se encuentra el fichero WSDL de un servicio (no autogenerado)
Esta caso suele darse en el entorno de desarrollo. Consutar el apartado 3.1.6 de este documento para más
información. Muy probablemente, el error se deba a no haber modificado el fichero weblogic.xml para añadir la
sentencia <wls:show-archived-real-path-enabled>.
La solución más adecuada es añadir la línea en amarillo en el fichero weblogic.xml del proyecto:
Fichero web/src/main/webapp/WEB-INF/weblogic.xml
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
<wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
</wls:container-descriptor>
102 de 106
Framework Atlas
9.2. No se reconoce el método en un cliente de Axis2 en la llamada a un servicio de Axis1
Se han detectado problemas de llamada en clientes Atlas de Axis2 que llaman a servicios web generados con Axis
1 en los que el error enviado por el servicio es:
consola
org.apache.axis2.AxisFault: No such operation 'xxxxxxxxxxxx'
En el caso concreto de ser un servicio web de Axis1 al que se llama desde un cliente ATLAS realizado con Axis2 el
problema son los parámetros con valor null. Es necesario pasar en dichos parámetros un valor de cadena vacía „‟
para que la llamada no produzca error. El método de utilidad StringUtils.nullToBlank() toma una cadena String
como parámetro y devuelve una cadena vacia si el parámetro es nulo.
9.3. Error al generar un cliente de Axis2 a partír del WSDL del servicio
El error producido al generar un cliente en base a su WSDL es:
consola
org.apache.axis2.schema.SchemaCompilationException: can not find type

{http://schemas.xmlsoap.org/soap/encoding/}Array from the parent schema ...
En este caso el WSDL del servicio ha sido generado con Axis1 en formato rpc/encoded, formato que no es
soportado por Axis2 ya que no es un estándar de servicios web. La única solución en este caso es generar el
cliente con el plugin maven de Atlas para Axis1.
Es este caso se deberá solicitar autorización a Arquitectura y les indicaremos el manual

ATLAS_MUS_Servicio_Invocador_de_Servicios_axis1 para hacer clientes de Axis1
103 de 106
Framework Atlas
9.4. Error al ejecutar Peticiones a Servicios Web Seguro desde entorno local
El error producido cuando se ejecuta una aplicación que realice peticiones a un servicio web seguro desde nuestro
entorno local es el siguiente:
consola
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target
Por favor, en caso de disponer de este error, revisad configuración de almacén de java, en el punto 4.3.0
9.5. Error al llamar al un servicio web no seguro
Al realizar la llamada a un servicio web no seguro (a través de http), en ocasiones puede producirse el siguiente
error:
Consola
org.apache.axis2.AxisFault: The service cannot be found for the endpoint reference

(EPR)
Este error se produce porque el servidor está configurado para utilizar solo el transporte https, para solucionarlo,
revisar que el fichero services.xml del servicio web (servidor) está incluyendo el transporte http además del https:
services.xml
<service name="nombreServicio">
…
…
…
<transports>
<transport>http</transport>
</transports>
9.6. Generación de TODAS las clases necesarias con WSDL2Code con Axis2
Al utilizar el plugin de maven Wsdl2code con Axis2 para la creación de un cliente de servicio web, es probable que
Axis2 no sea capaz de generar todas las interfaces necesarias para el correcto funcionamiento del cliente.
El error aparecerá al ejecutar la llamada al Servicio web, indicando que no reconoce un objeto del WSDL (un tipo
complejo).
Para evitar esto, y que axis genere todas las clases con el plugin (y no dinámicamente con la clase Stub), hay que
agregar los siguientes parámetros en el plugin de maven:
104 de 106
Framework Atlas
pom.xml
<plugin>
<configuration>
<packageName>atlas.ws.client</packageName>
</configuration>
<executions>
<execution>
<id>yyyyyService</id>
<configuration>
<generateServerSide>true</generateServerSide>
<generateAllClasses>true</generateAllClasses>
<wsdlFile>src/main/resources/wsdl/xxxx.wsdl</wsdlFile>
</configuration>
<goals>
</goals>
</execution>
</executions>
</plugin>
105 de 106
Framework Atlas
ENLACES RELACIONADOS
Producto URL
Axis2 http://ws.apache.org/axis2/
Certificados ICM http://desarrollo.madrid.org/certificados/
Descarga certificados de prueba http://desarrollo.madrid.org/certificados/descarga_de_certificados.htm
106 de 106

ATLAS MUS Servicios Web-SACUZ PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ATLAS MUS Servicios Web-SACUZ PDF

Încărcat de

Drepturi de autor:

Formate disponibile

ATLAS

Título Manual de Usuario Invocador de Servicios

Responsable Arquitectura de Software

Versión 2.1 Fecha Versión 06/02/2017

Versión Causa del Cambio Fecha

2.0 Reestructuración de documento 21/07/2015

5.5.4. Paso 4: Configuración y uso del Cliente .............................................................................................................. 60

1.1. Audiencia objetivo

1.2. Conocimientos Previos

La invocación y generación de servicios web de ATLAS se basa en los siguientes elementos:

A continuación se muestra un diagrama de clases para un ejemplo de un servicio llamado MiPrimerService:

Para el desarrollo de un cliente de un servicio web se van a distinguir dos casos:

En los servicios web podemos distinguir los distintos tipos de accesos:

 Acceso público securizado

Trusted CA SSL Server

 Acceso privado con certificado digital cliente

SSL Client Client trusted Server trusted SSL Server

Server trusted de la CAM

 WS-Security: Mensaje SOAP firmado y cifrado

Este documento se divide en dos partes bien diferenciadas:

3. ¿QUE SEGURIDAD DEBO IMPLEMENTAR?

3.1.1. Seguridad de lado del Servidor

Si debemos crear un servidor, tendremos los siguientes posibles opciones de seguridad:

3.1.2. Seguridad de lado del Cliente

4. DESARROLLO DE UN SERVICIO WEB (SERVIDOR)

Para el desarrollo de servicios web el framework se apoya en las siguientes tecnologías:

Además de esto, el framework ATLAS aporta los siguientes elementos propios:

Para la creación de proyecto de servicio web partiendo de un arquetipo consultar el manual

El arquetipo de servicio web contiene un ejemplo de servicio web llamado EjemploServicio.

las clases del módulo lib estarán accesibles desde el web.

Por ejemplo nos creamos la interfaz siguiente:

public interface MiPrimerService {

String getFechaString() throws ServiceException;

A continuación se muestra el código de alguno de estos objetos:

public class DatosEntrada implements Serializable {

4.1.3. Paso 3: Implementación del Servicio

A continuación mostramos una implementación de ejemplo:

4.1.4. Paso 4: Configuración del Servicio

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

<bean id="miPrimerService" class="ejpl.services.MiPrimerServiceImpl" />

Definir el servicio en el fichero de axis web/src/main/webapp/WEB-INF/services.xml.

SpringBeanName: nombre del bean que se definió en el fichero applicationContext-services.xml.

4.1.5. Paso 5: Cambio del namespace del servicio (si se necesita)

Por ejemplo para cambiarlo a http://salud.madrid.org/IntegracionHorus

4.1.6. Paso 6: Eliminar Namespaces, Elements y Atributos (Si se necesita)

La clase MiInterceptor sería de la siguiente forma:

public class MiInterceptor extends AtlasInOutMessageReceiver {

4.1.7. Paso 7: Levantar el Servidor

4.1.8. Paso 8: Obtener el wsdl del Servicio

Para poder obtener correctamente el wsdl es necesario realizar lo siguiente:

1. - Si el WSDL predeterminado del servicio es un solo fichero, se ha de hacer lo

a.- En el fichero WEB-INF/services.xml, en la definición del servicio se coloca el siguiente

Un ejemplo, si tengo el servicio 'EjemploServicio', además del parámetro 'useOriginalwsdl'

En este caso el wsdl se obtendría con la URL:

2. - Si el WSDL consta de varios ficheros, además del parámetro 'useOriginalwsdl' en la

En este ejemplo, el fichero service.wsdl tiene sentencias:

<xs:import namespace="..." schemaLocation="parte1.xsd" />

En este caso el wsdl se obtendría con la URL:

y cada una de los ficheros xsd con la URL:

4.1.9. Paso 9: Creación de la interfaz para clientes en nuestro servidor

Realizamos una interfaz como el siguiente ejemplo: