U3 Arquitecturas y Patrones Aplicaciones Distribuidas

Arquitecturas y patrones de
aplicaciones distribuidas
Índice
1 Charla 1: Introducción a los patrones de diseño. Algunos patrones básicos................3
1.1 Por qué patrones.......................................................................................................3
1.2 Patrones JavaEE.......................................................................................................4
1.3 Singleton (GoF)....................................................................................................... 6
1.4 Facade (GoF)........................................................................................................... 8
1.5 Data Access Object - DAO (JavaEE).................................................................... 10
1.6 Transfer Object...................................................................................................... 12
1.7 Factory (GoF).........................................................................................................13
2 Charla 2: Arquitecturas Java EE................................................................................ 18
2.1 Bloques Arquitectónicos........................................................................................18
2.2 Arquitectura y Java EE.......................................................................................... 23
2.3 Propuestas de Arquitecturas Java EE.....................................................................27
2.4 Para Saber Más...................................................................................................... 38
3 Integración de aplicaciones........................................................................................ 40
3.1 ¿Qué es la EAI?..................................................................................................... 40
3.2 Sistemas de Información de Empresas (EIS).........................................................43
3.3 Arquitectura de aplicaciones existentes................................................................. 44
3.4 Arquitectura de aplicaciones modernas................................................................. 48
3.5 Retos que plantea la EAI........................................................................................51
3.6 Capas en la integración de aplicaciones.................................................................52
3.7 Uso de middleware para EAI.................................................................................54
3.8 Servicios de infraestructura necesarios para la integración................................... 59
3.9 Técnicas de integración..........................................................................................63
3.10 Opciones alternativas a la integración..................................................................65
3.11 Arquitectura de integración..................................................................................67
Copyright © 2011-2012 Dept. Ciencia de la Computación e IA All rights reserved.

Arquitecturas y patrones de aplicaciones distribuidas
4 Arquitectura orientada a servicios (SOA).................................................................. 76

4.1 Razones para introducir SOA................................................................................ 76
4.2 El concepto de servicio.......................................................................................... 77
4.3 Definición de SOA. Elementos que la componen................................................. 79
4.4 Características de los servicios de una SOA..........................................................86
4.5 Capas en aplicaciones orientadas a servicios.........................................................87
4.6 El gobierno SOA (SOA governance).....................................................................89
4.7 SOA y JBI.............................................................................................................. 93
4.8 SOA y Servicios Web............................................................................................ 96
4.9 SOA y BPM........................................................................................................... 98
2
1. Charla 1: Introducción a los patrones de diseño. Algunos patrones

básicos
Aunque cada aplicación JavaEE tiene peculiaridades que la hacen única, en el proceso de
desarrollo de casi todas las aplicaciones es necesario solucionar una y otra vez los mismos
problemas: autentificación del cliente, persistencia de datos, separación entre
presentación, lógica y control,... En lugar de reinventar continuamente la rueda, es mucho
más productivo aplicar estrategias que ya hayan funcionado con anterioridad. Esta idea es
la que lleva a la definición de los patrones software.
1.1. Por qué patrones
En ingeniería del software, un patrón (pattern) es una solución ya probada y aplicable a

un problema que se presenta una y otra vez en el desarrollo de distintas aplicaciones y en
distintos contextos. Es importante destacar que un patrón no es en general una solución en
forma de código directamente "listo para usar", sino más bien una descripción de cómo
resolver el problema y de ante qué circunstancias es aplicable.
Los patrones software fueron popularizados en el libro Design Patterns: Elements of
Reusable Object-Oriented Software, que trata de patrones genéricos, aplicables a una
amplia gama de contextos y a cualquier lenguaje orientado a objetos. Este libro
popularizó el "movimiento" de patrones y se ha convertido en un clásico, ampliamente
referenciado y que muchos han tomado como base para añadir patrones nuevos. Los
autores de Design Patterns... son Erich Gamma, Richard Helm, Ralph Johnson y John
Vissides, aunque de manera jocosa y popular son más conocidos como el Gang of Four.
De hecho, en muchas publicaciones serias los patrones que aparecen en Design Patterns
se referencian con las siglas GoF.
Ante todo este floreciente movimiento en torno a los patrones cabe preguntarse si
realmente aportan beneficios. Se suele argumentar que los patrones ofrecen tres ventajas
fundamentales:
• Están ya probados: son soluciones que han sido utilizadas con anterioridad de
manera repetida y se ha comprobado que funcionan.
• Son reutilizables: corresponden con problemas que no son específicos de un caso
concreto, sino que se presentan una y otra vez en distintas aplicaciones.
• Son expresivos: cuando un equipo de desarrolladores tiene un vocabulario común de
patrones, se puede comunicar de manera fluida y precisa las ideas fundamentales
sobre el diseño de una aplicación.
Por supuesto, los patrones no pueden ser la solución a todos los problemas de diseño y
desarrollo de aplicaciones JavaEE. Como cualquier herramienta o metodología son
susceptibles de malos usos, y de abusos (uso "compulsivo" simplemente "porque son
buenos"). La experiencia y el sentido común dictarán cuándo son apropiados y cómo
3
utilizarlos.
1.2. Patrones JavaEE
Los patrones JavaEE están orientados específicamente a los problemas comunes a todas
las aplicaciones JavaEE. Algunos están basados en los patrones originales mientras que
otros son más específicos del tipo de problemas que surgen específicamente en JavaEE,
bien sea por los tipos de aplicaciones que se suelen desarrollar con la plataforma o por las
características (o deficiencias, incluso) de la tecnología. Los primeros fueron publicados
en el libro Core J2EE Patterns, convertido también en un clásico dentro del "mundillo"
JavaEE. En la actualidad son muchos los libros y los sitios web dedicados íntegramente a
patrones para aplicaciones JavaEE o con algún apartado sobre ellos.
Una versión resumida del catálogo de Core J2EE Patterns está disponible en su sitio web.
Siguiendo la idea de dividir la arquitectura de una aplicación en varias capas, los patrones
se clasifican atendiendo a la capa a la que pertenecen. En la figura 5 aparece el esquema
general en la que se muestra la situación de cada uno de los 21 patrones en el modelo de
capas y las relaciones que existen entre ellos. Iremos viendo con detalle algunos de estos
patrones y sus interrelaciones en las distintas charlas del módulo.
4
Catálogo de patrones de Core J2EE Patterns

En los patrones que vamos a ver en el módulo mezclaremos por igual patrones JavaEE
con patrones genéricos. El resultado es una lista de patrones bastante ad-hoc, en cuanto al
orden de explicación que seguiremos y en cuanto a los patrones que trataremos frente a
los que dejaremos de lado. Hay que tener en cuenta que el objetivo no es dar una lista
extensiva de los mismos. Si a los 21 patrones JavaEE se les suman los 23 fundamentales
del GoF surge un número demasiado elevado para las horas disponibles. Por ello se ha
optado por describir solo algunos. El criterio de inclusión no ha sido su importancia per
se, sino el hecho de que sea un patrón de uso habitual en aplicaciones JavaEE. Para una
lista de patrones más "estándar" se puede consultar cualquiera de los recursos
especificados en la bibliografía.
5
Junto al nombre de cada patrón especificaremos si se trata de un patrón JavaEE o procede

del GoF.
1.3. Singleton (GoF)
1.3.1. Problema a resolver
Hay muchos casos en los que solo necesitamos una instancia de una determinada clase.
Ejemplos típicos son clases que representan las preferencias del usuario o la
configuración del sistema, o clases que sirven de interfaz con dispositivos físicos.
En estos casos hay que asegurarse de poder obtener una referencia a dicha instancia desde
cualquier punto del código, y que solo haya una instancia creada, para evitar posibles
problemas o inconsistencias. Una posible solución es definir variables globales (o sea,
static), pero esto tiene dos problemas:
• Por descuido, se podría instanciar una misma variable en dos sitios distintos, lo que
"machacaría" el valor anterior.
• El orden y momento de inicialización de las variables depende del compilador, lo cual
puede ser delicado si unas dependen de otras y están en lugares distintos.
1.3.2. Discusión y beneficios
El patrón singleton nos permite asegurar que de una clase habrá solo una instancia, y
proporciona un punto de acceso a ella global a todo el código. El diagrama de clases es
muy sencillo, ya que se compone de una única clase:
Patrón singleton
El método getInstance() nos sirve para obtener la referencia a la única instancia de la
clase. Además dicha instancia está almacenada dentro de la propia clase como una
variable de tipo static (esto último puede resultar curioso, pero no deja de ser un "truco
ingenioso" perfectamente legal para el compilador). Por supuesto el singleton tendrá otros
métodos, los servicios que proporcione la clase.
La implementación de un singleton podría hacerse de varias formas, pero casi siempre se
utiliza el mismo tipo de código. Vamos a resumir las ideas que nos llevarán a la
implementación final:
• Si el constructor de una clase es público, podrá llamarse desde cualquier otra. Por
tanto, si queremos asegurar un control de la creación de instancias, no podemos tener
un constructor público, debemos hacerlo privado:
6
public class MiSingleton {

private MiSingleton() {
//aqui va el codigo del constructor
}
}
• Evidentemente, aunque el código anterior sea una definición legal que compilará
perfectamente, no parece tener mucho sentido. Si el constructor es privado, solo se
podrá llamar desde un objeto de la clase MiSingleton. Pero ¡no podemos instanciar
objetos de esa clase, porque el constructor es privado!. La solución al aparente dilema
consiste en utilizar un método estático para llamar al constructor:

}
public static MiSingleton getInstance() {
return new MiSingleton();
}
}
//código aparte...
MiSingleton ms = MiSingleton.getInstance();
• Con esto ya conseguimos controlar el acceso al constructor y poder llamarlo desde
fuera de la clase. Lo único que nos falta es asegurarnos de que en todo momento
existe una única instancia de MiSingleton. El "truco" consise en almacenar dicha
instancia dentro de la propia clase MiSingleton (como una variable static) y en
introducir código en getInstance que chequee si dicha instancia está creada o no,
para devolverla o en caso contrario devolver un nuevo MiSingleton.

//la unica instancia que existe de esta clase
private static MiSingleton unico = null;
}
public static MiSingleton getInstance() {
//instanciar el singleton si no existe
if (unico == null) {
unico = new MiSingleton();
}
//devolver el singleton
return unico;
}
}
//código aparte...
MiSingleton ms = MiSingleton.getInstance();
Como puede verse, este código es una especie de "idea feliz" que consigue de forma
elegante el objetivo que nos proponíamos. Aunque quizá esto podría conseguirse de otras
formas, esta es ampliamente utilizada y conocida, por lo que merece la pena usarla en
lugar de intentar formas propias de hacerlo (después de todo, esta "reutilización de ideas"
es consustancial a la idea misma de patrones software).
7
¡Cuidado!
El código visto no asegura que solo exista una instancia si se permiten varios threads (piénsese
que pasaría si los dos threads comprueban "a la vez" que no existe una instancia del objeto y la
crean ¡por dos veces!). Consultad la bibliografía adicional para ver formas de solucionar este
problema (basadas en general en el uso de synchronized).
1.3.3. Relación con otros patrones
En aplicaciones JavaEE, son múltiples los casos en los que solo se necesita una
instancia de un objeto para toda la aplicación (aunque a este objeto lo puedan llamar
varios threads simultáneamente). Piénsese por ejemplo en un objeto encargado de
calcular costes de envío de pedidos. Los costes según métodos de envío, plazos de
recepción, peso del paquete, etc. son información global para toda la aplicación, de modo
que se puede implementar como un singleton.
Un uso típico de este patrón en aplicaciones enterprise es para implementar un encargado
global de localizar recursos JNDI como por ejemplo conexiones JDBC, EJBs, etc. Esto es
lo que se conoce como Service Locator.
1.4. Facade (GoF)
Supongamos que tenemos un sistema complejo, que agrupa multitud de clases, y para
realizar una tarea tenemos que llamar a varios métodos de estas clases en una secuencia
precisa. Por ejemplo, supongamos un sistema domótico en el que tenemos el siguiente
diagrama de clases
Sistema domótico inicial

Imaginémonos las operaciones que hay que realizar al entrar en casa: hay que desactivar
8
la alarma, poner el aire acondicionado a nuestra temperatura preferida, y encender las

luces. Esto se podría hacer con un código similar al siguiente:
...
//de alguna forma, ya hemos obtenido una referencia a la alarma,
configuración, aire y luces
//y tenemos también el nombre de usuario y el password
...
//desactivar la alarma
alarma.desactivar(password);
//obtener preferencias de usuario
Preferencias prefs = configuracion.getPreferencias(usuario);
//poner el aire acondicionado a la temperatura deseada
Float temp = (Float) prefs.getPreferencia("temperatura");
aire.setTemp(temp.floatValue());
//poner las luces en "auto" si es la preferencia del usuario
String luces = (String) prefs.getPreferencia("luces");
if (luces.equals("auto"))
luces.setAuto(true);
...
Como se ve, una operación tan sencilla en apariencia implica manejar un número elevado
de objetos y métodos. salirDeCasa() sería igual de tedioso: apagar las luces, el aire,
activar la alarma.... Un cliente que quiera invocar una de estas operaciones no debería
necesitar tanto código.
Parece inmediata la idea de crear una clase a la que trasladaremos todo este código y a la
cual puedan acceder los clientes que lo necesiten. Esto es ni más ni menos que un facade.
Patrón facade
Un Facade (fachada) consiste en implementar un interfaz simplificado para un
sistema complejo. La idea es implementar una clase con un interfaz sencillo y que
encapsule los detalles de la interacción entre todas las clases del sistema. Es importante
9
notar que se sigue permitiendo el acceso directo a las clases del sistema a los clientes que
necesiten "acceso a bajo nivel" pero se simplifica la interacción para los que no necesiten
más que operaciones comunes.
En aplicaciones JavaEE, las fachadas se suelen utilizar para proporcionar un "frontal de
servicios" de la capa de negocio. De este modo, la interacción de los clientes (web, swing,
etc...) con esta capa se simplifica considerablemente. Como veremos en charlas
posteriores, en aplicaciones distribuidas las fachadas también mejoran la eficiencia del
sistema, ya que las operaciones "de fachada para adentro" serán todas locales y la única
llamada remota será la del cliente a la fachada.
1.5. Data Access Object - DAO (JavaEE)
Supongamos que el código de acceso a los recursos de datos (normalmente bases de datos
relacionales) está incluído dentro de clases que tienen además otras responsabilidades
diferentes. Por ejemplo supongamos que en una biblioteca (el ejemplo que usaremos en
las sesiones de integración) tuviéramos una clase GestorPrestamos que se ocupara de
realizar y gestionar los préstamos de libros. En una primera aproximación podríamos
hacer que esta clase se encargara tanto de la lógica de negocio (por ejemplo comprobar si
un usuario es "moroso" antes de prestarle un libro) como del acceso a datos (introducir el
préstamo en una hipotética tabla de préstamos).
Este tipo de enfoque lleva a sistemas poco modulares y difícilmente mantenibles. En
nuestro caso, el cambio de las reglas de negocio implicaría cambios en GestorPrestamos.
El problema es que además, un cambio en la base de datos también implica cambios en
GestorPrestamos.
Principio básico de diseño

Distintas responsabilidades no deben ser delegadas en la misma clase. Este es un principio
básico del desarrollo de software, propuesto originalmente por Dijkstra en los años 70 (aunque
no exactamente en esta forma), que lo llamó separation of concerns o separación de
incumbencias.
Claramente la implementación de GestorPrestamos descrita con anterioridad viola el

principio de separación de incumbencias. Si nos llevamos la persistencia de datos a una
clase separada y dejamos GestorPrestamos solo con la lógica de negocio conseguimos un
sistema mucho más modular y mantenible.
El DAO (Data Access Object) es un patrón de diseño directamente basado en el

separation of concerns, en el que se separa la persistencia de datos del resto de
10
funcionalidades del sistema. El siguiente esquema UML muestra una estructura de clases
típica para el DAO de préstamos de la biblioteca.
DAO
Como se observa en la figura, el DAO es el punto de entrada al almacén de datos (aquí
representado por un DataSource JDBC) y proporciona operaciones de tipo CRUD
(Create-Read-Update-Delete).
Destacamos algunos puntos importantes:
• Como se ve, el DAO no tiene por qué implementar todas las operaciones CRUD
(quizá en nuestro sistema no se puedan borrar los préstamos, solo devolver el libro
quedando el registro del préstamo en la base de datos).
• En general (aunque esto es una decisión de diseño), por cada objeto de negocio en
nuestro sistema, crearemos un DAO distinto. En nuestro caso además del
PrestamosDAO podríamos tener también un UsuarioDAO y un LibroDAO.
• Aunque aquí el almacén de datos se representa como una base de datos compatible
JDBC no tiene por qué ser siempre así, como discutiremos a continuación.
• La información que devuelve o se le pasa al DAO se encapsula en objetos de tipo
transfer object (en nuestro caso la clase Prestamo), que, simplificando, no son más
que "contenedores de información" y que trataremos en la discusión del patrón
correspondiente.
Hay que tener en cuenta que si el DAO se considera un patrón J2EE (o hablando más en
general un patrón de aplicaciones de tipo enterprise) es porque prácticamente todas las
aplicaciones J2EE de cierta dimensión hacen uso intensivo de almacenes persistentes de
datos (normalmente bases de datos relacionales) aunque muchas aplicaciones J2SE no lo
hagan.
Otro importante beneficio del DAO es la independencia del almacén de datos: el cambio
de motor de base de datos o el paso de usar un pequeño archivo XML a usar una base de
datos relacional para almacenar datos solo afectará al DAO y no a las clases encargadas
de la lógica de negocio o de presentación. Se suele usar el patrón Factory para poder
instanciar los DAOs reduciendo al máximo la dependencia del DAO concreto a crear (por
ejemplo de MySQL, Oracle, XML, fichero .properties, ...).
Principio básico del diseño
11
Identificar los aspectos de la aplicación que cambian o pueden cambiar y separarlos de los
que van a permanecer fijos. Muchos patrones de diseño se basan en encapsular de alguna forma
la parte que cambia para hacer más fácil la extensión del sistema. En este caso, el DAO
encapsula la parte que puede variar (la interacción con la fuente de datos).
1.5.2.1. Relación con otros patrones

• Transfer object: la información que se envía/recibe del DAO se "empaqueta" en estos
objetos.
• Factory: con el objeto de conseguir la independencia del almacén de datos,
comúnmente se usa este patrón para instanciar los DAOs.
1.6. Transfer Object
Cuando se trabaja con arquitecturas de varias capas, un problema típico es cómo pasar los
datos de una capa a otra. En el caso de la biblioteca que veíamos anteriormente, cuando
por ejemplo queremos ver los datos de un libro, éstos tienen que sacarse de la base de
datos, pasando por las capas de datos y negocio hasta la capa de presentación. Solicitar
los datos uno a uno (título, autores, ISBN,...) no es una opción adecuada ya que en
aplicaciones distribuidas incrementa innecesariamente el número de llamadas remotas.
Necesitamos una forma compacta y organizada de pasar estos datos de una capa a otra.
Si la aplicación no es distribuida, no va a existir este problema. No obstante, en todas las
aplicaciones se suele plantear el caso de que la capa de presentación puede necesitar
menos datos de los almacenados en un objeto del modelo del dominio o bien puede
necesitarlos organizados de otra manera. Por ejemplo, quizá en un listado de libros nos
baste con el título y el autor y no sea necesario obtener de la base de datos todos los
demás campos.
Un transfer object no es más que un objeto que "empaqueta" datos para que puedan viajar
entre las capas. Dicho objeto contendrá todos los datos que nos interesen accesibles
mediante getters y setters. Por ejemplo, como ya se vio en el patrón DAO la
comunicación entre la capa de negocio (clase GestorPrestamos) y la de datos (el propio
DAO) se hace en base a transfer objects.
Principio básico de diseño

L os Transfer Object violan un principio clásico del diseño orientado a objetos que dice que éstos
deben tener estado y comportamiento, cosa que no tienen los TOs.
12
Nótese que aunque los transfer objects están directamente relacionados con los objetos
del modelo de objetos del dominio, no se trata de los mismos objetos. Los objetos del
dominio pueden contener lógica de negocio mientras que como ya se ha dicho los transfer
objects son meros almacenes de datos. Además no tiene por qué haber una relación
uno-a-uno entre objetos del dominio y transfer objects, como se discutirá a continuación.
Destacamos algunos puntos importantes:
• Por cada objeto de negocio puede haber más de un transfer object. De hecho, una
estragegia muy común es usar un transfer object distinto para cada caso de uso. Por
ejemplo, al ver los datos de un solo libro vamos a mostrar probablemente mucha más
información que la que aparece en un listado de varios libros, por lo que podemos
tener un LibroTO y un LibroListaTO.
• Un problema importante es el de la sincronización entre los valores del transfer object
y los del objeto del dominio que representa. Hay que asegurarse de que dichos valores
están actualizados o que una falta de actualización de los mismos no conlleve
consecuencias graves (caso típico de las operaciones de solo lectura). En caso de usar
los TO tanto para mostrar datos como para almacenarlos (TOs actualizables) habrá
que llevar sumo cuidado para sincronizar la información de los TOs que hayan
cambiado.
1.7. Factory (GoF)
El patrón factory pretende proporcionar una buena manera de instanciar objetos cuando la
clase a la que pertenece el objeto instanciado puede cambiar, bien por modificaciones en
el diseño o bien porque en tiempo de compilación no se conoce la clase exacta.
Por poner un ejemplo concreto, supongamos que tenemos un sistema de mensajería
instantánea. Los mensajes se pueden enviar a través de varios canales (TCP/IP, SMS,
buzón de mensajes,...) y hemos implementado una serie de clases que nos permiten hacer
el envío por ellos: EnvioTCP, EnvioSMS, EnvioBuzon,... todas estas clases implementan la
misma interfaz ICanal, y el usuario elige el medio a través del GUI del programa. El
código que envía el mensaje podría ser similar al siguiente:
Mensaje mensaje;
ICanal canal;
...
mensaje = GUI.getMensaje();
nombreCanal = GUI.getOpcionEnvio();
if (nombreCanal.equals("TCP"))
canal = new EnvioTCP();
else if (nombreCanal.equals("SMS"))
canal = new EnvioSMS();
else if (nombreCanal.equals("buzon"))
canal = new EnvioBuzon();
canal.enviar(mensaje)
13
El código anterior es tedioso de modificar si se cambian los posibles canales de envío o

aparecen canales nuevos (bluetooth, ...).
Nota:
Un principio básico de un buen diseño es que el código debería estar abierto a la extensión
pero cerrado a la modificación. Es decir, que el diseño debería ser tal que nos permitiera
extender la funcionalidad donde fuera necesario, pero al mismo tiempo consiguiera que esta
extensión no suponga cambios en el código ya existente. Cualquier modificación de código en
funcionamiento podría suponer la introducción de bugs en el sistema.
Es evidente que el código anterior no cumple esta condición, ya que es necesario insertar
líneas de código y recompilar la clase para extender la funcionalidad.
1.7.2. Simple factory
Recordemos de nuevo ese principio básico del diseño que dice que hay que separar lo que
varía de lo que permanece igual. En nuestro caso hemos visto que al tomar la precaución
de usar una interfaz común para todas las clases lo que puede cambiar es la instanciación
de la clase concreta que necesitamos. Por tanto, vamos a encapsularla y separarla del
resto.
Si tuviéramos una clase auxiliar que nos proporcionara instancias concretas de la clase o
interfaz deseados (en nuestro caso ICanal) podríamos hacer algo como:
Mensaje mensaje;
ICanal canal;
...
mensaje = GUI.getMensaje();
nombreCanal = GUI.getOpcionEnvio();
canal = FactoriaCanales.crearCanal(nombreCanal);
canal.enviar(mensaje)
Que es un código mucho más limpio que la versión anterior. Ahora trasladamos los
detalles de la instanciación a FactoriaCanales, que se ha convertido en una especie de
factoría o fábrica de objetos:
public class FactoriaCanales {

public static ICanal crearCanal(String nombre) {
ICanal canal;
if (nombre.equals("TCP"))
canal = new CanalTCP();
else if (nombre.equals("SMS"))
canal = new CanalSMS();
else if (nombre.equals("buzon"))
canal = new CanalBuzon();
return canal;
}
}
14
A primera vista parece que simplemente hemos trasladado el problema a la clase

FactoriaCanales. Es parcialmente cierto, en el sentido en que todavía es necesario
modificar esta clase si se modifican o crean canales nuevos, pero no será necesario
modificar ni recompilar ninguna de las clases que llamen al método
FactoriaCanales.crearCanal (que podrían ser muchas). Hemos acotado los cambios
necesarios a una clase únicamente.
Usando la terminología de patrones, la clase anterior es una "factoría simple" (simple
factory). No es exactamente el patrón factory sino una versión simplificada de este.
Podéis compararar el diagrama UML del simple factory con el del factory del apartado
siguiente para ver las diferencias.
Simple factory
En el diagrama anterior, Cliente es cualquier clase que requiera los "servicios" del
Simple Factory para crear objetos.
Aviso:
En algunas fuentes de referencia se da como patrón factory esto que no es sino una versión
simplificada. Esto no supone un problema siempre que se tenga clarpo de qué se está hablando y
la diferencia entre ambas "versiones".
1.7.3. Factory method
Supongamos que el problema anterior se complica: ahora tenemos que distinguir entre
usuarios lite, que no pagan una cuota y por tanto tienen algunas restricciones (número
máximo de SMS, tiempo máximo de conexión, tamaño más limitado del buzón,..) y
usuarios pro, que tienen menos restricciones en la mensajería. Necesitamos por tanto
crear un canal lite y pro de cada tipo (SMS, TCP,...). Para organizar el código de manera
flexible podemos usar el patrón factory method, a veces llamado simplemente factory.
Este patrón es ligeramente más complicado que la versión anterior. Tenemos una factoría
"genérica" que es una clase abstracta y sirve para "fabricar" un producto, también
genérico (un interfaz o bien una clase abstracta). Siguiendo con nuestro ejemplo,
15
tendríamos una clase abstracta FactoriaCanales cuyo método crearCanal devolvería

un nuevo ICanal. Las factorías "concretas" (clases que heredan de la clase de la factoría
"genérica") sirven para "fabricar" productos concretos. En nuestro caso tendríamos dos
clases que heredarían de FactoriaCanales: FactoriaCanalesLite y
FactoriaCanalesPro, cuyo método crearCanal(tipo) devolvería objetos CanalTCP,
CanalSMS, de tipo lite y pro respectivamente. La siguiente figura muestra el diagrama de
clases para el ejemplo.
Factory method para objetos ICanal

Esta es una forma del patrón que, aunque más compleja que el simple factory es más
flexible y permite extender el sistema de una manera más elegante. Por ejemplo, la
aparición de un nuevo tipo de usuarios digamos silver, con privilegios intermedios,
conllevaría la creación de nuevas clases, como CanalSMSSilver y CanalTCPSilver,
cuyas instancias las crearía una factoría FactoriaCanalesSilver. La ventaja de este
enfoque es que no requiere modificar prácticamente nada del código ya existente. Las
clases que envían y reciben mensajes simplemente trabajan con objetos ICanal y las
clases que necesiten obtener nuevas instancias de canales simplemente necesitan una
referencia al FactoriaCanales del tipo adecuado. Cambiando una simple línea de código
(o un fichero de configuración) podemos convertir a un usuario lite en pro sin más que
cambiar su FactoriaCanalesLite por una FactoriaCanalesPro.
La siguiente figura muestra el diagrama de clases genérico del patrón.
Factory method: diagrama genérico
16
Nótese que no siempre es necesario que un factory concreto cree más de un producto
distinto. En nuestro ejemplo, cada subclase de FactoriaCanales creaba distintos tipos de
canal, pero no siempre es así. En ese caso el método que actúa de factoría de objetos no
tendrá parámetros.
17
2. Charla 2: Arquitecturas Java EE
Esta charla se enfoca partiendo de un repaso de las diferentes capas lógicas (layers) de
una aplicación, para luego centrarnos en diferentes planteamientos de arquitectura
dependiendo del uso o no de un servidor de aplicaciones.
2.1. Bloques Arquitectónicos
En toda aplicación empresarial se pueden distinguir 3 bloques arquitectónicos:

• Capa de Servicios de Negocio. Elemento central de las aplicaciones.
• Capa de Presentación. Interfaz gráfico o fachada remota.
• Capa de Acceso a Datos. Objetos que acceden a un almacén persistente
(normalmente, una o más bases de datos relacionales).
2.1.1. Capa de Servicios de Negocio
La clave de una arquitectura sólida es una capa de servicios bien definida. Esta capa
expone la lógica de negocio a los clientes, como interfaces web o capas remotas. Esta
capa consistirá en múltiples interfaces, cada uno con un contrato bien definido.
Una capa de servicios bien definida debería:
• Ser completa. Debería exponer todas las operaciones que necesiten los clientes.
Puede que sea necesario exponer diferentes interfaces que den soporte a los diferentes
clientes.
• Ser simple. No debe ser más compleja que los requisitos de negocio que ofrece.
• Estar definida mediante interfaces en vez de clases, persiguiendo las buenas
prácticas de OO.
• Ser orientada a objetos. Se debe minimizar el número de restricciones de los objetos
de negocio. Por ejemplo, no se debe forzar a que implementen interfaces especiales o
que hereden de alguna superclase particular.
• Ser independiente de la lógica de presentación
• Ser fácil de escribir, maximizando la productividad y reduciendo los costes.
• Forzar la ocultación de la tecnología de acceso a datos. El acceso a datos es un
tema de bajo nivel, y por tanto, los objetos de negocio no deben tratar con tecnologías
como JDBC ni capturar excepciones específica de este tipo de tecnologías.
• Tratar la gestión de transacciones. Los clientes de la capa de servicios de negocio
no se deberían preocupar sobre las transacciones.
• Ser compatible con el escalado horizontal (si fuese necesario). Nada de la capa de
negocio debe impedir la realización de un cluster. Sin embargo, esto no significa que
la capa de negocio ofrezca escalado horizontal. No tiene por que ser un mecanismo
distribuido.
• Ser fácil de probar y estar probada a conciencia. Esto es crucial, ya que la robustez
18
de un objeto de negocio es esencial para construir aplicaciones de calidad.
2.1.1.1. Acciones Web dentro de MVC
¿Qué sucede si no existe capa de negocio y toda la lógica de negocio residen en la capa
web dentro de un Action de Struts o un Controlador Spring, u otras clases de la capa web?
Esto suele ocurrir por la falta de una gestión de los objetos de negocio en aplicaciones
JavaEE que no utilizan EJB. Las desventajas son numerosas, incluyendo:
• Atar los objetos de negocio al API de los Servlets.
• Reutilización limitada de los objetos de negocio. Un framework como XWork, el cual
desacopla los Actions del API de los Servlets puede paliar este problema.
• Dependiendo del framework MVC utilizado, podemos perder capacidades de OO, ya
que, por ejemplo, mediante el uso de Struts los Actions deben heredar de las clases de
Struts, lo que nos priva de poder realizar herencia sobre otras clases.
• Responsabilidades difusas en la capa web. Cada clase debería tener una sola y clara
responsabilidad. Con este enfoque, las clases de la capa web al menos tienen 2
responsabilidades bien diferentes.
• Ausencia de soporte para la gestión declarativa de transacciones (Spring AOP se
puede utilizar para los controladores web, o los filtros de Servlets se puede utiliza
para gestionar las transacciones en una aplicación web, pero estas son soluciones tipo
tirita para problemas mejor resueltos de forma separada al API de los Servlets).
• La lógica de negocio es difícil de probar, causado por los elementos implícitos del
contenedor web.
2.1.1.2. Capa de Servicios en un Contenedor Ligero
La tendencia actual es utilizar una capa de servicio de negocio mediante POJOs corriendo
sobre un contenedor ligero, tipo Spring o PicoContainer, el cual reemplaza la estructura
de los EJB con mucha menos complejidad.
En pocas palabras, un contenedor ligero:
• Gestiona el ciclo de vida de los objetos de negocio. La principal diferencia con los
EJBs es que un contenedor ligero puede gestionar POJOs: no hay necesidad de
implementar contratos especiales.
• Ofrece facilidades de lookup, resolviendo la dependencia entre objetos gestionados
por el contenedor. El paradigma de Inversion Of Control (IoC) es el elemento central
de este tipo de contenedores ligeros.
• Ofrece servicios empresariales (mediante AOP) como gestión declarativa de
transacciones sobre objetos corriendo dentro del contenedor, devaluando una de los
principales defensas de EJB.
Los contenedores ligeros promueven el uso de buenas prácticas OO, como que los
clientes realicen la llamadas a interfaces y no a clases. Estos interfaces definen contratos
19
en la capa de negocio, los cuales permiten el intercambio de diferentes implementaciones.

IoC hace de esta separación interfaz/implementación una cosa sencilla.
Los objetos de negocio y los componentes de la capa de presentación que utilizan estos
BOs se ejecutan en la misma máquina virtual (JVM). La escalabilidad horizontal se puede
conseguir mediante el clustering de la aplicación entera en máquinas virtuales
adicionales.
A partir de una capa de servicios bien definida, los clientes de los servicios deberían ser
más sencillos.
2.1.1.3. Limitaciones de Qué se Puede Exponer
Hay algunas cosas que una capa de servicio no debería exponer al resto del mundo. Por
ejemplo:
• Si la capa de servicios es remota, es obligatorio trabajar con parámetros y tipos de
retorno Serializable. También hay que considerar la eficiencia ¿Cuanto costará que
estos objetos se codifiquen (marshall) y descodifiquen (unmarshall) para viajar a
través de la red?
• Con algunas tecnologías de persistencia, puede ser necesario desconectar los objetos
del almacén persistente de un modo explicito.
Importante
La desconexión de un almacén persistente es un problema común e importante.
En la mayoría de tecnologías persistentes, existen retos en desconectar los objetos

persistentes de sus almacenes. La solución pasa por:
• Utilizar una capa de Transfer Objects (TOs) para mantener los datos desconectados,
incluso en aplicaciones que residen en un único nivel. Esto se suele evitar, lo cual
fuerza la escritura de objetos falsos y malgasta las ventajas de una arquitectura
mononivel.
• Usar un API de acceso a datos como Hibernate o JDO 2.0 que permita la desconexión
y reconexión de los objetos persistentes. Como con los TOs, esto requiere materializar
todas las relaciones necesarias.
• Evitar las tecnologías como los EJBs de Entidad que descartan las desconexiones.
• Mantener la sesión de persistencia abierta hasta que el trabajo del cliente haya
terminado, por ejemplo, en una aplicación web, hasta que la vista pinte los datos. A
primera vista es una opción atractiva, ya que elimina los problemas de traslado de
relaciones hasta la profundidad requerida, pero en realidad es peligroso, ya que las
excepciones relacionadas con la persistencia pueden provocar problemas en la capa de
presentación.
2.1.2. Capa de Presentación
20
El requisito más común es exponer los servicios de negocio vía un interfaz web. En esta
arquitectura, existe un línea divisoria que fuerza la distribución, la que existe entre el
cliente y su navegador, y el servidor web. Sin embargo, no son necesarias más barreras
distribuidas, ya que normalmente todo funciona mejor sin los costes asociados a los
objetos distribuidos.
Navegador-Contenedor Web
Lo que comúnmente se conoce como arquitectura JavaEE (J2EE) tradicional u ortodoxa
promueve la separación física entre el nivel web (vía un Contenedor Web) y los objetos
de negocio (vía un Servidor de Aplicaciones). La tendencia señala en otra dirección,
donde toda la aplicación reside un único nivel y, como hemos comentado, la escalabilidad
se consiga mediante el clustering de servidores.
Navegador-Contenedor Web-Servidor Aplicaciones
Consejo
Coloca los objetos de negocio en el contenedor web (mononivel).
Este es el enfoque más sencillo, con mejor rendimiento, y con un enfoque más OO.
La separación de los BOs del nivel web es una de las falacias del mundo JavaEE.
Puede haber un línea divisoria entre el servidor web y el contenedor web. Por ejemplo, se
puede utilizar Apache como servidor HTTP, con un conector proxy el cual envíe
peticiones al contenedor JavaEE. Esta distribución no afecta al código de la aplicación.
Lo que varía es el efecto en el rendimiento. Normalmente este enfoque es más lento que
si el contenedor web sirve todo el contenido web, a no ser que exista un gran proporción
de contenido estático respecto al dinámico. Otra razón puede ser por cuestiones de
seguridad, colocando todas las partes de la aplicación JavaEE detrás de un firewall.
21
2.1.2.1. Importancia de la Separación Lógica
Parece ser que por lo general, no queremos una separación física de los objetos de
negocio del nivel web. Sin embargo, si queremos una separación lógica, y el hecho de
rechazar la separación física no implica que olvidemos esto.
El primer paso para tener una separación lógica es tener una capa de servicios de negocio
bien definida. Sin embargo, también debemos asegurar que el acceso a estos servicios sea
fácil y que no produzca una dependencia en la capa de UI o en la tecnología detrás del
interfaz de los servicios de negocio
La mayoría de las aplicaciones JavaEE contienen demasiado código dentro de la capa
web, ya sea porque pocos libros enfatizan la importancia de esta separación (se centran
más en separar la lógica de control de la vista), que los frameworks MVC tipo Struts no
obligan a realizar esta separación, y al no obligar, los desarrolladores tienden a colocar la
lógica de negocio en los Action, o bien porque parece que la solución más fácil sea
colocar todo en el Action y evitar la creación de las diferentes capas mediante el uso de
interfaces/implementaciones desacopladas mediante factorías.
En resumen, el interfaz web debería ser ligero. Se debería construir sobre la capa de
servicio y únicamente contener el código necesario para capturar los eventos del usuarios
y visualizar las respuestas.
2.1.2.2. Clientes Remotos
El uso de los clientes remotos debe tratarse con cuidado. Aunque no se trata de un acceso
complejo, los servicio de negocio solo deben exponer interfaces remotos cuando sea
necesario.
Aunque nuestros servicios de negocio no incluyan soporte nativo para el acceso remoto,
el proceso de añadir una fachada sobre la capa de servicios es tan fácil como añadir una
fachada web.
Las elecciones para acceder a servicios remotos se centran en RMI (Remote Method
Invocation), la cual es la tecnología que utilizan los EJBs para la comunicación remota de
los componentes; también se pueden utilizar diferentes protocolos Hessian o Burlap vía
Commons Proxy (commons.apache.org/proxy) o el uso de servicio SOAP con Web
Services vía herramientas como Apache Axis/Axis2 (ws.apache.org/axis y
ws.apache.org/axis2)
2.1.3. Capa de Acceso a Datos
El acceso a los datos persistentes normalmente determina el rendimiento global de las

aplicaciones empresariales, ya que el almacén suele ser el cuello de botella. Los datos
persistentes suelen almacenarse en una base de datos relacional, aunque en ocasiones
22
podemos tener múltiples almacenes con transacciones distribuidas o aplicaciones legacy.

El concepto de capa de acceso a datos engloba una o más bases de datos, aunque el
concepto de una capa EIS (Sistema de Información Empresarial) engloba no solo a las
bases de datos, sino también sistemas legacy, los cuales también suelen ser
transaccionales.
2.1.3.1. Tecnologías
Las tecnologías de acceso a datos incluidas en JavaEE son JDBC, JDO y JPA. Sin
embargo, es muy común utilizar productos de terceros, y en la mayoría de las ocasiones,
vale la pena.
Antes de JPA, el uso de EJBs de Entidad producía , el uso de EJBs de Entidad produce
resultados no muy buenos. Esta apreciación está ampliamente aceptada dentro de la
comunidad JavaEE. ¿Qué nos queda?
• JDBC es una buena tecnología para acceso a bases de datos relacionales vía SQL. Si
utilizas JDBC, hazlo indirectamente mediante una buena capa de abstracción.
Frameworks como Commons DbUtils (jakarta.apache.org/commons/dbutils) y Apache
iBatis (ibatis.apache.org) facilitan y mejoran la calidad de este tipo de código.
• Hibernate es un excelente tecnología ORM
• A pesar de la lenta adopción desde su lanzamiento en 2001, JDO esta emergiendo
como estándar Java de persistencia.
• Alternativas comerciales como TopLink, aunque no tengan nada que los hagan muy
superiores (normalmente, asistentes gráficos y soporte por parte de las empresas
propietarias) a Hibernate o JDO.
Como ya sabemos, podemos mezclar y encajar código basado en SQL con persistencia
ORM. El patrón DAO es la elección correcta, ya que oculta los detalles de las
operaciones de persistencia tras un interfaz DAO, el cual libera a los objetos de negocio
de conocer que tecnología de persistencia se está utilizando.
2.2. Arquitectura y Java EE
Desarrollar aplicaciones con arquitecturas multinivel implica el uso de computación

distribuida, lo que complica el proceso de desarrollo. Aunque la plataforma JavaEE
simplifica en gran medida el desarrollo de sistemas en tres niveles, el diseño de
componentes distribuidos es más complejo que si nos centráramos en uno o dos niveles.
Esta complejidad extra debe estar justificada por los requisitos del sistema, ya que se trata
de una decisión que va a condicionar la naturaleza del proyecto.
Si podemos evitar el uso de una arquitectura distribuida para los sistemas que no lo
necesitan, obtendremos un diseño más simple. El hecho de evitar la complejidad nos va a
ayudar a cumplir un calendario apretado.
23
La complejidad va a:
• dificultar la comprensión del diseño y el código
• alargar los tiempos de desarrollo debido a la curva de aprendizaje
• encarecer el mantenimiento del software
• dificultar la evaluación y aplicación de los cambios
• provocar la realización de errores
A continuación vamos a evaluar las ventajas e inconvenientes de los sistemas distribuidos
y considerar posibles arquitecturas que no se basen en componentes distribuidos
2.2.1. Arquitecturas de 2 Capas vs Multicapa
Antes de la entrada de las tecnologías distribuidas como JavaEE o CORBA, los sistemas
de empresa normalmente utilizaban una arquitectura de 2 capas conocida como
cliente/servidor, la cual se desplegaba a su vez en 2 niveles.
Bajo el modelo de cliente/servidor, la lógica de negocio se implementaba como parte
integrada de un cliente rico y pesado que accedía al servidor para obtener los datos de una
base de datos centralizada.
El modelo cliente/servidor disfrutó de un éxito considerable, ya que era fácil de
comprender, fácil de probar y soportado por numerosas herramientas de desarrollo visual
a alto nivel.
El problema es que la arquitectura de 2 capas/niveles tiene las siguientes limitaciones:
• Despliegue: en las grandes empresas donde existen miles de clientes, el hecho de
realizar un despliegue supone un reto logístico
• Compartición de servicios: si la aplicación debe compartir servicios dentro de la
empresa, y la lógica esta integrada con los clientes, tenemos una gran redundancia de
código entre las diferentes aplicaciones.
• Pobre separación de la presentación y la lógica de negocio: este tipo de
arquitectura provoca un alto acoplamiento, ya que es muy fácil mezclar ambas capas.
Debido a estas limitaciones, la comunidad de desarrollo concluyó que era necesaria una
tercera capa de negocio que se colocara entre las 2 anteriores, apareciendo la necesidad de
un tercer nivel.
El uso de una capa intermedia de negocio ofrece ciertos beneficios respecto al modelo
cliente/servidor:
• Inteligencia de negocio centralizada: al estar centralizado y accesible por un sistema
remoto, resuelve el problema de juntar presentación y negocio
• Fácil despliegue: ya no es necesario actualizar miles de cliente. Al tener el negocio
centralizado, los cambios se pueden desplegar de forma rápida y fácil con un mínimo
impacto sobre el sistema base del usuario
• Redundancia: al poder desplegar la capa de negocio en un cluster, ofrecemos un
24
conjunto de máquinas replicadas que mantienen un entorno de alta disponibilidad

• Escalabilidad: del mismo modo, el cluster de negocio nos permite incrementar el
número de máquinas conforme crece la demanda de los clientes.
Estos beneficios han provocado que el modelo multicapa sea la arquitectura por defecto
para las aplicaciones de empresa. La plataforma JavaEE ofrece componentes distribuidos
para desarrollar sistemas mediante arquitecturas multicapa/multinivel, siendo los EJBs
una tecnología clave para los componentes de negocio distribuidos en un nivel
intermedio.
2.2.2. Enterprise JavaBeans
Los EJBs permiten desarrollar aplicaciones usando una arquitectura basada en

componentes.
La arquitectura EJB define componentes, conocidos como Beans de Empresa, que
encapsulan funcionalidad en módulos desplegables, los cuales están claramente definidos
mediante interfaces.
Como ya sabemos, la plataforma JavaEE ofrece 3 tipos de EJBs:
• Beans de Sesión (SBs): encapsula la lógica de negocio
• Beans de Entidad (EBs): mecanismo que ofrece una vista de entidades basadas en
objetos dentro de un almacén persistente de datos.
• Beans dirigidos por el Mensaje (MDBs): consume mensajes entregados al servidor
via el API JMS
Una arquitectura EJB ofrece beneficios substanciales a la hora de construir una aplicación
empresarial:
• Incrementa la productividad mediante la gestión de las transacciones y la seguridad
mediante información especificada en el descriptor de despliegue.
• Ofrece escalabilidad gestionando inteligentemente los recursos y ofreciendo
transparencia de estado en los componentes "con estado".
• Ofrece y hace de mediador entre los componentes de negocio y múltiples tipos de
cliente, tanto pesado como aplicaciones web ligeras.
• Aísla al cliente de los temas de la red mediante transparencia de localización, de
modo que se pueden invocar a los componentes sin necesidad de saber donde están
desplegados.
Este último punto de transparencia de localización es de especial interés, ya que los EJBs
permiten el desarrollo de arquitecturas distribuidas mediante el modelo de componentes
que ofrece JavaEE.
2.2.3. Interfaces Remotos o Locales
Los clientes de un bean de sesión pueden acceder a éste mediante su interfaz remoto o
25
local. Si se utiliza el interfaz remoto, un cliente ejecutándose en una JVM separada

accede a la instancia del EJB. Con acceso local, el cliente reside en la misma JVM que
bean.
De forma alternativa, con la especificación de EJB 2.1, los cliente puede acceder a los
beans mediante Web Services. Esto no es más que otra forma de acceso remoto.
2.2.4. Componentes Distribuidos
El uso de EJBs con interfaces remotos permite el desarrollo de sistemas con arquitecturas
distribuidas. La plataforma JavaEE ofrece una gran ayuda para construir arquitecturas
complejas de éste tipo. Sin embargo, añadir interfaces remotos a los objetos de negocio
implica ciertos aspectos que el arquitecto debe tener en cuenta antes de decidirse por este
tipo de planteamiento.
2.2.4.1. Rendimiento
La tecnología EJB se basa en el estándar RMI, él cual ofrece la transparencia necesaria

para acceder a un bean a través de su interfaz remoto. Sin embargo, el proceso de ejecutar
una invocación a un método a través de una JVM o entre máquinas distintas, hace las
llamadas RMI mucho más costosas que si se hicieran a un objeto local.
Por cada llamada, RMI crea un objeto stub en el cliente que se responsabiliza de enviar
los parámetros del método y de recibir la respuesta a través de la red (marshalling). El
stub del cliente no habla directamente con el objeto del servidor, sino con el skeleton
RMI. Del mismo modo, una vez ejecutado el método remoto, este skeleton se volverá a
comunicar con el stub del cliente para devolver la información.
Por ello, se produce una sobrecarga en la llamada de los métodos. Por lo tanto, tenemos
que cuidar el diseño de las llamadas para asegurarnos que los beneficios de la
transparencia de localización no son menores que la penalización de rendimiento
obtenida.
Consejo
El paso de objetos pesados en las llamadas remotas reduce el rendimiento gravemente. Si un
objeto contiene referencias a otros objetos, entonces estos objetos miembros también son
serializados como parte de la llamada.
Para reducir el tamaño de algunos objetos, se pueden excluir objetos innecesarios marcándolos
con la palabra clave transient
2.2.4.2. Complejidad
Aunque RMI puede hacer parecer que simplifica las llamadas a un bean remoto, la
computación distribuida introduce cierta complejidad extra al desarrollador.
26
Se debe tener en cuenta la diferencia entre el paso de variables por valor en las llamadas
remotas, y el paso por referencia en las locales. Además, los clientes remotos pueden
gestionar las posibles excepciones lanzadas por problemas en la red.
2.2.4.3. Impedancia Orientada a Objetos
El uso de las capacidades distribuidas de los EJBs requiere un cambio en el modo que
aplicamos las prácticas de diseño orientado a objetos.
En una arquitectura no-distribuida, los desarrolladores trabajan directamente con los
objetos del modelo del dominio. Aquí, los objetos del dominio representa entidades de
negocio y exponen interfaces con métodos de granularidad fina, como pueden ser los
métodos get y set de un javabean.
La penalización de rendimiento de una aplicación distribuida descarta el uso de éste tipo
de objetos, ya que incrementa el número de llamadas a través de la red.
Para mantener el número de viajes de ida y vuelta al mínimo, los interfaces remotos se
deben diseñar con granularidad gruesa, donde los métodos combinan la funcionalidad de
varios métodos finos en una sola llamada.
Una ayuda a la hora de diseñar los métodos es el uso de los patrones de diseño, en
especial, aquellos que tratan con componentes distribuidos, como pueden ser Session
Façade y Transfer/Value Object. Más información en Patrones para Aplicaciones
Distribuidas
A pesar de la existencia de los patrones, el arquitecto debe tener en cuenta las
restricciones que ofrecen las tecnologías, y reflejarlo en las arquitecturas diseñadas. Si las
tecnologías marcan el modo de diseñar el interfaz de un componente, estamos
contradiciendo las pautas de un buen diseño orientado a objetos.
2.2.5. Elección de un Diseño Apropiado
Los componentes distribuidos no son un prerrequisito para todas las arquitecturas

empresariales. A menos que los requisitos del sistema dicten la necesidad de una
arquitectura distribuida, siempre se podrá implementar una aplicación más sencilla que
evite el uso de las llamadas remotas.
Importante
La decisión arquitectural de utilizar componentes distribuidos va a condicionar la complejidad de
la aplicación, y por ello, los costes (económicos y temporales) del proyecto.
2.3. Propuestas de Arquitecturas Java EE
27
2.3.1. Arquitectura Web
En los últimos tiempos, predominan los clientes web ligeros respecto a los interfaces de
usuario pesados (Swing), aunque no hemos de descartarlos. Por lo tanto, las aplicaciones
web son el estándar de facto de las aplicaciones empresariales.
Estas arquitecturas, fácilmente escalables a nivel de hardware (clustering), pueden
acceder al mismo tipo de APIs que los EJBS, además, se benefician de las capacidades
que ofrece el servidor J2EE, como pueden ser la gestión de transacciones y el pool de
conexiones. Finalmente, también pueden utilizar todos los servicios de empresas, tales
como JMS, JDBC, JavaMail y JCA. La única tecnología a la que no puede acceder es a
los Entity Beans. Por lo tanto, cubre las necesidades de la mayoría de las aplicaciones.
En este tipo de arquitectura, tanto la capa web como la de negocio se ejecutan en la
misma JVM, normalmente desplegadas sobre un contenedor web (tipo Tomcat, Resin,
etc...). Sin embargo, es muy importante, que a nivel lógico si que las separemos. Uno de
los mayores riesgos a la hora de diseñar una aplicación web es mezclar responsabilidades
entre componentes de presentación y de lógica de negocio.
2.3.1.1. Ventajas
El uso de arquitecturas web ofrece las siguientes ventajas:

• Velocidad. Estas arquitecturas son mínimamente penalizadas por el servidor J2EE.
• Los interfaces de usuario y los componentes de negocio se ejecutan dentro de la
misma JVM, lo cual ofrece un gran rendimiento.
• Al ejecutarse en una única JVM, posibilidad de hacerlo en un contenedor web, lo que
conlleva licencias más baratas y administración más sencilla.
• El uso de POJOs en vez de EJBs para encapsular la lógica de negocio elimina las
configuraciones adicionales y complejidades de acceso y despliegue asociadas con la
tecnología EJB.
• Mayor portabilidad entre servidores de aplicaciones o contenedores web. Al haber
menos configuraciones, es más fácil su portabilidad.
• Las pruebas unitarias de los objetos de negocio, en principio, son más sencillas
porque no necesitamos desplegarlos en el servidor J2EE para poder probarlos.
• No se realizan llamadas RMI, por lo que se mantiene la convención de llamada por
paso de referencia.
• Los objetos de negocio pueden exponer interfaces de granularidad fina.
Un prerequisito de la mayoría de arquitecturas empresariales es la escalabilidad. Este tipo
de arquitectura puede escalar mediante múltiples servidores con la ayuda de
balanceadores de carga que repartan las peticiones entre los diferentes nodos de servidor.
2.3.1.2. Limitaciones
28
Como toda solución, este tipo de arquitectura también tiene sus limitaciones, entre las que
se encuentran:
• Sólo soporta interfaces web. Si fuera necesaria que un cliente pesado acceder a la
capa de negocio de forma remota, entonces necesitaríamos una capa de servicios web
(por ejemplo, mediante Apache Axis) o una arquitectura EJB.
• Falta de un entorno estándar para gestionar los objetos de negocio.
• Puede no existir una capa de servicios de negocio bien definida. Se puede evitar
mediante el uso de frameworks web, tipo Struts, Spring, etc...
• Puede que necesitemos implementar "a mano" algún tipo de solución que los EJBs ya
ofrecen, como puedan ser la gestión de transacciones declarativas o el modelo
declarativo de seguridad, que nos toca implementarlo mediante el código de la
aplicación.
• No existe un estándar de configuración de los objetos de negocio (aunque los EJBs
tampoco lo hacen muy bien).
• Falta de consistencia entre aplicaciones, o incluso en una misma aplicación. Cada
aplicación tiende a manejar a su modo el acceso a los objetos de negocio, su
configuración, la gestión de transacciones, etc... Por lo tanto, cada aplicación requiere
de su propia curva de aprendizaje.
El mayor inconveniente que puede ser la falta de una capa de servicios claramente
definida, se puede resolver mediante el uso consistente de interfaces de negocio y el
acceso consistente a los objetos de negocio.
2.3.1.3. Implementación
En esta arquitectura, la capa de servicios de negocio consiste en un conjunto de interfaces

Java implementados mediante POJOs (clases Java normales y corrientes).
Pregunta
¿Sabrías identificar los elementos del siguiente gráfico con la implementación que hemos
realizado en el proyecto de integración?
29
Arquitectura Web
2.3.2. Arquitectura Contenedor Ligero
Por supuesto que las arquitecturas JavaEE pueden ser exitosas sin EJBs. Sin embargo, se
puede utilizar algunas de las buenas ideas de los EJBs y llevarlas a una arquitectura sin
EJBs. Para ello, se utiliza una arquitectura de Contenedor Ligero.
Del mismo modo que los EJBs, se plantea una arquitectura centrada a partir de una capa
de servicios de negocio gestionados por el contenedor. Pero aquí se acaba la similitud. En
vez de ejecutarse dentro de un contenedor EJB, los objetos de negocio corren dentro de
un contenedor ligero.
Un contenedor ligero no está atado a JavaEE, por lo que puede correr en un contenedor
web, una aplicación "standalone", o incluso en un contenedor EJB (si fuese necesario).
Además, tampoco esta atado al API de los Servlets, como los frameworks MVC, lo cual
seria una pobre elección para gestionar los objetos de negocio.
Los contenedores ligeros tienen un coste de arranque insignificante y elimina el proceso
de despliegue necesario en los EJBs. Los contenedores ligeros ofrecen un modo de
gestionar y localizar los objetos de negocio; ya no necesitan búsquedas JNDI,
localizadores de servicio o singletons, ya que ofrece un registro de los objetos de
aplicación. Este enfoque es menos invasivo y más poderoso que los EJBs, siempre y
cuando todo resida en la misma JVM.
30
En la actualidad, los contenedores ligeros más conocidos son:

• Framework Spring (www.springsource.org)
• JBoss Seam Framework (seamframework.org)
• PicoContainer (www.picocontainer.org)
Para ofrecer una solución completa, el contenedor ligero debe ofrecer servicios
empresariales como la gestión de transacciones. Esto normalmente se realiza mediante
invocaciones a intercepciones AOP: añadir comportamiento adicional (como la gestión de
transacciones) de un modo transparente, antes y tras la ejecución de los métodos de
negocio.
Los contenedores ligeros son una arquitectura reciente, hecha posible al desarrollo de
frameworks open source con soporte para la IoC.
2.3.2.1. Ventajas
El uso del contenedor ligero ofrece las siguientes ventajas:

• Arquitectura simple pero potente
• Permite la escalabilidad horizontal mediante el clustering del contenedor web. Las
limitaciones a la escalabilidad vendrán dadas por la gestión del estado de la sesión.
• Más sencilla que una arquitectura EJB, pero más compleja que una arquitectura Web.
• Servicios declarativos sofisticados mediante AOP.
• No requiere un contenedor EJB
• Alta portabilidad entre servidores de aplicaciones.
• IoC permite al contenedor ligero conectar objetos, lo que elimina la complejidad de
búsqueda y conexión de recursos del código de la aplicación. La dependencia y
colaboración de los objetos se expresa mediante simples propiedades JavaBean o
argumentos de constructor, siendo el contenedor el que las resuelve en tiempo de
ejecución. IoC permite que la granularidad de los BOs sea fina.
• Los BOs son más fáciles de probar fuera de un servidor de aplicaciones, y algunas
pruebas de integración se pueden realizar desde pruebas JUnit (sin necesidad de
Cactus). Esto facilita seguir un enfoque TDD en el desarrollo.
A continuación se enumeran algunas de las desventajas de esta arquitectura:

• Igual que la arquitectura anterior, para permitir el acceso remoto de cliente es
necesaria una fachada remota (RMI, Web Services, ...) Los Web Services son una
gran alternativa para esta fachada, pero solo en el caso de utilizar RMI/IIOP será
necesario el uso de EJBs.
• No existe un estándar para contenedores ligeros. Pese a que Spring esta muy
difundido, es un estándar de facto, pero no forma parte de ninguna especificación de
Sun. Aun así, como los objetos de la aplicación no dependen de ningún API, en el
caso de querer migrar de framework, los cambios se realizan sobre ficheros de
31
configuración y clases muy especificas.

• Se trata de una arquitectura todavía desconocida para la mayoría del mercado, donde
no existen muchos desarrolladores con dominio sobre las tecnologías empleadas. Por
suerte, poco a poco, Spring suena más y mejor.
Dentro de una aplicación, todas las clases se ejecutan dentro de la misma JVM. Desde el
punto de vista del usuario, la capa web la ofrece un framework MVC, ya sea mediante
Struts, o en el caso de Spring, mediante una capa web que puede ser gestionada por el
contenedor y ofrecer un integración cercana con los objetos de negocio.
Los objetos de negocio serán POJOs, ejecutándose dentro del contenedor ligero. Estos
pueden ser avisados vía intercepcion AOP para que ofrezcan servicios empresariales. El
acceso a los BOs ser realizará exclusivamente a través de sus interfaces, lo cual permite el
intercambio de implementaciones de negocio, sin necesidad de modificar el código
llamador. En cuanto al acceso a datos, ya sea mediante un framework ORM tipo
Hibernate, o JDBC si la abstracción de ORM no aporta casi valor.
A parte de la ya comentada posibilidad de gestionar servicios empresariales de forma
declarativa mediante AOP, el uso de un contenedor ligero como Spring permite que si
controlamos las transacciones mediante conexiones JDBC, sin utilizar JTA, si en un
futuro necesitamos sacar ventaja de JTA, entonces sólo habremos de cambiar la
configuración de Spring.
32
Arquitectura Contenedor Ligero
2.3.3. Arquitectura JavaEE Local
Para solucionar algunos de los problemas en la arquitectura vista previamente, la

siguiente solución modifica la arquitectura para incorporar los EJBs que ofrecen una vista
local de sus interfaces a los clientes.
Por un lado, la especificación de servlets 2.3 garantiza que los objetos de la capa web
puedan acceder a los EJBs vía sus interfaces locales si la aplicación se despliega en un
servidor de aplicaciones JavaEE integrado en un única JVM. Esto nos permite
beneficiarnos de los servicios ofrecidos por el contenedor EJB, pero sin incurrir en la
excesiva complejidad ni la necesidad de hacer nuestra aplicación distribuida.
Por el otro, la especificación de EJB 2.0, introdujo los interfaces locales como respuesta a
la presión de la industria respecto al rendimiento de las arquitecturas EJB. Como ya
sabemos, el uso de interfaces locales permite el uso de la convención de paso por
referencia, evitando la sobrecarga incurrida en las llamadas remotas.
2.3.3.1. Ventajas
El uso de arquitecturas con EJBs locales ofrece las siguientes ventajas:

• Es menos compleja que una aplicación EJB distribuida
• El uso de los EJBs no altera el diseño básico de la aplicación. En este tipo de
arquitectura, podemos hacer EJBs sólo aquellos objetos que necesitan servicios del
contenedor EJB.
• Este tipo de uso de los EJBs implica una penalización de rendimiento muy pequeña
(casi despreciable), ya que no realiza llamadas remotas ni serialización de los objetos.
• Ofrece los beneficios del contenedor EJB tales como la gestión de las transacciones,
seguridad declarativa y gestión de la concurrencia.
• En el caso de quererlo, podemos utilizar beans de entidad
Hemos visto que esta arquitectura representa un buen uso (y valido) de la tecnología EJB,
donde los requisitos del sistema pueden utilizar la seguridad declarativa y la gestión de las
transacciones. Algunas de las debilidades son:
• Es más compleja que una aplicación web pura.
• Todavía no soporta otro tipo de clientes que no sean el interfaz web, a no ser que
añadamos una capa de servicios web.
• Toda la aplicación corre sobre la misma JVM, lo que significa que todos los
componentes debe ejecutarse en el mismo servidor físico y no se pueden separar para
desplegarlos en servidores diferentes.
• Este tipo de EJBs son difícil de probar. Necesitamos hacerlo desde casos de prueba
33
que lo hagan dentro del servidor JavaEE (con Cactus).

• Todavía existe la tentación de modificar el diseño de lo objetos como resultado del
uso de los EJBs. Incluso con interfaces locales, existe un pequeño ralentizacimiento
en las llamadas a los métodos, lo que nos puede llevar a modificar la granularidad
natural de los objetos de negocio.
A veces podemos decidir introducir EJBs en una arquitectura, que en un principio no los
necesita. Si seguimos el enfoque XP de "haz la cosa más simple que pueda funcionar",
puede que los requisitos funcionales no justifiquen la complejidad introducida por los
EJBs, pero la incorporación de futuros requisitos puede aconsejar su uso.
Si adoptamos los interfaces como componentes de negocio, tal como en la arquitectura
anterior, el hecho de introducir EJBs con interfaces locales no conlleva ningún problema.
Simplemente, podemos elegir que interfaces queremos hacerlos accesibles desde proxys.
Si introducimos EJBs remotos, la cosa cambia. Ya no es una cuestión de meter o no meter
EJBs, sino que modifica completamente la naturaleza de la aplicación. Por ejemplo, la
granularidad de los interfaces de negocio puede necesitar ser más gruesa para evitar el
múltiple uso de llamadas remotas y conseguir un rendimiento adecuado. También puede
que queramos mover toda la lógica de negocio dentro del contenedor EJB...
En la siguiente arquitectura, la capa web es idéntica a la vista anteriormente. Los

interfaces de negocio son idénticos. La diferencia está en su implementación, lo que atañe
a la capa EJB. Por lo tanto, la capa de middleware se divide en dos (los interfaces de
negocio corriendo en el contenedor web y los EJBs), pero ambas partes ejecutándose
dentro de la misma JVM.
Así pues, hemos cambiado los objetos de negocio por beans de sesión, los cuales los
desplegamos sobre el contenedor EJB del servidor JavaEE.
Tenemos 2 posibilidades para implementar los interfaces de negocio:
• mediante un Proxy, en el cual un EJB local implementa el interfaz de negocio
directamente, y se le ofrece una referencia al interfaz del EJB local en el código del
contenedor web, sin la necesidad de realizar la búsqueda JNDI.
• mediante un Business Delegate, en el cual el la implementación del interfaz de
negocio del contenedor web delega de forma explicita en el EJB apropiado. Esto tiene
la ventaja de soportar el cacheo y permitir a las operaciones fallidas recuperarse en el
lugar apropiado.
En ninguno de los dos casos hemos de preocuparnos por capturar la excepción
java.rmi.RemoteException, ya que no existen errores de transporte.
34
Arquitectura EJB Local

En esta arquitectura, a diferencia de una arquitectura que expone los interfaces remotos
vía EJB, el uso de los EJBs simplemente es una elección de implementación, pero no una
característica fundamental de la arquitectura. Cualquiera de los interfaces de negocio
puede implementarse sin usar EJBs, lo que no conllevaría ningún cambio en el diseño
global de la aplicación.
Por lo tanto, estamos ante una arquitectura comprometida con el rendimiento, la cual es
posible gracias a las mejoras introducidas en la especificación EJB 2.0
2.3.4. Arquitectura JavaEE Distribuida
Se trata de la arquitectura clásica JavaEE. Ofrece la capacidad de partir la capa de

middleware de forma física y lógica, usando diferentes JVMs para los EJbs, de modo que
los componentes web puedan utilizarlos. Se trata de una arquitectura compleja, con una
sobrecarga de rendimiento significativa.
35
2.3.4.1. Ventajas
El uso de arquitecturas distribuidas ofrece las siguientes ventajas:

• Soporta todos los tipos de cliente JavaEE mediante una capa de middleware
compartida.
• Permite la distribución de componentes de aplicación a través de los diferentes
servidores físicos. Esto funciona particularmente bien si la capa de EJB es "sin
estado". Las aplicaciones JavaEE con capa de presentación con estado (mediante el
uso del objeto Session), pero con la capa de middleware sin estado (mediante
Stateless Session Beans) se benefician de este tipo de despliegue y obtienen la
máxima escalabilidad posible.
Las limitaciones de esta arquitectura son:

• Se trata del enfoque más complejo de los que hemos considerado. Si los requisitos de
la aplicación no obligan a esta complejidad, estaremos malgastando recursos a lo
largo del ciclo de vida del proyecto, y sembrando un campo fértil para la aparición de
errores.
• Afecta al rendimiento. Las llamadas a métodos remotos pueden ser cientos de veces
más lentas que las llamadas locales por referencia. El efecto de esta sobrecarga de
rendimiento depende del número de llamadas remotas necesarias.
• Las aplicaciones distribuidas son difíciles de probar y depurar.
• Todos los componentes de negocio deben ejecutarse en el contenedor EJB. Mientras
esto ofrece un interfaz comprensible para los clientes remotos, es un aspecto
problemático si el EJB no puede utilizar para resolver todos los problemas impuestos
por los requisitos de negocio. Por ejemplo, si el patrón de diseño Singleton es una
buena elección, será muy difícil de implementar satisfactoriamente mediante EJBs.
• El diseño OO se dificulta por el uso centralizado de RMI.
• La gestión de las excepciones es más compleja en sistemas distribuidos. Se deben
controlar tanto los errores de transporte como los de aplicación.
Aunque el diagrama muestre una aplicación web, esta arquitectura soporta cualquier tipo
de cliente JavaEE. Por lo tanto, se trata de una arquitectura preparada para las necesidades
de las aplicaciones cliente.
Esta arquitectura utiliza RMI entre las capas de presentación (o con otros cliente remotos)
y los objetos de negocio, los cuales están expuestos como EJBs (los detalles de la
comunicación RMI los abstrae el contenedor de EJBs, pero hemos de tratar con las
implicaciones de su uso). Esto hace las invocaciones remotas un factor determinante de
rendimiento y una consideración central a la hora de realizar el diseño. Como vimos
36
anteriormente, hemos de minimizar el número de llamadas remotas (evitando las llamadas

"chatty"). Además, todos los objetos enviados deben ser serializables, y debemos tratar
con requisitos de gestión de errores más complejos.
La capa web de esta arquitectura es la misma que hemos comentado antes. Sin embargo,
la implementación del interfaz de negocio debe tratar el acceso remoto al EJB en el,
posiblemente remoto, contenedor EJB.
De las 2 posibilidades de conectividad vistas anteriormente, solo el enfoque del Business
Delegate es útil en este caso, ya que todos los métodos del interfaz remoto del EJB lanzan
java.rmi.RemoteException.
Al tratarse de una excepción chequeada, a no ser que utilicemos un Business Delegate

para contactar con los EJBs y envolver las excepciones RMI como excepciones de
ejecución o aplicación, la capa de presentación deberá capturar la excepción remota, lo
cual la ata de forma inapropiada a la implementación del EJB.
37
Arquitectura EJB Remota
2.3.5. ¿Y tu qué eliges?
Tras ver las diferentes alternativas arquitecturales, podemos hacer una elección de si una
nueva aplicación necesita un servidor de aplicación completo (con soporte de JTA, JCA,
EJBs) o un contenedor web como Tomcat.
Existen diferentes beneficios para evitar el uso de un servidor de aplicaciones, tales como:
• Menor coste de licencia, en el caso de productos comerciales. Muchas empresas están
pagando la licencia de un producto que no necesitan.
• Arranque más rápido, lo que nos ahorra tiempo de desarrollo.
• Administración más sencilla, y por lo tanto, curva de aprendizaje menor.
Las aplicaciones web que sólo utilizan una base de datos rara vez requieren un servidor
de aplicaciones. Los contenedores ligeros (tipo Spring) ofrecen mejores alternativas que
un contenedor EJB para gestionar los objetos de negocio en la mayoría de las aplicaciones
web. Las transacciones distribuidas, y por tanto JTA, no son necesarias cuando
trabajamos con una única base de datos.
Necesitamos un servidor de aplicaciones si:
• necesitamos transacciones distribuidas
• queremos que nuestra aplicación sea remota, para lo cual los EJBs son una buena
solución. Sin embargo, los servicios web remotos ofrecen casi las mismas
prestaciones (recuperación frente a caída del servidor, clustering, ...) sin necesidad de
un servidor de aplicaciones para ofrecer escalabilidad y tolerancia.
Resumiendo, en las arquitectura que no son EJB, el factor crítico que se hecha en falta es
la gestión de las transacciones. Por ello, debemos asegurarnos que nuestros requisitos se
cumplen con transacciones locales o distribuidas.
2.4. Para Saber Más
2.4.1. Bibliografía
• Expert one-on-one J2EE Design and Development , de Rod Johnson. Libro que
sirvió como base del desarrollo de Spring y que destaca todos los puntos fuertes y
débiles de los EJBs, destacando cuando hacer qué y cómo hacerlo.
• Expert one-on-one J2EE Development without EJB, de Rod Johnson. Secuela de
libro anterior donde se defiende la Arquitectura de Contenedor Ligero.
2.4.2. Enlaces
• Apartado del tutorial de Sun sobre JavaEE que habla de las Aplicaciones distribuidas
38
en múltiples niveles: java.sun.com/javaee/6/docs/tutorial/doc/bnaay.html
39
3. Integración de aplicaciones
Las empresas necesitan, cada vez más, un fácil acceso a la información por parte de sus
aplicaciones. Esta necesidad presenta nuevos retos para el desarrollo de aplicaciones. La
facilidad de acceso a los datos es poco probable que se consiga mediante aplicaciones
separadas (stand-alone) usadas por la mayoría de las empresas, debido a la dificultad que
representa el compartir datos entre ellas. Sin embargo, muchas empresas no pueden
permitirse el lujo de retirar o reemplazar sus aplicaciones stand-alone de un día para otro
debido a que juegan un papel crítico en el funcionamiento de la empresa, y a menudo no
es rentable desarrollar de nuevo la aplicación en su totalidad. Recordemos que una
aplicación stand-alone es aquella que se puede ejecutar sin necesidad de ningún elemento
soporte (por ejemplo un navegador).
Por otro lado, a medida que pasa el tiempo, las empresas necesitan introducir nuevas
aplicaciones y sistemas. Estas nuevas soluciones se basan normalmente en arquitecturas
modernas, que difieren de forma significativa de las arquitecturas usadas por aplicaciones
que ya tienen años de uso. A menudo las aplicaciones modernas se adquieren en forma de
componentes, que se integran en una aplicación más grande. Estas nuevas aplicaciones
necesitan integrarse en el sistema existente para que la información que contienen esté
disponible y sea accesible.
En estas situaciones, la integración de aplicaciones corporativas (EAI) adquiere una gran
importancia, permitiendo que una empresa integre sus aplicaciones y sistemas existentes
y sea capaz de añadir nuevas tecnologías y aplicaciones al nuevo conjunto.
La integración de aplicaciones no es una tarea fácil; de hecho se ha convertido en uno de
los problemas más difíciles con los que se enfrenta el desarrollo de aplicaciones para la
empresa desde hace pocos años. Los mayores retos se presentan en la integración de
diferentes dominios, arquitecturas y tecnologías. Además, los requerimientos de los
sistemas de información van creciendo significativamente y cambiando continuamente,
por ello los proyectos de integración deben realizarse en el menor tiempo posible,
entregar sus resultados rápidamente, y adaptarse a estos requerimientos siempre
cambiantes.
Actualmente hay dos formas principales de integración: primero es necesario permitir la
integración de aplicaciones dentro de una compañía (intra-EAI), y en segundo lugar,
podemos querer promover una integración inter-EAI (business-to-business, B2B).
En esta charla presentamos los conceptos básicos de la integración de aplicaciones
corporativas. Comenzaremos definiendo el concepto de integración, considerando los
retos que representa, así como los tipos, técnicas y tecnologías utilizadas para la
integración de aplicaciones corporativas.
3.1. ¿Qué es la EAI?
40
La integración de aplicaciones corporativas (Enterprise Application Integration, EAI) es

básicamente un nuevo nombre para el proceso de integración en el que las empresas han
estado trabajando durante años. EAI hace referencia a una integración global y
sistemática.
Antes de definir de forma más precisa la EAI, consideraremos con más detalle cómo
surge la necesidad de integrar las aplicaciones de una empresa.
En el pasado, las aplicaciones se ideaban como soluciones individuales a problemas
aislados. Los arquitectos software no pensaban en esas aplicaciones como partes de un
sistema de información más amplio de la empresa. Esta es la razón de por qué la mayoría
de aplicaciones antiguas permiten una interoperabilidad muy limitada con otras
aplicaciones. Para modificar dichas aplicaciones y hacerlas más interoperables, se
necesita un buen conocimiento del desarrollo de la aplicación y de los procesos lógicos
que implementa. Incluso hoy en día, algunas aplicaciones se desarrollan sin tener en
cuenta (o muy poco) cómo conectarlas con otros sistemas. Por estas razones, EAI es
relevante tanto para las aplicaciones ya existentes, como para aplicaciones modernas.
La importancia de la EAI radica en las expectativas del negocio. Desde el punto de vista
del negocio, el objetivo es maximizar los beneficios de cada aplicación y el sistema de
información como un todo. Las aplicaciones separadas no pueden cumplir este
requerimiento.
Parte del problema es que los datos se encuentran particionados y replicados entre las
diferentes aplicaciones. Cada aplicación modela los datos de forma diferente, de acuerdo
con las necesidades de la aplicación, no de la empresa. Esto hace que sea difícil
"ensamblar" los datos de diferentes aplicaciones, ya que probablemente usarán diferentes
tecnologías, aplicaciones y bases de datos para acceder a ellos. En la Figura 1 se muestra
un dominio típico de empresa. En este escenario, podemos encontrar "islas" de funciones
y datos, y cada una de ellas existe con su dominio del problema de forma separada.
Figura 1. Dominio de negocio típico.
41
Las empresas necesitan modernizar y mejorar la funcionalidad de sus sistemas de

información para seguir siendo competitivas (los gestores ven el sistema de información
como una herramienta que pueden utilizar para maximizar los beneficios de la empresa).
Mejorar la funcionalidad de un sistema de información puede hacerse de varias maneras:
(a) La forma más obvia consiste en reemplazar las aplicaciones antiguas por una solución
más reciente. Incluso aunque a primera vista parezca una solución atractiva, es inaplicable
en la mayoría de los casos. Reemplazar sistemas existentes con nuevas soluciones
siempre requiere más tiempo y dinero de lo que en principio estaba planificado, incluso
teniendo en cuenta los escenarios más pesimistas. Incorporar todas las peculiaridades y
casos especiales en el software requiere un conocimiento del sistema existente. Este
conocimiento es mucho más fácil de adquirir si la empresa tiene sus procesos del negocio
bien documentados, cosa que no suele ocurrir en la práctica. Además, a menudo, no hay
una única persona que conozca el proceso en su totalidad; (b) Otra alternativa es la de
introducir soluciones comerciales. Esta solución probablemente no sea factible, ya que
cada empresa tiene una forma particular de realizar los negocios, y que las distingue. El
adaptar soluciones comerciales a la empresa requiere tiempo, y tiempo significa dinero.
Introducir nuevos sistemas requiere también entrenar y educar al personal.
Una alternativa factible para mejorar la funcionalidad del sistema de información consiste
en conseguir una forma estándar para reusar sistemas existentes pero integrándolos en un
sistema global de información de la empresa más amplio. En este sentido, EAI
proporciona una metodología estándar para la comunicación entre aplicaciones y fuentes
de datos.
Ahora daremos una definición más precisa del término EAI. Realmente, la definición de
EAI varía dependiendo del punto de vista:
Desde el punto de vista del negocio, EAI representa la ventaja competitiva que consigue
una empresa cuando todas las aplicaciones están integradas en un sistema de información
único, capaz de compartir información y soportar flujos de trabajo del negocio (business
workflow). La información debe compartirse a menudo desde diferentes dominios y ser
integrada en un proceso de negocio. Sin EAI, si bien la información requerida puede que
exista y esté disponible en algún lugar y de alguna forma en una aplicación, para los
usuarios típicos es prácticamente imposible tener acceso a ella on-line.
Desde el punto de vista técnico, EAI se refiere al proceso de integrar las diferentes
aplicaciones y los datos sin tener que modificar demasiado las aplicaciones existentes.
EAI debe realizarse utilizando métodos y actividades que permitan que dicho proceso sea
efectivo en términos de coste y tiempo.
Existen muchos ejemplos reales de EAI, particularmente en la industria de la banca y
servicios financieros, así como en telecomunicaciones. Por ejemplo, AT&T comenzó
como un suministrador de servicios de telefonía, a los que añadió los servicios de
televisión por cable y otros servicios inhalámbricos. Más tarde se convirtió en un
suministrador de banda ancha. La compañía ha crecido absorbiendo a otras compañías y
42
adquiriendo otros negocios. Como resultado de su crecimiento, y antes de sus planes

actuales de dividirse en cuatro compañías diferentes, AT&T necesitó integrar sus
servicios on-line a sus clientes. Tuvo que integrar sus presentaciones de facturas a todos
los servicios, los pagos de los servicios, y la totalidad de los servicios a los clientes. Esto
supuso una integración del acceso a las aplicaciones existentes que proporcionaban
dichos servicios.
En el proceso de integración de procesos del negocio y los datos, EAI abarca tanto la
distribución de dichos procesos y datos, como el concepto de reutilización de módulos. Y
lo que es más importante, EAI aborda esta integración como un proceso separado de las
diferentes aplicaciones. Es decir, alguien puede integrar varias aplicaciones, incluyendo
las fuentes de datos subyacentes, sin tener que comprender o conocer los detalles propios
de cada aplicación.
No todas las empresas se benefician de igual forma del proceso de integración. Por
supuesto, cuando una empresa tiene únicamente un número limitado de sistemas, que
comparten tecnología y arquitectura, la integración es mucho más fácil. A la inversa,
puede haber sistemas formados por grandes aplicaciones diferentes, distribuidas
geográficamente en varias plataformas, algunas de las cuales tienen funcionalidades
comunes. En este caso, la empresa se beneficiará considerablemente del proceso de
integración.
Además, para realizar una integración de forma exitosa es necesario evaluar el estado de
las aplicaciones existentes, analizar los requerimientos del sistema, y comparar la
situación actual con las metas fijadas y los requerimientos actuales. Este estudio debe
realizarse caso por caso, ya que no es fácil definir procedimientos universales.
Puesto que hemos visto que la comprensión de los sistemas existentes es vital para una
integración efectiva, estudiaremos el concepto de sistemas de información, y
analizaremos más de cerca la arquitectura de dichos sistemas.
3.2. Sistemas de Información de Empresas (EIS)
Antes de entrar en detalles sobre la EAI, es útil entender la definición de un sistema de

información de empresa (EIS: Enterprise Information System). Una empresa requiere
ciertos procesos de negocio y datos subyacentes para ejecutar dichos procesos. Un EIS
abarca los procesos del negocio y la infraestructura para las tecnologías de información
(IT: Information Technology). Los procesos del negocio incluyen aplicaciones para la
gestión del procesamiento de nóminas, gestión de inventario, control de producción de
fabricación, y la contabilidad financiera.
Definimos un sistema de información de empresa como un sistema con una o varias
aplicaciones que proporciona la estructura de información para la empresa. Un EIS
proporciona un conjunto de servicios a sus usuarios, que pueden estar disponibles en
distintos niveles de abstracción (por ejemplo a nivel de sistema, nivel de datos, o nivel de
43
negocio).
En la Figura 2 se puede apreciar gráficamente esta situación. En el entorno mostrado, las
aplicaciones residen en un servidor de aplicaciones. Dicho servidor tiene una
infraestructura particular dependiente del vendedor, contemplando en particular los
servicios de procesamiento de transacciones, seguridad y balanceo de carga. Las
aplicaciones incluidas en el servidor pueden ser suministradas por diferentes vendedores,
o pueden desarrollarse en el departamento IT de la empresa. Las aplicaciones están
escritas en varios lenguajes, como COBOL, C, y C++. Los clientes acceden a las
diferentes aplicaciones mediante interfaces (APIs: Application Programming Interfaces).
Un API es alguna rutina que permite a un cliente realizar operaciones tales como crear
una orden de compra o actualizar un registro de usuario. La interfaz de acceso a los datos
permite acceder al almacenamiento de los datos (ficheros o base de datos relacional). Los
interfaces de objetos del negocio son abstracciones que representan la lógica específica
del negocio para acceder a las funciones y los datos.
Figura 2. Entorno Sistema de Información de Empresa.

Hay muchas y diferentes aplicaciones que pueden catalogarse como un EIS. Por ello los
EIS varían unos de otros, incluso dentro de la misma empresa. Una empresa puede
desarrollar varios EISs a lo largo del tiempo, dependiendo de las necesidades particulares
del momento. Por ejemplo, una empresa puede comenzar con un sistema de fabricación.
A medida que pasan los años y la empresa crece, se añaden otros paquetes como
contabilidad, atención al cliente y recursos humanos. Algunos servicios puede incluirlos
en la plataforma en donde residen las operaciones relacionadas con la fabricación, sin
embargo, otros requerirán ser desarrollados con una plataforma o arquitecturas diferentes.
La empresa no solamente añade nuevos sistemas software, sino que adquiere hardware
adicional que puede ser completamente diferente de su configuración original. Es fácil
ver que cuando una empresa opera durante largo tiempo, puede estar usando EIS que han
sido desarrolladas e instaladas sobre diferentes plataformas y arquitecturas.
3.3. Arquitectura de aplicaciones existentes
Los proyectos EAI tienen que tratar con aplicaciones (sistemas de información)
44
existentes. Algunas de las aplicaciones existentes son antiguas, basadas en tecnologías no

consideradas actualmente como "estado del arte", con lenguajes de programación en
desuso, y sobre plataformas anteriores a las actuales, estas aplicaciones se conocen con el
nombre de aplicaciones o sistemas legacy. Podemos considerar dos tipos de sistemas
legacy: los sistemas monolíticos tradicionales (basados principalmente en sistemas
mainframe), y los sistemas cliente/servidor (basados mayormente en PC's).
Una arquitectura monolítica contiene la presentación, la lógica del negocio y los datos
en la misma aplicación. Normalmente se trata de aplicaciones con un diseño estructurado
e implementadas con lenguajes estructurados como COBOL, Fortran y PL/1 entre otros.
En la mayoría de casos, los datos se almacenan en ficheros usando diferentes formatos
binarios. Los sistemas contienen miles de líneas de código que han sido desarrolladas y
mantenidas a lo largo de los años por diferentes desarrolladores. Usualmente no se
dispone de documentación, y en el peor de los casos, tampoco del código fuente. La
mayoría de dichos sistemas residen en ordenadores mainframe. Huelga decir que
inicialmente no había ningún tipo de integración entre las diferentes aplicaciones
monolíticas. Sin embargo, las soluciones de integración sobre dichos sistemas se
comenzó a realizar hace unas tres décadas.
Un primer intento de integración consiste en enlazar las diferentes aplicaciones con una
base de datos centralizada (ver Figura 3). Dicha base de datos normalmente no almacena
todos los datos de todas las aplicaciones (debido a restricciones de capacidad y
rendimiento), por lo tanto éstas todavía necesitan de bases de datos locales. Este tipo de
integración requiere una re-programación de cada aplicación.
Figura 3. Arquitectura mainframe.

Desde una perspectiva técnica, esta integración no es demasiado difícil cuando solamente
hay una plataforma en la empresa, y no hay demasiadas aplicaciones a integrar.
Desafortunadamente, hay un gran número de empresas que no pertenecen a esta
categoría.
45
Posteriormente, en la década de los 80, el proceso de reemplazamiento de los mainframes

por PCs lleva consigo algunos grandes cambios en las arquitecturas de las aplicaciones,
pero complica todavía más las cosas. No se dispone de estrategias para estandarizar las
plataformas y tecnologías a usar, con lo que cada departamento es libre de realizar su
elección, usualmente basada en preferencias personales, y no en los objetivos de la
empresa en su totalidad. Por un lado las necesidades de integración se hicieron cada vez
más crecientes, por otro lado, los PCs interconectados comenzaron a sustituir a los
terminales "mudos". A medida que fue necesario compartir los datos entre los usuarios,
las arquitecturas monolíticas se volvieron inviables.
La solución a estos problemas fue la arquitectura cliente/servidor que separa las
aplicaciones en dos capas (ver Figura 1.4). En la mayoría de los casos, la gestión de los
datos se separó del resto de la aplicación (ver Figura 4a). Esto significaba que la lógica
del negocio y la interfaz del usuario todavía permanecía unida, y en demasiados casos,
interconectadas. Debido a que el cliente realizaba la mayor parte del procesamiento
implicado en la lógica del negocio, a este tipo de aplicaciones cliente/servidor se les ha
denominado clientes ricos (fat clients). Los datos usualmente residían en uno o varios
servidores dedicados de gestión de base de datos (DBMS). Otra posibilidad para los
sistemas cliente/servidor fue separar la lógica del cliente y situarla en el servidor (ver
Figura 4b). En este escenario, el código en la parte del cliente es mucho más sencillo, y a
dichos clientes se les ha llamado clientes ligeros (thin clients). La lógica del negocio se
almacenaba en el servidor de la base de datos (en forma de procedimientos con sentencias
SQL), o en un servidor fuertemente acoplado a la base de datos. La mayoría de los
gestores de bases de datos soportan procedimientos almacenados, si bien hay variaciones
en la sintaxis y en sus capacidades, creando así otro problema potencial: el traslado de
esta lógica de un DBMS a otro es una tarea extremadamente ardua, si no prácticamente
imposible.
Figura 4. Arquitectura cliente/servidor. (a) Cliente rico. (b) Cliente ligero

La mayor parte de las nuevas aplicaciones, a partir de entonces se desarrollaron siguiendo
la arquitectura cliente/servidor, pero las soluciones monolíticas permanecieron, haciendo
así crecer la necesidad de integración. Además, la arquitectura cliente/servidor implica un
estrecho acoplamiento entre la aplicación y la base de datos.
El número de aplicaciones diferentes en una misma empresa fue creciendo. Si bien
diferentes aplicaciones resolvían problemas diferentes, en muchos casos había algún
solape funcional entre ellas, con lo que se podía dar el caso de datos similares residentes
en bases de datos diferentes, con nombres diferentes. Para una integración efectiva, el
46
acceso a los mismos datos no resuelve todos los problemas. Dicho acceso a los datos y su
posible transferencia entre bases de datos no es suficiente debido a la dificultad que
entraña el análisis de dichos datos para obtener información del negocio valiosa para el
soporte de decisiones. Tampoco es posible reusar todas las funcionalidades de otras
aplicaciones. Sin la reusabilidad de las funciones la única posibilidad consiste en
implementar las funcionalidades en diferentes aplicaciones, incrementando la
complejidad de nuevo (especialmente a la hora de mantener las aplicaciones). Duplicar la
funcionalidad es necesario debido a que si accedemos a los datos en la base de datos
directamente, evitamos implementar reglas del negocio en la aplicación original; pero
esto significa que tenemos que ser extremadamente cautos debido a que un acceso directo
a la base de datos puede amenazar la integridad del sistema.
Para resolver el problema del análisis de grandes cantidades de datos almacenados en
aplicaciones diferentes, y permitir el compartir funcionalidades de las aplicaciones, se
utilizan los datawarehouse y los sistemas ERP.
A principios de los 90, la integración es una cuestión relevante desde dos puntos de vista
distintos. Por un lado tenemos el uso de data warehouses. Un data warehouse es un
repositorio central para todos los datos significativos que las aplicaciones de una
compañía obtienen. Debido a la variedad de datos bien estructurados contenidos en ellos,
los data warehouses fueron (y todavía siguen siendo) efectivos como sistemas de soporte
de decisiones off-line, y útiles siempre que puedan obtenerse datos "en bruto" y
analizarlos para derivar conclusiones a partir de ellos.
Los datos de las bases de datos de las aplicaciones se envían al data warehouse a
intervalos de tiempo predeterminados, normalmente una vez por día. Esto hace que los
data warehouses no sean la elección perfecta para la integración, especialmente cuando
no podemos permitirnos el trabajar con datos que pueden estar anticuados. Los
procedimientos asociados con un sistema data warehouse se asemejan a los de la Figura
5, en donde los datos desde diferentes bases de datos son extraídos, transformados y
cargados en un data warehouse central. Las reglas para estas tres fases se definen como
meta-datos.
Figura 5. Data warehouse

Por otro lado, se comienzan a usar sistemas de planificación de recursos de la empresa
(Enterprise Resource Planning, ERP). Los sistemas ERP son sistemas de gestión de
empresas, típicamente implementados por un vendedor particular como un conjunto de
47
aplicaciones integradas que cubren todas las facetas del negocio, incluyendo
planificación, fabricación, ventas y marketing. La idea es usar los sistemas ERP para
cubrir todas las necesidades de información de la empresa. Por desgracia, la experiencia
ha demostrado que los sistemas ERP no pueden satisfacer las necesidades de información
de una compañía totalmente. Si bien el código fuente está disponible para algunos de
ellos, los vendedores no quieren realizar cambios específicos sobre ellos. Sin embargo,
cada empresa tiene muchas particularidades que necesitan ser cubiertas sobre una base
individual, además de tener que reaccionar de forma rápida para adaptarse a los cambios
del mercado. Todo ello hace que se requieran modificaciones o añadidos sobre el sistema
de información, y esperar las soluciones de los suministradores de los ERP no es práctico.
Algunos resultados de estudios de mercado sugieren que los sistemas ERP típicamente
cubren únicamente un 25-40% de las necesidades de información de una empresa (el
resto se cubre con otras aplicaciones software).
La situación actual es que las empresas se encuentran con una mezcla disparatada de
sistemas existentes heterogéneos de los cuales dependen sus negocios. Desgraciadamente
esta mezcla de sistemas diferentes no ha sido diseñada de una manera unificada
(solamente ha crecido, y continuará creciendo). La heterogeneidad consume recursos de
desarrollo. En vez de crear soluciones a problemas nuevos, muchos desarrolladores
emplean una considerable cantidad de tiempo y recursos trabajando sobre soluciones
viejas. Y tenemos que tener en cuenta, que el número de computadores en una empresa
suele ser finito.
Las aplicaciones más críticas para la mayor parte de las empresas son las aplicaciones de
procesamiento de transacciones. Suelen ser aplicaciones desarrolladas a lo largo de
muchos años, los desarrolladores han ido cambiando varias veces, y es difícil encontrar a
alguien que las entienda en su totalidad. Algunas de ellas todavía se ejecutan sobre
sistemas mainframe. Las empresas son renuentes, comprensiblemente, a modificar o
reemplazar dichas aplicaciones. El dilema entonces se convierte en cómo modernizarlas
sin comprometer las operaciones.
3.4. Arquitectura de aplicaciones modernas
Cualquier arquitectura de una aplicación moderna debe satisfacer la necesidad de un

desarrollo rápido de la solución, posiblemente mediante la composición de componentes
software. Además, debería soportar propiedades tales como mantenibilidad, flexibilidad y
escalabilidad, entre otras. La solución actual consiste en utilizar arquitecturas multi-capa,
la más común contiene tres capas (ver Figura 6):
• Capa de presentación o interfaz de usuario. Maneja servicios tales como entrada,
diálogos, y gestión de la visualización de los datos
• Capa intermedia o de lógica del negocio. Proporciona los servicios de la lógica del
negocio que son compartidos entre aplicaciones diferentes.
• Capa de persistencia de datos. Proporciona una gestión de los datos y otras
funcionalidades relacionadas.
48
Figura 6. Arquitectura de tres capas

Cada capa, y en particular la capa de lógica del negocio, puede subdividirse en varias
sub-capas dando lugar a la arquitectura lógica multi-capa. En la Figura 1.6 se pueden
observar los elementos de la capa de lógica del negocio denominados componentes.
Un componente es un código ejecutable que implementa una cierta funcionalidad. Dicha
funcionalidad es accesible para el resto de la arquitectura mediante uno o más interfaces.
Los componentes están fuertemente encapsulados y ocultan sus detalles internos a sus
clientes (otros componentes, métodos de objetos, procedimientos, funciones, etc.). La
única forma que tiene un cliente de acceder a una componente es a través de su interfaz.
Se puede acceder a la interfaz de una componente usando un alto nivel de abstracción, de
forma que no sea necesario preocuparse ni de su implementación, ni tampoco de su
localización o forma de comunicación. Un middleware se ocupa de todos los detalles de
la comunicación permitiendo así la interoperabilidad entre componentes (ver Figura 7).
Figura 7. Interoperabilidad entre componentes

Los componentes constituyen una forma de empaquetar código ejecutable, no son
ninguna técnica de implementación en sí, si bien los componentes son a menudo
confundidos con objetos. Es cierto que los componentes y los objetos comparten algunos
conceptos, como los interfaces y la encapsulación. Sin embargo, los componentes difieren
de los objetos en que proporcionan una funcionalidad más amplia y muy poca relación
con otros componentes. Cualquier cliente puede usar los servicios del componente, no
importa en qué lenguaje esté escrito, ni dónde se encuentre físicamente, o cual sea su
estructura interna. No es necesario que los componentes sean implementados con
lenguajes orientados a objetos.
49
Los componentes pueden encontrarse en diferentes capas. Los componentes de la interfaz

de usuario difieren de los de la capa de lógica del negocio, puesto que solamente
proporcionan alguna forma de representación visual, mientras que estos últimos
proporcionan fundamentalmente servicios.
Los componentes se desarrollan usando modelos de componentes. Dichos modelos
proporcionan el entorno en el que se ejecutan los componentes. Modelos populares de
componentes para la capa de presentación son los JavaBeans, o Microsoft ActiveX.
Componentes usuales de la capa de negocio incluyen CORBA (Common Object Request
Broker Architecture), y EJB (Enterprise Java Beans).
Los beneficios de una arquitectura multi-capa son obvios y numerosos: integración y
reusabilidad, encapsulación, distribución, particionamiento, escalabilidad, desarrollo
independiente, y desarrollo rápido, entre otros. Pero también presentan desventajas como
los riesgos de seguridad, y la gestión de los componentes. Además, la arquitectura lógica
tiene una arquitectura física asociada, que puede corresponderse con ésta o no (podemos
ubicar cada capa lógica en una física, o agrupar varias lógicas en una sola capa física, por
ejemplo para minimizar los tiempos de comunicación entre sus componentes).
Un ejemplo de arquitectura multi-capa son los sistemas basados en web, que presentan a
menudo una capa separada de la presentación denominada capa de componentes web,
para gestionar la lógica de la presentación de la web.
Con el auge de la web, la integración de aplicaciones adquiere un mayor significado que
va más allá de la mera combinación de aplicaciones en una empresa. Los servidores de la
empresa actualmente, manejan y mantienen grandes cantidades de datos y lógica del
negocio. Además, debido a que la web facilita el fácil acceso a los servicios y la
información, se ha convertido en uno de los principales medios de comunicación. Una
empresa debe ser capaz de hacer accesibles sus datos, desde empleados internos a socios
externos, suministradores y fabricantes.
Hasta ahora, las aplicaciones se clasifican como frontales de oficina (front-office) e
internas de la oficina (back-office). Las aplicaciones front-office se utilizan para
interactuar con el cliente o usuario final. Incluyen aplicaciones para la gestión de las
relaciones con los clientes y automatización de las tareas de marketing. Las aplicaciones
back-office proporcionan la infraestructura de la información para ejecutar los procesos
back-end de una empresa. Las aplicaciones que proporciona un ERP son buenos ejemplos
de aplicaciones back-office. La integración tradicional se centra en integrar las
aplicaciones front-office y back-office. Sin embargo, esta integración está siendo
condicionada por la web incluyendo también a las aplicaciones web.
Ya que es un imperativo para un EIS cambiar a una arquitectura basada en web, las
aplicaciones de la misma necesitan ser desplegadas en plataformas de aplicaciones
estándar, cada vez más extensamente utilizadas. Actualmente los servidores de empresa
se consideran como plataformas adecuadas para desarrollar aplicaciones web. Tal y como
muestra la Figura 8, los servidores de aplicaciones son particularmente apropiados para
50
las áreas B2C (business-to-customer) y B2B (business-to-business). El servidor de

aplicaciones proporciona un punto de integración natural entre los sistemas de
información existentes en la empresa y las aplicaciones web. El servidor de aplicaciones
ayuda también en el manejo de transacciones y puede escalarse si es necesario. La
plataforma J2EE es una tecnología a tener en cuenta para las empresas y vendedores de
aplicaciones.
Figura 8. ntegración de aplicaciones dirigida por la Web
3.5. Retos que plantea la EAI
Los EIS difieren significativamente, en términos de nivel de soporte tecnológico,

restricciones administrativas y tecnológicas, capacidad para integrarse con otros sistemas,
y el grado de exposición de detalles de bajo nivel. Por lo tanto, estos elementos
constituyen los principales retos que debe asumir la integración de aplicaciones:
• Nivel de soporte tecnológico: puede variar enormemente de unas aplicaciones a
otras. Tomemos por ejemplo, el soporte para transacciones y seguridad. Algunos EIS
pueden no ofrecer soporte para acceso transaccional, o, si tienen algún tipo de soporte,
está muy limitado. Otros EIS más avanzados ofrecen soporte para ambos servicios.
• Restricciones administrativas y tecnológicas: normalmente los sistemas legacy
suelen imponer restricciones de uso, debido a que están estructuradas de forma más
rígida. Por ejemplo, en un sistema de este tipo puede ser difícil crear nuevas cuentas
de usuario.
• Capacidad para integrarse con otros sistemas: los EIS pueden diferir en términos
de sus modelos de programación de aplicaciones y clientes API, lo que hace difícil su
integración con otros EIS. Estas diferencias existen debido a que dichas aplicaciones
se han desarrollado en momentos diferentes, utilizando las tecnologías más adecuadas
en dichos momentos. Y además no se ha tenido en cuenta la interoperabilidad con
otros sistemas como un objetivo de diseño primario.
• Grado de exposición de detalles de bajo nivel: los APIs de los clientes pueden
diferir en los detalles de bajo nivel de transacciones y seguridad que muestran a los
desarrolladores de aplicaciones, y esto complica la integración de diferentes EIS. El
desarrollador de aplicaciones debe conocer los detalles de programación de bajo nivel
del API del cliente para una integración efectiva. Por ejemplo, supongamos que un
EIS define el API del cliente usando una librería C. Dicha librería define métodos que
51
usan las aplicaciones cliente para gestionar las transacciones y realizar un acceso
transaccional a dicho EIS. La librería puede contemplar mecanismos de comunicación
distribuidos entre las aplicaciones cliente y los EIS. El desarrollador de aplicaciones
tiene por lo tanto, la tarea añadida de comprender esta librería C (y los mecanismos de
bajo nivel que contempla esta API), para usar el API del cliente. Esta complejidad
adicional incrementa el esfuerzo de la integración de aplicaciones.
Dada la complejidad del desarrollo de aplicaciones y la integración de los EIS, es
importante que los desarrolladores utilicen herramientas de desarrollo estándares y
entornos de integración.
El acceso transaccional y la seguridad son cuestiones importantes en términos de
integración EIS. Las empresas llevan a cabo sus negocios utilizando la información
almacenada en sus EIS, el éxito de una empresa depende de forma crítica de su
información, así como de un acceso seguro a la misma.
Otro requerimiento importante es la escalabilidad, con el fin de permitir que la empresa
pueda ampliar sus relaciones con suministradores, compradores, y socios. Para lograr
esto, el uso de un pooling de conexiones se convierte en un requerimiento importante para
la integración de sistemas.
Adicionalmente, las empresas deben considerar su inversión actual en las aplicaciones
existentes y un plan de integración que resulte efectivo en cuanto a coste. La mayoría de
las empresas y EIS han invertido cantidades considerables en el código de sus
aplicaciones e infraestructura asociada. Si bien reconocen la necesidad de migrar a una
plataforma J2EE, deben lograr esta integración de forma incremental en lugar de en un
solo paso. Una migración incremental les permite mantener un uso máximo de sus
sistemas existentes, pero añadiendo de forma gradual nuevas funcionalidades como
componentes J2EE, haciendo así accesibles sus aplicaciones mediante J2EE. Durante este
proceso de migración, pueden descargar sobre los vendedores del servidor de aplicaciones
la gestión de la complejidad de las transacciones y la seguridad, y así dejar que los
desarrolladores del software se centren en la resolución de problemas del dominio del
negocio.
3.6. Capas en la integración de aplicaciones
La integración de aplicaciones debe realizarse con un coste lo más bajo posible y en un

tiempo también corto, es decir, debe ser efectiva en coste y tiempo. La arquitectura de
integración se construye paso a paso y en varios niveles. La idea es dividir el problema de
integración en varios sub-problemas. Comenzaremos construyendo la arquitectura por el
nivel inferior e iremos subiendo. Los procesos más importantes en la integración de
aplicaciones son:
• Integración de la plataforma (hardware).
• Integración a nivel de datos.
• Integración de la interfaz de la aplicación.
52
• Integración de métodos del negocio.

• Integración de la presentación.
• Integración inter-EAI o integración B2B.
Omitir alguna capa acelera el proceso de integración a corto plazo, pero podemos estar
seguros de que "pagaremos por ello" a largo plazo. La capa de integración de interfaz de
la aplicación y métodos del negocio se combinan a veces en una capa denominada
integración a nivel de negocio.
Integración de la plataforma. Es el prerequisito para permitir la integración en su
totalidad. El objetivo es alcanzar la interoperatividad entre las diferentes plataformas, por
ejemplo mainframes con distintos sistemas operativos como VMV, OS/400, PC con
Windows, Linux, estaciones Solaris, AIX, etc. Actualmente la mayoría de plataformas
hardware utilizan estándares abiertos, con lo que alcanzar la interoperatividad de éstos no
plantea demasiadas dificultades. Sin embargo, los problemas se plantean con la
integración de plataformas ya no soportadas por sus vendedores, y también cuando se han
utilizado soluciones propietarias.
Integración a nivel de datos. A menudo la integración a nivel de datos es el punto de
partida de la integración. Esta capa habilita el acceso a los datos compartidos por otras
aplicaciones y permite mover dichos datos entre diferentes almacenamientos de datos. La
integración a nivel de datos puede complicarse bastante cuando se ven implicados cientos
de estos almacenamientos. Las dificultades típicas son la no comprensión de los
esquemas, identificación de los datos, garantía de la consistencia, etc. Además, es
necesario unificar el modelo de datos, resolviendo las redundancias de datos y anomalías
semánticas introducidas durante el desarrollo a lo largo de los años.
Integración de la interfaz de la aplicación. Esta capa habilita una forma de integración
de alto nivel, en la que una aplicación usa alguna otra funcionalidad residente en otra
aplicación. Esto se consigue usando las interfaces de programación de aplicaciones
(APIs) que cada una de ellas expone a las demás. A menudo se utiliza alguna forma de
middleware para transferir las peticiones y resultados, como los orientados a mensajes
(MOM), procedimientos remotos (RPC), e incluso los Object Request Brokers (ORB).
Integración de métodos del negocio. Esta integración permite dar soporte a los procesos
del negocio en la empresa mostrando los métodos de alto nivel como abstracciones
accesibles mediante interfaces. Esta capa presenta el sistema de información de la
empresa en su totalidad tal y como quisiéramos tenerlo (o tal y como quisiéramos haberlo
desarrollado si pudiésemos reconstruirlo de nuevo con unos requerimientos claros sobre
lo que pretendemos obtener del sistema integrado, con el conocimiento y soporte de las
nuevas tecnologías). Esto significa que las interfaces del sistema de información se basan
en una arquitectura moderna. Pero las funcionalidades no son reimplementadas; en su
lugar usan las aplicaciones existentes. Dichas aplicaciones se remodelan de tal forma que
expongan la funcionalidad de la capa de proceso del negocio y se incluyan en la nueva
arquitectura. El conseguir la integración a nivel de negocio se asocia a menudo con el
proceso de reingeniería del negocio y no es únicamente un problema técnico. Requiere la
53
implementación de varias capas como base para integrar las aplicaciones en un nivel alto
de abstracción.
Integración de la presentación. Una vez que las aplicaciones existentes se remodelan y
encapsulan en la capa intermedia, en la que exponen su funcionalidad a través de
interfaces de alto nivel, resulta crucial que el usuario también observe una vista unificada
del sistema de información. Mediante el desarrollo de una capa de presentación unificada,
estaremos ocultando el hecho de que las aplicaciones que se están ejecutando son
aplicaciones diferentes, algunas de ellas legacy, y otras desarrolladas recientemente. De
esta manera se mejora la eficiencia de los usuarios finales, ya que no tienen que cambiar
entre diferentes aplicaciones existentes y usar diferentes interfaces de usuario. Además, se
proporciona una forma de reemplazar parte de los sistemas legacy en el futuro sin
influenciar al resto de partes del sistema.
Integración inter-EAI o integración B2B. Actualmente la integración de las
aplicaciones de una compañía puede no resultar suficiente. Hay una necesidad creciente
de permitir una integración entre empresas, a menudo referida como integración B2B
(business-to-business), o también e-business. Por supuesto, el requerimiento para una
integración eficiente B2B requiere una integración de cada una de las empresas a nivel de
negocio en ambos sentidos.
3.7. Uso de middleware para EAI
Se denomina middleware al software de los servicios del sistema que se ejecuta entre la
capa del sistema operativo y la capa de aplicación. Conecta dos o más aplicaciones,
proporcionando interoperabilidad entre ellas. El concepto de middleware cobra
protagonismo hoy en día, ya que todos los proyectos de integración tienen que usar una o
varias soluciones diferentes middleware.
Usaremos el término middleware para denotar a aquellos productos software que actúan
como "pegamento" entre aplicaciones, que sean distintos de simples funciones de
importación y exportación de datos que pudieran formar parte de las propias aplicaciones.
Todas las formas de middleware son útiles para facilitar la comunicación entre diferentes
aplicaciones software. El middleware introduce un nivel de abstracción en la arquitectura
del sistema, reduciendo así su complejidad considerablemente. Por otro lado, cada
producto middleware introduce una cierta sobrecarga en el sistema con respecto a la
comunicación, lo cual puede afectar al rendimiento, la escalabilidad, y otros factores de
eficiencia. Esto es importante tenerlo en cuenta, particularmente si nuestros sistemas son
críticos y son usados por un gran número de clientes concurrentemente.
Los productos middleware comprenden una amplia variedad de tecnologías, incluyendo
las siguientes:
Tecnologías de acceso a bases de datos. Proporcionan acceso a una base de datos a
través de una capa de abstracción que permite cambiar el sistema de gestión de base de
54
datos (DBMS) sin tener que modificar el código fuente de la aplicación. En otras
palabras, permiten usar el mismo o similar código para acceder a diferentes fuentes de
bases de datos. Las tecnologías de acceso a bases de datos difieren en la forma de los
interfaces que proporcionan. Pueden ofrecer acceso a las bases de datos orientado a la
función o a objetos. Los representantes más conocidos son JDBC y Java Data Objects
(JDO) en la plataforma Java, y Open Database Connectivity (ODBC) y Active Data
Objects (ADO) en la plataforma Microsoft.
Middleware orientado a mensajes. También denominado MOM: Message Oriented
Middleware. Es una estructura cliente/servidor que incrementa la interoperabilidad,
flexibilidad y portabilidad de las aplicaciones. Permite la comunicación entre aplicaciones
entre plataformas distribuidas y heterogéneas, y reduce su complejidad debido a la
ocultación de los detalles de la comunicación y de las plataformas y protocolos
implicados; la funcionalidad del MOM es accedida mediante APIs. Las aplicaciones
pueden por lo tanto intercambiar datos sin necesidad de comprender los detalles del resto
de aplicaciones, arquitecturas y plataformas implicadas.
Geralmente MOM reside tanto en la parte del cliente como en la del servidor.
Proporciona comunicación asíncrona mediante el uso de colas de mensajes para
almacenar los mensajes temporalmente. La comunicación puede darse incluso aunque el
receptor esté temporalmente no disponible, y los mensajes pueden contener casi cualquier
tipo de dato. Cada mensaje espera en la cola y es entregado tan pronto como el receptor es
capaz de aceptarlo. La comunicación asíncrona tiene el inconveniente de que, ya que el
servidor no bloquea a los clientes, puede continuar aceptando peticiones con el riesgo de
producir una situación de sobrecarga.
La Figura 9 muestra dos aplicaciones que usan MOM. Las aplicaciones acceden a MOM
a través de un API, y son responsables de construir y analizar los mensajes, pero MOM
oculta todos los detalles de red y transporte.
Figura 9. Comunicación de aplicaciones mediante MOM
55
MOM es adecuado para comunicación entre aplicaciones dirigida por eventos. También
es adecuado para sistemas orientados a objetos. Los productos MOM son propietarios y
están disponibles desde mediados de los 80, de forma que son incompatibles entre ellos.
El uso de un único producto tiene como consecuencia la dependencia de un vendedor
específico, lo que puede influenciar negativamente la flexibilidad, portabilidad,
mantenibilidad e interoperabilidad de las aplicaciones. El mismo producto MOM debe
poder ejecutarse sobre cada una de las plataformas que están siendo integradas. Sin
embargo, no todos los productos MOM soportan todas las plataformas, sistemas
operativos y protocolos. La plataforma Java proporciona formas de conseguir una
relativamente alta independencia de un vendedor específico mediante una interfaz común,
usada para acceder a todos los productos middleware: el servicio de mensajes java (JMS).
Llamadas a procedimientos remotos (RPC). Las RPC: Remote Procedure Call
constituyen una infraestructura cliente/servidor orientada a mejorar la interoperabilidad
entre las aplicaciones desde plataformas heterogéneas. Al igual que MOM, oculta los
detalles de la comunicación. La principal diferencia con MOM es la forma de
comunicación, mientras que MOM soporta comunicación asíncrona, RPC promueve la
comunicación síncrona en forma de petición-espera, que bloquea al cliente hasta que el
servidor completa la respuesta. RPC previene la sobrecarga de la red (a diferencia de
MOM). Hay alguna implementación asíncrona de RPC disponible, pero son la excepción
y no la regla. En la Figura 10 se muestra un esquema de dos aplicaciones que utilizan
RPC.
Figura 10. Comunicación de aplicaciones mediante RPC

RPC es adecuado para aplicaciones cliente/servidor el las que el cliente puede realizar
una petición y esperar a que el servidor emita la respuesta antes de continuar el proceso.
Además, RPC requiere que el receptor de la llamada esté disponible para aceptar la
llamada remota. Si el receptor falla, la llamada remota no tiene lugar, ya que las llamadas
no se almacenan temporalmente tal y como ocurre en MOM.
Monitores de procesamiento de transacciones (TP). Los TP: Transaction Processing
56
monitors, son importantes en aplicaciones con requisitos críticos. Representan la primera

generación de servidores de aplicaciones. Los TP se basan en el concepto de
transacciones, de forma que monitorizan y coordinan las transacciones entre diferentes
recursos. Si bien el nombre sugiere que esta es su única tarea, tienen otras funcionalidades
adicionales: gestionar el rendimiento, y servicios de seguridad, tal y como muestra la
Figura 11.
Figura 11. Comunicación de aplicaciones mediante TP

Los TP gestionan el rendimiento de las transacciones mediante técnicas de balanceo de
carga y de poolling de recursos, de forma que pueda existir un gran número de clientes
accediendo concurrentemente y de forma eficiente a los recursos de computación. Por
otro lado los servicios de seguridad proporcionados por los TP permiten habilitar o
deshabilitar accesos de clientes a fuentes particulares de datos.
Intermediarios de peticiones de objetos (ORB). Los ORB: Object Request Brokers,
gestionan y soportan la comunicación entre objetos distribuidos o componentes sin
necesidad de preocuparse por los detalles de la comunicación. Los detalles de
implementación de un ORB no están visibles para los componentes. De esta forma se
proporciona transparencia en la localización, transparencia en el lenguaje de
programación, protocolo y sistema operativo.
La comunicación se lleva a cabo a través de interfaces, y normalmente es síncrona.
Proporcionan la ilusión de "localidad", haciendo que todos los componentes parezcan
locales, aunque en realidad estén en otra red. Simplifican el desarrollo de forma
considerable pero pueden tener una incidencia negativa en el rendimiento de la
aplicación.
La Figura 12 muestra dos componentes que se comunican mediante un ORB.
57
Figura 12. Comunicación de aplicaciones mediante ORB

Hay tres estándares principales para ORBs: (a) OMG CORBA, (b) Java RMI y
RMI-IIOP, y (c) Microsoft COM/DCOM/COM+.
Hay muchos productos que cumplen el estándar ORB. RMI-IIOP. RMI-IIOP utiliza el
mismo protocolo para comunicaciones entre componentes que CORBA ORB, de forma
que resulta interoperable con CORBA.
Solamente existe una implementación del modelo Microsoft, el cual difiere de los otros
dos en algunos conceptos importantes. Aún así, la interoperabilidad entre RMI-IIOP y
CORBA por un lado, y el modelo de Microsoft por otro, es posible.
Servidores de aplicaciones. Son la forma más reciente de middleware. Manejan todas o
la mayoría de las interacciones entre la capa del cliente y la capa de persistencia de datos.
Proporcionan una colección de servicios middleware como los ORBs, MOM, gestión de
transacciones, seguridad, balanceo de carga y gestión de recursos. Además incluyen una
gestión del entorno en el que se despliegan los componentes lógicos del negocio: el
contenedor.
Los servidores de aplicaciones proporcionan una plataforma excelente para integración.
Independientemente de que se use para integración o para el desarrollo de aplicaciones
nuevas los servidores de aplicaciones son plataformas software. Una plataforma software
es una combinación de tecnologías software necesarias para ejecutar aplicaciones. En este
sentido los servidores de aplicaciones, o más específicamente, la plataforma software que
soportan, definen la infraestructura de todas las aplicaciones desarrolladas y ejecutadas
sobre ellos. Los servidores de aplicaciones son la plataforma de integración a elegir para
aplicaciones desarrolladas con una arquitectura multi capa. Ademas, los servidores de
aplicaciones pueden soportar una plataforma software estandarizada, abierta y
generalmente aceptada.
Los aspectos más importantes a tener en cuenta en una plataforma software son:
• Aspectos técnicos: incluyen las tecnologías software que se incluyen en la plataforma,
así como interoperabilidad, escalabilidad, portabilidad, disponibilidad, fiabilidad y
seguridad, entre otras cuestiones.
58
• Carácter abierto: existen diferentes soluciones, desde plataformas cerradas asociadas

a un vendedor particular, hasta plataformas totalmente abiertas, en donde cada cosa,
incluido el software es de libre distribución y puede cambiarse libremente.
• Interoperabilidad: es crucial para considerar la adopción de una determinada
plataforma, en particular la forma en que dicha plataforma regula las adiciones y
modificaciones de software.
• Coste: probablemente es el más difícil de evaluar debido a que incluye los costes del
servidor de aplicaciones, del hardware, del aprendizaje de su uso, y el coste del
mantenimiento de las aplicaciones.
• Madurez: es un indicador de cuán estable es la plataforma. Cuanto más madura sea,
más habrá sido probada en entornos reales, probando su idoneidad para aplicaciones a
gran escala.
Las plataformas de integración típicamente tienen más de una tecnología middleware. De
hecho es usual encontrar productos middleware de diferentes vendedores en una misma
plataforma de integración. Por ejemplo, en servidores de aplicaciones que cumplen J2EE,
diferentes vendedores incluyen diferentes tipos de middleware adicional. El servidor de
aplicaciones WebSphere de IBM, por ejemplo, incluye el motor de mensajes IBM
MQSeries, y el servidor Bea Weblogic incluye el monitor de transacciones Tuxedo.
3.8. Servicios de infraestructura necesarios para la integración
La infraestructura de integración consiste en el conjunto de tecnologías middleware que

proporcionan los servicios necesarios para establecer la comunicación entre las
aplicaciones. Para realizar una mejor selección de las tecnologías que se van a usar para la
integración, en primer lugar nos centraremos en los servicios de infraestructura
requeridos. Vamos a identificar dichos servicios desde una perspectiva de alto nivel y los
separemos en capas horizontales y verticales. Los servicios de las capas horizontales
proporcionan servicios básicos de infraestructura útiles para la mayoría de las
aplicaciones existentes así como aplicaciones de nueva generación. Los servicios de la
capa vertical proporcionan funcionalidades relacionadas con una tarea específica que
puede extenderse a través de varios servicios de la capa horizontal.
Los servicios de las capas horizontales incluyen: (a) Comunicación; (b) Brokering y
routing; (c) Lógica del negocio. Los servicios de las capas verticales son: Transacciones,
Seguridad, Ciclo de vida, Nombrado, Escalabilidad, Gestión, Reglas. Los servicios
mencionados se pueden apreciar en la Figura 13.
59
Figura 13. Relaciones entre los servicios de infraestructura de integración

Comunicación. Proporciona transparencia para el acceso a diferentes sistemas remotos y
unifica la vista de los mismos. Asegura, por lo tanto, que los desarrolladores no tiene que
tratar con los detalles de comunicación a bajo nivel. Debido a que la capa de
comunicación no ejecuta lógica del negocio, permite una separación entre los servicios de
la capa del negocio y la capa de comunicación, aunque permite comunicación entre ellas.
Las tecnologías más utilizadas son las de acceso a base de datos, como JDBC, tecnologías
MOM, y tecnologías RPC. La capa de comunicación proporciona también transparencia
en la localización.
Brokering y Routing. Constituyen la implementación de la parte técnica de la
integración. No importa que tipo de integración se use, esta capa deberá adaptar las
comunicaciones entre las aplicaciones participantes en la integración de forma que todas
ellas sean capaces de interoperar.
En primer lugar, esta capa tiene que proporcionar la forma de reunir los datos requeridos
desde múltiple fuentes, provenientes de aplicaciones existentes y nuevas, y/o
almacenamientos de datos. A esta responsabilidad se le denomina agregación, ya que los
datos se obtienen de diferentes fuentes para representar un concepto del negocio, como
por ejemplo una factura.
En segundo lugar, estos datos deben procesarse, de forma que esta capa tendrá que
transformar y dividir los datos y mensajes en partes adecuadas para que puedan
procesarse por las aplicaciones individuales.
Finalmente, esta capa debe reunir los resultados de todas las aplicaciones y presentarlos
de forma consistente.
Para conseguir estos tres pasos, esta capa necesita información de meta-datos que defina
las aplicaciones participantes, métodos, mensajes, e interfaces, y la secuencia de
operaciones implicadas. Esta capa también proporciona formas de manejar eventos, que
serán asociados con ciertas operaciones a realizar.
No hay una única tecnología middleware estandarizada que proporciona todos los
requerimientos necesarios para esta capa. De forma que se usarán varias tecnologías
diferentes, incluyendo MOM, RPC, ORBs, y servidores de aplicaciones.
60
Lógica del negocio. Esta capa es la responsable de presentar un interfaz de alto nivel que
permita acceder a la información del negocio para otras aplicaciones y para los usuarios,
presentando los datos a los usuarios en una forma comprensible.
Actualmente, esta capa es soportada por la capa de presentación, normalmente en forma
de portales personalizados.
Adicionalmente a la entrega de datos y contenidos, esta capa está conectada a menudo
con tecnologías de procesamiento de datos como OLAP (Online Analytical Processing),
data mining y sistemas de soporte de decisiones, entre otros. Estas fuentes analizan los
datos de la empresa y proporcionan informaciones tales como estimaciones y pronósticos.
Transacciones. La infraestructura de integración debe proporcionar los medios para
llevar a cabo las operaciones de la empresa de forma transaccional. Por lo tanto debe ser
capaz de invocar varias operaciones sobre diferentes sistemas existentes y de nueva
generación como una operación atómica que cumpla con las propiedades denominadas
ACID (Atomicity, Consistency, Isolation and Durability).
Seguridad. Se debe proporcionar la forma de restringir el acceso al sistema. La seguridad
debería incluir a las tres capas horizontales. El sistema de seguridad no debería basarse en
diferentes passwords para diferentes aplicaciones o incluso entre partes de la misma
aplicación.
Ciclo de vida. Se trata de proporcionar formas de controlar el ciclo de vida de las
aplicaciones implicadas. Se debería permitir que las aplicaciones existentes fuesen
reemplazadas de una en una, sin influenciar al resto de aplicaciones del sistema integrado.
Hay que hacer hincapié en que este reemplazamiento debería ser posible paso a paso,
cuando lo dicten las necesidades de la empresa y cuando estén disponibles los recursos
suficientes. También se debe permitir que el reemplazo tenga lugar mientras el sistema
permanece on-line. Esta última funcionalidad se consigue a menudo minimizado las
dependencias entre las aplicaciones y formas específicas en las que interoperan las
aplicaciones.
Nombrado. Un servicio unificado de nombres permitirá a la implementación
transparencia en la localización y el reemplazo de un recurso por otro si éste es requerido.
Normalmente se implementa con un producto de nombrado y directorios que permite el
almacenamiento y la búsqueda de información relacionada mediante nombres.
Idealmente, el servicio de nombres se debe unificar.
Escalabilidad. Es una característica que debe tenerse en mente a la hora de diseñar la
infraestructura de integración. Se debe permitir el acceso a información sobre los clientes
y proporcionar acceso concurrente a las aplicaciones. Se deben incorporar soluciones que
permitan extender las demandas de carga del sistema. Puede ser un problema difícil el
proporcionar escalabilidad en un sistema integrado debido a que se deben tener en cuenta
aplicaciones existentes que probablemente no hayan sido diseñadas para el grado de
escalabilidad que deseamos conseguir. Por ello, se deben implementar algunos prototipos
para probar qué niveles de rendimiento se pueden esperar. También deberían usarse
61
herramientas de pruebas de carga que permitan simular cargas elevadas y evaluar criterios
de rendimiento.
Gestión. Se deben proporcionar los mecanismos para gestionar la infraestructura de
integración. El no hacerlo puede ocasionar dificultades en la fase de mantenimiento. Se
debe proporcionar una gestión de versiones y configuración sencilla. Una gestión
declarativa permite el acceso a cambios y actualización de parámetros sin necesidad de
modificar los fuentes y volver a desplegar las soluciones. Una gestión remota permite
llevar a cabo la gestión de la infraestructura de forma remota, minimizando la necesidad
de entrenamiento del personal en los lugares de trabajo.
Reglas. Los servicios horizontales requieren reglas específicas para realizar la
comunicación, brokering, routing, y tareas de lógica del negocio. Estas reglas con
deberían estar codificadas en el "interior" de las aplicaciones, sino que deberían
especificarse de una forma declarativa formando parte de la infraestructura de
integración. Esto incluye definiciones, formatos de datos, transformaciones de datos y
flujos, eventos, procesamiento de información y representación de la información. A
menudo estas reglas se almacenan en un repositorio, lo cual proporciona un
almacenamiento centralizado evitando así duplicaciones e inconsistencias.
Como hemos visto, los servicios de infraestructura pueden ser realizados por diferentes
tecnologías middeware. Al seleccionar y reunir tecnologías diferentes hay que tener en
cuenta su interoperabilidad. Alcanzar dicha interoperabilidad entre tecnologías puede ser
difícil, incluso para aquellas basadas en estándares abiertos; para soluciones propietarias
es todavía más difícil.
No solamente es una cuestión de si podemos alcanzar interoperabilidad, sino cuánto
esfuerzo tenemos que invertir para conseguirlo. Por ello, las empresas se inclinan cada
vez más hacia plataformas software que reúnen tecnologías compatibles. El uso de una
plataforma software normalmente ahorra mucho trabajo adicional. Actualmente hay tres
plataformas importantes:
• La plataforma Java 2, Enterprise Edition (J2EE)
• CORBA
• Microsoft.NET
J2EE y CORBA tienen asociadas unas especificaciones y diferentes vendedores ofrecen
productos que cumplen dichas especificaciones. En este sentido son plataformas abiertas,
J2EE está controlado por Sun y JCP (Java Community Process), y CORBA por OMG.
Por otro lado Microsoft.NET es una plataforma propietaria y dirigida específicamente a
plataformas Windows. Las tres plataformas proporcionan un conjunto de tecnologías, más
o menos apropiadas para integración.
Todos los productos EAI incluyen un componente denominado integration broker o
intermediario de integración. Un intermediario de integración es una abstracción utilizada
para las tecnologías que componen la infraestructura de integración. El intermediario
proporciona los servicios horizontales y verticales que hemos identificado, y centraliza la
62
gestión de dichos servicios.

El intermediario de integración se usa en todos los niveles de integración, facilitando el
camino para construir las capas de integración paso a paso y reusar resultados previos,
evitando cualquier dependencia de la comunicación punto a punto entre las aplicaciones.
La integración punto a punto tiene los siguientes inconvenientes:
• El número de conexiones entre aplicaciones puede llegar a ser muy grande
• Un elevado número de dependencias entre aplicaciones requiere demasiado esfuerzo
de mantenimiento
• El mantenimiento de los enlaces entre las aplicaciones puede llegar a ser más costoso
que el mantenimiento de las propias aplicaciones, haciendo menos obvios los
beneficios de la integración
El intermediario de integración proporciona un mediador común, al que todas las
aplicaciones deben conectarse, reduciendo así la multiplicidad n-a-n de la integración
punto a punto, a 1-a-n. Además, no solamente conecta las aplicaciones, sino que basa la
integración en contratos entre aplicaciones. Estos contratos se expresan generalmente en
forma de interfaces de interoperabilidad.
Las interfaces de interoperabilidad definen qué servicios pueden pedir las aplicaciones
clientes a las aplicaciones servidor. Dichas interfaces son efectivamente contratos de larga
duración que definen el acoplamiento entre aplicaciones integradas. En la medida en la
que las interfaces permanecen inalterables, podemos reemplazar partes o la totalidad de
aplicaciones servidor sin influenciar en nada en ninguna aplicación cliente. La Figura 14
muestra un intermediario de integración y las interfaces de interoperabilidad.
Figura 14. Intermediario de integración e interfaces de interoperabilidad
3.9. Técnicas de integración
63
En primer lugar debemos seleccionar las aplicaciones que incluiremos en la integración,

que deberá incluir dos tipos de aplicaciones: las aplicaciones primarias y las subsidiarias.
Las aplicaciones primarias de una empresa son aquellas importantes para la compañia en
su totalidad, son usadas por un gran número de empleados, y están bajo el control del
departamento que desarrolla las aplicaciones informáticas. Las aplicaciones subsidiarias
son usadas normalmente por un único empleado, y probablemente sin el conocimiento del
departamento de desarrollo de informática; se trata de aplicaciones usadas diariamente
pero no soportadas por las aplicaciones primarias; ejemplo de dichas aplicaciones
incluyen la impresión de circulares, la generación de informes específicos, etc. El no
incluir las aplicaciones subsidiarias en la integración puede dar lugar a varios problemas
(ya que sus usuarios continuarán utilizándolas), incluyendo las tranferencias manuales de
datos entre las aplicaciones primarias y subsidiarias y el almacenamiento en
computadores locales de datos importantes en varios formatos, como procesadores de
texto u hojas de cálculo.
Una vez que hemos seleccionado las aplicaciones a integrar, debemos elegir la
aproximación de integración. Podemos distinguir dos aproximaciones diferentes, cada
una de las cuales tiene ventajas e inconvenientes:
• Aproximación descendente (top-down)
• Aproximación ascendente (botton-up)
La aproximación botton-up se centra en problemas individuales que surgen debido a la
ausencia de integración de las aplicaciones. Resuelve los problemas específicos a través
de proyectos de integración no coordinados, evitando las cuestiones de la arquitectura de
integración global.
Esta aproximación que sigue el patrón de implementar soluciones parciales conduce a
soluciones rápidas, pero que pueden ocultar problemas, que con seguridad saldrán a la luz
posteriormente. Implementar una integración sin planificación es una opción que
solamente los más optimistas deberían contemplar, o bien aquellos que no tengan otra
opción debido a que los órganos de gestión de la empresa ya han tomado sus decisiones.
Muchas veces, los órganos de gestión de la empresa ven al departamento de desarrollo de
informática como un órgano cuyo propósito es proporcionar una solución en el mínimo
tiempo posible y con unos costes mínimos a corto plazo. También muchas veces, dichos
órganos de gestión de la empresa no quieren ni oír que una solución total de integración
(con un largo tiempo de desarrollo) podría proporcionar resultados mucho mejores a largo
plazo. Lo que complica todavía más las cosas es que la compañía probablemente no se de
cuenta a tiempo de esta realidad y continúe soportando el resto de proyectos de la misma
forma, ocasionando el alcanzar un punto sin retorno a medida que se van parcheando
soluciones en capas superiores. El sistema entonces alcanzará un nivel de complejidad no
manejable.
En definitiva, la aproximación bottom-up para integración probablemente conducirá a la
compañía un paso adelante al principio, pero pronto tendrá necesidad de volver hacia
64
atrás varios pasos. Por lo tanto esta aproximación es altamente desaconsejable, siendo
mucho mejor la aproximación top-down.
La aproximación top-down es esencialmente una estrategia de integración definida. El
comenzar la integración simplemente conectando las aplicaciones sin un buen plan y
arquitectura, podría conducir casi con toda seguridad a un gran número de conexiones
punto a punto que resultarían difíciles de gestionar y mantener. En su lugar, se define en
primer lugar una arquitectura del sistema integrado, y solamente entonces se empezará a
revisar las aplicaciones existentes y decidir como pueden encajarse en la arquitectura de
integración. Esta aproximación presenta varias ventajas y nos permitirá construir la
arquitectura en la que se ubicarán de igual forma tanto las aplicaciones existentes como
sistemas de nueva generación. Además nos permitirá reemplazar y realizar reingeniería
sobre sistemas existentes con nuevos desarrollos. Esta forma de pensar es lo que se
conoce como aproximación top-down.
La aproximación top-down centra su atención en la integración como actividad global.
Identifica una estrategia de integración conjunta que define todos los aspectos previsibles
de los problemas del negocio relacionados con la integración, analiza las dependencias
existentes, fija guías de actuación, y define prioridades. Gestiona la integración como un
gran proyecto coordinado y comparte esfuerzos con todas las partes implicadas.
Debería quedar claro que la integración no es solamente un problema técnico. En lugar de
eso, requiere también un buen nivel de organización y gestión para que la integración
tenga éxito. Además resulta crucial que la compañia inicie el proyecto de integración con
los suficientes recursos, prioridades y autorización para ser capaz de conseguir una buena
coordinación de las partes implicadas.
Para conseguir una buena coordinación existen varias posibilidades, una de las cuales
consiste en introducir y organizar un nuevo servicio denominado servicio de integración,
responsable de la integración. Dicho servicio debería tener tres responsabilidades
principales:
• Definición de la arquitectura de integración
• Selección de la infraestructura y tecnologías de la integración
• Desarrollo y mantenimiento de la documentación de la integración
3.10. Opciones alternativas a la integración
La EAI no representa una solución fácil o rápida hacia un sistema de información

integrado. Antes de decidirnos por la integración se deberían examinar otras
posibilidades. Generalmente, estas incluyen:
• Reemplazamiento
• Extensión
Reemplazamiento de los sistemas. Con ánimo de ahorrar tiempo y dinero, los gestores a
menudo considerarán el reemplazamiento total o parcial de los sistemas existentes. El
65
reemplazamiento requiere un claro "corte" y parada del uso de las aplicaciones existentes
y un cambio al nuevo sistema.
Para reemplazar las aplicaciones se puede optar por comprarlas o desarrollarlas, bien por
nosotros o por terceros. Los factores determinantes para elegir entre comprar o desarrollar
son esencialmente el tipo de aplicación a reemplazar y el grado en el que una aplicación
comercial podría satisfacer nuestras necesidades. Si bien en teoría, la compra es la
solución preferida sobre el desarrollo al ser mucho más rápida, tiene inconvenientes
importantes. Primero es poco probable que una aplicación comercial cubra las
necesidades del negocio de forma tan eficiente o global como una solución desarrollada a
medida. Y además no podremos influenciar en el desarrollo de la aplicación o su
modificación de la misma forma que si se trata de una solución a medida.
Por otro lado, la flexibilidad de las aplicaciones a medida se consigue en un tiempo mayor
que el del desarrollo. Y además las compañías actualmente rara vez cuentan con los
recursos para realizar por sí mismas largos desarrollos, y encargar el desarrollo a una
empresa externa no necesariamente acelera dicho desarrollo.
Otra cuestión importante (quizá más importante que la decisión desarrollar-comprar) es la
de qué aplicaciones se van a reemplazar, si solamente parte de ellas (por ejemplo las
aplicaciones legacy), o todas.
Si reemplazamos parte de ellas, realmente no hemos solucionado el problema original: la
integración. Por lo tanto, en términos de integración, la única decisón razonable es
reemplazar el sistema de información en su totalidad con una nueva solución integrada.
Sin embargo, el total reemplazamiento del sistema no es aplicable en muchos casos
debido a:
• la necesidad de tiempo, recursos y conocimiento para crear el sistema desde cero
simplemente no es posible,
• no existen herramientas comerciales (por ejemplo ERPs) que se adapten al 100% a
nuestras necesidades (un estudio sugiere que suelen cubrir alrededor de un 30% ó
40% de las necesidades de la empresa, por lo que se están introduciendo interfaces
interoperables en este tipo de productos),
• se necesitan tiempos y recursos adicionales para desplegar, transferir los datos y
entrenar a los usuarios que van a usar el nuevo sistema.
Extensión de los sistemas. Debido a las ajustadas agendas que imponen los órganos de
gestión de la empresa, muchas veces los desarrolladores optan por extender la
funcionalidad de las aplicaciones existentes en vez de integrarlas en su totalidad. Dichas
extensiones no están centradas en la arquitectura global de la aplicación, sino que intentan
modificar aplicaciones existentes para que puedan acomodarse a los cambios. Las
modificaciones se llevan a cabo sin determinar en qué modo se adecúan y contribuyen a
los requerimientos globales de la empresa y la arquitectura de información, tratando cada
aplicación como un dominio separado.
66
La extensión de aplicaciones se usa frecuentemente, debido a que proporcionan

soluciones rápidamente y con poco esfuerzo. Los escenarios más obvios son el añadir un
interfaz gráfico de usuario a una aplicación legacy. Más recientemente, un problema
comparable es el relacionado con la adición de un front-end basado en Web, y la
implementación de colaboraciones B2B o B2C sobre las aplicaciones existentes. La
Figura 19 muestra dos aplicaciones existentes que tienen implementado un intercambio
de datos. Una de las aplicaciones se extiende con un front-end basado en Web que
permite acceder a alguna de las funcionalidades mediante web. Adicionalmente, se
dispone de un "puente" (bridge) de bases de datos que permite el acceso a los datos desde
otras aplicaciones.
Figura 19. Extensión de aplicaciones

Si bien esta arquitectura parece razonable, presenta varios inconvenientes en términos de
integración. La extensión anterior efectivamente modifica la arquitectura de la aplicación
existente sin pensar en una arquitectura global, pero presenta los mismos inconvenientes
que la aproximación de integración botton-up: fomenta las conexiones punto a punto que
son difíciles de mantener a largo plazo debido a que en este escenario las aplicaciones
están estrechamente acopladas (tightly coupled). Únicamente es cuestión de tiempo que la
complejidad se vuelva demasiado grande para gestionar todos los cambios requeridos.
3.11. Arquitectura de integración
La arquitectura de integración especifica la estructura en su totalidad, los componentes

lógicos y las relaciones lógicas entre las diferentes aplicaciones que queremos integrar.
Los dos objetivos esenciales de los sistemas de información integrados que deben ser
soportados por la infraestructura de integración y por la arquitectura para un desarrollo
67
más sencillo son:

• Entradas de datos únicas. Claramente, entradas de datos únicas aseguran que los datos
son introducidos en el sistema únicamente una vez, garantizan la consistencia y
minimizan los errores provocados por el volver a teclear los datos y la gestión de
almacenamientos locales de los datos de la empresa.
• Acceso a información con baja latencia. También denominado acceso a datos con
latencia cero. Con ello nos aseguramos que los cambios realizados en una parte del
sistema de información son visibles en todas las partes relacionadas de forma
inmediata (o en el menor tiempo posible).
Ambos objetivos son difíciles de alcanzar. La dificultad con respecto a las entradas de
datos únicas la plantean la existencia de aplicaciones subsidiarias que los usuarios utilizan
diariamente para proporcionar soluciones a problemas diarios de los mismos. Con
respecto a la baja latencia de acceso a la información, es difícil de lograr debido a que la
funcionalidad requerida para realizar las tareas de la empresa están dispersas entre
aplicaciones diferentes, tanto conceptual como físicamente.
Resolver el problema de la dispersión entre aplicaciones puede lograrse de diferentes
formas. Históricamente, este problema se ha tratado solamente a nivel de datos, en donde
soluciones típicas incluyen la construcción de bases de datos consolidadas y warehouses.
Estas técnicas implican recolectar pequeñas cantidades de datos de vez en cuando y
almacenándolos en la base de datos central en un formato adecuado para realizar análisis
y otras tareas. Esta aproximación no soluciona el problema de la latencia cero, debido a
que en el mundo real las transferencias de datos solamente se pueden realizar pocas veces
a lo largo del día.
El acceso a los datos en tiempo real es mucho más difícil de implementar, y más teniendo
en cuenta que debemos tratar con muchas fuentes de datos distribuidas. El acceso en
tiempo real presenta limitaciones en cuanto a rendimiento y escalabilidad.
La forma más eficiente de acceder a los datos es a través de la lógica de la aplicación. A
continuación analizaremos una arquitectura multi-capa que permite alcanzar los objetivos
mencionados. Para ello nos centraremos en el concepto de componentes virtuales.
Un sistema de información basado en componentes virtuales es un sistema que "parece"
un sistema de información desarrollado nuevamente, mientras que realmente está
reusando la funcionalidad de las aplicaciones existentes.
Podemos pensar que un sistema de información basado en componentes es un
reemplazamiento de todas las aplicaciones existentes, pero que no tiene los
inconvenientes asociados con los reemplazamientos. Por otro lado, ya que se reusan las
aplicaciones existentes no se añaden costes y no se requiere tanto tiempo adicional como
en el reemplazamiento clásico de las aplicaciones.
El sistema de información basado en componentes es el objetivo último de la EAI:
permite el acceso a toda la información y el uso de cualquier funcionalidad a través de
68
componentes virtuales, con ello se consigue, además obtener información con baja
latencia y garantizar que solamente necesitamos introducir la misma información en el
sistema una vez.
Los componentes virtuales son bloques de construcción sobre los que basaremos la
integración. Encapsulan los detalles y métodos que las aplicaciones existentes usan para
satisfacer las peticiones realizadas sobre ellas. Por un lado, muestran la aplicación
existente a través de unos interfaces, y por otro lado, se comunican con la aplicación
existente utilizando las facilidades que ya tiene implementadas.
La interoperabilidad entre componentes virtuales se consigue mediante el uso de un
intermediario de integración. Los componentes virtuales deberán definir los contratos, o
los interfaces de interoperabilidad, a través de los cuales se proporcionará la
funcionalidad al resto de componentes.
Los interfaces de los componentes introducirán una aproximación basada en servicios
para reusar la funcionalidad, y expondrán todos ellos un conjunto de servicios
normalizados que diferirán en complejidad y abstracción. En cada nivel de integración se
construirán componentes virtuales más abstractos y complejos:
• A nivel de integración de datos los componentes virtuales proporcionarán únicamente
acceso a los datos
• A nivel de interfaz de aplicaciones permitirán reusar además la funcionalidad de las
aplicaciones existentes
• A nivel de lógica del negocio se proporcionará acceso a funcionalidades de alto nivel
• A nivel de presentación se añadirá una capa por encima haciendo que el sistema de
información integrado tenga una apariencia de un sistema desarrollado nuevamente
Los componentes virtuales implementarán las funciones reusando las aplicaciones
existentes. Si una función no puede implementarse únicamente con los sistemas
existentes se puede añadir código nuevo. De hecho, desde el punto de vista de los
clientes, los componentes virtuales no difieren de los componentes nuevos. El concepto
de componentes virtuales, por tanto nos permitirán mezclar aplicaciones existentes con
aplicaciones nuevas de muchas formas distintas.
Los componentes virtuales, junto con los interfaces abstractos de interoperabilidad
presentan una vista de la aplicación que es independiente de la implementación: si
mantenemos constante la interfaz abstracta, el resto de aplicaciones no tendrán
conocimiento de los cambios realizados sobre la aplicación original.
El sistema de información integrado estará basado en una arquitectura multi-capa, que
separa los roles del sistema y define las siguientes capas:
• Interfaz de usuario
• Lógica del negocio
• Persistencia de datos
Las aplicaciones existentes se situarán en la capa de persistencia de datos. En los tres
69
primeros niveles de integración (datos, interfaz de aplicación y métodos de lógica del

negocio) construiremos los componentes virtuales que proporcionarán las interfaces de
las aplicaciones existentes. Estos componentes virtuales se desarrollarán en la capa de
lógica del negocio.
En el nivel de integración de presentación se añadirá la nueva capa de presentación
desarrollada y se desplegará sobre la capa de interfaz de usuario. Para la comunicación
entre las capas utilizaremos la infraestructura de integración que proporciona el
intermediario de integración. En la Figura 20 se muestra esta arquitectura multi-capa.
Figura 20. Arquitectura de integración multi-capa de un sistema de información basada en

componentes
Para desarrollar los componentes virtuales (que son los bloques principales de
construcción del sistema de información basado en componentes) usaremos una técnica
denominada "envoltura" de componentes (component wrapping). Dicha técnica nos
permite implementar la funcionalidad de los componentes virtuales mediante el uso de
aplicaciones existentes.
Los componentes virtuales no presentan demasiadas dificultades para su implementación.
En particular, si las aplicaciones proporcionan ya algunos API's a través de los cuales
podemos acceder a su funcionalidad, ni siquiera necesitamos realizar cambios sobre las
aplicaciones existentes.
Si las aplicaciones no proporcionan ningún tipo de interfaces, o si dichas interfaces no
satisfacen nuestros requerimientos, entonces tendremos que desarrollarlas, o comprarlas.
Para ello tendremos que modificar las aplicaciones existentes para añadir las interfaces
necesarias. Denominaremos wrapper a la interfaz de la aplicación que vamos a añadir,
mientras que a la aplicación modificada existente la denominaremos aplicación existente
"envuelta" (wrapped).
La adición de wrappers puede realizarse de forma sencilla, especialmente en soluciones
desarrolladas en la misma empresa de las que se dispone el código fuente y
documentación asociada. Sin embargo, con aplicaciones en las que no se dispone del
70
código fuente, y la documentación es limitada, realizar cambios en la aplicación puede

resultar difícil. En este último caso, podemos considerar el acceder directamente a la base
de datos, o incluso utilizar la interfaz de usuario para acceder a la funcionalidad. Existen
técnicas como la captura de pantallas (screen scraping), en las que los wrappers acceden
a la funcionalidad de la aplicación a través de la interfaz de usuario, permitiéndonos
acceder a la información necesaria sin tener que modificar las aplicaciones.
Los wrappers proporcionan la siguiente arquitectura (ver Figura 21):
Figura 21. Componentes virtuales y wrappers

La forma en la que implementemos los wrappers dependerá de las tecnologías
seleccionadas. Normalmente usaremos el intermediario integración para obtener la
comunicación entre el componente virtual y el wrapper. La comunicación entre el wapper
y la aplicación existente usará soluciones propietarias. En ocasiones integraremos el
wrapper con la aplicación existente utilizando código fuente, comunicación entre
procesos, o captura de pantallas (para así simular la entrada de datos del usuario, y leer las
pantallas para obtener los resultados).
A continuación analizaremos los niveles de integración que deberemos seguir para
construir la arquitectura de integración:
• Integración a nivel de datos
• Integración a nivel de interfaz de la aplicación
• Integración a nivel de la lógica del negocio
• Integración a nivel de la presentación
Integración a nivel de datos. Se centra en el "movimiento" de datos entre aplicaciones
con el objetivo de compartir los mismos datos entre diferentes aplicaciones. Este nivel de
integración no requiere cambios en las aplicaciones. El problema de implementar la
integración de datos se complica por el hecho de la complejidad de las bases de datos y su
número. La integración de datos se consigue siguiendo la siguiente secuencia de pasos
(ver Figura 22):
71
Figura 22. Integración a nivel de datos

La primera tarea (identificar los datos) implica familiarizarnos con los datos existentes en
la compañía. Para ello deberemos crear modelos de datos de cada aplicación para conocer
cómo se estructuran las bases de datos. Y además deberemos comprender con detalle
cómo se gestionan estos datos por parte de la aplicación, para lo que utilizaremos los
diccionarios de datos.
La segunda tarea (identificar los tipos de bases de datos) implica familiarizarnos con la
implementación física de la base de datos. Esta normalmente pertenecer a uno de los tipos
siguientes: relacional, orientada a objetos, jerárquica. Los sistemas legacy podrían usar
otros formatos basados en estructuras propietarias de ficheros, u otras ampliamente
usadas como: ISAM, VSAM, y CODASYL.
La tercera tarea (definición del modelo de datos) consiste en obtener una representación
de alto nivel de todos los datos relevantes utilizados por la organización. El modelo
obtenido presenta los datos de la empresa de una forma consistente, centrándose en la
relación entre los datos de la empresa. Se trabajará principalmente en la eliminación de
elementos redundantes, en la detección de aplicaciones independientes con procesos
separados y en la detección de pasos innecesarios en la transferencia de datos.
Finalmente, la cuarta tarea (implementación de la integración de datos) consiste en la
implementación real de la integración de datos teniendo en cuenta las tareas anteriores.
Debemos evitar la integración punto a punto, para lo cual utilizaremos un intermediario
de integración, implementando uno o más componentes virtuales para cada base de datos
de las aplicaciones.
Integración a nivel de interfaz de la aplicación. Se centra en compartir las
funcionalidades con los datos. Se consigue mediante el uso de APIs, de forma que se
consigue acceder a las funcionalidades sin necesidad de usar la interfaz de usuario.
Representaremos la funcionalidad de las aplicaciones existentes mediante componentes
virtuales que mostrarán las operaciones de las aplicaciones existentes a través de sus
interfaces interoperables, accesibles a a través de intermediario de integración (ocultando
las diferencias de tecnología).
Afortunadamente la integración a nivel de interfaz no requiere que las aplicaciones
existentes dispongan de APIs implementados, ya que podemos utilizar wrappers. Dichos
wrappers se añadirán mediante la modificación de código fuente de las aplicaciones
existentes, o bien accediendo a la funcionalidad de dichas aplicaciones mediante la
simulación de la interacción con el usuario.
Los pasos a seguir en este nivel son los siguientes (ver Figura 23).
72
Figura 23. Integración a nivel de interfaz

En primer lugar debemos analizar las funcionalidades existentes a través de interfaces, lo
cual nos responderá a la cuestión de si las aplicaciones existentes proporcionan las
interfaces requeridas y si estas interfaces son adecuadas para acceder a las
funcionalidades que se requieren. Si la respuesta es positiva, continuaremos con el
análisis de las tecnologías usadas. Si es negativa deberemos añadir las interfaces que sean
necesarias.
En el pasado, las interfaces se implementaban con tecnologías propietarias, pero hoy en
día han surgido diferentes estándares que pueden ser utilizados. Las interfaces pueden
proporcionar formas de comunicación síncrona o asíncrona, y las aplicaciones que usan
interfaces estadarizadas utilizan a menudo middleware para proporcionar esta
comunicación. Posibles soluciones middleware que resultan apropiadas para implementar
la interfaz de las aplicaciones incluyen: MOM, RPCs, ORBs, protocolos de comunicación
(SOAP, HTTP, TCP/IP).
El último paso en este nivel es el ocultar las diferencias de tecnologías utilizadas. Esto se
consigue mediante el uso de componentes virtuales: una vez que se han identificado las
operaciones de las aplicaciones existentes a las que necesitamos acceder mediante APIs,
definimos las mismas (o ligeramente modificadas) interfaces para los componentes
virtuales; a continuación usaremos la tecnología del intermediario de integración para
conseguir la interoperabilidad, simplemente delegando las peticiones desde el
componente virtual a las interfaces específicas de las aplicaciones existentes.
Integración a nivel de la lógica del negocio. El objetivo es desarrollar componentes
virtuales que proporcionen las interfaces con los métodos de la lógica del negocio de alto
nivel que puedan considerarse como servicios de la empresa. De esta forma se consigue
una integración consistente en compartir la lógica del negocio entre las aplicaciones.
Para conseguir el integración a nivel de la lógica del negocio, en general, necesitaremos
introducir varios niveles de componentes virtuales. De esta forma, un componente virtual
de un método de lógica del negocio realizará varias llamadas a componentes de interfaces
de más bajo nivel para realizar completar su tarea. Los pasos a seguir se muestran en la
Figura 24.
73
Figura 24. Integración a nivel de lógica de negocio

Para definir los interfaces de algo nivel se requiere un esfuerzo coordinado de los
analistas, diseñadores y arquitectos. En términos simples, de lo que se trata es de definir
un diseño global del sistema de información tal y como quisiéramos obtener si
implementáramos el sistema de nuevo. No es una tarea fácil y requiere un gran
conocimiento y esfuerzo. Sin embargo, si no podemos definir dicho diseño, significa que
realmente no podemos fijar los requerimientos fundamentales, metas y objetivos. Esto
hará que el proyecto de integración probablemente falle incluso antes de que haya
comenzado.
El segundo paso consiste en realizar una correspondencia entre las operaciones de
negocio y los componentes virtuales que representan las aplicaciones existentes,
intentando reusar las funcionalidades de las aplicaciones existentes en la medida de lo
posible. La correspondencia a establecer deberá definir las transformaciones necesarias
que deber realizarse entre las llamadas a componentes virtuales de bajo nivel, y otras
restricciones como temporales y de sintaxis.
Finalmente se deben implementar los componentes virtuales de alto nivel. Es importante
tener en cuenta que los componentes virtuales de alto nivel desarrollados utilizarán
componentes virtuales de bajo nivel implementados en los niveles de interfaz y datos.
Integración a nivel de la presentación. Hasta ahora hemos conseguido compartir la
lógica del negocio, pero las aplicaciones existentes seguirán usándose de la misma forma
que antes. Esto significa que el usuario es completamente consciente de que se usan
aplicaciones existentes distintas y que requiere un cambio manual entre ellas. La
integración a nivel de presentación resuelve estos problemas. Se trata de definir una
interfaz de usuario común para el sistema de información integrado a nivel de métodos de
negocio. La secuencia de actividades a realizar es la siguiente (ver Figura 25)
Figura 25. Integración a nivel de presentación

Primero debemos seleccionar qué interfaces de usuario necesita el sistema de información
integrado. Deberemos ser prácticos y seleccionar primero aquellas parte que tienen mayor
necesidad de interfaces de usuario.
La actividad de mayor envergadura a nivel de presentación es el análisis y diseño de un
interfaz de usuario unificado para el sistema de información integrado. Dicho sistema
74
debe aparecer ante los usuarios finales como una aplicación desarrollada completamente
nueva, de forma que los usuarios no deben ser capaces de reconocer que las aplicaciones
existentes están siendo usadas "por debajo", y no deben tener contacto directo con dichas
aplicaciones, que ahora sirven como componentes virtuales en la capa media.
A continuación debemos establecer la correspondencia entre las operaciones de interfaz
de usuario con los métodos del negocio de la capa de lógica del negocio.
Finalmente tenemos que implementar la nueva capa de presentación. Podemos utilizar
diferentes aproximaciones, entre ellas: clientes con interfaces gráficas, clientes web o
clientes "thin", o clientes universales para diferentes tipos de tecnologías cliente (basados
en web, o móviles entre otras).
Una implementación exitosa de la capa de integración de presentación resulta en una
arquitectura multi-capa tal y como se muestra en la Figura 26.
Figura 26. Arquitectura de integración

Los principales beneficios de la integración a nivel de presentación son: proceso
unificado del negocio, integración de toda la aplicación, interfaz de usuario unificado,
sistemas interconectados física y lógicamente, información accesible completamente sin
latencia, entradas de datos únicas.
75
4. Arquitectura orientada a servicios (SOA)
Muchas empresas han dedicado grandes inversiones en los recursos de sus sistemas
software a lo largo de los años. Dichas empresas tienen una enorme cantidad de datos
almacenados en sistemas de información (EIS) legacy, de forma que no resulta práctico
descartar dichos sistemas existentes. Es mucho más efectivo evolucionar y mejorar los
EIS. ¿Pero cómo hacer ésto? La arquitectura orientada a servicios (Service Oriented
Architecture) proporciona una solución con unos costes aceptables. Si bien la arquitectura
a servicios no es nueva, se está convirtiendo en el principal framework para la integración
de entornos heterogéneos y complejos. En esta charla, explicaremos con detalle qué es la
arquitectura orientada a servicios.
4.1. Razones para introducir SOA
El software de empresa está estrechamente relacionado con su organización interna, con

los procesos que la forman, y con el modelo de negocio de dicha empresa. El software de
empresa está condicionado tanto por las dependencias entre sus departamentos, como por
las relaciones con negocios externos. Consecuentemente, una arquitectura para software
de empresas debe contemplar un gran número de requerimientos diferentes. Muchos de
estos requerimientos entran en conflicto, mientras que otros no están claros. En casi todos
los casos, los requerimientos cambian constantemente debido al cambio permanente de
los mercados, cambios en la organización de la empresa, así como en sus objetivos de
negocio. Esta implicación en todos los aspectos de la empresa y del negocio es lo que
hace que el software de empresa sea altamente complejo. Como dice Dirk Krafzig: "El
software de empresa es un animal diferente". El software de empresa es único en muchos
aspectos, y por lo tanto, requiere medidas únicas para asegurar la eficiencia de su
desarrollo y mantenimiento.
En el software de empresa, el arquitecto adquiere el rol de un influenciador y controlador
externo. Tiene la responsabilidad de dirigir proyectos software individuales tanto desde el
punto de vista estratégico de la organización en su totalidad, como desde el punto de vista
táctico (punto de vista de la meta a alcanzar con el proyecto individual). Tiene que
equilibrar diferentes requerimientos a la vez que intentar crear un orden perdurable dentro
del ámbito del software de empresa. La arquitectura del software de empresa es una de las
herramientas más importantes con las que cuenta el arquitecto. Éste tiene que enfrentarse
constantemente con cambios y adiciones de funcionalidades que incrementan la
complejidad del sistema y reducen su eficiencia. Mediante la refactorización de las
soluciones actuales, los arquitectos luchan para intentar reducir la complejidad e
incrementar la agilidad del sistema.
Para mejorar la eficiencia y agilidad del sistema, una arquitectura de software de empresa
debe proporcionar las siguientes características:
• Simplicidad: A pesar de la cantidad de gente implicada, todos deben ser capaces de
76
comprender y gestionar la arquitectura en sus niveles respectivos (por ejemplo,

especificar nuevas funcionalidades a nivel de negocio, implementarlas y mantenerlas).
• Flexibilidad y mantenibilidad: La arquitectura debe definir diferentes componentes
que puedan reordenarse y reconfigurarse de una forma flexible. No se debe permitir
que cambios locales tengan un efecto sobre el sistema global.
• Reusabilidad: Uno de los aspectos más importantes de la reusabilidad es el de
compartir datos en tiempo real, así como el compartir funcionalidades comunes.
• Desacoplamiento entre funcionalidad y tecnología: La arquitectura debe hacer que
la organización de la empresa sea independiente de la tecnología. En particular, la
arquitectura debería evitar dependencias de productos y vendedores específicos.
Una arquitectura orientada a servicios posee las características que acabamos de
comentar.
La meta última de la reusabilidad y flexibilidad proporcionada por una arquitectura
orientada a servicios es el de conseguir una empresa ágil, en la que todos los procesos y
servicios son completamente flexibles y pueden crearse, configurarse y reordenarse
rápidamente cuando así sea requerido por los expertos en el negocio, sin la necesidad de
personal técnico. Entre otras cosas, se facilita el dedicar más tiempo al mercado para
conseguir nuevas iniciativas de negocio. Esta visión de una empresa ágil reconcilia la
demanda cada vez más creciente de entornos de negocio rápidamente cambiantes, con las
limitaciones de las teconologías e infraestructuras organizacionales actuales. Otras
ventajas que se derivan de la agilidad de la empresa son el ahorro de costes,
independencia de la tecnología, un proceso de desarrollo más eficiente, y mitigación de
riesgos.
4.2. El concepto de servicio
El término "servicio" se ha venido utilizando desde hace bastante tiempo y de muchas

formas diferentes. Hoy, por ejemplo, encontramos grandes compañías, como por ejemplo
IBM, que promocionan el concepto de "servicios bajo demanda". Con la llegada del siglo
21, el término "servicios Web" se ha convertido extremadamente popular, si bien ha sido
utilizado a menudo para hacer referencia a diferentes conceptos de computación. Por
ejemplo, algunos lo utilizan para refererirse a servicios de aplicaciones que se ofrecen a
los usuarios a través de la Web, como la aplicación salesforce.com. Otros utilizan el
término "servicios Web" como módulos de aplicaciones que son accesibles para otras
aplicaciones a través de Internet, mediante protocolos basados en XML. Hay que decir
que servicios Web y SOA NO son equivalentes, sin embargo, como veremos más
adelante, se pueden utilizar servicios Web para implementar una arquitectura SOA.
Para nosotros, el término servicio hará referencia a alguna actividad significativa que un
programa de ordenador realiza o solicita a otro programa de ordenador. O, en términos
más técnicos, un servicio es un módulo de aplicación autocontenido que es
remotamente accesible. Los frontends de las aplicaciones proporcionan accesibilidad a
los servicios. A veces, los términos "cliente" y "servidor" se utilizan como sinónimos de
77
"consumidor de un servicio" y "proveedor de un servicio", respectivamente.

Ademas, los servicios proporcionan un nivel de abstracción que oculta muchos detalles
técnicos, incluyendo la localización y búsqueda del servicio. Típicamente, los servicios
proporcionan funcionalidad de negocio, en lugar de funcionalidades técnicas. Otra
característica de los servicios es que no se diseñan para un cliente específico, en su lugar
constituyen una facilidad que contribuye a satisfacer alguna demanda pública. Es decir,
proporcionan una funcionalidad que puede reutilizarse en diferentes aplicaciones. La
"rentabilidad" del servicio dependerá del número de clientes diferentes que utilicen el
servicio, o lo que es lo mismo, del nivel de reutilización conseguido.
Una implementación concreta de una arquitectura de servicios proporciona un acceso
uniforme para todos los servicios disponibles. Así, si hacemos una analogía con la
telefonía, después de que un consumidor de un servicio es "dirigido" hasta una instancia
de una arquitectura de servcios, y, después de que "suene el tono de llamada", el uso de
los servicios es transparente para los usuarios. Sin embargo, y como luego veremos, una
arquitectura de servicios es una arquitectura en sí misma, y por lo tanto, únicamente
describe la estructura y no las tecnologías concretas. Consecuentemente, las instancias de
SOA podrían utilizar diferentes tecnologías en diferentes empresas.
Destacar también que los principios en los que se basa SOA son significativamente
diferentes de los principios y paradigmas orientados a objetos. La diferencia clave está en
que las interacciones entre los servicios se definen utilizando interfaces que están más
orientadas hacia los datos que al comportamiento. Un servicio aislado puede ser
implementado utilizando principios y técnicas orientadas a objetos, sin embargo, las
interacciones entre estas interfaces se orientan más hacia intercambios basados en
documentos. Mientras que la orientación a objetos mantiene el comportamiento "cerca"
de los datos (un objeto encapsula datos y comportamiento), la orientación a servicios
desacopla los datos del comportamiento. Pongamos un ejemplo sencillo: imaginemos un
CD que queremos escuchar. Para poder oirlo necesitamos introducir el CD en un
reproductor de CD y dicho reproductor realiza la tarea de reproducción. El reproductor de
CD ofrece un servicio de reproducción de CDs. Ésto resulta muy útil ya que podemos
reemplazar un reproductor de CD por otro: podemos ejecutar el mismo CD sobre un
reproductor portátil o sobre un sofisticado equipo estéreo. Ambos aparatos ofrecen el
mismo servicio, pero la calidad del mismo es diferente. Ahora consideremos el mismo
ejemplo según la perspectiva orientada a objetos: en un estilo de programación orientado
a objetos, cada CD debería contener su propio reproductor de forma no separada. Esto
suena raro, pero esta es la forma en la que están construidos muchos sistemas software
actuales.
El resultado de un servicio lleva consigo normalmente un cambio de estado para el
proveedor, o para el cliente, o para ambos. Siguiendo con el ejemplo anterior, después de
escuchar el CD en el reproductor, nuestro humor habrá cambiado, por ejemplo, de "triste"
a "animado".
78
4.3. Definición de SOA. Elementos que la componen.
Una arquitectura orientada a servicios es una arquitectura que permite la construcción

de aplicaciones de negocio como un conjunto de componentes de caja negra (black-box)
débilmente acoplados, que son orquestados para entregar un nivel de servicio bien
definido enlazando conjuntamente diversos procesos de negocio.
De la definición anterior, se desprende que SOA es una aproximación extensible,
reutilizable y sostenible para los negocios y la tecnología, que proporciona una gran
ventaja competitiva a las organizaciones que la adoptan. Resaltamos las siguientes
observaciones:
• SOA está dirigida a aplicaciones de negocio. Existen muchas aproximaciones
legítimas para las arquitecturas software, y SOA no está pensada para cualquier tipo
de software. SOA está pensada para aplicaciones de negocio.
• SOA es una arquitectura de componentes black-box. Siempre que sea posible,
SOA oculta de forma deliberada la complejidad subyacente, y la idea de caja negra es
inherente a SOA. El concepto de caja negra permite la reutilización de aplicaciones de
negocio añadiendo simplemente un adaptador, sin importar cómo se hayan construido
dichas aplicaciones. Los adaptadores son los que proporcionan las interfaces y hacen
que SOA sea posible. Sin adaptadores no hay SOA. SOA está pensada, sobre todo,
para reutilizar las aplicaciones de negocio existentes. Para hacer esto, necesitamos
añadir interfaces a estas aplicaciones que nos permitan invocar directamente a las
funciones que dichas aplicaciones contienen. Los adaptadores SOA proporcionan
dichos interfaces.
• Los componente SOA son débilmente acoplados. El término "débilmente acoplado"
hace referencia a la forma en la que interactúan los componentes en SOA. Un
componente pasa datos a otro componente y realiza una petición. El segundo
componente envía una respuesta y, si es necesario, envía datos de vuelta al
componente que solicitó la petición. Se hace énfasis en la simplicidad y la autonomía.
Cada componente ofrece un pequeño conjunto de servicios simples a otros
componentes. Un conjunto de componentes débilmente acoplados hacen el mismo
trabajo que si fuesen usados en aplicaciones con mucho acoplamiento, pero los
componentes pueden combinarse y recombinarse de mútiples formas. Esto hace que la
totalidad de la estructura sea mucho más flexible. También resulta mucho más
sencillo crear lo que denominamos "aplicaciones compuestas" (composite
applications), que son nuevas aplicaciones creadas a partir de las funciones de
negocio de las aplicaciones existentes, y añadiendo, quizá, algún componente nuevo.
• Los componentes software son orquestados de forma que enlazan varios procesos
de negocio para entregar un nivel de servicio bien definido. SOA crea una alineación
simple de componentes que pueden, de forma colectiva, entregar un servicio de
negocio muy complejo. Además, la arquitectura incluye componentes que aseguran
un nivel de servicio confiable. Ejemplos de niveles de servicio pueden ser: la
aplicación debe estar disponible el 99,99% del tiempo cada fin de semana desde las 6
79
a.m hasta las 10 p.m; en caso de un error, la aplicación debe recuperarse en 20

minutos; el tiempo de respuesta para consultas, modificaciones y creación de nuevos
pedidos será de 1 segundo, y nunca peor que dos segundos, etc.
Una arquitectura orientada a servicios está basada en cuatro elementos clave: frontend de
la aplicación, servicio, repositorio y bus de servicios (ver Figura 1).
Figura 1. Elementos que componen SOA.

Si bien el frontend de la aplicación es el propietario del proceso del negocio, los servicios
proporcionan la funcionalidad del negocio que los frontends de las aplicaciones y otros
servicios pueden utilizar.
Un servicio consiste en: (a) una implementación que proporciona lógica del negocio y
datos, (b) un contrato del servicio que especifica la funcionalidad, uso, y restricciones
para el cliente (que puede ser un frontend de una aplicación u otro servicio), y (c) una
interfaz del servicio que físicamente expone la funcionalidad.
El repositorio de servicios almacena los contratos del servicio de los servicios
individuales de una SOA, y el bus de servicios interconecta los frontends de las
aplicaciones y los servicios.
Elementos claves de una SOA

Una arquitectura orientada a servicios (SOA) es una arquitectura software basada en los
conceptos clave de frontend de aplicaciones, servicio, repositorio de servicios, y bus de servicios.
Un servicio está formado por un contrato, una o más interfaces y una implementación. Los
bloques de construcción de SOA son los servicios, los cuales están débilmente acoplados para
favorecer su reutilización y son altamente interoperables a través de sus contratos. Los servicios
en sí mismos son "ajenos" a las interacciones requeridas a nivel de transporte para hacer posible
la comunicación entre el suministrador del servicio y el consumidor del servicio.
El concepto de una SOA se centra en la definición de una infraestructura de negocio.

Cuando utilizamos el término "servicio" tenemos en mente un servicio de negocio tal
como realizar una reserva de un vuelo, o acceder a una base de datos de clientes de una
compañía. Estos servicios proporcionan operaciones de negocio tales como hacer una
reserva, cancelar un billete, u obtener el perfil de un usuario. A diferencia de los
servicios de negocio, los servicios de infraestructura técnica, tales como un servicio de
80
persistencia o de transacciones, proporcionan operaciones tales como inicio de

transacción, actualización de datos, o abrir cursor. Si bien este tipo de funcionalidad
técnica es bastante útil cuando vamos a implementar una operación de negocio, tiene poca
relevancia estratégica desde el punto de vista de SOA. De forma más general, la
tecnología no debe tener ningún impacto sobre la estructura de alto nivel de la aplicación,
ni debe provocar dependencias entre componentes. Realmente, la arquitectura orientada a
servicios debe desacoplar las aplicaciones de negocio de los servicios técnicos y hacer
que la empresa sea independiente de la implementación o infraestructura técnica
específica.
Vamos a comentar con más detalle los elementos que componen la arquitectura SOA.
FRONTENDS de las aplicaciones
Los frontends de las aplicaciones son los elementos activos de la arquitectura SOA. Éstos
inician y controlan todas las actividades de los sistemas corporativos. Hay diferentes tipos
de frontends. Un frontend de una aplicación puede presentar una interfaz gráfica de
usuario, como por ejemplo una aplicación Web o un cliente rico que interactúa
directamente con los usuarios finales. Los frontends no tienen que interactuar
necesariamente de forma directa con los usuarios finales. Los programas por lotes o los
procesos de larga duración que invocan a las funcionalidades de forma periódica o como
resultado de eventos específicos son también ejemplos válidos de frontends.
En última instancia, siempre es un frontend de una aplicación quién inicia un proceso de
negocio y recibe los resultados. Los frontends de aplicaciones son similares a las capas de
nivel más alto en las arquitecturas multi-capa tradicionales.
SERVICIOS
Un servicio es un componente software con un significado funcional que lo distingue de
otros, y que típicamente encapsula un concepto de negocio de alto nivel. La Figura 2
muestra los elementos que forman parte de un servicio.
Figura 2. Elementos que componen un servicio SOA.
81
El contrato del servicio proporciona una especificación informal sobre el propósito,

funcionalidad, restricciones, y uso del servicio. La forma de dicha especificación puede
variar dependiendo del tipo de servicio. La definición formal de la interfaz basada en
lenguajes tales como IDL y WSDL no es obligatoria. Si bien añade un beneficio
significativo: proporciona una abstracción e independencia de la tecnología, incluyendo el
lenguaje de programación, protocolo de red y entorno de ejecución. Es importante
comprender que un contrato de un servicio proporciona más información que una
especificación formal. El contrato puede imponer una determinada semántica sobre la
funcionalidad o el uso de parámetros que no están sujetos a especificaciones IDL o
WSDL. En realidad, muchos proyectos deben tratar con servicios que no pueden
proporcionar una descripción formal de las interfaces de dichos servicios. No debemos
olvidar que la tarea clave en un proyecto que pretende introducir SOA a nivel de empresa
es, a menudo, no implementar nuevas funcionalidades, sino identificar módulos existentes
de aplicaciones y componentes y "envolverlos" con interfaces con el nivel adecuado de
funcionalidad y granularidad, haciendo que éstos estén disponibles en forma de servicios
fácilmente utilizables y mejor documentados. En los casos en los que no se disponga de
una descripción formal de los servicios en forma de interfaces, el servicio puede
proporcionar acceso a librerías, o bien una descripción técnica detallada a nivel de
protocolo de red.
La interfaz expone la funcionalidad del servicio a los clientes que están conectados a
dicho servicio a través de la red. Si bien la descripción de la interfaz forma parte del
contrato del servicio, la implementación física de la misma consiste en unos stubs de
servicio, que se incorporan en los clientes de un servicio.
La implementación del servicio proporciona la lógica del proceso así como los datos
requeridos. Es la realización técnica que satisface el contrato del servicio. La
implementación del servicio consiste en uno o más artefactos tales como programas,
datos de configuración y bases de datos.
REPOSITORIO de servicios
El repositorio de servicios proporciona facilidades para encontrar servicios y adquirir toda
la información para utilizar los servicios, particularmente si estos servicios tienen que
buscarse fuera del ámbito funcional y temporal del proyecto que los creó. Si bien mucha
de la información requerida forma parte del contrato del servicio, el repositorio de
servicio puede proporcionar información adicional, tal como la localización física,
información sobre el proveedor, personas de contacto, tasas de uso, restricciones técnicas,
cuestiones sobre seguridad, y niveles de servicio disponibles.
Vamos a considerar repositorios de servicios utilizados principalmente dentro de los
límites de una única empresa. Los repositorios que se utilizan para integración de
servicios entre empresas típicamente tienen diferentes requerimientos. En particular,
aquellos repositorios públicos a través de Internet pueden requerir cuestiones legales
(términos y condiciones de uso), estilo de presentación, niveles de seguridad, registro de
82
usuarios, suscripción a servicios, tarifas de uso, y versión utilizada).

Obviamente, un repositorio de servicios es un elemento muy útil de una SOA. Si bien no
es indispensable disponer de un repositorio de servicios, éste resultará indispensable a
largo plazo. Una arquitectura puede evitar el uso de un repositorio si el ámbito de un
servicio es justamente un proyecto, si tiene muy pocos servicios, o si todos los proyectos
son llevados a cabo por el mismo equipo de personas. En un escenario real, la mayoría de
las veces habrá múltiples proyectos concurrentes, grupos de trabajo cambiantes, y una
gran variedad de servicios.
Un repositorio de servicios puede ser arbitrariamente simple: en un extremo, podríamos
no requerir usar ninguna tecnología. Un lote de contratos de servicio impresos localizados
en una oficina y accesible por todos los proyectos es un repositorio de servicios válido.
Sin embargo, hay mejores formas de proporcionar esta información, manteniendo la
simplicidad del repositorio, como por ejemplo utilizar alguna base de datos propietaria
que contenga datos administrativos y contratos de servicios más o menos formales para
cada versión de un servicio.
En algunos casos, algunas compañías han desarrollado sus propias herramientas que
automáticamente generan la descripción del servicio a partir de las definiciones formales
de los servicios (por ejemplo un generador de HTML que toma un WSDL como entrada,
similar al generador JavaDoc). Esto resulta particularmente útil si la definición formal del
servicio se anota con información adicional sobre el servicio.
Es importante distinguir entre enlazado de servicios (binding of services) en tiempo de
desarrollo y en tiempo de ejecución. El binding (utilizaremos los términos binding o
enlazado indistintamente) hace referencia a la forma en la que las definiciones de los
servicios y las instancias de los servicios son encontradas, incorporadas en la aplicación
del cliente, y finalmente enlazadas a nivel de red.
Vamos a explicar un poco más el concepto de enlazado. Una forma sencilla de entenderlo
es pensar en él en términos humanos. Cuando necesitamos hacer una llamada de teléfono
a alguien, descolgamos el teléfono, marcamos el número, y esperamos mientras el
teléfono suena. La persona a la que estamos llamando puede no descolgar
inmediatamente, pero suponiendo que lo haga, comenzaremos formulando algún saludo,
indicaremos quienes somos y por qué estamos llamando, y después de todo esto,
pasaremos al asunto central de nuestra llamada.
Bien, cuando un adaptador de un componente software (recordemos que un adaptador
proporciona la interfaz del componente) quiere establecer una conversación con otro,
ocurren el mismo tipo de cosas que con las llamadas de teléfono. A este proceso se le
denomina binding o enlazado, y quien establece la conexión es el broker del servicio (o
intermediario del servicio).
Volviendo con el binding de servicios, si los servicios son encontrados y enlazados en
tiempo de desarrollo, las signaturas de las operaciones del servicio son conocidas con
antelación, así como el protocolo de servicio y su localización física (o al menos el
83
nombre exacto del servicio en un servicio de directorios). La Figura 3 describe un proceso

en el que los servicios se encuentran en tiempo de desarrollo. En este caso, el
desarrollador es responsable de localizar toda la información requerida en el repositorio
de servicios para crear un cliente que interactúe correctamente con la instancia del
servicio.
Figura 3. Descubrimiento de servicios en tiempo de desarrollo.

Si bien el enlazado en tiempo de desarrollo es un modelo bastante simple, es suficiente la
mayoría de las veces. Permite a los proyectos identificar la funcionalidad que ha sido
creada por proyectos anteriores y reutilizar sus servicios.
El enlazado en tiempo de ejecución es mucho más complejo. Podemos diferenciar entre
varios niveles de enlazado:
• Búsqueda del servicio por nombre. Este es el caso más sencillo, y el usado más
comúnmente. La definición del servicio se conoce en tiempo de desarrollo, y la lógica
del cliente se desarrolla en consecuencia. El cliente puede enlazar de forma dinámica
con diferentes instancias de un servicio buscandolas con nombres específicos dentro
de un directorio. Por ejemplo, una aplicación cliente busca servicios de impresión con
diferentes nombres, dependiendo del nombre de impresora seleccionado por el
usuario.
• Búsqueda del servicio por propiedades. Es similar al anterior, excepto que los
servicios se encuentran por propiedades. Por ejemplo, un servicio de impresión puede
buscar en el repositorio impresoras a través de propiedades como la planta en la que
se encuentran (p.ej. "planta ==2") y el tipo de documentos que es capaz de imprimir
(p.ej. "doctype==PostScript").
• Búsqueda del servicio basada en reflection. En este caso, la especificación real del
servicio no se conoce en tiempo de desarrollo. Supongamos que un cliente encuentra
un servicio con las propiedades del ejemplo anterior, pero con una interfaz del
servicio desconocida. En este caso, en el cliente se debe implementar algún
mecanismo de reflection, que permita al cliente descubrir de forma dinámica la
semántica del servicio y el formato de peticiones válidas. Este tipo de enlazado es
bastante poco usual y limitado a algunos pocos dominios de aplicaciones. Un ejemplo
84
de un dominio que realmente requiere un enlazado de servicios altamente dinámico es

una aplicación Bluetooth: los clientes Bluetooth descubren los servicios de forma
dinámica basándose en la localización y otras propiedades. Pero de nuevo, incluso en
este escenario, los clientes Bluetooth soportan un conjunto limitado de servicios
predefinidos.
En general, es recomendable tener un enlazado de servicios lo más simple posible debido
a que el nivel de complejidad y riesgo crece exponencialmente con el nivel de dinamismo
resultante. La búsqueda de servicios por nombre con interfaces de servicio predefinidas
suele ser la opción que mejor equilibra las necesidades de flexibilidad y complejidad de
implementación en la mayor parte de los casos.
BUS de servicios (ESB)
Un bus de servicios (ESB: Enterprise Service Bus) conecta a todos los participantes de
una SOA (tanto servicios como frontends). El bus de servicios es similar al concepto de
bus software definido en el contexto de CORBA. Aunque existen diferencias
significativas, entre ellas la más importante es que el bus de servicios no necesariamente
debe estar formado por una única tecnología, sino que puede comprender varios
productos y conceptos.
El bus de servicios es el nervio central de las comunicaciones entre los servicios de una
SOA. Los ESBs se diseñan para ser versátiles. Los ESBs pueden conectar con varios tipos
de middleware, repositorios de definiciones de metadatos (como por ejemplo cómo
podemos definir un número de cliente), registros (para indicar cómo localizar la
información), e interfaces de cualquier cosa. Un ESB tiene no solamente tien el rol de
transportador de mensajes. Las principales características de un bus de servicios son:
• Conectividad: el objetivo principal de un bus de servicios es del de interconectar a
los participantes de una SOA. Por lo tanto debe proporcionar facilidades para permitir
a los participantes de una SOA invocar las funcionalidades de los servicios.
• Heterogeneidad de tecnología: puesto que la realidad de las empresas se caracteriza
por tecnologías heterogéneas, el bus de servicios debe ser capaz de conectar
participantes basados en diferentes lenguajes de programación, sistemas operativos o
soporte de ejecución. Además, normalmente encontraremos muchos productos
middleware y protocolos de comunicación en la empresa, todos las cuales deben ser
soportados por el bus de servicios.
• Heterogeneidad de conceptos de comunicación: es similiar a lo expuesto
anteriormente pero aplicado a las comunicaciones. Obviamente, el bus de servicios
debe permitir comunicaciones síncronas y asíncronas.
• Servicios técnicos: si bien el propósito del bus de servicios es fundamentalmente la
comunicación, también debe proporcionar servicios técnicos tales como logging,
auditorías, seguridad, transformación de mensajes o transacciones.
Podemos construir una SOA sin un ESB, pero a medida que el sistema crece y se vuelve
más complejo, necesitaremos un ESB
85
4.4. Características de los servicios de una SOA
Los servicios son el corazón de una arquitectura SOA y deben ser: débilmente acoplados,
de grano grueso (coarse-grained: implementan funcionalidades de alto nivel), centrados
en el negocio y reutilizables.
Un servicio "bien escrito" es de grano grueso, lo que significa que hace referencia a que
tiene un alto nivel de abstracción, y por lo tanto, su ámbito es lo suficientemente amplio
como para que la gente implicada en el negocio pueda comprender el propósito del
servicio incluso si tienen pocos conocimientos sobre software. Según la cantidad de
colecciones de procedimientos de negocio que maneje una compañía, en la misma
proporción los analistas del negocio y los profesionales del software de dicha compañia
podrán compartir el conocimiento de la información de forma provechosa para ambos.
Además, pueden incluir al cliente en sus las deliberaciones tempranas sobre el alcance de
cada servicio, así como pueden comprender todas las implicaciones de la realización de
cambios sobre un procedimiento de negocio. La facilidad de comunicaciones entre las
personas es un beneficio importante de SOA y sugiere que la arquitectura se conviertirá
en el principio de organización primaria para los procesos de negocio.
Por otro lado, los servicios bien diseñados son reutilizables. Las organizaciones se
benefician de la reusabilidad de dos formas al menos: primero, evitando el gasto asociado
al desarrollo de un nuevo software, y segundo, incrementando la fiabilidad del software
existente a lo largo del tiempo. Las compañías pueden realizar unas pruebas menos
extensivas si utiliza un servicio existente en una nueva aplicación, en comparación con las
pruebas necesarias requeridas para desplegar software que ha sido escrito desde cero.
A continuación discutiremos con más detalle la característica de bajo acoplamiento. El
término acoplamiento hace referencia al grado en el que los componentes software
dependen unos de otros. El acoplamiento puede tener lugar a diferentes niveles. Los
procesos de negocio requieren un alto nivel de flexibilidad, y por lo tanto una arquitectura
con un bajo acoplamiento para así poder reducir la complejidad total y las dependencias,
y en consecuencia facilitar cambios más rápidos y con menores riesgos. En la siguiente
tabla mostramos las diferencias fundamentales entre acoplamiento débil (loose coupling)
y fuerte (tight coupling), considerando diferentes niveles.
Nivel Tight coupling Loose coupling
Acoplamiento físico Requiere conexión física Utiliza un intermediario físico

directa
Estilo de comunicación Síncrono Asíncrono
Sistema de tipos Interfaz explícita con nombres Formato de mensajes flexible

de operaciones y argumentos
fuertemente tipados
Patrón de interacción Navegación a través de Centrado en los datos,

complejos árboles de objetos mensajes autocontenidos
86
Control de la lógica del proceso Centralizado Componentes distribuidos

lógicamente
Descubrimento y enlazado de Estático Dinámico

servicios
Dependencia de la plataforma Dependencia fuerte del sistema Independencia del sistema

operativo y lenguaje de operativo y lenguaje de
programación programación
Como ya hemos comentado, una composite application es una aplicación compuesta a

partir de servicios autónomos. Incluso si cada uno de dichos servicios ha sido construido
y usado en aplicaciones anteriores que no tienen nada que ver unas con otras, éstos
pueden combinarse si hay alguna razón para ello. Si estos servicios componentes pueden
utilizarse fácilmente tanto conjuntamente como separados, entonces se dice que están
débilmente acoplados.
Un aspecto importante sobre el acoplamiento débil es que los servicios componentes y las
instrucciones básicas utilizadas para indicar cómo las "piezas" interactúan entre ellas, son
separados de forma deliberada para que el servicio no contenga código relacionado con el
manejo del entorno de computación. Debido a esta separación, los componentes pueden
enlazarse dinámicamente en tiempo real y se comportarán como si formaran parte de una
única aplicación fuertemente acoplada.
El bajo acoplamiento es posible conseguirlo debido al soporte que proporcionan varios
componentes SOA, como por ejemplo el bus de servicios, el repositorio SOA, el registro
SOA, y las interfaces tales como XML, SOAP, y WSDL.
Un bajo acoplamiento nos permitirá ganar en rapidez y eficiencia en varios aspectos. A
continuación nombramos algunos beneficios significativos derivados de un bajo
acoplamiento:
• Crear nuevas aplicaciones rápidamente utilizando servicios existentes.
• Reemplazar un servicio por otro sin tener que reescribir toda la aplicación.
• Crear aplicaciones de negocios seguras rápidamente.
• Aislar fácilmente los problemas
• Convertir los servicios software en un beneficio económico, al ofrecer su uso, previo
pago, a otras organizaciones.
4.5. Capas en aplicaciones orientadas a servicios
Al igual que en cualquier aplicación distribuida, las aplicaciones orientadas a servicios

son aplicaciones multicapa y tienen capas de presentación, lógica de negocio y
persistencia. La Figura 4 muestra una arquitectura típica de una aplicación orientada a
servicios.
87
Figura 4. Capas en aplicaciones orientadas a servicios.

Las dos capas clave en una aplicación orientada a servicios son la de servicios y la de la
lógica de negocio.
Capa de servicios
Como ya hemos dicho, los servicios son los bloques de construcción de las aplicaciones
orientadas a servicios. Los servicios son auto-contenidos, mantienen su propio estado, y
proporcionan una interfaz con bajo acoplamiento.
El mayor reto cuando construimos una aplicación orientada a servicios es crear una
interfaz con el nivel adecuado de abstracción. Cuando analizamos los requerimientos del
negocio, tenemos que considerar cuidadosamente qué componentes software queremos
construir como servicios. Generalmente, los servicios deberían proporcionar una
funcionalidad con un alto nivel de abstracción (coarse-grained). Por ejemplo, un
componente software que procesa una orden de compra es un buen candidato para ser
publicado como un servicio, en contraposición con un componente que solamente
actualiza un atributo de una orden de compra.
Tenemos dos posibilidades a la hora de construir un servicio: la aproximación top-down o
bottom-up. La aproximación top-down requiere que identifiquemos y describamos los
mensajes y las operaciones que proporciona nuestro servicio y a continuación
implementemos dicho servicio. Esta aproximación es recomendable cuando estamos
construyendo un servicio completamente nuevo, puesto que somos totalmente libres de
elegir la tecnología de implementación que prefiramos. Esta aproximación también
promueve servicios más interoperables, ya que podemos evitar artefactos de
implementación que imposibiliten la interoperabilidad (por ejemplo, tipos de datos que
pueden tener una representación interoperable).
La aproximación bottom-up es bastante popular debido a que nos permite reutilizar la
inversión realizada en los componentes de negocio. Por ejemplo, los vendedores
proporcionan las herramientas que nos permiten exponer como un servicio
88
procedimientos almacenados PL/SQL que comprueban si a un cliente se le puede aplicar

un descuento.
El aspecto más importante de un servicio es su descripción. Cuando utilizamos servicios
Web como tecnología de implementación para una SOA, el Web Service Description
Language (WSDL) describe los mensajes, tipos y operaciones del servicio Web, que
constituyen el contrato de dichos servicios.
Capa de lógica de negocio
Otra "promesa" de SOA es que podemos construir nuevas aplicaciones a partir de
servicios existentes. El principal beneficio que proporciona SOA es la estandarización del
modelado de procesos de negocio, a menudo referido como orquestación de servicios.
Podemos construir una capa de abstracción basada en servicios Web sobre sistemas
legacy y posteriormente beneficiarnos de este hecho para ensamblar procesos de negocio.
Adicionalmente, los vendedores de plataformas SOA proporcionan herramientas y
servidores para diseñar y ejecutar estos procesos de negocio. Este esfuerzo se ha
materializado en un estándar de OASIS denominado Business Process Execution
Language (BPEL); la mayoría de vendedores de plataformas se están adhiriendo a este
estándar. BPEL es esencialmente un lenguaje de programación pero su representación es
XML.
Si bien la sintaxis BPEL es bastante sencilla, es preferible una representación gráfica de
un proceso de negocio, de esta forma nos beneficiaremos de una herramienta de diseño
GUI para ensamblar nuevos procesos de negocio a partir de servicios existentes.
4.6. El gobierno SOA (SOA governance)
La definición de la palabra "gobierno" (governance) implica la acción o forma de

gobernar. El gobierno comprende las reglas y principios de organización que determinan
cómo debería comportarse una organización. Dentro del contexto de las IT (Information
Technology), además, representa un marco de toma de decisiones y responsabilidades que
fomenta un comportamiento deseable en las IT. Los participantes en el gobierno deciden
políticas sobre diferentes categorías de decisiones que deben realizarse. Dichos
participantes también llevan a cabo la identificación de roles entre la gente que conforma
la empresa. Los miembros del grupo de gobierno también identifican a los expertos en
diferentes materias de quienes se espera que proporcionen las "entradas" para acordar
decisiones, así como identifican al grupo de gente que debe tener que ejercer sus
responsabilidades (basadas en sus roles). Un equipo de gobierno de IT debe tratar tres
cuestiones:
• ¿Qué decisiones debemos tomar para asegurar una gestión y uso efectivos de la IT?
• ¿Quién debe tomar dichas decisiones?
• ¿Cómo se van a tomar dichas decisiones y cómo pueden monitorizarse?
4.6.1. La importancia de las IT y el gobierno SOA
89
Actualmente, las IT son el elemento más omnipresente dentro de una empresa. Una
organización que posee algo tan importante para el crecimiento y éxito del negocio debe
considerarlo como uno de los elementos clave de la empresa. Un bien tan valioso debe ser
entendido completamente, no sólo para maximizar los beneficios que pueden derivarse de
él, sino para poderlo gestionar de forma adecuada y, consecuentemente, mitigar los
riesgos asociados con él. Todo ello plantea la necesidad de establecer una forma de
gobierno para formular, controlar y vigilar el mantenimiento y crecimiento adecuados de
dicha posesión valiosa para la empresa, es decir es necesario establecer un gobierno para
las IT.
SOA es como un vino viejo en una botella nueva. Los conceptos de SOA ya existen desde
hace bastante tiempo en la industria de las IT. Pero es sólo recientemente que ha captado
la atención como forma de alinear la estrategia del negocio y los imperativos de una
empresa con sus iniciativas de IT. Lo que hace que una empresa que utilice de SOA
necesite tomarse en serio el gobierno es la naturaleza distribuida de los servicios entre
varias LOBs ( Lines of Business). La proliferación de más partes "movibles" (es decir, los
bloques de construcción en forma de servicios) que necesitan ser mantenidos por las
diferentes organizaciones hace que la actividad que hemos denominado como gobierno se
plantee como un reto. La naturaleza inter-organizacional de los servicios de negocio y la
potencial composición de servicios a través de las "fronteras" de las organizaciones puede
funcionar correctamente si y sólo si los servicios son gobernados eficientemente para que
así estén conforme a los requerimientos dictados por un determinado nivel de satisfacción
requerido de características tales como la seguridad, fiabilidad, rendimiento, etc. El
proceso de identificar, especificar, crear, y finalmente desplegar los servicios de la
empresa, por lo tanto, requiere de un gobierno SOA a través de un grupo "fuerte" y
eficiente que vigile el ciclo de vida en su totalidad de una cartera de servicios de una
empresa.
4.6.2. Responsabilidades de gobierno
El rol de las IT en la empresa deber ser comprendido en su totalidad y monitorizado

cuidadosamente. Para ello los stakeholders de la compañia necesitan asegurar que las
inversiones en IT de sus organizaciones soportan la estrategia del negocio en su totalidad,
así como mitigar sus riesgos potenciales. Las responsabilidades más importantes de un
cuerpo de gobierno se muestran en la Figura 5.
90
Figura 5. Responsabilidades de gobierno.

Las principales áreas de gobierno incluyen las siguientes:
• El alineamiento estratégico se centra en la necesidad de alinear la visión del negocio,
los objetivos y las necesidades con los esfuerzos en IT.
• El valor de la entrega hace referencia a cómo el valor de una IT puede medirse a
través de los resultados como por ejemplo el aprovechamiento, la reducción de gastos,
la reducción de errores, la mejora de imagen de la compañia, etc.
• La gestión de riesgos se centra en la continuidad del negocio y las medidas a tomar
para proteger los bienes referentes a las IT.
• La gestión de recursos se centra en optimizar los servicios de infraestructura que
soportan los servicios de las aplicaciones.
• La gestión del rendimiento se centra principalmente en monitorizar los servicios que
se ejecutan en el entorno de infraestructura de la empresa u otros entornos de
infraestructura.
Un metamodelo de gobierno que ilustra la interrelación entre las cinco decisiones más
importantes a las que hacen referencia las áreas que acabamos de mencionar, se muestra
en la Figura 6.
Figura 6. Metamodelo de gobierno.

La Figura 5 muestra los principales elementos de gobierno y sus relaciones entre ellos.
Los principios de IT y SOA guían la arquitectura de las IT y el modelo de servicios, los
cuales, a su vez, determinan cómo deben definirse los servicios de infraestructura de las
91
IT de la empresa. Las necesidades de las aplicaciones de negocio requeridas pueden

evaluarse basándonos en la capacidad del marco de infraestructuras de las IT. La madurez
de la arquitectura de las IT y el modelo de servicios, así como los servicios de
infraestructura de las IT condicionan la decisión de qué partes de de las aplicaciones de
negocio requeridas pueden priorizarse para realizar inversiones de IT sobre ellas.
4.6.3. Implementación del gobierno
Cualquier implementación del gobierno debería centrarse en los cuatro pilares de una
arquitectura de empresa: la gente, los procesos, la tecnología, y los servicios. Una
implementación de gobierno SOA necesita ser soportada por una organización jerárquica,
como por ejemplo la mostrada en la Figura 7.
Figura 7. Ejemplo de estructura de organización de gobierno.

El nivel de dirección (steering committee). Está formado por miembros del comité de
dirección. El comité de dirección articula la estrategia de negocio y los objetivos de la
empresa. Los participantes en este nivel deciden cómo se deben realizar las inversiones en
IT y cómo deben canalizarse a áreas específicas del negocio que necesitan mejoras, o bien
necesitan implementar nuevas aplicaciones que puedan marcar la diferencia en el
mercado y hacer que la empresa sea más competitiva.
El nivel de liderazgo. Está formado por los líderes del gobierno y de cada uno de los
dominios del negocio. Este grupo crea la arquitectura IT de la empresa y los principios
SOA que deben seguirse.
El nivel de gestión de oportunidades. En este nivel se forman grupos separados. Cada
uno de ellos se centra en una o más necesidades del negocio y son responsables de
proporcionar definiciones claras de las aplicaciones del negocio que cubren algunas de las
necesidades de la empresa.
El nivel de gestión de proyectos. Los grupos en este nivel (initiative teams) gestionan el
ciclo de vida en su totalidad de una aplicación (diseño, desarrollo, construcción, pruebas y
92
despliegue).
4.7. SOA y JBI
JBI (Java Business Integration) es un estándar basado en Java que aborda las cuestiones
principales sobre EAI y B2B, y que está basado en los paradigmas y principios que
defiende SOA. La versión actual (1.0) lleva el nombre de JSR (Java Specification
Request) 208. Tanto los vendedores comerciales como los open source han comenzado ya
a utilizar JBI como un estándar de integración en sus productos ESB (Enterprise Service
Bus).
JBI define una arquitectura basada en plug-ins en la que los servicios pueden ser plugged
en el entorno de ejecución de JBI. JBI proporciona interfaces bien definidas para los
servicios que interactúan con el entorno de ejecución JBI. Los servicios necesitan exponer
sus interfaces al entorno JBI para que éste pueda enrutar los mensajes hacia los servicios.
El entorno de ejecución JBI actúa como un mediador entre los servicios que están
desplegados en dicho entorno (ver Figura 8)
Figura 8. Entorno de ejecución JBI.

El núcleo (core) del entorno de ejecución JBI está formado por los siguientes
componentes dentro de la misma máquina virtual Java (JVM):
• Framework de componentes: permite el despliegue de diferentes tipos de
componentes en el entorno de ejecución JBI.
• Router de mensajes normalizado: permite un mecanismo estándar de intercambio de
mensajes entre los servicios.
• Framework de gestión: está basado en JMX y permite el despliegue, gestión y
monitorización de componentes en el entorno JBI
JBI adopta SOA para maximizar el desacoplamiento entre componentes, y crear una
semántica de interoperación bien definida basada en mensajería estándar. JSR 208
describe las interfaces proveedoras de servicios (SPI: Service Provider Interfaces), que
las máquinas de servicios (no definidas por JSR 208) y los bindings incorporan, así como
el servicio de mensajes normalizado que utilizan para comunicarse entre ellos. JSR 208
tiene las siguientes ventajas de negocio:
• Es en sí misma una arquitectura orientada a servicios, y por lo tanto altamente
flexible, extensible y escalable
• Las máquinas de servicios podrían implementarse en cualquier lenguaje siempre y
cuando soporten la definición SPI implementada por los sistemas que cumplen JSR
208.
93
• Pueden añadirse nuevas máquinas en el contenedor definiendo los mensajes que

utilizarán para interactuar con el resto del sistema.
• Las interfaces abiertas permiten una competencia gratuita y abierta alrededor de la
implementación de estas máquinas. Esto significa que los clientes son libres de elegir
la mejor solución disponible, y su código de integración puede migrarse entre las
diferentes implementaciones.
En la Figura 9 se muestra un ejemplo de arquitectura JSR 208:
Figura 9. Ejemplo de arquitectura basada en JSR.

Como se puede observar, JBI proporciona un entorno en el que residen los componentes
plug-in. La interacción entre los componentes plug-in se lleva a cabo mediante la
invocación de servicios basada en mensajes. Los servicios producidos y consumidos por
los componentes plug-in se modelan utilizando WSDL 2.0. Un mensaje normalizado está
formado por dos partes: el mensaje abstracto XML, y los metadatos del mensaje (o datos
del contexto del mensaje), lo cual permite la asociación de información extra con un
mensaje particular ya que éste es procesado por los componentes del sistema y los
componentes plug-in.
Los elementos clave de un entorno JBI (mostrados en la Figura 10) son:
• Máquinas de servicios (SE: Service Engines), son componentes JBI que permiten una
lógica de negocio pluggable.
• Componentes de enlazado (BC: Binding Components), son componentes JBI que
permiten una conectividad externa pluggable.
• El enrutador normalizado de mensajes (NMR: Normalized Message Router),
direcciona los mensajes normalizados desde los componentes de origen hasta sus
destinatarios de acuerdo a políticas especificadas.
• El entorno de ejecución JBI (JBI Runtime Environment), contiene a los componentes
JBI y al NMR. Debido a sus características como contenedor, a menudo se le conoce
con el nombre de meta-contenedor JBI.
94
Figura 10. El entorno JBI.

Modelo de componentes JBI
JBI define dos tipos de componentes:
• Componentes de la máquina de servicios (SE: Service Engine): se trata de
componentes responsables de la implementación de la lógica del negocio y otros
servicios. Los componentes SE pueden ser implementados internamente utilizando
varias tecnologías y principios de diseño. Los componentes SE pueden ser tan simples
como un componente que proporciona servicios de bajo nivel tales como
transformación y traslación de datos o algo más complejos como una instancia
WS-BPEL que modela un intrincado proceso de negocio.
• Componentes de enlazado (BC: Binding components): se utilizan principalmente
para proporcionar enlaces a nivel de transporte para los servicios desplegados. Los
BC pueden ser de varios tipos, incluyendo: (a) los que permiten la comunicación
remota con sistemas externos utilizando protocolos de transporte estándar; (b) los que
permiten una invocación dentro de la máquina virtual entre dos servicios desplegados
en la misma JVM; y (c) los que permiten la comunicación entre servicios utilizando
ficheros de configuración WS-I (Web Services Interoperability).
El aspecto clave de JBI es el desacoplamiento de la máquina de servicios y los
componentes de enlazado para que la lógica de negocio no se "infeste" con los detalles de
infraestructura requeridos para invocar y consumir servicios. Esto promueve una
arquitectura flexible y extensible. Tanto los componentes BC como los SE pueden actuar
como proveedores y/o consumidores de servicios, así como aceptar/enviar mensajes
desde/hasta el entorno de ejecución JBI.
Modelo de mensajes JBI
JBI utiliza un modelo de mensajes que desacopla los consumidores de servicios de los
proveedores de servicios. El modelo de mensajes se define utilizando WSDL. WSDL se
utiliza para describir las operaciones expuestas por los componentes SE y BC. WSDL
también se utiliza para definir los enlaces a nivel de transporte para las operaciones
abstractas de los servicios.
95
NMR (Normalized Message Router) es otro de los componente fundamentales utilizado

en la arquitectura de JBI. NMR proporciona la espina dorsal construida alrededor de
WSDL, quien proporciona el intercambio de mensajes débilmente acoplados entre los
componentes SE y BC desplegados dentro de JBI. Se requiere que los servicios tengan
interfaces, formados por un conjunto de operaciones. Cada operación está formada por
uno o más mensajes. Un interfaz puede tener uno o más bindings a nivel de transporte.
4.8. SOA y Servicios Web
Muchos desarrolladores piensan a menudo que los servicios Web y SOA son sinónimos.
Muchos también piensan que no es posible construir aplicaciones orientadas a servicios
sin utilizar servicios Web. Para clarificar las diferencias diremos que SOA es un principio
de diseño, mientras que los servicios Web son una tecnología de implementación. Por lo
tanto, podemos construir una SOA utilizando otras tecnologías tradicionales, como por
ejemplo RMI.
Tenemos que destacar que el precursor de SOA es Jini: un entorno de computación
distribuida basado en Java y desarrollado por Sun a finales de los 90, en la que los
dispositivos (como por ejemplo impresoras, portátiles y PDAs) pueden ser plugged en
una red y automáticamente ofrecer sus servicios y hacer uso de otros servicios en dicha
red. Posteriormente los servicios Web utilizan estándares independientes de la plataforma
tales como HTTP, XML, SOAP, y UDDI, permitiendo la interoperabilidad entre
tecnologías heterogéneas tales como J2EE y .NET.
En 2003, SOA entra al fin por completo en el mundo de las tecnologías de la información
empresariales, a través de los servicios Web, y gracias a:
• Al contrario que CORBA y DCE, los estándares de servicios web no tienen
detractores entre los fabricantes.
• Los servicios Web tienen flexibilidad para soportar aplicaciones multicanal.
• La capacidad de SOAP de atravesar los firewalls, aprovechando la ubicuidad del
HTTP.
• El soporte de servicios Web en servidores de aplicaciones que albergan lógica
empresarial.
• Los ESBs, que combinan servicios Web con middleware orientado a mensajes
(MOM), más algunas capacidades de transformación y enrutado.
SOA está emergiendo como el principal marco de integración en entornos de
computación complejos y heterogéneos. Los intentos anteriores no permiten soluciones
interoperables abiertas, ya que recaen sobre APIs propietarios y requieren un alto nivel de
coordinación entre grupos de trabajo. SOA puede ayudar a las organizaciones a
modernizar sus procesos para que sus negocios sean más eficientes, así como adaptarlos a
las necesidades de cambio y ser más competitivos, gracias al concepto de servicio. eBay,
por ejemplo, ha "abierto" los APIs de sus servicios Web de sus subastas online. El
objetivo es permitir a los desarrolladores ganar dinero a través de la plataforma eBay.
96
Utilizando los nuevos APIs, los desarrolladores pueden construir aplicaciones cliente que
enlacen con el sitio online y permitir que las aplicaciones acepten ítems que se pondrán a
la venta. Tales aplicaciones suelen interesar a vendedores, ya que los compradores
todavía utilizan ebay.com para pujar sobre los items. Este tipo de estrategia, por lo tanto,
incrementará la base de clientes de eBay.
Aunque una SOA se podría implementar sin servicios Web, siendo realistas, cualquier
proyecto SOA realizado en los últimos años está plagado de ellos. Es más, la mayoría de
los clientes empiezan a practicar con SOA creando un servicio Web, muchas veces sobre
lógica de negocio ya existente.
Una de las principales ventajas de implementar una SOA con servicios Web es que los
servicios Web están muy extendidos y constituyen una plataforma sencilla y sobre todo
neutral.
La arquitectura básica de los servicios Web (mostrada en la Figura 11), consiste en
especificaciones (SOAP, WSDL, y UDDI) que soportan la interacción de un servicio
Web que realiza una solicitud (servicio Web cliente) con un servicio Web que suministra
el servicio requerido y con un registro de servicios (directorio de servicios Web). El
suministrador publica una descripción WSDL de su servicio Web, y el solicitante accede
a dicha descripción utilizando UDDI u otro tipo de registro, y solicia la ejecución del
servicio del suministrador enviandole un mensaje SOAP.
Figura 11. Arquitectura básica de servicios Web.

La combinación de servicios Web y SOA proporciona una integración rápida.
Consideremos un ejemplo con tres aplicaciones de bases de datos de la industria de las
finanzas que soportan préstamos bancarios, operaciones comerciales y operaciones de
inversiones bancarias. Supongamos que dichas aplicaciones se han desarrollado
utilizando una arquitectura clásica de tres capas, separando la lógica de la presentación, la
lógica del negocio, y la lógica de la base de datos.
Tal y como se muestra en la Figura 12, es posible reutilizar una aplicación tradicional de
tres capas como una aplicación orientada a servicios creando servicios a nivel de la capa
de lógica de negocio e integrando dicha aplicación con otras aplicaciones utilizando el
bus de servicios. Otro beneficio de la orientación a servicios es que es más fácil separar la
lógica de presentación de la lógica del negocio cuando la capa de lógica de negocio está
preparada para soportar servicios. También es más fácil conectar varios tipos de GUIs y
97
dispositivos móviles con la aplicación cuando la capa de lógica de negocio soporta

servicios. En lugar de ejecutar la lógica de la capa presentación como una interfaz
altamente acoplada sobre el mismo servidor, la lógica de presentación puede situarse
sobre un dispositivo separado, y la comunicación con la aplicación puede realizarse a
través del bus de servicios.
Figura 12. Diseño que facilita una integración orientada a servicios.

Otro aspecto importante es que las aplicaciones pueden intercambiar datos más
fácilmente utilizando un servicio Web definido en la capa de lógica de negocio que
utilizando otra tecnología de integración diferente debido a que los servicios Web
representan un estándar común entre todos los tipos de software. XML puede utilizarse
independientemente de la definción de los tipos de datos y estructuras. Finalmente, el
desarrollo de puntos de entrada orientados a servicios en la capa de lógica de negocio
permiten a una máquina de gestión de procesos de negocio llevar a cabo un flujo
automático de ejecución a través de los múltiples servicios.
4.9. SOA y BPM
Un proceso de negocio es una actividad del mundo real consistente en un conjunto de

tareas lógicamente relacionadas que, cuando se ejecutan en la secuencia adecuada, y de
acuerdo con unas correctas reglas de negocio, produce una salida para el negocio. Los
procesos de negocio pueden durar minutos u horas, o incluso semanas, meses o años.
La gestión de procesos de negocio (BPM: Business Process Management) aborda el
problema de cómo las organizaciones pueden identificar, modelar, desarrollar, desplegar
y gestionar sus procesos de negocio, incluyendo a los procesos que implican a los
sistemas de IT e interacciones humanas. BMP es un concepto que se utiliza desde hace
mucho tiempo, que comenzó inicialmente con sistemas workflow y que ha derivado de
forma progresiva en los modernos sistemas de orquestación y coreografía de servicios
Web.
Los principales objetivos y beneficios de un BPM incluyen:
• Reducen las diferencias entre los requerimientos del negocio y los requerimientos de
98
los sistemas IT permitiendo que los usuarios del negocio modelen los procesos de
negocio, y dejando que el departamento de IT proporcione la infraestructura para
ejecutar y controlar estos procesos de negocio.
• Incrementan la productividad de los empleados y reducen los costes operacionales
automatizando y modernizando los procesos de negocio.
• Incrementan la agilidad y flexibilidad de la empresa separando explícitamente la
lógica del proceso de otras reglas de negocio y representan los procesos de negocio de
forma que es fácil cambiarlos a medida que los requerimientos del negocio cambian.
Esto permite que las organizaciones sean más ágiles, ya que permiten responder
rápidamente a los cambios del mercado y conseguir rápidamente un mayor poder
competitivo.
• Reduce los costes de desarrollo y el esfuerzo usando un lenguaje de programación
gráfico, de alto nivel, que permite a los analistas del negocio y a los desarrolladores
construir de forma rápida y actualizar los sistemas IT dentro de un dominio particular
del problema.
Obviamente, todos los sistemas IT soportan e implementan procesos de negocio de una
forma u otra. Sin embargo, lo que hace único a la gestión de los procesos de negocio es
que explícitamente separa la lógica de dichos procesos de negocio de otras reglas de
negocio. De esta forma, la lógica del proceso se mantiene separada de las aplicaciones
subyacentes y no está incluida en dichas aplicaciones, por lo tanto, resulta sencillo y
rápido modificar los procesos de negocio a medida que los requermientos y las
necesidades del negocio cambien.
Los primeros sistemas BPM definieron formatos propietarios para representar los
procesos de negocio. Actualmente WS-BPEL proporciona una forma estándar para la
composición de servicios, así como para la orquestación y coreografía de servicios. Un
proceso de negocio puede estar formado por una composición de servicios, y la
composición de servicios es una tarea importante en SOA para proporcionar
funcionalidades de negocio de grano grueso (coarse-grained).
La Figura 13 muestra la relación entre BMP y SOA:
Figura 13. Relación entre BMP y SOA.
99
100

U3 Arquitecturas y Patrones Aplicaciones Distribuidas

Cargado por

Copyright:

Formatos disponibles

U3 Arquitecturas y Patrones Aplicaciones Distribuidas

Cargado por

Información del documento

Título 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

U3 Arquitecturas y Patrones Aplicaciones Distribuidas

Cargado por

Copyright:

Formatos disponibles

Arquitecturas y patrones de

Copyright © 2011-2012 Dept. Ciencia de la Computación e IA All rights reserved.

4 Arquitectura orientada a servicios (SOA).................................................................. 76

1. Charla 1: Introducción a los patrones de diseño. Algunos patrones

1.1. Por qué patrones

En ingeniería del software, un patrón (pattern) es una solución ya probada y aplicable a

1.2. Patrones JavaEE

Catálogo de patrones de Core J2EE Patterns

Junto al nombre de cada patrón especificaremos si se trata de un patrón JavaEE o procede

1.3. Singleton (GoF)

1.3.1. Problema a resolver

1.3.2. Discusión y beneficios

public class MiSingleton {

public class MiSingleton {

public class MiSingleton {

1.3.3. Relación con otros patrones

1.4. Facade (GoF)

1.4.1. Problema a resolver

Sistema domótico inicial

la alarma, poner el aire acondicionado a nuestra temperatura preferida, y encender las

1.4.2. Discusión y beneficios

1.5. Data Access Object - DAO (JavaEE)

1.5.1. Problema a resolver

Principio básico de diseño

Claramente la implementación de GestorPrestamos descrita con anterioridad viola el

1.5.2. Discusión y beneficios

El DAO (Data Access Object) es un patrón de diseño directamente basado en el

Principio básico del diseño

1.5.2.1. Relación con otros patrones

1.6. Transfer Object

1.6.1. Problema a resolver

1.6.2. Discusión y beneficios

Principio básico de diseño

1.7. Factory (GoF)

1.7.1. Problema a resolver

El código anterior es tedioso de modificar si se cambian los posibles canales de envío o

1.7.2. Simple factory

public class FactoriaCanales {

A primera vista parece que simplemente hemos trasladado el problema a la clase

1.7.3. Factory method

tendríamos una clase abstracta FactoriaCanales cuyo método crearCanal devolvería

Factory method para objetos ICanal

Factory method: diagrama genérico

2. Charla 2: Arquitecturas Java EE

2.1. Bloques Arquitectónicos

En toda aplicación empresarial se pueden distinguir 3 bloques arquitectónicos:

2.1.1. Capa de Servicios de Negocio

de un objeto de negocio es esencial para construir aplicaciones de calidad.

2.1.1.1. Acciones Web dentro de MVC

2.1.1.2. Capa de Servicios en un Contenedor Ligero

en la capa de negocio, los cuales permiten el intercambio de diferentes implementaciones.

2.1.1.3. Limitaciones de Qué se Puede Exponer

En la mayoría de tecnologías persistentes, existen retos en desconectar los objetos

2.1.2. Capa de Presentación

Navegador-Contenedor Web-Servidor Aplicaciones

2.1.2.1. Importancia de la Separación Lógica

2.1.2.2. Clientes Remotos

2.1.3. Capa de Acceso a Datos

El acceso a los datos persistentes normalmente determina el rendimiento global de las