Desarrollo y Consumo de Servicios Web Buenas Prácticas v26

Sistema Integral Multicanal de Atencin al
Ciudadano
e-SIRCA-Desarrollo y consumo de servicios web.

Buenas prcticas
Versin 026
Abril de 2017
Desarrollo y consumo de servicios web. Buenas prcticas
ndice........................................................................................................................................ 2
1 Control del documento......................................................................................................... 4

1.1 Informacin general................................................................................................................... 4
1.2 Histrico de revisiones.............................................................................................................. 4
1.3 Estado del documento............................................................................................................... 5
1.4 Objetivos..................................................................................................................................... 5
1.5 Audiencia.................................................................................................................................... 5
1.6 Glosario....................................................................................................................................... 6
1.7 Referencias................................................................................................................................. 6
2 Por qu usar servicios web?..............................................................................................7

2.1 Servicios web en el mbito de la Administracin electrnica................................................8
3 Criterios para crear un Servicios web...............................................................................10

3.1 Granularidad de los servicios................................................................................................. 10
3.2 Definiendo el servicio (Contract-First)...................................................................................11
3.3 Norma Tcnica.......................................................................................................................... 11
3.3.1 Estilo de construccin del servicio (binding style operation use).................................................11
3.3.2 Atributo de cabecera SOAP: MustUnderstand...............................................................................12
3.3.3 Namespace de Soap envelope.......................................................................................................13
3.3.4 Definicin de atributos y mtodos legibles......................................................................................14
3.3.5 Recomendacin respecto a definicin de esquemas.....................................................................16
3.3.5.1 Patrn de diseo de XML Schema..............................................................................................16
3.3.5.2 Representaciones del null en XML Schema................................................................................16
3.3.5.3 Uso de los tags elementFormDefault y attributeFormDefault......................................................16
3.3.5.4 Espacio de nombres.....................................................................................................................19
3.4 Estrategias de versionado de servicios y XSD......................................................................19

3.5 Estrategia de comunicacin de adjuntos...............................................................................20
3.6 Definicin de la Taxonoma de Servicio.................................................................................21
3.7 Servicios REST......................................................................................................................... 22
3.7.1 Modalidades de Publicacin de servicios REST................................................................24
3.7.1.1 Servicios SOAP a REST..................................................................................................... 24
3.7.1.2 Servicios REST................................................................................................................... 24
4 Entorno tecnolgico de la PAI............................................................................................26

4.1 Poltica de seguridad............................................................................................................... 26
4.2 Proveedores de servicios........................................................................................................ 26
4.3 Trazabilidad en el consumo de servicios de la PAI...............................................................27
4.3.1 Trazabilidad en los servicios instrumentales..................................................................................27
4.3.1.1 Trazabilidad en los servicios instrumentales en el Bus de Innovacin........................................28
4.3.1.2 Ejemplo de peticin incluyendo trazabilidad en Servicios Instrumentales...................................28
4.3.1.3 Ejemplo de peticin incluyendo trazabilidad en Servicios Innovacin.........................................30
4.3.2 Trazabilidad en Servicios de Verificacin.......................................................................................30
2 / 43
4.4 Definicin de Errores de negocio y SoapFaults....................................................................31
4.4.1 Especificacin Errores de negocio..................................................................................................31
4.4.2 Especificacin Soap Fault...............................................................................................................32
4.4.2.1 faultcode.......................................................................................................................................33
4.4.2.2 faultstring......................................................................................................................................33
4.4.2.3 detail.............................................................................................................................................34
4.4.2.4 Ejemplo de SoapFault..................................................................................................................36
5 Apoyo a los desarrolladores..............................................................................................40

5.1 Esqueleto de servicio web....................................................................................................... 40
5.1.1 Como utilizar gvNIX en el mbito de la PAI....................................................................................40
5.1.2 Bloques que componen el esqueleto..............................................................................................40
5.2 Clientes de servicios................................................................................................................ 41
1 Control del documento

1.1 Informacin general
Ttulo Desarrollo y consumo de servicios web. Buenas prcticas
Creado por DGTI
Revisado por
Lista de distribucin
Desarrollo_y_consumo_de_servicios_web_Buenas_prcticas_v26.
Nombre del fichero
odt
1.2 Histrico de revisiones

Versin Fecha Autor Observaciones
001 13/02/2012 DGM Versin Inicial
002 08/04/2014 DGTI Inclusin particularidades PAI
003 24/04/2014 DGTI SoapFaults y gestin de errores
Eliminar texto/puntos generales y ambiguos. Aadir

004 1/05/2014 DGTI criterios tcnicos que deben implementar los
desarrolladores
Modificacin e inclusin de nuevos tags y revisin
005 16/05/2014 DGTI
general del documento.
006 10/09/2014 DGTI Revisin del documento. Inclusin faultcode.
Reorganizacin del contenido. Inclusin de punto

007 23/09/2014 DGTI para proveedores de servicios y espacios de
nombres.
Revisin del contenido. Reorganizacin de los
008 26/09/2014 DGTI puntos. Inclusin de Ayuda a los desarrolladores,
patrones XML Schema, Por qu usar servicios web?
Revisin de contenido. Sustituidas referencias a PIE
(Plataforma de Intermediacin del Estado) por PID
009 31/10/2014 DGTI
(Plataforma de Intermediacin de Datos). Referencia
al documento de generacin de servicios web.
Revisin del contenido. Aadido MustUnderstand.
010 21/11/2014 DGTI
Cambio en Granularidad.
Modificaciones en faultcode, soapfault, definicin de
011 28/11/2014 DGTI atributos y mtodos, granularidad de servicios,
parmetros de los xsd.
Revisin del contenido. Cambio en ejemplo
012 01/12/2014 DGTI soapFault, reasignacin de puntos para la norma
tcnica.
013 015/01/2015 DGTI Incluido ejemplo del Id_trazabilidad en el punto 4,3,1.
014 27/01/2015 DGTI
4 / 43
Aadida referencia al documento de consumo de

015 26/02/2015 DGTI
servicios en la seccin mustUnderstand
016 27/02/2015 DGTI Correccin de la seccin mustUnderstand
017 02/11/2015 DGTI Mustunderstand en servicios web
018 26/05/2016 DGTI Correccin de la seccin mustUnderstand
Ampliacin Servicios REST, Id_trazabilidad, servicios

019 11/02/2016 DGTI innovacin
Cambio de Logos
020 09/06/2016 DGTI Revisin de Contenido
Modificaciones relativas a cambios de redaccin y

021 10/06/2016 DGTI
aclaracin
Inclusin de Ejemplo y Recomendaciones en
022 22/06/2016 DGTI
servicios REST
023 12/07/2016 DGTI Revisin del Contenido y Correccin de errores
024 18/07/2016 DGTI Revisin del faultcode, cabecera aplicacin en REST
Modificacin formato Timestamp Id_trazabilidad y

025 03/10/2016 DGTI tabla de errores soapFault. Se aaden ejemplos de
soapFault con descripcin de tags.
026 03/04/2017 DGTI Correccin de errores
1.3 Estado del documento
Responsable aprobacin Fecha
1.4 Objetivos
El presente documento pretende guiar en las buenas prcticas en el desarrollo de servicios web
para permitir orientar la plataforma de servicios SOA de la GVA hacia un entorno de
interoperabilidad real y eficiente.
1.5 Audiencia
Nombre y Apellidos Rol
CONSUMIDORES Y DESARROLADORES DE SERVICIOS
5 / 43
Tabla 1: Audiencia
1.6 Glosario
Trmino Definicin
Tabla 2: Glosario
1.7 Referencias
Referencia Ttulo
Tabla 3: Referencias
6 / 43
2 Por qu usar servicios web?

SOA (Service Oriented Architecture) es una arquitectura de Software orientada a servicios. Para
implementar con xito una SOA se consideran unos principios importantes sobre los que debemos
trabajar. Sobre ellos hemos destacado los que nos parecen ms importantes y por tanto el core
SOA:
Bajo acoplamiento: Es uno de los factores crticos para el xito de la estrategia SOA. El
objetivo del bajo acoplamiento es reducir las dependencias entre los sistemas implicados.
En el caso de los Web services la comunicacin entre consumidores y servicios se realizar
mediante la interfaz del servicio (WSDL), logrando as la independencia entre el servicio a
ejecutar y el consumidor.
Reusabilidad: Un servicio debe ser diseado y construido pensando en su reutilizacin

dentro de la misma aplicacin, empresa o dominio pblico para su uso masivo. En el caso
de los Servicios Web, tienen que ver en este apartado la relacin entre WSDL y XML
Schemas, como veremos ms adelante el hecho de separar los XSD del WSDL es clave
para su reutilizacin.
Descubrimiento: Todo servicio debe poder ser descubierto de alguna forma para que
pueda ser utilizado, consiguiendo as evitar la creacin accidental de servicios que
proporcionen las mismas funcionalidades.
Interoperabilidad: Permite que los consumidores y los servicios desarrollados en

tecnologas y plataformas diferentes puedan informacin y colaborar.
Gobernabilidad: En un entorno SOA, la gobernanza gua el desarrollo de servicios

reutilizables, lo que establece cmo se disearn y se desarrollarn los servicios y cmo
cambiarn con el tiempo. Establece acuerdos entre los proveedores de servicios y los
consumidores de esos servicios y indicando a los consumidores lo que deben esperan y lo
que los proveedores estn obligados a proporcionar.
Si bien SOA no est estrictamente vinculado necesariamente con Servicios Web, estos suman
cada da ms importancia ya que las caractersticas que poseen los convierten en el mecanismo
ideal para cubrir los principios de la orientacin a servicios (SOA).
Bsicamente los Servicios Web son mecanismos de comunicacin que permiten interoperabilidad
entre aplicaciones a travs del uso de estndares abiertos. De esta manera aplicaciones
7 / 43
desarrolladas en diferentes lenguajes de programacin y ejecutadas en diferentes plataformas

pueden intercambiar datos y presentar informacin dinmica al usuario de forma homognea y
coherente.
2.1 Servicios web en el mbito de la Administracin electrnica

En el entorno del desarrollo de servicios web en el mbito de Administracin electrnica, hay que
tener muy en cuenta la Resolucin de 28 de Junio de 2012, de la Secretara de Estado de
Administraciones Pblicas, por la que se aprueba la Norma Tcnica de Interoperabilidad de
Protocolos de intermediacin de datos. En dicha resolucin se especifica que de forma general, en
servicios de intercambio e intermediacin, se debe seguir la estructura del protocolo SCSP
(Sustitucin de Certificados en Soporte Papel) cuya especificacin est disponible en el Portal de
Administracin electrnica PAE/CTT en la direccin
http://administracionelectronica.gob.es/es/ctt/scsp.
La especificacin SCSP define un conjunto de mensajes, basados en XML, definidos por sus
correspondientes esquemas XSD.
El sistema permite que la peticin-respuesta sea sncrona o asncrona y los mensajes van firmados
mediante WS-Security.
Mensajes generales: Son comunes a todos los servicios y estn compuestos por los
siguientes mensajes.
o Peticin (peticion.xsd) con namespace
o Confirmacin (confirmacionPeticion.xsd) con namespace
o Solicitud de Respuesta (solicitudRespuesta.xsd) con namespace
o Respuesta (respuesta.xsd) con namespace
o Soap Fault Atributos (soapfaultatributos.xsd ) con namespace
Mensajes Especficos: Depende de cada certificado administrativo o transmisin de datos.
Lo define el organismo emisor.
o Datos Especficos con namespace
La PAI dispone de todos los esquemas definidos en el ENI.
La recomendacin desde la PAI es seguir estos esquemas en lo que a servicios de verificacin e

intermediacin compete, para facilitar la homogeneidad en el consumo de servicios ya sea como
cedentes o requirentes de informacin en el mbito de la norma tcnica de interoperabilidad. En el
caso de servicios denominados como instrumentales se han de seguir en la medida de lo posible
las especificaciones y normas expuestas en este documento, pudiendo en caso de duda consultar
a los responsables de la PAI en el uso de los estndares en base a los servicios a publicar.
8 / 43
Al tratar en la mayora de ocasiones, de informacin sensible a LOPD, se debern tener muy

presentes las medidas en cuanto la confidencialidad e integridad de la informacin intercambiada,
que ser protegida conforme al grupo de medidas de proteccin, captulos Proteccin de las
comunicaciones (mp.com) y Proteccin de la informacin (mp.info) definidas en el Real Decreto
3/2010, de 8 de enero, y con las medidas de seguridad dispuestas en la Ley Orgnica 15/1999, de
13 de diciembre, y normativa de desarrollo, asegurando que no se almacena informacin personal
de ningn ciudadano.
En el apartado III.6 de la Resolucin de 28 de Junio, por el que se aprueba la Norma Tcnica de

Interoperabilidad de Protocolos de intermediacin de datos, se hace referencia a los requisitos de
trazabilidad y auditora de los intercambios.
9 / 43
3 Criterios para crear un Servicios web.
Un Web Service es una parte del software que puede comunicarse con otra aplicacin a travs de
una red usando un juego especfico de protocolos estandarizados- SOAP, UDDI, WSDL.
Entre los principales beneficios que se exponen al hablar de los servicios Web, generalmente se
encuentran aquellos que tienen que ver con granularidad e interoperabilidad, es decir, con la
posibilidad de desarrollar componentes de software totalmente independientes que tienen
funcionalidad propia, pero que son capaces de exponer tal funcionalidad y compartirla con otros
servicios y aplicaciones para lograr crear sistemas ms complejos.
Por otro lado, la visin planteada por este paradigma computacional, donde todo es un servicio,
permite manejar un esquema de integracin universal en el cual se pueden aprovechar todos los
beneficios de cada componente con un nuevo nivel de complejidad y dinamismo.
Los Servicios Web permiten que las organizaciones integren sus diferentes aplicaciones de una
manera eficiente, sin preocuparse por cmo fueron construidas, donde residen, sobre qu sistema
operativo se ejecutan o cmo acceder a ellas.
3.1 Granularidad de los servicios

La granularidad de un servicio en un contexto SOA viene determinada por la cantidad global de
funcionalidad encapsulada en dicho servicio. La granularidad de los servicios es fundamental para
la reusabilidad y versatilidad de los servicios que se diseen.
Los servicios web son definidos en WSDL (WebService Description Language), que de forma
resumida, aglutinan en distintos mtodos u operaciones, la funcionalidad implementada en los
mismos. La recomendacin desde la PAI es el desarrollo de un mayor nmero de servicios con
menor nmero de mtodos (servicios ms simples), ms que la encapsulacin en un solo servicio
de toda la funcionalidad aplicable a un determinado modelo de negocio complejo. Esto permite la
clara identificacin de los servicios de negocio y la simplificacin en el consumo de los mismos
debido a la minimizacin en las interacciones del mtodo de consumo. Adems permiten un mayor
detalle en el registro de estadsticas de consumo de servicios.
Para entender mejor este concepto de granularidad, imaginemos un determinado organismo que
por ejemplo, desarrolla un servicio que permite verificar los datos catastrales, pero al que se le
puede preguntar bien por bienes inmuebles asociados a un titular, bien por todos los datos
10 / 43
catastrales de los inmuebles, que figuran en la base de datos del Catastro, asociados a un titular .
La recomendacin sera exponer ambas funcionalidades como servicios distintos.
Como resumen de este punto, se deben disear servicios web con las responsabilidades bien
repartidas, que sean cohesivos, extensibles, escalables y reutilizables.
3.2 Definiendo el servicio (Contract-First)

Existen dos formas tradicionales de acometer el desarrollo de un servicio web. En la jerga
tradicionalmente se les conoce como ContractFirst (contrato al principio) y ContractLast (contrato al
final). La recomendacin en este caso es claramente utilizar ContractFirst, es decir, definir las
operaciones, mtodos y datos del negocio del servicio como fase inicial del anlisis, para
implementar posteriormente el cdigo. Los diseos Contract-First permiten dar mayor robustez al
servicio frente a variaciones. Tambin mejora los aspectos de reusabilidad, rendimiento y
versionado, haciendo que sea una de las caractersticas ms habituales en el diseo de
webservices.
Se debe tener en cuenta que el desarrollo de servicios con esta filosofa requiere un planteamiento
y definicin iniciales, tanto de los servicios, como de los datos que van a formar parte del mismo.
Este esfuerzo en la definicin redundar como hemos dicho en la mejora del servicio a
proporcionar, una mayor claridad en el planteamiento y una independencia en cuanto a la lgica de
negocio interna de la aplicacin.
3.3 Norma Tcnica
En este captulo se tratan puntos relativos a la aplicacin de buenas prcticas en la definicin

tcnica de los servicios web.
La definicin de los mismo se basa en un conjunto de especificaciones y buenas prcticas

definidas por la industria conocido como WS-I Basic Profile, para la obtencin de servicio web
interoperables.
3.3.1 Estilo de construccin del servicio (binding style operation use)

En el captulo de definicin de los contratos de integracin de los servicios, el documento en el que
se especifican las operaciones y mtodos est basado en el conocido WSDL. Respecto al WSDL,
la particularidad ms importante a tener en cuenta hace referencia a dos parmetros que enlazan
cmo un determinado protocolo de mensajera es asociado a las operaciones y mtodos del
servicio (binding style) as como se conforman formalmente las peticiones (operation use). Las
opciones posibles para el parmetro binding son rpc/document mientras que para el parmetro
11 / 43
use son: encoded/literal. De las cuatro combinaciones posibles de estos parmetros, la opcin
adecuada para publicar un servicio en el bus de la PAI exige que esta definicin sea:
binding=document use=literal
La razn fundamental para el uso de esta opcin es la ventaja que supone para los desarrolladores
frente a cambios del interfaz del servicio. La simple adicin de un parmetro a la operacin de un
servicio suele redundar en cambios importantes en el cdigo desarrollado en base a un interfaz
rpc/encoded, mientras que dichos cambios pueden ser menores en la evolucin de un servicio
codificado en base a un interfaz document/literal. Esta razn, entre otras, ha concluido finalmente
que el style/operation document/literal se haya convertido en el enfoque de diseo recomendado en
el diseo de webservices.
Mostramos a continuacin un detalle que muestra sobre un determinado wsdl los parmetros sobre
los que hacemos referencia anteriormente.
Finalmente, el WSDL debe ser compatible con el WS-I Basic Profile.
3.3.2 Atributo de cabecera SOAP: MustUnderstand

Las cabeceras en el mbito SOAP son utilizadas para extender capacidades como puedan ser
seguridad, enrutamiento, autenticacin, transaccionabilidad, etc.
Los contratos de integracin en el mundo SOAP (los wsdl) nos dicen claramente cmo debe ser un
el cuerpo (body), qu operaciones debe tener un servicio, como se deben conformar las peticiones,
etc. Pero nunca dicen nada acerca de cmo deben ser los headers, la propia especificacin SOAP
tampoco lo define, sino que las deja a expensas de las definiciones del usuario.
Cuando alguien manda una peticin con el parmetro de cabecera mustUnderstand=1 lo que est
queriendo decir es que el nodo SOAP al que est mandando la peticin debe obligatoriamente
entender la cabecera marcada por ese parmetro. Si alguno no lo entiende, no puede ignorarlo, y
el servicio web debe devolver un SoapFault informando de ello.
Pongamos un ejemplo para entender su utilidad; Imaginemos que una determinada peticin
exigiera que fuera transaccional, y que slo se hiciera el commit si todas y cada una de las
12 / 43
solicitudes que viajan en la peticin fueran exitosas. Si un servidor omitiera (no hiciera caso) el
hecho de que el cliente le est informando que debe entender que esa peticin exige
transaccionalidad, podra darse el caso que la aplicacin se quedara en un estado inconsistente.
Por eso en la gran mayora de las ocasiones se omite informar este parmetro, ya que exige que
el nodo al que le estn mandando la peticin entienda y procese toda la cabecera adecuadamente.
En el escenario de la PAI, el mustUnderstand no tiene sentido ya que los consumidores de los

servicios web no deben exigir el procesado de las cabeceras a los servicios finales.
En el documento Manual de usuario para el consumo de servicios instrumentales y de verificacin

publicado en el portal de eSirca junto al presente documento, aparece detallado como crear un
cliente de ejemplo mediante CXF con el parmetro mustUnderstand desactivado.
Aun as, la aplicacin ms habitual de este parmetro se realiza la cabecera Security de WSS,
obligando de esta forma a que todos los sistemas por lo que pasa la peticin deban entender este
protocolo de seguridad SOAP. Por ello, ya que la PAI no altera el mensaje de peticin los servicios
finales se ven obligados a comprender estas cabeceras. En el documento Manual Usuario
Generacin de Servicios gvNIX de detalla como realizar las acciones necesarias sobre un servicio
web CXF para procesar una cabecera de este tipo.
3.3.3 Namespace de Soap envelope

Es recomendable, con la finalidad de obtener una validacin correcta de la firma realizada sobre el
cuerpo Soap, tal y como marca el estndar, definir correctamente los namespaces de envoltorio
Soap.
Por ello, a nivel de nodo Envelope solo debe aparecer una nica definicin de namespaces para
Soap, evitando cabeceras como puede ser la siguiente, donde observamos dos definiciones de
namespace iguales, junto a prefijos distintos:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
Esto crea inconsistencia en la validacin de la firma que se hay realizado, provocando un error en
la misma. La forma correcta de los namespaces es:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
13 / 43
3.3.4 Definicin de atributos y mtodos legibles

No se permiten servicios que expongan mtodos en los que un archivo XML lleve la lgica
asociada como un solo parmetro de llamada al mtodo, ya que en esta prctica encontramos
ciertas desventajas.
Peticin:
xmlns:urn="urn:es:gva:comunicaciones:ComunicacionesWS">
<soapenv:Header/>
<soapenv:Body>
<urn:getComunicaciones>

<data><![CDATA[<?xml version="1.0" encoding="UTF-8" standalone="yes"?
>
<REQUEST_CONSULTA_COMUNICACIONES
xmlns="urn:gva:es:comunicaciones:requestConsultaComunicaciones">
<CODIGO_ENTIDAD>L046111-00000000</CODIGO_ENTIDAD>
<NUMERO_IDENTIFICACION>00265889D</NUMERO_IDENTIFICACION>
<ACUSE>true</ACUSE>
<PAGINACION>
<TAMANYO_PAGINA>1000</TAMANYO_PAGINA>
<NUMERO_PAGINA>0</NUMERO_PAGINA>
</PAGINACION>
</REQUEST_CONSULTA_COMUNICACIONES> ]]>
</data>
</urn:getComunicaciones>
</soapenv:Body>
</soapenv:Envelope>
Esquemas:
<xsd:element name="getComunicaciones" type="getComunicaciones"/>
<xsd:complexType name="getComunicaciones">
<xsd:sequence>
<xsd:element minOccurs="0" name="data" type="xs:string"/>
</xsd:sequence>
14 / 43
15 / 43
Para evitar esta problemtica se debe eludir este tipo de prcticas en los servicios web y realizar la
definicin de esquemas precisos para cada uno de los elementos que van a viajar en la peticin, a
continuacin vemos una aproximacin de cmo deberan ser las peticiones y los esquemas bien
estructurados.
Peticin:
xmlns:urn="urn:es:gva:comunicaciones:v3:ComunicacionesWS">
<soapenv:Header/>
<soapenv:Body>
<urn:getComunicaciones>
<urn:peticion>
<urn:codigoEntidad>GV</urn:codigoEntidad>
<urn:fechaFin>2016-02-16T17:30:04.347+01:00</urn:fechaFin>
<urn:paginacion>
<urn:tamanyoPagina>2</urn:tamanyoPagina>
<urn:numeroPagina>1</urn:numeroPagina>
</urn:paginacion>
</urn:peticion>
</urn:getComunicaciones>
</soapenv:Body>
</soapenv:Envelope>
Extracto de esquema:
<xs:complexType name="consultaComunicacionesRequest">
<xs:sequence>
<xs:element name="codigoEntidad" type="types:typeCodigoEntidad" />
<xs:element name="numeroComunicacion" type="types:typeNumeroComunicacion"
minOccurs="0" />
<xs:element name="numeroIdentificacion" type="types:typeNumeroIdentificacion"
minOccurs="0" />
<xs:element name="fechaInicio" type="xs:dateTime"
minOccurs="0" nillable="true" />
<xs:element name="fechaFin" type="xs:dateTime" minOccurs="0"
nillable="true" />
<xs:element name="acuse" type="xs:boolean" minOccurs="0"
nillable="true" />
<xs:element name="estados" minOccurs="0" nillable="true">
<xs:complexType>
<xs:sequence>
<xs:element name="estado" type="types:typeEstadoComunicacion"
minOccurs="0" nillable="true" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="paginacion" type="tns:paginacion"
minOccurs="0" nillable="true" />
</xs:sequence>
</xs:complexType>
16 / 43
3.3.5 Recomendacin respecto a definicin de esquemas

Una recomendacin habitual en la definicin de servicios web es la de separar el modelo de datos
de las distintas peticiones (XSDs) de las correspondientes definiciones asociadas a los mtodos y
operaciones del servicio (WSDL). Aunque es muy habitual el uso autocontenido en los wsdl de los
modelos de datos, la separacin de ambos ayuda en la organizacin y legibilidad del servicio,
reduce el tamao/complejidad del WSDL, permite utilizar editores especializados para el diseo del
schema XSD y permite reutilizar schemas y namespaces.
A la hora de disear el schema XSD, conviene crear tipos y elementos globales (a nivel raz) para
poder reutilizarlos, tanto a nivel de elementos XML como clases del lenguaje de implementacin del
servicio web.
3.3.5.1 Patrn de diseo de XML Schema

Existen muchas maneras de disear XML Schemas vlidos, pero si los queremos utilizar junto a los
descriptores de contratos de servicios web (WSDL) , tendrn que cumplir adems con las especifi-
caciones WS-I Basic Profile con el propsito de cumplir unos requisitos de interoperabilidad y ase-
gurar la compatibilidad en las invocaciones entre los mismos.
Las buenas prcticas en el diseo de XML Schema, giran en gran parte, en torno a la existencia
de:
Declaracin de elementos (element) globales (elemento global es cualquier hijo de un nodo
<schema> o una referencia directa a uno de ellos) o locales (Se anidan dentro de la estruc-
tura del <schema> y no son hijos directos de la raiz).
dem para con la declaracin de tipos definidos (complexType simpleType)
Existen varios patrones de diseo aceptados, entre los cuales se recomienda el uso del conocido
como Salami Slice que consiste declarar los elementos a nivel global del documento y utilizar las
referencias a los mismos en los tipos complejos, facilitando la reutilizacin de componentes.
3.3.5.2 Representaciones del null en XML Schema

Hay dos maneras cuya utilizacin recomienda el WS-I Basic Profile para representar un valor nulo
para elementos: ya sea con el atributo nillable=true, o con minOccurs=0.
Para matizar sobre su uso, se debe utilizar minOccurs=0 para definir un elemento como opcional y
nillable=true para indicar que un elemento puede ser vaco pero siempre estar presente en el
mensaje XML.
17 / 43
31: 

32: <element name="member" type="tns:Band_Member_Type" minOccurs="1"
33: maxOccurs="unbounded" />
34: </sequence>
35: <attribute name="id" type="string" />
36: </complexType>
37: </element>
38: </schema>
As pues, elementFormDefault=qualified, significa que todos los elementos (globales y locales)

deben ser qualified, esto es, deben ser asociados a un determinado namespace. Por otra parte,
elementFormDefault=unqualified significa que slo los elementos globales deben ser asociados con
namespaces, no as los elementos llamados locales. Esto mismo se puede aplicar al parmetro
attributeFormDefault el cual aplicar la norma a los nodos <xs:attribute>.
La recomendacin es emplear elementFormDefault qualified y attributeFormDefault
"unqualified", para evitar colisiones y conflictos en caso de indefiniciones adecuadas de
namespaces.
Un ejemplo de esta definicin lo mostramos seguidamente:

<xs:schema targetNamespace="http://intermediacion.redsara.es/scsp/esquemas/V3/peticion" elementFor-
mDefault="qualified" attributeFormDefault="unqualified"
xmlns="http://intermediacion.redsara.es/scsp/esquemas/V3/peticion"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns1="http://intermediacion.redsara.es/scsp/esque-
mas/datosespecificos">
<xs:element name="Apellido1">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="40"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Apellido2">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:schema>
Por tanto la peticin a este servicio seria correcta:

<soapenv:Body>
<pet:Peticion>
<pet:Atributos>
...
</pet:Atributos>
<pet:Solicitudes Id="">
<pet:SolicitudTransmision>
<pet:DatosGenericos>
<pet:Emisor>
18 / 43
...
</pet:Emisor>
<pet:Solicitante>
...
</pet:Solicitante>
<pet:Titular>
<pet:TipoDocumentacion>NIF</pet:TipoDocumentacion>
<pet:Documentacion>99999999R</pet:Documentacion>
<pet:Nombre>JUAN</pet:Nombre>
<pet:Apellido1>ESPAOL</pet:Apellido1>
<pet:Apellido2>ESPAOL</pet:Apellido2>
</pet:Titular>
<pet:Transmision>
...
</pet:Transmision>
</pet:DatosGenericos>
</pet:SolicitudTransmision>
</pet:Solicitudes>
</pet:Peticion>
</soapenv:Body>
Como podemos ver en la peticin, con el elementFormDefault=qualified todos los elementos

globales deben estar asociados a un determinado namespace. Seria adems posible obviar las
referencias en este caso a pet simplemente utilizando lo siguiente en el nodo Peticin:
<Peticion xmlns=http://intermediacion.redsara.es/scsp/esquemas/V3/peticion">
3.3.5.4 Espacio de nombres

En XML, como en muchos lenguajes de programacin, frecuentemente se debe especificar un
"espacio de nombres" para varios elementos y atributos. Esto permite distinguir entre elementos
que tienen el mismo nombre, pero diferentes propsitos y tal vez diferentes orgenes. XML hace
referencia a un espacio de nombres mediante un identificador URI que no tiene por qu ser
accesible. Por ejemplo, el espacio de nombres del esquema XML es
http://www.w3.org/2001/XMLSchema. Para facilitar la tarea, sin embargo, tambin se asigna un
alias o un prefijo. Por ejemplo, justo en el ejemplo anterior el espacio de nombres de esquema
tiene un prefijo xs:. Recuerde que el alias es tan solo eso: un alias. El identificador URI es que
realmente importa.
En el caso de los servicios de verificacin se debe seguir la definicin de espacio de nombres del
protocolo SCSP (Sustitucin de Certificados en Soporte Papel) cuya especificacin est disponible
en el Portal de Administracin electrnica PAE/CTT en la direccin
http://administracionelectronica.gob.es/es/ctt/scsp.
19 / 43
3.4 Estrategias de versionado de servicios y XSD
Por necesidades de los proyectos, los servicios web se encuentran en constante cambio y
evolucin. Las bases y principios de una arquitectura orientada a servicios (SOA) deben asegurar
que los proveedores de servicios puedan:
Liberar una nueva versin de un servicio, despus de que los consumidores del servicio
hayan probado y certificado la nueva versin del servicio.
Liberar una nueva versin de un servicio, sin esperar a que los consumidores adapten la
invocacin al nuevo servicio.
En la PAI no se aceptarn escenarios de transformacin como el que se muestra en la imagen,

puesto que implica tener un conocimiento del negocio final, que en la mayora de los casos se
salen de las funciones de intermediacin que se atribuye al bus de la PAI.
Cliente v1.00 Cliente v1.01 Cliente v2.00
Proxy v1.XX Proxy v2.XX
Transformacin
Business v1.00 Business v1.01 Business v2.00
Servicio v1.00 Servicio v1.01 Servicio v2.00

OSB
OSB
La recomendacin, es que las distintas revisiones de los servicios guarden compatibilidad con
versiones anteriores, para producir el menor nmero de incidencias en el consumo de las nuevas
versiones.
20 / 43
3.5 Estrategia de comunicacin de adjuntos
En el caso de que el servicio tenga que transmitir ficheros asociados al servicio, es interesante
conocer y gestionar las diferentes modalidades de hacerlo. Entre las ms importantes y utilizadas
encontramos MTOM y Base64.
La transmisin de ficheros en Base64 sobre el body es una practica comn historicamente y el

mtodo ms utilizado y extendido de transmisin de ficheros, pero principalmente una desventaja
muy grande, ya que la codificacin en Base64 aade al contenido original aproximadamente un
33% ms de peso.
MTOM proporciona una forma ms efectiva y normalizada por W3C de transmitir ficheros, donde en
lugar de proporcionar el contenido en el body codificado en Base64, enva los datos binarios como
adjunto.
A efectos prcticos es recomendable la utilizacin del mtodo de transmisin MTOM siempre que
se deban transmitir adjuntos, salvo cuando el tamao mximo de los ficheros objeto de la
transmisin no superen en ningn caso el tamao de 1MB.
3.6 Definicin de la Taxonoma de Servicio
Con el fin de tener una correcta estructuracin de los servicios incorporados a la infraestructura
SOA de la PAI es de vital importancia mantener una correcta taxonoma de servicios, que permita
categorizar dichos servicios a publicar conforme a criterios diferentes que sirvan como base en la
definicin de alertas, monitorizacin, gestin de recursos asociados, etc.
La informacin que normalmente se requiere para categorizar estos servicios hace referencia a
caractersticas relativas:
Semntica e informacin del servicio. En la mayora de los casos esta informacin viene
auto contenida en los wsdl y xsd del servicio, pero en ocasiones, esta informacin se debe
completar con mayor detalle. Por ello se exige un contrato de integracin en el que se
facilite toda la informacin relevante tanto de entrada como de salida para consumir el
servicio y tratar adecuadamente las respuestas que ste proporcione, tanto por el sistema
mediador (bus de interoperabilidad) como por el usuario/consumidor final.
21 / 43
Dimensionamiento del Sistema. Los recursos a destinar a la hora de exponer los diferentes
servicios, son dependientes en ocasiones, de las caractersticas como los perfiles de trfico,
tamao de las peticiones/respuestas, etc. Es importante detallar el perfil de trfico esperado
en nmero de peticiones por minuto/segundo, nivel de concurrencia mximo, as como si el
trfico es estacionario, peridico, etc. Todas estas caractersticas, ms las que se puedan
considerar de inters por parte de los desarrolladores deben ser incorporadas en el
formulario de alta de proveedor. Con ellas se definen los acuerdos de nivel de servicio a
cumplir entre los diferentes componentes. Puede consultar los formularios de alta de
proveedor en este enlace.
Comunicaciones: En ocasiones, se producen restricciones de acceso administrativas, que

obligan a considerar temas como direcciones IP origen y destino, protocolos a nivel de VPN,
etc. La exposicin de los servicios de la PAI se hace mediante protocolo https securizando
las peticiones mediante WSSecurity en cabecera SOAP. No existe de momento exposicin
de servicios REST, JSON-RPC, etc.
Requisitos de Integracin: Ciertos componentes y servicios desplegados, con frecuencia

requieren de la interaccin con otros elementos o servicios que deban ser configurados y
definidos en sincrona. Todas las interacciones y dependencias que sean necesarias para el
correcto funcionamiento del servicio deben ser establecidas en la solicitud a la PAI mediante
el formulario del proveedor, haciendo constar en la peticin todos los requerimientos de
integracin accesorios que deban ser contemplados.
3.7 Servicios REST

La arquitectura REST se define como un conjunto de principios arquitectnicos por los cuales se
disean servicios web haciendo foco en los recursos del sistema, incluyendo cmo se accede al
estado de dichos recursos y cmo se transfieren por HTTP hacia clientes escritos en diversos
lenguajes. Se caracteriza por la siguiente serie de fundamentos clave:
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la

informacin necesaria para comprender la peticin. Como resultado, ni el cliente ni el
servidor necesitan recordar ningn estado de las comunicaciones entre mensajes.
Un conjunto de operaciones bien definidas que se aplican a todos los recursos de

informacin: HTTP en s define un conjunto pequeo de operaciones, las ms importantes
son POST (genera un nuevo elemento), GET (consulta), PUT (modificacin del estado del
recurso) y DELETE (eliminacin del recurso).
22 / 43
Los parmetros que se le pueden pasar tienen que ser representados en Strings (en http lo
que viaja es siempre string).
Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es
direccionable nicamente a travs de su URI.
El uso de estndares.
El resultado que va a devolver el servicio tendr que ser String, en un formato estndar,
originalmente ese formato era XML, actualmente se suele usar JSON.
Para su inclusin siguiendo unos mnimos de securizacin en los servicios publicados en la

plataforma PAI, se ha determinado una norma de consumo de servicios REST publicados en la
PAI. Consta de dos partes:
API-KEY
Inclusin en la cabecera HTTP del mensaje realizado a la PAI un campo destinado a un cdigo o
token proporcionado por la Plataforma en el momento de la solicitud de alta al servicio.
Este cdigo se compone de 32 caracteres y es nico por cada aplicacin.
x-api-key: [VALOR]
Como ejemplo:
x-api-key: 1345c25df49d43c8153d2e91c8346ba4
Aplicacin
Inclusin en la cabecera HTTP de un campo de usuario con nombre de Aplicacin, que debe
contener la aplicacin de la consulta con el que se ha realizado el alta al servicio.
aplicacion: [VALOR]
Como ejemplo:
aplicacion: TEST_00001
Se han de incluir ambas partes para un consumo correcto del servicio. De esta forma, como
ejemplo del mensaje final:
POST https://innovacion-pre.gva.es/pai_bus_inno/REST/REST_operacion HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
23 / 43
Content-Length: 60
Host: innovacion-pre.gva.es
x-api-key: 1345c25df49d43c8153d2e91c8346ba4
aplicacion: TEST_00001
Accept: application/xml
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
"usuario": "prueba",
"password": "test001"
NOTA: Los servicios en modalidad REST utilizan el protocolo HTTP y sus operaciones, esto no
significa que la conexin tenga que ser en http sin cifrar, es posible securizar la conexin utilizando
https sin afectar al funcionamiento del mismo y con el mismo funcionamiento que normalmente.
Este protocolo (https) es el utilizado por la PAI para la publicacin de servicio REST.
Un ejemplo de inclusin de estas cabeceras en una peticin Post a un servicio Rest desde una
aplicacin Android (java) con API level 21 seria el siguiente:
HttpPost httpPost = new HttpPost(serverURL);

httpPost.addHeader("x-api-key","1345c25df49d43c8153d2e91c8346ba4");
httpPost.addHeader("aplicacion","TEST_00001");
3.7.1 Modalidades de Publicacin de servicios REST
Existen varias opciones para la publicacin de un determinado servicio en la PAI cuando se desea
un consumo del servicio en estndar REST. Por un lado es posible implementar la conversin de
un servicio SOAP a REST y por otro lado, es posible la publicacin de un servicio de naturaleza
REST como tal.
3.7.1.1 Servicios SOAP a REST
Los servicios que proporciona el proveedor en estndar SOAP a los cuales se les puede anexar
una fachada de entrada REST mediante un recurso de bus. De esta forma, el consumidor de dicho
24 / 43
servicio lo utiliza como si de un REST puro se tratase y el bus de la PAI realiza la conversin de la
llamada al servicio final en SOAP.
Esta modalidad requiere realizar un estudio de los path y operaciones http a asignar a cada uno de
los mtodos, as como el formato de los menajes, por tanto se recomienda consultar con la
Plataforma en caso de querer acogerse a esta posibilidad.
3.7.1.2 Servicios REST
La publicacin de un servicio proporcionado en REST requiere las mismas caractersticas que la

publicacin de un servicio SOAP, en cuanto a documentacin propia del servicio (juego de
pruebas, contrato de integracin, ...).
Adems se recomienda una serie de buenas practicas para el correcto funcionamiento del servicio
y la integracin del mismo en las distintas aplicaciones que puedan consumirlo:
Usa los cdigos de operacin HTTP correctamente, evitando por ejemplo el uso del cdigo
GET para la insercin de un registro en lugar de utilizar POST para este fin.
Las llamadas GET y HEAD no deben alterar el estado de los registros ni utilizarse para el
transporte de datos sensibles.
Las llamadas errneas deben devolver un error suficientemente claro y bien formado
siguiendo la especificacin lo ms cercana al punto 5.2 Especificacin Soap Fault.
No utilizar verbos en las URI, utilizar nombres y en plural.
25 / 43
4 Entorno tecnolgico de la PAI

4.1 Poltica de seguridad
Las peticiones que se realizan a la PAI para los servicios verificacin e instrumentales se securizan
y autentican utilizando mecanismos WS-Security. Concretamente, se permite seguridad WS-
Security con identificador de clave Binary Security Token.
La PAI cuenta con una poltica de autorizacin de firma de mensaje en cabecera SOAP, siguiendo
las especificaciones de WS-Security. A los servicios se les aplica una poltica que exige que las
peticiones vengan firmadas mediante un certificado que pueda validar la ACCV.
Los consumidores de servicios de verificacin de datos de la GVA o servicios instrumentales,
pueden utilizar tanto certificado de Sello de rgano como certificados de aplicacin de la ACCV.
Los consumidores de servicios de verificacin de datos ofrecidos por la Plataforma de
Intermediacin de Datos (PID) a travs de la PAI, estn obligados a utilizar certificados de Sello de
rgano de la ACCV para firmar sus peticiones.
Las particularizacin de los parmetros de configuracin de seguridad se pueden ver en la

siguiente figura:
Ilustracin 1: Definicin de parmetros WSS
Especificacin disponible en:

https://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf
4.2 Proveedores de servicios

Tal y como se describe en la parte de clientes de servicio, hay diversas tecnologas que hacen
posible la generacin de servicios web. En el Manual de Usuario para Generacin de servicios en
gvNIX se muestran los pasos para la generacin de un servicio web con el framework gvNIX
siguiendo los patrones descritos en este documento.
En el desarrollo en s de los servicios, existen en la actualidad multitud de entornos de desarrollo

(frameworks) que permiten agilizar los procesos de integracin, as como la publicacin rpida de
webservices centrndose nicamente en la lgica de negocio a implementar, obviando las labores
26 / 43
accesorias. La facilidad e integracin con los IDEs de uso habitual (Eclipse, Netbeans, JDeveloper,
IntelliJ, BlueJ, etc) permite un gil y rpido desarrollo teniendo curvas de aprendizaje con tiempos
muy cortos. En el punto 3 se esbozan directrices generales de orientacin para el desarrollo de
servicios en entornos SOA.
4.3 Trazabilidad en el consumo de servicios de la PAI

Las aplicaciones que consumen los servicios de la PAI, deben guardar informacin suficiente que
permita hacer un seguimiento de la trazabilidad de las transacciones realizadas e intercambiadas
con la plataforma.
Es importante destacar que las aplicaciones que hacen uso de la PAI, deben almacenar los
correspondientes identificadores que permitirn hacer un seguimiento de dichas transacciones,
ante futuras auditorias del proveedor del servicio.
Por parte de la PAI y de manera general a todos los servicios desplegados en la misma, se
registran los siguientes parmetros de las peticiones realizadas;
- Cabecera de la peticin (Header).

- Hash del cuerpo del mensaje (Body).
- Timestamp en el que se recibi la peticin

- Servicio destino de la peticin
- Tipo de mensaje; request | response

- Certificado del consumidor.
- Procedimiento de la peticin.
Adems especficamente para los servicios instrumentales se registra el Id_trazabilidad y para
los servicios de verificacin se registra el IdPeticin y el/los Idsolicitud. Seguidamente
procedemos a exponer estas peculiaridades y describimos las caractersticas que deben
implementar las peticiones a realizar en las llamadas a los servicios expuestos en la PAI.
NOTA: Para los servicios con poltica aplicada se registra adicionalmente a todo lo descrito
anteriormente el thread-id como identificador inequvoco del hilo.
4.3.1 Trazabilidad en los servicios instrumentales.

Con el fin de minimizar los cambios a realizar en los correspondientes desarrollos, e igualmente,
impactar de la forma ms liviana posible en el rendimiento de la plataforma, se ha optado por
27 / 43
incorporar una cabecera de mensaje SOAP, en la peticin al servicio web, que incluya el tag
Id_trazabilidad que, permitir hacer el correspondiente seguimiento posterior.
Ejemplo:
<Id_trazabilidad xmlns="http://dgti.gva.es/interoperabilidad">68254ed222d65eeb-CODIGO_CATI-20140130184955000</Id_trazabilidad>
Este tag se compone del nmero de serie del certificado utilizado para firmar la peticin,
CODIGO_CATI que toma el valor del cdigo CATI de la aplicacin y el instante de la peticin
codificado como ao,mes,dia,hora,minuto,segundo,milisegundos (patrn YYYYMMddHHmmssSSS y
formato 24 horas). Estos tres componentes del tag de trazabilidad se han de separar por un carcter
- como se aprecia en el formato de ejemplo mostrado anteriormente, se define adems el
namespace correspondiente "http://dgti.gva.es/interoperabilidad".
4.3.1.1 Trazabilidad en los servicios instrumentales en el Bus de Innovacin.

Para el consumo correcto de servicios instrumentales en el entorno de innovacin, se deben
realizar algunos ajustes sobre el Id_trazabilidad. Dado que en este entorno no se realiza firma WS-
Security con certificado, no hay que incluir el numero de serie como primer campo del
Id_trazabilidad, por tanto, este campo no se completar, quedando el tag de la siguiente forma:
Ejemplo:
<Id_trazabilidad xmlns="http://dgti.gva.es/interoperabilidad">-CODIGO_CATI-20140130184955000</Id_trazabilidad>
En sustitucin de la validacin del certificado que se realiza en el bus instrumental, en este caso,
en el bus de innovacin, la validacin se realiza sobre la IP o rango de IPs consumidora/s del
servicio.
Este tag se compone del CODIGO_CATI que toma el valor del cdigo CATI de la aplicacin y el
instante de la peticin codificado como ao,mes,dia,hora,minuto,segundo,milisegundos (patrn
YYYYMMddHHmmssSSS y formato 24 horas ). Estos componentes del tag de trazabilidad se han de
separar por un carcter - como se aprecia en el formato de ejemplo mostrado anteriormente, se
define adems el namespace correspondiente "http://dgti.gva.es/interoperabilidad".
NOTA: En caso de existir por parte del proveedor del servicio alguna necesidad de utilizar la
primera parte de este Id_trazabilidad con el fin de trasladar algn cdigo que queda vaco en este
mbito, pnganse en contacto con la PAI y se estudiar el caso.
4.3.1.2 Ejemplo de peticin incluyendo trazabilidad en Servicios Instrumentales
Un ejemplo de cdigo en Java - CXF para incluir esta cabecera sera del estilo:
List<Header> headersList = new ArrayList<Header>();
28 / 43
Header testSoapHeader1 = new Header(new QName("http://dgti.gva.es/interoperabilidad", "Id_trazabilidad"),

"68254ed222d65eeb-CODIGO_CATI-20140130184955000", new JAXBDataBinding(String.class));
headersList.add(testSoapHeader1);
client.getRequestContext().put(Header.HEADER_LIST, headersList);
Existen documentacin de inclusin de esta misma cabecera referenciada arriba, en tecnologa

gvNIX (documento Manual_Usuario_Generacin_servicios_gvNIX) y soapUI (documento
GUIA_CONFIGURACION_SOAP_UI).
A continuacin se adjunta el ejemplo de una peticin completa incluyendo la etiqueta destinada a la
trazabilidad.
<soapenv:Envelope xmlns:sch="http://www.telefonica.es/MI/InterfazSimplificado/schemas"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-
1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="X509-
DCB9D5EE6640DE7420142131045237816">MIII4DCCBsigAwIBAgIIK9mt3c2fCZgwDQYJKoZIhvcNAQEFBQAwQzETMBEGA1UEAwwKQUNDVkNBLTEyM
DEQMA4GA1UECwwHUEtJQUNDVjENMAsGA1UECgwEQUNDVjELMAkGA1UEBhMCRVMwHhcNMTMxMDA0MTAzNTQxWhcNMTYxMDAzMTAzNTQx
WjCBuTE7MDkGA1UEAwwyRElSRUNDSU9OIEdFTkVSQUwgREUgVEVDTk9MT0dJQVMgREUgTEEgSU5GT1JNQUNJT04xEjAQBgNVBAUTCVM0NjExMDAx
QTEbMBkGA1UECwwSc2VsbG8gZWxlY3Ryw7N.........+
+mD5nYvY4BriImaW+bRJeaR+5xS20uvwM6bo4y929jqeABB9v5FgBwrSh98C6MtEQ/J9Z/iJZwlGRQyoIgt6vtocQat3YOKE03/Gd7rjmrSYsECow4STBKvd4
QRqcp5b5fs8jNt97nrgsdaM+nFSFkHy8pIBecgoDbuG9JLzxJ+XVO2RSvijNb1HX7qUVrkARkxVXdDHm7xMNGSPKl9a5ea0ShWTCDU7ctquc2E5oDK6Tv+bD
f7Z1Z4JBM0T0Vnh75+PDnizmFhSzAvjIGujZigGm2ouzch34MfG0/KpflYaUnldGPbMAP4SGar77COaVwVJ8mrfOeMunpU=</wsse:BinarySecurityToken>
<ds:Signature Id="SIG-DCB9D5EE6640DE7420142131045238020" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="sch soapenv" xmlns:ec="http://www.w3.org/2001/10/xml-exc-
c14n#"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-DCB9D5EE6640DE7420142131045237819">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="sch" xmlns:ec="http://www.w3.org/2001/10/xml-
exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>nXA9tKHn/MaC1V1P/BzI6rY1xAY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>LlnonOkwUP/N6EmDub9J+jPMW/Q03p042Dge6+B8cQ/4S67VtzHbJGab0e4BAMj2nx3fz6wLMP3P
ACiDEG5HlIJjbZvpxlEehWzN8LGZE8wwh/0thtiHzAD5LwCJND5JGXsK7ps10s0EIntCPEr9GpoQ
ZXhoJzzWBdTThI718uQ=</ds:SignatureValue>
<ds:KeyInfo Id="KI-DCB9D5EE6640DE7420142131045237817">
<wsse:SecurityTokenReference wsu:Id="STR-DCB9D5EE6640DE7420142131045237818">
<wsse:Reference URI="#X509-DCB9D5EE6640DE7420142131045237816" ValueType="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
29 / 43
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
<Id_trazabilidad xmlns="http://dgti.gva.es/interoperabilidad">68254ED222D65EEB-CODIGO_CATI-
20140130184955000</Id_trazabilidad>
</soapenv:Header>
<soapenv:Body wsu:Id="id-DCB9D5EE6640DE7420142131045237819" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">
<sch:EnviarReq>
<Remitente>PRUEBASGVA</Remitente>
<Destinatarios>
<Para>N_TELF</Para>
</Destinatarios>
<TextoSMS>Hola Mundo</TextoSMS>
<NotificacionEntrega>No</NotificacionEntrega>
</sch:EnviarReq>
</soapenv:Body>
</soapenv:Envelope>
4.3.1.3 Ejemplo de peticin incluyendo trazabilidad en Servicios Innovacin

En cuanto al cdigo necesario en Java - CXF para incluir esta cabecera no dista demasiado del
punto anterior y la aproximacin seria la siguiente:
List<Header> headersList = new ArrayList<Header>();
Header testSoapHeader1 = new Header(new QName("http://dgti.gva.es/interoperabilidad ", "Id_trazabilidad"), "-CODIGO_CATI-
20140130184955000", new JAXBDataBinding(String.class));
headersList.add(testSoapHeader1);
client.getRequestContext().put(Header.HEADER_LIST, headersList);
A continuacin se adjunta el ejemplo de una peticin completa incluyendo la etiqueta destinada a la

trazabilidad en innovacin
<soapenv:Envelope xmlns:sch="http://www.telefonica.es/MI/InterfazSimplificado/schemas"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<Id_trazabilidad xmlns="http://dgti.gva.es/interoperabilidad">-CODIGO_CATI-20140130184955000</Id_trazabilidad>
</soapenv:Header>
<soapenv:Body >
<sch:EnviarReq>
<Remitente>PRUEBASGVA</Remitente>
<Destinatarios>
<Para>N_TELF</Para>
</Destinatarios>
<TextoSMS>Hola Mundo</TextoSMS>
<NotificacionEntrega>No</NotificacionEntrega>
</sch:EnviarReq>
</soapenv:Body>
</soapenv:Envelope>
30 / 43
4.3.2 Trazabilidad en Servicios de Verificacin
En el caso de los servicios de verificacin, la trazabilidad ha de ser igualmente registrada por la

aplicacin consumidora del servicio, pero los valores a guardar, vienen directamente informados
como parmetros/tags del mensaje. Para ello se registran siempre los campos de IdSolicitud (para
peticiones con ms de un IdSolicitud se registran todos los incluidos en el mensaje) y IdPeticion
del mensaje (ambos son tags obligatorios String 16/26 caracteres).
Adicionalmente a estos dos campos, se ha de registrar el cdigo del procedimiento administrativo

que faculta y habilita la peticin que se realiza por parte del organismo que cede los datos. Este
procedimiento puede ser informado de dos formas. Por una parte, a travs del tag
CodProcedimiento que es informado directamente en el mensaje en gran parte de los servicios de
verificacin. Se debe poblar con el cdigo GUC adecuado.
En los casos en los que este campo no sea informado, bien porque no exista, bien porque sea
opcional, se deber incluir el cdigo de procedimiento, insertndolo en las primeras 20 posiciones
del tag Finalidad, conforme al criterio que exponemos a continuacin (el Id_expediente puede ir
vaco).
Finalidad: CodProcedimiento#::#Id_Expediente#::#Texto Finalidad
4.4 Definicin de Errores de negocio y SoapFaults

Es imprescindible contar con un tratamiento de errores definido y detallado para aportar la
informacin necesaria por una parte al usuario o aplicacin final consumidora, pero tambin para el
entorno de interoperabilidad con el fin de que lo medie o derive al cauce adecuado.
Por ello, y siguiendo el mismo funcionamiento establecido en la Plataforma de Intermediacin de

Datos, se devolver un mensaje SOAP Fault cuando el error detectado pertenezca a alguno de los
siguientes tipos:
Error de conexin a la BD.

Error de conexin a los sistemas externos (SAFE, Servidores Externos, etc).
Error en la validacin de esquemas (o peticin recibida sin firma).
Error por Validacin de la Firma digital
o No estar firmada la peticin
o Certificado caducado, revocado o no vlido
Error del Sistema Interno en el tratamiento de la peticin.
Los mensajes SoapFault no se firmarn.
31 / 43
4.4.1 Especificacin Errores de negocio

En el resto de casos, no contemplados en la lista anterior, se entender que la peticin se ha
podido tramitar y se devolver un mensaje de Respuesta especificando en las etiquetas
correspondientes el cdigo y el texto del error o estado correspondiente (una vez mapeado) al
considerarse una respuesta contemplada por el negocio.
Esos cdigos y texto debern estar recogidos en el contrato de integracin del servicio.
Un ejemplo de estos tipos de errores controlados por el servicio final y que deben ser tratados
atendiendo a lo especificado en el contrato de servicio pueden ser a modo de ejemplo algunos
como los que se expone en la siguiente tabla, en la que se recogen errores de negocio tpicos de
diferentes servicios estatales. El siguiente listado de cdigos y descripciones de errores se
devuelve en el nodo DatosEspecificos del esquema de respuesta, concretamente, en los campos
CodigoEstado y LiteralError:
Cdigo de Descripcin de la respuesta obtenida

respuesta
0 El contribuyente se encuentra al corriente en sus
obligaciones tributarias
1 El contribuyente no se encuentra al corriente en sus
obligaciones tributarias.
2 Se ha encontrado ms de un registro para los datos del
titular indicados
3 Para la persona consultada no hay informacin en la
Comunidad Autnoma.
Tabla 2.-Errores de negocio devueltos por servicio de estar al corriente de las obligaciones tributarias GVA
Para las peticiones que devuelven respuestas con errores de negocio, en el nodo Estado del
nodo Retorno" en DatosEspecificos del mensaje de Respuesta se devolver informacin que in-
dica que la peticin es errnea.
4.4.2 Especificacin Soap Fault

Segn el esquema de SOAP, la forma del mensaje de la parte SOAP Fault es la siguiente:
<xs:element name="Fault" type="tns:Fault" />

<xs:complexType name="Fault" final="extension">
<xs:annotation>
<xs:documentation>Fault reporting structure</xs:documentation>
</xs:annotation>
32 / 43
<xs:sequence>
<xs:element name="faultcode" type="xs:QName" />
<xs:element name="faultstring" type="xs:string" />
<xs:element name="faultactor" type="xs:anyURI" minOccurs="0" />
<xs:element name="detail" type="tns:detail" minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="detail">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax" />
</xs:complexType>
Segn acuerdo y acercndonos a los estndares los valores que tomarn cada uno de estos
elementos ser el siguiente:
4.4.2.1 faultcode
Se debera dejar abierta la especificacin de este elemento, siempre y cuando sea un Xml Qualified
Name correcto, segn especificacin de la W3C. Esto permitir usar los faultcode que se rellenan
automticamente por los motores SOAP. Opcionalmente, si se desea se podra indicar un faultcode
del tipo:
Faultcode = Sender | Client | Receiver | Server [.Subcode]*
SOAP 1.1 SOAP 1.2 Descripcion
Client Sender El SOAPMessage no se form correctamente o no contiene la informacin necesaria

para tener xito.
Server Receiver El SOAPMessage no pudo ser procesado debido a un error de procesamiento.
Donde Sender o Client, se utilizaran para indicar que el problema proviene del mensaje enviado
por el requirente, y Receiver o Server, para indicar que el problema ha surgido por los procesos del
receptor del mensaje.
33 / 43
Si el mensaje de error se localizase en la PAI este campo vendra informado como soap-env:PAI.
En cuanto a los proveedores de servicio, se recomienda, la informacin de este campo de forma
que sea detectable el elemento que origina el error.
4.4.2.2 faultstring
Puede tomar cualquier valor de tipo string. El proveedor debe tratar este campo para devolver
errores legibles. Nunca se debe devolver informacin sobre las IPs, URL u otros elementos
sensibles para la seguridad del servicio.
Como sugerencia podra tomar el valor:

faultstring = [Cod_Error] Literal Error
Donde el Cod_Error seran 4 dgitos.

Por ejemplo: [0301] Organismo no autorizado
4.4.2.3 detail
Se recomienda que este elemento contenga una estructura/nodo Atributos, en la que se indicar
toda la informacin necesaria para el error, con el fin de mantener una coherencia sintctica con los
errores proporcionados por los servicios expuestos en la Plataforma de Intermediacin de Datos
(PID).
Esquema de nodo Atributos:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema xmlns="http://intermediacion.redsara.es/scsp/esquemas/V3/soapfaultatributos"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://intermediacion.redsara.es/scsp/esquemas/V3/soapfaultatributos"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Atributos">
<xs:complexType>
<xs:all>
<xs:element ref="IdPeticion"/>
<xs:element ref="NumElementos"/>
<xs:element ref="TimeStamp"/>
<xs:element ref="Estado" minOccurs="0"/>
<xs:element ref="CodigoCertificado"/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="CodigoCertificado">
<xs:simpleType>
</xs:restriction>
34 / 43
</xs:simpleType>
</xs:element>
<xs:element name="CodigoEstado">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="CodigoEstadoSecundario">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="IdPeticion">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="LiteralError">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="LiteralErrorSec">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="NumElementos">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:totalDigits value="7"/>
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="TiempoEstimadoRespuesta">
<xs:simpleType>
<xs:restriction base="xs:int">
35 / 43
<xs:totalDigits value="4"/>
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="TimeStamp">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Estado">
<xs:complexType>
<xs:all>
<xs:element ref="CodigoEstado" minOccurs="0"/>
<xs:element ref="CodigoEstadoSecundario" minOccurs="0"/>
<xs:element ref="LiteralError" minOccurs="0"/>
<xs:element ref="LiteralErrorSec" minOccurs="0"/>
<xs:element ref="TiempoEstimadoRespuesta" minOccurs="0"/>
</xs:all>
</xs:complexType>
</xs:element>
</xs:schema>
4.4.2.4 Ejemplo de SoapFault

Un ejemplo de estos tipos de errores lo podemos ver en la siguiente tabla que es extrada de un
contrato de integracin.
Cdigo de
Descripcin del error Cuando se devuelve este error
estado SCSP
Imposible ejecutar el El servicio esta cado y no se pudo cursar la
0101
servicio peticin del cliente.
Este error se produce cuando se solicita la
La peticin no existe en
0204 respuesta asncrona de un idPeticion para el cual
el sistema
no se ha registrado ninguna respuesta correcta
El timestamp de la Se recibe una peticin con un timestamp con
0230 peticin debe ser vlido formato incorrecto o que no es ni de ayer ni de
y de hoy o de ayer hoy.
El certificado o procedimiento utilizados son
Organismo no
0301 incorrectos y no se pudo autorizar el consumo al
autorizado
servicio
0302 Certificado caducado El certificado esta caducado
0303 Certificado revocado El certificado esta revocado
36 / 43
La firma de la peticin no
0305 Se ha recibido una peticin en la que la firma no
es vlida
es vlida
La peticin no tiene ca-

becera de seguridad v-
lida
0307 La peticin llega sin cabecera WS-Security vlida
o
La peticin no tiene ca-

becera de seguridad v-
lida
Error general al verificar
0309 Se produce un error al validar el certificado
el certificado
No se ha podido verificar Se produce un error al verificar la Autoridad de
0310
la CA del certificado Certificacin del certificado
La estructura del XML
introducido no La peticin enviada no cumple la estructura del
0401
corresponde con el esquema.
esquema
Se dar cuando se produzca algn error interno
Error de sistema e
0502 que impida el funcionamiento correcto (error de
identificacin del sistema
configuracin, inconsistencia de datos, etc.)
la peticin recibida no contenia el tag
Id_trazabilidad en la cabecera SOAP
Falta la cabecera
0807
Id_trazabilidad
Este error solo se producir en los servicios
instrumentales
El usuario en el
Id_Trazabilidad no
corresponde con el El usuario o nm. De serie que se han incluido en
usuario en la cabecera el tag Id_trazabilidad no se corresponden con los
de seguridad que vienen incluidos en la cabecera WS-Security
0808
o
Este error solo se producir en los servicios ins-
El nmero de serie del trumentales de firma/username (no en los instru-
Id_Trazabilidad no mentales de innovacin)
corresponde con el
certificado de firma
Tabla 3.- Ejemplo de Errores devueltos como SOAPFault
Con lo expuesto anteriormente un ejemplo de SoapFault de un servicio de verificacin podra

tener el siguiente aspecto:
<?xml version="1.0" encoding="UTF-8"?>
37 / 43
<soapenv:Body>
<soapenv:Fault>
<faultcode>env:Server</faultcode>
<faultstring>[0403] Error al obtener el contenido XML del mensaje SOAP </faultstring>
<faultactor>XSPRUW30 </faultactor>
<detail>
<Atributos xmlns="http://intermediacion.redsara.es/scsp/esquemas/V3/soapfaultatributos">
<IdPeticion>CODCERT00001</IdPeticion>
<NumElementos>1</NumElementos>
<TimeStamp>2010-09-20T13:22:35.993+0200</TimeStamp>
<Estado>
<CodigoEstado>0403</CodigoEstado>
<LiteralError>Imposible obtener el contenido XML del mensaje SOAP.</LiteralError>
<CodigoEstadoSecundario>04031</CodigoEstadoSecundario>
<LiteralErrorSec>Imposible obtener el campo atributos del SOAP</LiteralErrorSec>
<TiempoEstimadoRespuesta>0</TiempoEstimadoRespuesta>
</Estado>
<CodigoCertificado>AEAT103I</CodigoCertificado>
</Atributos>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
faultcode: Cdigo que determina el tipo de error producido.
faultstring: Descripcin del tipo de error producido.

faultactor: Cdigo que determina donde se origina el error.
IdPeticion: Identificador con el que se realiza la peticin.

NumElementos: Nmero de elementos que se incluyen en la peticin.
TimeStamp: Fecha y hora del momento en que se realiza la peticin.

CodigoEstado: Cdigo del error producido.
LiteralError: Descripcin del error producido.

CodigoEstadoSecundario: Cdigo que especifica con ms detalle el error producido.
LiteralErrorSec: Descripcin ms detallada del error producido.

TiempoEstimadoRespuesta: Tiempo en el que se estima que se obtenga la respuesta.
38 / 43
CodigoCertificado: Cdigo del certificado del servicio que se pretende consumir.
Ejemplo de SoapFault de un servicio instrumental podra tener el siguiente aspecto:

<soapenv:Body>
<soapenv:Fault>
<faultcode xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">soap-env:PAI</faultcode>
<faultstring>[0305]La firma de la peticin no es vlida</faultstring>
<detail>
<Atributos xmlns="http://intermediacion.redsara.es/scsp/esquemas/V3/soapfaultatributos">
<IdPeticion/>
<NumElementos>0</NumElementos>
<TimeStamp>2016-10-03T13:01:24.582+02:00</TimeStamp>
<Estado>
<CodigoEstado>0305</CodigoEstado>
<CodigoEstadoSecundario/>
<LiteralError>La firma de la peticin no es vlida</LiteralError>
<LiteralErrorSec>OSB-382500La accin de llamada de servicio de OSB ha recibido una respuesta de
fallo de SOAPsoapenv:ServerOSB-386200: Error de seguridad de servicio web generalAutenticacionrequest-
7f000101.3956d90b.0.1511ee842f3.N72d1Validacion_Firmarequest-pipeline</LiteralErrorSec>
<TiempoEstimadoRespuesta>0</TiempoEstimadoRespuesta>
</Estado>
<CodigoCertificado/>
</Atributos>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
faultcode: Cdigo que determina el tipo de error producido.

faultstring: Descripcin del tipo de error producido.
IdPeticion: Identificador con el que se realiza la peticin. En esta modalidad no se utiliza.

NumElementos: Nmero de elementos que se incluyen en la peticin.
TimeStamp: Fecha y hora del momento en que se realiza la peticin.

CodigoEstado: Cdigo del error producido.
CodigoEstadoSecundario: Cdigo que especifica con ms detalle el error producido. En esta

modalidad no se utiliza.
LiteralError: Descripcin del error producido.
39 / 43
LiteralErrorSec: Descripcin ms detallada del error producido.
TiempoEstimadoRespuesta: Tiempo en el que se estima que se obtenga la respuesta.

CodigoCertificado: Cdigo del certificado del servicio que se pretende consumir. En esta
modalidad no se utiliza.
40 / 43
5 Apoyo a los desarrolladores

La PAI pretende ofrecer herramientas e informacin al desarrollador, mediante la cual se pueda
facilitar, reducir el tiempo y dedicacin destinado a la integracin con la Plataforma.
5.1 Esqueleto de servicio web

Definimos esqueleto de servicio como las clases necesarias para la creacin de un servicio web
segn las directrices descritas en el documento que nos ocupa. Incluimos en este paquete; las
clases base del servicio, as como las diseadas para realizar otras acciones (seguridad,
auditoria).
5.1.1 Como utilizar gvNIX en el mbito de la PAI

gvNIX es un entorno de trabajo Java de cdigo abierto para el desarrollo rpido de aplicaciones
web, altamente productivo, flexible y que no compromete la calidad de los proyectos. Es una
distribucin de Spring Roo centrada en reutilizar el conocimiento y los estndares de las
organizaciones para construir sus aplicaciones de gestin, cuyo organismo responsable es la
Generalitat Valenciana.
Este entorno, dispone de Add-ons que proporcionan mediante la integracin de CXF las
herramientas necesarias para realizar fcilmente tanto clientes de servicios como servicios web.
La documentacin y el propio entorno estn disponibles en: http://www.gvnix.org/.
Toda la informacin referente a los pasos a seguir para realizar dicho esqueleto con tecnologa
gvNIX, se encuentran ms detalladamente en el documento de e-SIRCA-CONSTRUCCION-
Manual_Usuario_Generacin_de_Servicios_gvNIX.
5.1.2 Bloques que componen el esqueleto

Como hemos citado anteriormente el esqueleto se divide en varias partes, en adelante mdulos.
Por un lado y ms importante tenemos las clases necesarias para generar un servicio web a raz
de un WSDL y unos XML Schemas ya definido y vlidos.
Por otro lado, tenemos los mdulos destinados a auditora, seguridad y gestin de errores.
Describiendo un poco cada uno de estos ltimos:
Mdulo auditora: Se implementan las bases de trazabilidad y auditoria de los mensajes a la

entrada y/o salida.
Mdulo ws-security: A travs de este mdulo, es posible tanto la firma de peticiones de

respuesta mediante un certificado concreto y/o encriptacin de parte del mensaje. Adems,
es posible su extensin para el tratamiento de seguridad en la entrada del mensaje.
41 / 43
Mdulo gestin de errores: Mediante validaciones en la lgica del servicio se permite

transmitir una respuesta errnea, que asociada a un esquema que se encargar de dar el
detalle al error del servicio, cumpliendo con lo definido en 4.4.2 Especificacin Soap Fault.
5.2 Clientes de servicios
Existen diversas tecnologas en la actualidad para consumir los servicios web. No es captulo de
este documento servir de gua tutorial de desarrollo, sino dar unas pautas de ejemplo. En el
Manual de usuario para el consumo de servicios instrumentales y de verificacin se muestra un
cliente de servicio realizado con Apache CXF 2.7. Concretando las recomendaciones que desde la
PAI se han realizado, se opt por clientes basado en CXF 2.7 por su comodidad en la confeccin
de los Stubs y clases asociadas al consumo de servicios web.
42 / 42

Desarrollo y Consumo de Servicios Web Buenas Prácticas v26

Cargado por

Copyright:

Formatos disponibles

Desarrollo y Consumo de Servicios Web Buenas Prácticas v26

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo y Consumo de Servicios Web Buenas Prácticas v26

Cargado por

Copyright:

Formatos disponibles

Sistema Integral Multicanal de Atencin al

e-SIRCA-Desarrollo y consumo de servicios web.

1 Control del documento......................................................................................................... 4

2 Por qu usar servicios web?..............................................................................................7

3 Criterios para crear un Servicios web...............................................................................10

3.4 Estrategias de versionado de servicios y XSD......................................................................19

4 Entorno tecnolgico de la PAI............................................................................................26

5 Apoyo a los desarrolladores..............................................................................................40

1 Control del documento

Creado por DGTI

1.2 Histrico de revisiones

001 13/02/2012 DGM Versin Inicial

002 08/04/2014 DGTI Inclusin particularidades PAI

003 24/04/2014 DGTI SoapFaults y gestin de errores

Eliminar texto/puntos generales y ambiguos. Aadir

006 10/09/2014 DGTI Revisin del documento. Inclusin faultcode.

Reorganizacin del contenido. Inclusin de punto

013 015/01/2015 DGTI Incluido ejemplo del Id_trazabilidad en el punto 4,3,1.

014 27/01/2015 DGTI

Aadida referencia al documento de consumo de

016 27/02/2015 DGTI Correccin de la seccin mustUnderstand

017 02/11/2015 DGTI Mustunderstand en servicios web

018 26/05/2016 DGTI Correccin de la seccin mustUnderstand

Ampliacin Servicios REST, Id_trazabilidad, servicios

020 09/06/2016 DGTI Revisin de Contenido

Modificaciones relativas a cambios de redaccin y

023 12/07/2016 DGTI Revisin del Contenido y Correccin de errores

024 18/07/2016 DGTI Revisin del faultcode, cabecera aplicacin en REST

Modificacin formato Timestamp Id_trazabilidad y

026 03/04/2017 DGTI Correccin de errores

1.3 Estado del documento

Responsable aprobacin Fecha

CONSUMIDORES Y DESARROLADORES DE SERVICIOS

2 Por qu usar servicios web?

Reusabilidad: Un servicio debe ser diseado y construido pensando en su reutilizacin

Interoperabilidad: Permite que los consumidores y los servicios desarrollados en

Gobernabilidad: En un entorno SOA, la gobernanza gua el desarrollo de servicios

desarrolladas en diferentes lenguajes de programacin y ejecutadas en diferentes plataformas

2.1 Servicios web en el mbito de la Administracin electrnica

La recomendacin desde la PAI es seguir estos esquemas en lo que a servicios de verificacin e

Al tratar en la mayora de ocasiones, de informacin sensible a LOPD, se debern tener muy

En el apartado III.6 de la Resolucin de 28 de Junio, por el que se aprueba la Norma Tcnica de

3 Criterios para crear un Servicios web.

3.1 Granularidad de los servicios

3.2 Definiendo el servicio (Contract-First)

3.3 Norma Tcnica

En este captulo se tratan puntos relativos a la aplicacin de buenas prcticas en la definicin

La definicin de los mismo se basa en un conjunto de especificaciones y buenas prcticas

3.3.1 Estilo de construccin del servicio (binding style operation use)

Finalmente, el WSDL debe ser compatible con el WS-I Basic Profile.

3.3.2 Atributo de cabecera SOAP: MustUnderstand

En el escenario de la PAI, el mustUnderstand no tiene sentido ya que los consumidores de los

En el documento Manual de usuario para el consumo de servicios instrumentales y de verificacin

3.3.3 Namespace de Soap envelope

3.3.4 Definicin de atributos y mtodos legibles

3.3.5 Recomendacin respecto a definicin de esquemas

3.3.5.1 Patrn de diseo de XML Schema

3.3.5.2 Representaciones del null en XML Schema

31: