Hola de nuevo queridos lectores y seguidores...en esta ocasion les presentamos las diversas estructuras en las que podemos implementar la arquitectura Cliente-Servidor, cada modelo tiene inscritas sus ventajas y desventajas espero les guste!
Modelo mono-capa
Entendemos por aplicaciones mono-capa, aquellas que tanto la propia aplicación como los datos que maneja se encuentran en la misma máquina y son administradas por la misma herramienta: podríamos decir que son una sola entidad
Figura 1. Arquitectura Típica de una aplicación de una sola capa.
Entendemos por aplicaciones mono-capa, aquellas que tanto la propia aplicación como los datos que maneja se encuentran en la misma máquina y son administradas por la misma herramienta: podríamos decir que son una sola entidad
Figura 1. Arquitectura Típica de una aplicación de una sola capa.
Modelo En Dos Capas (Two-Tier Model)
En una arquitectura cliente/servidor clásica tenemos dos "capas" (two-tier):
Una donde está el cliente que implementa la interface.
Otra donde se encuentra el gestor de bases de datos que trata las peticiones recibidas desde el cliente.
La lógica de la aplicación se encuentra por tanto repartida entre el cliente y servidor.
Un ejemplo de esta configuración podría ser un applet Java que se carga en el navegador del cliente y trabaja directamente con la base de datos mediante JDBC.
Figura A: Esquema de arquitectura Cliente/Servidor clásica.
Ventajas de este modelo:
o Se mantiene una conexión persistente con la base de datos.
Se minimizan las peticiones en el servidor trasladándose la mayor parte del trabajo al cliente.
Se gana en rendimiento gracias a la conexión directa y permanente con la base de datos. A través de una única conexión se realiza el envío y recepción de varios datos.
Inconvenientes:
o La más importante desventaja, es que esta solución es muy dependiente del tipo controlador JDBC que se utilice para acceder a la base de datos. El acceso se realiza desde el cliente y esto significa que es él el que tiene que tener instalado en su sistema los controladores necesarios para que se produzca la comunicación con la base de datos.
Además hay que tener en cuenta que el modelo de seguridad de Java impide que desde un applet sin validar (lo que se conoce como untrusted applet), como lo son la mayoría de los que se ejecutan en un navegador, se puedan realizar las siguientes operaciones:
1. El acceso general, y por supesto mediante JDBC, a bases de datos situadas en direcciones URL distintas a las que procede el mismo applet.
La configuración de recursos locales como, por ejemplo, la información de la fuente de datos ODBC para usar el puente JDBC-ODBC.
La descarga de clases nativas, es decir, aquellas cuyo nombre empieza por Java. Esta restricción afecta directamente a los navegadores que utilizan JDK 1.0.2 o anterior, pues JDBC es posterior a esta versión, de forma que las clases apropiadas no estarán instaladas localmente ni podrán ser descargadas de Internet por el applet.
o Finalmente debemos tener en cuenta que es bien conocido que los programas Java pueden ser descompilados muy fácilmente con lo que introducir el acceso a nuestras bases de datos mediante un applet Java conlleva un riesgo considerable en cuanto a la seguridad.
Modelo en Tres Capas (Three-Tier Model)
Con la arquitectura cliente/servidor en tres capas (three-tier) añadimos una nueva capa entre el cliente y el servidor donde se implementa la lógica de la aplicación. De esta forma el cliente es básicamente una interface, que no tiene por qué cambiar si cambian las especificaciones de la base de datos o de la aplicación; queda aislado completamente del acceso a los datos.
Así un applet de Java se carga en el navegador del cliente y se comunica con un servlet que corre en la máquina servidor; o bien accedemos a la base de datos a través de un formulario HTML. El servlet establece una conexión a la base de datos mediante JDBC.
En este caso se tiene total libertad para escoger dónde se coloca la lógica de la aplicación: en el cliente, en el servidor de base de datos, o en otro(s) servidor(es). También se tiene total libertad para la elección del lenguaje a utilizar.
Se utiliza un lenguaje de tipo general (probablemente C) por lo que no existen restricciones de funcionalidad.Los programas serán óptimos desde el punto de vista de la performance.
También deberá implementarse especialmente el Call remoto, lo que seguramente se hará de una forma más libre que los Remote Procedure Call actualmente disponibles.
No existe compromiso alguno con el uso de lenguajes propietarios, por lo que las aplicaciones serán totalmente portables sin cambio alguno.
Puede determinarse en qué servidor(es) se quiere hacer funcionar estos procedimientos. En aplicaciones críticas se pueden agregar tantos servidores de aplicación como sean necesarios, de forma simple, y sin comprometer en absoluto la integridad de la base de datos, obteniéndose una escalabilidad muy grande sin necesidad de tocar el servidor de dicha base de datos.
El problema de esta arquitectura es ¿cómo se implementa?. Parece ilusorio tratar de programar manualmente estos procedimientos, mientras que, si se dispone de una herramienta que lo hace automáticamente, presenta ventajas claras sobre la alternativa anterior:
Figura B: Arquitectura Cliente/Servidor en tres capas (three-tier)
Como se podría esperar cada uno de los componentes de la aplicación en una arquitectura three-tier se separa en una sola entidad. Esto te permite implementar componentes de una manera más flexible. Algo que no creo que sorprenda es la afirmación de que este tipo de arquitectura es la más compleja.
Figura 4. Arquitectura Three-Tier.
En esta Arquitectura todas las peticiones de los clientes se controlan en la capa correspondiente a la lógica del negocio. Cuando el cliente necesita hacer una petición se la hace a la capa en la que se encuentra la lógica del negocio. Esto es bastante importante pues eso quiere decir que:
1.- El cliente no tiene que tener drivers ODBCni la problemática consiguiente de instalación de los drivers por tanto se reduce el costo de mantener las aplicaciones cliente
2.- El Cliente y el Gestor de Reglas de negocio tienen que hablar el mismo lenguaje (en nuestro caso COM)
3.- El Gestor de Reglas de Negocio y el Servidor de Datos tienen que hablar el mismo lenguaje (en nuestro caso ODBC)
Lo ideal sería que el Gestor de Reglas de Negocio no sólo OLE y ODBC sino otros estandares como DBLib, OLI, DRDA, SQL/API y X/Open
Ventajas de este modelo:
o No existe ningún problema con respecto al tipo de controlador JDBC utilizado para acceder a la base de datos.Todos los recursos necesarios para establecer la conexión con la base de datos se encuentran en el servidor y por tanto, el cliente no necesita instalar nada adicional en su máquina para poder acceder a la base de datos.
Esta arquitectura proporciona considerables mejoras desde el punto de vista de la portabilidad de la aplicación, escalabilidad, robustez y reutilización del código. Asimismo facilita las tareas de migración o cambios en el sistema gestor de la base de datos.
Desaparecen las restricciones debidas a las limitaciones de los applets impuestas por el modelo de seguridad de Java.
Inconvenientes:
o Esta solución es algo menos eficiente que la del modelo de dos capas, ya que hemos añadido una capa intermedia más de software.
En una arquitectura cliente/servidor clásica tenemos dos "capas" (two-tier):
Una donde está el cliente que implementa la interface.
Otra donde se encuentra el gestor de bases de datos que trata las peticiones recibidas desde el cliente.
La lógica de la aplicación se encuentra por tanto repartida entre el cliente y servidor.
Un ejemplo de esta configuración podría ser un applet Java que se carga en el navegador del cliente y trabaja directamente con la base de datos mediante JDBC.
Figura A: Esquema de arquitectura Cliente/Servidor clásica.
Ventajas de este modelo:
o Se mantiene una conexión persistente con la base de datos.
Se minimizan las peticiones en el servidor trasladándose la mayor parte del trabajo al cliente.
Se gana en rendimiento gracias a la conexión directa y permanente con la base de datos. A través de una única conexión se realiza el envío y recepción de varios datos.
Inconvenientes:
o La más importante desventaja, es que esta solución es muy dependiente del tipo controlador JDBC que se utilice para acceder a la base de datos. El acceso se realiza desde el cliente y esto significa que es él el que tiene que tener instalado en su sistema los controladores necesarios para que se produzca la comunicación con la base de datos.
Además hay que tener en cuenta que el modelo de seguridad de Java impide que desde un applet sin validar (lo que se conoce como untrusted applet), como lo son la mayoría de los que se ejecutan en un navegador, se puedan realizar las siguientes operaciones:
1. El acceso general, y por supesto mediante JDBC, a bases de datos situadas en direcciones URL distintas a las que procede el mismo applet.
La configuración de recursos locales como, por ejemplo, la información de la fuente de datos ODBC para usar el puente JDBC-ODBC.
La descarga de clases nativas, es decir, aquellas cuyo nombre empieza por Java. Esta restricción afecta directamente a los navegadores que utilizan JDK 1.0.2 o anterior, pues JDBC es posterior a esta versión, de forma que las clases apropiadas no estarán instaladas localmente ni podrán ser descargadas de Internet por el applet.
o Finalmente debemos tener en cuenta que es bien conocido que los programas Java pueden ser descompilados muy fácilmente con lo que introducir el acceso a nuestras bases de datos mediante un applet Java conlleva un riesgo considerable en cuanto a la seguridad.
Modelo en Tres Capas (Three-Tier Model)
Con la arquitectura cliente/servidor en tres capas (three-tier) añadimos una nueva capa entre el cliente y el servidor donde se implementa la lógica de la aplicación. De esta forma el cliente es básicamente una interface, que no tiene por qué cambiar si cambian las especificaciones de la base de datos o de la aplicación; queda aislado completamente del acceso a los datos.
Así un applet de Java se carga en el navegador del cliente y se comunica con un servlet que corre en la máquina servidor; o bien accedemos a la base de datos a través de un formulario HTML. El servlet establece una conexión a la base de datos mediante JDBC.
En este caso se tiene total libertad para escoger dónde se coloca la lógica de la aplicación: en el cliente, en el servidor de base de datos, o en otro(s) servidor(es). También se tiene total libertad para la elección del lenguaje a utilizar.
Se utiliza un lenguaje de tipo general (probablemente C) por lo que no existen restricciones de funcionalidad.Los programas serán óptimos desde el punto de vista de la performance.
También deberá implementarse especialmente el Call remoto, lo que seguramente se hará de una forma más libre que los Remote Procedure Call actualmente disponibles.
No existe compromiso alguno con el uso de lenguajes propietarios, por lo que las aplicaciones serán totalmente portables sin cambio alguno.
Puede determinarse en qué servidor(es) se quiere hacer funcionar estos procedimientos. En aplicaciones críticas se pueden agregar tantos servidores de aplicación como sean necesarios, de forma simple, y sin comprometer en absoluto la integridad de la base de datos, obteniéndose una escalabilidad muy grande sin necesidad de tocar el servidor de dicha base de datos.
El problema de esta arquitectura es ¿cómo se implementa?. Parece ilusorio tratar de programar manualmente estos procedimientos, mientras que, si se dispone de una herramienta que lo hace automáticamente, presenta ventajas claras sobre la alternativa anterior:
Figura B: Arquitectura Cliente/Servidor en tres capas (three-tier)
Como se podría esperar cada uno de los componentes de la aplicación en una arquitectura three-tier se separa en una sola entidad. Esto te permite implementar componentes de una manera más flexible. Algo que no creo que sorprenda es la afirmación de que este tipo de arquitectura es la más compleja.
Figura 4. Arquitectura Three-Tier.
En esta Arquitectura todas las peticiones de los clientes se controlan en la capa correspondiente a la lógica del negocio. Cuando el cliente necesita hacer una petición se la hace a la capa en la que se encuentra la lógica del negocio. Esto es bastante importante pues eso quiere decir que:
1.- El cliente no tiene que tener drivers ODBCni la problemática consiguiente de instalación de los drivers por tanto se reduce el costo de mantener las aplicaciones cliente
2.- El Cliente y el Gestor de Reglas de negocio tienen que hablar el mismo lenguaje (en nuestro caso COM)
3.- El Gestor de Reglas de Negocio y el Servidor de Datos tienen que hablar el mismo lenguaje (en nuestro caso ODBC)
Lo ideal sería que el Gestor de Reglas de Negocio no sólo OLE y ODBC sino otros estandares como DBLib, OLI, DRDA, SQL/API y X/Open
Ventajas de este modelo:
o No existe ningún problema con respecto al tipo de controlador JDBC utilizado para acceder a la base de datos.Todos los recursos necesarios para establecer la conexión con la base de datos se encuentran en el servidor y por tanto, el cliente no necesita instalar nada adicional en su máquina para poder acceder a la base de datos.
Esta arquitectura proporciona considerables mejoras desde el punto de vista de la portabilidad de la aplicación, escalabilidad, robustez y reutilización del código. Asimismo facilita las tareas de migración o cambios en el sistema gestor de la base de datos.
Desaparecen las restricciones debidas a las limitaciones de los applets impuestas por el modelo de seguridad de Java.
Inconvenientes:
o Esta solución es algo menos eficiente que la del modelo de dos capas, ya que hemos añadido una capa intermedia más de software.
Como mencione anteriormente iremos de lo Micro a lo Macro, somos nuevo en este tema del blogging e iremos aprendiendo juntos Ustedes mis lectores de los temas que ire subiendo aca y yo de ustedes mediante sus criticas tanto negativas como positivas.
Nunca es Tarde Para Aprender, recuerda las excusas son solo para la persona que se siente incapaz de hacer las cosas aprovecha la tecnologia y usala de una manera positiva!!
Saludos!!
Jc
