LLAMADA A PROCEDIMIENTO REMOTO

LLAMADA A PROCEDIMIENTO REMOTO

RPC es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos.

El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los socketsusados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.

RPC

RPC es la transferencia sincrónica de datos y control entre dos partes de un programa distribuido a través de espacios de direcciones disjuntas. “La manera en que RPC logra hacer esto, es por medio de lo que se conoce como STUB. En el caso del STUBservidor, se conoce como SKELETON. Estos Stubs y Skeletons permiten que al momento de ser invocada la función remota esta pueda ser quot; simulada localmente quot .

Objetivos de RPC

·       Proporcionar un middelware que simplifique el desarrollo de aplicaciones distribuidas

·       Evitar que programador tenga que interactuar directamente con el interfaz de Sockets

·       Abstraer (ocultar) los detalles relativos a la red

·       El Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos locales

·       Se busca ofrecer un entorno de programación lo más similar posible a un entorno no distribuido.

·       El sistema RPC oculta los detalles de implementación de esas llamadas remotas Implementa la llamada remota mediante un dialogo petición respuesta -- Mensaje de petición: identifica procedimiento llamado, contiene parámetros de la llamada -- Mensaje de respuesta: contiene valor/es devuelto/s se encarga de enviar/recibir mensajes para comunicar ambas partes se encarga de gestionar los contenidos de esos mensajes (empaquetado y formateado de datos)

Diferencias con llamadas locales(LPC)

·       Punto clave: manejo de errores.

·       Con RPC pueden existir fallos en servidor remoto o en la red.

·       Acceso a variables globales y efectos laterales en el cliente no son posible

·       Procedimiento. Remoto (servidor) no tiene acceso al espacio de direcciones del cliente / imposibilidad de usar punteros.

·       RPC impone un mayor nivel de encapsulamiento

·       Los parámetros para la llamada remota no pueden pasarse por referencia (solo por valor).

·       Mayor sobrecarga en llamadas RPC (transferencia por red, aplanamiento de datos, etc.)

·       En algunos entornos se limita el intercambio de estructuras complejas, en otros se usan métodos de aplanado/desaplanado

El mecanismo de RPC

·       El stub del cliente: se encarga de empaquetar los parámetros y la solicitud, enviarlos al intermediario en el servidor, y luego esperar la respuesta, desempaquetarla y entregarla a la aplicación.

·       El programa principal del servidor (que incluye el stub y el dispatcher). se encarga de recibir peticiones, desempaquetar los parámetros, invocar la función solicitada, pasarle los parámetros, luego obtener el resultado, empaquetarlo y enviarlo al cliente.

·       Las rutinas de serialización de datos: Se debe tomar en cuenta que las máquinas cliente y servidor puedan ser de arquitectura diferente (y no compatible).

·       Servicio de binding: Responsable de la transparencia de localización, gestiona la asociación entre el nombre del procedimiento remoto (y su versión) con su localización en la maquina servidor (dirección, puertos, skeleton, etc). Realiza la búsqueda del skeleton de la implementación concreta del procedimiento remoto llamado por un cliente.

·        

Ejemplos:

·       portmapper en Sun-RPC

·       protocolo UDDI en servicios web

·       rmiregistry en Java-RMI.

Características del Stub

La base del mecanismo RPC consiste en la introducción de “representantes” que “hacen como si” fuesen el cliente/servidor

·       En el lado cliente, el representante del servidor se denomina Stub (o Proxy)

·       El stub es quien proporciona transparencia en la invocación del cliente

·       El stub debe poseer llamadas con la misma declaración (forma) que el servidor

·       El cliente invoca las llamadas del stub “como si” fuese el servidor

·       El stub, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al extremo remoto solicitando la “ejecución real” de la llamada

·       El stub, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto y recupera el “resultado” de la invocación.

·       El stub oculta los detalles de referencia del objeto remoto. Es decir, debe saber en qué dirección IP y en qué puerto hay que contactar con el extremo remoto

·       Cada procedimiento que el cliente quiera invocar a través de RPCs necesita su propio stub

Características del Skeleton

En el lado servidor, el representante del cliente se llama Skeleton

·       El skeleton es quien proporciona transparencia en el lado del servidor

·       El skeleton debe conocer las llamadas ofrecidas por el servidor

·       El skeleton, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto solicitando la “ejecución real” de la llamada

·       El skeleton invoca la llamada del servidor “como si” fuese el cliente

·       El skeleton, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al extremo remoto indicando el “resultado” de la invocación. Cada procedimiento que el servidor exporte a través de RPCs requiere su propio skeleton

La Interface

La interfaz que proporciona el servidor se refiere a la “forma” de las llamadas exportadas por el servidor Una interface es el principal acuerdo entre el componente de software y el cliente. El lenguaje de definición de interfaces (IDL) fue desarrollado para que los objetos en lenguajes diferentes puedan invocarse entre sí. Corba usa CORBA IDL, Sun propone XDR para su RPC, DCE usa su IDL para RPC, Microsoft usa DCOM IDL. Un punto interesante. Es si estos IDLs exponen las interfaces de manera tal que sean comprendidos por cualquier objeto invocante.

Funcionamiento del compilador de interfaces

La Interface de RPC Para la comunicación entre el servidor y el cliente, se trabaja con interfaces, que deben ser implementadas por el servidor y/o cliente, para que los STUBs puedan realizar la transparencia para ambos. Además esto evita que deba existir una definición local real de la clase remota, es decir, en el cliente solo debe estar definida la interface, no la clase remota

SISTEMA DE PROCESAMIENTO DE TRANSACCIONES

SISTEMA DE PROCESAMIENTO DE TRANSACCIONES

Transacción Según JAMRICH de 2008, es un intercambio entre dos partes que se registra y guarda en un sistema de equipos de cómputo. Como por ejemplo realizar una compra de mercancía o retirar efectivo de un cajero automático.

Los sistemas de procesamiento de transacciones (SPT) o (TPSs, sigla en inglés).

También conocido como EDP: Proceso Electrónico de Datos; es un sistema básico de negocios que dan servicio al nivel operativo de la organización, el cual “recopilar, procesar, guardar, exhibir, modificar o cancelar transacciones”, “recopila los datos de estas transacciones y los almacena en una base de datos. Los empleados usan la información de la base de datos para producir reportes y otras informaciones” como, estados de cuentas de los clientes, cheques de pago, pedidos de ventas, reservaciones en hoteles, la nómina y para escoger elementos (cliente por dirección, productos por región), estos son eventos cotidianos.  “Son datos rápidamente alterables pero muy poco variados, lo que hace que los procedimientos para gestionarlos puedan ser descritos con precisión. Estas características hicieron que fuera posible diseñar e implementar rutinas que se encargasen de estos trabajos repetitivos, lo que dio lugar a este tipo de sistemas”

Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro delos sistemas de base de datos, donde se usaba para auxiliar en el mantenimiento de los datos de las aplicaciones y que dependían de la consistencia de la información almacenada.

Las transacciones son un mecanismo que ayuda a simplificar la construcción de sistemas confiables a través de procesos que proveen soporte uniforme para invocar y sincronizar operaciones como:

·         Operaciones de compartición de datos.

·         Aseguramiento de la seriabilidad de las transacciones con otras.

·         Atomicidad en su comportamiento.

·         Recuperación de fallas provocadas en red y nodos.

El término transacción describe una secuencia de operaciones con uno o más recursos (por ejemplo una base de datos) que transforman su estado actual en un nuevo estado de consistencia

MOTIVOS DEL USO DE TRANSACCIONES

Los sistemas distribuidos son potencialmente muy fiables debido a la posibilidad de proveer redundancia y autonomía de recursos en diferentes nodos, esto permite detectar y localizar fallas, sin embargo comúnmente tenemos varios aspectos que representan problemas para la integridad de los recursos y que a su vez motivan el uso de transacciones:

1. Dificultad para mantener consistencia en los datos.

2. Una misma vía de comunicación no siempre puede ser utilizada para proveer interacción entre 2 procesos.

3. Requerimientos de procesamiento en paralelo.4. Manejo interactivo de uno o más usuarios

OBJETIVO

El objetivo de este sistema es, aumentar la productividad en tareas de tipo administrativo y capturar los datos relativos a las transacciones realizadas por la empresa con el fin de controlar las actividades del negocio.

PROPIEDADES DE LOS SISTEMAS TRANSACCIONALES

·         Automatizan tareas operativas en una organización, permitiendo ahorrar en personal.

·         Suelen dirigirse especialmente al área de ventas, finanzas, marketing, administración y recursos humanos.

·         Suelen ser los primeros sistemas de información que se implementan en una organización.

·         Sus cálculos y procesos suelen ser simples.

·         Se suelen utilizar para cargar grandes bases de datos.

·         Los beneficios de este tipo de sistemas en una organización son rápidamente visibles.

·         Estos sistemas son optimizados para almacenar grandes volúmenes de datos, pero no para analizar los mismos.

PROPIEDADES PARA QUE LA INFORMACIÓN SEA VALIDA

Para asegurar la integridad de la información de la base de datos es que debe ser completamente procesada la transacción. Según GOMEZ DE SILVA y ANIA BRISEÑO (2008) Existe también una teoría del procesamiento de transacciones (test ACID), que incluyen acciones a seguir para garantizar que el trabajo del usuario no interfiera con el otro. Las transacciones deben observar cuatro propiedades para asegurar que la información de una base de datos sea válida:

·         Atomicidad: que la transacción se debe ejecutar totalmente o no ejecutarse en absoluto.

·         Conservación de la coherencia: una ejecución correcta de la transacción debe llevar a la base de datos de un estado coherente a otro estado coherente (válido)

·         Aislamiento: Una transacción no debe hacer visibles sus actualizaciones de la base de datos a otras transacciones sino hasta que haya sido confirmada (terminada por completo).

·         Durabilidad: una vez que una transacción cambie a la base de datos y los cambios sean confirmados, éstos nunca deben perderse por fallas subsecuentes.

SISTEMAS DE ARCHIVOS DISTRIBUIDOS

El sistema de archivos es un elemento esencial de un sistema distribuido Su tarea fundamental es almacenar los programas y datos y tenerlos disponibles cuando sean necesarios. Nos centraremos en analizar los aspectos que los diferencían de los sistemas de archivos centralizados.

Es importante distinguir entre los conceptos de servicio de archivos y servidor de archivos.

El servicio de archivos especifica la interfaz del sistema de archivos con los clientes. Describe las primitivas disponibles, los parámetros que utilizan y las acciones que llevan a cabo.

Un servidor de archivos es un proceso que se ejecuta en alguna máquina y ayuda a implantar el servicio de archivos. Un sistema puede tener uno o varios servidores de archivos, pero los clientes no deben conocer el número de servidores de archivos, su posición o función. Todo lo que saben es que, al solicitar un servicio, éste se lleva a cabo de alguna manera.

Diseño

Generalmente un sistema de archivos distribuidos (DFS) tiene dos componentes: el servicio de archivos y el servicio de directorios.  

 

INTERFAZ DEL SERVICIO DE ARCHIVOS

Un archivo es una secuencia de bytes con algún significado especial para el usuario.

Un archivo puede tener atributos, que son partes de información relativas a él, pero que no son parte del archivo propiamente dicho (propietario, tamaño, fecha de creación, permisos de acceso, etc.). Generalmente el servicio de archivos proporciona primitivas para leer y escribir alguno de los atributos.

En algunos sistemas de archivos se maneja el concepto de inmutabilidad, que consiste en que un archivo sólo puede ser creado y leído, pero no modificado. Esto facilita el soporte del ocultamiento y la replicación de archivos, puesto que se eliminan los problemas de actualización de copias remotas.

Los servicios de archivos se pueden dividir en dos tipos, según si soportan un modelo de carga/descarga o un  modelo de acceso remoto. 

En el modelo de carga/descarga, el servicio de archivos proporciona dos operaciones principales: lectura de archivo y escritura del mismo. La lectura transfiere todo el archivo de los servidores de archivos al cliente solicitante. La escritura transfiere todo el archivo del cliente de regreso al servidor. El modelo conceptual es el traslado de archivos completos en alguna de las direcciones. La interfaz es sencilla, y la transferencia completa de archivos es muy eficiente.

El modelo de acceso remoto se proporciona un gran número de operaciones para abrir y cerrar archivos, leer y escribir partes de archivos, moverse a través de un archivo (lseek), etc. Aquí el sistema de archivos se ejecuta en los servidores y nunca se trasladan los archivos a los clientes. Su ventaja es que no necesita mucho espacio en los clientes y la cantidad de información transferida es mínima.

INTERFAZ DEL SERVICIO DE DIRECTORIOS

El servicio de directorios proporciona las operaciones para crear, eliminar directorios, nombrar o cambiar archivos dentro de directorios, y mover archivos de un directorio a otro. Los directorios pueden contener subdirectorios y éstos también pueden contener subdirectorios, lo que se conoce como sistema jerárquico de archivos o árbol de directorios.

En ciertos sistemas es posible crear enlaces o apuntadores a un directorio arbitrario desde cualquier directorio, con lo que se pueden crear grafos arbitrarios, que son más poderosos que los árboles. La distinción entre árboles y grafos es de particular importancia en sistemas distribuidos. 

  

Ejemplo de árbol de directorios y grafo de directorios 

 

En la gráfica anterior se muestra en ejemplo de cómo se pueden tener directorios que abarquen más de un servidor de archivos.

Cada servidor tiene una estructura de directorios local que se enlaza con la estructura de otro servidor. Es posible que cada servidor vea globalmente una estructura distinta y este es un problema si se desea que los clientes vean una referencia a los archivos del tipo //servidor/ruta, ya que debe reconocerse que el directorio raíz está en alguno de los servidores en particular, y la estructura de directorios que éste ve es la que verán todos los clientes.

Uno de los principales problemas de este tipo de estructura es que no se tiene una transparencia referencial o de nombres, ya que es necesario conocer el nombre del servidor para poder alcanzar un archivo, lo que impide que el servidor pueda migrarse dinámicamente.

Generalmente se puede atacar este problema con tres formas diferentes de nombrar los archivos y directorios: 

1.       Nombre de máquina + ruta de acceso [p.e.: //Servidor1/archivos/datos/textos/x1.txt - Windows]

2.       Montaje de sistemas de archivos remotos en la jerarquía local de archivos [p.e.: NFS]

3.       Un espacio de nombres que tenga la misma apariencia en todas las máquinas

Los dos primeros son fáciles de implantar en sistemas centralizados que se convierten en distribuidos. El tercero es la manera ideal en que se comporta un sistema distribuido .
  

SEMÁNTICA DE ARCHIVOS COMPARTIDOS

Uno de los principales problemas al manejar archivos en forma distribuida se refiere a cómo se reflejan los eventos de lectura y escritura en un archivo a todos los clientes (semántica de la lectura y escritura). Podemos considerar cuatro formas básicas de compartir archivos en un sistema distribuido: 

  
  OCULTAMIENTO

Para facilitar el desempeño en el acceso a los archivos distribuidos pueden utilizarse técnicas que permitan ocultar los retrasos normales en la transferencia de archivos entre las diferentes máquinas. Este ocultamiento se logra con el uso de cachés en sus diferentes formas.

Existen cuatro lugares donde se pueden almacenar archivos o partes de archivos: El disco del servidor, la memoria principal del servidor, el disco del cliente o la memoria principal del cliente:

Características de cada opción: 

  

EL MODELO CLIENTE – SERVIDOR

EL MODELO CLIENTE – SERVIDOR

TCP es un protocolo orientado a conexión. No hay relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo cliente/servidor en las comunicaciones.

Un servidor es una aplicación que ofrece un servicio a usuarios de Internet; un cliente es el que pide ese servicio. Una aplicación consta de una parte de servidor y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas.

Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como transporte.

El servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar múltiples peticiones (múltiples clientes) al mismo tiempo.

Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes saben a que zócalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qué puerto dirigirse. Este mecanismo podría usar un servicio de registro como Portmap, que utiliza un puerto bien conocido.

CARACTERÍSTICAS

En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:

·       Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).

·       Espera y recibe las respuestas del servidor.

·       Por lo general, puede conectarse a varios servidores a la vez.

·       Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus características son:

·       Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).

·       Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.

·       Por lo general, acepta las conexiones de un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).

En la arquitectura C/S sus características generales son:

·       El Cliente y el Servidor pueden actuar como una sola entidad y también pueden actuar como entidades separadas, realizando actividades o tareas independientes.

·       Las funciones de Cliente y Servidor pueden estar en plataformas separadas, o en la misma plataforma.

·       Cada plataforma puede ser escalable independientemente. Los cambios realizados en las plataformas de los Clientes o de los Servidores, ya sean por actualización o por reemplazo tecnológico, se realizan de una manera transparente para el usuario final.

·       La interrelación entre el hardware y el software están basados en una infraestructura poderosa, de tal forma que el acceso a los recursos de la red no muestra la complejidad de los diferentes tipos de formatos de datos y de los protocolos.

·       Su representación típica es un centro de trabajo (PC), en donde el usuario dispone de sus propias aplicaciones de oficina y sus propias bases de datos, sin dependencia directa del sistema central de información de la organización.

Los servidores pueden ser apátridas o stateful. Un servidor apátrida no guarda ninguna información entre las peticiones. Un servidor stateful puede recordar la información entre las peticiones. El alcance de esta información puede ser global o sesión-específico. Un servidor del HTTP para las páginas estáticas del HTML es un ejemplo de un servidor apátrida mientras que Apache Tomcat es un ejemplo de un servidor stateful.

La interacción entre el cliente y el servidor se describe a menudo usando diagramas de secuencia. Los diagramas de secuencia se estandarizan en el UML. Es importante que los clientes no interactúen entre sí ni que lo hagan clientes de capas bajas hacia otros de capas más altas, por eso todo tiene que pasar por el servidor.

Otro tipo de arquitectura de red se conoce como arquitectura del par-a-par porque cada nodo o caso del programa es un “cliente” y un “servidor” y cada uno tiene responsabilidades equivalentes. Ambas arquitecturas están en uso amplio. 

ARQUITECTURA CLIENTE-SERVIDOR 

La Arquitectura Cliente-Servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada usuario.

• ·        TELEPROCESO

Este aparece con la finalidad de compartir información y recursos con usuarios, la estructura de este es que su conexión es en paralelo para todos los usuarios, además tiene terminales tontos. Cuenta con un solo servidor en el cual está la memoria y solo el gestiona la información y las aplicaciones.

Ventajas:

• -       Seguros
• -       Rápidos
• -       Proceso local
• -       Conectividad eficiente

Desventajas:

• -       Infraestructura limitada
• -       Dependencia del servidor
• -       Costos elevados tanto como dinero y trabajo

-        

• ·        SERVIDOR DE ARCHIVOS

El servidor de archivo, aparecen con estaciones de trabajo esto quiere decir que los usuario ya puede manipularla información, claro está que deben tener privilegios. Cuentan con aplicaciones destinadas para cada usuario de acuerdo al trabajo que desempeñen, los documentos pueden ser compartidos y pueden manipularlos varias personas.

Ventajas:

• -       Menor costo de servidores
• -       Servicio local
• -       Mejor Rapidez
• -       Aplicaciones Robustas

Desventajas:

• -       Mayor Inversión de infraestructura
• -       Actualización de aplicaciones
• -       Problema en la red

-        

• ·        CLIENTE SERVIDOR

Sistema donde el cliente es una máquina que solicita un determinado servicio y se denomina servidor a la máquina que lo proporciona. Los servicios pueden ser: Ejecución de un determinado programa, Acceso a un determinado banco de información, Acceso a un dispositivo de hardware.

El servidor presenta a todos sus clientes una interfaz única y bien definida, existen varios servidores:

• -       Servidores de Software de Grupo.- El software de grupo es aquel, que permite organizar el trabajo de un grupo. El servidor gestiona los datos que dan soporte a estas tareas. Por ejemplo: almacenar las listas de correo electrónico. El Cliente puede indicarle, que se ha terminado una tarea y el servidor se lo envía al resto del grupo.
• -       Servidores WEB.- Son los que guardan y proporcionan Páginas HTML. El cliente desde un browser o link hace un llamado de la página y el servidor recibe el mensaje y envía la página correspondiente.
• -       Servidores de correo.- Gestiona el envío y recepción de correo de un grupo de usuarios (el servidor no necesita ser muy potente). El servidor solo debe utilizar un protocolo de correo.
• -       Servidor de objetos.- Permite almacenar objetos que pueden ser activados a distancia. Los clientes pueden ser capaces de activar los objetos que se encuentran en el servidor.
• -       Servidores de aplicación.- Se dedica a una única aplicación. Es básicamente una aplicación a la que pueden acceder los clientes.

-       El Cliente es Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores.

Características:

• -       El Cliente oculta al Servidor y la Red.
• -       Detecta e intercepta peticiones de otras aplicaciones y puede redireccionarlas.
• -       Dedicado a la cesión del usuario (Inicia...Termina).
• -       El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls).

-       Funciones Comunes del Cliente:

• -       Mantener y procesar todo el dialogo con el usuario.
• -       Manejo de pantallas.
• -       Menús e interpretación de comandos.
• -       Entrada de datos y validación.

-       Procesamiento de ayudas.

-       Recuperación de errores.

A continuación mostramos las arquitecturas cliente-servidor más populares:

• ·        Arquitectura Cliente-Servidor de Dos Capas.- Consiste en una capa de presentación y lógica de la aplicación; y la otra de la base de datos. La primera capa encapsula la presentación y la lógica, la segunda gestiona el almacenamiento y puede almacenar parte de la lógica (procedimientos almacenados, triggers). Normalmente esta arquitectura se utiliza en las siguientes situaciones:

• -       Cuando se requiera poco procesamiento de datos en la organización.
• -       Cuando se tiene una base de datos centralizada en un solo servidor.
• -       Cuando la base de datos es relativamente estática.
• -       Cuando se requiere un mantenimiento mínimo.

• ·        Arquitectura Cliente-Servidor de Tres Capas- Consiste en una capa de la Presentación, otra capa de la lógica de la aplicación y otra capa de la base de datos. Agrega una capa intermedia (middle tier) que permite priorizacion y gestión de peticiones de balances. Normalmente esta arquitectura se utiliza en las siguientes situaciones:

• -       Cuando se requiera mucho procesamiento de datos en la aplicación.
• -       En aplicaciones donde la funcionalidad este en constante cambio.
• -       Cuando los procesos no están relativamente muy relacionados con los datos.
• -       Cuando se requiera aislar la tecnología de la base de datos para que sea fácil de cambiar.
• -       Cuando se requiera separar el código del cliente para que se facilite el mantenimiento.
• -       Está muy adecuada para utilizarla con la tecnología orientada a objetos.