Cliente servidor
Entre las primeras cosas que hay que decir de la arquitectura cliente/servidor, es que estamos frente a la plataforma abierta por excelencia.
Ciertamente las posibilidades de igualar o nivelar distintos productos o aplicaciones o componentes de distintos proveedores nos brinda la oportunidad de hacer una gran variedad de combinaciones de clientes y servidores.
Pero esta gran variedad de posibilidades de combinación implica que debemos tener en cuenta también una gran cantidad de elementos a considerar y evaluar al momento de enfrentar una solución informática basada en la arquitectura cliente/servidor.
Podemos agrupar básicamente en dos aspectos la problemática cliente/servidor: ¿Qué plataforma elegir? ¿Qué herramientas de desarrollo elegir?. La primera pregunta tiene relación con la respuesta a cuestiones aun más específicas como ser ¿Qué plataforma cliente elegir?
¿Qué plataforma servidor? ¿Qué clase de middleware ? ¿Qué administrador o servidor de base de datos? ¿Sobre qué arquitectura de computación distribuida se tendrá que montar la solución?.
El segundo aspecto tiene relación con la toma de decisiones sobre el área de desarrollo y herramientas de cliente/servidor.
Si bien es cierto que la mayor ventaja de esta tecnología es la flexibilidad en cuanto a que podemos elegir entre muchas opciones, esto mismo nos obliga a tener conocimientos importantes para la integración de las mismas, dado que el desarrollo de aplicaciones cliente/servidor requiere del manejo de elementos en el área de diseños de bases de datos, comunicación entre procesos, procesamiento de transacciones, generación de GUI (interfaces gráficas de usuarios) y para que hablar de Internet, con clientes y servidores distribuidos a lo largo de la Web.
También las cosas han cambiado en cuanto a las interpretaciones que hasta no hace mucho tiempo se hacían, para unos el mundo de la computación estaba basado en el permanente desarrollo y mejoramiento en las PC, y para otros el verdadero entorno computacional lo conformaban los mainframe. Mantener éstas posturas no tiene mucho sentido puesto que con cliente/servidor lo único válido, y el único camino, es mezclar o combinar.
Pensando ya en beneficios más específicos, siempre y cuando se adopten las decisiones correctas en cuanto al diseño de la aplicación cliente/servidor, esta arquitectura permite distribuir físicamente los procesos y los datos en forma más eficiente lo que en computación distribuida afecta directamente el tráfico de la red, reduciéndolo grandemente.
Pero cliente/servidor también tiene sus desventajas. Quizás, como en la mayoría de las cosas, los mismos elementos que se presentan como potenciales ventajas, se pueden convertir también en los principales escollos en la implantación de proyectos con esta tecnología.
Si se dijo anteriormente que esta tecnología ofrece beneficios en cuanto a que permite y sobre todo promueve el establecimiento de sistemas abiertos, esto mismo le otorga un alto grado de complejidad, característica propia de los sistemas abiertos, con una gran cantidad de componentes que no siempre tienen un compromiso firme o permanente entre sí, a diferencia de los sistemas propietarios.
Si a esto se agregan las presiones comerciales de los distintos proveedores con objetivos distintos la cosa se complica aún más.
Ya se dijo anteriormente que se requieren conocimientos de varias áreas, y que las decisiones tomadas respecto del diseño deben ser las adecuadas, de otra manera resultan más críticas con relación a desarrollos tradicionales, lo que obliga siempre a manejarlos en forma mucho más coherente y a tener un gran dominio de herramientas para lograr una adecuada implantación y explotación.
La tecnología cliente/servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales. Desde el punto de vista funcional, se puede definir la computación cliente/servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aun en entornos multiplataforma.
En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor, y este envía uno o varios mensajes con la respuesta. En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras. Además como veremos en el modelo de implementación, el concepto es utilizado en forma constante para varias funciones e implementado de distintas formas.
La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar muchas tareas, pero con la consideración de que realice aquellas que son mas adecuadas a sus características. Si esto se aplica tanto a clientes como servidores se entiende que la forma más estándar de aplicación y uso de sistemas clientes/servidores es mediante la explotación de las PC a través de interfaces gráficas de usuario; mientras que la administración de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe.
Como se desprende de las definiciones anteriores, tanto clientes como servidores son entidades independientes que operan conjuntamente a través de una red para realizar una tarea. Pero para hacer la distinción respecto de otras formas de arquitecturas o software distribuidos, se presenta una lista de características que debieran cumplir los sistemas cliente/servidor:
|
|
|
|
Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo de la red.
|
|
|
Existe una clara distinción de funciones basada en el concepto de "servicio", que se establece entre clientes y servidores.
|
|
|
La relación establecida puede ser de muchos a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a recursos compartidos.
|
|
|
Los clientes corresponden a procesos activos en cuanto a que son éstos lo que hacen peticiones de servicios a los servidores. Estos últimos tienen un carácter pasivo ya que esperan las peticiones de los clientes.
|
|
|
No existe otra relación entre clientes y servidores que no sea la que se establece a través del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición y entrega de solicitudes de servicio.
|
|
|
Las plataformas de software y hardware entre clientes y servidores son independientes. Precisamente una de las principales ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas.
|
|
|
El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier sistema cliente/servidor. La escalabilidad horizontal permite agregar más estaciones de trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical permite mejorar las características del servidor o agregar múltiples servidores.
|
Como se ha venido diciendo, cliente/servidor es un modelo basado en la idea del servicio, en el que el cliente es un proceso consumidor de servicios y el servidor es un proceso proveedor de servicios. Además esta relación está establecida en función del intercambio de mensajes que es el único elemento de acoplamiento entre ambos. De estas líneas se desprenden los tres elementos fundamentales sobre los cuales se desarrollan e implantan los sistemas cliente/servidor: el proceso cliente que es quien inicia el diálogo, el proceso servidor que pasivamente espera a que lleguen peticiones de servicio y el middleware que corresponde a la interfaz que provee la conectividad entre el cliente y el servidor para poder intercambiar mensajes.
Para entender en forma más ordenada y clara los conceptos y elementos involucrados en esta tecnología se puede aplicar una descomposición o arquitectura de niveles. Esta descomposición principalmente consiste en separar los elementos estructurales de esta tecnología en función de aspectos más funcionales de la misma:
|
|
|
|
Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.
|
|
|
Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.
|
|
|
Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación entre los componentes Cliente y servidor.
|
|
|
Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.
|
|
|
Este modelo de descomposición en niveles, como se verá más adelante, permite introducir más claramente la discusión del desarrollo de aplicaciones en arquitecturas de hardware y software en planos.
|
Cliente
El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor, se lo conoce con el término front-end. Este normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de la red.
Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:
|
|
|
|
Administrar la interfaz de usuario.
|
|
|
Interactuar con el usuario.
|
|
|
Procesar la lógica de la aplicación y hacer validaciones locales.
|
|
|
Generar requerimientos de bases de datos.
|
|
|
Recibir resultados del servidor.
|
|
|
Formatear resultados.
|
Servidor
Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se lo conoce con el término back-end. El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos.
Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:
|
|
|
|
Aceptar los requerimientos de bases de datos que hacen los clientes.
|
|
|
Procesar requerimientos de bases de datos.
|
|
|
Formatear datos para trasmitirlos a los clientes.
|
|
|
Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.
|
Middleware
En su definición más simple, middleware es la interfaz que provee la conectividad entre aplicaciones clientes y aplicaciones servidoras, y entre aplicaciones y bases de datos. Es una capa de software que protege a los desarrolladores de tener que manejar detalles de bajo nivel de diferentes protocolos de comunicación, sistemas operativos y arquitecturas de bases de datos. Este tipo de interfaces incluyen API’s, PRC’s, Pipes, mensajería de red y accesos a bases de datos.
Uno de los aspectos claves para entender la tecnología cliente/servidor, y por lo tanto contar con la capacidad de proponer, promocionar y llevar a cabo soluciones de este tipo, es llegar a conocer la arquitectura de este modelo y los conceptos o ideas asociados al mismo. Más allá de entender los componentes cliente/middleware/servidor, es preciso analizar ciertas relaciones entre éstos, que pueden definir el tipo de solución que se ajusta de mejor forma a las estadísticas y restricciones acerca de los eventos y requerimientos de información que se obtuvieron en la etapa de análisis de un determinado proyecto. De hecho el analista o líder deberá conocer estos eventos/restricciones del negocio para, a partir de allí, hacer las consideraciones y estimaciones de la futura configuración, teniendo en cuenta aspectos como por ejemplo, la oportunidad de la información, tiempo de respuesta, tamaños de registros, tamaño de bases de datos, estimaciones del tráfico de red, distribución geográfica tanto de los procesos como los datos, etc.
En tal sentido se presenta, en primer lugar, un esquema de clasificación basado en los conceptos de Fat Client/Thin Client, Fat Server/Thin Server, Two Tier, Three Tier, los cuales están bastante generalizados y sobrecargados de definiciones, pero que se consideran necesarios y útiles para la aplicación del modelo cliente/servidor. Después se presentará un esquema de clasificación según otros aspectos.
Este tipo de clasificación se basa en los grados de libertad que brinda el modelo cliente/servidor para balancear la carga de proceso entre los niveles de presentación, aplicación y base de datos. Dependiendo de que segmento de las capas de software tenga que soportar la mayor o menor carga de procesamiento, se habla de Fat Cliente (Thin Server) o Fat server (Thin Client). Consideraciones de este tipo son importantes al momento de decidir una plataforma de desarrollo/explotación, al punto que pueden definir la viabilidad o no de las mismas para enfrentar un cierto número de restricciones impuestas por una problemática a resolver.
Fat Client (Thin Server)
En este esquema de arquitectura el grueso de la aplicación es ejecutada en el cliente, es decir, el nivel de presentación y el nivel de aplicación corren en un único proceso cliente, y el servidor es relegado a realizar las funciones que provee un administrador de base de datos.
Fat Server (Thin Client)
Este es el caso opuesto al anterior, el proceso cliente es restringido a la presentación de la interfaz de usuario, mientras que el grueso de la aplicación corre por el lado del servidor de aplicación.
En general este tipo de arquitectura presenta una flexibilidad mayor como para desarrollar un gran espectro de aplicaciones, incluyendo los sistemas de misión crítica a través de servidores de transacciones.
Por planos o capas (Tier)
Una de las más comunes y discutidas distinciones entre las diferentes arquitecturas cliente/servidor se basan en la idea de planos (tier), la cual es una variación sobre la división o clasificación por tamaño de componentes (clientes grandes y servidores amplios). Esto se debe a que se trata de definir el modo en que las prestaciones funcionales de la aplicación serán asignadas, y en que proporción, tanto al cliente como al servidor. Dichas prestaciones se deben agrupar entre los tres componentes clásicos para cliente/servidor: interfaz de usuario, lógica de negocios y los datos compartidos, cada uno de los cuales corresponde a un plano.
Dentro de esta categoría tenemos las aplicaciones en dos planos (two-tier), tres planos (three-tier) y multi planos (multi-tier). Dado que este término ha sido sobrecargado de significados por cuanto se lo utiliza indistintamente para referirse tanto a aspectos lógicos (Software) como físicos (Hardware), aquí se esquematizan ambas acepciones.
Planos a niveles de software
Este enfoque o clasificación es el más generalizado y el que más se ajusta a los enfoques modernos, dado que se fundamenta en los componentes lógicos de la estructura cliente/servidor y en la madurez y popularidad de la computación distribuida. Por ejemplo, esto permite hablar de servidores de aplicación distribuidos a lo largo de una red, y no tiene mucho sentido identificar a un equipo de hardware como servidor, si no más bien entenderlo como una plataforma física sobre la cual pueden operar uno o más servidores de aplicaciones.
Cliente/Servidor Dos Planos.
Esta estructura se caracteriza por la conexión directa entre el proceso cliente y un administrador de bases de datos. Dependiendo de donde se localice el grupo de tareas correspondientes a la lógica de negocios se pueden tener a su vez dos tipos distintos dentro de esta misma categoría:
1. Implementado con SQL Remoto
En este esquema el cliente envía mensajes con solicitudes SQL al servidor de bases de datos y el resultado de cada instrucción SQL es devuelto por la red, no importando si son uno, diez, cien o mil registros. Es el mismo cliente quien debe procesar todos los registros que le fueron devueltos por el servidor de base de datos, según el requerimiento que él mismo hizo. Esto hace que este tipo de estructura se adecue a los requerimientos de aplicaciones orientadas a los sistemas de apoyo y gestión, pero resultan inadecuados para los sistemas críticos en que se requieran bajos tiempos de respuesta.
Ventajas:
- Presenta una estructura de desarrollo bastante simple por cuanto el programador típicamente maneja un único ambiente de desarrollo (es más simple respecto de cliente/servidor en tres planos, puesto que reduce una capa de programación, como se verá más adelante).
Desventajas:
- La gran cantidad de información que vviaja al cliente congestiona demasiado el tráfico de red, lo que se traduce en bajo rendimiento.
- Por su bajo rendimiento esta estructura tiene un bajo espectro de aplicación, limitándose a la construcción de sistemas no críticos.
2. Implementado con Procedimientos Almacenados
En este esquema el cliente envía llamadas a funciones que residen en la base de datos, y es ésta quien resuelve y procesa la totalidad de las instrucciones SQL agrupadas en la mencionada función.
Ventajas:
- Presenta las mismas ventajas de una arquitectura dos planos con procedimientos almacenados, pero mejora considerablemente el rendimiento sobre ésta, dado que reduce el tráfico por la red al procesar los datos en la misma base de datos, haciendo viajar sólo el resultado final de un conjunto de instrucciones SQL.
Desventajas:
- Si bien la complejidad de desarrollo se ve disminuida, se pierde flexibilidad y escalabilidad en las soluciones implantadas (especialmente respecto de cliente/servidor en tres planos, como se verá mas adelante).
- Obliga a basar el grueso de la aplicación en SQL extendido, propios del proveedor de la base de datos que se elija. Debiera considerarse que sí bien los procedimientos almacenados (stored procedures), los desencadenantes (triggers) y las reglas (constraint) son útiles, en rigor son ajenos al estándar de SQL:
- No existen dos implementaciones de proveedores iguales.
- El lenguaje para la descripción de los procedimientos almacenados y probablemente su funcionalidad varía de un proveedor a otro. Lo que implica que los procedimientos almacenados no son totalmente exportables entre plataformas de distintos proveedores.
- Se pierde la independencia entre el código de la aplicación (conocimiento y reglas del negocio) y los datos.
Cliente/Servidor Tres Planos.
Esta estructura se caracteriza por elaborar la aplicación en base a dos capas principales de software, más la capa correspondiente al servidor de base de datos. Al igual que en la arquitectura dos capas, y según las decisiones de diseño que se tomen, se puede balancear la carga de trabajo entre el proceso cliente y el nuevo proceso correspondiente al servidor de aplicación.
En este esquema el cliente envía mensajes directamente al servidor de aplicación el cual debe administrar y responder todas las solicitudes. Es el servidor, dependiendo del tipo de solicitud, quien accede y se conecta con la base de datos.
Ventajas:
- Reduce el tráfico de información en la red por lo que mejora el rendimiento de los sistemas (especialmente respecto de la estructura en dos planos).
- Brinda una mayor flexibilidad de desaarrollo y de elección de plataformas sobre la cual montar las aplicaciones.
- Provee escalabilidad horizontal y vertical.
- Se mantiene la independencia entre el código de la aplicación (reglas y conocimiento del negocio) y los datos, mejorando la portabilidad de las aplicaciones.
- Los lenguajes sobre los cuales se desarrollan las aplicaciones son estándares lo que hace más exportables las aplicaciones entre plataformas.
- Dado que mejora el rendimiento al optimizar el flujo de información entre componentes, permite construir sistemas críticos de alta confiabilidad.
- El mismo hecho de localizar las reglas del negocio en su propio ambiente, en vez de distribuirlos en la capa de interfaz de usuario, permite reducir el impacto de hacer mantenimiento, cambios urgentes de última hora o mejoras al sistema.
- Disminuye el número de usuarios (licencias) conectados a la base de datos.
Desventajas:
- Dependiendo de la elección de los lennguajes de desarrollo, puede presentar mayor complejidad en comparación con cliente/servidor dos planos.
- Existen pocos proveedores de herramientas integradas de desarrollo con relación al modelo cliente/servidor dos planos, y normalmente son de alto costo.
- Debido a estas desventajas es aquí la mayor importancia del Generador (aplicación creada en el presente trabajo).
Planos a niveles de hardware.
Esta clasificación del modelo cliente/servidor se basa igualmente en la distribución de los procesos y elementos entre sus componentes, pero centrándose en la parte física del mismo, en el que la administración de la interfaz gráfica se asocia a los clientes PC y la seguridad e integridad de los datos quedan asociados a ambientes mainframe o por lo menos a servidores locales y/o centrales.
Cliente/Servidor Dos Planos.
Como se ve en la figura, los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual, dependiendo de la aplicación puede dar acceso a los datos administrados por él.
Cliente/Servidor Tres Planos.
Como se ve en la figura, los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual a su vez se comunica con un servidor central de bases de datos. El servidor local tiene un comportamiento dual, dado que actúa como cliente o servidor en función de la dirección de la comunicación.
Cliente/Servidor Múltiples Planos.
Este esquema permite que las PCs clientes puedan conectarse directamente a un servidor de bases de datos, pasando por alto a los servidores locales, los cuales son utilizados como simples servidores de archivos.
Cabe aclarar que este enfoque no se contrapone con el enfoque centrado en planos lógicos, es decir, la clasificación del modelo cliente/servidor en planos a niveles de software, si no más bien son distintos puntos de vista que se complementan al momento de diseñar soluciones cliente/servidor. En tal sentido, debe entenderse que la clasificación de la arquitectura cliente/servidor en "planos a niveles de hardware", define la configuración física más conveniente sobre la cual montar una determinada aplicación, la cual es estructurada de acuerdo a las consideraciones del modelo lógico o "planos a niveles de software".
Servidores de Bases de Datos
Este análisis está elaborado desde el punto de vista del modelo cliente/servidor, y está directamente relacionado con la arquitectura en dos planos, descrita anteriormente. Dado que las características inherentes a dicho modelo ya fueron dadas, aquí sólo se hará una extensión a otros aspectos que se consideran relevantes.
Obviamente la creación de aplicaciones cliente/servidor está asociada a la utilización de servidores de bases de datos relacionales SQL, y dependiendo de los requerimientos y restricciones se debe elegir entre una arquitectura dos o tres planos.
Pero una arquitectura centrada en un servidor de bases de datos, cualquiera de las modalidades dos planos, permite que un proceso cliente solicite datos y servicios directamente a un servidor de bases de datos.
Según las distintas normas de SQL (SQL-89, SQL-92, SQL3) el servidor debe proveer un acceso compartido a los datos con los mecanismos de protección necesarios, así como proveer mecanismos para seleccionar resultados dentro de un conjunto de datos, posibilitando un ahorro en procesos de comunicación.
El servidor debe también proveer mecanismos de concurrencia, seguridad y consistencia de datos, basado principalmente en el concepto de transacción en el que todo se realiza, y por lo tanto se hace permanente, o todo falla, anulándose la transacción en tal caso.
Los servidores de bases de datos actuales son una mezcla de SQL estándar más otras extensiones propias de cada proveedor.
Por ejemplo casi todas las bases de datos están provistas con procedimientos almacenados (stored procedures), desencadenantes (triggers) y restricciones (constraints) pero presentan diferencias importantes en su implementación.
Es claro que esto obedece a presiones comerciales para tratar de extender los mecanismos de bases de datos para que realicen más funciones de las que corresponden a un servidor SQL relacional, con el objeto de tener una mayor participación en el espectro de los sistemas cliente/servidor por parte de los proveedores de bases de datos y como una manera de diferenciar sus productos.
Procedimientos Almacenados
Una de las posibilidades de implementar de mejor forma un sistema cliente/servidor en dos planos (two-tier), sin olvidar todas sus restricciones y limitaciones, es a través de procedimientos almacenados, que son funciones que agrupan un conjunto de instrucciones y lógica de procedimientos SQL, los cuales son compilados y almacenados en la misma base. Ya se hizo notar que con estos mecanismos los proveedores de bases de datos introducen la lógica de negocios dentro de su servidor propietario; lo lógico sería mantener una independencia entre datos y códigos.
El rol principal de los procedimientos almacenados es proveer la parte servidora de la lógica de una aplicación cliente/servidor, es decir vendría a reemplazar al servidor de aplicaciones en una arquitectura tres planos (three-tier). Con todo, si bien los procedimientos almacenados permiten a un servidor brindar servicios aptos para OLTP (On Line Transaction Proccesing), no se compara con los rendimientos alcanzados por una arquitectura en tres planos con TP pesado.
Desencadenantes : Son mecanismos que permiten realizar acciones automáticamente sobre los datos, las cuales están asociadas a algún evento definido.
Normalmente son implementados a través de procedimientos almacenados.
Los eventos a los cuales se hace referencia están asociados a las actualizaciones de tablas mediante sentencias delete, insert o update, y son llamados implícitamente al suceder cualquiera de estos eventos, a diferencia de los procedimientos almacenados que son llamados explícitamente por un proceso cliente.
Restricciones : Al igual que los desencadenantes, son acciones que se realizan asociadas a algún evento determinado y están orientadas a llevar a cabo validaciones más simples de datos. Los tipos de eventos son los mismos que para los desencadenantes.
Mas sobre SQL propietario
Los proveedores de bases de datos optan también por introducir lenguajes de procedimientos para SQL, con lo que se supone que la lógica de negocios (el servidor dentro del modelo cliente/servidor) se haga más exportable, permitiendo migrar la aplicación a cualquier plataforma sobre la cual corre la base de datos. Ejemplos de estos lenguajes de procedimientos para SQL son: PL/SQL (Oracle), Ingres/4GL (Ingres), SPL (Informix), Transac SQL (Sybase).
Servidores de transacciones
Estos tipos de sistemas se pueden implementar con cualquiera de las modalidades cliente/servidor en dos o tres planos, pero incorporan un elemento principal sobre el cual se elabora y basa toda la fortaleza de este modelo, el concepto de transacción.
Tal cual se explica mediante los conceptos de planos, tamaños de componentes y servidores de bases de datos, con un servidor de transacciones el proceso cliente llama a funciones, procedimientos o métodos que residen en el servidor, ya sea que se trate de un servidor de bases de datos o un servidor de aplicaciones. Lo importante es que el intercambio a través de la red se realiza mediante un único mensaje de solicitud/respuesta, es decir, independientemente de que se necesite ejecutar una o más funciones, una o más instrucciones o sentencias SQL, éstas son agrupadas en una unidad lógica llamada transacción; evitando así el intercambio a través de la red de un mensaje solicitud/respuesta por cada sentencia SQL, el cual es el caso de los sistemas cliente/servidor dos planos, implementados a través de SQL remoto. Estas aplicaciones denominadas OLTP (On Line Transaction Proccesing) están orientadas a dar soporte a los procedimientos y reglas de los sistemas de misión crítica.
Ampliación de la relación entre las clasificaciones por tamaño de componente y por planosComo se hizo notar anteriormente existe una estrecha relación, o equivalencia, entre estos términos, dado que se trata de una misma idea, en la que todo se reduce a la forma en que la lógica del negocio se distribuye entre los niveles lógicos del modelo: presentación, aplicación y base de datos.
En el caso de sistemas en dos planos, la lógica de negocios se puede distribuir en el cliente (fat client/thin server), en la base de datos (thin client/fat server), o una combinación de ambos.
En los sistemas en tres planos en cambio, la lógica de la aplicación se localiza normalmente en el servidor de aplicaciones, lo que lo convierte en un esquema thin client/fat server.
Consideraciones para herramientas de desarrollo cliente/servidorLas primeras generaciones de herramientas de desarrollo cliente/servidor estaban basadas en una arquitectura dos planos, y hasta hoy el término cliente/servidor se asocia por defecto a dicha estructura.
En la segunda generación de herramientas de desarrollo se incorporó la necesidad de separar claramente el nivel de presentación (interfaz de usuario) de la lógica de negocios, es decir, una arquitectura tres planos.
Conclusiones
Las únicas alternativas válidas, de acuerdo a los requerimientos de desarrollo y explotación de sistemas críticos, son la implantación de soluciones cliente/servidor en dos planos a través de la utilización de procedimientos almacenados, o la estructura cliente/servidor en tres planos.
Ambos modelos están presentes en el mercado a través de herramientas que apoyan las etapas de análisis, diseño y construcción de aplicaciones cliente/servidor y representan mejoras a lo largo de todo el ciclo de desarrollo, principalmente a través de la incorporación de procedimientos estándares, documentación desde las primeras etapas de vida de un proyecto.
La elección de la primera opción presenta ventajas de simplicidad en el ciclo de desarrollo, aunque no necesariamente en el mantenimiento, pero a costa de ejercer presiones para que los mecanismos de bases de datos hagan funciones de servidores más allá del modelo de datos relacional, a la vez que obliga a depender demasiado de un proveedor de base de datos y de lenguajes propietarios poco estándares (SQL extendido), lo que puede dificultar la exportación de las aplicaciones a otras plataformas.
La elección de la segunda opción brinda más grados de libertad en cuanto a la disponibilidad de plataformas, pero se debe tener en cuenta que las decisiones en la elección del software de base, si no son correctas, pueden hacer más compleja la implementación de una solución. De todas maneras se puede apelar a la característica de flexibilidad de esta estructura como para asegurar la posibilidad de contar con alternativas suficientes para tomar buenas decisiones.
