Вы находитесь на странице: 1из 15

Folleto 3 MIGRACIN E IMPLATACION DE APLICACIONES EN PLATAFORMA CLIENTE SERVIDOR

ndice Introduccin. 1 La estructura de una aplicacin y su relacin con Cliente/Servidor. 2 Presentacin distribuida 3 Presentacin Remota 4 Proceso distribuido 4 Gestin de datos remota 4 Bases de datos distribuidas 4 Metodologa de desarrollo.................................................................................................. 4 Planeacin y anlisis de sistema 5 Costos 6 Diseo 6 Aplicaciones de Prueba 11 Liberacin del sistema integrado 12 Implantacin de la arquitectura Cliente/Servidor............................................12 Las razones que impulsan el crecimiento de las aplicaciones Cliente/Servidor son 13 Ventajas 13

Introduccin La investigacin en computacin de alto rendimiento ha estado orientada durante las ltimas dcadas al diseo de arquitecturas avanzadas que permitan resolver los problemas de gran desafo (intensivos en uso de procesador o en manejo de datos); al desarrollo de sistemas operativos, lenguajes de programacin o extensiones de lenguajes existentes que permitan explotar estos sistemas; y a la optimizacin de aplicaciones y algoritmos para que aprovechen de forma ms eficiente estas arquitecturas. Muchas de las aplicaciones de oficina utilizadas actualmente poseen buenos modelos de datos e interfaces realmente claras que permitieron en su momento un significativo aumento de la productividad. El problema es que ven afectada su posibilidad de crecimiento por caractersticas tecnolgicas de base que dificultan el acceso a alta velocidad dentro de la Red Local e impiden el acceso desde fuentes remotas como Internet y otras redes no locales. Tal es el caso de la mayora de las aplicaciones desarrolladas en los ltimos aos en que el acceso a datos se efectuaba a partir de aplicaciones monolticas que concentran en una sola capa tanto la interfaz visual como lo mtodos de acceso a datos, lo que comnmente se conoce como modelos Cliente - Cliente. Estas aplicaciones Cliente-Cliente concentran toda la actividad en los equipos de los usuarios, dejando al los servidores la labor de meros reservorios de datos compartidos. As ante cada peticin de datos, el servidor devuelve archivos completos que luego son procesados por el equipo cliente, para obtener el resultado. Por ejemplo, suponiendo que una base de cliente tuviera un tamao medio de 5Mb y se efecta una bsqueda muy simple de un cliente en particular, el servidor no efectuar la bsqueda por s sino que devuelve la tabla de 5Mb completa, luego el equipo del usuario procesa la bsqueda en su equipo para seleccionar 1 registro de digamos unos 1Kb y descarta el resto de la informacin. Los principales defectos de este modelo son: Requieren ms y mejor Hardware en las estaciones de trabajo. Son infinitamente ms lentos en el procesamiento de peticiones sencillas. Ocupan mayor ancho de banda, provocando congestionamiento en la Red Local. Requieren habilitar el acceso real a la carpeta de datos para todos los usuarios de la aplicacin. Su actualizacin es ms costosa No permiten el acceso en lnea desde fuera de la Red Local Requieren de implementaciones de soluciones de conectividad muy costosas

Las computadoras personales y los paquetes de software de aplicaciones proliferan comercialmente. Estas computadoras, tambin conocidas como estaciones de trabajo programables, estn conectadas a las Redes de rea Local (LAN), mediante las cuales, los grupos de usuarios y profesionales comparten aplicaciones y datos. Las nuevas tecnologas de distribucin de funciones y datos en una red, permiten desarrollar aplicaciones distribuidas de una manera transparente, de forma que mltiples procesadores de diferentes tipos (computadoras personales de gama baja, media y alta, estaciones de trabajo, minicomputadoras o incluso mainframes), puedan ejecutar partes distintas de una aplicacin. Si las funciones de la aplicacin estn diseadas adecuadamente, se pueden mover de un procesador a otro sin modificaciones, y sin necesidad de retocar los programas que las invocan. Si se elige una adecuada infraestructura de sistemas distribuidos y de herramientas de desarrollo, las aplicaciones resultantes podrn trasladarse entre plataformas de distintos proveedores. A mediados de los 90s, se deca que el desarrollo de aplicaciones Cliente/Servidor era inevitable por varias razones: era ms eficiente que el procesamiento centralizado, sobre todo cuando aumentaba mucho la cantidad de usuarios; ya existan en ese momento servidores razonablemente eficientes y confiables, de los cuales la mayora haba adoptado el estndar para 1

una interfaz Cliente/Servidor (el ODBC SQL). Adems, se consideraba imprescindible para apoyar con informacin a la creciente cantidad de ejecutivos de nivel medio para la toma de decisiones. Sin embargo, exista tecnologa para esta arquitectura desde haca ya mucho tiempo atrs, sin que nada ocurriera. Los primeros trabajos conocidos para la arquitectura Cliente/Servidor los hizo Sybase, que se fund en 1984 pensando en lanzar al mercado nicamente productos para esta arquitectura. A fines de la dcada de los 80s el producto fue lanzado para el voluminoso segmento "low-end" del mercado, en conjuncin con Microsoft, teniendo como soporte de la base de datos un servidor OS/2, y como herramienta "front end" bsica el Dbase IV de Ashton Tate. El Dbase IV no se mostr como una herramienta adecuada, y los desencuentros comerciales entre Sybase, Microsoft e IBM (en aquel momento socia de Microsoft para el OS/2) hicieron el resto. La situacin era muy diferente en 1994, cuando los principales fabricantes tradicionales (Informix, Oracle, Sybase) haban lanzado al mercado poderosos servidores y, a ellos, se agregaba IBM que estaba lanzando su producto DB2 para, prcticamente, todos los sistemas operativos importantes (adems de sus clsicos MVS y VM, ahora anunciaba AIX, OS/2,Windows NT, Hewlett Packard's UNIX, Suns UNIX, Siemens' UNIX, etc.) y Microsoft que, luego de finalizar su acuerdo con Sybase, parti para su propio SQL Server para Windows NT. Exista un conjunto de lenguajes "front end" como, por ejemplo, Delphi, Foxpro, Powerbuilder, SQL Windows, Visual Basic, etc. Se deca en aquel momento que Visual Basic, ms all de sus mritos intrnsecos como lenguaje, era el favorito para dominar el mercado, cosa que est ocurriendo. Por otra parte, en la comunidad informtica existan muchas dudas sobre la calidad de los optimizadores de los sistemas de gerencia de base de datos, cuyas fallas del pasado haban sido causantes de verdaderas historias de horror. Qu ha ocurrido en estos aos? Los servidores se han mostrado slidos y eficientes, sus optimizadores probaron, en general, ser excelentes. Una cantidad muy importante de empresas, en todo el mundo, ha encarado aplicaciones Cliente/Servidor, y quienes lo estn haciendo con los planes necesarios y con las herramientas adecuadas, estn obteniendo xitos muy importantes, mientras los que lo hicieron desaprensivamente, han cosechado fracasos. Elegir un servidor es una cuestin muy complicada; para aplicaciones pequeas y medianas, todos los servidores han probado ser muy buenos, las diferencias se darn cuando se necesiten altsimos regmenes transaccionales, y dependern de cmo cada uno vaya incorporando nuevas caractersticas como paralelismo, "read ahead", etc. Cada nueva versin puede modificar las posiciones y los principales fabricantes estn trabajando al ritmo de una gran versin nueva por ao. En general, los servidores de base de datos han evolucionado demasiado en los ltimos aos y todos los fabricantes trabajan con tecnologa sensiblemente equivalente. Parecen, mucho ms importantes para la eleccin, elementos que estn fuera de la tecnologa: la confianza que nos despierta el fabricante, su compromiso con el producto, su tendencia a mantenerse siempre actualizado, su situacin econmico/financiera, las garantas que brinde el soporte local y, en menor medida, el precio. Aunque inicialmente fueron los propios usuarios quienes impulsaron esta nueva tecnologa, la situacin ha cambiado drsticamente. Hoy en da, el modelo Cliente/Servidor se considera clave para abordar las necesidades de las empresas. El proceso distribuido se reconoce actualmente como el nuevo paradigma de sistemas de informacin, en contraste con los sistemas independientes. Este cambio fundamental ha surgido como consecuencia de importantes factores (negocio, tecnologa, proveedores), y se apoya en la existencia de una gran variedad de aplicaciones estndar y herramientas de desarrollo, fciles de usar que soportan un entorno informtico distribuido. LA ESTRUCTURA DE UNA APLICACIN Y SU RELACION CON CLIENTESERVIDOR Toda aplicacin de software tiene tres funciones fundamentales, administracin de los datos, lgica de la aplicacin (procesos) y lgica de la presentacin (interfaz de usuario). As, los procesos se efectan mediante el uso de los dispositivos que forman parte del hardware; a su vez los datos y 2

programas que constituyen parte del software interactan entre s realizando las funciones lgicas necesarias para correr una aplicacin, misma que genera un despliegue de informacin (presentacin) para el usuario. La relacin entre las funciones de una aplicacin y la arquitectura Cliente/Servidor es tal, que los procesos, datos y presentacin se ejecutan compartiendo recursos del sistema en red. Esta relacin est presente tanto en las PC's como en los sistemas grandes; y pretende lograr la integracin de ambas plataformas, combinando lo mejor de cada una dentro de un mismo sistema. Por esta razn, existe un conjunto de variantes de la arquitectura Cliente-Servidor, dependiendo dnde se ejecutan las diversas funciones de una aplicacin (qu asume el cliente y qu el servidor), como se aprecia en la figura 1.

Figura 1. Arquitectura Cliente-Servidor. Conjugando ambas estructuras y adicionado los recursos que sern compartidos, la relacin entre componentes para la Arquitectura Cliente-Servidor se visualiza as (figura 2):

Figura 2. Relacin entre componentes Donde todos los componentes estn estrechamente vinculados de tal forma que los procesos, datos y presentacin de cualquier tipo de aplicacin se ejecutan compartiendo los recursos del sistema en red. Presentacin Distribuida En este modelo, se distribuye la presentacin entre el cliente y el servidor, pero ste ltimo ejecuta todos los procesos y almacena la totalidad de los datos. Es similar a la arquitectura 3

tradicional de un Host y terminales; el cliente se utiliza solo para mejorar la presentacin desde un punto de vista estrictamente cosmtico. Tiene un bajo costo de desarrollo, pero dificulta el mantenimiento del sistema y no se aprovecha la red. Presentacin Remota Aqu, la interfaz del usuario est completamente en el cliente, la presentacin soporta la captura de datos, incluyendo una validacin parcial de los mismos y una presentacin de las consultas. La lgica de la aplicacin y los datos est en el servidor. Con este modelo, el cliente aprovecha bien la presentacin y la red; sin embargo, los procesos de la aplicacin pueden ser complejos de desarrollar y si existe un alto trfico en la red, puede ser difcil la operacin de aplicaciones muy pesadas. Proceso Distribuido Se da cuando la presentacin est en el cliente, la base de datos est en el servidor y la lgica de la aplicacin est distribuida entre el cliente y el servidor. Este modelo permite distribuir los programas del sistema al componente ms apropiado, aunque es difcil de disear, ya que el diseador debe definir los servicios y las interfaces de manera que los papeles de cliente y servidor sean intercambiables (excepto el control de los datos, que es responsabilidad exclusiva del servidor). Gestin de Datos Remota Para este modelo, tanto la presentacin como los procesos de la aplicacin residen en el cliente, mientras que las bases de datos permanecen centralizadas en el servidor. Es fcil de desarrollar ya que la lgica de la aplicacin no est distribuida y adems, libera la carga del servidor; pero, como desventaja, la totalidad de los datos viajan a travs de la red ya que no hay procesamiento en el mismo. Bases de Datos Distribuidas Este ltimo modelo, la presentacin, los procesos de la aplicacin y parte de los datos de la Base de Datos estn en el cliente; el resto de los datos estn en el servidor. Esto permite que la ubicacin de los datos sea transparente para la aplicacin y que se pueda accesar a datos almacenados en ambientes heterogneos, aunque ste acceso es dependiente del proveedor del software administrador de Base de Datos, el cual divide sus componentes entre el cliente y el servidor. METODOLOGA DE DESARROLLO Aunque existen diversas tecnologas y herramientas de desarrollo para aplicaciones basadas en arquitectura Cliente/Servidor, no se cuentan con metodologas claras para su diseo. Debido a todas las caractersticas y conceptos que presenta esta arquitectura, las metodologas tradicionales de desarrollo de sistemas de informacin se quedan cortas cuando se aplican a los sistemas actuales, ya que stos requieren de un uso intensivo de interfaces grficas interactivas e integracin de herramientas de productividad personal, adems de un manejo de varios tipos de informacin (grficos, fotos, sonido, adems de texto) distribuida sobre mltiples sitios. Las metodologas ms comunes son: la del modelo Entidad-Relacin para bases de datos relacionales, que no se adapta bien al uso intensivo de interfaces grficas y manejo de objetos complejos; y, la de diseo orientado a objetos, que no fue concebida para manejar informacin distribuida. Sin embargo, son adoptadas por las organizaciones como herramientas de soporte para 4

el diseo de proyectos adecuando lineamientos y guas de accin propios, segn sus polticas internas. En este documento, se han recopilado una serie de recomendaciones para detectar los elementos ms relevantes en cada fase del desarrollo de un sistema en arquitectura Cliente/Servidor, desde el anlisis hasta su liberacin. El objetivo de esta metodologa propuesta es identificar los componentes y herramientas necesarias para implementar la arquitectura, y adecuarlos a los requerimientos del sistema de informacin a desarrollar. El enfoque general de una metodologa de desarrollo comprende: Identificar las necesidades o requerimientos de la organizacin, incluyendo las aportaciones tecnolgicas. Realizar el diseo conceptual, localizando los bloques funcionales y de datos del sistema, junto con la relacin y comunicacin entre ambos. Definir en detalle los componentes funcionales, seleccionar procesos y determinar los principios que deben aplicarse a la seleccin de software o diseo de los mdulos. Definir los conceptos del sistema y la infraestructura tecnolgica. Seleccionar las plataformas y productos para la implantacin. Construir la arquitectura incrementalmente y ampliada a medida que se desarrollan nuevas aplicaciones.

Planeacin y anlisis de sistema En una infraestructura Cliente/Servidor, debe tenerse siempre presente los componentes esenciales de la misma: Plataformas operativas del sistema (servidores, clientes y sistemas operativos) Estndares, formatos y protocolos aplicables al hardware y software de sistemas y aplicaciones. Software para los componentes de middleware de las plataformas operativas y herramientas de desarrollo de aplicaciones. Software de aplicacin estndar disponible en el mercado.

La etapa de planeacin debe integrar los elementos organizativos del proyecto: definir los objetivos y las metas; el personal que est involucrado en el mismo (jefe del proyecto, asesores y analistas), y la asignacin de comisiones. Deber especificarse tambin la justificacin de migracin hacia el nuevo sistema, as como los objetivos y beneficios que se pretenden obtener al reimplantar su sistema de cmputo bajo Cliente/Servidor en una red distribuida. Una vez definido lo anterior, debe realizarse un anlisis completo sobre la problemtica existente en la organizacin, indicando la descripcin detallada del sistema de cmputo actual: Necesidades de la empresa y volmenes de informacin que maneja. Debe incluirse toda aquella documentacin que especifique la lista de requerimientos particulares para cada rea de la organizacin. Restricciones de accesos a la informacin real para los usuarios de los distintos niveles empresariales, y los problemas que esto representa. Aplicaciones crticas para la empresa, principales operaciones entre usuarios. Frecuencias de transacciones diarias.

Costos

Identificar las funciones del hardware: volmenes de informacin, cargas de trabajo, capacidad de los equipos, movimientos de actualizacin, aplicaciones y software que manejan. Dificultades en la comunicacin y manejo de documentos entre grupos de trabajo, as como la limitacin al uso de aplicaciones especficas. Capacidades de los trabajos existentes y de los que debern adquirirse. Visin del crecimiento empresarial a futuro (usuarios y aplicaciones). Sistema de red actual y sus alternativas de crecimientos. Diversidad de herramientas de software y aplicaciones en cada rea funcional, para determinar la creacin de interfaces que permitan el acceso entre aplicaciones y software utilizado en los diversos departamentos. Existencia de burocracias tajantes que impiden agilizar los ciclos del negocio, an con el uso de herramientas de cmputo.

El estudio de factibilidad para el sistema propuesto debe reflejar cual sera el impacto para la empresa, el migrar hacia el nuevo sistema en trminos de corto, mediano y largo plazo. Esto deriva en un estudio del costo - beneficio que refleja el tiempo o lapso en que se recuperar la inversin de las adquisiciones (insumos, recursos humanos y materiales) para implementar el nuevo ambiente de cmputo. Se podra mencionar que dentro de esta misma etapa, tal vez el concentrado de mayor inters para las gerencias responsables de tomar la decisin, sera la propuesta y estrategia de la solucin: Las alternativas o propuestas de solucin elaboradas por los grupos de sistemas a cargo del proyecto, debern contener como parte de la documentacin, los costos totales por cada propuesta, en trminos cuantitativos, cualitativos y en periodos de tiempo. As, en base a las necesidades y prioridades presentadas como resultado del anlisis sobre los puntos anteriores, las gerencias involucradas junto con los responsables del proyecto, debern evaluar las diversas propuestas de solucin, para elegir y autorizar aquella que refleje la estructura fsica-lgica ms adecuada para el nuevo sistema, considerando las caractersticas de rentabilidad y factibilidad, acorde a los requerimientos y capacidad financiera de la empresa. Diseo La clave del desarrollo de un sistema Cliente/Servidor es: centrarse primero en la estructura lgica del sistema antes de involucrarse en los detalles fsicos. En esta metodologa se recomienda seguir cuatro pasos principales: Asignar los requerimientos funcionales entre clientes y servidores Identificar las funciones de acuerdo al balance de la aplicacin (datos, procesos y presentacin). Aplicar las reglas heursticas determinando contextos monousuario vs. multiusuario, con el objetivo global de intentar desplazar el mayor procesamiento posible hacia los clientes. Identificar servidores potenciales tratando cada recurso o funcin compartida como un servidor virtual. Distribuir los recursos entre los servidores virtuales Esta fase es igual que las dems, es de suma importancia ya que en ella se estructuran y se definen a nivel de detalle cada uno de los elementos que conformaran al sistema integrado Cliente/Servidor; de esta manera, dentro del diseo o rediseo -cuando se trata de un sistema ya existente- se recomienda definir las siguientes especificaciones: 6

Concretar los objetivos y metas del nuevo sistema Realizar asesoras con personal especializado en ambiente Cliente/Servidor Debern disearse grficas y planos para mostrar la interrelacin del sistema distribuido en red, que contemple los siguientes enfoques: Aspecto lgico Definir los recursos que integrarn el sistema conceptualizndolos en clientes, servidores y middleware. Disear lgicamente la estructura, distribucin y relacin de comunicacin entre elementos de la red, auxilindose de planos, diagramas de flujo, de entidad-relacin o cualquier otra herramienta de diseo que permita plasmar en forma grfica la integracin entre dichos componentes. Debe especificarse el modelo Cliente/Servidor ya sea de dos o tres planos, de acuerdo al que ms se adecu a las necesidades de la estructura. Estructurar lgicamente, a nivel de detalle, la ubicacin del software, aplicaciones y bases de datos dentro de los servidores y/o clientes. Mencionar el tipo y caractersticas de software que se piensa adquirir para incorporarlo con el ya existente, previa verificacin. Debe considerarse el nmero de usuarios existentes y el posible crecimiento o proyeccin a futuro para agilizar su incorporacin a la red, sin mayores contratiempos. Aspecto tcnico Debe considerarse la infraestructura fsica en cuanto a hardware se refiere, es decir un informe tcnico de los componentes, incluyendo las caractersticas de los componentes de la red. Protocolos, capacidad de los servidores y clientes, voltajes; lugares de conexin, tipo de cable, software de comunicaciones, etc. Aqu deber definirse cul es la topologa de red que se sugiere implementar, evaluando la ya existente, para decidir si nicamente se complementar o bien si ser sustituida totalmente por una nueva interconexin de red. Se ha encontrado que en una aplicacin Cliente/Servidor debe existir un balance de las tres partes de una aplicacin (interfaz, procesos y datos) entre el cliente y el servidor. Por lo tanto, a manera de gua, se proponen estas reglas heursticas para el diseo de este tipo de aplicaciones: 1) Disponer del mayor procesamiento posible en el cliente Debe tenerse en cuenta que la aplicacin cliente est dedicada a un solo usuario, mientras que en el servidor estn las aplicaciones compartidas por varios usuarios; esto significa que el procesamiento en el cliente ser ms rpido. As, se evitar la ejecucin de procesos innecesarios en el servidor. 2) Hacer todas las actividades intensivas de programacin en el cliente Esto refleja una arquitectura ms econmica. Las actividades intensivas incluyen: ordenamiento general o de tablas bases, procesamiento de texto y anlisis estadstico, optimizacin 7

de consultas, encriptamiento y decodificacin de datos; compilacin del cdigo fuente, toda la aritmtica de punto fijo y punto flotante, dibujo y/o presentacin de imgenes y captura o emisin de sonido y video, entre otras. 3) Separar los contextos de procesamiento: multiusuario vs monousuario Se refiere a que partes de la lgica de una aplicacin sern programadas para manejar informacin o procesos de un solo usuario (acceso y validacin de datos de un usuario especfico, ayuda para el usuario) y cules corresponden a varios de ellos (por ejemplo, cuando el status del trabajo de cada usuario debe ser conocido para seguir el flujo de trabajo requerido). De esta forma se entiende mejor qu debe ocurrir en el cliente y qu en el servidor. 4) Administrar todos los recursos compartidos con el servidor Todos los equipos perifricos, servicios o datos que deban ser compartidos por varios usuarios sern administrados por el servidor, el cual proveer una abstraccin lgica de los recursos compartidos a sus clientes y ocultar los detalles de cmo estn siendo administrados. 5) Mantener una vista virtual de los servidores durante el diseo Un diseo de Cliente/Servidor exitoso requiere de una perspectiva virtual: en las primeras etapas del diseo debe ponerse mayor nfasis en la parte lgica del sistema (servicios "virtuales" del servidor), que en la parte fsica (tamao de mquinas, costo involucrado). Despus, las tcnicas de planeacin de capacidad sern utilizadas para plasmar los servidores lgicos en equipos fsicos. 6) Administrar todos los datos con el servidor Puesto que la visin del cmputo empresarial se basa en hacer que la informacin sea accesible a todo el que la requiera, todos los datos (o la mayor parte de ellos) deben ser administrados por el servidor. Esto permite hacer respaldos rpidamente. Entre las excepciones se encuentran archivos para uso individual y datos estticos; sin embargo, stos tambin deben ser controlados por el servidor. 7) Evitar la centralizacin de servicios La administracin de recursos compartidos no implica necesariamente el uso de un solo servidor. Los sistemas Cliente-Servidor son inherentemente sistemas distribuidos; deben utilizarse servidores mltiples distribuidos en lugar de un gran servidor central. Aunque la particin de datos debe hacerse cuidadosamente, los sistemas distribuidos proveen mejor disponibilidad y la configuracin de servidores ms pequeos (lo que se refleja en los costos). 8) Asegurarse de que los datos locales se tengan y sean administrados localmente Se recomienda poner atencin al nmero de interacciones entre entidades mientras se decide como particionar un sistema. Debe encontrarse un balance entre el acceso centralizado y el distribuido, ya que no siempre se tiene una localidad total de referencia en los sistemas. 9) Utilizar procesamiento en planos para lograr la escalabilidad El software Cliente-Servidor debe ser diseado para explotar una jerarqua de procesamiento que permita la escalabilidad. Dividiendo la aplicacin en planos (two - or three - tier), se pueden agregar planos intermedios para agrandar un sistema. Se recomienda utilizar la aplicacin del servidor en planos si el nmero de sesiones de bases de datos concurrentes es mayor a 50. Es necesario mantener configuraciones y topologas estndares; todo el equipo y software de un mismo nivel en la jerarqua debe tener la misma configuracin. Esto reducir la complejidad del sistema en todas sus formas: tcnica, administrativa y operacional.

10) Extraer las transferencias de datos en lugar de dejarlas en el servidor Para evitar la saturacin del servidor en un sistema grande, hay que asegurar que el servidor administre grandes transferencias de datos. Un cliente nunca debe decidir cundo iniciar una transferencia, ni mucho menos cuestionar al servidor; de otra forma, el sistema no ser escalable. 11) Minimizar los datos transferidos entre clientes y servidores Las redes de comunicacin traen consigo un potencial latente de perdida de datos, errores y an ms, de una falla total; a mayor transferencia de datos, mayor riesgo de falla. El canal de comunicacin es un recurso compartido; cualquier incremento de trfico de datos en un cliente, reduce la salida a la red de otros clientes. Por lo tanto deben evitarse transferencias de datos innecesarias. 12) Comprimir grandes transferencias de datos si es posible Si una transferencia de datos es muy grande, debe considerarse comprimirla para reducir el impacto en el ancho de banda de la red y para acelerar su tiempo de entrega. Existen diferentes tcnicas de compresin especficas segn el tipo de datos que son transferidos (datos de texto, datos numricos, imgenes, etc.). 13) Inspeccionar las transferencias de datos grandes Las transferencias de datos grandes siempre deben ser inspeccionadas de tal manera que no sean reiniciadas si un problema ocurre durante la transferencia. El inspeccionamiento es esencial en transferencias a travs de una WAN, y es una buena prctica para LAN's altamente cargadas. Agregar inspecciones lgicas a una aplicacin es complicado a veces, porque el servidor debe mantener la pista de los datos que ha enviado al cliente en sesiones previas; sin embargo, la inversin en el tiempo de desarrollo se recupera con la reduccin de los costos operacionales y la mejora en la productividad del usuario. 14) Utilizar clientes sustitutos para implementar flujos de datos multiservidores Se recomienda utilizar el paradigma Cliente-Servidor para simular procesamiento Par-a-Par donde sea necesario. Esto reduce la complejidad del diseo y frecuentemente permite reutilizar las mismas herramientas de desarrollo para programacin Cliente-Servidor en la implementacin de flujos de datos multiservidores. 15) Disear para interrupciones Es axiomtico que alguna parte de un enorme ambiente de red se caer en algn momento. Para tener xito operacional, debe disearse la aplicacin para manejar interrupciones elegantemente, de tal forma que se mantenga en procesamiento. 16) Centralizar la administracin con propagacin distribuida Disear para obtener una facilidad de administracin y de operacin del sistema, significa proveer un punto central para administrar el sistema, a partir del cual se realicen actualizaciones administrativas distribuidas. 17) Disear para administracin y monitoreo remotos Si una aplicacin espera consultar a un servidor (diferente al que mantiene sus datos) para obtener informacin administrativa, la aplicacin se integra fcilmente a un ambiente remotamente administrado. Si una aplicacin est diseada para proveer performance y otras estadsticas en demanda va una llamada de procedimiento remoto, entonces es ms fcil integrarla a un ambiente de monitoreo remoto. 18) Construir permetros de seguridad dentro de los sistemas y aplicaciones

Planear un diseo de sistema que utilice permetros de seguridad que protejan bienes importantes como sistemas, aplicaciones y datos. Las tcnicas de Cliente-Servidor se utilizan donde sea necesario para compartir servicios de seguridad entre aplicaciones. La identificacin y autenticacin distribuida de un servidor de seguridad, puede ayudar a reducir los costos operacionales ya que los cambios del usuario se pueden hacer desde un solo lugar. 19) Analizar la confiabilidad de la arquitectura Se recomienda usar las tcnicas de modelamiento de disponibilidad para analizar las vulnerabilidades de la arquitectura. Hay que determinar si se pueden aprovechar las redundancias que ocurren naturalmente dentro de una arquitectura en planos. Frecuentemente, se puede cambiar la topologa de la red para proveer rutas alternas que se puedan utilizar si ocurre una falla. Si los componentes no pueden hacerse redundantes, debe pagarse por el equipo ms confiable siempre y cuando se pueda pagar. El modelo de disponibilidad se usa para justificar la compra del equipo ms caro, y ms confiable. Una alta disponibilidad se traduce en horas de servicio a usuarios. 20) Disear para tener compatibilidad hacia atrs Para facilitar las actualizaciones y mejoras del sistema, se requiere idealmente que el software del cliente y del servidor sea compatible hacia atrs con las generaciones previas de servidores y clientes. La aplicacin Cliente-Servidor debe percatarse de cul es la versin del software que se est utilizando en cada extremo. 21) Medir la demanda independientemente de la capacidad ofertada Existen frecuentemente innumerables combinaciones posibles cuando se trata de decidir dnde situar las aplicaciones en una red. Se recomienda tener bien definidos cules son los vectores de carga de aplicacin; independientemente de la capacidad potencial de diferentes mquinas. Despus se podrn plasmar esos vectores en las diferentes configuraciones alternativas hasta que se encuentre un balance efectivo de costo entre la demanda y la capacidad ofertada. 22) Optimizar primero las cosas fciles Los mayores beneficios de performance se obtienen alterando el contexto en el cual se realizan las cosas, en vez de cmo se estn haciendo. En la sincronizacin de un sistema Cliente/Servidor, es mejor centrarse en los componentes compartidos: el servidor y la red. Por ejemplo: Se recomienda analizar la organizacin de la base de datos para ver si se puede mejorar, antes de ver la estructura de consulta de las transacciones ms frecuentes. Una vez que se han definido los perfiles de consulta, debe considerarse si la capacidad del servidor es adecuada antes de empezar a modificar los ndices. 23) Romper los cuellos de botella mediante la particin de la carga Los cuellos de botella se pueden particionar a travs de recursos lgicos, espacio y tiempo. Ejemplos: Se puede extender el acceso a las tablas de bases de datos ocupadas mediante discos mltiples (espacio). Se puede crear una sola tabla temporal grande para soportar mltiples consultas, en vez de varias pequeas que soporten consultas individuales (tiempo). 24) Utilizar servidores de aplicaciones solo si stos mejoran las cosas Los servidores de aplicaciones pueden proveer muchos beneficios junto con el performance para un gran nmero de conexiones de bases de datos concurrentes. Este tipo de servidores pueden simplificar las comunicaciones porque aslan los protocolos usados para conectarse a la base de datos del servidor desde la terminal. Sin embargo, no son recomendables para arquitecturas en tres planos, porque hacen ms complejo todo el diseo y la implementacin. 25) Evitar bloqueos de recursos innecesarios

10

Adems de hacer la recuperacin ms delicada, el bloqueo de recursos es, frecuentemente, una fuente de embotellamiento de ejecucin. No se necesita bloqueo si no existe concurrencia en la aplicacin. 26) Probar la integracin Cliente/Servidor tempranamente No debe darse por hecho la interoperabilidad de los productos y/o herramientas de desarrollo, debe comprobarse la interoperabilidad de los mismos antes de comprar licencias; para evitar divergencias de versiones o estndares entre lo que est implementando en el servidor y en el cliente. Aplicaciones de Pruebas Normalmente, los aspectos a probarse cuando se desarrolla una aplicacin deben incluir: La lgica de la aplicacin El diseo de la base de datos Las interfaces con otras aplicaciones Pruebas de regresin de cambios, y Pruebas por volumen de transacciones.

Sin embargo, para una aplicacin Cliente-Servidor los principales elementos a verificar son: Interfaz grfica de usuario (GUI). La riqueza de la interfaz de usuario presenta muchos componentes (cajas de dilogo, listas desplegables, mens dinmicos, botones de opciones, etc.), los cuales debern ser probados en su totalidad para asegurarse de que trabajan correctamente. Ayuda de contexto sensitivo y otra documentacin en lnea. El estndar para aplicaciones comerciales encontrada en los escritorios es muy alto, y los usuarios esperan ahora una cantidad enorme de ayuda en lnea. Estos mecanismos y el contenido de toda la informacin deben ser verificados, si estn incluidos en la aplicacin desarrollada. Manejo de errores. Existen diversos tipos de fallas como son: el cliente no se puede conectar con el servidor, fuera de tiempo debido al trfico en la red, si el servidor se reinicia, etc. El sistema debe probarse para localizar estas fallas y ver si es posible controlarlas. Integracin. Clientes y servidores son diferentes en hardware y ms an en software (entorno de desarrollo, bases de datos, middleware, protocolos de comunicacin, sistemas operativos, etc). Consecuentemente, la interoperabilidad de estos diversos elementos minuciosamente probada,

Sistemas en Arquitectura Cliente-Servidor. Debe ser preferentemente desde las primeras etapas de desarrollo del proyecto.

Impacto al entorno de operacin. El despliegue de una nueva aplicacin Cliente-Servidor puede tener impacto en aplicaciones no relacionadas que comparten el mismo escritorio, red o servidor. Por ejemplo, en la configuracin de un parmetro del sistema o la actualizacin de libreras de aplicaciones que puedan ser incompatibles con aplicaciones existentes. Por esto, es necesario probar que no se alterar nada al instalar la nueva aplicacin. Flujo de informacin. El paso de informacin hacia otras aplicaciones relacionadas en el proceso de negocio debe ser claro. Esto implica ms que probar la interfaz de usuario, probar el flujo del proceso end-to-end tambin. Ejecucin. La operacin end-to-end de una aplicacin Cliente-Servidor no debe considerarse aislada de las otras aplicaciones que pueden utilizar la misma red y los mismos servidores. Las 11

pruebas de volumen y de los modelos de operacin son necesarias para asegurar la calidad del servicio deseado. Administracin y operacin. La administracin de la aplicacin distribuida, la actualizacin de versiones y las operaciones, deben ser verificadas antes de la instalacin. Los procedimientos de distribucin en s necesitan probarse tambin. Soporte. El entrenamiento del soporte de ayuda, su capacidad de diagnstico y sus procedimientos para detectar problemas deben ser probadas antes de hacer una extensin a gran escala. Frecuentemente, la forma ms efectiva de probar la efectividad del soporte es probando la nueva aplicacin con un pequeo subconjunto de la eventual comunidad de usuarios. Seguridad. La seguridad, los respaldos y sus mecanismos de recuperacin necesarios para soportar la distribucin de la aplicacin, deben ser verificados. Incluso, si un nuevo equipo se va a instalar, los procedimientos de instalacin y configuracin deben ser verificados para asegurar que los sistemas entrarn en servicio con buen estado. Probar la aplicacin involucra pruebas de integracin (mdulo a mdulo), de sistema (funcin a funcin) y de operacin. La aceptacin, funcionalidad y utilidad final del software desarrollado debe probarse por el equipo de desarrollo en coordinacin con un conjunto de asesores designados inicialmente por la institucin o empresa usuaria. Liberacin del Sistema Integrado Una vez ya instalado el ambiente fsico, se realizar la carga del software y migracin de las aplicaciones existentes dentro de los clientes y servidores integrando dichos componentes fsica y lgicamente, de acuerdo a las especificaciones previamente descritas en la etapa de diseo. Bsicamente, aqu se concluye la implementacin del sistema distribuido bajo la arquitectura Cliente/Servidor. Para asegurarse de que no existan fallas tcnicas de instalacin deben revisarse nuevamente las conexiones. Por otra parte, para verificar que el sistema est funcionando adecuadamente, se procede a realizar una serie de pruebas, para ello se recomienda crear algunas aplicaciones desde los clientes, para accesar y extraer informacin de las bases de datos residentes en los servidores o en la localidad que se les haya asignado. Al obtener la informacin y/o respuesta a las peticiones sobre el uso de los recursos, prcticamente la integracin ha sido exitosa y el sistema queda listo para su explotacin. Bsicamente la liberacin del sistema integrado bajo Cliente/Servidor se concreta al finalizar la etapa de pruebas y al presentar a la gerencia los resultados satisfactorios de la fase anterior. Algunos autores incluyen la capacitacin como una etapa adicional a la metodologa, sin embargo, para ambientes Cliente/Servidor sta no es tan necesaria, debido a que los usuarios continuarn manejando las aplicaciones que ya conocen y ahora en un mejor ambiente de cmputo que optimiza el uso de recursos, lo cual destaca otra ventaja de la arquitectura Cliente/Servidor: al no tener que capacitar a todos los usuarios para utilizar el equipo slo a quienes se requiera para administrarlo, por lo tanto el costo por capacitacin se reduce considerablemente.

IMPLANTACIN DE LA ARQUITECTURA CLIENTE/SERVIDOR Las condiciones que pueden aconsejar la implantacin del modelo Cliente-Servidor en una organizacin son los cambios estructurales y organizativos, cambios en los organigramas con 12

mayor delegacin en personas y departamentos -, la respuesta a la dinmica del mercado o los cambios en los procesos del negocio. La capacidad de aproximacin de los productos y servicios, a la medida de las necesidades del cliente, exige disearlos, producirlos y suministrarlos con rapidez y mnimos costos. Las razones que impulsan el crecimiento de las aplicaciones Cliente/Servidor son: La demanda de sistemas ms fciles de usar, que contribuyan a una mayor productividad y calidad. El precio/rendimiento de las estaciones de trabajo y de los servidores. La creciente necesidad de acceso a la informacin para tomar decisiones y de soportar los procesos mediante aplicaciones ms ajustadas a la estructura organizativa de la empresa, que permitan realizar las operaciones de forma ms natural. La utilizacin de nuevas tecnologas y herramientas de alta productividad, ms aptas para la dinmica del mercado.

Ventajas a) Aumento de la productividad Los usuarios pueden utilizar herramientas que le son familiares, como hojas de clculo y herramientas de acceso a bases de datos. Mediante la integracin de las aplicaciones Cliente-Servidor con las aplicaciones personales de uso habitual, los usuarios pueden construir soluciones particularizadas que se ajusten a sus necesidades cambiantes. Una interfaz grfica de usuario consistente reduce el tiempo de aprendizaje de las aplicaciones. b) Menores costos de operacin La existencia de plataformas de hardware cada vez ms baratas. sta constituye a su vez una de las ms palpables ventajas de este esquema, la posibilidad de utilizar mquinas considerablemente ms baratas que las requeridas por una solucin centralizada, basada en sistemas grandes. Permiten un mejor aprovechamiento de los sistemas existentes, protegiendo la inversin. Por ejemplo, la comparticin de servidores (habitualmente caros) y dispositivos perifricos (como impresoras) entre mquinas clientes, permite un mejor rendimiento del conjunto. Se pueden utilizar componentes, tanto de hardware como de software, de varios fabricantes, lo cual contribuye considerablemente a la reduccin de costos y favorece la flexibilidad en la implantacin y actualizacin de soluciones. Proporcionan un mejor acceso a los datos. La interfaz de usuario ofrece una forma homognea de ver el sistema, independientemente de los cambios o actualizaciones que se produzcan en l y de la ubicacin de la informacin. El movimiento de funciones desde una computadora central hacia servidores o clientes locales origina el desplazamiento de los costos de ese proceso hacia mquinas ms pequeas y por tanto, ms baratas. c) Mejora en el rendimiento de la red Las arquitecturas Cliente-Servidor eliminan la necesidad de mover grandes bloques de informacin por la red hacia las computadoras personales o estaciones de trabajo para su proceso. Los servidores controlan los datos, procesan peticiones y despus transfieren slo los datos requeridos a la mquina cliente. Entonces, la mquina cliente presenta los datos al usuario mediante interfaces amigables.

13

Todo esto reduce el trfico de la red, lo que facilita que pueda soportar un mayor nmero de usuarios. Si se utilizan interfaces grficas para interactuar con el usuario, el esquema Cliente-Servidor presenta la ventaja, con respecto a uno centralizado, de que no es siempre necesario transmitir informacin grfica por la red, pues sta puede residir en el cliente, lo cual permite aprovechar mejor el ancho de banda de la red. Se pueden integrar PCs con sistemas medianos y grandes, sin que todas las mquinas tengan que utilizar el mismo sistema operacional. Tanto el cliente como el servidor pueden escalar para ajustarse a las necesidades de las aplicaciones. Las CPUs utilizados en los respectivos equipos, pueden dimensionarse a partir de las aplicaciones y el tiempo de respuesta que se requiera. La existencia de varias CPUs proporciona una red ms fiable: una falla en uno de los equipos, no significa necesariamente que el sistema deje de funcionar. En una arquitectura como sta, los clientes y los servidores son independientes los unos de los otros, con lo que pueden renovarse para aumentar sus funciones y capacidad de forma independiente, sin afectar al resto del sistema. La arquitectura modular de los sistemas Cliente/Servidor, permite el uso de computadoras especializadas (servidores de bases de datos, servidores de archivos, estaciones de trabajo, etc.). Permite centralizar el control de sistemas que estaban descentralizados, como por ejemplo la gestin de las computadoras personales que antes estuvieron aisladas. Es ms rpido el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear las herramientas existentes (por ejemplo, los servidores de SQL o las herramientas de ms bajo nivel como los sckets o el RPC). El esquema Cliente-Servidor contribuye adems a proporcionar a las diferentes direcciones de una institucin soluciones locales, pero permitiendo adems la integracin de la informacin relevante a nivel global.

14

Вам также может понравиться