Clase 2 - Cliente Servidor

Sistemas de Clase Mundial ERP y su Arquitectura

Implantando un ERP: Proceso Distribuido, Cliente Servidor y Agrupaciones. Al pensar en las arquitectura actual que poseen la mayoría de los ERP en el mundo, solo nos queda pensar en la arquitectura mas próxima que hasta hoy es pionera en sistemas en producción. En el detalle siguiente, se plantea una serie de estructuras de implantación, sobre las cuales sólo se comentan sus principales características y beneficios. Ya que como lo hemos dicho; la selección de la mejor arquitectura dependerá de muchos factores; siendo de decisivo la el gusto personal y particular de cada Empresa. Con el incremento en la disponibilidad de maquinas y servidores, ha habido una mayor tendencia hacia el proceso de datos distribuido (PDD), en el que los procesadores, datos y otros elementos de los sistema de proceso de datos pueden estar distribuidos en una organización. Un sistema PDD implica la partición de la función que cumplen los computadores y puede también, conllevar una organización y administración distribuida de las bases de datos, el control de los dispositivos y el control de las interacciones ( por ejemplo redes). Los computadores personales se utilizan para soportar aplicaciones amigables, en cambio, los servidores almacenan las bases de datos corporativas y el software de sistemas de información y gestión de base de datos. Son necesarios los enlaces entre un computador personal y el servidor, así como entre cada uno de los computadores personales. Apoyados por la evolución de las capacidades distribuidas de los sistemas operativos y de las utilidades de soporte es que se esta tratando al computador personal como una simple terminal hasta el punto de llegar a tener un alto grado de integración entre las aplicaciones de la misma y la base de datos del servidor. Se ha explorado un espectro de estas capacidades, como por ejemplo: ARQUITECTURA DE COMUNICACIONES: Este es el software que da soporte a una red de computadores independientes. Ofrece soporte para aplicaciones distribuidas, tales como correo electrónico, transferencia de archivos y acceso a terminales remotas. Sin embargo, los computadores conservan una identidad diferenciada para el usuario y para las aplicaciones, las cuales se deben comunicar con otros computadores mediante una referencia explícita. Cada computador tiene su propio sistema operativo y es posible una mezcla heterogénea de computadores y sistemas operativos, siempre que todas las máquinas soporten la misma arquitectura de comunicaciones (Ejemplo: el conjunto de protocolos TCP/IP). SISTEMA OPERATIVO DE RED: Es una configuración en la que existe una red de máquinas de aplicación, generalmente estaciones de trabajo monousuario y uno o más servidores. Los servidores proporcionan servicios o aplicaciones a toda la red. Cada computador tiene su propio S.O. privado. El S.O. de red es simplemente un añadido al S.O. local que permite a los servidores de aplicación interactuar con los servidores. El usuario es consciente de que existen múltiples computadores independientes y debe tratar con ellos explícitamente. SISTEMAS OPERATIVOS DISTRIBUIDOS: Es un S.O. común compartido por una red de computadores. Para los usuarios es como un S.O. centralizado, les proporciona un acceso transparente a los recursos de numerosos

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

computadores. Un sistema operativo distribuido puede depender de una arquitectura de comunicaciones para las funciones básicas de comunicación. PROCESO CLIENTE / SERVIDOR Lo más significativo en los sistemas de información, en los últimos años, ha sido el avance del proceso cliente / servidor. Este modo de procesamiento esta remplazando a gran velocidad tanto a los métodos de procesamiento basados en computadores centrales, como al proceso centralizado y otras formas alternativas del proceso distribuidos de datos. ¿QUÉ ES EL PROCESO CLIENTE /SERVIDOR?: Algunos de los términos que se encuentran generalmente en las descripciones de las aplicaciones y productos cliente / servidor son: Interfaz de programas de aplicación (API siglas en ingles): Un conjunto de funciones y programas de llamada que permiten comunicarse a clientes y servidores. Cliente: El que solicita información a la red, generalmente una PC o estación de trabajo, y que puede consultar bases de datos u otra información del servidor. Middleware: Un conjunto de controladores, API u otro software que mejora la conectividad entre las aplicaciones de cliente y un servidor. Base de Datos Relacional: Una base de datos en donde el acceso a la información esta limitado por la selección de filas que satisfacen todos los criterios de búsqueda. Servidor: Un computador, generalmente una estación de trabajo muy potente, un mini computador o un mainframe, que contiene información para que los clientes de red puedan manipularla. Lenguaje de Consulta Estructurado (SQL siglas en ingles): Un lenguaje desarrollado por IBM y estandarizado por ANSI para direccionar, crear, actualizar o consultar bases de datos relaciónales. La figura intenta resumir lo esencial de los conceptos cliente / servidor Un entorno cliente / servidor está poblado de clientes y servidores. Las máquinas cliente (PC monousuario o puestos de trabajo) ofrecen una interfaz muy amigable para el usuario final. Los puestos de cliente presentan, en general, un tipo de interfaz gráfica que es más cómoda para los usuarios. En un entorno cliente / servidor, cada servidor ofrece una serie de servicios de usuario compartidos a los clientes. El tipo más común de servidor es el servidor de base de datos que permite el acceso a los clientes y el uso de un sistema de computación para gestionar la base de datos. La diferencia de una configuración cliente / servidor de cualquier otro distribuido normal y corriente es una serie de características: •

•

Hay una gran confianza en depositar aplicaciones amigables para los usuarios en sus propios sistemas. Esto da a los usuarios un alto grado de control sobre la medida del tiempo y el estilo de utilización del computador y ofrece a los directores de departamentos la posibilidad de responder a sus necesidades locales. Al mismo tiempo que las aplicaciones se dispersan se produce un énfasis en la centralización de las bases de datos corporativas y de muchas funciones de utilidad y de gestión de la red. Esto habilita una gestión corporativa para mantener un control global de la inversión total en sistemas de información e informática y, además permite una gestión corporativa que ofrezca interoperatividad, de manera que los sistemas queden vinculados. Al mismo tiempo alivia a los departamentos individuales y divisiones de gran parte de la carga de mantener servicios de computación, permitiéndoles elegir cualquier tipo de máquina e interfaz que necesitan para acceder a los datos y a la información.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

•

•

Existe un compromiso, tanto por parte de las organizaciones de usuarios como de los fabricantes, hacia los sistemas abiertos y modulares. Esto significa que los usuarios disponen de ofertas mejores en la elección de productos y en la combinación de equipos de varios fabricantes. El trabajo en red es fundamental para la operación. De este modo, la gestión y seguridad de la red tienen una prioridad alta en la organización y operación de los sistemas de información.

APLICACIONES CLIENTE / SERVIDOR: La característica central de la arquitectura cliente / servidor es la ubicación de las tareas (del nivel de aplicación) entre clientes y servidores. Tanto en el cliente como en el servidor el software básico es un sistema operativo. Las plataformas y los sistemas operativos del cliente y del servidor pueden ser diferentes. El software de comunicaciones (Ej. TCP IP) es el que permite ínter-operar a cliente y servidor. El objeto de todo este software de soporte es proporcionar una base para las aplicaciones distribuidas. En tanto que un cliente particular y un servidor compartan los mismos protocolos de comunicación y soporten las mismas aplicaciones las diferencias entre plataformas y sistemas operativos no son relevantes. Las funciones reales de la aplicación pueden repartirse entre cliente y servidor de forma que se optimicen los recursos de la red y de la plataforma así como la capacidad de los usuarios para realizar varias tareas y cooperar el uno con el otro en el uso de los recursos compartidos. En algunos casos estos requisitos dictan que el grueso del software de la aplicación se ejecute en al servidor, mientras que en otros casos la mayor parte de la lógica de la aplicación se ubica en el cliente. En la mayoría de los sistemas cliente / servidor, se hace un gran hincapié en ofrecer una interfaz de usuario grafico (GUI, Grafica l User Interfaz)

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

Aplicaciones de base de datos: Como el ejemplo que ilustra el “concepto de división de la lógica de una aplicación entre cliente y servidor” considérese la familia más común de aplicaciones cliente / servidor: aquellas que utilizan base de datos relaciónales. La interacción entre el cliente y el servidor se hace en forma de transacciones, donde el cliente realiza una petición a la base de datos y recibe una respuesta de aquella. El servidor mantiene la base de datos mediante complejos sistemas gestores de base de datos. En las maquinas clientes se pueden guardar una variedad de aplicaciones que hagan uso de la base de datos. El software que enlaza al cliente con el servidor es el que le permite al cliente realizar peticiones de acceso a la base de datos del servidor (Ej. SQL).

Supongamos que contamos con un servidor que solo se debe ocupar de la gestión de la base de datos -una base de datos de 1 millón de archivos por ej.- y que toda la lógica de la aplicación –el software de tratamiento numérico u otras clases de análisis de datos- resida en el cliente. Y el cliente realiza una serie de consultas, que da como resultados 1 solo archivo. Esta aplicación se adapta bien a la arquitectura cliente / servidor por dos razones: 1. Contener la base de datos requiere de un disco grande o una serie de discos, una PC y una arquitectura de E/S de alta velocidad. 2. Mover todo el archivo de la base de datos al cliente para realizar la búsqueda introducirá una carga de trafico demasiado grande en la red. Por lo tanto no es suficiente con que el servidor solo sea capaz de recuperar archivos en nombre del cliente, el servidor debe disponer de la lógica de la base de datos que permita realizar búsquedas de parte del cliente. Ahora consideremos que el cliente realiza una sola consulta que da como resultado la transmisión de 300.000 archivos por la red, esto es inaceptable. Una solución al problema que conserva la arquitectura cliente / servidor es mover parte de la lógica de la aplicación al servidor, que permita a este realizar análisis de datos, así como recuperación y análisis de datos.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

CLASES DE APLICACIONES CLIENTE / SERVIDOR: Dentro del entorno general cliente / servidor se dispone de una gama de posibles implementaciones que “dividen el trabajo entre el cliente y el servidor de manera diferente.

1. Proceso basado en una maquina central: el proceso basado en host(maquina central)

2.

3.

4.

es en el cual casi todo el tratamiento se realiza en el computador central. La interfaz de usuario consiste a menudo en un terminal tonto, incluso si el usuario emplea un microprocesador el puesto de usuario se limita en general al papel de emulador de terminales. Proceso basado en servidor: es aquel en que el servidor es básicamente responsable de ofrecer una interfaz de usuario grafica, mientras casi todo el tratamiento lo hace el servidor. La razón fundamental que subyace en dichas configuraciones es que los puestos de trabajo se adaptan mejor a una interfaz amigable y que las bases de datos y las aplicaciones pueden mantenerse fácilmente en sistemas centrales. Este tipo de configuraciones no se presta a ganancias significativas. Proceso basado en el cliente: en el otro extremo, casi todo el proceso de la aplicación puede hacerse en el cliente, con la excepción de las rutinas de validación de datos y otras funciones lógicas de la base de datos que se realizan mejor en el servidor. Permite al usuario utilizar aplicaciones a la medida de sus necesidades locales. Proceso cooperativo: el proceso de la aplicación se lleva a cabo de forma optimizada, aprovechando la potencia de las maquinas cliente y servidora y la distribución de los datos. Esta configuración es más compleja de instalar y mantener, pero a largo plazo, este tipo de configuración puede ofrecer una mayor ganancia de productividad del usuario y una mayor eficacia de la red.

Los modelos con las configuraciones en las que gran parte de la carga esta en el cliente son llamados cliente grueso, soportan entre 25 y 150 usuarios. El mayor beneficio de esta configuración es que saca provecho del computador de escritorio, descargando a los servidores del procesamiento de aplicaciones, haciéndolos más eficientes y disminuyendo la posibilidad de que sean un cuello de botella. Si embargo existen barios inconvenientes pues la utilización de mas funciones sobrecarga rápidamente la capacidad de las maquinas de escritorio. Esta configuración es difícil de mantener, actualizar o reemplazar aplicaciones distribuidas entre cintos de maquinas de escritorio. Los modelos con las configuraciones en las que la menor parte de la carga esta en el cliente son llamados cliente delgado, este enfoque casi imita al enfoque de host centralizado.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

ARQUITECTURA CLIENTE / SERVIDOR DE TRES CAPAS: La arquitectura tradicional cliente / servidor implica dos niveles o capas: una capa cliente y una servidor. En la arquitectura de tres capas el software de aplicación esta distribuido en tres tipos de maquinas: una maquina de usuario, un servidor de capa intermedia y servidor final (Backend). La maquina de usuario es la maquina de cliente y el modelo de tres capas utiliza, generalmente, un cliente delgado. Las maquinas de capa intermedia son esencialmente pasarelas entre los clientes delgado y una variedad de servidores finales de base de datos, pueden convertir protocolos y traducir un tipo de consulta de base de datos a otro. Además puede mezclar e integrar resultados de distintas fuentes de datos. Por ultimo puede servir como pasarela entre aplicaciones de computador de escritorio y antiguas aplicaciones finales actuando de mediadoras entre los dos mundos. La interacción entre el servidor de capa intermedia y el servidor final también sigue el modelo cliente / servidor. De esta forma el sistema de capa intermedia actúa a la ves como cliente y como servidor. CONSISTENCIA DE LA CACHE DE ARCHIVOS: Cuando se utiliza un servidor de archivos, el rendimiento de la E/S referente a los accesos locales a archivos puede degradarse por causa del retardo introducido por la red. Para reducir esta carga, los sistemas individuales pueden usar caches de archivos para almacenar los registros a los que se ha accedido hace poco. Cuando un proceso realiza un acceso a archivo, la petición es cursada, en primer lugar, a la cache del puesto de trabajo del proceso. Si no satisface la petición, se pasa al disco local o al servidor donde se almacena el archivo. Una vez en el servidor, se examina primero su cache y si se produce un fallo de acceso, se accederá al disco del servidor. Se suele utilizar un procedimiento de doble cache para reducir el trafico de comunicaciones (cache del cliente) y la E/S a disco (cache del servidor). MIDDLEWARE: Es un conjunto de interfaces y protocolos estándares de comunicación. Con interfaces estándares de programación, es fácil de implementar una misma aplicación en una variedad de tipos de servidores y de puestos de trabajo. Esta tiene un beneficio para los clientes puesto que estos compran aplicaciones no servidores, los clientes solo elegirán entre aquellos servidores donde se ejecuten las aplicaciones que ellos deseen. Se necesitarán protocolos estándares para enlazar las distintas interfaces de servidor con los clientes que necesiten acceder a ellos. Existe una gran variedad de paquetes middleware, simples o complejos. Todos tienen en común la capacidad de ocultar las complejidades y diferencias de los diferentes protocolos de red y sistemas operativos. ARQUITESTURA MIDDLEWARE: La figura propone el papel del middleware en una arquitectura cliente/servidor. El papel exacto del componente middleware dependerá del estilo del proceso distribuido que se utilice.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

- Papel del middleware en la arquitectura cliente/servidor. En el middleware existen componentes de cliente y servidor. La finalidad básica del middleware es hacer que una aplicación o usuario del cliente acceda a una serie de servicios del servidor sin preocuparse de las diferencias entre servidores. Considerando un área específica de aplicación, se supone que el SQL proporciona una forma estándar de acceder a un base de datos relacional tanto a usuarios o aplicaciones locales como remotos. Sin embargo muchos fabricantes de base de datos relacionales, aunque también soportan SQL le han añadido sus propias ampliaciones, logrando de esta forma una diferenciación de productos, pero a la vez posibles incompatibilidades. Por ejemplo considérese el caso de un sistema distribuido en el que los datos principales están guardados en una base de datos Gupta, mientras que otro tipo de información adicional, pero necesaria está en una base de datos Oracle. Cuando un usuario necesite acceder a determinados registros, no deberá preocuparse del fabricante de la base de datos que contiene los registros que necesite. El middleware proporciona una capa software que permite un acceso uniforme a estos sistemas diferentes.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

•

Visión lógica del middleware.

Es interesante considerar el papel del middleware desde un punto de vista lógico más que desde la implementación . El middleware permite cumplir la promesa del proceso distribuido. El sistema distribuido entero puede verse como un conjunto de aplicaciones y recursos disponibles para los usuarios. Estos no necesitan preocuparse de la ubicación de los datos ni de la ubicación de las aplicaciones. Todas las aplicaciones operan sobre una interfaz uniforme de programación de aplicaciones (API). Todas las aplicaciones operan sobre una interfaz uniforme de programación de aplicaciones (API). El middleware, que atraviesa todas las plataformas clientes y servidoras, es el responsable de encaminar las peticiones de los clientes al servidor aprEsta instalación es un ejemplo de cómo se aplica el middleware para integrar productos dispares, en este caso, se usa el middleware para soslayar las incompatibilidades de redes y sistemas operativos. Una red central conecta redes DECnet. Novell y TCP/IP. El middleware, que se ejecuta en cada componente de la red, asegura que todos los usuarios de la red disponen de un acceso transparente a las aplicaciones y los recursos de cualquiera de las tres redes. Aunque hay una amplia variedad de productos del middleware, estos se basan normalmente en uno de los mecanismos básicos: el paso de mensajes o llamada a procedimiento remoto. Ejecutando en la red Novell Hay aplicaciones, middleware, aplicaciones Software de red Novell y OS/2 de IBM

Ejecutando sobre la DECnet y en los PC hay y middleware.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

PASO DISTRIBUIDO DE MENSAJES En los sistemas de procesos distribuidos reales se suele dar el caso de que los computadores no compartan una memoria principal: cada una es un sistema aislado. Por lo tanto, no es posible, emplear técnicas de comunicación entre procesadores basadas en memoria compartida, como son los semáforos y el uso de un área de memoria común. En su lugar, se usa técnicas basadas en el paso de mensajes. Entre los procedimientos más usuales está la aplicación directa de los mensajes, tal como se hace en un sistema único. El segundo es una técnica distinta que se basa en el paso de mensajes como función básica: la llamada a procedimiento remoto.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

Paso distribuido de mensajes para implementar la funcionalidad cliente/servidor. Un proceso cliente solicita un servicio y envía, a un proceso servidor, un mensaje que contiene un petición dl servicio. El proceso servidor satisface la petición y envía un mensaje de respuesta. En su forma más simple, sólo se necesita 2 funciones: Send y Receive. La función Send debe especificar un destino e incluir el contenido del mensaje. La función Receive dice de quien se desea recibir mensajes (incluyendo a todos) y proporciona un almacenamiento intermedio donde se guardará el mensaje.

Los procesos hacen uso de los servicios de un módulo de paso de mensajes. Las solicitudes de servicios pueden expresarse en forma de primitivas y parámetros. Una primitiva especifica la función a realizar y los parámetros se usan para pasar datos e información de control. El formato real de las primitivas depende del software de paso de mensajes. Pueden ser llamadas a procedimientos o mensajes a un proceso que forme parte del sistema operativo. La primitiva Send la utiliza el proceso que quiere enviar el mensaje. Sus parámetros son el identificador del proceso de destino y el contenido del mensaje. El módulo de paso de mensajes construirá una unidad de datos que incluya estos dos elementos. Esta unidad de datos se envía a la máquina que alberga el proceso de destino mediante algún tipo de servicio de comunicaciones, como TCP/IP. Cuando se recibe la unidad de datos en el sistema de destino, se encaminará, mediante el servicio de comunicaciones, hacia el módulo de paso de mensajes. Este módulo examina el campo IdProceso y almacena el mensaje en el buffer de dicho proceso. En este escenario, el proceso receptor debe anunciar su intención de recibir mensajes, designando un área de almacenamiento intermedio e informando al módulo de paso de mensajes por medio de una primitiva Receive. Una solución alternativa consiste en no exigir dicho anuncio. En su lugar, cuando el módulo de paso de mensajes, avisará al proceso de destino con algún tipo de señal de recepción y después hará que el mensaje recibido esté disponible en un buffer compartido. FIABILIDAD FRENTE A NO FIABILIDAD: Un servicio de paso de mensajes fiable que garantiza la entrega, si es posible. Dicho servicio deberá hacer uso de un protocolo de transporte fiable o de alguna lógica similar y llevaría a cabo control de errores, acuse de recibo, retransmisión y reordenación de mensajes desordenados. Como la entrega está garantizada, no es necesario hacer que el proceso emisor sepa que se entregó el mensaje. Sin embargo, puede ser útil proporcionar un acuse Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

de recibo al proceso emisor de manera que se entere que ya se ha entregado. En cualquier caso, si el servicio falla al completar la entrega, se notificará de esta falla al proceso emisor. En el otro extremo, el servicio de paso de mensajes puede enviar simplemente el mensaje a la red de comunicaciones sin informar de su éxito o de su fracaso. Esta alternativa reduce enormemente la complejidad y la sobrecarga de proceso y de comunicaciones en el servicio de paso de mensajes. Las aplicaciones que necesiten confirmación de que se han enviado un mensaje pueden usar mensajes de repetición y respuesta para cumplir con tal requisito. BLOQUEANTE FRENTE A NO BLOQUEANTE: Con primitivas no bloqueantes, o asíncronas, un proceso no queda suspendido como resultado de un Send o un Receive. De esta forma, cuando un proceso emita una primitiva Send, el sistema operativo le devolverá el control tan pronto como el mensaje se haya puesto en cola para su transmisión o se haya hecho una copia. Si no se hace copia, cualquier cambio que realice el emisor en el mensaje antes de la transmisión , o durante la misma, se ara bajo la responsabilidad del mismo. Cuando el mensaje se aya trasmitido o se aya copiado a un lugar seguro para su posterior trasmisión, se interrumpe al proceso emisor para informarle de que el buffer del mensaje puede reciclarse. De forma similar Receive no bloqueante lo emite un proceso para después seguir ejecutándose. Cuando llega un mensaje se informa al proceso mediante interrupción o bien este puede comprobar periódicamente su estado. Las primitivas no bloqueantes ofrecen un empleo eficiente y flexible del servicio de paso de mensajes. Las desventajas de este enfoque es que los programas que emplean esta primitivas son difíciles de probar y depurar. Las secuencias irreproducibles dependientes del tiempo pueden originar problemas sutiles y complicados. La otra alternativa es emplear primitivas bloqueantes, o síncronas. Un Send bloqueante no devuelve el control al proceso emisor hasta que el mensaje se haya trasmitido (servicio no fiable) o hasta que el mensaje se haya enviado y obtenido un acuse de recibo (servicio fiable).Un Receive bloqueante no devuelve el control hasta ubicado en el buffer asignado. LLAMADAS A PROCEDIMIENTO REMOTO Una variante del modelo básico de paso de menaje es la llamada a procedimiento remoto (RPC). Es un método común muy aceptado actualmente para encapsular la comunicación en un sistema distribuido. Lo fundamental de la técnica es permitir que programas de máquinas diferentes interactúen mediante la semántica de llamadas retorno a simples procedimientos, como si los dos programas estuvieran en la misma máquina. Es decir, se va a usar la llamada a procedimiento para acceder a servicios remotos. La popularidad de este enfoque se debe a las siguientes ventajas. • •

• •

La llamada a procedimiento es una abstracción muy usada, aceptada y bien comprendida. El empleo de llamadas a procedimientos remoto permite que las interfaces remotas se especifiquen como un conjunto de operaciones con nombre y de un tipo determinado. De este modo, la interfaz puede documentarse de forma clara y los problemas distribuidos pueden comprobarse estadísticamente para detectar errores tipo. Como la interfaz es estándar y está definida de forma precisa, el código de comunicaciones de una aplicación puede generarse automáticamente. Como la interfaz es estándar y está definida de forma precisa, los desarrolladores de software pueden escribir módulos clientes y servidores que pueden trasladarse ente computadores y sistemas operativos con pocas modificaciones. Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

El mecanismos de las llamadas a procedimiento remoto puede considerarse como un refinamiento del paso de mensajes fiables y bloqueantes. El programa llamador realiza una llamada normal a un procedimiento con los parámetros situados en su máquina. Por ejemplo: CALL P(X,Y) Donde: P = nombre del procedimiento. X = argumentos pasados. Y = valores devueltos. El hecho de que se intente ejecutar un procedimiento remoto de otra máquina puede resultar o no trasparente al usuario. El espacio de direcciones del llamador debe incluir un procedimiento P de presentación, o debe enlazarse dinámicamente en el momento de la llamada. Este procedimiento crea un mensaje que identifica al procedimiento llamado, e incorpora los parámetros. Luego envía el mensaje y queda en espera de una respuesta. Una vez recibida la respuesta, el procedimiento de presentación retorna al programa llamador, proporcionando los valores devueltos. En la máquina remota, se asocia al procedimiento invocado otro procedimiento de presentación. Cuando llega un mensaje se examina y se genera una llamada local CALL P(X,Y). Se llama a este procedimiento de forma local y los supuestos sobre dónde encontrar los parámetros, el estado de pila y otros, son idénticos al caso de una llamada local. PASO DE PARÁMETROS: La mayoría de los lenguajes de programación permiten pasar parámetros como valores (llamada por valor) o como un puntero a la ubicación que contiene el valor (llamada por referencia). La llamada por valor es sencilla para una llamada a procedimiento remoto: los parámetros simplemente se copian en el mensaje y se envían al sistema remoto. Las llamadas por referencia son más difíciles de implementar. Hace falta un único puntero para cada objeto, válido en todo el sistema. El costo de este servicio puede ser muy alto y no valer la pena. REPRESENTACION DE PARAMETROS: Otra cuestión es cómo representar los parámetros y los resultados en los mensajes. Si el programa llamador y el llamado están escritos en el mismo lenguaje de programación tienen el mismo tipo de máquina y el mismo sistema operativo, los requisitos de representación no representan un problema. Pero si existen diferencias en estos aspectos, habrá diferencias en la manera en que se representan los datos numéricos e incluso los textos. Si se emplea una arquitectura de comunicaciones, este problema será resuelto por el nivel de presentación. Pero el costo de estas arquitecturas, ha llevado al diseño de servicios de llamada a procedimiento remoto que ofrecen servicios de comunicaciones básicos. En este caso la conversión la realiza el servicio de llamada a procedimiento remoto. La mejor solución para este problema es ofrecer un formato estándar para los objetos comunes, como los enteros, números en coma flotante, caracteres y cadenas de caracteres. Así los parámetros propios de cualquier máquina pueden convertirse a la representación estándar. ENLACE CLIENTE / SERVIDOR: Especifica la forma en que se establecerá la relación entre un procedimiento remoto y el programa llamador. Un enlace se forma cuando dos aplicaciones establecen una conexión lógica y están preparadas para intercambiar órdenes y datos. Los enlaces no persistentes suponen que la conexión lógica se establece entre dos procesos en el momento de la llamada remota y que la conexión desaparece ni bien se devuelvan los valores. Como una conexión requiere mantener información de estado en los dos extremos, consume recursos. El estilo no persistente se utiliza para conservar esos Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II

Sistemas de Clase Mundial ERP y su Arquitectura

recursos. Por otro lado el costo de establecer las conexiones hace que los enlaces no persistentes no sean adecuados para procedimientos remotos que se invocan con frecuencia. Con enlaces persistentes, una conexión establecida para una llamada a procedimiento remoto, se mantiene después que el procedimiento termina. Esta conexión podrá ser utilizada para futuras llamadas a procedimientos remotos; pero esta finalizará si transcurre un determinado período de tiempo y no es utilizada para aplicaciones que realizan llamadas a procedimientos repetidamente, el enlace persistente, mantiene la conexión lógica y permite que una secuencia de llamadas y retornos utilice la misma conexión. SINCRONISMO FRENTE A ASINCRONISMO: Las llamadas a procedimiento remoto tradicionales son síncronas, lo que requiere que el proceso llamador espere hasta que el proceso llamado devuelva un valor (RPC síncrona). La RPC síncrona no es capaz de explotar por completo el paralelismo inherente a las aplicaciones distribuidas; esto limita el tipo de interacción que las aplicaciones distribuidas pueden realizar y así obtienen un rendimiento menor. Para ofrecer una mayor flexibilidad se implementaron varios servicios de RPC asíncrona que consiguen un grado mayor de paralelismo. Las RPC asíncronas no bloquean al llamador, permitiendo que la ejecución de los clientes continúe localmente y en paralelo con la llamada al servidor. Una aplicación de las RPC asíncronas es hacer que un cliente invoque repetidamente a un servidor, generando una serie de peticiones a la vez. La sincronización del cliente y el servidor puede conseguirse de dos formas: 1. una aplicación de nivel superior en el cliente y en el servidor puede iniciar el intercambio y comprobar al final que se han llevado a cabo todas las acciones solicitadas. 2. un cliente puede emitir una cadena de RPC asíncronas, seguidas de una última RPC síncrona. El servidor responderá a la RPC síncrona después de terminar todo el trabajo solicitado por las RPC asíncronas. El algunos esquemas las RPC asíncronas no exigen una respuesta al servidor, otros requieren o permiten una respuesta, pero el llamador no queda a la espera de la misma.

Universidad de las Américas ACI 554 – 170 – Sistemas de Clase Mundial II