Monday, September 19, 2005

Arquitecturas Multi Tier

Arquitecturas Client-Server

Es una arquitectura de red en la cual cada computadora o proceso en la red puede ser un cliente o servidor. Los servidores son poderosas computadoras  dedicadas al manejo de discos, printers o tráfico en la red. Los clientes son Pcs o workstations en los cuales los usuarios corren aplicaciones.

Otro tipo de arquitectura es conocida como peer-to-peer. En esta arquitectura cada nodo tiene una responsabilidad equivalente.

Las arquitecturas cliente-servidor algunas veces son llamadas arquitecturas two-tier.
Introduccion a las Arquitecturas
Traditional 2-Tier Model
El tradicional modelo Two-tier consiste en un cliente que tiene acceso a una base de datos directamente.
Figure 1: Traditional 2-tier Application
(image placeholder)
En esta arquitectura tradicional, todo el procesamiento lo hace  la aplicacion del cliente, los servidores de base de datos solo almacenan los datos.
La ventaja principal:
  1. Familiar: la arquitectura es familiar y simple de crear. En particular, es similar al tradicional mainframe program donde el programa tiene todo lo lógico y acceda los datos mientras se necesita.

  2. Accesible: muchas herramientas pueden solo trabajar con modelos two-tiers. Ejemplo: herramientas de reporte.

  3. Productivo: muchas herramientas avanzadas tienen una optimizacion especial que significa menos esfuerzo requerido cuando se trabaja con esta arquitectura.(vb,delphi, etc)

  4. Pruebas: 2-tier model esta probado y se entiende muy bien.
Aplicaciones con las siguientes atributos son bien acojidas por esta arquitectura.
  1. Las aplicaciones en las que se espera un numero limitado de usuarios.(no mas de unos cientos)

  2. La aplicacion tiene acceso a la red con base de datos local.

  3. Un normal nivel de seguridad requerido.

  4. El acceso desde aplicaciones externas es minimo.
Las desventajas son:
  1. Escabilidad: El desempeño de la aplicacion se puede degradar rapidamente cuando un numero grande de personas traten de utilizar la aplicación, sin importar el tamaño de la base de datos. La razon por la que ocurre esto es porque cada cliente requiere su propia coneccion y cada coneccion requiere memoria del CPU. Mientras el numero de conecciones incrementa, el desempeño de la base de datos se degrada.

  2. Pobre compartimiento logico: La tradicional arquitectura two-tier maneja la logica del negocio en el cliente. Cuando la logica esta en el cliente, es usualmente mas difícil re-usar la lógica entre aplicaciones y herramientas.

  3. Distribución de la Aplicaron: Los cambios entre las aplicaciones tienen que ser distribuidos entre las aplicaciones. When there are a large number of users, this entails considerable administrative overhead.

  4. Uso remoto: usuarios remotos, probablemente no queran instalar tu aplicacion en sus clients, prefieren clients ligeros o requerimiento de software es minimo.

  5. Esctructura de base de datos: otros aplicaciones que acceden tu base de datos se convertirán en dependientes en la existente estructura de datos. Esto quiere decir que va hacer mas difícil rediseñar la base de datos ya que otras aplicaciones estan íntimamente ligadas con la estructura de datos.

Modified 2-tier Model
Un acercamiento para mejorar la reusabilidad de logica de negocio es poner la logica de negocio en trugger o store procedures en la base de datos. Las validaciones son realizadas por la llamada del store procedure apropiado. In addition, dependent logic can be initiated by a trigger in the database. For example, the business logic might dictate that whenever a requisition is updated to "approved", a purchase order should automatically be created. This business rule could be effectively implemented with a database trigger on the requisition table.
Este acercamiento prove algunas ventajas comparandolas con el tradicional modelo de two tier:
  1. Mayor Re-uso: La misma logica(en triggers y store procedures) puede ser inicializada desde muchas aplicaciones y herramientas.

  2. Mejor integridad de los datos: cuando es incondicional una validación logica. database triggers (e.g. before inserts and updates), then business integrity of the data can be ensured.

  3. Mejora en el desempeño de validaciones complejas: cuando la logica del negocio requiere mucho acceso(ir y venir) a la base de datos para realizar operaciones, el trafico de la red se reduce considerablemente cuando la validación es encapsulada en un strore procedure.

  4. Mejoras en la seguridad: stored procedures pueden mejorar la seguridad, ya que la logica del negocio esta encapsulada en las de un secure central server.

  5. Reduccion de la distribución: cambios en la logica del negocio solo se necesitara ser actualizada en la base de datos.
The modified 2-tier aun hay problemas con la escabilidad
Pure 3-Tier / N-Tier Model
En el modelo de 3-tier/n-tier, la aplicacion es dividida en tres niveles: el nivel de presentacion(GUI), el nivel intermedio(aplication server) y el nivel de data. La nueva mejora de este modelo es la adicion del aplication Server el cual encapsula la logica del negocio (see sidebar on business logic). N-tier es usado para describir esta arquitectura ya que el aplication Server puede estar implementado en uno o mas layers y puede ser distribuido en uno o mas lugares. For simplicity, the architecture will simply be referred to as "3-Tier", rather than N-Tier.
Figure 2: Pure 3-Tier/N-Tier Model
(image placeholder)
Presentation Tier
El nivel de presentacion puede incluir una variedad de clients incluyendo clients standar (como parte del cliente/Server aplication), Clientes de Internet y herramientas de reporte. Ya que la logica del negocio esta implementada en el nivel intermedio.
Middle Tier (Application Server)
Como mencionamos anteriormente  el application server puede ser implementado en varias capas. Tambien puede ser distribuido en varios host machines. El Transaction Processing (TP) monitor or an Object Request Broker (ORB) puede ser utilizado para balancear las peticiones de clientes a traves de multiples servidores de base de datos, tambien como start up/shutdown adicionales instancias de aplication Server. Como el aplication Server contiene la logica del negocio, es posible que soporte mas usuarios agregando aplicaciones server mas rapidas sin tener la necesidad de re-diseñar o la aplicacion.
No es necesario tener el middle tier en su propio servidor desde el principio. En un temprano lanzamiento de una aplicación, the middle tier puede deploy en el clien machina o en el servidor de base de datos para simplicidad. Cuando el numero de clientes cresca, el middle tier puede moverse a un servidor aparte.
Data Tier
El data tier contiene la base de datos. Puede que contenga tambien data access procedures. La base de datos puede ser colocada en un simple locacion o puede ser distribuida, si es necesario.
Los beneficios del modelo 3 tier :
  1. Escabilidad: el punto importante de este modelo es mejorar la escabilidad ya que la aplicacion server puede deploy on many machines. Tambien, la base de datos ya no requiere una coneccion de cada usuario, solo requiere conexiones de pequeñas numeros de aplication servers. En adicion, TP monitors or ORBs pueded ser usado para balancear la carga y manejar dinámicamente el numero de aplicion servers disponibles.

  2. Mejor Re-uso: La misma logica puede ser inicializada desde muchos clientes o aplicaciones. Si un objeto COM/DCOM or CORBA is employed (as discussed in tool dependence), entonces el lenguaje especifico de implementacion del middle tier puede hacerce transparente.

  3. Integridad de los datos: Ya que todas las actualizaciones se dan en el middle tier, esta puede asegurar  que solo datos validos van hacer actualizados en la base de datos the risk of a rogue client application corrupting data is removed.

  4. Seguridad: se puede implementar en multiples niveles (no solo base de datos). Security can be granted on a service-by-service basis. Ya que el cliente no tiene acceso directo a la base de datos, es mas dificil que el cliente obtenga datos no-autorizados. De este modo la logica del programa esta mas segura.

  5. Reducir la Distribucion: Cambios a la logica del programa solo se necesita que se actualice en el application server y no tiene que ser distribuidas a todos los clients.

  6. Estructura de datos Oculta: ya que la estructura de la base de datos esta escondida, es posible que los cambios a la base de datos sean transparentes. De esta forma las aplicaciones pueden retener su interfase original.
The drawbacks of the 3-tier model are as follows:
  1. Complejidad: En general, es mas dificil construer una 3 tier application comparada con la de 2 tier. Los puntos de comunicación se duplican( del cliente al middle tier al Server, en ves de cliente -server) and many handy productivity enhancements provided by client tools (e.g. Visual Basic, PowerBuilder, Delphi) will be foregone or their benefit will be reduced with a 3-tier architecture.

  2. Menos Herramientas: hay mas herramientas disponibles para la arquitectura de 2 tier(reportes). It is likely that additional programming effort will be required to manage tasks that an automated tool might handle in a 2-tier environment.
Hybrid 2-tier / 3-tier model
La complejidad del modelo de 3 tier no se puede pasar por alto. En muchos ambientes, ciertos beneficios del modelo de 3 tier son requeridos. Hay que considerar situaciones como:
  1. El bulto de mantenimiento de los datos esta hecho por un grupo pequeño de usuarios.

  2. Un gran numero de usuarios  hay que darle soporte, especialmente los de internet.

  3. Otras aplicaiones necesitan intercambiar información  con esta aplicacion.

  4. Algunos usuarios necesitan acceso directo a los datos para poder usar herramientas especiales.(reportes)
Para suplir estos requerimientos, un modelo hibrido 2tier/3tier se puede implementar. En esta situación, el bulto de datos
Para resolver estos requisitos, un híbrido 2-tier/el modelo 3-tier podría ser empleado (véase el cuadro 3). En esta situación, el bulto de los usuarios utilizaría clientes del Internet y/o extremos delanteros client/server simples para tener acceso a datos a través de los servidores del uso (véase la tapa del centro del cuadro 3) -- el acceso a través de los servidores del uso proporciona las ventajas del scalability. Semejantemente, los usos relacionados intercambiarían datos a través de los servidores del uso (la derecha superior del cuadro 3) de modo que su interfaz pudiera ser manejado mejor.                                                            
Figure 3: Hybrid 2-Tier / 3-Tier with Replicated Database
(image placeholder)


El bulto de logica, sin embargo, seria construido usando un modelo 2 tier. Esto permitira que las muchas optimizaciones cliente/servidor de la productividad de la herramienta fueran logradas. El desarrollo 2 tier es tambien mas facil de manejar.
Un aspecto notable de este modelo es una base de datos replegada(RETRIEVAL: Los datos redundantes y resumidos). Esta base de datos de la recuperacion se puede utilizar para satisfacer ciertas peticiones de los Application Server. Tambien seria el lugar ideal para que los usuarios tengan aceeso a datos con  herramientas de reporte.
Dependencia de la herramienta bajo estos modelos
Un problema comun cuando construimos una aplicación es la necesidad de evitar que sea excesivamente dependiente en las herramientas específicas (Visual Basic or Oracle RDBMS) porque estas herramientas pueden ser remplazadas en el futuro.               
Dependencia de la herramienta por Arquitectura.          




















En la tradicional aplicación de 2-tier, la presentación y la lógica del negocio se pone en la herramienta del cliente. Por esta razón, la aplicacion es altamente dependiente en la herramienta del cliente – una aplicación reescribe su esencia requerida si la herramienta del cliente es cambiada. Por otra parte, si el ANSI estándar SQL se utiliza para tener acceso a la base de datos en un uso tradicional 2-tier, entonces debe ser relativamente fácil cambiar a una diferente base de datos.
En el modificado modelo 2-tier, los trigger y los stored procedures se utilizan extensivamente para la lógica del negocio. Puesto que los trigger y los stored procedures son propietarios a cada vendedor de la base de datos, sería difícil cambiar bases de datos (sin reescrituras importantes). Aunque restringen al cliente a la presentación en este modelo, un esfuerzo moderado sería requerido de virar las muchas ventanas, controles, etc. a la nueva herramienta de cliente. En general, cambiar la herramienta del cliente en este modelo debe requerir perceptiblemente menos esfuerzo que una reescritura total de la aplicación.
En una aplicación de 3-tier, el esfuerzo considerable se pone en mantener lógica del negocio en el middle tier or application server. Si el ANSI estándar SQL se utiliza para tener acceso a la base de datos (y a la lógica del trigger se reduce al mínimo), entonces debe ser relativamente fácil cambiar de base de datos. Un cambio de la herramienta del cliente requeriría una cantidad justa de esfuerzo (como el modelo  modified 2-tier) pero el cambio debe requerir mucho menos esfuerzo que una reescritura total de la aplicacion.
¿este medio que 3-tier logra la "independencia deseada de la herramienta"? No. La lógica del negocio se escribe en el lenguaje middle tier (de la cual pudo incluir una o más: C, C++, Java, VB/ActiveX, PowerBuilder distribuido, etc.). Si se cambia el lenguaje middle tier, entonces la logica del middle tier se debe reescribir en el nuevo lenguaje. Afortunadamente, cuando el middle tier se desarrolla dentro de un paradigma estándar de la petición del objeto (e.g. COM/DCOM o CORBA), los cambios del lenguaje middle tier se pueden realizar transparente a las aplicaciones del cliente o del solicitante.

0 Comments:

Post a Comment

<< Home