UNIDAD 2. ARQUITECTURA DE APLICACIONES DISTRIBUIDAS. INTRODUCCIÓN El avance en las tecnologías de redes comenzó a dibujar un horizonte en el que las aplicaciones se comunicarían entre sí y en el que los procesos de una aplicación se distribuirían entre diferentes equipos, cada uno con características que les permitirán aumentar la eficacia y la disponibilidad de la aplicación. Se comenzó a separar la lógica de las aplicaciones para situarla en el nivel más conveniente y conceptos como “cliente” y “servidor” fueron cobrando cada vez más sentido. Tras algunos años de indecisión, los protocolos de red se estandarizaron y hacia mediados de los años 90 Internet se convirtió en la primera revolución auténtica del siglo XXI, provocando no sólo un vuelco en las relaciones sociales y económicas sino también, por supuesto, un cambio completo de paradigma en la arquitectura de las aplicaciones informáticas. Las aplicaciones se convierten, así, en aplicaciones distribuidas. Sin arriesgarnos a proporcionar una definición académica que puede encontrarse muy fácilmente en Internet, diremos informalmente que una aplicación distribuida es aquella cuyo objetivo final se alcanza mediante la ejecución de diversos procesos independientes que por lo general se ejecutan en equipos diferentes y que de una forma u otra se pasan datos entre ellos mediante protocolos de comunicaciones bien establecidos. ARQUITECTURA DE APLICACIONES DISTRIBUIDAS. ¿Qué es una arquitectura? Es un nivel de diseño que hace foco en aspectos más allá de los algoritmos y estructuras de datos de la computación, el diseño y especificaciones de la estructura global del sistema es un nuevo tipo de problema, la forma que se considera para formar algo. ¿Qué es una aplicación distribuida? Es una aplicación con distintos componentes que se ejecutan separados, normalmente en diferentes plataformas conectadas. ¿A qué se refiere la distribución? La distribución se refiere a la construcción de software por partes, a las cuales le son asignadas un conjunto específico de responsabilidades dentro de un sistema. Esta distribución como bien enunciaba la definición formal, habla de que las partes o componentes se encuentran en entornos separados, sin embargo, lo que tiene implícito esta definición, es que para realizar esta separación física primero debe tenerse clara la separación lógica de las partes de una aplicación, esto quiere decir que programáticamente existe una forma de separar o agrupar los componentes.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIDAD 2. ARQUITECTURA DE APLICACIONES DISTRIBUIDAS.
INTRODUCCIÓN El avance en las tecnologías de redes comenzó a dibujar un horizonte en el que las
aplicaciones se comunicarían entre sí y en el que los procesos de una aplicación
se distribuirían entre diferentes equipos, cada uno con características que les permitirán aumentar la
eficacia y la disponibilidad de la aplicación. Se comenzó a separar la lógica de las aplicaciones para
situarla en el nivel más conveniente y conceptos como “cliente” y “servidor” fueron cobrando cada
vez más sentido.
Tras algunos años de indecisión, los protocolos de red se estandarizaron y hacia mediados de los
años 90 Internet se convirtió en la primera revolución auténtica del siglo XXI, provocando no sólo un
vuelco en las relaciones sociales y económicas sino también, por supuesto, un cambio completo de
paradigma en la arquitectura de las aplicaciones informáticas.
Las aplicaciones se convierten, así, en aplicaciones distribuidas. Sin arriesgarnos a proporcionar una
definición académica que puede encontrarse muy fácilmente en Internet, diremos informalmente
que una aplicación distribuida es aquella cuyo objetivo final se alcanza mediante la ejecución de
diversos procesos independientes que por lo general se ejecutan en equipos diferentes y que de una
forma u otra se pasan datos entre ellos mediante protocolos de comunicaciones bien establecidos.
ARQUITECTURA DE APLICACIONES DISTRIBUIDAS.
¿Qué es una arquitectura?
Es un nivel de diseño que hace foco en aspectos más allá de los algoritmos y estructuras de datos
de la computación, el diseño y especificaciones de la estructura global del sistema es un nuevo tipo
de problema, la forma que se considera para formar algo.
¿Qué es una aplicación distribuida?
Es una aplicación con distintos componentes que se ejecutan separados, normalmente en diferentes
plataformas conectadas.
¿A qué se refiere la distribución?
La distribución se refiere a la construcción de software por partes, a las cuales le son asignadas un
conjunto específico de responsabilidades dentro de un sistema.
Esta distribución como bien enunciaba la definición formal, habla de que las partes o componentes
se encuentran en entornos separados, sin embargo, lo que tiene implícito esta definición, es que
para realizar esta separación física primero debe tenerse clara la separación lógica de las partes de
una aplicación, esto quiere decir que programáticamente existe una forma de separar o agrupar los
componentes.
La separación física no es en todas la ocasiones en “maquinas diferentes” de acuerdo a la
arquitectura también puede ser la ubicación de un conjunto de funcionalidades en archivos, rutas o
montadas sobre tecnologías diferentes dentro de la misma máquina. Cuando hablamos de
distribución lógica lo entenderemos como separación por “capas” y cuando hablemos de
distribución física usaremos el término separación en “niveles”.
“Las capas dentro de una arquitectura son un conjunto de servicios especializados que pueden ser
accesibles por múltiples clientes y que deben ser fácilmente reutilizables”. Una capa puede contener
muchos componentes, un mismo componente puede ubicarse en varias capas de acuerdo a su
naturaleza y a las consideraciones explicitas de la arquitectura.
¿Qué es una arquitectura en ambiente distribuido?
Describe la estructura y la organización de los componentes del software, sus propiedades y la
conexión entre ellos para formar el sistema; la cantidad y la granularidad de comunicación que se
necesita para la interacción y los protocolos de interfaz usada por la comunicación.
En una aplicación distribuida en n-capas los diferentes elementos que integran la aplicación se
agrupan de forma lógica según la funcionalidad que reciben o suministran al o desde el resto de los
elementos. Así, algunos elementos se limitarán a recibir peticiones de datos mientras que otros
interactuarán con el usuario y su función será principalmente la de solicitar a otros elementos la
información que el usuario precisa.
Una vez agrupada la funcionalidad en capas lógicas es fácil relacionar unas con otras. El usuario
interactuará con la capa de presentación, solicitando datos o desencadenando acciones. Las
solicitudes serán atendidas por la capa de negocios, que se encargará de su gestión o de la
traducción necesaria para que la capa de servidor realice la tarea solicitada. La capa de servidor
debe proporcionar datos los cuales se devolverán a la capa de negocios, la cual los gestionará o
transmitirá a la capa de presentación.
La figura 2.1 ilustra este esquema.
Esquema lógico de las capas en una aplicación distribuida.
Es importante notar que el esquema que mostramos es un esquema lógico, no físico. El modo
de distribuir físicamente las capas (en diferentes ejecutables o DLL, o en diferentes equipos) se
corresponderá con el esquema lógico en todo o en parte, pero no necesariamente existirá una
correspondencia exacta entre la distribución lógica de los elementos y su distribución física. La capa
de negocios podría residir en diferentes máquinas, por ejemplo, o las entidades de negocio y la capa
de servidor podrían formar parte de la misma DLL.
2.1 CAPA DE INTERFAZ DE USUARIO La capa de presentación o interfaz de usuario se refiere al mecanismo de interacción del
usuario con el sistema. Es la que ve el usuario (también se la denomina "capa de usuario"), presenta
el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo
de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es
conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de
usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio.
Los tipos de interfaces de software más comunes son las aplicaciones de ventanas y web. Los tipos
de interfaces de hardware más comunes son el ratón, el teclado, el micrófono, pantallas táctiles,
dispositivos de imagen y audio.
Está formada por los formularios y los controles que se encuentran en los formularios, capa con la
que interactúan el usuario y es responsable de obtener datos de la capa siguiente, mostrarlos,
validar entradas de datos, enviarlas a la siguiente capa donde pueden dividirse en: presentación,
código de interfaz de usuario.
La capa de presentación o interface de usuario la constituye el software con el que el usuario
interactúa para operar con la aplicación. Es probablemente la parte más trabajosa de la misma, ya
que es muy frecuente que aplicaciones cuyas reglas de negocio sean relativamente sencillas tengan
en cambio un interfaz de usuario complejo y vistoso que le proporcione al usuario una experiencia de
manejo fácil y agradable. Además, mientras que en la creación de reglas de negocio normalmente
sólo interviene un tipo de programación, preferentemente basada en lenguajes, en la preparación del
interfaz de usuario suelen mezclarse varias disciplinas, como el diseño o la usabilidad.
Un error frecuente en la creación de los interfaces de usuario consiste en olvidar que las reglas de
negocio no se hallan en el interfaz, sino en los objetos subyacentes que residen en las capas
inferiores de la solución. La capa de presentación no es más que un sistema de presentación y
manejo de datos que se obtienen y se actualizan con los objetos de negocio comunes para todas las
aplicaciones que los usan. Si se olvida este aspecto se puede caer en la tentación de colocar reglas
de negocio en el interfaz de usuario, imposibilitando la reutilización de las mismas y complicando la
distribución y despliegue de la aplicación. Por lo tanto, una regla de oro a observar en toda aplicación
distribuida es que la capa de presentación ha de ser completamente independiente de las reglas de
negocio, y su función se limitará a la presentación y manejo de los datos de la aplicación, que
obtendrá mediante el uso de los objetos de la capa de negocios comentados en la sección anterior.
Esto convierte a la capa de presentación en una mera fachada de los procesos que son gestionados
por la capa de negocios. Las capas de presentación suelen ser “delgadas”, es decir, contienen pocas
líneas de código, ya que su función principal está cubierta por las características de los elementos
“visuales” que las componen. Una tendencia creciente es la separación entre diseño y código, ya
existente, por ejemplo, en las aplicaciones web dinámicas.
2.2 CAPA DE MANEJO DE DATOS La capa de negocios o de manejo de datos, es donde residen los programas que se ejecutan,
se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina
también capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas
las reglas que deben cumplirse.
Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los
resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar
datos de él. También se consideran aquí los programas de aplicación.
División de la capa de manejo de datos
La capa de negocios representa el grueso de la lógica de funcionamiento de la aplicación
distribuida. En esta capa se sitúan las normas de acceso a datos, la lógica de tratamiento de los
mismos, y en general cualquier elemento de la aplicación que pueda reutilizarse.
El objetivo de la creación de esta capa “intermedia” es aislar la capa de presentación de la capa de
servidor, de forma que las estructuras de datos subyacentes y la lógica que las utilizan sean
independientes de la capa de presentación. De esta forma, también, el mantenimiento de las normas
de negocio será más sencillo y, sobre todo, será reutilizable desde cualquier capa de presentación,
sea del tipo que sea.
A pesar de que se suele utilizar el nombre de capa de negocios para referenciar a todos los
elementos que componen esta capa intermedia de software, por lo general la capa de negocios
suele dividirse en dos tipos de elementos, atendiendo a la función que desempeñan en la capa.
La figura 2.3 ilustra los elementos típicos que suelen aparecer en las capas de negocios.
Figura 2.3: Esquema lógico de las capas en una aplicación distribuida
Lógica de negocios
Cuando las aplicaciones adquieren cierto volumen o las entidades implicadas tienen cierta
complejidad, la lógica de acceso a datos por sí sola no es suficiente para encapsular
convenientemente el acceso a las entidades de datos. En estos casos será necesario añadir objetos
más complejos que a su vez encapsulen los objetos de acceso a datos y los expongan de forma más
sencilla a las capas superiores, facilitando su manejo.
Además, en las aplicaciones distribuidas con cierto tamaño es frecuente encontrar reglas de negocio
que no tienen nada que ver con el acceso a datos, sino que constituyen mecanismos aparte que de
una forma o de otra es deseable extraer de la capa de presentación para su reutilización o para que
su mantenimiento sea sencillo.
Estas necesidades implican a menudo la creación de una capa adicional de lógica que
llamaremos lógica de negocios. Los elementos de la lógica de negocios ya no se conectan a los
orígenes de datos ni representan a las entidades de datos subyacentes, sino que utilizan los objetos
de acceso a datos y las entidades de negocio, siendo pues una especie de “cliente” de la lógica de
acceso a datos.
Lógica de acceso a datos
La lógica de acceso a datos incluye los elementos necesarios para que la aplicación se
conecte a orígenes de datos y recupere estructuras de datos que serán utilizadas por el resto de la
aplicación. En una aplicación distribuida, los únicos elementos que se conectan a la base de datos
son los objetos de acceso a datos, y el resto de elementos de la aplicación se limitan a enlazar con
estos objetos para solicitar datos y enviar órdenes a los orígenes de datos.
Los motivos para encapsular todo el acceso a datos en la lógica de acceso a datos son múltiples. En
primer lugar, no será necesario distribuir la información de conexión por todo el sistema, ya que el
único punto desde el que se efectuará el acceso directo a los orígenes de datos será el equipo en el
que resida físicamente la lógica de acceso a datos. Tampoco será necesario distribuir el software
cliente del SGBD por diferentes máquinas, lo que facilita el mantenimiento y la instalación de la
aplicación.
Además, encapsular la lógica de acceso a datos permite que la aplicación sea agnóstica respecto al
origen de datos, es decir, puede realizar sus tareas sin tener la necesidad de saber en qué SGBD
concreto residen los datos, ni en qué punto de la red se halla el servidor, lo que facilita la
configuración del sistema. Este sistema posibilita la utilización de varios SGBD en una aplicación o
facilita la migración de un SGBD a otro.
También permite que la aplicación ignore la estructura real de los orígenes de datos, ya que es la
propia lógica de acceso a datos la que expondrá las estructuras con las que trabajará la aplicación,
acomodándolas a las necesidades de la misma. Otro factor importante es la reutilización. La
separación de esta lógica permite reutilizar los componentes de acceso a datos en diversas
aplicaciones sin necesidad de copiar el código y manteniendo la coherencia en el comportamiento
del acceso a datos en todas ellas.
A pesar de que otros elementos, como los que componen la lógica de negocios, son opcionales, los
elementos de lógica de acceso a datos deben estar presentes en toda arquitectura distribuida que se
diseñe, debido a las ventajas que aportan.
2.3 CAPA DE PROCESAMIENTO DE DATOS Es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno
o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes
de almacenamiento o recuperación de información desde la capa de negocio.
El acceso a datos se refiere al medio a través del cual podemos acceder y manipular los datos
persistentes de un sistema.
El almacenamiento de datos se refiere a la forma en que se encuentran guardados dichos datos, por
ejemplo, en archivos o bases de datos.
Servicios
En esta capa encontraremos los procesos de la aplicación que se encargan recibir las
peticiones de las capas superiores y, si es necesario, devolver los datos solicitados. Esta función
será desempeñada por un servicio.
Los servicios son procesos que se ejecutan en los equipos servidores y que se mantienen a la
escucha esperando que los procesos cliente les soliciten funcionalidad o datos. Por lo general los
servicios residen en equipos dedicados cuya configuración y características físicas están
especialmente diseñadas para realizar esta función.
Servicios de base de datos
Los servicios de base de datos son los más frecuentes en las aplicaciones distribuidas. Los
SGBD como SQL Server u Oracle disponen de toda la infraestructura de servicios necesarios para
que los equipos cliente les realicen peticiones y para responder a ellas. Se ejecutan como un servicio
de forma totalmente desatendida, se enlazan al protocolo de red para escuchar peticiones de otros
equipos, gestionan la concurrencia de las llamadas e incorporan mecanismos de seguridad propios o
integrables con el directorio activo.
Una de las características más importantes de los SGBD es que nos permiten crear reglas de
negocio. Estas reglas pueden invocarse remotamente desde los clientes y se escriben en lenguajes
propios del SGBD (Transact-SQL en el caso de SQL Server, por ejemplo). Los SGBD compilan y
ejecutan de la forma más óptima posible estas reglas, de modo que su ejecución siempre es de alto
rendimiento.
Casi todas las aplicaciones y servicios necesitan almacenar y obtener acceso a un determinado tipo
de datos. Por ejemplo, una aplicación comercial necesitaría almacenar datos de productos, clientes y
pedidos.
Al trabajar con datos debe determinar:
El almacén de datos que utiliza.
El diseño de los componentes utilizados para obtener acceso al almacén de datos.
El formato de los datos pasados entre componentes y el modelo de programación necesario
para ello.
La aplicación o servicio puede disponer de uno o varios orígenes de datos, los cuales pueden ser de
tipos diferentes. La lógica utilizada para obtener acceso a los datos de un origen de datos se
encapsulará en componentes lógicos de acceso a datos que proporcionan los métodos necesarios
para la consulta y actualización de datos. Los datos con los que la lógica de la aplicación debe
trabajar están relacionados con entidades del mundo empresarial que forman parte de la empresa.
En determinados escenarios, puede disponer de componentes personalizados que representan
estas entidades, mientras que en otros puede decidir trabajar con datos utilizando directamente
conjuntos de datos ADO.NET o documentos XML.
En la figura 2.11 se muestra cómo la capa de datos lógicos de una aplicación consta de uno o varios
almacenes de datos y describe una capa de componentes lógicos de acceso a datos utilizados para
recuperar y manipular los datos en dichos almacenes.
Figura 2.11. Componentes de datos
La mayoría de las aplicaciones utilizan una base de datos relacional como almacén principal de los
datos de la aplicación. También se puede utilizar el almacén de Web Microsoft Exchange Server,
bases de datos heredadas, el sistema de archivos o servicios de administración de documentos.
Cuando la aplicación recupera datos de la base de datos, puede hacerlo utilizando un formato de
conjunto de datos DataReader. A continuación los datos se transfieren entre las capas y los distintos
niveles de la aplicación y, finalmente, uno de los componentes los utilizará. Tal vez desee utilizar
formatos de datos diferentes para recuperar, pasar y utilizar datos; por ejemplo, puede utilizar los
datos de un conjunto de datos para llenar las propiedades de un objeto de entidad personalizado. No
obstante, debería intentar mantener una coherencia en cuanto al tipo de formato utilizado, ya que
mejorará probablemente el rendimiento y la facilidad de mantenimiento de la aplicación para
presentar sólo un conjunto limitado de formatos, evitando así la necesidad de capas de traducción
adicionales y de familiarizarse con API diferentes.
En las siguientes secciones se describe la elección de almacenes de datos, el diseño de los
componentes lógicos de acceso a datos y las distintas posibilidades disponibles de representación
de datos.
Almacenes de datos
Entre los tipos de almacenes habituales se encuentran:
Bases de datos relacionales. Las bases de datos relacionales, como las bases de datos SQL
Server, proporcionan funcionalidad de administración de un gran volumen de datos
transaccionales de alto rendimiento con capacidades de seguridad, operaciones y transformación
de datos. Las bases de datos relacionales también alojan instrucciones y funciones complejas de
lógica de datos en forma de almacenamientos almacenados que se pueden utilizar como un
entorno eficaz para los procesos empresariales con un gran volumen de datos.
Bases de datos de mensajería. Puede almacenar datos en el almacén Web de Exchange Server,
lo que resulta especialmente útil si la aplicación está centrada en el grupo, el trabajo en grupo o
mensajes y no desea basarse en otros almacenes de datos que pueden necesitar que se
administren de forma independiente. Sin embargo, los almacenes de datos de mensajes suelen
presentar menores capacidades de rendimiento, escalabilidad, disponibilidad y administración
que los sistemas de administración de bases de datos relacionales completas (RDBMS) y, por
tanto, es relativamente no habitual que las aplicaciones que utilicen el almacén de datos
proporcionado por un producto de mensajería.
Sistema de archivos. Puede decidir almacenar los datos en sus propios archivos en el sistema de
archivos. Estos archivos pueden presentar su propio formato o el formato XML con un esquema
definido para los propósitos de la aplicación.
Hay un gran número de otros almacenes (como bases de datos XML, servicios de procesamiento
analítico en línea y bases de datos de almacenamiento de datos, entre otros) pero no son el
objeto de análisis de esta guía.
Componentes lógicos de acceso a datos. Independientemente del almacén de datos utilizado, la
aplicación o el servicio utilizarán componentes lógicos de acceso a datos para obtener acceso a
los datos. Estos componentes abstraen la semántica del almacén de datos subyacente y la
tecnología de acceso a datos (como ADO.NET) y proporcionan una interfaz simple de
programación para la recuperación y realización de operaciones con datos.
Los componentes lógicos de acceso a datos suelen implementar un patrón de diseño sin estado que
separa el procesamiento empresarial de la lógica de acceso a datos. Cada uno de estos
componentes suele proporcionar métodos para realizar operaciones Create, Read, Update y Delete
(CRUD) relacionadas con una entidad empresarial determinada de la aplicación (por ejemplo, Order).
Los procesos empresariales pueden utilizar estos métodos. La interfaz de usuario pueden utilizar las
consultas específicas para procesar los datos de referencia (como una lista de tipos de tarjetas de
crédito válidos).
Cuando la aplicación contiene varios componentes lógicos de acceso a datos, puede resultar útil
utilizar un componente de ayuda de acceso a datos genéricos para administrar las conexiones de las
bases de datos, ejecutar comandos y almacenar parámetros en caché, entre otros. Los componentes
lógicos de acceso a datos proporcionan la lógica necesaria para obtener acceso a datos
empresariales específicos, mientras que el componente de ayuda para el acceso a datos centraliza
el desarrollo de API de acceso a datos y la configuración de la conexión a éstos, permitiendo de esta
forma la reducción de código duplicado. Un componente de ayuda de acceso a datos bien diseñado
no debe repercutir negativamente en el rendimiento y proporciona una ubicación central para el
ajuste y optimización del acceso a datos. Microsoft proporciona Data Access Application Block para
.NET, que se puede utilizar como un componente de ayuda de acceso a datos genéricos en la
aplicación al utilizar bases de datos SQL Server.
En la figura 2.12 se muestra el uso de componentes lógicos de acceso a datos para obtener acceso
a datos.
Figura 2.12. Componentes lógicos de acceso a datos
Observe los siguientes puntos en la figura 2.12:
1. Los componentes lógicos de acceso a datos exponen métodos para insertar, eliminar,
actualizar y recuperar datos, incluyendo la provisión de funcionalidad de paginación al
recuperar grandes cantidades de datos.
2. Puede utilizar un componente de ayuda de acceso a datos para centralizar la administración
de la conexión y todo el código relacionado con un origen de datos específico.
3. Se recomienda implementar las consultas y operaciones de datos como procedimientos
almacenados (si es compatible con el origen de datos) para mejorar el rendimiento y la
facilidad de mantenimiento.
Agentes de servicios. Cuando un componente empresarial requiere el uso de la funcionalidad
proporcionada por un servicio externo, tal vez sea necesario hacer uso de código para
administrar la semántica de la comunicación con dicho servicio. Por ejemplo, los componentes
empresariales de la aplicación comercial descrita anteriormente podría utilizar un agente de
servicios para administrar la comunicación con el servicio de autorización de tarjetas de crédito y
utilizar un segundo agente de servicios para controlar las conversaciones con el servicio de
mensajería. Los agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios
servicios desde la aplicación y pueden proporcionar servicios adicionales, como la asignación
básica del formato de los datos que expone el servicio al formato que requiere la aplicación.
2.4 INTEGRACION DE SISTEMAS HEREDADOS Un sistema heredado (o sistema legacy) es un sistema informático (equipos
informáticos o aplicaciones) que ha quedado anticuado pero continúa siendo utilizado por el usuario
(típicamente una organización o empresa) y no se quiere o no se puede reemplazar o actualizar de
forma sencilla. Los sistemas heredados no son sólo sistemas de software de aplicación. Son
sistemas socio-técnicos, por lo que incluyen procesos de negocio, software de aplicación, software
de apoyo y sistema hardware.
Aunque la funcionalidad que un sistema heredado ofrece a los procesos empresariales puede estar
disponible a través de una tecnología más moderna, la posibilidad de una interrupción del servicio
durante la actualización de sistemas puede impedir una migración hacia el uso de sistemas más
nuevos, o incluso la puede impedir dada la dificultad percibida en la conversión del contenido
heredado para ajustarse a los nuevos modelos de contenido y formatos.
Muchos sistemas heredados todavía se utilizan porque solucionan bien el problema y remplazarlos
sería demasiado costoso. Las compañías gastan mucho dinero en sistemas informáticos y, para
obtener un beneficio de esa inversión, el software o el hardware debe utilizarse varios años. El
tiempo de vida de los sistemas informáticos es muy variable, pero muchos sistemas grandes se
pueden llegar a utilizar hasta más de 20 años. Muchos de estos sistemas antiguos aún son
importantes para sus respectivos negocios, es decir, las empresas cuentan con los servicios
suministrados por estos sistemas y cualquier fallo en estos servicios tendría un efecto serio en el
funcionamiento de la organización. Estos sistemas antiguos reciben el nombre de sistemas
heredados.
Lo habitual es que los sistemas heredados, que ya suponen un problema para una empresa u
organización por la dificultad para sustituirlos, no sean los mismos sistemas que originalmente se
empezaron a utilizar en la empresa. Obviamente la modernización de estos sistemas anticuados es
deseable, pero muchas veces no es muy asequible, no sólo por razones económicas sino también
por razones críticas de entrega de servicios. Muchos factores externos e internos, como el estado de
las economías nacional e internacional, los mercados cambiantes, los cambios en las leyes, los
cambios de administración o la reorganización estructural, conducen a que los negocios
experimenten cambios continuos.
El enfoque del problema de las aplicaciones heredadas es el de evitar cualquier modificación en los
sistemas heredados que pueda poner en peligro la entrega de servicios; este enfoque también
elimina la formación de los usuarios del sistema heredado al nuevo sistema, con el beneficio
evidente del ahorros de costes y tiempos en la adquisición de nuevo equipamiento y el período de
adaptación requerido para utilizarlo. Además que estos cambios generan o modifican
los requerimientos del sistema de información, por lo que éste va sufriendo cambios conforme
cambian los negocios. Por esta razón, los sistemas heredados incorporan un gran número de
actualizaciones hechas a lo largo de su vida útil.
Muchas personas diferentes pueden haber estado involucradas en la realización de estas
modificaciones a lo largo del tiempo, y es inusual para cualquier usuario o administrador del
sistema tener un conocimiento completo del mismo, sobre todo cuando éste tiene una cierta
envergadura.
Riesgos de la migración de un sistema heredado. Los sistemas heredados son considerados
potencialmente problemáticos por numerosos ingenieros de software por diversos motivos.
Dichos sistemas a menudo operan en ordenadores obsoletos y lentos, cuyo mantenimiento tiene
elevados costes y son difíciles de actualizar por falta de componentes adecuados o
de mantenimiento.
Costes de mantenimiento de un sistema heredado. Seguir utilizando los sistemas heredados evita
los mencionados riesgos del reemplazo, pero hacer cambios al sistema existente en vez de
cambiarlo por uno más moderno puede ser más costoso puesto que éste es cada vez más viejo
Alternativas. Los negocios que tienen sistemas informáticos anticuados se enfrentan a un dilema
fundamental. Si continúan utilizando los sistemas heredados y realizan los cambios requeridos,
sus costos se incrementarán de forma inevitable. Si deciden reemplazar sus sistemas heredados
con nuevos sistemas, esto tendrá un coste y puede ocurrir que los nuevos sistemas no provean
apoyo efectivo al negocio como lo hacen los sistemas heredados.
Mantener el sistema heredado. Muchos negocios están buscando técnicas de ingeniería de
software que prolonguen el tiempo de vida de los sistemas heredados y que reduzcan los costos
de seguir utilizando estos sistemas
Los sistemas heredados son considerados por las organizaciones de TI como elementos
destacados dentro del nuevo concepto de empresa. Los usuarios ya no preguntan cómo librarse
de sus sistemas heredados, sino que buscan formas para aprovechar el valor de negocio de
estos sistemas heredados.
¿Qué es la integración de sistemas heredados?
La integración de sistemas heredados puede definirse como la reutilización de sistemas y
aplicaciones heredadas existentes, que se logra mediante la integración con aplicaciones
corporativas desarrolladas recientemente.
La integración de sistemas heredados brinda un método no intrusivo para reutilizar aplicaciones
críticas que residen en sistemas heredados, como un sistema mainframe o AS/400. El poder utilizar
estos recursos existentes tiene muchas ventajas, entre ellas un riesgo reducido y ahorros
significativos. Riesgo reducido por medio de fiabilidad, disponibilidad y facilidad de mantenimiento
(RAS, por su sigla en inglés) Para muchas organizaciones, la decisión inicial de recurrir al uso de un
equipo mainframe o AS/400 se basaba en la estabilidad sin precedentes del sistema. El término RAS
fue acuñado por IBM, y se refiere a la fiabilidad, disponibilidad y facilidad de mantenimiento de un
sistema.
Según IBM, para que un sistema se considere fiable debe ser capaz de realizar pruebas de auto-
verificación de errores, y rápidamente aplicar cualquier actualización necesaria para recuperarse de
estos problemas sin interacción manual. El concepto de disponibilidad se refiere a la capacidad del
sistema de recuperarse de los problemas sin alterar el correcto funcionamiento del resto de sus
áreas. Además de la auto-verificación de errores y la auto-recuperación aislada de esos errores, un
sistema debería ser también capaz de determinar la causa de la falla. Esto se conoce como facilidad
de mantenimiento.
Paul Baquet, un analista de sistemas señor de Duke Health Technology Solutions afirma: "En
términos de estabilidad, el mainframe es probablemente el equipo más adecuado para procesar
transacciones. Nosotros atendemos las necesidades de 2000 usuarios finales en todo momento, de
modo que contar con esa clase de flexibilidad nos permite continuar apoyando el entorno de los
servicios de salud, mientras el mainframe procesa aplicaciones y las deriva a otros sistemas". La
integración de sistemas heredados permite a las organizaciones capitalizar esta solidez comprobada
y utilizarla como base para nuevas aplicaciones de negocios.
Seguridad
Cuando se trata de proteger los datos y recursos TI de una organización, la plataforma Power
de IBM incorpora características avanzadas de autenticación y cifrado, así como recursos de control
de gastos y administración. Se pueden implementar políticas de seguridad tanto a nivel de sistema
como de usuario.
Estas herramientas ayudan a las organizaciones a asegurar sus datos frente a amenazas de
seguridad internas y externas, satisfacer o exceder el alcance de las regulaciones de seguridad y
políticas de cumplimiento, y apoyar las auditorías de seguridad. La integración de estas herramientas
con el sistema operativo facilita el proceso de administración y provee una fiabilidad superior. La
línea pSeries admite herramientas de gestión de seguridad diseñadas tanto para la plataforma como
para el nivel corporativo.
Escalabilidad
Para adaptarse al crecimiento de un negocio, los sistemas deben ser escalables. Los sistemas
heredados, como el mainframe, son reconocidos por su escalabilidad. Los sistemas escalables
pueden adaptarse para utilizar una cantidad adecuada de recursos de sistema, como memoria,
procesadores y almacenamiento, a fin de funcionar eficientemente y con independencia del tamaño o
la complejidad de la red.
Ahorros en costos
La integración de sistemas heredados permite a las organizaciones ahorrar dinero por medio
del aprovechamiento de recursos existentes, que ya han demostrado su capacidad para incrementar
el retorno de la inversión (ROI). Muchos de estos sistemas heredados han estado funcionando por
décadas y han resistido el paso del tiempo en lo que hace a RAS; fiabilidad, disponibilidad y
escalabilidad. En la mayoría de los casos, la implementación de tecnologías completamente nuevas
y la portación de los datos existentes a estos nuevos sistemas suponen costos prohibitivos.
En una encuesta reciente auspiciada por BMC software, el 95% de los 1100 gerentes de TI
encuestados indicó que el mainframe seguiría cumpliendo un rol central en su infraestructura de
tecnología de la información. El 65% de ellos declaró que su uso de la plataforma seguiría creciendo.
Los sistemas fiables, disponibles y fáciles de mantener, y que además son seguros y escalables,
brindan ventajas demasiado numerosas como para ser ignoradas por cualquier organización que
desee mantener un control racional de los costos. La integración de sistemas heredados permite
que las organizaciones aprovechen estas ventajas y las integren con tecnologías actuales.
2.5 DISTRIBUCIÓN DE ELEMENTOS DE UNA APLICACIÓN. Se refiere a la construcción de software por partes, a las cuales les son asignadas un conjunto
específico de responsabilidades dentro de un sistema. También se refiere a la necesidad de distribuir
los elementos de un sistema dependiendo de las características y necesidades del lugar.
Una aplicación distribuida es una aplicación con distintos componentes que se ejecutan en entornos
separados, normalmente en diferentes plataformas conectadas a través de una red. La distribución
habla de que las partes o componentes se encuentran en entornos separados, entonces para
realizar la separación física, primero se debe de tener clara la separación lógica de las partes de una
aplicación.
Hay componentes de diferentes tipos: Ejecutables páginas web, librerías, controles, Procedimientos
almacenados servicios web…Ejemplo: Paquetería de office, Corel, Reproductor Windows etc. Los
ejecutables se refieren a programas o aplicaciones de escritorio que corren sobre un sistema
operativo.
Una página web es una fuente de información adaptada para worldwide web (WWW) que es
accesible mediante un navegador de internet y normalmente forma parte de un sitio web
Las librerías se refieren bibliotecas o conjunto de clases que contiene lógica de programación
implementada como servicios que pueden ser utilizados desde otras librerías o aplicaciones.
Ejemplo: Java(java.io, java.lang), Netbeans entre otros.
2.6 INTEGRACIÓN DE TECNOLOGÍAS HETEROGÉNEAS Y HOMOGÉNEAS. Existen diferentes motivos para la heterogeneidad y homogeneidad. Una razón son los
cambios tecnológicos que siempre se dan en un periodo de tiempo corto. En este contexto, dichos
cambios se refieren a mejor calidad, mejor desempeño, costos más económicos, seguridad, entre
otras características que se toman en cuenta.
Otra razón es que la diversidad en una red de computadoras puede hacerla más resistente que
cualquier problema dado en algún tipo de máquina, sistema operativo o aplicación son poco
probables que afecten a otros sistemas corriendo en diferentes sistemas operativos y aplicaciones.
HOMOGENEO
En los sistemas homogéneos, todos los sitios emplean idéntico software de gestión de base
de datos, son conscientes de la existencia de los demás sitios y acuerdan cooperar en el
procesamiento de las solicitudes de los usuarios.
Un sistema distribuido homogéneo tiene múltiples conexiones de datos ; integra múltiples recursos
de datos. Los sistemas homogéneos se parecen a un sistema centralizado, pero en lugar de
almacenar todos los datos en un solo lugar los datos se distribuyen en varios sitios comunicados. No
existen usuarios locales y todos ellos accedan la base de datos global. El esquema global es la
unión de todas las descripciones de datos locales y las vistas de los usuarios se definen sobre el
esquema global.
HETEROGENEO
Las tecnologías Heterogéneas son aquellas donde Sitios diferentes utilizan diferentes DBMS,
siendo cada uno esencialmente autónomo. Es posible que algunos sitios no sean conscientes de la
existencia de los demás y quizás proporcionen facilidades limitadas para la cooperación en el
procesamiento de transacciones. La heterogeneidad se debe a que los datos de cada BD son de
diferentes tipos o formatos. El enfoque heterogéneo es más complejo que el enfoque homogéneo.
VENTAJAS
La potencia que ofrece multitud de computadores conectados en red usando grid es
prácticamente ilimitada, además de que ofrece una perfecta integración de sistemas y dispositivos
heterogéneos, por lo que las conexiones entre diferentes maquinas no generan ningún problema.
Se trata de una solución altamente escalable, potente y flexible ya que evitaran problemas de falta
de recursos (cuellos de botellas) y nunca queda obsoleta, debido a la posibilidad de modificar el
número de características de sus componentes.
CONCLUSION
Los sistemas homogéneos son los que están basados en un mismo tipo de aplicación lo que
permite una integración más rápida.
Los sistemas heterogéneos manejan diferentes tipos de aplicaciones en los diferentes sitios lo que
provoca que cada equipo pueda ser autónomo y la cooperación entre los diferentes sitios es más
complicada, costosa y no siempre posible.
2.7 SERVICIOS DE LA ARQUITECTURA (EMAIL, WEB, BASE DE DATOS,