Grupo de apoyo a la preparacin de la XXII

convocatoria de oposiciones al Cuerpo Superior de

Sistemas y Tecnologas de la Informacin de la
Administracin del Estado

INTEGRACIN DE COMPONENTES, SERVICIOS Y

APLICACIONES
El objetivo de esta gua es enumerar las diferentes opciones que tenemos a la hora de conseguir que
varias aplicaciones trabajen de forma conjunta, sin entrar a describir en profundidad las diversas
tecnologas. Se consideran las situaciones en las que puede ser conveniente emplear cada
tecnologa, as como los escenarios de uso habituales.

Servicios Web (WS)

Actualmente es la tecnologa por excelencia para integrar aplicaciones. Es la primera opcin que
debemos contemplar, salvo que se den circunstancias que desaconsejen su uso.

Existen multitud de especificaciones en torno a los servicios web, mayoritariamente emitidas por los
consorcios W3C y OASIS. En la mayora de los casos, es suficiente con emplear el conjunto de
protocolos incluidos en el WS-I Basic Profile (perfil bsico definido por la Organizacin para la
Interoperabilidad de Servicios Web): SOAP para describir el formato de los mensajes y WSDL como
descriptor de los servicios son los protocolos principales.

Los WS son neutrales desde el punto de vista del lenguaje de programacin y las plataformas de
ejecucin. Existen implementaciones certificadas en el perfil bsico WS-I para mltiples plataformas y
lenguajes: Zend Framework para PHP, gSOAP para C/C++, ASP.Net 2.0 o WCF para la plataforma
.Net, etc. En el entorno JavaEE, las implementaciones de la API JAX-WS (JSR 224) son conformes al
perfil bsico WS-I. Apache Axis 2 es una implementacin bastante popular de la JSR 224, distribuida
bajo licencia libre Apache Software Foundation.

SOAP es independiente del transporte. Lo que se entiende normalmente al hablar de WS es SOAP

sobre HTTP o HTTPS, pero tambin sera vlido el intercambio de mensajes SOAP sobre FTP,
SMTP, directamente sobre conexiones TCP/UDP, etc. La principal ventaja de SOAP sobre HTTP es
que no presenta problemas para atravesar los firewalls, ya que estos se configuran habitualmente
para dejar pasar el trfico HTTP.

REST nace como una alternativa para simplificar la comunicacin entre procesos. Est basado en un
esquema cliente-servidor, y utiliza el protocolo HTTP como modelo central de comunicacin. Mientras
que trabajar con SOAP en JavaScript, por ejemplo, implicar escribir una importante cantidad de
cdigo porque la estructura XML debe ser creada cada vez, REST resuelve este conflicto basndose
en simples direcciones URL. En casi todas las situaciones los servicios se comunicarn via URL, a
travs de comandos GET, POST, PUT y DELETE. Esta notable sencillez es el gran punto fuerte de
REST. Prcticamente no tiene costos de aprendizaje, y de manera directa se pueden desarrollar
servicios web sin la necesidad de pesados protocoles de comunicacin.

Comparacin SOAP - REST

Si bien ambos proveen la misma funcionalidad (comunicar dos servicios web), sus races son
distintas. REST est basado en un esquema cliente-servidor, mientras que SOAP es un protocolo
dedicado al intercambio de datos entre dos puntos dedicados. Esto ya saca a relucir una diferencia
importante desde el punto de vista arquitectnico. Con respecto a seguridad, ninguno es
particularmente ms seguro que el otro, aunque SOAP cuenta con extensiones que garantizan
seguridad punto a punto. Si tiene ventajas SOAP desde el punto de vista de transacciones,
contemplando nociones como Two-Phase commit, y otros enfoques para el manejo de transacciones

1
 Grupo de apoyo a la preparacin de la XXII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologas de la Informacin de la
Administracin del Estado

distribuidas. REST, priorizando un protocolo simple y ligero, adolece de este tipo de cuestiones. En
cuanto a la posibilidad de adaptarse a diferentes plataformas, si bien REST depende del protocolo
HTTP, SOAP ofrece muchas extensiones, con sutiles diferencias entre s, y comunicarlas a todas en
un lenguaje comn no es tan simple en muchas ocasiones. Luego, REST parece salir mejor parado
de esta situacin, teniendo como nica precondicin la comunicacin via URLs.
REST permite inmeros formatos de datos, dando por ejemplo al desarrollador la posibilidad de
utilizar JSON que normalmente es ms rpido y como permite la utilizacin de JSON, permite tambin
un mejor soporte a los clientes del explorador. SOAP solamente permite XML.

Lo ms habitual al hablar de WS es considerar un modelo peticin-respuesta sncrono, pero las

especificaciones son suficientemente flexibles para permitir otros modelos: peticin-respuesta
asncrona, notificacin en un solo sentido (sin respuesta del servidor), etc.

Mecanismos de integracin de aplicaciones tradicionales

Deben ser tenidos en cuenta como posible alternativa al uso de WS. Los principales son los
siguientes:

Envo de ficheros.- Es el mecanismo de integracin ms primitivo, en el que una aplicacin genera

un fichero con un formato preestablecido y lo deposita en una ruta determinada (posiblemente
mediante envo FTP a un servidor remoto); otra aplicacin lee este fichero y lo procesa, y genera
ficheros de respuesta que luego pueden ser recogidos por la primera aplicacin. Aunque presenta
desventajas evidentes que lo hacen poco mantenible (falta de formatos estandarizados, alto grado de
acoplamiento entre las aplicaciones,...), puede ser una buena solucin cuando se requiere una
transmisin y procesado de grandes volumenes de datos, especialmente en entornos de
comunicacin cerrados (en los que las aplicaciones que van a generar y consumir la informacin se
conocen de antemano). En el mbito tributario y de la Seguridad Social, todava existen mecanismos
de este tipo para la consulta y/o envo masivo de informacin, utilizados frecuentemente por
empresas y otros organsimos pblicos.

Base de datos compartida.- Supone una mejor respecto al envo de ficheros. Mltiples aplicaciones
comparten un esquema de datos sobre una misma base de datos fsica. Evita duplicidad en el
almacenamiento y la transferencia de datos entre aplicaciones. El empleo de vistas lgicas permite
cierto grado de aislamiento entre las aplicaciones. Es una buena solucin para compartir informacin
e integrar aplicaciones dentro de la propia organizacin. Es complicado implementar un patrn de
interaccin del tipo peticin-respuesta.

Remote Procedure Call (RPC).- Nombre genrico para todos los mecanismos en los que un
programa es capaz de llamar a una rutina de otro programa que se est ejecutando en una mquina
remota y obtener una respuesta. En su da fueron populares los estndares DCOM o CORBA. SOAP
es un tipo de mecanismo RPC; de hecho, es la evolucin del antiguo estandar XML-RPC. La nica
ventaja que pueden presentar estos mecanismos clsicos respecto a los servicios web es que
introducen menos sobrecarga de informacin (las cabeceras SOAP y la serializacin XML no resulta
ptima para transmitir grandes volumenes de informacin). No obstante, no hay demasiados motivos
para considerar este tipo de integracin, salvo que haya que dar soporte a la integracin de
aplicaciones heredadas (legacy) que no permitan otro tipo de interaccin.

Middleware de integracin de aplicaciones

Son productos software cuya finalidad es facilitar la integracin de aplicaciones heterogneas. Son
caractersticas habituales de este tipo de productos:
Independencia del fabricante, la plataforma o el lenguaje de programacin de las
aplicaciones, ofreciendo adaptadores para mltiples transportes y protocolos (HTTP, FTP,
REST, SOAP, SAP RFC, DCOM, CORBA, objetos Java simples,...)
Mapeo entre productores y consumidores de informacin y enrutado de mensajes dinmico y
basado en reglas.

2
 Grupo de apoyo a la preparacin de la XXII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologas de la Informacin de la
Administracin del Estado

Encolado y priorizacin de mensajes.

Orquestacin de servicios.
Calidad de servicio: validacin de mensajes, seguridad (autenticacin, encriptacin), entrega
confiable, gestin de transacciones,etc.
Herramientas de gestin: monitorizacin, mtricas, auditora, registro de eventos,etc.

Bsicamente, los productos que se definen como middleware de integracin caen en una de las
siguientes categoras: Buses de Servicios Empresariales (Enterprise Service Bus o ESB) o
Colas/Brokers de Mensajera Asncrona (Message Queues o MQ). Los primeros estn ms
orientados al paradigma peticin/respuesta, mientras que los segundos se orientan hacia el
paradigma publicacin/subscripcin. Para una descripcin ms detallada de los ESB, vase la gua
Mdulos Software > Herramientas ESB.

El cuadrante mgico de Gartner para herramientas de integracin de aplicaciones publicado en junio

de 2013 sita como lderes del mercado a los fabricantes Software AG (webMethods), IBM
(WebSphere MQ, WebSphere Registry and Repository), Oracle (Oracle SOA Suite), Tibco Software
(ActiveMatrix ESB, ActiveMatrix BusinessWorks, Business Connect) y Microsoft (BizTalk Server).

Escenarios habituales de integracin de aplicaciones

Servicios comunes dentro de la Organizacin.- En los sistemas de informacin de todos los
organismos administrativos existen aplicaciones horizontales cuya finalidad es ofrecer un
determinado servicio a otro conjunto de aplicaciones internas. Ejemplos de este tipo de servicios son
el registro electrnico, el gestor documental/archivo de expedientes, el portafirmas electrnico,
servicios de autenticacin mediante certificado electrnico, servicio de notificaciones electrnicas,
plataforma de envo de SMS, etc. Es recomendable que todos estos componentes de servicio
horizontales implementen una interfaz WS, de forma que se consiga maximizar la interoperabilidad
con distintas plataformas y lenguajes de programacin y minimizar la dependencia con las
aplicaciones consumidoras. En el caso concreto de los gestores de contenidos, es habitual usar el
estndar CMIS (Content Management Interoperability Services), que es una extensin de SOAP.

Servicios compartidos entre Administraciones.- La mayor parte de servicios reutilizables de las

Administraciones Pblicas accesibles a travs de la red SARA implementan una interfaz de servicios
web para su utilizacin, permitiendo que cada organismo integre estos servicios en sus propias
aplicaciones de tramitacin. Algunos de estos servicios transversales de uso muy comn y que
cuentan con una interfaz WS son: el servicio Valide para verificacin de validez de certificados y
firmas electrnicas, los servicios de la plataforma de sellado de tiempo TS@, la pasarela de pago
telemtico, la consulta del punto general de entrada de facturas electrnicas (FACE), los servicios de
publicacin de licitaciones y adjudicaciones en la Plataforma de Contratacin del Estado (PLACE),etc.
Puede consultarse ms informacin sobre servicios compartidos en la seccin Transversal >
Servicios Red SARA.

Plataforma de Intermediacin.- Como caso particular de servicio horizontal accesible a travs de la

Red SARA, la Plataforma de Intermediacin se utiliza para recabar, previa autorizacin, determinada
informacin sobre ciudadanos que obra en poder de otros organismos: datos fiscales y de la
seguridad social, titulaciones acadmicas oficiales, datos catastrales,... La obtencin de datos se
realiza mediante llamadas a WS sncronas o asncronas. El proveedor de informacin debe publicar
tambin sus propios WS para que la Plataforma de Intermediacin los invoque cuando sea necesario.

Obligaciones de suministro de informacin.- Determinados organismos pblicos ejercen una

funcin de control o fiscalizadora sobre otros organismos, por ejemplo, en los mbitos de la
contratacin pblica, la ejecucin del presupuesto o la concesin de ayudas y subvenciones. Los
sistemas informticos que mantienen estos rganos de control para la remisin de informacin,
adems de tener una interfaz web de consulta y envo, suelen incorporar diversos mecanismos de
integracin (tales como interfaces WS o procesamiento masivo de ficheros), con el fin de que los

3
 Grupo de apoyo a la preparacin de la XXII
convocatoria de oposiciones al Cuerpo Superior de
Sistemas y Tecnologas de la Informacin de la
Administracin del Estado

organismos obligados al suministro de informacin puedan automatizar estos procesos

incorporndolos a sus propios sistemas de tramitacin.

Federacin de sistemas de informacin.- Puede aparecer tambin el caso de una Administracin

que tenga que compartir determinados registros o catlogos de informacin con otras
administraciones de mbito nacional o internacional, con el fin de crear un registro o catlogo
federado: catlogos de biblioteca, historial sanitario, registros policiales, catlogo de bienes
protegidos, etc. En estos escenrios, cada administracin mantiene su propio sistema, pero debe
habilitar mecanismos de integracin que permitan al resto de administraciones extender sus servicios
de bsqueda y consulta. Lo habitual es que se defina una interfaz y un formato de intercambio
normalizados, y puede haber un organismo que haga de intermediario o pasarela de consultas.