23
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.

ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

Embed Size (px)

DESCRIPTION

UNIDAD 2 ARQUITECTURA DE APLICACIONES

Citation preview

Page 1: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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.

Page 2: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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.

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

Page 3: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 4: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 5: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 6: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 7: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 8: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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.

Page 9: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 10: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 11: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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.

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

Page 12: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

procedimientos almacenados (si es compatible con el origen de datos) para mejorar el

rendimiento y la facilidad de mantenimiento.

4. 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 formato 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

Page 13: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 14: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 15: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 16: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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

Page 17: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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 world wide 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

Page 18: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

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 numero 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,

Page 19: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

APLICACIONES, TRANSACCIONES, SISTEMAS OPERATIVOS, FIREWALL)

SERVICIO WEB

Es un conjunto de protocolos y estándares que sirven para intercambiar datos entre

aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de

programación diferente y ejecutada sobre cualquier plataforma pueden utilizar los

servicios web para intercambiar datos en redes de ordenadores como internet.

Protocolos utilizados:

a) XML: Es el formato estándar para los datos que se vayan a intercambiar.

b) SOAP o XML-RPC: Protocolos sobre los que se establece el intercambio.

c) HTTP, FTP, o SMTP: los datos en XML también pueden enviarse de una

aplicación a otra mediante protocolos normales ya bien conocidos.

d) WSDL: Es el lenguaje de la interfaz pública para los servicios Web.

e) UDDI: Protocolo para publicar la información de los servicios Web.

f) WS-Security: Protocolo de seguridad aceptado como estándar por OASIS.

Estos servicios proporcionan mecanismos de comunicación estándares entre

diferentes aplicaciones, que interactúan entre sí para presentar información

dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre

estas aplicaciones, y que al mismo tiempo sea posible su combinación para

realizar operaciones complejas, es necesaria una arquitectura de referencia

estándar.

El siguiente gráfico muestra cómo interactúa un conjunto de Servicios Web:

Según el ejemplo del gráfico, un usuario (que juega el papel de cliente dentro

de los Servicios Web), a través de una aplicación, solicita información sobre un viaje que

desea realizar haciendo una petición a una agencia de viajes que ofrece sus servicios a

través de Internet. La agencia de viajes ofrecerá a su cliente (usuario) la información

requerida. Para proporcionar al cliente la información que necesita, esta agencia de viajes

solicita a su vez información a otros recursos (otros Servicios Web) en relación con el

hotel y la compañía aérea. La agencia de viajes obtendrá información de estos recursos,

lo que la convierte a su vez en cliente de esos otros Servicios Web que le van a

proporcionar la información solicitada sobre el hotel y la línea aérea. Por último, el usuario

realizará el pago del viaje a través de la agencia de viajes que servirá de intermediario

entre el usuario y el servicio Web que gestionará el pago.

SERVICIO EMAIL

Page 20: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

Servicio de red que permite a los usuarios enviar y recibir mensajes rápidamente a los

usuarios enviar y recibir mensajes rápidamente también denominados mensajes

electrónicos o cartas electrónicas mediante sistemas de comunicación electrónicos.

Aplicaciones para envío y recepción de emails

Los mensajes de email son intercambiados entre hosts que emplean el protocolo SMTP,

con programas llamados agentes de transferencia de emails.

En tanto, los usuarios pueden recibir sus emails de los servidores empleando protocolos

como POP o IMAP; o protocolos propietarios específicos como Lotus Notes o Microsoft

Exchange Servers. También pueden emplear servicios de webmail para acceder a los

emails desde un navegador web

1. Aplicaciones online: Existen servicios online dedicados al webmail como Gmail,

Hotmail, Yahoo! Mail, etc. En general, un usuario debe registrarse al servicio de e-mail

para obtener una cuenta de correo electrónico.

2. Aplicaciones de computadora: Algunas aplicaciones que se utilizan para el envío y

recepción de e-mails son: Microsoft Outlook Express, Microsoft Outlook, Netscape Mail,

Eudora y Pegasus Mail.

BASE DE DATOS

Conjunto de datos pertenecientes a un mismo contexto y almacenados

sistemáticamente para su posterior uso. Un servidor de base de datos es un

programa que provee servicios de base de datos a otros programas u otras

computadoras, como es definido por el modelo cliente-servidor. También puede

hacer referencia a aquellas computadoras (servidores) dedicadas a ejecutar esos

programas, prestando el servicio.

Los servidores de datos deben proporcionar mecanismos de comunicación

óptimos, pues de cómo se envíe la información dependerán parámetros tan

importantes como la velocidad de acceso a los datos. Todos los sistemas gestores

analizados cuentan con múltiples configuraciones de protocolos, adaptándose a

los protocolos existentes y estandarizados de la actualidad: TCP/IP, IPX, Banyan,

etc.; es importante no sólo el canal de comunicaciones que está disponible para

los servidores de datos sino también cómo es transmitida la información.

APLICACIONES

Page 21: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

Programa informáticos que permiten a un usuario utilizar una computadora con un

fin específico. Son parte del software de una computadora y suelen ejecutarse

sobre el sistema operativo.

¿Qué es un proveedor de servicios de aplicación?

El modelo de negocios Proveedor de Servicios de Aplicación o mas conocido en

ingles como ASP (Application Service Provider) permite a una organización utilizar

un software de aplicación bajo el concepto de servicio, sin la necesidad de

comprar licencias, equipos y otros activos, pagando sólo una cuota mensual.

El proveedor esta especializado en manejar volúmenes mas eficientes con costos

fijos consiguiendo una mayor calidad de servicio.

Las ventajas del modelo son muchas, entre las cuales podemos destacar:

Menores costos de implementación

Costos de mantenimiento predecible y acordado.

Ahorra la inversión inicial para construir la infraestructura requerida para correr las

aplicaciones.

No se requiere disponer de recursos técnicos para la implementación.

Rápida puesta en producción y con menor riesgo.

Mayor seguridad.

Mayor escalabilidad.

TRANSACCIONES

Una transacción es una interacción con una estructura de datos compleja

compuesta por varios procesos que se han de aplicar uno después del otro.

FIREWALL

es una parte de un sistema o una red que esta diseñada para bloquear el acceso

no autorizado permitiendo al mismo tiempo comunicaciones autorizadas

cortafuegos, mecanismo de seguridad en internet frente a acceso no autorizados.

RESUMEN

Page 22: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

Una arquitectura distribuida es una aplicación con distintos componentes que se

ejecutan separados, normalmente en diferentes plataformas conectadas. 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. Esta

arquitectura presenta 3 capas:

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.

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.

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.

La distribución de estas aplicaciones 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

Page 23: ARQUITECTURA DE APLICACIONES DISTRIBUIDAS

sistema.

Entre los servicios que ofrece están los servicios de email, web, base de datos,

aplicaciones, transacciones, sistemas operativos, firewall.

Referencia:

https://www.google.com.mx/#hl=es&output=search&sclient=psy-

ab&q=+ilustra+los+elementos+t%C3%ADpicos+que+suelen++aparecer+en+las+capas+de+negocios

.&oq=+ilustra+los+elementos+t%C3%ADpicos+que+suelen++aparecer+en+las+capas+de+negocios.

&gs_l=hp.3...3416.10452.0.11344.11.8.3.0.0.2.2537.8758.6-

3j1j0j2.6.0...0.0...1c.1.wkSSZk6QHgY&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=beac41d89eb66a4a

&bpcl=37189454&biw=1366&bih=662