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)

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.
2. 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.
3. 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.
4. 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 Ejecutando sobre la DECnet

Hay aplicaciones, middleware, y en los PC hay
aplicaciones
Software de red Novell y OS/2 de IBM 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