Funcionamiento de Sistemas

24

Leccin 3

Funcionamiento de un Sistema Distribuido

Una vez descrito lo que es un Sistema Distribuido para que sirve y sus caractersticas ms saltantes nos toca observar los detalles de su funcionamiento a fin de entender cmo es que este tipo de sistema informtico cumple su labor y como se observara atreves de las pginas siguientes no solamente debe tomarse del punto de vista software sino tambin del punto de vista hardware. 3.1 Arquitecturas Software usadas en Sistemas Distribuidos Tan importante como establecer las caractersticas de un Sistema Distribuido es definir la forma como los servicios podrn ser organizados con el fin de poder acceder a ellos, de tal manera que su organizacin depender de los estilos de construccin que se quieran establecer en la aplicacin distribuida. Para esto, se definen cuatro modelos que van a servir de gua para establecer una arquitectura definida de acceso a servicios. 3.6.2 Arquitectura basada en capas En esta arquitectura la organizacin de los servicios se establece de manera jerrquica utilizando para ello un modelo de capas, atreves del cual un proceso de una capa superior pueda acceder al servicio de la capa inmediatamente inferior siendo transparente para l todas las capas tanto superiores como inferiores a sta. Este modelo fue muy popular desde el inicio de la comunicacin heterognea y fue la base para la implementacin del modelo OSI y posteriormente del modelo TCP/IP dado su fcil organizacin y mantenimiento, a continuacin un grfico de esta arquitectura:

Request Response Flow Flow

Fig. 9 Organizacin en capas

Layer 1

Layer 2

Layer N-1

Layer N

Generated by Foxit PDF Creator Foxit Softwarehttp://www.foxitsoftware.com For evaluation only.

25

3.6.2 Arquitectura basada en objetos En este modelo los servicios se encuentran definidos como mtodos pertenecientes a clases los cuales se hacen accesibles atreves de los objetos que se crean. La ventaja de este modelo radica en que cada objeto puede comunicarse con cualquier otro para accesar al servicio que necesite, lo que deriva en un fcil acceso para ejecucin de los procesos involucrados. Como desventaja podemos anotar que este modelo genera un alto acoplamiento y un gran trfico de datos atreves de la red. Un ejemplo de esta arquitectura se muestra a continuacin:

Llamada mtodo

Fig. 10 Organizacin basada en objetos

3.1.3 Arquitectura basada en eventos Este modelo de arquitectura organiza de una manera eficiente el trfico de mensajes producido por la arquitectura anterior, debido a que define dos mejoras fcilmente identificables: a) Rene a todos los objetos que tienen en comn ejecucin de requerimientos

atreves de componentes.

3.. Se organiza una carretera de informacin atreves del cual van a viajar todos los mensajes colocados o recuperados por los componentes del sistema, denominado bus de eventos.

En esta arquitectura todo aquel componente que ofrece servicios coloca la respuesta a las solicitudes planteadas por los clientes en este bus en el cual viajaran simultneamente muchos mensajes, el componente cliente solo necesita accesar al bus para recuperar el mensaje que le corresponde. La arquitectura SOA es un ejemplo de esta implementacin la cual de manera esquemtica presentamos a continuacin:

Object

Object

Object

Object

Object


26

Event delivery

Publish

Fig. 11 Organizacin basada en eventos 3.6.2 Arquitectura basada en datos compartidos En este modelo se define una zona o espacio de datos en la que tanto el componente cliente como el componente servidor podrn colocar los mensajes que desean intercambiar. Inicialmente este modelo quedo asociado al concepto de base de datos distribuidas, donde diferentes base de datos situadas en diferentes partes del Sistema Distribuido pueden almacenar o proveer informacin a los diferentes procesos que lo soliciten sin importar el lugar donde se encuentren, posteriormente este modelo evolucionara a lo que ahora denominamos computacin en nube (cloud computing) en la que un cliente puede acceder a un servicio sin saber realmente donde se encuentra dicho servicio otorgando una mxima flexibilidad tanto en la implementacin como en el mantenimiento de dicho servicio, un grfico de esta arquitectura se presenta a continuacin:

Fig. 12 Organizacin basada en datos compartidos

Component Component

Event bus

Component


27

3.2 Arquitecturas Hardware de un Sistema Distribuido Tal como se describi en la primera leccin del curso, un Sistema Distribuido consta de dos elementos fundamentales un sistema informtico mas una red de computadoras, ambos se renen de modo indivisible para conformar el tipo de implementacin que estamos estudiando. De ah que la forma como se conectan los equipos de cmputo para implementar un Sistema Distribuido se presenta en dos modelos bastante conocidos:

3.. Modelo de estaciones de trabajo: Esta implementacin rene a computadoras en las que se encuentra diseminados los servicios hardware y software disponibles en el Sistema Distribuido. No existe el trmino cliente o servidor para distinguir a los nodos reunidos en este tipo de red ya que cada computador puede ser en un momento solicitante de un servicio, o en otro momento proveedor de otro, por lo que cada equipo computador recibe el nombre de entidad para describir su presencia en esta arquitectura. Un grfico de este modelo se presenta a continuacin:

Fig. 13 Modelo de estaciones de trabajo

Actualmente a sta implementacin tambin se le conoce con el nombre de redes P2P (peer to peer) redes que se volvieron famosas en la dcada de los 90 y a principios del ao 2000 por implementar las famosas redes de intercambio de archivos y cuyos nombres conocemos hasta el da de hoy (Naspter, Ares, eMule y otros) asi como implementaciones acadmicas como JXTA desarrollada por SUN, de tipo open source utilizado hoy en da en muchas aplicaciones comerciales. b) Modelo cliente servidor: Es el modelo ms conocido de implementacin de Sistemas Distribuidos. En l las mquinas cumplen roles previamente definidos, las mquinas cliente que solicitan los servicios y las mquinas servidor que procesan las peticiones de servicio y generan la respuesta a las peticiones. Es el modelo ms extensamente utilizado en la actualidad, un grfico mostrando esta implementacin se presenta a continuacin:


28

Fig. 14 Modelo cliente/servidor

Esta implementacin es usada por CORBA, RMI, DCOM, Web Services, JMX y otros. 3.3 Acceso a servicios en un Sistema Distribuido Todo Sistema Distribuido debe garantizar algn tipo de mecanismo que permita a un cliente poder enviar su mensaje al servidor que posea dicho servicio. Por ello, se han establecido diferentes formas de comunicacin las que se resean a continuacin: 3.3.1 Modelo multiproceso En este modelo se toma en cuenta la forma como se usan los procesadores y el espacio memoria disponible para la ejecucin de los servicios. Se consideran dos modelos: 3.3.1.1 Modelo de memoria compartida Este modelo tambin es conocido como modelo multiprocesador debido a que los diferentes procesadores van a utilizar el mismo bloque de direcciones por lo que queda a la decisin del sistema operativo definir el lugar donde se colocaran los datos. Las redes basadas en computadoras con mltiples ncleos es un ejemplo tpico de esta implementacin.

PI Elemento de proceso Mi Modulo de memoria

Fig. 15 Modelo de memoria compartida


29

3.3.1.2 Modelo con memoria distribuida Este modelo se le conoce tambin como modelo multicomputador debido a la presencia de varios equipos de computo que poseen un nico procesador el cual tiene su propio bloque de direcciones y por lo tanto controla los procesos que se colocan en l, debido a ello el programador debe saber donde se van a colocar los datos en este tipo de red.

PI Elemento de proceso Mi Modulo de memoria

Fig. 16 Modelo de memoria distribuida 3.3.2 Paso de mensajes En este modelo el proceso cliente enva un mensaje atreves de la red hacia el servidor que contiene el servicio a accesar y por la misma red debe regresar la respuesta, para que este concepto funcione se requiere que el cliente conozca la localizacin (mquina y proceso dentro de una mquina) del servicio a accesar. De este modelo tenemos dos opciones: a) Envo de mensajes: Se enva un mensaje conteniendo datos hacia el servidor el cual puede ser una cadena de caracteres (sockets), una llamada a un procedimiento remoto (RPC) o una invocacin a un mtodo existente en una clase remota (RMI, CORBA, DCOM). b) Ejecucin remota: A diferencia del anterior se enva un cdigo atreves de la red el cual se ejecutar en el servidor remoto utilizando los recursos y procesador de este. En el momento que est disponible este cdigo regresar al cliente conteniendo la respuesta al servicio solicitado. Los agentes son ejemplos ms conocidos de este modelo. 3.6. Comunicacin cliente/servidor, uso de interface y Stub La implementacin de los Sistemas Distribuidos se considera un desarrollo informtico basado en el modelo cliente/servidor del tipo de n capas heterogneo, por lo tanto, hereda las mismas caractersticas de las implementaciones de este tipo una de las ms importantes sin lugar a dudas es el aislamiento de los servicios ofrecidos por un proceso servidor a las peticiones que puedan efectuar los procesos cliente 29 travs de las interfaces. La interface permite mostrar la descripcin de aquellos servicios que pueden ser accesados remotamente y sirve como una mesa de partes que recibir todas las solicitudes de ejecucin y que posteriormente derivar al proceso servidor para su ejecucin y envo de respuesta.


30

Fig. 17 Acceso a servicios mediante interface

Sin embargo, las interfaces en el Sistema Distribuido tienen un papel mucho ms importante, debido a que tanto el proceso cliente como el proceso servidor por naturaleza son heterogneos no ser posible jams poder realizar un intercambio de mensajes directo debido a la incompatibilidad manifiesta entre ambos. Es aqu donde aparece claramente el papel del componente integrador de estos procesos y que cumplir con la tarea de permitir la comunicacin eficiente entre los procesos involucrados, a este componente se le denomina MIDDLEWARE el cual define los protocolos de comunicacin formato de mensaje, formato de datos y todo aquello necesario para la ejecucin de servicios. Como es lgico el MIDDLEWARE deber conectarse tanto con el cliente como el servidor, estos conectores se les conoce con el nombre de Stubs y cumplirn tareas de adaptacin de mensajes, trasladarn la definicin de los servicios ofrecidos por la interface de servidor hacia el lado cliente posibilitando que cualquier cliente conozca la descripcin de los servicios que cualquier servidor tenga disponible. Los Stubs actan como referencias a objetos remotos desde el lado cliente y se encargarn de retransmitir las llamadas desde cliente a servidor. 3.6. Paradigma de computacin en red Una vez localizado el servicio a solicitar y el cliente ya ha enviado los parmetros de entrada para la ejecucin del servicio, cmo se ejecuta este servicio? Este concepto se denomina paradigma de computacin en red y se presenta en tres modelos caractersticos y que se utilizan en diferentes implementaciones. Debe indicarse adems que para la ejecucin de un servicio se requieren tres elementos fundamentales a) El procesador: El cual se encargara de ejecutar el servicio b) El cdigo del servicio: Que contiene las instrucciones para la ejecucin del servicio y generacin de la respuesta solicitada c) Los recursos: Elementos de apoyo que son necesarios para la ejecucin del servicio, pueden ser: base de datos, archivos, otros servidores, etc. A continuacin se presentan los tres paradigmas actuales de computacin en red:


31

3.5.1 Paradigma cliente/servidor En este paradigma el servidor posee el procesador, el cdigo de servicio y los recursos, correspondindole al cliente nicamente la tarea de solicitar el servicio y esperar recibir la respuesta. Este paradigma se utiliza en aquellas implementaciones en las que el cliente puede ser de cualquier tipo de tecnologa y cuyas caractersticas tcnicas no son relevantes. Ejemplo de este paradigma son: CORBA, RMI, Web Services, DCOM. 3.5.2 Paradigma cdigo por demanda Este paradigma tiene la particularidad en que el cliente es el que tiene el procesador en el que se va a ejecutar el servicio, mientras el servidor posee el cdigo de los servicios y los recursos. Este modelo el servidor debe enviar el cdigo del servicio al cliente para que este a continuacin pueda ejecutar dicho servicio y accesando a los recursos obtener la respuesta. Es evidente que el tipo de cliente utilizado en este paradigma tiene caractersticas tcnicas mucho ms fuertes que el paradigma anterior como por ejemplo un procesador de determinada potencia, una cantidad de memoria suficiente para alojar al servicio recibido. Ejemplo de este paradigma son: Youtube, los juegos en lnea, la ejecucin de los archivos flash 31 travs de HTML, etc. 3.5.3 Paradigma de agente mvil En este paradigma el cliente enva un bloque de cdigo conteniendo las lneas del servicio el cual ser enviado al servidor que posee el procesador y los recursos. Una vez llegado all se ejecutara el servicio de manera local obteniendo la respuesta, transportndose luego este cdigo de regreso al proceso cliente. Los sistemas basados en agentes son el ejemplo ms conocido de este tipo de paradigma. 3.6 Sistemas Distribuidos de gran escala Los Sistemas Distribuidos se construyen en su gran mayora para aplicaciones o usos generales es decir, para todo tipo de organizacin que requiere informacin o ejecutar operaciones de carcter heterogneo o que se encuentren diseminados en mltiples servidores. Sin embargo, hay una categora de Sistemas Distribuidos que estn destinados a trabajar en aplicaciones particulares, las cuales tendrn como caracterstica la necesidad de uso de grandes recursos de informacin, ejecucin de procesos complejos o clculos matemticos de gran amplitud, asimismo, operaciones que demanda buena performance en los sistemas computadores. Para esta situacin se presentan las soluciones distribuidas de gran escala las cuales vienen a solucionar en gran parte el requerimiento urgente de un gran poder de clculo necesario para estas situaciones de carcter especial; dentro de esta categora se encuentran las aplicaciones basadas en Cluster Computing y Grid Computing. 3.6.1 Cluster Computing La implementacin Cluster est basada en la idea de utilizar un conjunto de computadoras independientes que se van a conectar entre s formando una red de tipo homognea. Esto es importante, debido a que gran parte de las caractersticas de este modelo se basan en que los computadores deben ser idnticos en sus caractersticas tcnicas y deben trabajar en un ambiente de alto acoplamiento y gran cohesin.


32

La nota caracterstica de esta implementacin es que esta red no se ver nunca ya que existe un computador maestro (front end) que ser el que se comunique con el exterior tomando las peticiones que provengan de los clientes.

Fig. 18 Modelo Cluster Computing El Cluster posee un software especial el cual se encargara de dividir la tarea en subtareas que sern repartidas entre los nodos de Cluster para la ejecucin paralela correspondiente. Una caracterstica importante del modelo Cluster es el concepto de balanceo de carga o Failover que consiste, si un computador del Cluster falla o queda fuera de lnea, los dems computadores del Cluster asumen la tarea de este en forma automtica completando asi el proceso en ejecucin.

Fig. 19 Ejemplos de implementacion Cluster Computing


33

3.6.2 Grid Computing Este modelo define la organizacin de un Sistema Distribuido atreves de la comparticin absoluta de todos los recursos computacionales existentes tanto hardware como software por parte de un computador individual con el fin de ejecutar un servicio solicitado utilizando toda infraestructura existente. En ese sentido, el comportamiento del Grid ser la de un uniprocesador virtual, para ello, no ser necesario que los equipos de cmputo sean de las mismas caractersticas, adems se pueden encontrar en diferentes lugares y trabajar utilizando diferentes tipos de redes. Para ello, el software de tipo Grid administrara los recursos organizando una arquitectura de tipo capas la cual se muestra en la siguiente figura:

Fig. 20 Organizacin de un Grid Generalmente, el modelo Grid comprende todo tipo de sistemas computadores desde Mainframes, Clusters, as como computadoras personales de todo tipo, los cuales son federados tanto de manera permanente como temporal a travs de un software que organizara los recursos como se mostro en el grafico anterior. De acuerdo a la tecnologa informtica utilizada para determinar el funcionamiento del Grid se definen cuatro categoras dentro del Grid Computing, las cuales se muestran en la tabla siguiente: Grid Type Definition Applications Examples Market

Leaders

Compute Grid

Sharing excess compute cycles (and storage) to provide a high performance computing environment

Scientific research; engineering; financial; government, engineering..(compute-intesive applications)

Mersenne grid; SETI@home.

AVAKI, Data Synapse, Dell, Entropia, IBM, Plataform, Sun, others.

Information Distributed Business Royal Bank of IBM, SGI-and


34

Grid architecture designed for large-scale dynamic sharing of commercial and technical applications and data

analytics (for analytics acceleration); financial services; retail banking; petroleum; (geophysical analysis); (Data-intensive applications).

Canada; Wachovia Corp; Morgan Stanley; Hewitt; NLI Research Institute (Nippon Life Insurance)

at some point expect Oracle to enter this market segment

Service Grid Integration of Grid and Web services concepts and technologies using grid to implement a services-oriented architecture

Enterprise and inter-enterprise applications where program to program communications needs to take place

OGSA (Open Grid Services Architecture)

Data Synapse, IBM, Sun.

Intelligent Grid

Self-managing grid utility architectures

Beyond deparment and enterprise-extended enterprises encompassing partners, suppliers, and customers

IBM Autonomic Computing IBM Workload Manager HP Planetary Computing Sun Management Center

No leaders today- expect IBM, Sun and HP to be major players as these grid types evolve.

Tabla 5 Tipos de Grid 3.7 La Web como implementacin de Sistemas Distribuidos Los conceptos tericos sobre Sistemas Distribuidos datan de muchos aos sin embargo, la implementacin prctica es relativamente reciente debido a la imposibilidad de poder lograr lo que los tecnlogos llaman la conectividad total es decir, el concepto por el cual cualquier cliente puede comunicarse con cualquier servidor. Dentro de la evolucin informtica se desarrollaron diferentes intentos por lograr este concepto, desde los sistemas operativos distribuidos (como AMOEBA), como implementaciones basadas en Middleware (como CORBA), cada uno de ellos demostr una debilidad inherente para lograr la conectividad que se requera. Posteriormente, sin proponrselo, Tim Benners Lee al desarrollar el concepto HTML y a travs de la creacin e implementacin de la World Wide Web construira el entorno de integracin de aplicaciones informticas que las tecnologas anteriores no pudieron alcanzar, por ello, la Web es considerada la plataforma ideal para la implantacin de soluciones de tipo distribuidas. La Web aprovecha eficientemente la infraestructura fsica definida por la Internet y permite que mquinas de diferente naturaleza y tecnologa puedan intercambiar mensajes no importando el lugar donde se encuentren, como lo muestra el grafico siguiente:


35

Fig. 21 Organizacin fsica de la web 3.7.1 Estndares de la Web Para que una solucin distribuida pueda correr atreves del entorno Web se requiere obligatoriamente cumplir una serie de estndares exigidos por este entorno y los cuales son: a) El protocolo de comunicacin ser HTTP b) El formato de documento o interface de usuario de la aplicacin deber ser HTML c) El modelo de referencia para la comunicacin distribuida deber ser el modelo TCP/IP de 4 capas d) El formato de intercambio de datos deber ser XML Dado, el rpido crecimiento de la Web y su aceptacin masiva como el entorno de desarrollo y ejecucin de aplicaciones que es hoy da, estos estndares son utilizados por todas las aplicaciones sin importar la tecnologa en la que estn construidas ni la plataforma en la que estn alojadas. 3.7.2 Debilidades de la Web Si bien es cierto, la Web es el estndar actual para la ejecucin de aplicaciones distribuidas, este entorno tiene algunas debilidades inherentes a su funcionamiento, como son: a) El formato HTML es esttico por naturaleza, lo que quiere decir que su contenido siempre ser el mismo, lo cual imposibilitara su uso para operaciones transaccionales o de gestin de contenidos. b) El protocolo HTTP es de tipo useless, es decir sin estado, esto quiere decir que no tiene la capacidad de recordar operaciones realizadas por un mismo cliente en tiempos anteriores, por lo que sera imposible realizar operaciones de acumulacin de transacciones, tan necesarias en sistemas de ventas o consultas. c) La aplicacin Web est diseada con el fin de que el cliente de dicha aplicacin sea un ser humano, de ah la explicacin del uso en la pagina HTML de controles visuales como cajas, botones, combos, etc. Pero, este tipo de aplicacin sera


36

totalmente intil si el cliente a interactuar fuera otra aplicacin ms o menos compleja que la inicial (por ejemplo el modelo B2B). Debido a ello, el enfoque actual es la mejora de las caractersticas de la tecnologa Web desarrollando conceptos como Web Services, HTML Dinmica, Web Semntica, Ontologas y otros destinados a subsanar las deficiencias observadas y potenciar an ms el uso de la Web como la implementacin ms utilizada de nuestro tiempo. 3.7.3 Generacin de HTML Dinmica Una de las principales dificultades de la implementacin de las aplicaciones distribuidas bajo entorno Web fue sin lugar a dudas la generacin de las pginas HTML con contenido dinmico. Al respecto, se desarrollaron tres modalidades de generacin de pginas HTML de estas caractersticas que fueron las siguientes: a) CGI Common Gateware Interface: En esta tecnologa cada peticin HTTP genera un Nuevo proceso el cual se encarga de analizar la solicitud y generar un resultado. Cada proceso corresponder a una transaccin determinada. Es flexible e ideal para pequeas aplicaciones con pocos clientes concurrentes. El problema es que no escala adecuadamente. b) Plug-ins: En esta tecnologa la pgina HTML es generada debido a la ejecucin de un componente de cdigo perteneciente a un lenguaje determinado, el cual al ejecutarse incorporara etiquetas HTML y completar la descripcin de la pgina que ser devuelta al cliente solicitante. Tiene un mejor rendimiento y esta ms extensamente utilizada. Hay que tener en cuenta, sin embargo, niveles de seguridad y confiabilidad al usar esta tecnologa, debido a los posibles huecos de seguridad que podran producirse por el uso de dicho Plug-in. c) Servidor especializado: Se definen servidores Web que por su tecnologa generan la pgina dinmica de manera ptima con una facilidad de desarrollo debido a las herramientas que poseen. Sin embargo, los lenguajes que utilizan no son estndares y su configuracin es bastante rgida. 3.7.3.1 Tipos de Plug-ins 3.7.3.1.1 HTML incrustado en cdigo Este tipo de plug-in define a un componente de cdigo que al recibir una peticin de servicio la ejecuta en su lenguaje nativo y posteriormente genera una pgina HTML y coloca en ella la respuesta obtenida para luego ser enviada al cliente solicitante. Este tipo de plug-in es fcilmente optimizable y se centra en la lgica de negocios de la aplicacin. Ejemplos de este tipo son los Servlets y lenguajes como Perl, Python. 3.7.3.1.2 Cdigo incrustado en HTML En este tipo de plug-in la pagina HTML ya existe previamente, y en ella se colocan etiquetas pertenecientes a un lenguaje determinado, que al ejecutarse procesan el servicio solicitado y generan etiquetas HTML que se agregan a las ya existentes, envindose posteriormente el resultado al cliente. Este tipo de plug-in est centrado en la interface de usuario, adems son fciles de crear y modificar, as como no requieren grandes formalismos en su implementacin. Ejemplos de este tipo son JSP, PHP, ASP y ASPX.


37

3.7.4 Estructura de una aplicacin Web En modo conceptual una aplicacin web est constituida por un cliente que utilizan un navegador para visualizar la interface de entrada, un servidor web que es el que recibe la peticin del cliente mediante un protocolo HTTP, un servidor de aplicaciones que tiene la lgica de negocios, es decir, los servicios a ejecutar y un servidor de base de datos que contiene el repositorio de informacin de la aplicacin. En el grafico siguiente se muestra este modelo:

Fig. 22 Aplicacin web

Por otro lado, del punto de vista informtico los tres componentes bsicos de la aplicacin web pueden ser de cualquier tecnologa disponible manteniendo por ello el carcter heterogneo que los Sistemas Distribuidos definen como se visualiza en el siguiente grafico:

Fig. 23 Componentes de una aplicacin web

3.7.5 Arquitectura de una aplicacin web Tradicionalmente, el advenimiento de las aplicaciones basadas en LAN, trajo como consecuencia la adopcin del patrn de arquitectura cliente/servidor de tres capas, interface de usuario, lgica de negocios y acceso a los datos, el cual se desempeo exitosamente durante parte de la dcada de los 80 y la primera parte de la dcada de los 90. Este patrn planteaba como condicin necesaria que tanto el cliente como el servidor deberan tener por lo menos un elemento de la aplicacin instalado en el computador correspondiente. La adopcin del entorno web trajo un gran inconveniente a este patrn, debido a que normalmente todos los elementos de la aplicacin web residen en el servidor


38

de manera obligatoria. Por ello, algunas empresas de desarrollo tecnolgico (por ejemplo BEA WEBLOGIC) hicieron una adaptacin del modelo cliente servidor para ser usado en la web, como se presenta en la siguiente figura:

Fig. 24 Modelo de tres capas aplicado a la web Esta adaptacin no tuvo mayor uso debido a la presuncin errnea de que el navegador web es parte de la aplicacin, si esto fuera cierto, tendramos que aceptar que el monitor de la computadora seria parte de una aplicacin basada en ventanas. Por esa razn, se definira un patrn de arquitectura destinado especficamente para el entorno web, dicho patrn se conoce con el nombre de MVC (Modelo Vista Controlador) el cual se muestra en el siguiente grfico:

Fig. 25 Arquitectura MBC Este patrn utiliza tres componentes fundamentales que son: a) Controlador: Es el componente que recoge la peticin del cliente web y transferirlo ya sea al componente vista o al modelo, segn sea el caso. Como su nombre lo indica controla la ejecucin del servicio hasta la emisin de la respuesta. b) Modelo: Es el componente que contiene los servicios disponibles en la aplicacin y adems es el que genera la respuesta solicitada por el cliente. Es el anlogo a la lgica de negocios del modelo cliente servidor. c) Vista: Es el componente que genera la pgina de entrada y la de salida conteniendo la respuesta del servicio. Puede ser solicitado directamente por el


39

controlador o recibir la respuesta del componente modelo para la generacin de la pgina de salida. 3.8 Aplicaciones mviles Uno de los considerando fundamentales en la implementacin de los Sistemas Distribuidos es la tecnologa heterognea, es decir, la posibilidad de que cualquier cliente pueda comunicarse con cualquier servidor. Y al hablar de cualquier cliente no nos referimos exclusivamente clientes basados en computadoras sino en otras tecnologas hardware igualmente disponibles. En los ltimos aos los dispositivos mviles han tenido un crecimiento bastante grande tanto en su uso como en el nivel de operaciones que pueden realizar, y esto debido al gran impulso recibido por parte de los fabricantes de componentes como Intel, AMD y otros que han permitido la aparicin de nuevos equipos celulares con mayor potencia, mejor resolucin y mayor cantidad de memoria y que por lo tanto, son una alternativa ideal para construir aplicaciones que corran en estos terminales. La expectativa es grande, en el ao 2005, se esperaba ms de mil millones de usuarios mviles en la Internet, as como la aparicin de navegadores optimizados para dispositivos mviles como Openwave, Opera y otros, que permitiran que un cliente pudiera solicitar servicios a la web atreves de este medio. 3.8.1 La necesidad de las aplicaciones mviles y su adaptacin a la web Si se deseara desarrollar aplicaciones informticas que pudieran correr en un dispositivo mvil y que pudieran conectarse con servicios externos provistos por servidores conectados a la web tendra que resolverse un problema fundamental, el cual es la necesidad de adaptar la interface de usuario a cada tipo de dispositivo, sea PC o sea mvil. Para lograr este objetivo las acciones que deberan tomarse en cuenta serian: a) Separar la lgica de negocios del interface de usuario b) Utilizar mtodos estndar de comunicacin entre la lgica de negocios y el interface de usuario c) Usar herramientas que permitan adaptar rpidamente las aplicaciones a los nuevos tipos de dispositivos que irn apareciendo. d) Desarrollar algn tipo de mecanismo de compatibilidad entre protocolo HTTP que utiliza la web con el protocolo que utiliza las aplicaciones mviles que es el protocolo WAP. Para lograr ello, los fabricantes de aplicaciones desarrollaron tecnologas que permitieran que las aplicaciones mviles pudieran accesar a los mismos servicios que una aplicacin web. Inicialmente, se construyeron servidores paralelos tanto para cliente web como cliente WAP los cuales podan accesar a la lgica de negocios atreves del formato XML, como se muestra en la siguiente figura:


40

Fig. 26 Comparacin entre aplicaciones web y mvil Posteriormente, los fabricantes de base de datos presentan una alternativa al modelo anterior integrando la lgica de negocios con la base de datos, tal como se muestra en el grafico siguiente:

Fig. 27 Solucin de implementacin web y mvil orientada a datos Una variacin propuesta posteriormente, permita la unificacin de la interface de entrada, en este caso HTML, colocando una pasarela en el lado del servidor WAP para la traduccin de las pginas WML en paginas HTML, como se indica en el siguiente grfico:

Fig. 28 Uso de adaptador en aplicacin mvil


41

3.8.2 Arquitectura I-MODE Con la aparicin de las nuevas tecnologas y nuevas herramientas las aplicaciones mviles pueden integrarse de manera eficiente con el resto del Sistema Distribuido en una forma transparente, permitiendo por ello solicitar servicios igual que cualquier otro computador existente en la red distribuida. Una de las implementaciones ms conocidas es la arquitectura I-MODE, la cual define productos tecnolgicos y protocolos destinados para este fin, obtenindose una implementacin como la mostrada en el siguiente grfico:

Fig. 29 Arquitectura I-MODE

Aqu se puede observar como el dispositivo mvil puede interactuar directamente con cualquier servicio del Internet utilizando para ello protocolo HTTP de comunicaciones as como infraestructura propia de esta arquitectura. Finalmente, se puede decir que I-MODE es una tecnologa que compite con tecnologa WAP y que puede ser utilizada para navegar en paginas diseadas en forma especfica para mviles y PDAs. 3.8.3 La tecnologa Java y las aplicaciones mviles Una de las principales tecnologas que ha impulsado fuertemente el desarrollo de aplicaciones mviles en los ltimos aos, ha sido indudablemente Java, atreves de JavaME, la suite de libreras destinadas a aplicaciones mviles y que est enmarcada dentro de la poltica de desarrollar programas informticos usando Java a todo nivel, tal como se muestra en el grfico siguiente:

Fig. 30 Infraestructura Java


42

Uno de los principales aportes de JavaME ha sido el manejo eficiente del protocolo WAP el cual puede ser utilizado de manera transparente en Java logrando posteriormente utilizar el protocolo HTTP permitiendo conectarse directamente a servicios web sin necesidad de pasar por pasarelas que adapten los mensajes al protocolo apropiado. Para ello, existen dos opciones de interaccin WAP con Java: a) WML Nativo interactuando con Java. En esta opcin las paginas WML invocan directamente a componente JavaME dejando a estas la responsabilidad de la interaccin con los servicios web.

Fig. 31 Relacin en WML y J2ME

Esta implementacin tiene como limitaciones un uso intensivo de stack lo que obliga a un uso intensivo de memoria y adems limita las interdependencias entre los elementos de la aplicacin. b) Uso de un navegador que soporta Java. En esta opcin la invocacin de los servicios es directamente usando XML o interface Java con lo cual se logra una mayor integracin de los elementos de la aplicacin.

Fig. 32 Uso de browser con J2ME


43

Una ventaja de este modelo es que el navegador utilizado puede actualizarse dinmicamente y adems el lenguaje usado para la aplicacin es compatible con el utilizado en aplicaciones de otros entornos lo cual hace que su uso sea ms sencillo. Gracias a la tecnologa Java se realizan aplicaciones mviles de todo tipo, debido a su forma sencilla de implementacin y a su fcil manejo de protocolo HTTP. En el siguiente grfico se muestra la forma como se carga una aplicacin mvil basada en Java desde la web:

Fig. 33 Ejecucin de una aplicacin mvil en Java

No hay lmites para el tipo de usos que los dispositivos mviles integrados a una solucin distribuida puedan realizar, desde aplicaciones de ingeniera, juegos, servicios orientados al consumo, etc. Han logrado colocarse en una situacin expectante dentro del mundo de los negocios y su crecimiento est asegurado para los prximos aos. Esto al mismo tiempo ha trado por consecuencia la mejora de las caractersticas tcnicas de los dispositivos mviles para soportar el nuevo nmero de usos que se estn dando, como se aprecia en el grfico siguiente:

Fig. 34 Productos implementados bajo JavaME


Documents

Funcionamiento de Sistemas