INSTITUTO TECNOLOGICO NACIONAL DE MÉXICO, CAMPUS

ORIZABA

Contexto de la programación cliente/servidor

MATERIA
Programación en ambiente cliente/servidor

PRESENTA

Vasquez Carmona Oscar

DOCENTE
Pelaez Camarena Silvestre Gustavo

CARRERA
INGENERIA INFORMATICA

10° SEMESTRE
1.1 Arquitectura del modelo cliente/servidor
La arquitectura cliente/servidor persigue el objetivo de procesar la información de
un modo distribuido. De esta forma, los usuarios finales pueden estar dispersos en
un área geográfica más o menos extensa (un edificio, una localidad, un país, …) y
acceder a un conjunto común de recursos compartidos.

Además, el acceso debe ser transparente (el cliente puede desconocer la

ubicación física del recurso que pretende utilizar) y, preferiblemente,
multiplataforma, es decir, independiente del sistema operativo, del software de
aplicación e incluso del hardware.

En definitiva, cuando hablamos de la implantación de una arquitectura

cliente/servidor, nos referimos a un sistema de información distribuido.

Además de la transparencia y la independencia del hardware y del software, una

implantación cliente/servidor debe tener las siguientes características:

 Debe utilizar protocolos asimétricos, donde el servidor se limita a escuchar,

en espera de que un cliente inicie una solicitud.
 El servidor ofrecerá recursos, tanto lógicos como físicos a una cantidad
variable y diversa de clientes (por ejemplo, espacio de almacenamiento,
bases de datos, impresoras, etc.)
 El servidor ofrecerá también una serie de servicios, que serán usados por
los clientes. Estos servicios estarán encapsulados, para ocultar a los
clientes los detalles de su implementación (por ejemplo, aceptar el
requerimiento de un cliente sobre una base de datos o formatear los datos
obtenidos antes de transmitirlos al cliente).
 Se facilitará la integridad y el mantenimiento tanto de los datos como de los
programas debido a que se encuentran centralizados en el servidor o
servidores.
 Los sistemas estarán débilmente acoplados, ya que interactúan mediante el
envío de mensajes.
 Se facilitará la escalabilidad, de manera que sea fácil añadir nuevos clientes
a la infraestructura (escalabilidad horizontal) o aumentar la potencia del
servidor o servidores, aumentando su número o su capacidad de cálculo
(escalabilidad vertical)

Las características de una implantación cliente/servidor deben ser:

 Transparencia.
 Independencia.
 Protocolos asimétricos.
 Recursos compartidos.
 Servicio.
 Encapsulamiento.
  Integridad.
 Acoplamiento débil.
 Escalabilidad.

Elementos de la arquitectura cliente/servidor.

De lo dicho hasta ahora, podemos deducir que los principales elementos que
conforman la arquitectura cliente/servidor son los siguientes:

El servidor

Cuando hablamos de una forma genérica, si mencionamos a un servidor, nos

referimos a un ordenador, normalmente con prestaciones elevadas, que ejecuta
servicios para atender las demandas de diferentes clientes.

Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un servidor

es un proceso que ofrece el recurso (o recursos) que administra a los clientes que
lo solicitan (consultar la definición de cliente más abajo).

Es muy frecuente que, para referirse a un proceso servidor, se utilice el término

back-end.

Según el tipo de servidor implantado, tendremos un tipo de arquitectura

cliente/servidor diferente.

Por último, mencionar que, en algunas ocasiones, un servidor puede actuar, a su

vez, como cliente de otro servidor.

En ocasiones, los servicios también reciben el nombre de demonios (daemons en

inglés).

Se trata de una terminología que proviene del mundo Unix/Linux.

El cliente

Igual que antes, al hablar de forma genérica sobre un cliente, nos referimos a un
ordenador, normalmente con prestaciones ajustadas, que requiere los servicios de
un equipo servidor.

Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un cliente

es un proceso que solicita los servicios de otro, normalmente a petición de un
usuario.
En entornos cliente/servidor, suele utilizarse el término front-end para referirse a
un proceso cliente.

Normalmente, un proceso cliente se encarga de interactuar con el usuario, por lo

que estará construido con alguna herramienta que permita implementar interfaces
gráficas (GUI). Además, se encargará de formular las solicitudes al servidor y
recibir su respuesta, por lo que deberá encargarse de una parte de la lógica de la
aplicación y de realizar algunas validaciones de forma local.

Los mensajes quedan almacenados, permitiendo que el emisor o el receptor estén

inactivos por un tiempo. Así, las comunicaciones pueden ser persistentes y
asíncronas.

Este mecanismo se denomina Message-Oriented Middleware (MOM)

El Middleware

Es la parte del software del sistema que se encarga del transporte de los
mensajes entre el cliente y el servidor, por lo que se ejecuta en ambos lados de la
estructura.

El middleware permite independizar a los clientes y a los servidores, sobre todo,

gracias a los sistemas abiertos, que eliminan la necesidad de supeditarse a
tecnologías propietarias.

Por lo tanto, el middleware facilita el desarrollo de aplicaciones, porque resuelve la

parte del transporte de mensajes y facilita la interconexión de sistemas
heterogéneos sin utilizar tecnologías propietarias.

Además, ofrece más control sobre el negocio, debido a que permite obtener
información desde diferentes orígenes (uniendo tecnologías y arquitecturas
distintas) y ofrecerla de manera conjunta.

Podemos estructurar el middleware en tres niveles:

 El protocolo de transporte, que será común para otras aplicaciones del

sistema.
 El sistema operativo de red
 El protocolo del servicio, que será específico del tipo de sistema
cliente/servidor que estemos considerando.

El funcionamiento básico

Aunque es probable que a estas alturas ya te hagas una idea sobre el

funcionamiento general del modelo cliente/servidor, vamos a concretarlo a
continuación:
 1. Lo primero que debe ocurrir es que se inicie el servidor. Esto ocurrirá
durante el arranque del sistema operativo o con la intervención posterior del
administrador del sistema. Cuando termine de iniciarse, esperará de forma
pasiva las solicitudes de los clientes.
2. En algún momento, uno de los clientes conectados al sistema realizará una
solicitud al servidor.
3. El servidor recibe la solicitud del cliente, realiza cualquier verificación
necesaria y, si todo es correcto, la procesa.
4. Cuando el servidor disponga del resultado solicitado, lo envía al cliente.
5. Finalmente, el cliente recibe el resultado que solicitó. A continuación, realiza
las comprobaciones oportunas (si son necesarias) y, si era ese el objetivo
final, se lo muestra al usuario.

Si descomponemos este modo de funcionamiento en elementos estructurales,

será más fácil comprender los conceptos implicados. De esta forma, podemos
obtener una definición de la arquitectura por niveles, estructurada como sigue:

 Un nivel de presentación, que aglutina los elementos relativos al cliente.

 Un nivel de aplicación, compuesto por elementos relacionados con el
servidor.
 Un nivel de comunicación, que está formado por los elementos que hacen
posible la comunicación entre el cliente y el servidor.
 Un nivel de base de datos, formado por los elementos relacionados con el
acceso a los datos.

Ventajas del esquema Cliente/Servidor

Entre las principales ventajas del esquema Cliente/Servidor están:

 Uno de los aspectos que más ha promovido el uso de sistemas

Cliente/Servidor, es la existencia de plataformas de hardware cada vez más
baratas. Esta constituye a su vez una de las más palpables ventajas de
este esquema, la posibilidad de utilizar máquinas considerablemente más
baratas que las requeridas por una solución centralizada, basada en
sistemas grandes. Además, se pueden utilizar componentes, tanto de
hardware como de software, de varios fabricantes, lo cual contribuye
considerablemente a la reducción de costos y favorece la flexibilidad en la
implantación y actualización de soluciones.

 El esquema Cliente/Servidor facilita la integración entre sistemas diferentes

y comparte información permitiendo, por ejemplo, que las máquinas ya
existentes puedan ser utilizadas, pero utilizando interfaces más amigables
al usuario. De esta manera, podemos integrar PCs con sistemas medianos
y grandes, sin necesidad de que todos tengan que utilizar el mismo sistema
operacional.
  Al favorecer el uso de interfaces gráficas interactivas, los sistemas
Construídos bajo este esquema tienen mayor interacción y más intuitiva con
el usuario. En el uso de interfaces gráficas para el usuario, el esquema
Cliente/Servidor presenta la ventaja, con respecto a uno centralizado, de
que no es siempre necesario transmitir información gráfica por la red pues
esta puede residir en el cliente, lo cual permite aprovechar mejor el ancho
de banda de la red.
 Una ventaja adicional del uso del esquema Cliente/Servidor es que es más
rápido el mantenimiento y el desarrollo de aplicaciones, pues se pueden
emplear las herramientas existentes (por ejemplo, los servidores de SQL o
las herramientas de más bajo nivel como los sockets o el RPC).

 La estructura inherentemente modular facilita además la integración de

nuevas tecnologías y el crecimiento de la infraestructura computacional,
favoreciendo así la escalabilidad de las soluciones.

 El esquema Cliente/Servidor contribuye, además, a proporcionar, a los

diferentes departamentos de una organización, soluciones locales, pero
permitiendo la integración de la información relevante a nivel global.

Desventajas del esquema Cliente/Servidor

Entre las principales desventajas del esquema Cliente/Servidor están:

 El mantenimiento de los sistemas es más difícil pues implica la interacción

de diferentes partes de hardware y de software, distribuidas por distintos
proveedores, lo cual dificulta el diagnóstico de fallas. •Se cuenta con muy
escasas herramientas para la administración y ajuste del desempeño de los
sistemas.

 Es importante que los clientes y los servidores utilicen el mismo mecanismo

(por ejemplo, sockets o RPC), lo cual implica que se deben tener
mecanismos generales que existan en diferentes plataformas.

 Además, hay que tener estrategias para el manejo de errores y para

mantener la consistencia de los datos.

 La seguridad de un esquema Cliente/Servidor es otra preocupación

importante. Por ejemplo, se deben hacer verificaciones en el cliente y en el
servidor.
  El desempeño es otro de los aspectos que se deben tener en cuenta en el
esquema Cliente/Servidor. Problemas de este estilo pueden presentarse
por congestión en la red, dificultad de tráfico de datos, etc.

1.2 Modelos de dos y tres capas

La programación por capas es un modelo de desarrollo software en el que el

objetivo primordial es la separación (desacoplamiento) de las partes que
componen un sistema software o también una arquitectura cliente-servidor: lógica
de negocios, capa de presentación y capa de datos. De esta forma, por ejemplo,
es sencillo y mantenible crear diferentes interfaces sobre un mismo sistema sin
requerirse cambio alguno en la capa de datos o lógica.

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en

varios niveles y, en caso de que sobrevenga algún cambio, solo afectará al nivel
requerido sin tener que revisar entre el código fuente de otros módulos, dado que
se habrá reducido el Acoplamiento informático hasta una interfaz de paso de
mensajes.

Además, permite distribuir el trabajo de creación de una aplicación por niveles; de

este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles,
de forma que basta con conocer la API que existe entre niveles.

En el diseño de sistemas informáticos actual se suelen usar las arquitecturas

multinivel o programación por capas. En dichas arquitecturas a cada nivel se le
confía una misión simple, lo que permite el diseño de arquitecturas escalables
(que pueden ampliarse con facilidad en caso de que las necesidades aumenten).

El más utilizado actualmente es el diseño en tres niveles (o en tres capas).

Los grandes conocedores de la tecnología cliente/servidor prefieren usar términos

como dos o tres capas, así como arquitecturas cliente/servidor de n capas en lugar
de clientes obesos y servidores obesos. No obstante, se trata de la misma idea.
Depende enteramente de dividir la aplicación cliente/servidor en unidades
funcionales que luego puede asignar al cliente o a uno o más servidores.
La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor
en donde el cliente solicita recursos y el servidor responde directamente a la
solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra
aplicación para proporcionar parte del servicio.
En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la
arquitectura generalmente está compartida por:
1. Un cliente, es decir, el equipo que solicita los recursos, equipado con una
interfaz de usuario (generalmente un navegador Web) para la presentación

2. El servidor de aplicaciones (también denominado software intermedio), cuya

tarea es proporcionar los recursos solicitados, pero que requiere de otro servidor
para hacerlo
3. El servidor de datos, que proporciona al servidor de aplicaciones los datos que
requiere
La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la
que el servidor es polivalente, es decir, puede responder directamente a todas las
solicitudes de recursos del cliente.

Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor

son descentralizadas de uno a otro, es decir, cada servidor se especializa en una
determinada tarea, (por ejemplo: servidor web/servidor de bases de datos).

La arquitectura en 3 niveles permite:

• Un mayor grado de flexibilidad
• Mayor seguridad, ya que la seguridad se puede definir independientemente para
cada servicio y en cada nivel
• Mejor rendimiento, ya que las tareas se comparten entre servidores
Arquitectura de niveles múltiples
En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea
especializada (un servicio). Por lo tanto, un servidor puede utilizar los servicios de
otros servidores para proporcionar su propio servicio. Por consiguiente, la
arquitectura en 3 niveles es potencialmente una arquitectura en N-niveles

En los sistemas cliente servidor de dos capas, la lógica de la aplicación esta

dentro de la interfaz de usuario en el cliente o dentro de la base de datos en el
servidor (o en los dos lugares).

En los sistemas cliente/servidor de tres capas, la lógica de la aplicación (o del

proceso)  reside en la capa intermedia , y está separada de la información y de la
interfaz de usuario

Tres capas es un concepto recargado, se empleo por primera vez para describir la
división f’ísica de una aplicación entre computadoras personales (primera capa),
servidores departamentales (segunda capa) y servidores empresariales tercera
capa). Después se utilizó para describir una división entre cliente (primera capa),
base de datos local (segunda capa) y base de datos empresarial (tercera capa).
Hoy en día la definición en boga es cliente (primera capa), servidor de
aplicaciones (segunda capa) y servidor de base de datos (tercera capa).
En la mayor parte de las aplicaciones de tres capas la intermedia no está
implementada como un programa monolítico; más bien lo está como un conjunto
de componentes que se utilizan en una gran variedad de transacciones de
negocios que empiezan en el cliente.

Cada componente automatiza una función de negocios hasta cierto punto

pequeña. Con frecuencia, los clientes combinan varios componentes de la capa de
en medio en una sola transacción de negocios. Un componente puede llamar a
otros para que le ayuden a responder una solicitud. Además, algunos de esos
componentes podrían actuar como compuertas que encapsulan aplicaciones
heredadas que se ejecutan en equipos anfitrión (mainframes). Así, la mayor parte
del tiempo las tres capas son, en realidad, n capas.

Cliente - servidor (2 capas)

Características:

 Es un modelo de arquitectura que incluye uno o más clientes solicitando el

servicio de uno o más servidores.
 El cliente puede ser cualquier dispositivo como por ejemplo una
computadora, una tableta, un PDA, o un teléfono celular inteligente.
 En el cliente se encuentra la interface para comunicarse con el servidor.
 El servidor administra los datos
 El difícil de escalar
 Tiene un número reducido de conexiones

3 capas
Características:

 el modelo en 3 capas fue desarrollado para superar las limitaciones de las

arquitecturas en dos capas
 contiene una capa intermedia
 los procesos se manejan de forma separada de la interfaz de usuario y los
datos
 la capa de en medio centraliza la lógica de las aplicaciones
 la separación de capas hace la administración más sencilla
 puede integrar datos de múltiples fuentes
 las aplicaciones web actuales se adaptan a este modelo.
 La capa de presentación recoge la información de usuario y la envía al
servidor
 Recibe resultados de la capa proceso
 La capa proceso recibe la entrada de los datos
 La capa proceso realiza operaciones y los resultados los manda a la capa
presentación
 La capa datos almacena los datos
 La capa de datos asegura la integridad de los datos.

Ventajas del Sistema de Dos Capas:

El desarrollo de aplicaciones en un ambiente de dos capas funciona

adecuadamente, pero no es necesariamente lo más eficiente. Las herramientas
para el desarrollo con dos capas son robustas y amplia mente evaluadas.
Las técnicas de ingeniería de software de prototipo se emplean fácilmente. Las
soluciones de dos capas trabajan en en ambientes no dinámicos, pero no se
ejecutan bien en organizaciones rápidamente cambiantes.

Desventajas del sistema de dos capas:

Los ambientes de dos capas requieren control excesivo de las versiones y

demandan esfuerzo de distribución de la aplicación cuando se les hacen camios.
Esto se ve al hecho de que la mayoría de la aplicación lógica existe en la estación
de trabajo del cliente.

La seguridad del sistema en un diseño de dos capas es compleja y a menudo

requiere administración de las bases de datos; esto es debido al número de
dispositivos con acceso directo al ambiente de esas bases de datos.

Las herramientas del cliente y de la base de datos, utilizadas en diseños de dos

capas, constantemente están cambiando. La dependencia a largo plazo de
cualquier herramienta puede complicar el escalamiento futuro o las
implementaciones.

1.3 Usos y aplicaciones

Tipos de sistemas de los Cliente-Servidor dependiendo de las aplicaciones que el
servidor pone a disposición de los clientes. 
• Servidores de Impresión, mediante el cual los usuarios comparten impresoras. 
• Servidores de Archivos, con el cual los clientes comparten discos duros. 
•Servidores de Bases de Datos, donde existe una única base de datos. 
• Servidores de Lotus Notes, que permite el trabajo simultáneo de distintos clientes
con los mismos datos, documentos o modelos.
• Servidores Web, también utilizan la tecnología Cliente- Servidor, aunque añaden
aspectos nuevos y propios a la misma. 

Algunos servidores esperan las solicitudes en puertos bien conocidos de modo

que sus clientes saben a qué zócalo IP deben dirigir sus peticiones. El cliente
emplea un puerto arbitrario para comunicarse. Los clientes que se quieren
comunicar con un servidor que no usa un puerto bien conocido tienen otro
mecanismo para saber a qué puerto dirigirse. Este mecanismo podría usar un
servicio de registro como Portmap, que utiliza un puerto bien conocido.

Un servidor es una aplicación que ofrece un servicio a usuarios de Internet: un

cliente es el que pide ese servicio. Una aplicación consta de una parte de servidor
y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas.
La vida no es así de fácil en el nuevo mundo de la tecnología cliente/servidor y los
sistemas abiertos. La tecnología de computación cliente/servidor es la “plataforma
abierta” más reciente. Le da la libertad de “mezclar y acoplar” componentes en
casi cualquier nivel. Es posible unir en red una gran variedad de combinaciones de
clientes y servidores. En el mundo de la tecnología cliente/servidor todo se vende
a la carta.

Usted es quien toma las decisiones difíciles en el nuevo orden mundial. Para
triunfar debe elegir la plataforma cliente/servidor correcto, lo mismo que las
herramientas, fabricantes y arquitectura básica. Es necesario que identifique y se
suba en la ola correcta de la tecnología cliente/servidor. Si esa ola en los objetos
distribuidos no tiene sentido perder tiempo y energía en escribir procedimientos
almacenados para servidores en base de datos. Por eso es importante saber con
exactitud que puede hacer la tecnología por usted en un instante determinado.

Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud
para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como
transporte.

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro

programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a
programas que se ejecutan sobre una sola computadora es más ventajosa en un
sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los
servidores, aunque son más importantes las ventajas de tipo organizativo debidas
a la centralización de la gestión de la información y la separación de
responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el
servidor no se ejecuta necesariamente sobre una sola máquina ni es
necesariamente un sólo programa.

 
Es la tecnología que proporciona al usuario final el acceso transparente a las
aplicaciones, datos, servicios de cómputo o cualquier otro recurso del grupo de
trabajo y/o, a través de la organización, en múltiples plataformas. El modelo
soporta un medio ambiente distribuido en el cual los requerimientos de servicio
hechos por estaciones de trabajo inteligentes o “clientes, resultan en un trabajo
realizado por otras computadoras llamados servidores.

Es el que inicia un requerimiento de servicio. El requerimiento inicial puede

convertirse en múltiples requerimientos de trabajo a través de redes LAN o WAN.
La ubicación de los datos o de las aplicaciones es totalmente transparente para el
cliente.

Es cualquier recurso de cómputo dedicado a responder a los requerimientos del

cliente. Los servidores pueden estar conectados a los clientes a través de redes
LANs o WANs, para proporcionar múltiples servicios a los clientes tales como
impresión, acceso a bases de datos, procesamiento de imágenes, etc.

¿Qué es un proceso distribuido?

 Es un modelo de sistemas y/o de aplicaciones, en el cual las funciones y los

datos pueden estar dispersos a través de múltiples recursos de cómputo,
conectados en un ambiente de redes LAN o WAN.
 Podemos tener un proceso distribuido a través de los celulares

La idea es tratar a una computadora como un instrumento, que por sí sola pueda
realizar muchas tareas, pero con la consideración de que realice aquellas que son
más adecuadas a sus características [15]. Si esto se aplica tanto a clientes como
servidores se entiende que la forma más estándar de aplicación y uso de sistemas
Cliente/Servidor es mediante la explotación de las PC’s a través de interfaces
gráficas de usuario; mientras que la administración de datos y su seguridad e
integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente
la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los
procesos cliente sólo se ocupan de la interacción con el usuario (aunque esto
puede variar). En otras palabras, la arquitectura Cliente/Servidor es una extensión
de programación modular en la que la base fundamental es separar una gran
pieza de software en módulos con el fin de hacer más fácil el desarrollo y mejorar
su mantenimiento.

Esta arquitectura permite distribuir físicamente los procesos y los datos en forma
más eficiente lo que en computación distribuida afecta directamente el tráfico de la
red, reduciéndolo grandemente.

Cliente

El cliente es el proceso que permite al usuario formular los requerimientos y

pasarlos al servidor, se le conoce con el término front-end.

El Cliente normalmente maneja todas las funciones relacionadas con la

manipulación y despliegue de datos, por lo que están desarrollados sobre
plataformas que permiten construir interfaces gráficas de usuario (GUI), además
de acceder a los servicios distribuidos en cualquier parte de una red.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes
puntos:

 Administrar la interfaz de usuario.

 Interactuar con el usuario.
 Procesar la lógica de la aplicación y hacer validaciones locales.
 Generar requerimientos de bases de datos.
 Recibir resultados del servidor.
  Formatear resultados.

Servidor

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de

algún recurso administrado por él. Al proceso servidor se le conoce con el término
back-end [15].

El servidor normalmente maneja todas las funciones relacionadas con la mayoría

de las reglas del negocio y los recursos de datos.

Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes
puntos:

 Aceptar los requerimientos de bases de datos que hacen los clientes.

 Procesar requerimientos de bases de datos.
 Formatear datos para trasmitirlos a los clientes.
 Procesar la lógica de la aplicación y realizar validaciones a nivel de bases
de datos.

Características de la arquitectura Cliente/Servidor

Las características básicas de una arquitectura Cliente/Servidor son:

 Combinación de un cliente que interactúa con el usuario, y un servidor que

interactúa con los recursos compartidos. El proceso del cliente proporciona
la interfaz entre el usuario y el resto del sistema. El proceso del servidor
actúa como un motor de software que maneja recursos compartidos tales
como bases de datos, impresoras, módems, etc.
 Las tareas del cliente y del servidor tienen diferentes requerimientos en
cuanto a recursos de cómputo como velocidad del procesador, memoria,
velocidad y capacidades del disco y input-output devices.
 Se establece una relación entre procesos distintos, los cuales pueden ser
ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo
largo de la red.
 Existe una clara distinción de funciones basada en el concepto de
“servicio”, que se establece entre clientes y servidores.
 La relación establecida puede ser de muchos a uno, en la que un servidor
puede dar servicio a muchos clientes, regulando su acceso a recursos
compartidos.
 Los clientes corresponden a procesos activos en cuanto a que son éstos los
que hacen peticiones de servicios a los servidores. Estos últimos tienen un
carácter pasivo ya que esperan las peticiones de los clientes.
 No existe otra relación entre clientes y servidores que no sea la que se
establece a través del intercambio de mensajes entre ambos. El mensaje es
el mecanismo para la petición y entrega de solicitudes de servicio.
  El ambiente es heterogéneo. La plataforma de hardware y el sistema
operativo del cliente y del servidor no son siempre la misma. Precisamente
una de las principales ventajas de esta arquitectura es la posibilidad de
conectar clientes y servidores independientemente de sus plataformas.
 El concepto de escalabilidad tanto horizontal como vertical es aplicable a
cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite
agregar más estaciones de trabajo activas sin afectar significativamente el
rendimiento. La escalabilidad vertical permite mejorar las características del
servidor o agregar múltiples servidores.

Ventajas del esquema Cliente/Servidor

Entre las principales ventajas del esquema Cliente/Servidor están:

 Uno de los aspectos que más ha promovido el uso de sistemas

Cliente/Servidor, es la existencia de plataformas de hardware cada vez más
baratas. Esta constituye a su vez una de las más palpables ventajas de
este esquema, la posibilidad de utilizar máquinas considerablemente más
baratas que las requeridas por una solución centralizada, basada en
sistemas grandes. Además, se pueden utilizar componentes, tanto de
hardware como de software, de varios fabricantes, lo cual contribuye
considerablemente a la reducción de costos y favorece la flexibilidad en la
implantación y actualización de soluciones.
 El esquema Cliente/Servidor facilita la integración entre sistemas diferentes
y comparte información permitiendo, por ejemplo, que las máquinas ya
existentes puedan ser utilizadas pero utilizando interfaces más amigables al
usuario. De esta manera, podemos integrar PCs con sistemas medianos y
grandes, sin necesidad de que todos tengan que utilizar el mismo sistema
operacional.
 Al favorecer el uso de interfaces gráficas interactivas, los sistemas
Construidos bajo este esquema tienen mayor interacción y más intuitiva con
el usuario. En el uso de interfaces gráficas para el usuario, el esquema
Cliente/Servidor presenta la ventaja, con respecto a uno centralizado, de
que no es siempre necesario transmitir información gráfica por la red pues
esta puede residir en el cliente, lo cual permite aprovechar mejor el ancho
de banda de la red.
 Una ventaja adicional del uso del esquema Cliente/Servidor es que es más
rápido el mantenimiento y el desarrollo de aplicaciones, pues se pueden
emplear las herramientas existentes (por ejemplo los servidores de SQL o
las herramientas de más bajo nivel como los sockets o el RPC ).
 La estructura inherentemente modular facilita además la integración de
nuevas tecnologías y el crecimiento de la infraestructura computacional,
favoreciendo así la escalabilidad de las soluciones.
 El esquema Cliente/Servidor contribuye, además, a proporcionar, a los
diferentes departamentos de una organización, soluciones locales, pero
permitiendo la integración de la información relevante a nivel global.
Desventajas del esquema Cliente/Servidor

Entre las principales desventajas del esquema Cliente/Servidor están:

 El mantenimiento de los sistemas es más difícil pues implica la interacción

de diferentes partes de hardware y de software, distribuidas por distintos
proveedores, lo cual dificulta el diagnóstico de fallas.
 Se cuenta con muy escasas herramientas para la administración y ajuste
del desempeño de los sistemas.
 Es importante que los clientes y los servidores utilicen el mismo mecanismo
(por ejemplo, sockets o RPC), lo cual implica que se deben tener
mecanismos generales que existan en diferentes plataformas.
 Además, hay que tener estrategias para el manejo de errores y para
mantener la consistencia de los datos.
 La seguridad de un esquema Cliente/Servidor es otra preocupación
importante. Por ejemplo, se deben hacer verificaciones en el cliente y en el
servidor.
 El desempeño es otro de los aspectos que se deben tener en cuenta en el
esquema Cliente/Servidor. Problemas de este estilo pueden presentarse
por congestión en la red, dificultad de tráfico de datos, etc.

Características del Modelo

  El Cliente y el Servidor pueden actuar como una sola entidad y también
pueden actuar como entidades separadas, realizando actividades o tareas
independientes.
 Las funciones de Cliente y Servidor pueden estar en plataformas
separadas, o en la misma plataforma.
 Un servidor da servicio a múltiples clientes en forma concurrente.
 Cada plataforma puede ser escalable independientemente. Los cambios
realizados en las plataformas de los Clientes o de los Servidores, ya sean
por actualización o por reemplazo tecnológico, se realizan de una manera
transparente para el usuario final.

El servidor es un programa que recibe una solicitud, realiza el servicio requerido y

devuelve los resultados en forma de una respuesta. Generalmente un servidor
puede tratar múltiples peticiones (múltiples clientes) al mismo tiempo.

EJEMPLO: Al momento en que queremos ingresar a internet le enviamos una

petición al servidor de internet el cual nos provee el servicio dándonos una
respuesta que es la página que tiene el servidor.

También se conoce como aplicaciones de dos capas es aquella donde los datos y
la lógica del negocio se encuentran separados de la interfaz, este tipo de
aplicaciones también es llamado cliente servidor.
Otro escenario válido para una aplicación cliente/servidor se da separando los
datos de la interfaz y la lógica del negocio, este tipo de aplicación también se
conoce como cliente pesado.

1.4 Comunicaciones entre programas 

El proceso para la creación de un servicio siempre comienza con la creación del
Socket. Así como el cliente necesita llamadas especificas en determinados
momentos, el servidor trabajo de modo similar, pero añade unas pocas llamadas
extras al sistema.
El servidor utiliza la llamada del sistema Socket(), pero debe hacer un trabajo extra
que era opcional para el cliente, el cliente siempre realiza una conexión activa
porque la persigue enérgicamente los servidores por otro lado necesitan
proporcionar un numero de puesto especifico y consiste a los programas clientes
si les va a prestar servicio. El programa servido que escriba deberá utilizar las
llamadas de sistema socker(), bind(), listen(), accept(). Y mientras el programa
cliente es una conexión activa, el servidor es una conexión pasiva. Las llamadas
de isistemas() y accept() crean una conexión solo cuando el cliente pide una
conexión (similar a la acción de responder al timbre de un teléfono

El ejemplo de servidor escucha en un socket (puerto 8000) esperando peticiones

entrantes. Cualquier programa, como el cliente de ejemplo, puede conectar con
este servidor y pasarle hasta 16.384 bytes de datos

El servidor trata los datos como datos ASCII y los convierte en mayúsculas antes
de pasárselos al programa cliente. Estos dos sencillos programas se pueden
volver a utilizar fácilmente cuando se escriban programas cliente-servidor basados
en socket

Los servidores que pueden recibir muchas peticiones simultáneas utilizan fork
para crear un proceso separado para la administración de peticiones de servicio
constitucionalmente caras. 
Server.c crea un socket permanente para la escucha de peticiones de servicio;
cuando un cliente conecta con el servidor, se crea un socket temporal. Cada vez
que un cliente conecta con un servidor, se abre un nuevo socket temporal entre el
cliente y el servidor.

1.5 Modelos de computación distribuida

A la hora de hablar de computación distribuida, aparece el concepto de

programación distribuida, que es un modelo de programación enfocado a
desarrollar sistemas distribuidos, abiertos, escalables, transparentes y tolerantes a
fallos. Casi cualquier lenguaje de programación que tenga acceso al más bajo
nivel del hardware del sistema puede manejar la programación distribuida,
teniendo en cuenta que hace falta una gran cantidad de tiempo y código.

La programación distribuida utiliza alguna de las arquitecturas básicas: cliente-

servidor, 3-tier, n-tier, objetos distribuidos, etc. Existen lenguajes específicamente
diseñados para programación distribuida, como son: Ada, Alef, E, Erlang, Limbo y
Oz.

El sistema por antonomasia para lograr el cálculo distribuido es la

supercomputadora,que es una computadora con capacidades de cálculo muy
superiores a las de cualquier ordenador de trabajo convencional. Hoy en día, el
diseño de supercomputadoras se sustenta en cuatro importantes tecnologías, de
las cuales, las dos primeras que citaremos son las verdaderamente denominadas
supercomputadoras. Pasemos a verlas:

 La tecnología de registros vectoriales, creada por Seymour Cray,

considerado el padre de la súper computación, quien inventó y patentó
diversas tecnologías que condujeron a la creación de máquinas de
computación ultra-rápidas. Esta tecnología permite la ejecución de
innumerables operaciones aritméticas en paralelo.

 El sistema conocido como M.P.P. (Massively Parallel Processors o

Procesadores Masivamente Paralelos), que consiste en la utilización de
cientos y, a veces, miles de microprocesadores estrechamente
coordinados.

 La tecnología de computación distribuida propiamente dicha: los clusters y

los grids,de los que más tarde hablaremos.

 Por último, el cuasi-súper cómputo ocomputación de ciclos redundantes,

también llamada computación zombi. Recientemente, con el éxito de
Internet, han surgido proyectos de computación distribuida a nivel mundial,
en los que programas especiales aprovechan el tiempo ocioso de miles de
ordenadores personales para realizar grandes tareas. Consiste en que un
servidor o grupo de servidores distribuyen trabajo de procesamiento a un
grupo de computadoras voluntarias a ceder capacidad de procesamiento no
utilizada. A diferencia de las tres últimas categorías, el software que corre
en estas plataformas debe ser capaz de dividir las tareas en bloques de
cálculo independientes, que no se ensamblarán ni comunicarán durante
grandes periodos de tiempo, como pueden ser horas. En esta categoría
destacan BOINC y Folding@home.

Este tipo de máquinas, generalmente, presenta una arquitectura proyectada y

optimizada enteramente para la aplicación final en concreto.
El inconveniente de utilizar supercomputadoras es su alto coste de adquisición.
Por esta razón, el uso de superordenadores auténticos está limitado a organismos
gubernamentales, militares y grandes centros de investigación, donde se dispone
de suficiente capital.

El resto de los colectivos no pueden afrontar el costo económico que supone

adquirir una máquina de estas características, y aquí es donde toma la máxima
importancia la idea de

poder disponer de esa potencia de cálculo, pero a un precio muy inferior. El

concepto de cluster nació cuando los pioneros de la súper computación intentaban
difundir diferentes procesos entre varias computadoras, para luego poder recoger
los resultados que dichos procesos debían producir. Con un hardware más
asequible, se pudo perfilar que podrían conseguirse resultados muy parecidos a
los obtenidos con aquellas máquinas mucho más costosas, como se ha venido
probando desde entonces.

Esto último, nos lleva a fijar nuestra atención en la computación distribuida. Es un

modelo relativamente nuevo, destinado a resolver problemas de computación
masiva utilizando un gran número de computadoras organizadas en racimos
incrustados en una infraestructura de telecomunicaciones distribuida.

Esta computación distribuida consiste en compartir recursos heterogéneos,

basados en distintas plataformas, arquitecturas y lenguajes de programación,
situados en distintos lugares y pertenecientes a diferentes dominios de
administración sobre una red que utiliza estándares abiertos. En definitiva, es
tratar de forma virtual los recursos informáticos y telemáticos disponibles.

La aparición de la computación distribuida se debe a la necesidad de resolver

problemas demasiado grandes para cualquier supercomputadora, con el objetivo
adicional de mantener la flexibilidad de trabajar en múltiples problemas más
pequeños. Por tanto, la computación distribuida es naturalmente un entorno
multiusuario; esto hace que las técnicas de autorización segura sean esenciales
antes de permitir que los recursos informáticos sean controlados por usuarios
remotos.

Basándonos en la funcionalidad, las redes de computación distribuida se clasifican

en redes computacionales y redes de datos.

A continuación, describiremos brevemente algunas de las herramientas y aspectos

relacionados con la computación distribuida.

Grid.

La computación en grid o en malla es un nuevo paradigma de computación

distribuida en el cual todos los recursos de un número indeterminado de
computadoras son englobados para ser tratados como un único superordenador
de manera transparente.

Las computadoras asociadas al grid no están conectadas o enlazadas firmemente,

es decir no tienen porqué estar en el mismo lugar geográfico.

El grid ofrece una forma de resolver grandes problemas, como el plegamiento de

las proteínas y descubrimiento de medicamentos, construcción de modelos
financieros, simulación de terremotos, inundaciones y otras catástrofes naturales,
modelado del clima y el tiempo, etc.

En un sistema SSI (Single System Image), todas las computadoras vinculadas

dependen de un sistema operativo común, diseñado al efecto. Este es el caso
general de un cluster. En cambio, un grid es heterogéneo, en el sentido de que las
computadoras pueden tener diferentes sistemas operativos.

Globus.

La herramienta Globus ha emergido como el estándar de facto para la capa

intermedia (middleware) del grid. Algunos de los servicios que ofrece Globus son:

-La gestión de recursos: Protocolo de Gestión de Recursos en Rejilla.

-Servicios de Información: Servicio de Descubrimiento y Monitorización.

-Gestión y Movimiento de Datos: Acceso Global al Almacenamiento Secundario y

FTP en grid, GridFTP.

La mayoría de grids que se expanden sobre las comunidades académicas y de

investigación de Europa y Norteamérica están basadas en la herramienta Globus
como núcleo de la capa intermedia.

XML.

Los servicios Web basados en XML, ofrecen una forma de acceder a diversos
servicios en un entorno distribuido. Recientemente, el mundo de la informática en
grid y los servicios Web caminan juntos para ofrecer el grid como un servicio Web.
La arquitectura está definida por la Open Grid Services Architecture (OGSA). La
versión 3.0 de Globus Toolkit, será una implementación de referencia acorde con
el estándar OGSA.

Clustering.

Otro método para crear sistemas de supercomputadoras es el clustering. Un

cluster o racimo de computadoras consiste en un grupo de ordenadores de bajo
coste en relación al de una supercomputadora, conectados entre sí mediante una
red de alta velocidad (Gigabit de fibra óptica, Myrinet, etc.) y un software que
realiza la distribución de carga del trabajo entre los equipos. En un cluster, todos
los nodos (ordenadores) se encuentran en el mismo lugar geográfico, conectados
por una red local para englobar todos lo recursos.

Por lo general, éste tipo de sistemas cuentan con un centro de almacenamiento de

datos único.

El sistema utilizado para realizar nuestro trabajo es un cluster, del cual haremos
larga mención posteriormente.

Aspectos de seguridad.

El tema de la seguridad es delicado en el ámbito de la computación distribuida

pues las conexiones se hacen de forma remota, razón por la cual surgen
problemas para controlar el acceso a los distintos nodos de la red.

1.5.1 RMI
RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para
invocar un método de manera remota. Forma parte del entorno estándar de
ejecución de Java y proporciona un mecanismo simple para la comunicación de
servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se
requiere comunicación entre otras tecnologías debe utilizarse CORBAo SOAP en
lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar
específicamente diseñado para Java; proporciona paso de objetos por referencia
(no permitido por SOAP), recolección de basura distribuida (Garbage Collector
distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho
objeto estará accesible a través de la red y el programa permanece a la espera de
peticiones en un puerto TCP. A partir de ese momento, un cliente puede
conectarse e invocar los métodos proporcionados por el objeto.
La invocación se compone de los siguientes pasos:

 Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad

de serialización de Java).
 Invocación del método (del cliente sobre el servidor). El invocador se queda
esperando una respuesta.
 Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y
lo envía al cliente.
 El código cliente recibe la respuesta y continúa como si la invocación
hubiera sido local.
1.5.2  COM/DCOM

COM / DCOM
Microsoft Distributed COM (DCOM) extiende COM (Component Object Model)
para soportar comunicación entre objetos en ordenadores distintos, en una LAN,
WAN, o incluso en Internet. Con DCOM una aplicación puede ser distribuida en
lugares que dan más sentido al cliente y a la aplicación.
Como DCOM es una evolución lógica de COM, se pueden utilizar los
componentes creados en aplicaciones basadas en COM, y trasladarlas a entornos
distribuidos. DCOM maneja detales muy bajos de protocolos de red, por lo que
uno se puede centrar en la realidad de los negocios:
proporcionar soluciones a clientes.
Atualmente DCOM viene con los sistemas operativos Windows 2000, NT, 98 y
también está disponible una versión para Windows 95 en la página de Microsoft.
También hay una implementación de DCOM para Apple Macintosh y se está
trabajando en implementaciones para plataformas UNIX como Solaris.
La arquitectura DCOM
DCOM es una extensión de COM, y éste define como los componentes y sus
clientes interactuan entre sí. Esta interacción es definida de tal manera que el
cliente y el componente puede conectar sin la necesidad de
un sistema intermedio. El cliente llama a los métodos del componente sin tener
que preocuparse de niveles más complejos
En los actuales sistemas operativos, los procesos están separados unos de otros.
Un cliente que necesita comunicarse con un componente en otro proceso no
puede llamarlo directamente, y tendrá que utilizar alguna forma de comunicación
entre procesos que proporcione el sistema operativo. COM proporciona este tipo
de comunicación de una forma transparente: intercepta las llamadas del cliente y
las reenvía al componente que está en otro proceso.
Cuando el cliente y el componente residen en distintas máquinas, DCOM
simplemente reemplaza la comunicación entre procesos locales por
un protocolo de red. Ni el cliente ni el componente se enteran de que la unión que
los conecta es ahora un poco más grande.
Las librería de COM proporcionan servicios orientados a objetos a los clientes y
componentes, y utilizan RPC y un proveedor de seguridad para generar paquetes
de red estándar que entienda el protocolo estándar de DCOM.
Los Componentes y su reutilización
Muchas aplicaciones distribuidas no están desarrolladas
 Al existir infraestructuras de hardware, software, componentes, al igual
que herramientas, se necesita poder integrarlas y nivelarlas para reducir el
desarrollo y el tiempo de trabajo y coste. DCOM toma ventaja de forma directa y
transparente de los componentes COM y herramientas ya existentes. Un gran
mercado de todos los componentes disponibles haría posible reducir el tiempo de
desarrollo integrando soluciones estandarizadas en las aplicaciones de usuario.
Muchos desarrolladores están familiarizados con COM y pueden aplicar fácilmente
sus conocimientos a las aplicaciones distribuidas basadas en DCOM.
Cualquier componente que sea desarrollado como una parte de una aplicación
distribuida es un candidato para ser reutilizado. Organizando los procesos de
desarrollo alrededor del paradigma de los componentes permite continuar
aumentando el nivel de funcionalidad en las nuevas aplicaciones y reducir el
tiempo de desarrollo.
Diseñando para COM y DCOM se asegura que los componentes creados serán
útiles ahora y en el futuro.
Independencia de la localización
Cuando se comienza a implementar una aplicación distribuida en una red reak,
aparecen distintos conflictos en el diseño:
 Los componentes que interactuan más a menudo deberían estar
localizados más cerca.
 Algunos componentes solo pueden ser ejecutados en máquinas específicas
o lugares específicos.
 Los componentes más pequeños aumentan la flexibilidad, pero aumentan el
tráfico de red.
 Los componentes grandes reducen el tráfico de red, pero también reducen
la flexibilidad.

Con DCOM, estos temas críticos de diseño pueden ser tratados se forma bastante
sencilla, ya que estos detalles no se especifican en el código fuente. DCOM olvida
completamente la localización de los componentes, ya esté en el mismo proceso
que el cliente o en una máquina en cualquier lugar del mundo. En cualquier caso,
la forma en la que el cliente se conecta a un componente y llama a los métodos de
éste es identica. No es solo que DCOM no necesite cambios en el código fuente,
sino que además no necesita que el programa sea recompilado. Una simple
reconfiguración cambia la forma en la que los componentes se conectan entre sí.
La independencia de localización en DCOM simplifica enormemente las tarea de
los componentes de aplicaciones distribuidas para alcanzar un nivel de
funcionamiento óptimo. Supongamos, por ejemplo, que cierto componente debe
ser localizado en una máquina específica en un lugar determinado. Si la aplicación
tiene numerosos componentes pequeños, se puede reducir la carga de la red
situándolos en la misma LAN, en la misma máquina, o incluso en el mismo
proceso. Si la aplicación está compuesta por un pequeño número de grandes
componentes, la carga de red es menor y no es un problema, por tanto se pueden
poner en las máquinas más rápidas disponibles independientemente de donde
esten situadas.
Con la independencia de localización de DCOM, la aplicación puede combinar
componentes relacionados en máquinas "cercanas" entre si, en una sola máquina
o incluso en el mismo proceso. Incluso si un gran número de pequeños
componentes implementan la funcionalidad de un gran módulo lógico, podrán
interactuar eficientemente entre ellos.
Independencia del lenguaje de programación
Una cuestión importante durante el diseño e implementación de una aplicación
distribuida es la elección del lenguaje o herramienta de programación. La elección
es generalmente un termino medio entre el coste de desarrollo, la experiencia
disponible y la funcionalidad. Como una extensión de COM, DCOM es
completamente independiente del lenguaje. Virtualmentem cualquier lenguaje
puede ser utilizado para crear componentes COM, y estos componentes puede
ser utilizado por muchos más lenguajes y herramientas. Java, Microsoft Visual C+
+, Microsoft Visual Basic, Delphi, PowerBuilder, y Micro Focus COBOL interactuan
perfectamente con DCOM.
Con la independencia de lenguaje de DCOM, los desarrolladores de aplicaciones
puede elegir las herramientas y lenguajes con los que estén más familiarizados.
La independencia del lenguaje permite crear componentes en lenguajes de nivel
superior como Microsoft Visual Basic, y después reimplementarlos en distintos
lenguajes como C++ o Java, que permiten tomar ventaja de características
avanzadas como multihilo.

Independencia del protocolo

Muchas aplicaciones distribuidas tienen que ser integradas en la infraestructura de
una red existente. Necesitar un protocolo específico de red, obligará a mejorar
todos los cliente, lo que es inaceptable en muchas situaciones. Los
desarrolladores de aplicaciones tienen que tener cuidado de mantener la
aplicación lo más independiente posible de la infraestructura de la red.
DCOM proporciona esta transparencia: DCOM puede utilizar cualquier protocolo
de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS. DCOM proporciona un
marco de seguridad a todos estos protocolos.
Los desarrolladores pueden simplemente utilizar las características
proporcionadas por DCOM y asegurar que sus aplicaciones son completamente
independientes del protocolo.

1.5.3 Servicios WEB

Un servicio web (en inglés, Web Service o Web services) es una tecnología que
utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos
entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes
de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden
utilizar los servicios web para intercambiar datos en redes de
ordenadores como Internet. La interoperabilidad se consigue mediante la adopción
de estándares abiertos. Las organizaciones OASIS y W3C son los comités
responsables de la arquitectura y reglamentación de los servicios Web. Para
mejorar la interoperabilidad entre distintas implementaciones de servicios Web se
ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para
definir de manera más exhaustiva estos estándares. Es una máquina que atiende
las peticiones de los clientes web y les envía los recursos solicitados.

Arquitectura

En la arquitectura de servicios web existen tres partes: proveedor de servicios

web, el que pide el servicio web y el publicador. El proveedor de servicios envía al
publicador del servicio un fichero WSDL con la definición del servicio web. El que
pide el servicio contacta con el publicador y descubre quién es el proveedor
(protocolo WSDL) y contacta con el proveedor (protocolo SOAP). El proveedor
valida la petición de servicio y envía el dato estructurado en formato XML
utilizando el protocolo SOAP. El fichero XML es validado de nuevo por el que pide
el servicio utilizando un fichero XSD.

Estándares empleados

 Web Services Protocol Stack: conjunto de servicios y protocolos de los

servicios web.
 XML (Extensible Markup Language): formato estándar para los datos que
se vayan a intercambiar.
 SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote
Procedure Call): protocolos sobre los que se establece el intercambio.
 Otros protocolos: los datos en XML también pueden enviarse de una
aplicación a otra mediante protocolos normales como Hypertext Transfer
Protocol (HTTP), File Transfer Protocol (FTP), o Simple Mail Transfer
Protocol (SMTP).
 WSDL (Web Services Description Language): es el lenguaje de la interfaz
pública para los servicios web. Es una descripción basada en XML de los
requisitos funcionales necesarios para establecer una comunicación con los
servicios web.
 UDDI (Universal Description, Discovery and Integration): protocolo para
publicar la información de los servicios web. Permite comprobar qué
servicios web están disponibles.
 WS-Security (Web Service Security): protocolo de seguridad aceptado
como estándar por OASIS (Organization for the Advancement of Structured
 Information Standards). Garantiza la autenticación de los actores y la
confidencialidad de los mensajes enviados.
 REST (Representational State Transfer): arquitectura que, haciendo uso del
protocolo HTTP, proporciona una API que utiliza cada uno de sus métodos
(GET, POST, PUT, DELETE, etcétera) para poder realizar diferentes
operaciones entre la aplicación que ofrece el servicio web y el cliente.
 GraphQL, arquitectura alternativa a REST.

Ventajas de los servicios web

 Aportan interoperabilidad entre aplicaciones de software

independientemente de sus propiedades o de las plataformas sobre las que
se instalen.
 Los servicios Web fomentan los estándares y protocolos basados en texto,
que hacen más fácil acceder a su contenido y entender su funcionamiento.
 Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan ser combinados fácilmente para
proveer servicios integrados.

Inconvenientes de los servicios web

 Para realizar transacciones, no pueden compararse en su grado de

desarrollo con los estándares abiertos de computación distribuida como
CORBA (Common Object Request Broker Architecture).
 Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, tales como Java Remote Method Invocation (RMI), CORBA o
Distributed Component Object Model (DCOM). Es uno de los
inconvenientes derivados de adoptar un formato basado en texto. Y es que
entre los objetivos de XML no se encuentra la concisión ni la eficacia de
procesamiento.
 Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en
firewall cuyas reglas tratan de bloquear o auditar la comunicación entre
programas a ambos lados de la barrera.

Razones para crear servicios Web

La principal razón para usar servicios Web es que se pueden utilizar con HTTP
sobre Transmission Control Protocol (TCP) en el puerto de red 80. Dado que las
organizaciones protegen sus redes mediante firewalls (que filtran y bloquean gran
parte del tráfico de Internet), cierran casi todos los puertos TCP salvo el 80, que
es, precisamente, el que usan los navegadores web. Los servicios Web utilizan
este puerto, por la simple razón de que no resultan bloqueados. Es importante
señalar que los servicios web se pueden utilizar sobre cualquier protocolo, sin
embargo, TCP es el más común.
Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para
acceder a las funcionalidades de otras computadoras en red. Las que había eran
ad hoc y poco conocidas, tales como Electronic Data Interchange (EDI), Remote
Procedure Call (RPC), u otras API.

Una tercera razón por la que los servicios Web son muy prácticos es que pueden
aportar gran independencia entre la aplicación que usa el servicio Web y el propio
servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar
al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a
construir grandes aplicaciones a partir de componentes distribuidos más pequeños
es cada día más utilizada.

Se espera que para los próximos años mejoren la calidad y cantidad de servicios
ofrecidos basados en los nuevos estándares.

Plataformas

Servidores de aplicaciones para servicios Web:

 JBoss servidor de aplicaciones J2EE Open Source de Red Hat inc.

 Oracle Fusion Middleware
 IBM Lotus Domino a partir de la versión 7.0
 Axis y el servidor Jakarta Tomcat (de Apache)
 ColdFusion MX de Macromedia
 Java Web Services Development Pack (JWSDP) de Sun Microsystems
(basado en Jakarta Tomcat)
 JOnAS (parte de ObjectWeb una iniciativa de código abierto)
 Microsoft .NET
 Novell exteNd (basado en la plataforma J2EE)
 WebLogic
 WebSphere
 JAX-WS con GlassFish
 Zope es un servidor de aplicaciones Web orientado a objetos desarrollado
en el lenguaje de programación Python
 VERASTREAM de AttachmateWRQ para modernizar o integrar
aplicaciones host IBM y VT

1.5.4 Otros

Corba

Common Object Request Broker Architecture (CORBA) es un estándar definido

por Object Management Group (OMG) que permite que diversos componentes de
software escritos en múltiples lenguajes de programación y que corren en
diferentes computadoras, puedan trabajar juntos; es decir, facilita el desarrollo de
aplicaciones distribuidas en entornos heterogéneos.
CORBA fue el primer producto propuesto por OMG. Su objetivo es ayudar a
reducir la complejidad, disminuir los costes y acelerar la introducción de
nuevas aplicaciones informáticas, promoviendo la teoría y la práctica de la
tecnología de objetos en los sistemas distribuidos.
Es una tecnología que oculta la programación a bajo nivel de aplicaciones
distribuidas. No obstante también brinda al programador una tecnología orientada
objetos; las funciones y los datos se agrupan en objetos y estos objetos pueden
estar en diferentes máquinas, pero el programador accederá a ellos a través de
funciones normales dentro de su programa.
CORBA es más que una especificación multiplataforma, también define servicios
habitualmente necesarios como seguridad y transacciones. Y así este no es un
sistema operativo en sí, en realidad es un middleware.

Entre las principales características de CORBA nos encontramos con:

 Independencia en el lenguaje de programación y sistema operativo:

CORBA fue diseñado para liberar a los ingenieros de las limitaciones en
cuanto al diseño del software. Actualmente soporta Ada, C, C++, C+
+11, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I y Python.
 Posibilidad de interacción entre diferentes tecnologías: uno de los
principales beneficios de la utilización de CORBA es la posibilidad de
normalizar las interfaces entre las diversas tecnologías y poder así
combinarlas.
 Transparencia de distribución: ni cliente ni servidor necesitan saber si la
aplicación está distribuida o centralizada, pues el sistema se ocupa de todo
eso.
 Transparencia de localización: el cliente no necesita saber donde ejecuta el
servicio y el servicio no necesita saber donde ejecuta el cliente.
 Integración de software existente: se amortiza la inversión previa
reutilizando el software con el que se trabaja, incluso con sistemas heredados.
 Activación de objetos: los objetos remotos no tienen por qué estar en
memoria permanentemente, y se hace de manera invisible para el cliente.
 Otras como: el fuerte tipado de datos, la alta capacidad de configuración,
libertad de elección los detalles de transferencia de datos, o la compresión de
los datos.

La arquitectura CORBA está orientada a objetos. En CORBA los objetos poseen

muchas de las características de otros sistemas orientados a objetos, como son la
herencia en cuanto a interfaces y el polimorfismo. Pero lo más interesante de este
aspecto, es la posibilidad de proporcionar estas características a lenguajes no
orientados a objeto como C o COBOL, aunque CORBA trabaja más
eficientemente con lenguajes orientados a objeto como son Java o C++.
Object Request Broker (ORB)
El Object Request Broker (ORB), es un componente fundamental de la
arquitectura CORBA y su misión es facilitar la comunicación entre objetos. Éste se
encarga de enviar las peticiones a los objetos y retornar las respuestas a los
clientes que las invocan por el proceso de serialización.
El ORB tiene como principal característica la transparencia. Facilita la
comunicación entre cliente y servidor ocultando:

 La localización de los objetos: El cliente no tiene porque saber donde se

encuentra el objeto destino, puede estar en su propia máquina o en un proceso
en una máquina remota.
 La implementación de los objetos: El cliente ignora el lenguaje de
programación con el que se ha escrito el objeto remoto, su implementación o el
sistema operativo en el que se encuentra.
 Estado de ejecución del objeto: Al enviar una petición sobre un objeto
remoto, el ORB se encarga de inicializar el objeto en caso de ser necesario,
antes de enviarle la petición.
 Mecanismos de comunicación de los objetos: El cliente no sabe qué
mecanismos de comunicación utiliza el ORB para enviar las peticiones y
retornar el resultado.