Está en la página 1de 6

Qu es la arquitectura de una aplicacin? Este es un trmino usado al disear aplicaciones, particularmente del tipo Cliente-Servidor.

Esta arquitectura se refiere a la manera en la que es diseada tanto fsica como lgicamente. En el diseo fsico se especifica exactamente donde se encontrarn las piezas de la aplicacin (Como discos, ejecutables, cable de red y computadoras). En el diseo lgico o conceptual se especifica la estructura de la aplicacin y sus componentes sin tomar en cuenta dnde se localizar el software, hardware e infraestructura. Tales conceptos incluyen el orden de procesamiento, mantenimiento y seguimiento comunes en sistemas organizacionales. Muchas veces se toma demasiado en cuenta el diseo fsico de una aplicacin. Por aadidura los desarrolladores generalmente asumen, indebidamente, que el diseo lgico corresponde punto a punto con el diseo fsico. Contrario a esto, un diseo adecuado debera permitir su implantacin en varias plataformas y configuraciones. Como puede ver, esta caracterstica de portabilidad es un punto deseable para permitir que su aplicacin sea flexible y escalable. A qu le llaman Cliente-Servidor la mayora de las personas? Cuando se le menciona este trmino a la gente no se piensa en otra cosa que bases de datos, dado que generalmente (Y de manera incorrecta) este trmino se usa como sinnimo de esto. Desafortunadamente esta designacin incorrecta ha llevado a crear gran confusin en la industria e incontables y acalorados debates. Y qu significa Cliente-Servidor? Este trmino, en su ms amplia definicin, se usa para describir una aplicacin en la cual dos o ms procesos separados trabajan juntos para completar una tarea. El proceso cliente solicita al proceso servidor la ejecucin de alguna accin en particular. Esta operacin se conoce como Proceso Cooperativo, dado que dos procesos separados cooperan para completar la tarea en particular. Los procesos pueden o no estar en una sola mquina fsica. Tales procesos en una aplicacin cliente-servidor pueden localizarse en una mquina o separados por miles de kilmetros de lnea telefnica. El diseo lgico, y no el fsico, es el que determina en qu grado una aplicacin es Cliente-Servidor. Qu tipos de arquitecturas existen? La arquitectura centralizada es an comn en muchos lugares. Esta se centra en un mainframe principal y una serie de terminales satlite que no ejecutan ningn proceso y son llamadas Terminales tontas. La terminal recibe los teclazos y los enva al mainframe, este procesa las solicitudes y devuelve los resultados a la clsica pantalla verde. Por otro lado, las bases de datos como SQL Server, Access y Paradox se basan en una arquitectura de Servidor de archivos. La base de datos consiste en slo un archivo de base de datos. En este caso el nico servidor requerido es uno de archivos. En esta arquitectura el motor de bases de datos puede ejecutarse en la mquina cliente o en el servidor, muy estrechamente unida a la aplicacin cliente. Para Access, Visual Basic y FoxPro este motor se conoce como JET y se compone de varios DLLs que residen en la mquina cliente. Por ahora nos concentraremos en aquellos servidores de bases de datos.

Qu ventajas tiene usar la arquitectura Ciente-Servidor? Cuando un servidor de bases de datos procesa una consulta, la respuesta a esta peticin depender de la mquina servidora, no de la cliente. El proceso servidor activo devuelve slo la informacin solicitada en la red (Contrario a los grandes bloques de entrada y salida), de tal modo que el trfico en la red es sustancialmente reducido. Esto permite crear aplicaciones que acceden grandes cantidades de datos en un mdem, por ejemplo, el cual tiene un ancho de banda mucho menor. Un proceso servidor activo puede asegurar ms eficazmente la integridad de los datos. La arquitectura de dos capas tpica en Cliente-Servidor La mayora de las aplicaciones Cliente-Servidor funcionan bajo una arquitectura de dos capas en lenguajes de cuarta generacin. Estas aplicaciones son bifurcadas en las siguientes capas: El llamado front-end (la interfaz del usuario, llamadas a SQL, aplicacin de escritorio, etctera) y el llamado Back-end (servidor de Bases de datos SQL, Sistema operativo multitareas, etc.). El proceso front-end se desarrolla en algn lenguaje de 4 generacin (4GL) como Visual Basic. Se llama front-end dado que es la capa en donde el usuario interacta con su PC. El proceso back-end es el servidor de bases de datos como SQL Server Oracle. Se llama as dado que tpicamente reside en un servidor central en un entorno controlado. A pesar de ser un mtodo comn de aplicaciones Cliente-Servidor, si ya tiene o ha estado en alguna organizacin que maneje este tipo de arquitectura sabr que no es la panacea. Uno de los problemas es la dificultad de manipular los cambios en el front-end. Es decir, Qu pasa si desea alterar las consultas SQL dado que una columna ha sido aadida a la tabla de Base de datos? Y qu cuando los ms antiguos distribuidores ahora sern marcados como inactivos (no eliminados) de la base de datos? En estos casos, varios (a veces decenas, tal vez cientos o miles) de estaciones de trabajo clientes necesitarn ser actualizadas con una nueva versin del front-end simultneamente al cambio en la base de datos. Este no es un cambio sencillo, sobre todo si las aplicaciones cliente estn geogrficamente dispersas. Otro problema es la dificultad de compartir procesos comunes. Luego de lgrimas de sangre (todos los desarrolladores las hemos llorado), y largas horas-nalga frente a la mquina para lograr un proceso en particular, este cdigo no puede reutilizarse en alguna otra aplicacin. Ms problemas: La seguridad. Esta puede ser establecida por el back-end del servidor de bases de datos o por la aplicacin que sirve de front-end. Cada una tiene sus limitaciones: El primero consiste en dar privilegios a los objetos de la base de datos y a los usuarios. Sin embargo, las corporaciones no requieren slo asegurar cuales datos pueden ser actualizados o accedidos, sino cmo. En cuanto al segundo punto, que es el ms usado, aunque el usuario puede acceder a la base de datos con su identificacin, tiene dos problemas: 1. Dado que ninguno de los objetos en la base de datos es segura, cualquier usuario pudiese tener acceso total a la misma con alguna otra herramienta de front-end (Como Excel, Access, etctera.); 2. La implantacin de la seguridad deber ser desarrollada, probada y mantenida en absolutamente toda la red (no importa dnde se encuentren las estaciones cliente).

Hay otros problemas como la necesidad de usar aplicaciones MIS, el modelo de negocios y la ausencia de un motor de procesamiento de negocios De tal suerte que, aunque el entorno de dos

capas provee grandiosas herramientas para el front-end y el back-end, el desarrolador se regresar a las herramientas de tercera generacin (3GL) como C y COBOL para crear procesos en lotes. La arquitectura de 3 capas Una arquitectura de 3 capas (o de N capas) se define tambin como el modelo de servicios. Ver, las bases de datos, las herramientas de desarrollo y los corporativos se estn moviendo hacia esta arquitectura dadas las limitaciones de la de dos capas. La capa adicional provee de una capa explcita para las reglas de los negocios que se sita entre lo que se ha llamado front-end y back-end. Esta capa intermedia encapsula el modelo de negocios (o "reglas de negocios") asociado con el sistema y le separa de la presentacin y el cdigo de bases de datos. En la documentacin de Visual Basic, Microsoft llama adecuadamente a las aplicaciones cliente "Servicios del usuario" dado que son estas las que interactan directamente con los usuarios finales. El Modelo de Servicios A ver, una de las capas se comunica con su padre, hijo o similar, lo que significa que puede hacer solicitudes y devolver respuestas a un proceso desde su propia capa, inmediatamente arriba de su capa o inmediatamente abajo de su capa. Normalmente, la nica comunicacin que nunca ocurre es la de una aplicacin con el servicio de datos. En una arquitectura tradicional, una capa puede comunicarse slo con otra directamente arriba o abajo de ella. En este otro caso los servicios de usuarios, de negocios y de datos pueden comunicarse con ellos mismos. Este modelo se conoce como el modelo de servicios, dado que, lejos del comportamiento de un modelo de capas, cualquier servicio puede invocar a otro dentro de su capa. Los servicios se forman de Componentes Un particular servicio de usuario, de negocios o de datos se forma de componentes. Cada componente radica en el contexto de una simple capa y servicio, y cada capa contiene varios servicios creados con componentes. Mientras un servicio es un concepto lgico, un componente describe un paquete fsico de funcionalidad. De este modo, cada servicio puede describirse como un grupo lgico de componentes fsicos. Existen algunas reglas al respecto: La capa de aplicaciones cliente se compone de aplicaciones cliente (como un pedido o mantenimiento de productos) las cuales se crean a partir de componentes de aplicaciones cliente. La capa del servidor de negocios se compone de servidores de negocios (como el proceso de ordenes y el manejo del almacn) la cual se crea a partir de componentes de aplicaciones de servidor de negocios. La capa del servidor de datos se compone de servidores de datos (como rdenes y productos) que se crean a partir de componentes de servidores de datos.

Esto es ms sencillo de usar que de explicar. La aplicacin cliente puede llamarse de mltiples formas: Servicio de usuario, cliente, aplicacin, front-end, capa de presentacin, GUI, etc. La funcin de la aplicacin cliente es la de permitir al usuario una interfaz para los servicios de negocios. Una aplicacin cliente bien diseada permite que el usuario entienda los servicios de negocios como un todo y navegar eficientemente por estos servicios. Esta es la capa que se crea con lenguajes de 4 generacin como Visual Basic, as como aplicaciones de escritorio como Excel. El servicio o servicios de negocios crean la unin entre las aplicaciones cliente y los servicios de datos. La funcin de esta capa lgica es primordialmente la de hacer valer las polticas del negocio y encapsular un modelo de los negocios as como exponer tal modelo a las aplicaciones cliente. Las polticas de negocios son reglas que restringen y controlan el flujo de las tareas. Encapsulan polticas como en los siguientes ejemplos: a) Pedidos que han sido embarcados y no pueden ser cancelados, b) Enviar camiones en alguna ruta de servicio con un cdigo ms econmico, c) Un mensaje por correo electrnico deber ser enviado a una cuenta ejecutiva cuyo destinatario no ha hecho ningn pedido desde hace varias semanas. Las reglas de negocios cambian ms rpidamente de lo que una aplicacin es til (esto se confirma con el hecho de que, generalmente, una aplicacin es obsoleta an antes de ser liberada, dado que desde el proceso de anlisis hasta el de su liberacin los requerimientos cambian y, pocas veces, la aplicacin final da el ancho). Supngase que una regla adicional de crdito se ponga a efecto. El trabajo en el servidor de negocios, por lo tanto, deber cambiar no as el flujo de datos. Dado que estos cambios son frecuentes en un entorno empresarial, las reglas del negocio son excelentes cambios para su encapsulamiento. Estos servicios de negocios se crean con lenguajes de programacin como Visual Basic, COBOL, C o herramientas CASE. Finalmente los servicios de datos son aquellos cuyo manejo se lleva a cabo mediante sistemas manejadores de datos basados en SQL, como SQL Server y Oracle. Estos son los que manejan los datos, informacin y transacciones para los servidores de negocios. As, estos servidores mantendrn inalterable slo la integracin de datos que manipulan. As, la arquitectura de tres capas depende del proceso interno de comunicacin. Para que dos servicios se comuniquen, debern hacerlo en el mismo lenguaje o protocolo. Esta comunicacin se puede hacer con OLE, DDE, OpenDoc, CORBA, DB-LIB, WinSock, etc. Contrario a la arquitectura de dos capas, las ventajas son: Mejor manipulacin del sistema, servidores de negocios que pueden compartirse, los objetos y procesos sern seguros, los usuarios podrn crear sus propias aplicaciones cliente, entre otros. De esta manera se pueden lograr sistemas distribuidos, que son fsicamente localizados en varias mquinas dentro de varias locaciones. El grado en que pueda distribuirse una aplicacin es directamente proporcional al grado en que lgicamente se ha particionado. Finalmente, como ya se haba dicho, la arquitectura de 3 capas depende en gran parte de los procesos de comunicacin. Un comn denominador debe existir para permitir cualquier proceso. La comunicacin deber ser local (en las mismas mquinas) o remota (en mquinas distantes). Deber ser transparente al proceso que envuelve sin importar si es local o remota. Para efectos de Visual Basic y aplicaciones de Windows, la Automatizacin es una gran herramienta para llevar a cabo esta comunicacin. Pero este ya es otro cantar...

Para finalizar Usted sabe qu tiene que ver Visual Basic en esto? Bueno, el servidor de negocios es la pieza que falta en la arquitectura de dos capas cliente-servidor. Es la capa que le permite crear aplicaciones cliente-servidor basadas en Windows realmente escalables y reusables. Visual Basic en su Edicin Empresarial es la primera herramienta de desarrollo que permite fcilmente crear aplicaciones que operan en el servidor y crear aplicaciones que usen la Automatizacin para comunicarse con las 3 capas. Esto es porque VB a partir de la versin 4 puede crear servidores de automatizacin, incluye la capacidad de Automatizacin Remota y de COM Distribuido, puede crear aplicaciones de 32 bits y tiene soporte para un servidor de datos de alto desempeo. Antes de VB4 los productos que implementaban la arquitectura de 3 capas tendan a ser caros, propietarios y difciles de usar, como Forte, R/3 (De Sap), CICS y Tuxedo. Recuerde que la arquitectura de 3 capas es una gua, no un requerimiento. Este es un modelo lgico, no fsico, que describe cmo se disea la aplicacin no cmo se despliega. Si desea ms informacin a este respecto, consulte el manual "Developing client-server applications" que se incluye en el paquete de VB edicin empresarial o los libros "Visual Basic 4 Enterprise Development", Craig Goren, ed. QUE y "Developing Client/Server applications with Visual Basic 4", Dan Rahmen, Sams Publishing. Nos seguimos leyendo! Los mainframes o sistemas host son mquinas cuya principal tarea es el almacenado, procesos y transferencia de grandes volmenes de informacin, permitiendo el acceso compartido por varios usuarios al mismo sistema de una manera eficiente. Concepto: Es una plataforma de computacion de propsito general en contnua evolucin, que incorpora en su definicin de arquitectura la funcionalidad esencial requerida por sus aplicaciones objetivo. Los mainframes funcionan bajo sistemas operativos como IBM z/OS, OS/390, Unix/Linux, MVS, VM, y VSE con caractersticas como solidez y robustez, mxima conectividad, aprovechamiento del ancho de banda disponible y gran capacidad para la realizacin de consultas, transacciones y almacenamiento de datos.

Acceso

El software de acceso al Mainframe o terminal de teleproceso, funciona a gran velocidad por su carencia de elementos grficos. Es un interfaz en modo texto, lo que le hace idneo para conexiones con escaso ancho de banda. Se utilizan los denominados terminales 3270 que utilizan una conexin persistente basada en estados a diferencia del sistema web basado en una GUI con conexion sin estado con su principal problema: pasar del modelo host a web es el mantenimiento seguro de los diferentes estados, la integridad de datos durante una sesin de trabajo. Otros terminales son los CICS o interfaces Java que dotan de mayor funcionalidad al acceso a la informacin ofrecida por el mainframe.

Ventajas de los mainframes

Disponibilidad y mantenibilidad, los recursos no dejan de estar disponibles por el hecho de realizar tareas de mantenimiento. Capacidad de ejecucin Escalabilidad Seguridad de datos: el entorno host est especficamente diseado para proteger la informacin de accesos no autorizados.

Unido a su potencia estn los bajos costes de soporte, al ser administrados de forma centralizada: todos los usuarios acceden a un sistema nico a travs de un terminal compartiendo sus recursos. Problemas respecto a la perspectiva del usuario

Su pobre capacidad de presentacin de informacin. Los sistemas host procesan datos sin atender a la presentacin, lo que les vuelve fros y carente de emocion. Falta de intuitividad y amigabilidad para usuarios ocasionales Esto les hace complejos de utilizar. Es un sistema para usuarios expertos que tras superar el periodo de aprendizaje consiguen trabajar a gran velocidad. Su interactividad es limitada: es un sistema de gran potencia orientado a conseguir objetivos de forma rpida y eficiente. No es una herramienta de comunicacion, sino que se opera mediante lnea de comandos a travs de terminales 3270 (Terminales tontos basados en pantallas negras y de acceso en modo texto). Inflexibilidad, ya que depende del departamento tcnico encargado de su administracin y suelen estar sujetos a limitaciones impuestas por el fabricante (IBM, Digital...). El acceso se realiza desde entornos controlados como bibliotecas, laboratorios, oficinas bancarias. Pero la popularizacin de la informtica y necesidad de presentar datos a usuarios cada vez menos experimentados, lleva ofrecer como servicio el acceso anywhere anytime a esa informacion. La necesidad de acceder de forma remota a multitud de sistemas, entre ellos mainframes crean un lugar para la Web. Mediante un navegador es posible acceder a un sistema host, a sistemas de informacion, bases de datos, repositorios de contenidos sin cambiar de herramienta, y mediante la accin de navegar. Ejemplo: Contratacin de viajes a travs de sistemas como SABRE o AMADEUS a los que accedemos mediante sitios web de viajes o compaas areas. Accedemos en tiempo real a informacin y herramientas antes slo disponible para los minoristas a travs de terminales especficos. Gracias a la tecnologa web el acceso se realiza a esos mismos sistemas con un terminal ubcuo: el navegador.

También podría gustarte