Material Sistemas Distribuidos PDF

Resumen Sistemas Distribuidos
MATERIAL DIDÁCTICO
SISTEMAS DISTRIBUIDOS
Introducción a los Sistemas Distribuidos
INTENCIÓN EDUCATIVA
Contribuir al fortalecimiento de tu formación profesional en los temas relevantes de
tecnologías de la información, especialmente en el campo de los sistemas
distribuidos, los cuales se han popularizado por la alta demanda de aplicaciones de
Internet. Con ello tendrás más y mejores oportunidades de incorporarte o
mantenerte actualizado en e l mercado laboral.
OBJETIVOS GENERALES
Al finalizar el curso, el participante será capaz de:
1. Entender y emplear los conceptos principales que caracterizan a los sistemas

distribuidos.
2. Distinguir los temas más importantes sobre la implementación de sistemas

distribuidos.
3. Desarrollar una aplicación de sistema distribuido en una plataforma de

desarrollo conveniente.
4. Apreciar las ventajas y desventajas del ambiente distribuido en aplicaciones de

computación móvil.
METODOLOGÍA
Se emplearán diferentes técnicas didácticas para cubrir los temas del curso y se
hará referencia en las actividades de aprendizaje sobre el manejo de ellas y la
forma de evaluación basada en rúbricas. Las técnicas didácticas son las
siguientes:
APRENDIZAJE BASADO EN PROBLEMAS (ABP)
La técnica de aprendizaje basado en problemas esta orientada al constructivismo, que

tiene por objeto conjuntar ideas o conocimientos individuales o grupales de los alumnos
sobre un tema, tarea o problema y colectivamente llegar a una síntesis, conclusiones o
realización de metas de aprendizaje. En esta técnica los roles del profesor o tutor, y
de cada alumno de un grupo es de suma importancia. Los pasos del ABP son los
siguientes:
1. Presentación del problema o tema

2. Lluvia de ideas y preguntas
3. Si idea relevante con respuesta, sigue paso 7
4. Si pregunta relevante sin respuesta y se puede investigar, sigue paso 5
5. Fijar meta de aprendizaje
6. Investigación individual
7. Discusión y reporte.
8. Si todavía hay ideas y preguntas sigue paso 3
9. Integración de solución.
COMPROBACIÓN DE LECTURA
La técnica de comprobación de lectura tiene como finalidad fomentar en el alumno la

habilidad de leer, analizar y comprender. Los materiales que se utilicen deben ser
recopilaciones de diferentes autores de un tema, para homogenizar los
conceptos e ideas referentes al tema.
La técnica de comprobación de lectura es una de las más empleadas en los

procesos de enseñanza-aprendizaje y tiene como finalidad conformar conceptos e
ideas propias al alumno, por lo que no pretende que se memoricen los temas
tratados.
ESTUDIO DE CASOS (EC)
El estudio de casos difiere de los sistemas de enseñanza tradicionales porque

exige que el alumno tome parte activa en el análisis de los problemas y en la toma
de decisiones para la solución a situaciones reales muy específicas. El proceso

que se siga para tomar decisiones y las decisiones mismas, sustentadas en un
análisis adecuado, son la clave. Este tipo de ejercicios nos permite aprender a
comunicar criterios, defender hechos y opiniones en debates. Los pasos del EC son
los siguientes:
1. Presentación del caso

2. Preparación individual
3. Grupos de discusión
4. Plenaria
APRENDIZAJE ORIENTADO A PROYECTOS (AOP)
La técnica de aprendizaje orientado a proyectos permite consolidar el proceso de

aprendizaje en un proyecto final que representa una conexión con la realidad, dado
que en pequeños grupos, los alumnos tienen la oportunidad de identificar sus propias
necesidades de aprendizaje, localizando los recursos y construyendo con b ase en
ellas. Los pasos del AOP son los siguientes:
1. Analizar el problema
2. Resolver el problema
3. Elaborar el producto
4. Generar el reporte
FUENTES DE INFORMACIÓN
Referencias bibliografías:
· Distributed Systems, Concepts and Design.

Couloris
Addison Wesley/Pearson
http://www.cdk3.net/
· Distributed Systems: Principles and Paradigms

Tanenbaum
Prentice Hall
http://www.prenhall.com/divisions/esm/app/author_tanenbaum/custom/dist_sys_1
e/
· Distributed Computing: Principles and Applications

Liu
Addison Wesley
http://www.csc.calpoly.edu/~mliu/book/
Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. VI

REGLAS Y EVALUACIÓN
El curso tiene una serie de actividades que sirven como medio para que los
alumnos encuentren significado y propicien la construcción de los conocimientos
bajo las estrategias didácticas que el programa señala. No se trata de ejercicios
memorísticos o de una labor informativa del tutor sino de desafíos, ejercicios e
investigaciones desarrolladas por los alumnos con un enfoque de aprendizaje
cooperativo e independiente. Los alumnos deberán entregar con oportunidad las
tareas individuales y en equipo determinadas para cada tema y con el formato
adecuado. El informe de los ejercicios prácticos que deban presentar tiene la
modalidad de que detallen o amplíen el funcionamiento de ellos o en su caso la
compilación correspondiente. Los alumnos deberán participar interactivamente
mediante los apoyos de e-mail, foros, y Chat para retroalimentar su trabajo en
equipo y comunicación con el tutor. Rúbrica de evaluación de comprobación de
lecturas como Evaluación Síntesis.
Tareas que se integran: TI (1) y TE (1)
· Rúbrica de evaluación de ejercicios prácticos como Evaluación Ejercicios.
Tareas que se integran: TI (2.1, 2.2.1, 2.2.2, 2.3), TI (3.2, 3.4, 3.5, 3.6) y TI (5).
· Rúbrica de evaluación de aprendizaje basado en problemas como Evaluación

ABP.
Tareas que se integran: TE (3.1)
· Rúbrica de evaluación de estudio de casos como Evaluación EC.
Tareas que se integran: TI (3.3) y TE (3.3)
· Rúbrica de evaluación de aprendizaje orientado a proyectos como Evaluación

AOP.
Tareas que se integran: TE (4.2)

CONTENIDO
BIENVENIDA ............................................................................................................................................................... II
INTENCIÓN EDUCATIVA ......................................................................................................................................... II
OBJETIVOS GENERALES ......................................................................................................................................... II
INTRODUCCIÓN ......................................................................................................................................................... II
METODOLOGÍA .......................................................................................................................................................... V
FUENTES DE INFORMACIÓN ............................................................................................................................... VI
REGLAS Y EVALUACIÓN .................................................................................................................................... VII
1. INTRODUC CIÓN ............................................................................................................................................... 1
1.1. FUNDAMENTOS ........................................................................................................................................................... 3
1.2. VENTAJAS Y FACTORES DE DISTRIBUCIÓN ........................................................................................................23
1.3. DESVENTAJAS Y FACTORES A CONSIDERAR ......................................................................................................25
1.4. EVOLUCIÓN ...............................................................................................................................................................26
2. ARQUITECTURA CLIENTE SERVIDOR................................................................................................... 33
2.1. FUNDAMENTOS DE ARQUITECTURA CLIENTE SERVIDOR ...............................................................................33
2.2. COMUNICACIÓN ENTRE PROCESOS ......................................................................................................................40
2.3. MODELO DE CAPAS..................................................................................................................................................80
3. TECNOLOGÍAS DE DESARROLLO ........................................................................................................... 91

3.1. INTRODUCCIÓN AL MIDDLEWARE ........................................................................................................................98
3.2. PROGRAMACIÓN DE TRANSACCIONES .............................................................................................................104
3.2 PROGRAMACIÓN DE TRANSACCIONES ........................................................................................................................108
3.3. CORBA................................................................................................................................................... 124
3.4. RMI ........................................................................................................................................................ 161
3.5. COM+ .................................................................................................................................................... 166
3.6. W EB SERVICES.......................................................................................................................................................221
Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. VIII

1. Introducción
Objetivos
Al término del estudio del tema de introducción, el participante comprenderá:
• Los conceptos fundamentales que caracterizan a los sistemas distribuidos.
• Las ventajas y desventajas que presentan los sistemas distribuidos.
• La evolución de los sistemas distribuidos.
Actividades (1)
Actividad 1.1
Realizar una síntesis sobre los conceptos de introducción del curso, tomando
como base el Material de Apoyo.
· Utilice tablas, ilustraciones, mapas mentales o en su caso mapas conceptuales.
· Consultar por lo menos otra fuente de información y mencionarla, con el fin de

enriquecer su trabajo de síntesis.
· La síntesis no debe de exceder más de seis cuartillas.
· Agregar sus objetivos de aprendizaje que desea alcanzar del curso.
Una vez completada la Actividad 1.1, colocar su documento en Tarea Individual (1)
Actividad 1.2
Discutir en equipo las características que muestran los sistemas distribuidos y

elaborar una síntesis.
· Intercambien sus mensajes de discusión en el Foro Actividad 1.2
Una vez completada la Actividad 1.2, colocar su documento en Tarea en Equipo

(1)
Nota Importante: Ambas actividades 1.1 y 1.2 serán evaluadas de acuerdo a la

rúbrica localizada en Evaluación Síntesis.
Introducción
La computación distribuida ha ido tomando más y más importancia con el impresionante
desarrollo de las telecomunicaciones y conforme los avances tecnológicos han hecho
posible la construcción de computadoras que caben en un escritorio pero con
procesadores muy poderosos y grandes capacidades de memoria y disco; Millones de
usuarios dependen de sistemas distribuidos diariamente para hacer transacciones
bancarias, reservaciones de vuelos, telefonía, enviar correos electrónicos, obtener
información de todo tipo y realizar operaciones de compra-venta.
Se pueden resaltar las siguientes peculiaridades del tema:
Es un área de cambios constantes, debido al vertiginoso avance de tecnologías, tanto

de hardware como de software de nuevas ideas, modelos conceptuales y
herramientas matemáticas.
La complejidad de un sistema distribuido que abarca gran cantidad de

problemas de muy diversos tipos.
Sin embargo, existe ya un cuerpo de principios fundamentales, de ideas básicas

subyacentes que permiten entender muchos de los aspectos de un sistema
distribuido. El objetivo de este curso es introducir al alumno a modelos, técnicas y
conceptos relevantes, independientemente de las tecnologías del momento.
Desarrollar en el alumno una capacidad de análisis, creatividad y razonamiento que
lo ayuden a atacar problemas de tipo distribuido.
El temario del curso trata de identificar aspectos esenciales de lo que es un

problema distribuido. Intenta ser una presentación coherente y continua,
buscando que los temas presentados parezcan suceder unos a otros de manera
natural. Más que aspirar a un alcance en cantidad de los temas presentados, es
decir, de información, el curso intenta desarrollar en el alumno habilidades.
Consideramos de primera importancia formar alumnos que puedan resolver

problemas complejos de sistemas distribuidos, así como alumnos con capacidad
crítica y creadora. Pensamos que la manera de lograr esto es: a) logrando un
entendimiento a fondo, y b) aprendiendo resolver problemas difíciles;
enfocándose en material esencial, en principios fundamentales subyacentes no
solo a las tecnologías del momento, sino a cualquier otra que aparezca en el
futuro. Esto es especialmente importante en vista de las dos siguientes
peculiaridades de esta área.
Primero, es esta un área de cambios constantes, debido al vertiginoso avance

de tecnologías, tanto de hardware como de software: las redes de computadoras
cambian constantemente, incorporando líneas de comunicación más rápidas
cada vez, y de nuevos tipos, como fibra óptica y redes móviles de radio. Nuevas
arquitecturas como ATM, sistemas cada vez mías sofisticados de televisión
Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. 2

interactiva, telefonía celular, comunicadores personales (pagers) que pueden

transmitir además de recibir. Multiprocesadores más poderosos, redes de
estaciones de trabajo. Se generan constantemente nuevas ideas, y modelos
conceptuales que cambian nuestra manera de ver el cómputo y manejo de
información distribuida; quizás el ejemplo más dramático es Web, pero existen otros
como las listas de correo y noticias electrónicas, nuevos lenguajes y
paradigmas, que generan nuevos problemas fascinantes y que cambian las
suposiciones de problemas conocidos (por ejemplo, la relación entre la velocidad de
procesamiento y la de transmisión). Entre tanto, se descubren nuevas y más
poderosas herramientas matemáticas para solucionar los problemas, como
probabilidad, álgebra combinatoria y topología.
Segundo, la enorme complejidad de un sistema distribuido, que se aprecia al

detenerse a pensar en la gran diversidad de problemas que abarca, algunos de
ellos son: aspectos de comunicación : códigos para detección de errores,
protocolos de enlaces, problemas de ruteo, congestión, ATM, etc.
Sincronización: exclusión mutua, relojes, abrazos mortales, etc. Manejo de
procesos: administración de recursos, threads, tolerancia a fallas, tiempo real,
calendarización, etc. Seguridad y criptología. Uso compartido de memoria.
Especificación, modelado y verificación. Complejidad y análisis de algoritmos.
Problemas que pueden observarse en sistemas de archivos, bases de datos y
sistemas operativos distribuidos.
1.1. Fundamentos
1.1.1 ¿Qué es un Sistema Distribuido?
Antes de definir lo que es un Sistema Distribuido, vamos a definir un término

más general: La Computación Distribuida, podemos definirla de muchas
maneras, este término se utiliza indiscriminadamente para referirse a cualquier
sistema en el que múltiples agentes autónomos, cada uno con capacidades de
cómputo individual, se comunican entre sí y afectan mutuamente su
comportamiento. Los agentes, usualmente llamados procesadores, procesos o
nodos, pueden ser desde computadoras completas hasta autómatas celulares
con capacidad de cómputo y memoria muy limitados que se pueden comunicar
mediante mensajes.
La Computación Distribuida hace referencia a cualquier evento en el cual se

maneja un sistema en una red de computadoras y trata de describir las
tendencias hacia la funcionalidad distribuida: sistemas distribuidos,
procesamiento distribuido, bases de datos distribuidas y cualquier otro término
computacional que sea distribuido. Podemos decir entonces, que la
Computación Distribuida se refiere a los servicios que provee un Sistema de
Computación Distribuido.

Una de las primeras caracterizaciones de un Sistema Distribuido fue realizada por

Enslow, ya en 1978, que le atribuye las siguientes propiedades:
 Está compuesto por varios recursos informáticos de propósito general,

tanto físicos como lógicos, que pueden asignarse dinámicamente a tareas
concretas.
 Estos recursos están distribuidos físicamente, y funcionan gracias a una
red de comunicaciones.
 Hay un sistema operativo de alto nivel, que unifica e integra el control de
los componentes.
 El hecho de la distribución es transparente, permitiendo que los servicios
puedan ser solicitados especificando simplemente su nombre (no su
localización).
 El funcionamiento de los recursos físicos y lógicos está caracterizado por
una autonomía coordinada.
A pesar del tiempo transcurrido, esta definición sigue siendo, en esencia, válida. Así,
para Coulouris un sistema distribuido es aquél que está compuesto por varias
computadoras autónomas conectadas mediante una red de
comunicaciones y equipadas con programas que les permitan coordinar sus
actividades y compartir recursos. Bal ofrece una definición muy similar: ``Un
sistema de computación distribuida está compuesto por varios procesadores
autónomos que no comparten memoria principal, pero cooperan mediante el paso
de mensajes sobre una red de comunicaciones''. Y según Schroeder, todo sistema
distribuido tiene tres características básicas:
 Existencia de varias computadoras. En general, cada una con su propio

procesador, memoria local, subsistema de entrada/salida y quizás incluso
memoria persistente.
 Interconexión. Existen vías que permiten la comunicación entre las
computadoras, a través de las cuales pueden transmitir información.
 Estado compartido. Las computadoras cooperan para mantener algún tipo
de estado compartido. El funcionamiento correcto del sistema se
describirse como el mantenimiento de una serie de invariantes globales
que requiere la coordinación de varias computadoras.
Como lo hemos observado, el término de Computación Distribuida se define de

varias maneras y lo mismo se aplica al término de Sistema Distribuido, así que en
lugar de seguir dando más definiciones de estos términos, nos
concentraremos en el análisis de las características más importantes de los
Sistemas Distribuidos, de esta manera podremos construir una definición propia de lo
que es un Sistema Distribuido al finalizar este capítulo.
Una característica muy importante es que las diferencias entre las computadoras
y las maneras en que estas se comunican no son transparentes para el usuario

final, esto mismo aplica para la organización interna del sistema distribuido. Otra
característica importante es que los usuarios y las aplicaciones pueden
interactuar con un Sistema Distribuido de manera consistente y uniforme, sin
importar donde y cuando se lleve a cabo la interacción.
Todo Sistema Distribuido bebe también ser relativamente fácil poder expandir, lo
cual se logra al tener computadoras independientes, pero al mismo tiempo
“esconder” las funciones de dichas computadoras en el sistema. Normalmente
un sistema distribuido debe de estar siempre disponible a pesar de que ciertas
partes que lo conforman puedan no estar funcionando. Los usuarios y las
aplicaciones no deben de notar en ningún momento que estas partes están
siendo reemplazadas o reparadas, o que se han agregado nuevas partes al
sistema para poder dar servicio a más usuarios o aplicaciones.
1.1.2 Características de un Sistema Distribuidos
Cualquier diseñador de sistemas debe tener los conocimientos necesarios para

enfrentarse a todas las complicaciones que pueden surgir al momento de
considerar los requerimientos para el desarrollo de un sistema distribuido. A
continuación explicaremos cada una de las características de los Sistemas
Distribuidos, según Coulouris son estas características, los desafíos que
presentan los sistemas distribuidos.
1.1.2.1 Heterogeneidad
Al hablar de heterogeneidad nos referimos a la variedad y diferencia que

podemos encontrar en los elementos que componen una red de computadoras sobre
la que se ejecuta un sistema distribuido, dicha heteroge neidad no sólo se aplica a
las redes y al hardware de las computadoras, sino también a los sistemas
operativos, los lenguajes de programación y las implementaciones en las que
trabajan los diferentes desarrolladores.
Un ejemplo de esto lo podemos ver muy claro en Internet, ya que es una red que
esta conformada por muchos tipos de redes (Figura 1) cuyas diferencias se
encuentran enmascaradas, puesto que todas las computadoras que se conectan
a este utilizan los protocolos de Internet para comunicarse una con otra, así una
computadora conectada a una red Ethernet puede comunicarse con otra
computadora conectada a una red Token Ring, basta con que se haga una
implementación de los protocolos de Internet para cada una de esas redes.

Figura 1. Un esquema clásico de la conexión a Internet
Otro ejemplo lo podemos ver en los lenguajes de programación y en las

aplicaciones escritas por diferentes programadores; en el caso de los lenguajes
de programación es importante tener en cuenta las diferencias que puede haber
en la representación de los caracteres y estructuras de datos como cadenas de
caracteres y registros, las cuales pueden variar y pueden ocasionar conflictos
entre programas que necesitan comunicarse entre ellos. De igual manera dos
programas que son desarrollados por programadores diferentes tienen que
utilizar estándares comunes para la comunicación en red y para la
representación de los datos elementales y las estructuras de datos en los
mensajes, ya que si no se cuenta con dichas similitudes, los programas no
podrán comunicarse entre sí aunque se hayan desarrollado en el mismo
lenguaje de programación.
Un término que no podemos dejar de mencionar al hablar de heterogeneidad es

el de Middleware (Figura 2); este término se aplica a la capa de software que
provee una abstracción de programación, así como un enmascaramiento de la
heterogeneidad subyacente de las redes, hardware, sistemas operativos y
lenguajes de programación; además, el Middleware proporciona un modelo
computacional uniforme al alcance de programadores de servidores y
aplicaciones distribuidas que permite la invocación sobre objetos remotos,
notificación de eventos remotos, acceso a bases de datos remotas y
procesamiento distribuido de transacciones. Algunos ejemplos de Middleware
son CORBA y Java RMI, los cuales se describirán con más detalle en el capítulo
3 de este curso.

Figura 2. Un sistema distribuido organizado como Middleware
Otro término importante para este apartado es el de código móvil, que se emplea
para referirse al código que pude ser enviado de una computadora a otra para
que esta última la ejecute, un ejemplo de un código móvil son los applets de
java, que son enviados del servidor a la computadora del cliente para que este
los ejecute en su explorador de Internet. Al implementar un código de este tipo
podemos encontrarno s con el problema de que el conjunto de instrucciones (a
nivel máquina) de una computadora puede no ser el apropiado para otra
máquina, por ejemplo, un usuario de una PC puede enviar un archivo ejecutable
a un usuario de Linux y este último no será capaz de ejecutar dicho archivo.
Para solucionar este problema se han creado lo que se conocen como máquinas
virtuales, las cuales proveen un modo de crear código ejecutable sobre cualquier
hardware, ya que el compilador de un lenguaje concreto generará un código
para una máquina virtual y esta se encargará de “traducir” dicho código al
apropiado para un hardware particular, así, un compilador de Java producirá un
código para la máquina virtual de Java, y esta última sólo necesitará ser
implementada una sola vez para cada máquina en la que se va a ejecutar.
1.1.2.2 Extensibilidad y Apertura
La extensibilidad y la apertura son dos características de un sistema distribuido que

están ampliamente ligadas la una con la otra. Algunos autores dicen que un sistema
abierto debe de ser extensible y otros sostienen que un sistema extensible
puede ser etiquetado como un sistema abierto. De cualquier manera lo que es
importante saber y tener en cuenta es que un sistema distribuido debe de contar con
ambas características.
Un sistema distribuido abierto es un sistema que ofrece servicios desarrollados

de acuerdo a reglas estandarizadas que describen la sintaxis y la semántica de
dichos servicios. Por ejemplo, en una red de computadoras, estas reglas son las
que regulan el formato, contenido y significado de los mensajes que se envían y
se reciben a través de dicha red. Estas reglas son formalizadas en protocolos.
En el caso de los sistemas distribuidos, los servicios se especifican
generalmente a través de interfaces que por lo general son descritas en un
Lenguaje de Definición de Interfaz (IDL por sus siglas en ingles), dicho lenguaje
especifica los nombres de las funciones que están disponibles así como los

parámetros de entrada, los valores de salida y los posibles errores que pueden
obtenerse al invocarse dichas funciones.
Si la definición de una interfaz se hace de manera adecuada, esta permitirá que dos
procesos puedan comunicarse entre sí, siempre y cuando ambos procesos cuenten
con la misma interfaz. Esto también permite que cada dos desarrolladores
independientes construya n su propia implementación de dichas interfaces, lo cual
conlleva al desarrollo de dos sistemas distribuidos desarrollados por separado
que operan de la misma manera.
Una especificación se considera adecuada cuando es completa y neutral.

Completa significa que todo lo necesario para hacer una implementación de la
interfaz ha sido especificado y que no será necesario que el propio desarrollador
sea quien agregue detalles específicos de la implementación. Neutral significa
que las especificaciones no deben tener ninguna tendencia hacia como se debe
de hacer la implementación de dicha especificación. La completitud y la
neutralidad son muy importantes para la interoperabilidad y la portabilidad, que
son características que complementan la apertura de un sistema distribuido. La
interoperabilidad, también conocida como compatibilidad, caracteriza el grado en
el que la implementación de sistemas o componentes de diferentes fabricantes
pueden coexistir y trabajar juntos, siempre y cuando se utilicen los servicios
como este especificado por el estándar común bajo el cual dichos sistemas
fueron desarrollados. La portabilidad por su parte caracteriza a que nivel puede
ser ejecutada una aplicación desarrollada para un sistema distribuido “A” sobre
un sistema distribuido “B” que implementa las mismas interfaces del sistema “A”,
pero sin hacerle modificaciones.
Uno de los principales objetivos que se persiguen al desarrollar un sistema

operativo abierto, es que este sea flexible, lo que implica que dicho sistema
puede ser integrado por diferentes componentes (tanto de hardware como de
software), posiblemente de diferentes proveedores, que nuevos componentes
pueden agregarse al sistema y que componentes existentes pueden ser
reemplazados sin afectar el funcionamiento de los componentes ya existentes,
en otras palabras, un sistema distribuido abierto debe de ser extensible.
Para lograr la flexibilidad en un sistema distribuido abierto es necesario que el

sistema este organizado en módulos o componentes relativamente pequeños y
fáciles de reemplazar, esto implica que además de definir las especificaciones y la
documentación de las interfaces de alto nivel a las que tienen acceso los usuarios
y las aplicaciones, también es necesario definir las especificaciones de las interfaces
de las partes internas que componen el sistema y describir de que manera interactúan
entre sí.

1.1.2.3 Seguridad
La gran mayoría de la información que maneja un sistema distribuido tiene un

alto valor para los usuarios de dicho sistema, y es por eso que la seguridad de la
información juega un papel clave al momento de desarrollar dicho sistema.
La seguridad de la información es todo lo que concierne a asegurar que no

ocurrirán cosas malas con los mensajes que envían los clientes para solicitar
información a un servidor, y por su puesto, con la información que estos reciben
como respuesta a sus peticiones. No basta con asegurar que estos mensajes serán
transmitidos de forma oculta, sino que tambié n hay que asegurar que la información
sea entregada únicamente a quien debe de ser entregada y que esto se hará
siempre de forma correcta y en el momento en que se requiere. La seguridad es
relativa a la amenaza que cada sistema afronta, afecta a todos los puntos del sistema
y debe de ser fácil de obtener.
La seguridad debe ofrecer los siguientes servicios:

 Confidencialidad, es decir, el manejo privado de la información: proteger la
información de ser accedida por usuarios no autorizados.
 Autentificación, o capacidad de asegurar la identidad de un usuario.
 Integridad, que asegura que la información que empleamos no ha sido
manipulada, alterada o corrompida desde el origen.
 No repudio, de una operación de emisión y recepción de información por
parte de los agentes.
 Control de acceso a la información y/o recursos administrados por un
sistema.
 Disponibilidad de los recursos necesarios de un sistema cuando estos sean
requeridos, lo que protege la información contra interferencia con los
procedimientos de acceso a los recursos.
El alto valor de que tiene la información es la razón principal por la que esta se
puede ver amenazada de muchas formas, entre las principales podemos
encontrar:
Interrupción: Destruye la información o la inutiliza. Ataca la disponibilidad.
Interceptación: Obtiene acceso a información. Ataca la confidencialidad.

Modificación: Modifica la información. Ataca la integridad.
Fabricación: Falsifica la información. Ataca la autenticidad.
Para defenderse de este tipo de amenazas se han desarrollado diversas

técnicas de encriptación, firmas digitales, implementación de barreras
perimetrales (firewalls), modelos de seguridad internos y externos, etc. Sin
embargo, estas técnicas parecen no ser suficientes para evitar que intrusos
logren interferir con el flujo de información óptimo de un sistema, ya que
encuentran formas de “brincarse” las barreras de seguridad de muchas
organizaciones y además siguen ideando nuevas formas de atacar y amenazar
la información, un ejemplo de estos nuevos ataques son los ataques de
denegación de servicio. Estos ataques consisten en bombardear un servicio con
un gran número de peticiones simultáneas (y por lo general inútiles) de modo
que el sistema se colapse, obstaculizando el servicio a los usuarios que desean
utilizarlo. Como hoy en día la capacidad de los sistemas distribuidos ha crecido
mucho, en ocasiones resulta muy difícil o incluso imposible bloquear el servicio
utilizando una sola computadora atacante, por lo que ahora se han desarrollado
los ataques de denegación de servicio distribuidos, los cuales hacen uso de
miles o incluso millones de computadoras para generar las peticiones al sistema
que se desea bloquear, por lo que bloquear un ataque de esta magnitud resulta
sumamente complicado.
Si bien no podemos asegurar que un sistema distribuido sea cien por ciento
seguro, es importante contar con un esquema de seguridad lo más robusto
posible, que a pesar de no ser inmune a todo tipo de ataques, si será capaz de frenar
la gran mayoría de dichos ataques. Algunas recomendaciones muy útiles para los
desarrolladores, administradores e implementadotes de un sistema distribuido se
presentan a continuación:
a) Efectuar un análisis de riesgos
Esto se suele mencionar en la literatura como el primer paso a realizarse cuando

se plantea la seguridad en un sistema. La idea es muy sencilla: trazar todos los
elementos que conforman nuestro sistema (hardware y software) y observar

cuáles involucran más o menos riesgo. Esto desembocará en un plan de

seguridad cuyo objetivo es disminuir el riesgo total del sistema, que se puede
modelar como la suma de los riesgos de sus componentes:
RIESGO TOTAL = RIESGO (componente 1) + RIESGO (componente 2)...
El riesgo de cada componente está en función directa a las pérdidas que
ocasionaría el que éste deje de operar, así como en función de cuán vulnerable
es dicho componente en este momento. Por ejemplo, una base de datos de
clientes involucra un gran riesgo debido al gran valor que la información
representa para una organización; pero una simple PC Windows de la misma
organización conectada directamente al Internet (sin firewall/proxy de por
medio) también lo representa, debido a que puede ser objeto de un ataque
desde el exterior, con el posible riesgo de fácil propagación hacia otros
computadores de nuestra red.
b) Lo más valioso debe alejarse de lo más vulnerable
En la fórmula del "riesgo" propuesta arriba, es evidente que los componentes de

nuestro sistema con alto valor y alta vulnerabilidad serán de lejos los que
presenten mayor riesgo. Sin embargo, en muchos casos no es sencillo disminuir
el valor de cierto componente (y por tanto la pérdida en caso de problemas), y
tampoco se puede eliminar completamente la vulnerabilidad del mismo (por
ejemplo, si está de cara a Internet.) En este caso lo que conviene es separar o
dividir este componente en dos partes suficientemente alejadas e
independientes a fin de que el riesgo total disminuya. Por ejemplo, los portales
de comercio electrónico deben dar cara a Internet (siendo vulnerables en
principio) y a la vez manejar información muy costosa (como transacciones con
tarjeta de crédito.) Esto los convierte en un sistema de alto riesgo. Sin embargo
es casi universal la separación que se efectúa entre los componentes dedicados
a dar cara a Internet (como los Web Servers) y los componentes que manipulan
la información comercial (generalmente sistemas DBMS.) En términos prácticos,
esto significa que el hacker no puede acceder directamente al DBMS (lo que
sería catastrófico), y sólo podría atacar al Web Server, lo que en principio no
acarrea mayo res consecuencias.

c) Mantener las cosas simples
Un sistema complejo es más difícil de asegurar y potencialmente proporciona una

mayor cantidad de puertas abiertas a los atacantes. En general, es
recomendable intentar dividir el problema mediante la simplificación de la
configuración, para así identificar los puntos o rutas de control vulnerables para
incrementar la seguridad.
La seguridad debe estar en todos los niveles
Esto se puede expresar más sencillamente como: no confiar el sistema a un único

mecanismo de seguridad.
La información fluye a través de los distintos componentes y/o capas del sistema
y son muchas las instancias en las que se puede mejorar su seguridad. La
recomendación estipula que utilicemos todas estas instancias a pesar de que en
principio puedan parecer redundantes. Por lo general los administradores
tienden a preocuparse por un único punto de acceso desde donde
supuestamente hay una gran probabilidad de ser atacados (por ejemplo, la
conexión a Internet.) Por tanto se invierte esfuerzo y dinero en controlar este
único punto bajo la asunción de que es la única puerta de entrada a los
maleantes y que por tanto, tras asegurarla, todo el sistema quedará seguro. Esto
tiene dos problemas:
Muchos ataques o "vulnerabilidades" se originan (de forma inocente o

intencional) desde dentro de la organización.
El sistema que controla la "puerta" siempre puede fallar.
Esto obliga a implementar la seguridad no en un único punto evidentemente

vulnerable, sino en todos los lugares por donde fluye la información al interior de cada
componente involucrado.
Encriptar tanto como sea posible
La encriptación es un tema complejo pero cuya implementación resulta cada vez más
sencilla conforme aparecen más productos. Los cambios del año pasado en la
legislación norteamericana con respecto a la exportación de productos que
encriptan, son un incentivo claro para que los desarrolladores y vendedores se
interesen más en el tema.
En general, los canales de comunicación más vulnerables o de mayor cercanía

al público requieren una encriptación "más fuerte", es decir, más difícil de
descifrar por los curiosos o atacantes. Cierta información conlleva más riesgo
que otra, y por tanto requerirá un nivel de encriptación diferenciado. Las
herramientas capaces de hacer esto son muchas, dependiendo del contexto en
que nos encontremos. Por ejemplo, los sistemas DBMS más avanzados

incorporan la encriptación como una opción normal para los datos almacenados,
generalmente bajo esquemas propietarios.
La tecnología de encriptación de información destinada a pasar a través de la

red ha evolucionado bastante, haciéndose popular el término VPN para hacer
referencia a canales que encriptan la información de un modo más o menos
transparente. Hay soluciones propietarias así como estándares relativamente
implementados como IP Sec. Ciertas aplicaciones estándares han recibido
soluciones de encriptación también estándar. El caso del Web encriptado bajo
SSL (HTTPS) junto con la industria de certificados digitales es el caso más
conspicuo. De igual modo los estándares para correo electrónico PGP (o
derivados) y S/MIME son integrados cada vez con mayor frecuencia en las
aplicaciones de los usuarios finales.
En nuestra organización deberíamos encriptar todo lo que sea posible. La razón

de esto es evidente si de lo que se trata es de enviar un mensaje privado por
Internet. Sin embargo, al interior de la organización la encriptación puede ayudar
también. Naturalmente hay que sopesar los inconvenientes que trae la
encriptación en términos de incomodidad de uso, costo de licencias, ciclos de
CPU, etcétera; con el hecho de que cierta información es definitivamente de
carácter público y por tanto no tiene sentido que esté encriptada.
Además de estas hay muchas más recomendaciones de seguridad que

podemos mencionar, por ejemplo: no confiar en la autenticación estándar, no
usar la configuración "estándar", educar a los usuarios, ejecutar sólo los
servicios imprescindibles, mantenerse al día con las actualizaciones y hacer
chequeos regulares, establecer planes de contingencia y sistemas de respaldo,
mantener contacto con el proveedor de líneas de comunicación, no permitir
conexiones directas desde la red interna a Internet, hacer uso de una red
perimétrica o zona desmilitarizada, prácticas de programación segura, vigilancia,
establecimiento de políticas, etc.
1.1.2.4 Escalabilidad
La escalabilidad es una de las características más importantes para los

desarrolladores de un sistema distribuido. Se dice que un sistema es escalable si
logra conservar su efectividad cuando hay el número de recursos y el número de
usuarios incrementa significativamente. La escalabilidad de un sistema pude medirse
en tres aspectos diferentes:
Con respecto a su tamaño: lo que significa que se pueden agregar más usuarios y
más recursos al sistema de una manera muy fácil.
Con respecto a su localización o área de implementación: lo que significa que tanto
los usuarios como los recursos pueden estar en locaciones remotas y separadas
el uno del otro.

Con respecto a su administración: lo que significa que puede ser fácil de

administrar a pesar de que se utiliza en diferentes organizaciones
independientes que cuentan con diferentes políticas de seguridad y que hacen un
uso particular del sistema. Desafortunadamente, un sistema que es escalable en uno
o más de estos aspectos por lo general afecta el rendimiento del sistema conforme al
crecimiento del mismo.
Problemas de la Escalabilidad
Cuando se necesita escalar un sistema a un nivel más alto es muy común que surja
algún tipo de problema. Si consideramos la escalabilidad con respecto al tamaño de
un sistema, nos encontramos con las limitaciones que presentan los servicios, los
datos y los algoritmos centralizados.
En muchos sistemas distribuidos es común encontrar servicios centralizados, es

decir, que son implementados en un mismo servidor, lo que puede ocasionar un
problema muy obvio: este servidor puede convertirse en un cuello de botella si el
número de usuarios crece, y a pesar de tener una capacidad de procesamiento y
almacenamiento virtualmente ilimitada, la comunicación con este servidor puede
llegar a tener un límite y eventualmente impedir el crecimiento del sistema.
Desafortunadamente el uso de un sólo servidor puede ser inevitable, ya que por
lo general tenemos servicios que trabajan con información muy sensible y que
tiene que ser lo más segura posible, por lo que el tener esta información
almacenada en diferentes servidores puede llegar a poner la información en
riesgo y hacer el sistema más vulnerable.
De la misma manera, el almacenamiento centralizado de la información puede

ser un grave problema para un sistema distribuido, ya que a pesar de que un
sólo servidor nos puede ofrecer la capacidad de almacenamiento que
necesitamos, es muy poco probable que dicho servidor permita el acceso
simultáneo a miles o incluso millones de usuarios que desean consultar la
información almacenada en él. Un ejemplo de esto es el Sistema de Nombre de
Dominio, que a pasar de poder almacenar todos los registros en una sola base
de datos de varios gigabytes, no podría dar una respuesta a los millones de
usuarios de Internet que accedan este servicio simultáneamente.
El uso de algoritmos centralizados es en teoría la solución óptima a un problema

de computación distribuida, sin embargo, en la práctica podemos ver que el uso
de este tipo de algoritmos en un sistema distribuido grande no es una buena
idea, ya que colectar y transportar los datos de entrada y salida del sistema
hacia un sólo punto en el que se computan dichos datos pudiese sobrecargar
parte de la red con todos los mensajes que necesita enviar y recibir, además de
que el computo de toda la información en una sola máquina tiene más riesgo a
fallos y puede resultar más tardada. La solución a este problema es el uso de
algoritmos descentralizados, los cuales cuentan con ciertas características que

los diferencian de los algoritmos centralizados, entre las que podemos

mencionar:
Ninguna máquina tiene información completa del estado del sistema.

Cada máquina toma decisiones propias basándose solamente en información
local.
Problemas o fallos de una máquina no arruinan el procesamiento de todo el
algoritmo.
No necesariamente se cuenta con un reloj global (algoritmos no sincronizados).
A pesar de que en una LAN pudiese sincronizarse la ejecución de un algoritmo

descentralizado, este mismo procedimiento pudiese ser muy complicado o
incluso imposible si el algoritmo esta distribuido en una red más amplia, por lo que
no se debe de depender en la existencia de un reloj global para hacer posible la
ejecución de un algoritmo de este tipo.
Por otro lado tenemos los problemas de la escalabilidad con respecto a la

localización o área de implementación de un sistema distribuido. Una de las
principales razones por las cuales resulta difícil escalar los sistemas distribuidos
que existen actualmente, es que dichos sistemas fueron diseñados para trabajar
redes de acceso locales (LANs) y que están basados en una comunicación
síncrona. En este tipo de comunicación el cliente hace la solicitud de un servicio
y hace un bloqueo de la comunicación hasta que recibe la respuesta. Este
acercamiento por lo general trabaja bien en LANs en las que la comunicación
entre dos máquinas por lo general no toma más de algunos cientos de
microsegundos. En el caso de las WANs, tenemos que tomar en cuenta que la
comunicación entre los procesos pudiese tomar varios cientos de milisegundos, lo
que representa un alentamiento muy considerable del sistema.
Otro problema a considerar es que la comunicación en una WAN es poco

confiable y en la gran mayoría de los casos es punto a punto, al contrario de las redes
locales que generalmente son muy confiables y permiten hacer difusiones o
transmisiones de tipo “broadcast”, lo que hace mucho más fácil el desarrollo de
sistemas distribuidos.
La escalabilidad con respecto a la localización o área de implementación esta

directamente relacionada con los problemas de soluciones centralizadas
comentados anteriormente. Si tenemos un sistema con muchos componentes
centralizados, es muy claro que la escalabilidad del área de implementación será
imitada gracias a los problemas de desempeño y confiabilidad que trae consigo
la implementación en un área de redes extensa. Además, los componentes
centralizados también provocan el desperdicio de recursos de red.
Finalmente, podemos mencionar los problemas que acarrea la escalabilidad de

la administración de un sistema distribuido. Este problema se da cuando un
sistema distribuido de expande a otro dominio, que por lo general contará con

diferentes políticas de uso y pago de recursos, administración y seguridad. Por lo

general cuando esto pasa se deben de tomar al menos dos tipos de medidas de
seguridad:
El sistema distribuido tiene que protegerse de ataques malignos provenientes del

nuevo dominio, yrestringir el acceso a los servicios y datos que no están a
disponibilidad de los usuarios del mismo.
El nuevo dominio tiene que protegerse de ataques malignos provenientes del
sistema distribuido. Básicamente, el nuevo dominio no sabe que tipo de
información puede esperar del código enviado por el nuevo dominio por lo que
pudiera decidir limitar los permisos de acceso a dicho código.
Técnicas de Escalabilidad
Una vez que mencionamos ya los problemas de la escalabilidad, analizaremos

algunas maneras de solucionar dichos problemas. Como los problemas de
escalabilidad de los sistemas distribuidos se manifiestan como problemas de
rendimiento causados por la capacidad limitada de servidores y de las redes de
comunicaciones, existen solamente tres técnicas de escalabilidad: eliminar la
latencia de las comunicaciones, distribución y replicación.
Eliminar la latencia de las comunicaciones es útil en el caso de querer lograr la

escalabilidad geográfica de un sistema, la idea básica es simple: tratar de evitar
la espera de respuestas a las peticiones que se hagan a servicios remotos lo
más que se pueda. Esencialmente, esto significa que se tiene que construir la
aplicación que realiza las peticiones de tal manera que use solamente métodos
de comunicación asíncronos, es decir, que el cliente envía la petición al servidor,
mientras espera la respuesta el cliente aprovecha ese tiempo para realizar
tareas locales más importantes y cuando recibe la respuesta del servidor, el
proceso que se estaba realizando se interrumpe y se atiende la respuesta
recibida. Esta solución parece fácil, sin embargo, hay muchas aplicaciones que
no pueden hacer un uso efectivo de la comunicación asíncrona, por ejemplo,
aplicaciones interactivas en las que el usuario no tiene nada mejor que hacer
más que esperar la respuesta del servidor, por que esta se tiene que dar lo más
rápido que sea posible. En dichos casos, es mucho mejor solucionar el problema
de la latencia reduciendo el tráfico generado entre el cliente y el servidor cuando
se comunican entre sí; esto lo podemos lograr moviendo parte de la
computación que normalmente se hace del lado del servidor al cliente, para que
así sea el mismo proceso que hace la solicitud del servicio quien tenga que
procesarlo.
Otra técnica importante para lograr la escalabilidad es la distribución, que

consiste en tomar un elemento, separarlo en partes pequeñas y distribuir esas
partes en todo el sistema. Un ejemplo de un sistema distribuido que hace uso de
la distribución es el servicio de nombre de dominio (DNS), el cual esta distribuido
en diferentes servidores que permiten el acceso a la misma información a todos

los usuarios, sin necesidad de tener un sólo servidor que proporcione este
servicio.
En la mayoría de los casos, los problemas de escalabilidad los vemos reflejados

en el rendimiento del sistema, por lo que generalmente la replicación de los
componentes del sistema distribuido puede resultar ser una buena idea. La
replicación aumenta la disponibilidad de los componentes del sistema y además
ayuda a balancear la carga entre los componentes que se replican, con lo que
se logra una mejora del rendimiento del sistema. Si consideramos un sistema
que se encuentra distribuido en una red muy extensa, el hecho de tener una
copia de algún componente más cerca, también mejora el rendimiento del
sistema puesto que soluciona los problemas de latencia de las comunicaciones
que ya mencionamos anteriormente.
Una forma especial de replicación es el Cacheo, el cual consiste en guardar una

copia de algún recurso (por lo general, de datos) de forma temporal en un lugar
cercano al cliente, para que éste lo pueda acceder más fácilmente. En contraste
con la replicación, el cachear un recurso es una decisión que es tomada por el
cliente, y no por los diseñadotes del sistema. Un problema muy serio que puede
traer el cacheo, es que las copias que se hacen del recurso (o de datos) pueden
no actualizarse a su debido tiempo, por lo que al haber varias copias diferentes
del mismo recurso, lo que provoca problemas de consistencia dentro del
sistema; el nivel de inconsistencia que pueda ser tolerado por un sistema
depende del uso que se le da a al recurso que se esta replicando, en el caso de
páginas Web estáticas, por ejemplo, pudiese ser bastante tolerable, sin
embargo, en el caso de páginas dinámicas o de sistemas en tiempo real, la
replicación puede traer consigo muchos problemas.
1.1.2.5 Tratamiento de Fallos
El fallo tanto del hardware como el software es algo prácticamente inevitable, y por
más confiable que pueda parecer algún componente, siempre es importante estar
preparado para cuando este falle. En un sistema centralizado por lo general el
fallo de cualquier componente del sistema provoca que todos los servicios que
este ofrece dejen de funcionar, en cambio, en un sistema distribuido, los fallos
son parciales, puesto que solo afectan a los servicios que el componente que fallo
este prestando, mientras que otros servicios que prestan otros componentes siguen
funcionando.
El tratamiento de fallos en un sistema distribuido es una tarea difícil, pero que se

puede lograr si se utilizan las técnicas adecuadas, según el sistema que se
desee proteger. Algunas de las técnicas más comunes son:
Detección de Fallos: obviamente no es posible tratar un fallo si este no se ha

detectado, sin embargo, la detección de un fallo dentro de un sistema distribuido
puede no ser tan sencillo como parece, recordemos que además de

componentes de hardware y software, los sistemas distribuidos operan gracias a

la transmisión de mensajes, y el funcionamiento del sistema depende en gran
parte de estas transmisiones de datos entre los diferentes componentes; un fallo
en la transmisión de datos entre componentes no es fácil detectar, pero es algo
que podemos esperar (dependiendo del medio por el que se haga la transmisión
y otras condiciones) y al saber que existe la posibilidad de ese fallo, podemos
monitorear y aplicar técnicas que aseguren que dicha transmisión siempre sea
correcta.
Enmascaramiento de Fallos: una vez que un fallo es detectado, es importante

encontrar la manera para que un usuario del sistema no note dicho fallo y que
pueda seguir utilizando el sistema de manera normal, esto es, ocultar los fallos
del sistema y encargarse de que los servicios que se ofrecen al cliente nunca
sean interrumpidos. Son muchos ejemplos del enmascaramiento de fallos, en el
caso de un mensaje que se corrompió al ser enviado, una manera de ocultar el
fallo es haciendo la solicitud de reenvío del mensaje, y de esta manera el
usuario nunca notará que hubo un problema. Otro ejemplo lo dan las técnicas de
redundancia que explicaremos más adelante, pero que básicamente consiste en
tener disponibles varios elementos que puedan dar el mismo servicio y que en
caso de que uno falle, otro este en la disponibilidad de realizar el trabajo en su
lugar, esto puede darse cuando fallan componentes de un servidor (discos
duros, tarjetas de red, etc.), o incluso cuando fallan las conexiones a la red o los
sistemas de bases de datos.
Tolerancia a Fallos: es importante saber cuando un sistema puede llegar a tener

ciertos problemas sin que estos afecten de manera grave al usuario de los
servicios proporcionados, para así, ignorar la ocurrencia de dichos fallos cuando
la aplicación lo soporte, o bien, hacer saber al cliente que hay un problema en
lugar de gastar tiempo y recursos innecesarios para corregirlo cuando
probablemente el problema no se pueda arreglar rápido y el cliente termine por
abortar el proceso; Pretender arreglar de manera inmediata todos los problemas
que puedan surgir en un sistema puede resultar incluso dañino para el mismo
sistema, puesto que hay problemas que mientras son arreglados pueden afectar
el rendimiento de otros componentes del sistema que sí están trabajando.
Recuperación Frente a Fallos: Una vez que fue detectado un fallo y que se ha
decidido arreglarlo, hay que encontrar la mejor manera de hacerlo, y además, de
recuperar el estado del sistema antes de que ocurriera el fallo; esto requiere del
software adecuado para poder reconstruir o bien retractar los cambios que no
fueron completados al momento en que fue interrumpido el sistema, un ejemplo
de esto lo podemos ver en los sistemas manejadores de bases de datos, que se
sirven de una bitácora de las transacciones que se realizan y de acuerdo a esta
bitácora se decide reconstruir o retractar las transacciones hechas sobre la base
de datos antes de que se interrumpiera el funcionamiento de la misma.

Redundancia: un sistema distribuido puede lograr ser tolerante a fallos gracias a

la utilización de componentes redundantes dentro del sistema. La redundancia
se logra con la replicación de dichos componentes y con la habilidad del sistema
de recurrir a los componentes de respaldo en caso de que el componente de uso
primario falle, todo esto por supuesto, sin que el usuario se percate de lo que
esta sucediendo. La redundancia se puede dar en muchas partes del sistema:
componentes internos de los servidores, servidores de aplicaciones, de Web, de
archivos, de correo o de bases de datos, sistemas de almacenamiento,
conexiones a la red de comunicación, etc. Es muy importante tomar en cuenta
que todos los componentes que estén replicados en el sistema deben
mantenerse actualizados para evitar problemas de consistencia, y además, la
actualización de la información entre dichos componentes no debe de tener un
efecto significativo para las necesidades de transmisión de datos del sistema.
Las técnicas antes mencionadas no son las únicas, pero si las más utilizadas, estas
técnicas deben de proporcionar las herramientas necesarias para aumentar el
grado de disponibilidad de cualquier sistema distribuido, ya que al saber como tratar
un fallo del sistema, también es posible encontrar la manera de reconfigurar el
sistema para que los servicios que este proporciona no sean interrumpidos, o que en
el peor de los casos sólo sean afectados los servicios proporcionados por los
componentes afectados.
1.1.2.6 Concurrencia
El control de concurrencia trata con los problemas de aislamiento y consistencia

del procesamiento de transacciones. El control de concurrencia de un sistema
distribuido asegura que la consistencia de los datos que se almacenan y que se
procesan en el sistema se mantienen en un ambiente distribuido multiusuario. Si
las transacciones son internamente consistentes, la manera más simple de
lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin
embargo, esto puede afectar mucho el desempeño de un sistema distribuido
dado que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia,
es decir, el número de transacciones simultáneas activas, es probablemente el
parámetro más importante en sistemas distribuidos. Por lo tanto, los
mecanismos de control de concurrencia buscan encontrar un balance entre el
mantenimiento de la consistencia de os datos y el mantenimiento de un alto
nivel de concurrencia.
Si no se hace un adecuado control de concurrencia, se pueden presentar dos

anomalías. En primer lugar, se pueden perder actualizaciones provocando que
los efectos de algunas transacciones no se reflejen en los datos almacenados.
En segundo término, pueden presentarse recuperaciones de información
inconsistentes. Las técnicas que se utilizan para asegurar un control de
concurrencia de un sistema distribuido, como hilos, semáforos, candados, etc.,
se discutirán más adelante, en la parte de análisis de la arquitectura de cliente-
servidor.

1.1.2.7 Transparencia
Se dice que un sistema distribuido es transparente, cuando este es capaz de

presentarse ante los usuarios y las aplicaciones como si fuese un sistema que
corre en una sola computadora, y no como un sistema cuyos procesos y
recursos están distribuidos físicamente en varias computadoras.
1.1.2.7.1 Tipos de Transparencia
Según el Manual de Referencia ANSA y el Modelo de Referencia para el

Procesamiento Distribuido Abierto de la Organización Internacional de
Estándares (ISO 1995), el concepto de transparencia de puede aplicar a 8
aspectos diferentes de un sistema distribuido:
Transparencia de Acceso: oculta las diferencias entre la representación de los

datos y la manera en que los recursos son accedidos.
Transparencia de Ubicación: oculta la localización de los recursos y permite el
acceso a los mismos sin la necesidad de conocer su localización.
Transparencia de Migración: oculta que un recurso o un cliente del sistema sea
reubicado, lo que permite hacer dichas reubicaciones sin afectar la operación de los
usuarios y los servicios.
Transparencia de Recolocación: oculta que un recurso o un cliente del sistema
pueda moverse a una ubicación diferente mientras están en uso.
Transparencia de Replicación: oculta la existencia de múltiples ejemplares del
mismo recurso.
Transparencia de Concurrencia: oculta que un recurso sea compartido por varios
usuarios sin interferir entre ellos mismos.
Transparencia Frente a Fallos: oculta el fallo y recuperación de un recurso
dentro del sistema, dejando que los usuarios terminen sus tareas a pesar de los fallos
de hardware o software que pudieran presentarse.
Transparencia de Persistencia: oculta si un recurso (de software) esta
almacenado en memoria o en disco.
Desde el punto de vista de los usuarios, la transparencia se logra cuando:

Sus pedidos se satisfacen con ejecuciones en paralelo en distintas máquinas. Se
utilizan una variedad de servidores de archivo s.
El usuario no necesita saberlo ni notarlo.
La transparencia desde el punto de vista de los programas significa diseñar la

interfaz de llamadas al sistema de modo que no sea visible la existencia de varios
procesadores.

No es transparente un sistema donde el acceso a los archivos remotos se

realice mediante:
El establecimiento explícito de una conexión en la red con un servidor remoto.

El envío posterior de mensajes, donde el acceso a los servicios remotos será
distinto al acceso a los servicios locales.
Con todo esto en mente es posible diseñar un sistema que cuente con las
características necesarias para lograr la transparencia en tantos aspectos como
sea posible. Los dos más importantes son la transparencia de acceso y la
transparencia de ubicación, la primera se relaciona con la forma en que
representamos los datos en un sistema distribuido, es importante presentar al
usuario o a los programadores el acceso indistinto a recursos locales o remotos,
sin que este se de cuenta de la ubicación de los mismos, lo que al mismo tiempo
nos conduce a tener transparencia de ubicación dentro del sistema.
Como no se sabe donde están localizados los recursos, tampoco se debe de

saber si estos se mueven a una nueva ubicación, se este o no utilizando el
sistema, esto es lo que se conoce como transparencia de Migración y
Recolocación respectivamente.
Ejemplos de transparencia de acceso, ubicación y migración es el sistema de

nombre de dominio utilizado por los usuarios de Internet, estos utilizan un
nombre de dominio como “dominio.com” para acceder este sitio, sin importar en
donde este localizado el sitio de Internet, el usuario podrá acceder al servidor en
el que se este hospedando la página, y si se decide mover este sitio a otro
servidor, basta con redireccionar al cliente al servidor adecuado, sin que el
cliente lo note. Por su lado, si el cliente esta accediendo al sitio desde una
conexión inalámbrica dentro de su lugar de trabajo y esta en movimiento, es
posible seguir proporcionando servicios sin interrupciones al cliente siempre y
cuando el sistema sea transparente a la recolocación y permita que el cliente
siga conectado a pesar de cambiar su ubicación física.
Por otro lado, la replicación juega un papel muy importante dentro de un sistema
distribuido, en el caso de los nombre de domino, los servidores DNS trabajan en
un sistema de replicación distribuida organizado jerárquicamente que hace
posible el acceso simultáneo a millones de usuarios que requieren de la
información que contiene esta base de datos, sin embargo, la transparencia de
la replicación en el sistema consiste en esconder que existen varias copias de
un mismo recurso, y por lo general implica que dentro del mismo sistema se
cuenta con transparencia de ubicación, puesto que de otra manera sería
imposible acceder a las copias de los recursos con que se cuenta.
La idea de un sistema distribuido es poder proporcionar a sus usuarios un

servicio simultáneo a un mismo recurso; es entonces muy común que varios
usuarios intenten hacer uso del mismo recurso al mismo tiempo y que traten de

competir por el uso de dicho recurso; en estos casos la transparencia de

concurrencia nos ayuda a ocultar al usuario que además de él, hay otros usando
o intentando usar el mismo recurso. El reto más interesante de esta parte del
diseño de un sistema distribuido es que también se tiene que considerar la
consistencia de los datos que se almacenarán en el sistema, por lo que habrá
que tomar decisiones en cuanto a las técnicas de candados y de uso de
semáforos a utilizarse para lograr tener un sistema concurrente y a su vez
consistente.
La transparencia frente a fallos consiste en esconder cualquier falla que ocurra

en el sistema para que el usuario pueda hacer uso del mismo a pesar de que
alguno de sus componentes no este trabajando como es debido, uno de los
retos más desafiantes de esta tarea es saber distinguir entre recursos que están
fallando y recursos que simplemente están siendo accedidos por muchos
usuarios y cuya respuesta puede alentarse. Es importante tener un buen
esquema de replicación y de balanceo de cargas para evitar estas situaciones,
pero al ser prácticamente inevitables es necesario considerar que hacer cuando
el sistema esta en una situación como la antes mencionada, y sobre todo
determinar que tipo de respuesta enviar al cliente para que este no se de cuenta
de las fallas del sistema.
1.1.2.7.2 Grado de Transparencia
A pesar de que la transparencia es una característica generalmente deseable para

cualquier sistema distribuido, hay situaciones en las que el pretender
enmascarar todos los aspectos relacionados con la distribución de los
componentes del sistema puede no ser lo más óptimo; en algunas ocasiones es
mejor hacer del conocimiento del usuario que el sistema esta compuesto por varios
elementos y que por más óptima que sea la transmisión de mensajes o la distribución
y replicación de componentes, habrá cierto tiempo de respuesta mínimo entre cada
transacción que es imposible evitar.
Hay también una relación directa entre el nivel de transparenc ia y el rendimiento

de un sistema distribuido, por lo que lo ideal es encontrar un bien equilibrio entre
ambos factores. Por ejemplo, si pretendemos garantizar la transparencia de
replicación en un sistema, es necesario que el usuario sepa que para garanti zar
la consistencia de la información es necesario actualizar todos los componentes
replicados cuando se hace un cambio, por lo que el acceso al sistema puede
verse interrumpido por algunos segundos mientras esta operación se lleva a
cabo.
Es muy importante considerar la transparencia como uno de los principales

objetivos del diseño e implementación de un sistema distribuido, sin embargo, es
importante tener en consideración otros factores que pueden ser afectados por la
transparencia, principalmente el desempeño general del sistema.

1.2. Ventajas y Factores de Distribución
En general, los sistemas distribuidos exhiben algunas ventajas sobre los

sistemas centralizados que se describen enseguida.
1.2.1 Factores Estratégicos
Hoy en día, los clientes, proveedores y compañías se encuentran generalmente

en diferentes localidades alejados los unos de los otros. Debido a que todos
estos utilizan computadoras, las redes de información que los unen y que les
permiten interactuar pueden ofrecer a las empresas mayor competitividad.
1.2.2 Costos de Equipo
El cociente precio/desempeño de la suma del poder de los procesadores

separados, contra el poder de uno solo centralizado, es mejor cuando están
distribuidos, esto lo podemos calcular con base al costo promedio de MIPs
(Millones de Instrucciones por Segundo), el cual es mucho mayor en
mainframes que en un número fijo de estaciones de trabajo. Sin embargo, cabe
mencionar que los mainframes soportan cientos de dispositivos y permiten que miles
de clientes compartan los mismos recursos computacionales del mismo, aunque la
diferencia en costos es enorme.
1.2.3 Conocimiento y control de los usuarios
La gran mayoría de los usuarios de los servicios computacionales son cada vez más
cultos y competentes por lo que dichos usua rios desean operar sus propios sistemas,
a su manera, por lo que no están contentos con los sistemas centralizados que
llevan el control sobre los sistemas que son desarrollados, cuándo, cómo y por
quiénes son operados. La computación distribuida ofrece a los usuarios estar más
cerca de los procesos y de los datos.
1.2.4 Costos de Desarrollo
Cuando se trabaja con un sistema distribuido que cuenta con diferentes módulos de
software que pueden integrase como parte de un solo sistema, los usuarios finales
interesados en desarrollar sus propias aplicaciones pueden hacerlo utilizando
sus propias máquinas, lo que trae como consecuencia la reducción del costo y tiempo
de desarrollo de una nueva aplicación.
1.2.5 Interfaces de Usuarios
La mayoría de las estaciones de trabajo que se utilizan hoy en día soportan el

uso de interfaces gráficas sofisticadas con dispositivos de señalamiento y
sistemas de audio y video; esta tecnología resulta ser muy atractiva
especialmente para usuarios con diferentes estilos de aprendizaje que por lo

general se decepcionan por los tradicionales repotes o interfaces presentadas en

formato de texto o con gráficos de poca calidad.
1.2.6 Flexibilidad y Facilidad de Configuración
Los sistemas distribuidos, y en general la computación descentralizada, ofrece

muchas opciones para mejorar el desempeño y la fiabilidad de un sistema
mediante el uso de procesos y datos redundantes.
1.2.7 Explotación del Hardware
Las estaciones de trabajo y computadoras personales permiten el desarrollo de

software especializado que hace uso de las características específicas del
hardware de la estación de trabajo, cada una de estas estaciones puede ser
utilizada como un servidor especializado (por ejemplo, de correos, de Web, de
archivos, de bases de datos, etc.) y estos servidores con los que satisfacen las
peticiones de clientes que desean hacer uso de los servicios con los que cuenta
dicho servidor. A esta configuración se le conoce comúnmente como
configuración “cliente-servidor” y se explicará a detalle más adelante.
1.2.8 Nuevas aplicaciones
Muchas aplicaciones nuevas de tiempo real requieren ser procesadas y

acceder datos de manera local, lo cual es posible solamente si se utiliza un
sistema distribuido con estaciones de trabajo distribuidos en los lugares que más
se requiera.
1.2.9 Crecimiento
El poder total del sistema puede irse incrementando al añadir pequeños

sistemas, lo cual es mucho más difícil en un sistema centralizado y caro.
Por otro lado, los sistemas distribuidos también exhiben algunas ventajas sobre
sistemas aislados. Estas ventajas son:
Compartir datos: un sistema distribuido permite compartir datos más fácilmente

que los sistemas aislados, que tendrían que duplicarlos en cada nodo para
lograrlo.
Compartir dispositivos: un sistema distribuido permite acceder dispositivos desde

cualquier nodo en forma transparente, lo cual es imposible con los sistemas
aislados. El sistema distribuido logra un efecto sinergético.
Comunicaciones: la comunicación persona a persona es factible en los sistemas

distribuidos, en los sistemas aislados no.

Flexibilidad: La distribución de las cargas de trabajo es factible en el sistema

distribuido, se puede incrementar el poder de cómputo.
1.3. Desventajas y Factores a Considerar
Así como los sistemas distribuidos exhiben grandes ventajas, también se

pueden identificar algunas desventajas, algunas de ellas tan serias que han
frenado la producción comercial de sistemas distribuidos en la actualidad.
1.3.1 Falta de Estándares
La falta de estándares y herramientas de desarrollo para ambientes distribuidos

pueden crear graves problemas de compatibilidad, portabilidad e
interconectividad en los sistemas distribuidos. Esto se da cuanto se crean
muchas copias incompatibles de la misma aplicación. El desarrollo y us o de
estándares para aplicaciones, computadoras y redes son desarrolladas en
lugares, por personas y en tiempos diferentes, lo cual resulta muy complicado, y
es por eso que es común ver este tipo de problemas en un sistema distribuido.
1.3.2 Complejidad del Diseño
Los grandes sistemas de computadoras pueden distribuirse en muchas

computadoras, sin embargo, separar el sistema en muchas partes y decidir en
que lugar van a residir dichas partes, no es una tarea trivial. Los problemas de
compartir datos y recursos son tan complejos que los mecanismos de solución
generan mucha sobrecarga al sistema haciéndolo ineficiente. El verificar, por
ejemplo, quiénes tienen acceso a algunos recursos y quiénes no, el aplicar los
mecanismos de protección y registro de permisos consume demasiados
recursos. En la actualidad, las soluciones para estos problemas son incipientes.
1.3.3 Falta de Infraestructura en Soporte y Administración
Hasta ahora muchos de los problemas de administración y soporte que

demanda un sistema distribuido no han sido solucionados, y las soluciones que
existen para algunos otros problemas son limitadas. Algunos ejemplos de estos
problemas son la planeación de sistemas de información de acuerdo a la
cambiante tecnología que hay hoy en día, el manejo de recursos distribuidos y el
diseño de la estructura organizacional para la computación distribuida.
1.3.4 Seguridad e Integridad
La distribución de datos y de programas en múltiples localidades pueden crear

muchos problemas de seguridad e integridad que no con fáciles de solucionar y que
por lo general requieren también de un proceso paralelo que ayude a
solucionar dichos problemas, por lo que la carga del sistema aumenta y el
rendimiento en general puede verse afectado.

1.3.5 Opciones
La disponibilidad de muchas opciones y decisiones puede ser tanto buena, como

mala. En ocasiones tener muchas opciones nos quita tiempo, puesto que
tenemos que analizar, entender y probar todas las que están disponibles antes
de llegar a tomar una decisión cobre cual es la mejor. Por el lado contrario, el
tener muchas opciones nos permite diseñar un sistema que este conformado por
los elementos que mejor satisfagan las necesidades de los usuarios.
1.4. Evolución
1.4.1 Etapas de la evolución de los sistemas distribuidos
La computación distribuida ha evolucionado en los últimos veinte años y

continuará evolucionando por muchos años más. Durante esta evolución, hemos
acumulado muchos términos tal como procesamiento distribuido, procesamiento
distribuido cooperativo, procesamiento distribuido de datos, computación cliente-
servidor, computación en red y computación en súper-red. Brevemente veremos
la evolución y trataremos de poner en perspectiva algunos de éstos términos.
Durante los 70’s, la computación distribuida estaba caracterizada por

mainframes y mini computadoras interconectadas a través de redes de área
amplia (WANs). Éstas redes eran lentas, en el rango de 2400 a 9600 bits por
segundo (bps) y las computadoras intercambiaban información a través de
emulación de terminales y transferencia de archivos. Regularmente, las mini
computadoras eran emuladas como terminales tal que los datos en la
mainframe pudieran ser accedidos a través de emulación de terminal. En
algunos casos, los archivos eran transferidos entre mainframes y mini
computadoras a través de paquetes de transferencia de archivos. Muchos
paquetes de transferencia de archivos y emulación de terminal fueron
desarrollados en este periodo. Aunque se realizó mucha investigación en bases
de datos distribuidas en este periodo, esta tecnología no fue utilizada ni
comercializada. Dos términos se volvieron populares en esta época: (1)
procesamiento distribuido que se refiere a procesos de aplicaciones en múltiples
computadoras y (2) procesamiento distribuido de datos que se refiere a datos
como a procesos en diferentes computadoras. Independientemente de los
términos utilizados, las tecnologías de intercambio de información fueron
transferencia de archivos y emulación de terminales.
Durante los 80’s sucedieron tres cambios fundamentales: proliferación de

computadoras de escritorio desktop computers), disponibilidad de redes de
área local (LANs) y el uso común de mayores velocidades de transferencia de
datos (4 a 16 millones de bits por segundo para LANs y 56 Kbps a 1.54 Mbps
para WANs). En esta época, los sistemas de computación distribuida consistían
de mainframes, mini computadoras y computadoras de escritorio,

interconectadas a través de LANs y WANs. Además de procesamiento

distribuido y procesamiento distribuido de datos, el término computación en red se
volvió popular para describir a las redes como un valor agregado a las
computadoras. Aunque alguna paquetería de bases de datos distribuidas y
cliente -servidor salieron al mercado, lo más utilizado seguía siendo transferencia de
archivos y emulación de terminal.
Durante los 90’s se llevaron a cabo muchos cambios fundamentales, se

desarrolló software de bases de datos distribuidas y cliente-servidor, para llevar
a cabo la transferencia de datos de manera transparente entre procesos
remotos, proliferación de poderosas y baratas computadoras de escritorio y
computadoras portátiles, énfasis en estándares y disponibilidad de redes de
transferencia de datos sumamente rápidas (100 Mbps y más para LANs, WANs
y redes de área metropolitana MANs). Los sistemas de computación distribuida
de esta época consistían en muchas computadoras de diferentes capacidades y
de diferentes fabricantes conectadas a través de áreas geográficas grandes
sobre redes de alta transferencia de datos de difere ntes proveedores. Además
de los términos utilizados anteriormente, el término procesamiento cooperativo
distribuido entra en boga porque señala la característica principal de éstos
sistemas que permiten el intercambio de información interactivamente entre los
procesos de diferentes computadoras. La computación Cliente -Servidor (C-S) es
la forma más popular de procesamiento cooperativo distribuido. Permite que las
aplicaciones del cliente (procesadores de consultas a bases de datos, interfaces
de usuario, etc.) tengan acceso a servidores (servidores de bases de datos,
servidores de archivos, servidores de impresoras, etc.) transparentemente a
través de una red. La computación C-S representa un gran avance con respecto
a los sistemas distribuidos basados en la emulación de terminal y transferencia
de archivos.
En la actualidad, los Sistemas de Computación Distribuida hacen que toda la red

computacional parezca como una sola gran computadora donde diferentes
actividades se llevarán a cabo en diferentes computadoras. Estos sistemas
también incluyen supercomputadoras conectadas a través de redes Gigabit por
segundo, y supervisados por software de administración (Sistemas Operativos
Distribuidos). Dichos sistemas, llamados súper computación en red, son
ampliamente utilizados debido a su gran potencial.
Por otro lado, el desarrollo en computación neuronal es de gran interés porque

intenta simular los procesos de pensamiento del cerebro humano. Básicamente,
el cerebro humano consta de millones de millones de neuronas, donde cada
neurona se comporta como un CPU. Sin embargo, las neuronas son lentas
(cada neurona opera a 100 Hertz, inferior a 40 millones de Hertz, velocidad de
algunos procesadores actuales). Pero las neuronas están interconectadas entre
sí a través de nervios (cada neurona puede tener cuando menos 1000
interacciones con otras neuronas). Por lo tanto, el cerebro humano se puede
visualizar como una red (Red Neuronal) en la que millones de millones de

neuronas están interconectadas de muchas maneras. Sin embargo, una neurona

aislada es lenta. Computadoras muy rápidas conectadas a través de redes
sumamente rápidas crean grandes oportunidades para el desarrollo de nuevas
aplicaciones en inteligencia artificial, medicina, ingeniería, finanzas, etcétera.
1.4.2 Impacto de la orientación a objetos y componentes
Para entender el proceso que llevó al nacimiento del concepto que hoy se
conoce como orientación a objetos habría que volver unas cuantas décadas
atrás, hasta la época en la que reinaban FORTRAN y BASIC.
La programación de ese tiempo o de ese entonces estaba dedicada a procesos

lineales (época de la programación lineal), en los cuales las tareas se
ejecutaban una a una en una secuencia preestablecida. Pero ese enfoque
funcionó sin problemas durante los primeros años, hasta que los requerimientos
comenzaron a crecer en tamaño y complejidad, por lo tanto cada vez se volvía
más difícil agregar adaptaciones y ampliaciones a los programas ya existentes.
La programación estructurada atacó este problema descomponiendo los

procesos complejos en otros más sencillos (es una actividad conocida como
descomposición modular), y así permitió la reutilización de las partes comunes a
toda una aplicación a través de procedimientos y funciones. Para completar la
descomposición modular se usaba la metodología “hacia abajo” (topdown),
yendo de lo general a lo particular. Se buscaba, primero, entender cuál era la
función principal que se necesitaba representar y se la iba subdividiendo en
tareas menos complejas. Se intentaba que cada módulo fuera lo más
independiente posible del resto para, a futuro, poder restringir el impacto de los
cambios en áreas específicas de la aplicación.
Hasta el momento se dominaba la complejidad. Pero no fue así. La rueda siguió

girando y, aunque resulte sorprendente la fecha, a mediados de los '60 apareció
una nueva forma de ver las cosas en el mundo de la programación. La
orientación a objetos propulsó el encapsulamiento de comportamientos y datos
en un solo conjunto, apartándose del esquema tradicional, en el cual se
consideraba de manera aislada la información que se quería manipular de la
lógica para conseguirla. Las ventajas que prometía esa nueva perspectiva eran
facilitar la colaboración entre desarrolladores, ayudar a administrar la
complejidad y brindar la flexibilidad necesaria para lidiar con requerimientos que
cambian todo el tiempo. Lentamente, este paradigma fue creciendo y
difundiéndose cada vez más. Hoy en día, de ninguna manera podemos ignorarlo
como programadores. No creo que alguien considere la creación de un nuevo
lenguaje sin incorporar orientación a objetos en su estructura. Así, los lenguajes
estructurados (o basados en procedimientos) siguen siendo el primer contacto
formal con la programación.

La idea fundamental detrás de cua lquier lenguaje de programación orientado a

objetos es combinar en un mismo elemento información y funciones que puedan
actuar sobre ella; comportamiento y propiedades fusionados en una sola
entidad. La información contenida en un objeto está representada por sus
atributos. Cuando se define un atributo o un método como privado, solamente el
objeto en cuestión puede accederlo; lo contrario ocurre con aquellos atributos o
métodos definidos como públicos, que pueden ser accedidos por cualquier otro
objeto. El conjunto de atributos y métodos públicos que permiten a un objeto
interactuar con otros se conoce como la interfaz del objeto o de la clase que lo
define. El hecho de que la implementación del comportamiento de los objetos
esté aislada del entorno nos permite hacer todos los cambios que queramos en
ella mientras conservemos intacta la interfaz del objeto, su cara hacia el exterior.
Encontraremos además, que la única manera de acceder a la información

contenida en un objeto es a través de sus métodos. A pesar de que es posible
definir atributos públicos, esto no se considera un buen diseño orientado a
objetos, ya que altera el encapsulamiento y hace una especie de "agujero en esa
coraza protectora".
Cuando conservamos el encapsulamiento, los objetos pueden manipular la

información de otros sólo si existen métodos públicos para ese fin (getters y
setters). Así, la información se mantiene protegida de alteraciones accidentales
o no deseadas.
Esto tiene una importancia tremenda. Imaginemos que por error hubiéramos
implementado el atributo diámetro como público. Cualquier otro objeto podría
modificar destrozando la abstracción del mundo real que tratamos de
representar. Diseñar un sistema orientado a objetos también tiene sus riesgos.
Las Clases:
En casi todos los lenguajes orientados a objetos usamos el concepto de clase para
definir y crear las aplicaciones. Una clase es, a la vez, una especificación (como el
plano de una casa) y una plantilla o molde para la creación de objetos. Es la
definición conceptual de un objeto y, como tal, describe todas las
características de un tipo particular de objetos, sus atributos, métodos y los
correspondientes privilegios de acceso.
Cuando escribimos un programa, definimos clases, una por cada tipo de objeto,
para que puedan utilizarse en la creación o en la instanciación de nuevos
objetos en memoria durante la ejecución de la aplicación. "Instanciar" objetos a
partir de una clase hace que esos objetos se denominen instancias de la clase.
Usamos el mismo "molde" para crear todas las instancias de un mismo tipo en
nuestro sistema, y podemos pensar en las clases como tipos en nuestro

sistema, y podemos pensar en las clases como tipos de datos, al igual que int o char,
pero con una responsabilidad específica en el sistema.
Así, una clase Válvula define el comportamiento de todas las instancias (de
todas las válvulas) que tengamos en nuestro sistema. A pesar de representar
entidades distintas (cada una con su propio estado), todas se comportarán
exactamente igual o del mismo modo. Si durante nuestro proceso de diseño
descubrimos nuevos tipos de objetos, directamente modificaremos el punto del
programa en donde se define la clase que los genera.
Ahora, ¿qué ocurre cuando queremos incorporar un nuevo conjunto de objetos que
resulta muy similar a algunos de los ya existentes? (Herencia) Podemos manejar
esta situación dentro de la orientación a objetos creando una nueva clase derivada
de la existente, que retiene o "hereda" los métodos y atributos de su clase padre, y
que permite sumar nuevos elementos. Las clases que heredan se denominan
subclases de la clase padre o superclase, y el proceso de agregarlas es el de
subclasificar (subclassing).
Por ejemplo (retomando el ejemplo del sistema para la industria del petróleo, la
válvula), supongamos que una vez que tenemos nuestro sistema funcionando,
los ingenieros deciden incorporar otro tipo de válvula, una que proporcione un
mayor grado de apertura (o en todo caso que es más sofisticada que las
demás), junto con un nuevo método para abrir la válvula en la posición deseada
y otros métodos privados que permiten conectarla a sensores de posición para
saber cuál es su estado.
A través de la herencia, los cambios que hagamos a nuestro modelo se

propagarán de padres a hijos y así atravesarán todos los niveles que definamos.
Podemos construir jerarquías de clases para transmitir estos cambios
automáticamente.
Polimorfismo:
Significa, literalmente, muchas formas. Es una característica de la orientación a

objetos que permite que objetos similares puedan reaccionar al mismo mensaje de
diferentes maneras. Si consideramos una interfaz de usuario, en el evento de carga
podríamos incluir la inicialización de todos los controles (objetos) que contiene.
Lo hacemos enviando a todos el mismo mensaje, Reset, pero cada uno de ellos lo
implementará a su manera.
El polimorfismo juega un papel fundamental, al dejar que objetos que poseen

estructuras internas totalmente diferentes puedan compartir una misma interfaz
externa. Esto quiere decir que una clase general de operaciones puede ser
accedida del mismo modo a pesar de que las implementaciones específicas
asociadas con esa operación difieren de un objeto a otro.

La forma más común de implementar este tipo de polimorfismo es a través de

una clase con un método abstracto (solamente su definición, no tiene
implementación) que es heredado a varias subclases. Cada una de ellas
redefine este método de acuerdo con sus necesidades y hace lo que se conoce
como overriding.
Uno de los problemas que pueden surgir en este caso es que la redefinición del
método en las subclases sea totalmente inconsistente con las intenciones
originales de ese método en la superclase.
También podemos tener polimorfismo por overriding de un método. Para eso

definimos conjuntos diferentes de argumentos bajo el nombre de un único
método. La acción específica a seguir en cada caso estará determinada por la
naturaleza de los parámetros que reciba ese método.
Una buena jerarquía de clases será la base la reutilización del código en el que
hayamos invertido tiempo y esfuerzo para desarrollar y probar. Con el
encapsulamiento podremos modificar las implementaciones de los métodos sin
alterar el código existente que depende de la interfaz de nuestras clases.
Integrando en un todo las dos anteriores, el polimorfismo nos permitirá crear el
código para que se pueda mantener, sencillo de interpretar y flexible.
La OOP (Programación Orientada a Objetos) no es sólo clases:
Si vamos a ser estrictos, las clases no son una parte esencial de la OOP (sigla en
inglés). Pero dada la influencia de C++ y Java, la mayoría de las personas piensa
que usar clases es la única manera de escribir un programa con orientación a
objetos. En realidad existen dos formas de abordar a la orientación a objetos en un
lenguaje: mediante clases (como en todos los lenguajes comerciales, tales como
C++, C#, Java y otros) y a través de prototipos (como en Self, Kevo, Omega, todos
lenguajes de uso académico).
En los primeros, las clases se utilizan como "fábricas" de objetos. En los últimos no se
necesita la noción de clase; los objetos pueden crearse de la nada en forma
visual o por herencia (a partir de otro objeto), y el código resultante es mucho más
claro.
1.4.3 Internet y nueva tecnología en la red
Internet surge como consecuencia del establecimiento de estándares de

sistemas abiertos. Estos esquemas permitieron la creación una red de redes. De
hecho, Internet proviene del inglés inter-networking.
Particularmente el protocolo TCP/IP fue uno de los estándares que favoreció la

conexión a través de Internet y las aplicaciones que podían trabajar sobre este
protocolo.

Conceptualmente, generalmente se confunde la programación para Internet y la

programación Web; éste último es un subconjunto del primero. La programación
Web utiliza el protocolo HTTP (Hyper Text Transfer Protocol).
Tradicionalmente la utilización de aplicaciones Web se efectúa por seres

humanos. Sin embargo, nuevos protocolos como SOAP basado en XML
abrieron el horizonte a programas cliente que solicitan servicios a otras
aplicaciones Web a través de servicios.
Tarea Individual
Entregar la síntesis del tema de introducción en documento Word, con el nombre
INTRODUCCION.DOC
Tarea en Equipo
Entregar la síntesis en equipo sobre las características de sistemas distribuidos,
como CARACTERISTICAS.DOC.

2. Arquitectura Cliente Servidor
2.1. Fundamentos de Arquitectura Cliente Servidor
Actividad 2.1
Actividad 2.1 Fundamentos de Arquitectura Cliente Servidor
Contestar las preguntas que a continuación se plantean:
1. ¿Qué entiende por Arquitectura Cliente Servidor?
2. ¿Cuáles son los elementos de una Arquitectura Cliente Servidor?
3. ¿Qué características muestra el modelo Cliente Servidor?
4. ¿Cuáles son las ventajas y desventajas del modelo Cliente Servidor?
5. ¿Qué servicios ofrece el modelo Cliente Servidor?
Se proporciona Material de Apoyo 2.1, pero además es conveniente que

consulte otra fuente de información para resolver las preguntas.
Colocar el cuestionario resuelto en Tare a Individual 2.1 Nota
Importante:
Hasta aquí se han desarrollado las actividades como comprobaciones de

lectura, debido al esquema teórico y de fundamentos requeridos en el inicio del
curso, más adelante esto nos servirá como base en aplicaciones prácticas.
Material de Apoyo 2.1

2.1.1 Definiciones Básicas
Para entender el concepto de la arquitectura de cliente servidor, antes es

necesario conocer algunas definiciones. Entre las principales definiciones se
tiene:
1. Desde un punto de vista conceptual:
«Es un modelo para construir sistemas de información, que se sustenta en la

idea de repartir el tratamiento de la información y los datos por todo el sistema
informático, permitiendo mejorar el rendimiento del sistema global de
información»

2. En términos de arquitectura:
Los distintos aspectos que caracterizan a una aplicación (proceso,

almacenamiento, control y operaciones de entrada y salida de datos) en el
sentido más amplio, están situados en más de un computador, los cuales se
encuentran interconectados mediante una red de comunicaciones.
3. IBM define al modelo Cliente/Servidor
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 otros computadores llamados servidores.
Para entender mejor las definiciones antes mencionadas, analizaremos ahora

algunos de los conceptos mencionados en dichas definiciones:
Un Cliente 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.
Un Servidor 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 proveer de múltiples servicios a
los clientes tales como impresión, acceso a bases de datos, fax, procesamiento
de imágenes, etc. Es importante mencionar que un servidor no es
necesariamente un dispositivo físico (una computadora) sino que hay que
entender al servidor como un proceso que se encarga de atender las peticiones de un
cliente.
Con estos elementos podemos ya darnos una idea de lo que es el modelo cliente
servidor, sin embargo, es necesario analizar más a fondo las características
de la arquitectura si queremos llegar a entender por completo el funcionamiento de la
misma.
2.1.2. Elementos de la Arquitectura Cliente/Servidor
Una arquitectura es un entramado de componentes funcionales que

aprovechando diferentes estándares, convenciones, reglas y procesos, permite
integrar una amplia gama de productos y servicios informáticos, de manera que
pueden ser utilizados eficazmente dentro de la organización.

Debemos señalar que para seleccionar el modelo de una arquitectura, hay que partir
del contexto tecnológico y organizativo del momento y, que la arquitectura
Cliente/Servidor requiere una determinada especialización de cada uno de los
diferente s componentes que la integran.
En esta aproximación, y con el objetivo de definir y delimitar el modelo de

referencia de una arquitectura Cliente/Servidor, debemos identificar los
componentes que permitan articular dicha arquitectura, considerando que toda
aplicación de un sistema de información está caracterizada por tres
componentes básicos:
• Presentación/Captación de Información
• Procesos
• Almacenamiento de la Información
Y se integran en una arquitectura Cliente/Servidor en base a los elementos que

caracterizan dicha arquitectura, es decir:
• Puestos de Trabajo
• Comunicaciones
• Servidores
De estos elementos debemos destacar:
• El Puesto de Trabajo o Cliente “Una Estación de trabajo o microcomputador

(PC: Computador Personal) conectado a una red, que le permite acceder y
gestionar una serie de recursos”, el cual se perfila como un puesto de trabajo
universal. Nos referimos a un microcomputador conectado al sistema de
información y en el que se realiza una parte mayoritaria de los procesos.
Se trata de un fenómeno en el sector informático. Aquellos responsables

informáticos que se oponen a la utilización de los terminales no programables,
acaban siendo marginados por la presión de los usuarios. Debemos destacar
que el puesto de trabajo basado en un microcomputador conectado a una red,
favorece la flexibilidad y el dinamismo en las organizaciones. Entre otras
razones, porque permite modificar la ubicación de los puestos de trabajo, dadas
las ventajas de la red.
• Los Servidores o Back-End. «Una máquina que suministra una serie de

servicios como Bases de Datos, Archivos, Comunicaciones,...)». Los Servidores,
según la especialización y los requerimientos de los servicios que debe
suministrar pueden ser:
o Mainframes
o Minicomputadoras
o Especializados (dispositivos de red, imagen, etc.)

Una característica a considerar es que los diferentes servicios, según el caso,

pueden ser suministrados por un único Servidor o por varios Servidores
especializados.
Las Comunicaciones en sus dos vertientes:
• Infraestructura de redes
Componentes Hardware y Software que garantizan la conexión física y la

transferencia de datos entre los distintos equipos de la red.
• Infraestructura de comunicaciones
Componentes Hardware y Software que permiten la comunicación y su gestión, entre

los clientes y los servidores.
La arquitectura Cliente/Servidor es el resultado de la integración de dos culturas. Por

un lado, la del Mainframe que aporta capacidad de almacenamiento, integridad
y acceso a la información y, por el otro, la del computador que aporta facilidad de
uso (cultura de PC), bajo costo, presentación atractiva (aspecto lúdico) y una
amplia oferta en productos y aplicaciones.
2.1.3 Características del modelo Cliente/Servidor
En el modelo Cliente/Servidor podemos encontrar las siguientes características:
1. El Cliente y el Servidor pueden actuar como una sola entidad y también

pueden actuar como entidades separadas, realizando actividades o tareas
independientes.
2. Las funciones de Cliente y Servidor pueden estar en plataformas separadas, o en la
misma plataforma.
3. Un servidor proporciona servicio a múltiples clientes en forma concurrente.
4. 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.
5. La interrelación entre el hardware y el software están basados en una

infraestructura poderosa, de tal forma que el acceso a los recursos de la red no
muestra la complejidad de los diferentes tipos de formatos de datos y de los
protocolos. Un sistema de servidores realiza múltiples funciones al mismo
tiempo que presenta una imagen de un sólo sistema a las estaciones Clientes. Esto
se logra combinando los recursos de cómputo que se encuentran físicamente
separados en un sistema lógico, proporcionando de esta manera el servicio más
efectivo para el usuario final.

También es importante hacer notar que las funciones Cliente/Servidor pueden ser
dinámicas. Ejemplo, un servidor puede convertirse en cliente cuando realiza la
solicitud de servicios a otras plataformas dentro de la red. Tiene capacidad para
permitir integrar los equipos ya existentes en una organización, dentro de una
arquitectura informática descentralizada y heterogénea.
6. Además se constituye como el nexo de unión más adecuado para reconciliar

los sistemas de información basados en mainframes o minicomputadoras, con
aquellos otros sustentados en entornos informáticos pequeños y estaciones de
trabajo.
7. Designa un modelo de construcción de sistemas informáticos de carácter
distribuido.
8. Su representación típica es un centro de trabajo (PC), en donde el usuario
dispone de sus propias aplicaciones de oficina y sus propias bases de datos, sin
dependencia directa del sistema central de información de la organización, al
tiempo que puede acceder a los recursos de este host central y otros sistemas de la
organización ponen a su servicio.
En consecuencia, parte del control de las aplicaciones se transfieren del

computador central (servidor) a los PCs o estaciones de trabajo (clientes),
adquiriendo estas plataformas, entonces, un papel protagonista en conjunto del
sistema de información.
En conclusión, Cliente/Servidor puede incluir múltiples plataformas, bases de

datos, redes y sistemas operativos. Estos pueden ser de distintos proveedores,
en arquitecturas propietarias y no propietarias y funcionando todos al mismo
tiempo. Por lo tanto, su implantación involucra diferentes tipos de estándares:
APPC, TCP/IP, OSI, NFS, DRDA corriendo sobre DOS, OS/2, Windows o PC
UNIX, en Token-Ring, Ethernet, FDDI o medio coaxial, sólo por mencionar
algunas de las posibilidades. Dependiendo de estas características y de su
combinación, es el grado de complejidad de una solución C/S.
2.1.4 Ventajas y Desventajas del modelo Cliente/Servidor
El esquema Cliente/Servidor posee las siguientes ventajas:
a) Uno de los aspectos que más ha promovido el uso de sistemas

Cliente/S ervidor, 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.

b) 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 con 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.
c) Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos bajo

este esquema tienen mayor interacción más intuitiva con el usuario. 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.
d) 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).
e) 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.
f) 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 re levante a nivel global.
El esquema Cliente/Servidor tiene algunos inconvenientes que se mencionan a

continuación:
a) Tiene escasas herramientas para la administración y ajuste del desempeño de

los sistemas.
b) En el desarrollo de aplicaciones Cliente/Servidor se deben considerar los

aspectos, que se mencionan a continuación:
 Los clientes y los servidores deberán utilizar 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 pare el manejo de errores y para
mantener la consistencia de los datos. La seguridad de un esquema
Cliente/Servidor es muy importante. Por ejemplo, se deben hacer
verificaciones en el cliente y en el servidor. También se puede recurrir
a otras técnicas como el encripción.
 El desempeño. Problemas de este estilo pueden presentarse por
congestión en la red, dificultad de tráfico de datos, etc.

 Un aspecto directamente relacionado con lo anterior es el de cómo

distribuir los datos en la red. En el caso de una organización, por
ejemplo, éste puede ser hecho por departamentos, geográficamente, o
de otras maneras. Hay que tener en cuenta que en algunos casos, por
razones de confiabilidad o eficiencia, se pueden tener datos
replicados, y que puede haber actualizaciones simultáneas.
 A otro nivel, una de las decisiones que deben tomar las
organizaciones es la de si comprar o desarrollar los diferentes
componentes.
2.1.5 Servicios basados en Cliente/Servidor
IBM ha orientado sus esfuerzos de desarrollo de productos ha satisfacer los

siguientes servicios:
a) Servicios de Datos e Impresión:

Servicios que permiten compartir archivos, bases de datos, impresoras y
graficadores (plotters). Administración de las colas de impresión en diferentes
dispositivos.
b) Servicios de Comunicaciones:
Aseguran que cada componente físico de la red sea capaz de comunicarse
exitosamente con otros componentes, tales como LAN a LAN y LAN a WAN. El
sistema puede incluir dispositivos de comunicaciones que manejen diferentes tipos
de protocolos para conectar sistemas heterogéneos.
c) Servicio de Administración:
Administración de Sistemas involucra administración de cambios, de problemas,
operaciones, configuración y rendimiento.
Administración de Cambios: es definida como las actividades involucradas en la

planeación, programación, distribución, instalación y registro de hardware y
software en una red distribuida.
Administración de Problemas: involucra la determinación de los mismos, la

identificación de su origen en una red y su solución.
Administración de Operaciones: es definida como la administración del uso de los

sistemas y de los recursos para soportar la carga de trabajo de la
organización, la cual incluye operaciones automatizadas y remotas.
Administración de Configuración: es el manejo de las relaciones lógicas y físicas entre

los recursos de la red.

Administración del Rendimiento: es un conjunto de actividades tales como la

recopilación de datos de desempeño, afinamiento, distribución de carga de
trabajo y el planeamiento de la capacidad para las redes distribuidas.
Administración de Sistemas: también incluye servicios de respaldo, recuperación

de datos, seguridad de recursos de cómputo y distribución y mantenimiento de
software.
d) Servicios de Aplicación:
Si el recurso compartido es una parte de una aplicación (una función de la
aplicación), estamos hablando de servicios de aplicación. Cada uno de los
procesadores participantes en un ambiente Cliente/Servidor puede mantener
parte del código de la aplicación, el cual debe ser compartido por todos ellos
(interoperabilidad). Esto significa que las partes de una aplicación pueden ser
distribuidas en varios procesadores, locales o remotos.
El diseño de las funciones de la aplicación no debe estar ligado a un

computador, lo que permite transportar la aplicación de un procesador a otro, sin
modificaciones (portabilidad).
Una ventaja derivada de esto, es que la aplicación puede estar óptimamente

ubicada dentro de una red en base a las necesidades: de recursos de cómputo y de la
organización.
Tarea Individual 2.1
Entregar el cuestionario de Fundamentos de Arquitectura C/S en documento

Word, con el nombre FUNDAMENTOSCS.DOC
2.2. Comunicación entre Procesos
Objetivos 2.2
Objetivos Comunicación entre Procesos
Con la finalidad de enfatizar los conceptos más representativos del entorno de

comunicación entre procesos se realizarán dos ejercicios prácticos sobre el
manejo de sockets y RPC.
El protocolo TCP/IP y conjuntos de UDP son dominantes, incluso para los

sistemas distribuidos que son implementados sobre redes de área local. Los
sockets son mecanismos en estos protocolos que permiten que un cliente y
servidor puedan comunicarse escribiendo a o leyendo de sus sockets.
La mayoría de los servicios Web y las aplicaciones de acceso remoto actuales

utilizan un enfoque de llamadas a procedimientos remotos (RPC, Remote

Procedure Call). Se crea lo que parece ser una llamada de función y se pone en
marcha un sistema de fondo que hace que tenga lugar en el servidor. El sistema
controla el intercambio de mensajes entre cliente y servidor.
Actividades 2.2
Actividades Comunicación entre Procesos
Realizar el Ejercicio Sockets TCP anexo. Colocar informe de ejercicio en Tarea

Individual 2.2.1
Realizar el Ejercicio RPC anexo. Colocar informe de ejercicio en Tarea Individual

2.2.2
Nota Importante: Antes de iniciar el ejercicio de RPC debe concluir el ejercicio de

Sockets TCP.
Sugerencia: Antes de realizar los ejercicios se recomienda que revise el Material
de Apoyo 2.2 para reafirmar sus conocimientos sobre comunicación entre
procesos.
EJERCICIO SOCKETS TCP
En aplicaciones Cliente Servidor, el servidor proporciona algún servicio, como

procesamiento de consultas en base de datos o envío de precios actualizados
de existencias. El cliente utiliza el servicio proporcionado por el servidor, ya sea
el despliegue de resultados de la consulta de base de datos al usuario o hacer
recomendaciones de compra de existencias a un consumidor. La comunicación
que ocurre entre el cliente y el servidor debe ser confiable. Es decir, ningún dato
puede dejarse caer y debe llegar en el lado del cliente en el mismo orden en el
que el servidor lo envió.
En el primer caso ambos programas deben conectarse entre ellos con un socket
y hasta que no esté establecida correctamente la conexión, ninguno de los dos
puede transmitir datos. Esta es la parte TCP del protocolo TCP/IP, y garantiza
que todos los datos van a llegar de un programa al otro correctamente. Se utiliza
cuando la información a transmitir es importante, no se puede perder ningún
dato y no importa que los programas se queden "bloqueados" esperando o
transmitiendo datos. Si uno de los programas está atareado en otra cosa y no
atiende la comunicación, el otro quedará bloqueado hasta que el primero lea o
escriba los datos.
En el segundo caso, no es necesario que los programas se conecten.

Cualquiera de ellos puede transmitir datos en cualquier momento,
independientemente de que el otro programa esté "escuchando" o no. Es el

llamado protocolo UDP, y garantiza que los datos que lleguen son correctos, pero
no garantiza que lleguen todos. Se utiliza cuando es muy importante que el programa
no se quede bloqueado y no importa que se pierdan datos.
En este ejercicio práctico trataremos como da soporte Java a Socket TCP.
ESCENARIO
En este ejercicio veremos las clases de Java que nos permite trabajan de forma
sencilla con sockets TCP.
La interfaz Java que da soporte a sockets TCP está constituida por las clases
ServerSocket y Socket.
1. ServerSocket: es utilizada por un servidor para crear un socket en el puerto

en el que escucha las peticiones de conexión de los clientes. Su método accept
toma una petición de conexión de la cola, o si la cola está vacía, se bloquea
hasta que lle ga una petición. El resultado de ejecutar accept es una instancia de
Socket, a través del cual el servidor tiene acceso a los datos enviados por el
cliente.
2. Socket: es utilizada tanto por el cliente como por el servidor. El cliente crea
un socket especificando el nombre DNS del host y el puerto del servidor, así se
crea el socket local y además se conecta con el servicio. Esta clase proporciona
los métodos getInputStream y getOutputStream para acceder a los dos streams
asociados a un socket (son bidireccionales), y devuelve tipos de datos
InputStream y OutputStream, respectivamente, a partir de los cuales podemos
construir BufferedReader y PrintWriter, respectivamente, para poder procesar los
datos de forma más sencilla.
La forma general de implementar un cliente será:
1. Crear un objeto de la clase Socket, indicando host y puerto donde corre el

servicio.
2. Obtener las referencias al stream de entrada y al de salida al socket.
3. Leer desde y escribir en el stream de acuerdo al protocolo del servicio.

Para ello emplear alguna de las facilidades del paquete java.io.
4. Cerrar los streams.
5. Cerrar el socket.
La forma de implementar un servidor será:

1. Crear un objeto de la clase ServerSocket para escuchar peticiones en el

puerto asignado al servicio.
2. Esperar solicitudes de clientes
3. Cuando se produce una solicitud:
 Aceptar la conexión obteniendo un objeto de la clase Socket

 Obtener las referencias al stream de entrada y al de salida al socket
anterior.
 Leer datos del socket, procesarlos y enviar respuestas al cliente,
escribiendo en el stream del socket. Para ello emplear alguna de las
facilidades del paquete java.io.
4. Cerrar los streams.
5. Cerrar los sockets.
Vamos a ver todo esto con un sencillo ejemplo: una aplicación cliente/servidor
de eco, es decir, el servidor repite lo mismo que le envía el cliente, hasta que el
cliente quiere finalizar el servicio, para lo cual envía la palabra "Bye" al servidor.
CÓDIGO DEL CLIENTE
Analizar el siguiente código del cliente EcoCliente.java:
import java.net.*;
import java.io.*;
public class EcoCliente {
public static void main(String[] args) throws IOException {

Socket socketCliente = null;
BufferedReader entrada = null;
PrintWriter salida = null;
// Creamos un socket en el lado cliente, enlazado con un //

servidor que está en la misma máquina que el cliente // y que
escucha en el puerto 4444
try {
socketCliente = new Socket("localhost", 4444);
// Obtenemos el canal de entrada

entrada = new BufferedReader(new
InputStreamReader(socketCliente.getInputStream()));

// Obtenemos el canal de salida

salida = new PrintWriter(new BufferedWriter(new
OutputStreamWriter(socketCliente.getOutputStream())),true); }
catch (IOException e) {
System.err.println("No puede establer canales de E/S para la conexión");

System.exit(-1);
}
BufferedReader stdIn =
new BufferedReader(new InputStreamReader(System.in));
String linea;
// El programa cliente no analiza los mensajes enviados por el //

usario, simplemente los reenvía al servidor hasta que este // se
despide con "Bye"
try {
while (true) {
// Leo la entrada del usuario
linea = stdIn.readLine(); //
La envia al servidor
salida.println(linea);
// Envía a la salida estándar la respuesta del servidor
linea = entrada.readLine();
System.out.println("Respuesta servidor: " + linea); // Si
es "Bye" es que finaliza la comunicación
if (linea.equals("Bye")) break;
}
} catch (IOException e) {
System.out.println("IOException: " + e.getMessage());

}
// Libera recursos
salida.close();
entrada.close();
stdIn.close();
socketCliente.close();
}
CÓDIGO DEL SERVIDOR

Analizar el siguiente código del servidor EcoServidor.java:
import java.io.*;
import java.net.*;
public class EcoServidor {
public static final int PORT = 4444;

public static void main(String[] args) throws IOException {
// Establece el puerto en el que escucha peticiones

ServerSocket socketServidor = null;
try {
socketServidor = new ServerSocket(PORT); }
catch (IOException e) {
System.out.println("No puede escuchar en el puerto: " + PORT);

System.exit(-1);
}
Socket socketCliente = null;

BufferedReader entrada = null;
PrintWriter salida = null;
System.out.println("Escuchando: " + socketServidor);
try {
// Se bloquea hasta que recibe alguna petición de un cliente //

abriendo un socket para el cliente
socketCliente = socketServidor.accept();
System.out.println("Connexión acceptada: "+ socketCliente);
// Establece canal de entrada

entrada = new BufferedReader(new
InputStreamReader(socketCliente.getInputStream()));
// Establece canal de salida

salida = new PrintWriter(new BufferedWriter(new
OutputStreamWriter(socketCliente.getOutputStream())),true);
// Hace eco de lo que le proporciona el cliente, hasta que recibe "Bye"

while (true) {
String str = entrada.readLine();
System.out.println("Cliente: " + str);
salida.println(str);
if (str.equals("Bye")) break;
}

} catch (IOException e) {
System.out.println("IOException: " + e.getMessage());
}
salida.close();
entrada.close();
socketCliente.close();
socketServidor.close();
}
Ejercicio RPC
Los RPC o Llamados a Procedimientos Remotos (“Remote Procedure Call”) son

mecanismos que permiten crear una comunicación entre procesos
(clienteservidor), al igual que los Sockets, pero la diferencia con estos es que
mientras que los Sockets permiten enviar y transmitir caracteres, los RPC utilizan a
los Sockets para crear una comunicación de más alto nivel.
Los RPC permiten llamar a una función que está en otro programa y
generalmente en otra máquina, para lo cual el paso de parámetros a la función
remota se efectúa a través de algún protocolo de representación de datos (XDR,
eXternal Data Representation).
Mientras que a nivel de la capa de transporte el concepto de puerto existe para poder
enviar información entre procesos, los RPC definen un concepto llamado número de
programa. Este, junto con el uso de la versión del programa permite que los
servidores y clientes puedan comunicarse.
Programación con RPCs
Dentro de las funciones para programar con RPC existen tres niveles:
 Nivel alto: En la práctica se usa sólo para aplicaciones muy específicas

con poca utilidad.
 Nivel Bajo: Es en donde se pueden mezclar programación con RPCs y
Sockets.
 Nivel Medio: Permite disponer de la mayor parte de las ventajas de RPCs
sin tener que entrar en el detalle de su implementación bajo Sockets. En
este nivel representaremos nuestro ejercicio práctico.
En este ejercicio práctico trataremos el uso de RPC de Sun.
ESCENARIO

En este ejercicio veremos como se implementa un servidor y un cliente para

obtener la hora de una máquina, con RPCs.
Analizar los programas.
PROGRAMA SERVIDOR
El programa servidor (listado 1) llama a la función “registerrpc”, sus primeros tres

parámetros son: el número de programa a registrar, el número de versión de
programa y el número de procedimiento a registrar.
Listado 1:
/*
Ejemplo del uso de los RPC de Sun
Este programa permite obtener la hora de una máquina
rpc_server _hora
*/
#include <rpc/rpc.h>
#include <time.h>
#include "def_rpc.h"
{ /* programa servidor de hora con rpcs */
void *servidor_hora();
/* registramos el programa, versión y procedimiento */
registerrpc(HORA_PROG, HORA_VERS, PIDEHORA_NUM,

servidor_hora, xdr_void, xdr_hora);
svc_run(); /* nunca regresa */
perror("regreso de svc_run");
exit(1);
}
void *servidor_hora() {
/* servidor de hora */
struct tiempo str_tiempo, *ap_str_tiempo = &str_tiempo;
time_t t;
printf ("RECIBI RPC\n"); t =
time(NULL);
ap_str_tiempo->segundos = t;
ap_str_tiempo->s_tiempo = localtime(&t);
ap_str_tiempo->cad_hora = ctime(&t);
return (void *) ap_str_tiempo;
}

El cuarto parámetro es el nombre de una función de "C" (esto es, la dirección de la

fun-ción), de tal forma que cuando el cliente llame a este programa, versión y número
de procedi-miento, el mecanismo de RPCs llamará a la función
"servidor_hora" con un parámetro de llamada de tipo "xdr_void" (en este caso
ningún parámetro), y con un valor de regreso de tipo xdrcadena_32.
Después, el programa servidor llama a la función "svc_run", la cual a su vez se

queda en un ciclo infinito en espera de RPCs; esta función al recibir la petición del
procedimien-to "PlDEHORA_NUM" llamará a la función "servidor_hora" la que
simplemente regresa la dirección de una cadena de caracteres.
PROGRAMA CLIENTE
El programa cliente (listado 2) toma los ar-gumentos con los que fue mandado a
ejecutar y entra en un ciclo llamando a la función "callRPC”, que se encarga de
ejecutar el llama-do a un RPC.
Listado 2
/*
Ejemplo del uso de los RPC de Sun
Este programa permite obtener la hora de una máquina
rpc_cliente_hora
*/
#include <stdio.h>
#define T_ESPERA 10 /* tiempo de espera en segundos */
main(narg,arg){
char **arg;/* programa cliente de hora con rpcs */
struct tiempo hora;
int espera = T_ESPERA;
enum clnt_stat stat;
if( narg < 2 ){
fprintf(stderr,"uso: %s máquina tiempo_de_espera\n",arg[0]);
exit(1);
}
if( narg == 3 )
espera = atoi(arg[2]);
printf ("VOY A MANDAR\n");
while( (stat = callrpc(arg[1], HORA_PROG, HORA_VERS,

PIDEHORA_NUM, xdr_void,NULL, xdr_hora, &hora)) ==0){

printf ("YA RECIBI\n");

/*printf("Hora de %s es %Id \n", arg[1] ,hora.segundos);*/
sleep(espera);
}
/* algun error */
clnt_perrno(stat) ;
exit(2);
}
La función "callRPC" recibe ocho parámetros. Estos son:
1) El nombre de la máquina hacia donde se envía el RPC.

2) El número de programa que se quiere llamar.
3) La versión del programa.
4) El número de procedimiento que se quiere llamar.
5) xdr del tipo de argumento de llamada.
6) La dirección del argumento de llamada
7) xdr del argumento de regreso.
8) La dirección del argumento de regreso.
La función "callrpc" trabaja bajo el proto-colo de UDP, para un manejo de

retransmisión.
Si después de cierto tiempo no llega una contestación "callRPC" simplemente

reintenta, después de cierto número de reintentos "callRPC" regresa un error de
'timeout', pero si la contestación llega y no hubo error "callRPC' regresa un 0.
En el archivo def_RPC.h (listado 3), están definidos los números de programa,

versión y procedimiento, además de la función xdr_cadena_32.
Listado 3
/*
Definiciones para rpcs del ejemplo de hora
Sirven tanto para el cliente como el servidor
*/
#define HORA_PROG 555555555 /* Número del programa */
#define HORA_VERS /* versión */
#define PIDEHORA_NUM /* procedimiento 1 pide hora */
bool_t xdr_hora();
bool_t xdr_cadena_32();
bool_t xdr_stiempo();
struct tiempo {
time_t segundos;

struct tm *s_tiempo;
char *cad_hora;
}
XDRs
El archivo xdrhora.c (listado 4) tiene la de-finición de la función xdr_cadena_32, que

per-mite manejar cadenas de hasta 32 caracteres con los RPCs.
Los xdrs constituyen simultáneamente un protocolo de presentación de datos y una

implementación del mismo. La biblio-teca de manejo de RPCs trae una gran canti-dad
de funciones de xdrs.
Listado 4
/*
Ejemplo del programa de hora con rpcs
xdrs
*/
#include <time.h>
XDR *xdrsp;
struct tiempo *ap_hora;
{ /* xdr para la estructura tiempo */

if(xdr_u_long(xdrsp,&ap_hora->segundos) &&
xdr_stiempo(xdrsp,ap_hora->s_tiempo) &&
xdr_cadena_32(xdrsp,ap_hora->cad _hora))
return (TRUE);
else
retum (FALSE);
}
bool_t xdr_cadena_32(xdrsp,cadena)
XDR *xdrsp;
char *cadena;
{ /* xdr para cadenas de 32 bytes */

return xdr_string(xdrsp,&cadena,32);
bool_t xdr_stiempo (xdrsp,ap_tiempo)
XDR *xdrsp;
struct tm *ap_tiempo;
{
if (xdr_int(xdrsp,&ap_tiempo->tm_sec) &&
xdr_int(xdrsp,&ap_tiempo->tm_min) &&
xdr_int(xdrsp,&ap_tiempo->tm_hour) &&

xdr_int(xdrsp,&ap_tiempo->tm_mday) &&
xdr_int(xdrsp,&ap_tiempo->tm_mon) &&
xdr_int(xdrsp,&ap_tiempo->tm_year) &&
xdr_int(xdrsp,&ap_tiempo->tm_wday) &&
xdr_int(xdrsp,&ap_tiempo->tm_yday) &&
xdr_int(xdrsp,&ap_tiempo->tm_isdst))
return (TRUE);
else
return (FALSE);
}
Los XDRs son funciones que realizan las operaciones de serializar y

deserializar. Seriali zar se llama el proceso de convertir datos que están en
representación interna de una máquina y se convierten al formato de
representación externa lo que permite intercambiar in-formación entre máquinas
con representaciones de datos distintas; deserializar es el proceso inverso.
2.2. Comunicación entre Procesos

2.2.1 Generalidades de IPC
El rendimiento de un sistema de computación distribuida depende en gran

medida de la comunicación rápida entre procesos. Esta última depende de dos
partes: las primitivas de comunicación entre procesos y el protocolo de
transporte sobre el cual trabajan esas primitivas.
La comunicación entre procesos en un ambiente distribuido no puede hacerse por

memoria compartida; la única posibilidad es intercambio de mensajes.
Diferentes conjuntos de primitivas pueden ser usados en la comunicación entre

procesos remotos. Los tres más comunes están basados e n:
 Paso de mensajes
 Llamado a procedimientos remotos
 Transacciones
El orden en la lista anterior indica que cada forma de comunicación puede ser
construida en base a la anterior. En otras palabras, a mayor número, mayor nivel de
abstracción.
Paso de mensajes

Un mensaje es una colección de datos de cierto tipo consistente en un

encabezado y un cuerpo de longitudes fijas o variables, la cual puede ser
manejada por un proceso y entregada a su destinatario.
La comunicación orientada a mensajes está íntimamente ligada al modelo

cliente -servidor. El proceso cliente envía un mensaje (petición) a un proceso
servidor y espera una respuesta o continúa ejecutándose.
Las primitivas de comunicación por paso de mensajes son send y receive. En

algunos sistemas, la primitiva receive puede ser selectiva o condicional si se
agrega un guardia al llamar a la primitiva.
Existen diversas formas o interpretaciones semánticas de las primitivas:

1. Direccionamiento
Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la
dirección de éste.
Existen varios métodos por los que un cliente puede conocer o determinar la
dirección del servidor, a continuación se mencionan tres de ellas:
Asignación numérica fija predeterminada.- en este caso la dirección del

servidor es acordada en forma anterior o durante el desarrollo de las
aplicaciones cliente-servidor, y por ello se puede incluir en el programa
ejecutable (ejemplo en un archivo de encabezados header.h). Aunque esta
estrategia podría funcionar en un sistema particularmente sencillo, es necesaria una
forma más sofisticada de direccionamiento. Aquí cabe señalar que no se ha
determinado que es lo que significa el número asignado, es decir, no especifica si es
la identificación de un proceso o de un equipo.
Asignación aleatoria de número de proceso.- este método consiste en dejar

que cada proceso elija su propio identificador de un espacio de direcciones

grande y disperso, como el espacio de enteros de 64 bits. La probabilidad de

que dos procesos elijan el mismo número es muy pequeña. Este método puede
utilizarse en sistemas grandes. Sin embargo existe el problema de saber ¿a que
máquina enviar el mensaje?. Para ello el emisor podría enviar un paquete
especial de localización con la dirección del proceso destino. Puesto que es un
paquete de transmisión, será recibido por todas las máquinas de la red. Todos
los núcleos verifican si la dirección es la suya y, en caso de que lo sea, regresa
el mensaje de aquí estoy con su dirección en la red (número de máquina).
Servidor de nombres.- aunque el esquema anterior es transparente, la

transmisión provoca carga adicional en el sistema. Esta carga se puede evitar
mediante una máquina adicional para la asociación a alto nivel (es decir en
ASCII) de los nombres de servicios con las direcciones de las máquinas. Al
utilizar este sistema, se hace referencia a los procesos del tipo de los servidores
mediante cadenas en ASCII, las cuales son las que introducen en los programas
y no los números en binario de las máquinas o procesos. Cada vez que se
ejecute un cliente, en su primer intento por utilizar el servidor, el cliente envía
una solicitud de cuestionamiento a un servidor especial de asociaciones, el cual
se conoce como servidor de nombres para pedirle el número de máquina donde
se localiza en ese momento el servidor.

2. Primitivas de Comunicación
Primitivas con bloqueo o sin bloqueo.- una primitiva tiene una semántica sin
bloqueo cuando su ejecución no produce un retardo en el proceso que la invoca; de
otra manera la primitiva es con bloqueo.
Existen básicamente cuatro tipos de comunicación para este tipo de primitivas:
1. Send con bloqueo (CPU inactivo durante la transmisión de los mensajes)

2. Send sin bloqueo, sin copia (no se puede sobrescribir hasta que el mensaje
haya sido leído)
3. Send sin bloqueo, con copia (se desperdicia el tiempo del CPU para la copia
adicional)
4. Send sin bloqueo, con interrupción (dificulta la programación)

Primitivas almacenadas con buffer y no almacenadas.- cuando se efectúa un

intercambio de mensajes se presentan dos casos en relación a donde se va a
almacenar la información. En el primero de estos es el proceso servidor el que
destina una área para recibir un mensaje al efectuar la operación receive (no
almacenado); mientras que en el segund o el proceso servidor solicita la creación de
un buzón para alojar los mensajes que a ser recibidos mientras los puede procesar
(almacenamiento con buffers).
En sistemas sin buffer, la ejecución de un send se detiene hasta que en el otro

extremo se ejecuta un receive (si se utilizó bloqueo). En ese momento el
mensaje es enviado y ambos procesos pueden continuar su ejecución. Ambos
procesos se sincronizan o se encuentran cuando el mensaje es transferido.
Los sistemas con buffer son más difíciles de controlar debido a la necesidad de
crear, destruir y mantener los buffers.
Primitivas confiables y no confiables.- existen tres distintos enfoques de este

problema. El primero consiste en volver a definir la semántica de send para
hacerlo no confiable. El sistema no da garantía alguna acerca de la entrega de
mensajes. La implantación de una comunicación se deja enteramente en manos
de los usuarios
El segundo método exige que el núcleo de la máquina receptora envíe un

reconocimiento al núcleo de la máquina emisora. Sólo cuando se reciba este
reconocimiento, el núcleo emisor liberará al proceso usuario (cliente). El
reconocimiento va de un núcleo al otro; ni el cliente, ni el servidor ven alguna vez un
reconocimiento. De la misma forma que la solicitud de un cliente a un servidor
es reconocida por el núcleo del servidor, la respuesta del servidor de regreso al
cliente es reconocida por el núcleo del cliente. Así una solicitud de respuesta consta
de cuatro mensajes.

El tercer método aprovecha el hecho de que la comunicación cliente-servidor se

estructura como una solicitud del cliente al servidor, seguida de una respuesta
del servidor al cliente. En este método, el cliente se bloquea después de enviar
un mensaje. El núcleo del servidor no envía de regreso un recono cimiento sino
que la misma respuesta funciona como tal. Así, el emisor permanece bloqueado
hasta que regresa la respuesta. Si tarda demasiado, el núcleo emisor puede
volver a enviar la solicitud para protegerse contra la posibilidad de una pérdida
del mens aje.
Una consideración más dentro de la comunicación por paso de mensajes es la

determinación del receptor o receptores de un mensaje. Se tienen tres opciones:
 Transmisión a un sólo receptor (unicast)

 Transmisión radial (broadcast)
 Transmisión radial múltiple (multicast)
Llamados a Procedimientos Remotos
El llamado a procedimientos remotos (RPC) implica que un proceso cliente envía una
petición y permanece bloqueado hasta que el proceso servidor devuelve una
respuesta.
El objetivo de los RPCs es permitir que los programas en un ambiente distribuido se

escriban con el mismo estilo que los programas en un sistema de cómputo
centralizado. Una de las principales ventajas de este esquema de comunicación es
que los programadores no requieren saber si un llamado a procedimiento se atenderá
local o remotamente.
La responsabilidad del mecanismo RPC es convertir llamadas escritas en un

lenguaje de programación y manejar los tipos de datos de alto nivel
traduciéndolos en llamadas a servicios del nivel de Transporte en una red. El
mecanismo RPC está asociado con servicios en los niveles de Presentación y
Sesión en el modelo OSI:
Las primitivas de comunicación en RPC son: Del
lado del cliente:
call service (value_args; result_args)
Del lado del servidor:
accept service (in value_parameters; out result_parameters)

body
El RPC ocurre normalmente en la forma de un rendezvous.

Transacciones
Dentro de los sistemas distribuidos, hay muchos casos en que una sola
comunicación no resuelve problemas específicos de interacción entre dos
procesos (por ejemplo, un retiro de una cuenta bancaria). La interacción entre los
procesos puede ser una secuencia de comunicaciones y cálculos. En estas
situaciones, es adecuado operar en base a transacciones.
El concepto de transacción se desarrolló en sistemas de manejo de bases de

datos para mantener la consistencia de la información almacenada. Los
mecanismos de transacciones simplifican la construcción de sistemas
confiables, y son transparentes para las aplicaciones de usuario (nivel de Sesión
en el modelo OSI).
En general, el término transacción describe una secuencia de operaciones sobre

una o más bases de datos que transforma un estado consistente del sistema en
otro estado consistente. No todos los estados de un sistema son consistentes y,
por lo tanto, algunos cambios no son permitidos. Las aseveraciones que
describen los cambios permitidos reciben el nombre de restricciones de
consistencia.
3. Propiedades
Las transacciones tienen las siguientes propiedades:
 Consistencia.- debe mantener la consistencia del sistema en que se

aplica.
 Atomicidad.- debe ejecutarse completamente o no ejecutarse.
 Durabilidad.- una vez que se completó con buen éxito, una transacción no
se puede cancelar (al menos que se aplique otra transacción).
Los sistemas de transacciones deben soportar las siguientes operaciones:

terminación, concurrencia y recuperación (Commitment, Concurrency and
Recovery [CCR]).
4. Algoritmo de Compromiso de 2 Fases (two-phase commit)
Supongamos que hay un proceso maestro y N procesos esclavos. En la primera

fase del algoritmo two-phase commit, el proceso maestro envía peticiones a los
N esclavos solicitando algunas operaciones. Cada esclavo verifica si puede
atender la petición. Si en efecto puede, el esclavo almacena la petición y el
estado inicial del objeto en cuestión, bloquea el objeto (para que las peticiones
de otros maestros no puedan interferir), y envía un mensaje confirmando su
disposición a realizar el trabajo. De otro modo, envía un mensaje rechazando la
petición.

La segunda fase inicia cuando todas las respuestas de los esclavos han llegado. En
este momento, el maestro verifica si todos los esclavos pueden llevar a cabo su
trabajo. Si la respuesta es afirmativa, el maestro les informa que ejecuten el trabajo.
En caso contrario, es decir, si uno o más esclavos rechazan la petición inicial, el
maestro aborta la operación y pide a los esclavos que desbloqueen su objeto y
restablezcan su estado inicial.
Un esclavo puede caerse después de recibir una petición y antes de ejecutar su

trabajo. En este caso, el esclavo puede recuperarse cuando es reactivado, en base
al estado inicial y a la petición que debe tener almacenados.

2.2.2 Modelo de Referencia OSI (Open Systems Interconnection)
Propuesto en 1977 por la ISO (International Organization for Standardization). Toma

ideas de SNA (Systems Network Architecture) (1974) de IBM.
Arquitectura de capas; la capa N usa servicios de la capa N-1 y provee servicios

a la capa N+1. En contraste, una arquitectura jerárquica (como la de TCP/IP),
permite que un nivel dado se pueda comunicar con todos los niveles inferiores.
El modelo OSI tiene siete capas. Los principios aplicados para el establecimiento de
siete capas fueron:
Una capa se creará en situaciones en donde se necesite un nivel diferente de

abstracción.
Cada capa deberá efectuar una función bien definida.
La función que realizará cada capa deberá seleccionarse con la intención de
definir protocolos normalizados internacionalmente.
Los límites de las capas deberán seleccionarse tomando en cuenta la
minimización del flujo de información a través de las interfaces.
El número de capas deberá ser lo suficientemente grande para que funciones
diferentes no tengan que ponerse juntas en la misma capa y, por otra también
deberá ser suficientemente pequeñas para que su arquitectura no llegue a ser
difícil de manejar.
Capa Física
Comprende:
Transmisión de cadenas de bits, sin importar su estructura, a través de algún

medio físico.
Características:
a) Mecánicas (conectores, cables, etc.).
b) Eléctricas (voltajes, técnicas de modulación, etc.).
c) Funcionales (por ejemplo, definición de funciones de cada pin en un
conector).
d) Procedurales (por ejemplo, mecanismos de "handshake").
Ejemplos:
RS-232C, RS -449
Capa de Enlace de Datos
Comprende:
Detección y control de errores producidos en la capa física.

Sincronización de la transmisión.

Control de acceso al medio de comunicación (redes locales).

Activación, mantenimiento y desactivación de enlaces entre dos o más nodos.
Control de flujo (control, por parte del nodo receptor, de la cantidad de datos
aceptados o la velocidad de transmisión).
Ejemplos:
SDLC, HDLC, LAPB, LLC (IEEE 802.2).
Capa de Red (ó Inter-red)
Comprende:
 Entrega de paquetes entre dos o más nodos a través de inter-redes

(redes de redes), proporcionando independencia de las tecnologías de
transmisión de datos o de conmutación usadas entre los sistemas
conectados.
 Establecimiento, mantenimiento y terminación de conexiones (en
servicios orientados a la cone xión).
Ejemplos:
CLNP de OSI
IP de la familia TCP/IP
IPX de Novell
X.25 PLP (Packet-Level Protocol)
Capa de Transporte
Comprende:
 Comunicación entre procesos residentes en distintos sistemas, permitiendo

"multiplexar" dos o más enlaces proceso-a-proceso sobre un solo canal de
comunicación.
 En servicios orientados a la conexión, entrega de datos confiable por medio
de recuperación de errores, secuenciación de paquetes, control de flujo y
control de retardos en la transmisión.
Ejemplos:
TP0-TP4 de OSI
TCP y UDP de la familia TCP/IP
SPX de Novell
Capa de Sesión
Comprende:
 Control y sincronización de diálogos o sesiones.

 Control de puntos de verificación (checkpoints) en transacciones.

 Manejo de errores en sesiones (por ejemplo, una impresora inteligente a
la que se le termina el papel).
 Llamados a procedimientos remotos.
Ejemplos:
RPC de Sun Microsystems
Protocolo OSI Session
Capa de Presentación (ó Representación)
Comprende:
 Representación y/o sintaxis de los datos.

 Encripción de información.
 Compresión de datos.
Ejemplos:
ASN.1 (Abstract Syntax Notation) de OSI
XDR (External Data Representation) de Sun Microsystems
DES (Data Encryption Standard)
Capa de Aplicación
Comprende:
 Aplicaciones de red.
 Interfaces de programación para aplicaciones de us uario (APIs).
Entre las aplicaciones de red (con ejemplos) se cuentan:

Transferencia de archivos (FTP de TCP/IP, FTAM de OSI, NFS de Sun)
Emulación de terminal (Telnet de TCP/IP)
Correo electrónico (X.400 de CCITT, SMTP de TCP/IP)
Administración de redes (SNMP de TCP/IP, CMIP de OSI)
Servicios de directorio (OSI Directory Services, X.500 de CCITT)


2.2.3 Protocolos TCP/IP
La familia de protocolos conocida como TCP/IP fue desarrollada a mediados de

los años 70s por la Universidad de Stanford y a compañía Bolt, Beranek and
Newman. Quien patrocinó su desarrollo fue el Departamento de Defensa de E.U.
a través de la agencia Advanced Research Projects Agency (DARPA). El
objetivo era desarrollar una familia de protocolos para interconectar equipos de
diversos tipos.
La primera red que adoptó TCP/IP, hacia 1980, fue la ya existente ARPANET.
Esta red se convirtió en la base de la Internet que en nuestros días conecta a
más de 30,000 subredes y 2.5 millones de computadoras en unos 107 países.
La tabla 1 muestra algunos de los protocolos más comunes en la familia TCP/IP, los
servicios que proporcionan y el nivel del modelo OSI en que se ubican.
Protocolo Servicio Capa OSI
Internet Protocol (IP) Entrega de paquetes entre nodos. 3
Internet Control Message Controla la transmisión de mensajes 3 de

Protocol (ICMP) error y de control entre nodos y
gateways.
Address Resolution Protocol Mapea direcciones IP a direcciones 3

(ARP) físicas.
Reverse Address Resolution Mapea direcciones físicas a 3

Protocol (RARP) direcciones IP.
Transmission Control Entrega confiable de mensajes entre 4

Protocol (TCP) nodos.
User Datagram Protocol Entrega no confiable y sin conexión 4

(UDP) de paquetes entre nodos.
File Transfer Protocol (FTP) Transferencia de archivos. 5-7
Telnet Emulación de terminal. 5-7
Tabla 1.- Protocolos TCP/IP más comunes.

La figura 1 muestra las capas de la arquitectura TCP/IP. Al igual que en el

modelo OSI, cada capa en la máquina fuente se comunica con la misma capa de la
máquina destino.
source host destination host
Application Application
messages or streams
Transport Transport
Datagrams (UDP) or
segments (TCP)
Internet Internet
IP datagrams
Network Interface Network Interface
network frames
Network Hardware
Figura 1.- Modelo de capas TCP/IP.
Direcciones Físicas y Direcciones IP
Cada nodo tiene una dirección física (llamada dirección MAC en el contexto de
redes locales) asociada con el dispositivo de hardware que lo conecta con la red.
Por ejemplo, en Ethernet, una dirección física es un número de 6 bytes; las
redes X.25 usan el estándar X.121 que define direcciones físicas como números
de 14 dígitos.
La dirección IP de un nodo es una dirección lógica (independiente del hardware).

Consiste de 32 bits (4 bytes) que identifican tanto a la red como al host particular
dentro de esa red.
Típicamente, las direcciones IP se representan en notación decimal con puntos. (Por

ejemplo, 129.71.6.17 corresponde a 0x81.0x47.0x6.0x11).

Dado que las direcciones IP son independientes del tipo de red, éstas pueden
ser usadas para enviar paquetes entre distintos tipos de redes. En cada tipo de
red, el software de TCP/IP hace la correspondencia entre direcciones físicas y
direcciones IP.
En redes conectadas a la Internet, las direcciones IP deben ser asignadas por el NIC
(Network Information Center).
Clases de Direcciones IP
Cada dirección IP se divide en dos partes: la porción de red y la porción de host.

La división de cuántos bits corresponden a cada porción queda definida por la
clase de dirección. Se manejan tres clases principales, denominadas A, B y C.
Una dirección clase A consta de 1 byte para la porción de red y 3 bytes para el host.
El bit más significativo de la porción de red es siempre 0. Esto permite 126 redes clase
A (1 a 126) con más de 16 millones de nodos en cada una.
Una dirección clase B consta de 2 bytes para la porción de red y 2 bytes para el
host. Los bits más significativos de la porción de red son siempre 10. Así, es
posible tener 16 mil (214) redes clase B con más de 65,000 nodos cada una.
Una dirección clase C consta de 3 bytes para la porción de red y 1 byte para la
porción de host. Los tres bits más significativos de la porción de red son siempre 110.
Esto permite aproximadamente dos millones de redes clase C con un máximo de
254 nodos cada una.
Direcciones Reservadas
Direcciones de red. Estas son direcciones IP donde la porción de host está

puesta en ceros. Por ejemplo, 129.47.0.0 es la dirección de una red clase B.
Direcciones de broadcast. Estas son direcciones donde la porción de host está

puesta en unos.
Dirección de loopback. La dirección 127.0.0.0 está diseñada para pruebas y

comunicación entre procesos en forma local. Un paquete enviado a la dirección de
red 127 no debe aparecer jamás en ninguna red.

Protocolos
El Protocolo IP
IP proporciona un servicio de entrega de paquetes no confiable y sin conexión. El

servicio es no confiable porque la entrega de un paquete no está garantizada. Un
paquete puede ser ruteado erróneamente, duplicado o puede desaparecer en su
camino al destino final. El servicio es sin conexión porque cada paquete es transmitido
independientemente de cualquier otro paquete.
IP define el formato de los paquetes (llamados datagramas IP) y la forma de

manejarlos.
El software de IP de un nodo crea un datagrama que cabe dentro del marco

(frame) de la red física. Sin embargo, durante su viaje un paquete puede cruzar
distintos tipos de redes con marcos de tamaño menor. El protocolo IP define la forma
de fragmentar los paquetes en cada nodo que requiera retransmitir paquetes.
Una vez que un paquete ha sido fragmentado, no es re-ensamblado sino en su
destino final.
Asimismo, el software de IP utiliza un algoritmo de ruteo para determinar si un

paquete recibido del nivel de transporte debe ser entregado directamente (a un nodo
de la misma red), o debe ser enviado a un gateway (ruteador) para ser enviado a
otra red.
Los paquetes recibidos son verificados y luego se determina si el paquete debe ser
procesado localmente o retransmitido.
Protocolos de Transporte
Los protocolos de transporte proveen un servicio de intercambio de información entre

procesos específicos residentes en distintas máquinas. En este nivel, las entidades
direccionables reciben el nombre de puertos. Cada puerto identifica a un proceso
distinto dentro de un computador.
TCP/IP define una serie de puertos conocidos (well-known ports), asignados a

aplicaciones específicas (por ejemplo, Telnet utiliza el puerto 23). Otros números de
puerto son asignados dinámicamente.
Dentro de la familia TCP/IP se manejan principalmente dos protocolos de

transporte: UDP y TCP.

El Protocolo UDP
UDP provee un servicio de transporte no confiable y sin conexión. Cada

datagrama UDP es encapsulado en uno o más datagramas IP.
UDP se utiliza en aplicaciones que requieren intercambiar poca información, o

donde el costo de establecer una conexión virtual es muy alto (ya sea por
restricciones de velocidad o por espacio en memoria para almacenar el software
requerido).
El Protocolo TCP
TCP es un protocolo confiable de entrega de mensajes orientado a la conexión. TCP

mantiene un circuito virtual entre dos aplicaciones, controlando las formas en que
esta conexión se establece y se termina.
TCP controla que los paquetes sean entregados a las aplicaciones en la

secuencia correcta y corrige errores tales como la pérdida o duplicación de
paquetes.
2.2.4 Sockets
Introducción
La interfaz de sockets es una API (Application Programming Interface) que

permite el desarrollo de programas donde se requiera comunicación entre
procesos, ya sea local o remotamente, con base en distintos protocolos de
comunicación (principalmente TCP/IP, XNS y mecanismos de comunicación entre
procesos de Unix).
El uso más común de esta interfaz es en el desarrollo de programas dentro de

un ambiente distribuido cliente-servidor, trabajando sobre la familia de protocolos
TCP/IP.
La disponibilidad de una API de sockets está en función del sistema operativo

que se esté usando así como del lenguaje de programación. Originalmente, la
interfaz de sockets fue desarrollada para el Unix de Berkeley (léase 4.1cBSD),
hacia el año 1982. No sorprende que esta herramienta se haya diseñado en
lenguaje C.
En sistemas Unix existe otra API de comunicaciones estándar, el Transport

Layer Interface (TLI) del Unix System V de la AT&T. Ésta también fue
desarrollada en lenguaje C y en términos generales tiene la misma funcionalidad que
la interfaz de sockets de Berkeley. La TLI se usa sobre SPX e IPX de Novell,
entre otros protocolos.

¿Qué es un socket?
Definición Informal
Un socket es un extremo o un punto terminal de un canal de comunicación entre dos

procesos. Obviamente, para formar un canal de comunicación se requieren dos
sockets, a los cuales se les conoce como socket local y socket remoto. La
comunicación a través de una conexión de sockets es bidireccional.
Los sockets trabajan normalmente al nivel de transporte (en el caso de TCP/IP, sobre
los protocolos TCP o UDP), aunque existen también los raw sockets que operan en
la capa de red del modelo OSI (por ejemplo, dentro de la suite de protocolos
TCP/IP, los raw sockets se usan en programas basados en el protocolo ICMP,
como es el caso del programa Ping).
Definición Formal
Una conexión de red entre dos procesos queda completamente definida por una
asociación, la cual es una quinteta formada de la siguiente manera:
{protocolo, dirección_local, proceso_local, dirección_remota, puerto_remoto} Un
ejemplo de asociación usando la suite de protocolos TCP/IP es el siguiente: {tcp,
192.43.235.2, 1500, 192.43.235.6, 21}
Con base en el concepto de asociación, se puede definir un socket como una

media-asociación, la cual tiene dos posibles definiciones:
{protocolo, dirección_local, proceso_local}
{protocolo, dirección_remota, proceso_remoto}
A una media-asociación también se le llama dirección de transporte.
Operaciones sobre Sockets
El principal objetivo de la interfaz de sockets es facilitar al programador el

desarrollo de aplicaciones distribuidas. Casi todos los programadores están
familiarizados con el manejo de archivos por medio de las operaciones básicas
open-read-write-close. La interfaz de sockets intenta que la programación en
ambientes distribuidos se realice con las mismas operaciones, sólo que en lugar
de actuar sobre un archivo actúan sobre un punto terminal de un canal de
comunicaciones (socket). De esta manera tenemos las siguientes analogías:

Operaciones sobre un archivo Operaciones sobre un socket

open(archivo) open(socket)
read(archivo, datos) read(socket, datos)

o
receive(socket, datos)
write(archivo, datos) write(socket, datos)
o
send(socket, datos)
close(archivo) close(socket)
En realidad las operaciones sobre sockets son más complicadas. Por
ejemplo, la acción de “abrir” un socket se divide en tres pasos: Crear el
socket (local).
Asociar la interfaz de red y el número de puerto sobre los cuales va a operar.

Conectar el socket local con un socket remoto.
Una vez que un socket está conectado (es decir, abierto) se pueden realizar
operaciones de lectura y escritura sobre él.
Los siguientes puntos deben ser considerados en las operaciones de

entrada/salida con una red, contrastando con operaciones de entrada/salida
sobre archivos:
La relación cliente-servidor es asimétrica. Antes de establecer una conexión en red

se requiere que el programa sepa qué función (cliente o servidor) va a
desempeñar.
Una conexión de red puede ser orientada a la conexión o sin conexión. La
primera se parece más al manejo de archivos que la segunda, dado que, una
vez que se ha establecido (es decir, abierto) una conexión, las operaciones de
entrada/salida se aplican sobre el mismo proceso pareja. En el caso de un
protocolo sin conexión, no existe una operación de “open” debido a que cada
operación de entrada/salida sobre la red se puede hacer con un proceso distinto
en un host distinto.
La definición de asociación comprende cinco parámetros, para una conexión de red
se requieren manejar más parámetros que para operaciones de
entrada/salida sobre archivos.
La API de red debe soportar diferentes protocolos de comunicación. Distintas

familias de protocolos trabajan con direcciones de red e identificaciones de
proceso en distintos formatos, por lo cual se requiere que la API tenga algún
mecanismo genérico para operar sobre cualquier protocolo.

Principales Llamadas de Sockets
La interfaz de sockets comprende decenas de llamadas a función. El uso y la

semántica de cada función depende del contexto en que se aplica, influyendo
aspectos como el tipo de protocolo de transporte utilizado (orientado a la
conexión o sin conexión) y el rol del programa (lado cliente o lado servidor). A
continuación se presentan sólo las llamadas elementales.
Socket
Una aplicación llama a socket para crear un nuevo socket. La llamada regresa un
descriptor (el cual es del tipo entero) del socket creado.
Uso:
s = socket (family, type, protocol);
Argumentos:
Argumento Tipo Significado

family int Familia de protocolos (AF_INET para
TCP/IP).
type int Tipo de servicio (SOCK_STREAM para TCP
o SOCK_DGRAM para UDP).
protocol int Número de protocolo para la familia de
protocolos dada; normalmente 0.
Connect
Después de crear un socket, un cliente llama a connect para establecer una

conexión activa a un servidor remoto.
Uso:
retcode = connect (socket, addr, addrlen);
Argumentos:

socket int Descriptor del socket.
addr sockaddr * Punto de conexión en la máquina remota.
addrlen int Longitud del segundo argumento.
Write
Tanto clientes como servidores usan write para enviar información a través de
una conexión de red. Esta función se usa principalmente sobre TCP.

Uso:
retcode = write (socket, buf, buflen);
Argumentos:

buf char * Apuntador al buffer que contiene los datos.
buflen int Longitud en bytes del buffer.
Read
La llamada read es usada tanto por clientes como por servidores para recibir datos
de una conexión de red, principalmente sobre TCP.
Uso:
retcode = read (socket, buf, buflen);
Argumentos:

buf char * Apuntador al buffer que recibe los datos.
buflen int Longitud en bytes del buffer.
Close
Una vez que un cliente o un servidor ha terminado de usar un socket, llama a close
para destruir el socket.
Uso:
retcode = close (socket);
Argumentos:

Bind
Cuando se crea un socket, éste no sabe cuáles son las direcciones local y
remota de la conexión. Una aplicación llama a bind para especificar la dirección local
del socket. Esta llamada es usada principalmente por servidores para indicar el
puerto conocido en el cual esperarán conexiones.

Uso:
retcode = bind (socket, localaddr, addrlen);
Argumentos:

localaddr sockaddr * Apuntador a la estructura que especifica la
dirección IP y el número de puerto de
protocolo.
addrlen int Tamaño en bytes del segundo argumento.
Listen
Cuando se crea un socket, éste no queda ni activo (listo para ser usado por un
cliente) ni pasivo (listo para ser usado por un servidor). Los servidores
orientados a la conexión llaman a listen para poner un socket en modo pasivo,
es decir, listo para aceptar peticiones de conexión. Esta llamada no aplica para
UDP.
Uso:
retcode = listen (socket, queuelen);
Argumentos:

Queuelen int Tamaño de la cola de conexiones
pendientes.
Accept
Después de que un servidor llama a socket para crear un socket, bind para
especificar la dirección local, y listen para poner el socket en modo pasivo, se
llama a la función accept con el fin de crear un nuevo socket que atienda a la
nueva conexión. El socket original, que maneja un puerto conocido, se usa para
aceptar otras peticiones de conexión.
Uso:
newsock = accept (socket, addr, addrlen);
Argumentos:

socket int Descriptor del socket original.

addr sockaddr * Apuntador a una estructura de dirección

TCP/IP. Accept llena la estructura con la
dirección IP y el número de puerto de
protocolo de la máquina remota
addrlen int * Apuntador a un entero que inicialmente
especifica el tamaño del argumento addr y,
cuando la llamada regresa, especifica el
número de bytes almacenados en addr.
Las figuras 1 y 2 ejemplifican la secuencia en que se efectúa el envío y

recepción de datos para comunicaciones orientadas a conexión y no orientadas
a conexión; y las figuras 3 y 4 muestran las secuencias típicas de llamadas
hechas por un cliente y un servidor usando los protocolos TCP y UDP,
respectivamente.


2.2.5 Remote Procedure Call (RPC)

Introducción
Un llamado a procedimiento remoto tiene lugar en los siguientes pasos:
El cliente llama a un procedimiento local, llamado acoplador del cliente (client

stub). Para el cliente, el acoplador aparenta ser el procedimiento real que desea
llamar en el lado servidor. La función del acoplador es empacar los argumentos para
el procedimiento remoto, posiblemente ponerlos en un formato estándar (como se
comentará más adelante) y luego construir uno o más mensajes de red. El
empaquetamiento de los argumentos del cliente en un mensaje de red recibe el
nombre de alineación (en inglés, marshaling).
El acoplador del cliente envía los mensajes de red al sistema remoto. Esto
requiere una llamada de sistema en el kernel local.
Los mensajes de red son transmitidos al sistema remoto. Se puede usar un

protocolo orientado a la conexión o uno sin conexión, dependiendo del producto
utilizado.
Un acoplador del servidor en el sistema remoto espera la llegada de la petición

del cliente. Este componente obtiene o “desalinea” a partir de los mensajes de
(acción conocida en inglés como unmarshaling) y posiblemente convierte su
formato.
El acoplador del servidor ejecuta un llamado a procedimiento local para invocar a la

función real del lado servidor, pasándole los argumentos que recibió en los mensajes
de red del acoplador del cliente.

Cuando el procedimiento del lado servidor termina, regresa el control al

acoplador del servidor, entregándole algún o algunos valores de regreso.
El acoplador del servidor convierte los valores de regreso, si es necesario, y los

alinea en uno o más mensajes de red para enviarlos de vuelta al acoplador del
cliente.
Los mensajes se transfieren de regreso a través de la red al acoplador del

cliente.
El acoplador del cliente lee los mensajes del kernel local.
Después de convertir, posiblemente, los valores de regreso, el acoplador del

cliente finalmente regresa el control al programa cliente. Para este último, todo lo
anterior es visto como el regreso de un procedimiento normal.
Consideraciones de Transparencia
Aunque el objetivo del mecanismo de RPC es hacer que un procedimiento
remoto se pueda invocar en forma transparente, es necesario considerar los
siguientes puntos:
Paso de parámetros.
Asociación entre el cliente y el servidor.
Protocolo de transporte.
Manejo de excepciones.
Semántica de la llamada.
Representación de datos.
Rendimiento.

1. Paso de Parámetros
El paso de parámetros entre cliente y servidor puede no ser transparente. Los

parámetros que se pasan por valor son simples: El acoplador del cliente copia el
valor del programa cliente y lo empaca en un mensaje de red. El problema se
presenta con los parámetros que se pasan por referencia (es decir, cuando se
pasa la dirección de una variable en lugar de su valor). Obviamente el servidor
no puede hacer referencias directamente a la memoria del sistema cliente.
La solución típica consiste en sólo permitir el paso de argumentos por valor. Para
cada procedimiento remoto se define específicamente cuáles son los
parámetros de entrada y cuáles son los parámetros de regreso.
2. Asociación entre el cliente y el servidor
La asociación entre el cliente y el servidor se refiere a contactar el sistema

remoto apropiado. Esto tiene dos partes:
Encontrar un host remoto para el servicio deseado.

Encontrar el proceso servidor correcto en el host remoto.
3. Protocolo de transporte
Existen varios protocolos que pueden ser usados para la implementación de

RPC, entre ellos podemos mencionar UDP, TCP, SPX, TP. Cabe señalar que estos
no fueron diseñados específicamente para dicho fin.
4. Manejo de excepciones
Dentro de una llamada a una función remota hay muchas cosas que pueden
fallar. Podemos experimentar problemas con la red, con nuestra máquina o
incluso con la máquina que corre el procedimiento remoto. Muchas veces el
cliente desea detener el procedimiento que llamo por problemas en los datos,
por falta de tiempo o incluso por indecisiones. También puede suceder que el
cliente salga de su sesión de Internet cuando todavía no se termina de ejecutar
el procedimiento remoto, lo que generaría un fallo cuando el servidor intente
mandar el resultado o la conclusión del procedimiento al usuario.
Para todos estos problemas se debe tener un manejo de excepciones, las

cuáles son generadas cuando se suscita algunos de los problemas que
mencionamos. Las excepciones son una lista de valores numéricos que
representan el fallo que ocurrió.

5. Semántica de la llamada
Cuando se hace una invocación a un procedimiento local, no hay ninguna duda

respecto a cuántas veces se ejecutó el procedimiento. Si regresa al programa
que lo llamó, sabemos que se ejecutó exactamente una vez. Sin embargo, con
un procedimiento remoto, si no obtenemos ninguna respuesta después de cierto
tiempo, no sabemos cuántas veces se ejecutó éste en el otro equipo. Hay varias
posibilidades:
El cliente no puede localizar el servidor.- en este caso pueden existir varias

razones que van desde que el servidor no se encuentre levantado, hasta que el
resguardo utilizado no sea compatible con el del servidor.
Pérdida de mensajes de solicitud.- este es un caso sencillo, ya que lo único que es

necesario hacer es que el núcleo inicialice un cronómetro al enviar la
solicitud. Si el tiempo se termina antes de que regrese una respuesta o
reconocimiento, el núcleo vuelve a enviar el mensaje.
Pérdida de mensajes de respuesta.- la pérdida de las respuestas es más difícil de

enfrentar. La solución más obvia es basarse de nuevo en un cronómetro. Si no llega
una respuesta en un periodo razonable, solo hay que volver a enviar la solicitud. El
problema con esta solución es que el núcleo del cliente no está seguro de la
razón por la que no hubo respuesta. ¿Se perdió la respuesta? ¿ Ocurre que el
servidor es lento?. Esto puede ser la diferencia.
Cuando una operación, tal como un llamado a procedimiento, se puede ejecutar

cualquier número de veces “sin causar ningún daño”, se dice que es
idempotente. Ejemplos de procedimientos idempotentes son: una función que
regrese la hora del día, una función para calcular la raíz cuadrada, un
procedimiento para leer los primeros 512 bytes de un archivo en disco y una
función para obtener el saldo actual de una cuenta bancaria. Ejemplos de
procedimientos que no son idempotentes son: una función para agregar 512
bytes al final de un archivo en disco, una función para hacer un retiro de una
cuenta bancaria.
Una forma de resolver este problema es intentar estructurar de alguna manera todas
las solicitudes de modo que sean idempotentes. Otro método sería que el núcleo del
cliente asigne un número secuencial a las solicitudes. Si el núcleo del servidor
mantiene un registro del número secuencial de recepción más reciente de cada uno
de los núcleos clientes que lo utilizan, el núcleo servidor podrá indicar la
diferencia entre una solicitud original y una retransmisión. Una protección
adicional es tener un bit en el encabezado del mensaje para distinguir las solicitudes
de las retransmisiones.
Fallos del servidor.- este también se relaciona con la idempotencia, pero por
desgracia no se puede resolver mediante números secuenciales.

La razón de ello es que existen diferencias en el proceso de la llamada, estas

son relativas al momento de fallo del servidor. Se tienen los casos siguientes:
Si el proceso servidor se cayó antes de ser invocado por el acoplador del

servidor, entonces no se ejecutó.
Si el servidor se cayó después de ejecutar el procedimiento y el mensaje con la

respuesta se perdió, el procedimiento se ejecutó una vez.
Si el cliente alcanza un tiempo fuera y retransmite una petición, las cosas se

confunden más: es posible que la petición original se haya retardado en algún
punto de la red pero que tarde o temprano se haya ejecutado, y que la petición
retransmitida también se haya ejecutado.
Hay tres semánticas posibles en RPC:
Exactamente una vez significa que el procedimiento remoto fue ejecutado una vez,
nada más. Este tipo de operación es difícil de lograr debido a la posibilidad de caídas
de los servidores.
Como máximo una vez significa que el procedimiento remoto no fue ejecutado o
que fue ejecutado cuando más una vez. Si el cliente obtiene un regreso normal,
sabemos que el procedimiento remoto fue ejecutado una vez. Pero si se obtiene
una condición de error, no se sabe si el procedimiento remoto fue ejecutado una
vez o ninguna.
Al menos una vez significa que el procedimiento remoto fue ejecutado en una
ocasión pero posiblemente más veces. Esto es típico para procedimientos
idempotentes: el cliente se mantiene transmitiendo su petición hasta que recibe una
respuesta válida. Pero si el cliente tiene que enviar su petición más de una vez para
recibir una respuesta válida, hay una posibilidad de que el procedimiento
remoto fue ejecutado más de una vez.
6. Representación de datos
Un elemento que afecta a la comunicación entre dos equipos distintos es la

forma de representación de los datos. Para solucionar esta problemática es
necesario definir un estándar de representación.
7. Rendimiento
En relación a este punto es necesario señalar que cada máquina en conjunción con
el sistema operativo con que cuenta, representa una problemática diferente para
efectuar una RPC, y que ello se refleja en el rendimiento del equipo para efectuar
este tipo de llamadas. En estos casos lo mejor que se puede hacer es optimizar el
código relacionado con estos procedimientos.

2.3. Modelo de Capas
Actividad 2.3
Para estudiar el Modelo de Capas o de Aplicación para diseñar programas

estudiaremos algunos fundamentos teóricos y posteriormente se plantearán
escenarios de una aplicación modelada
Instrucciones
Coloque los programas solicitados en Tarea Individual 2.3
Material 2.3.
Una estrategia fundamental para diseñar aplicaciones, particularmente aquellas

basadas en componentes, consiste en utilizar el modelo de aplicación.
El modelo de aplicación sugiere modelar las aplicaciones por capas. El término

capa deriva del término en inglés tier (no proviene del término layer en inglés).
Independientemente del número de capas que se empleen para diseñar una

aplicación, son básicamente 3 tipos de servicios que pueden proveer estas
capas:
 Servicios de usuario o presentación
 Servicios de negocio
 Servicios de datos

Cuando una aplicación se diseña a una capa, estos 3 tipos de servicios se

encuentran fusionados en el código de este componente.
Cuando se diseña a 2 capas, en una de las capas se ubican uno de los tipos de
servicios y en la otra capa se encuentran fusionados los otros 2 tipos de
servicios. Las combinaciones posibles para fusionar servicios son:
 Servicios de presentación y servicios de negocio

 Servicios de negocio y servicios de datos
La combinación exclusiva de servicios de presentación con servicios de datos en una

capa es inválida.
Las aplicaciones diseñadas a mayor número de capas son posibles, ya que

aunque estos servicios persisten, las capas pueden comenzar a estratificarse en
subcapas y es en dónde aparecen un mayor número de capas. Por ejemplo, si
partimos de un modelo a 3 capas, y el arquitecto de software decide que la capa
de negocio se estratifique en 2 subcapas, en total tendremos una aplicación de 4
capas. A partir de la tercera capa, podemos hablar de modelos multicapa o n-
capas.
Los servicios de usuario o presentación son los que proveen la interfaz al

usuario.
El usuario puede ser una persona u otro programa o componente. Cuando es una
persona los servicios de presentación son proporcionados por una Interfaz Gráfica
del Usuario (GUI - Graphic User Interface). Cuando el usuario es un programa o
componente, los servicios de presentación son proporcionados a través de una API
o interfaz programática.

Aunque la capa de presentación no debe procesar información puesto que

corresponde a la capa de “negocio”; es válido que la capa de presentación tenga
código de procesamiento para validar entrada de datos en forma básica o
formatear información de salida.
Los Servicios o Reglas de Negocio de una aplicación corresponden a los

algoritmos principales de ésta. El emplear el término “Negocio” no implica que
forzosamente correspondan a algoritmos de aplicaciones administrativas; sino
que, como se ha denotado, es cualquier algoritmo principal de la aplicación. Por
ejemplo, en un programa que pida números al usuario, los ordene y los imprima
en pantalla; la regla de negocio correspondiente es el algoritmo de
ordenamiento.
Es la capa responsable de administrar las transacciones de negocio, la cual

generalmente es implementada a través de la tecnología de componentes
basada en objetos. El empleo del paradigma de la orientación a objetos nos hace
recurrir a un conjunto de herramientas denominadas Monitores de
Transacciones (también conocidos en inglés como TP Monitors - Transaction
Processing Monitors).
La capa de negocio tiene dentro de sus facultades el solicitar el cambio o

consulta de los datos, pero no le corresponde llevar a cabo esta tarea, lo cual será
el trabajo a realizar por la capa de datos.
Por ejemplo, en una aplicación de créditos hipotecarios, en un punto de

ejecución de la misma se requerirá que para otorgar un crédito el cliente debe
ser mayor de edad, contar con un aval, contar con una propiedad valor superior
o igual a $500,000.00 y ser de nacionalidad mexicana. Para tal efecto, la
aplicación deberá realizar una serie de consultas y cálculos para autorizar el
crédito. Este tipo de algoritmos corresponden a las reglas de negocio.

La capa de datos realiza los servicios u operaciones de manipulación de bajo nivel

de base de datos.
Los servicios u operaciones podrán ser los de inserción, borrado, modificación y

consulta en una base datos.
Como se comentó en la sección anterior, la capa de negocio solicita estos

servicios más no los implementa o lleva a cabo. La capa de datos si los
implementa.

De esta manera, aunque la capa de negocio hace solicitudes a la capa de datos

respecto a las operaciones a realizar sobre los mismos; la capa de negocio no
requiere conocer dónde se localizan los datos, como se implementa el acceso a los
mismos y los pormenores de éste.
Ejemplo a 2 Capas
Cliente Cliente
Presentación Presentación
(Servicios de Usuario) Presentación (Servicios de Usuario) Presentación
Reglas de Negocio Reglas de Negocio Red

(Lógica de Aplicación) (Lógica de Aplicación)
Reglas de Negocio Reglas de Negocio
Red (Lógica de Aplicación) (Lógica de Aplicación)
Datos y Recursos Datos y Recursos

(Servicios de Datos) Datos (Servicios de Datos) Datos
Servidor Servidor
En el modelado a 2 capas, existen 2 formas en que las capas pueden

fusionarse:
1) Capa de presentación - Capa de negocio, o

2) Capa de negocio - Capa de datos
Ejemplo a 3 Capas
Presentación
(Servicios de Usuario) Presentación Cliente
Red
Middleware
Reglas de Negocio Reglas de Negocio +
(Lógica de Aplicación) (Lógica de Aplicación)
Servidor1
Red
Datos y Recursos
(Servicios de Datos) Datos Servidor2
Base de Datos

En el modelado a 3 capas, los servicios se distribuyen para cada uno de estos tipos
de servicios: presentación, negocio y datos.
Por ejemplo, para una aplicación diseñada a 3 capas podemos tener una
aplicación cuya capa de presentación pueda ser provista de dos formas. Una de
ellas a través de la interfaz gráfica que puede ser construida con un lenguaje de
programación. La otra a través de un navegador para Internet (browser)
empleando páginas Web (construidas en forma estática o dinámica).
La capa de negocio puede ser implementada a través tecnología de

componentes. Y la capa de datos a través de componentes de acceso a
manejadores de bases de datos.
Existe una discusión respecto a la implementación de la capa de datos. Algunos

autores o diseñadores consideran que el manejador de base de datos y los
procedimientos almacenados conforman la capa de datos. Otros consideran que
debe existir por lo menos una capa de objetos que administren e interactúen con
el manejador de bases de datos y los procedimientos almacenados; y todos
estos elementos

Escenario 2.3.
La aplicación del ejemplo consiste en una interfaz gráfica que solicita al usuario
su nombre y fecha de nacimiento. A través de dos botones principales, el
primero “Calcular edad” y el segundo “Guardar”. “Calcular edad” obtendrá la
fecha de sistema y calculará la diferencia en años entre ésta y la fecha de
nacimiento capturada. “Guardar” almacenará la información en una base de
datos.
Una propuesta o sugerencia de la interfaz gráfica.

Pseudocódigo para diseñar la aplicación a 1 capa
Pseudocódigo para diseñar la aplicación a 2 capas

Pseudocódigo para diseñar la aplicación a 3 capas


Rúbrica para evaluación de ejercicios prácticos
Puntos de
Arriba del Debajo del
Atributos En el Estándar Atributo
Estándar
Estándar Obtenidos
(10-9) (8.5-7) (6.5-0)
La información La información La información
revisada permitió revisada permitió revisada no a
Aplicación de a los estudiantes los estudiantes permitió a los
la comprender con comprender estudiantes
Información claridad los solamente los comprender
ejercicios y ejercicios y los ejercicios y
programas. programas. programas.
(10-9) (8.5-7) (6.5-0)
Los estudiantes
han demostrado el
significado del Los
material Los estudiantes estudiantes no
elaborando han demostrado han hecho
correctamente, el significado del contacto con el
Conexiones material material,
mientras
Especialistas incorporándolo simplemente
extienden y
explican la correctamente sin incorporar
información, en el estudio del la información
incorporándola en tema. en su estudio
el estudio del del tema.
tema.
Total de Puntos Obtenidos

3. Tecnologías de Desarrollo
Panorama General
Tecnologías de Desarrollo Sistemas

Distribuidos
Definición de Actividades
Agenda
Metodología Actividades
Evaluación

Metodología
 Introducción
 Estrategias de Aprendizaje
o Aprendizaje Basado en Problemas o

Estudio de Casos
o Aprendizaje Orientado a Proyectos
Introducción
En el sentido de abordar el tema de tecnologías de desarrollo

dentro de los sistemas distribuidos se plantearan las bases para que
los alumnos trabajen en un ambiente de colaboración a través de los
pasos de las técnicas didácticas de aprendizaje basado en problemas
(ABP), estudio de casos (EC) y
aprendizaje orientado a proyectos (AOP).
Al incorporar las estructuras de estas técnicas se identifican los roles

dentro de los grupos o equipos de alumnos, así como del profesor o
tutor.

Aprendizaje Basado en Problemas
Con la técnica de ABP los alumnos aprenderán a:

1) Identificar sus necesidades de aprendizaje.
2) Dirigir su aprendizaje utilizando recursos adecuados.
3) Proveer a los demás con muestras de su aprendizaje.
4) Actuar en general en forma responsable.
Problema: Discusión en un grupo reducido:

• Descripción de un conjunto de • “¿Qué es lo que ya sé sobre el
problemas o sucesos. problema?”.
• Preparado por un equipo de • “¿Qué es lo que necesito saber
docentes. sobre el problema?”
Discusión en un grupo reducido: Estudio individual:

• “¿Adquirimos una mejor • Exploración de los diversos
comprensión de los procesos recursos de aprendizaje.
involucrados en el problema?” • Fuentes externas de
información.
• Integración de los
conocimientos de varias
disciplinas.

ABP, Roles y Apoyos en General

Dinámica ABP: Roles:
 Presentación del problema. o Equipo de Trabajo (Miembro,
 Análisis, construcción de hipótesis Moderador y/o Secretario).
e identificación de la información  Investigación individual.
necesaria.  Discusión grupal.
 Enumeración de las áreas de duda.  Discusión plenaria.
 Búsqueda de la información o Tutor o Profesor.
 Discusión de la hipótesis según los  Planteamiento del problema.
datos.  Seguimiento e integración.
 Replanteamiento / Conclusiones. Apoyos:
Actividades ABP: o Chat
 Resumen de que saben y que o Foro
necesitan investigar. o E-mail
 Distribución de tareas y forma de o Fuentes de Información
recolectar la investigación, como
colocar todo junto.
 Evaluación y retroalomentación.
Estudio de Casos
Con la técnica de EC los alumnos aprenderán a:
1) Analizar y ejercitar sobre un caso típico de estudio.
2) Colaborar y dirigir el aprendizaje utilizando recursos adecuados.
3) Defender el conocimiento adquirido y actuar en forma responsable.
Problema: Estudio individual:

• Descripción de una situación • Exploración de los diversos
real pero abordable. recursos de aprendizaje.
• Preparada por un equipo de • Identificación de alternativas.
docentes. • Integración de propuesta.
Discusión entre grupos: Discusión en un grupo reducido:

• Defensa de postura. • Intercambio de propuestas.
• Conclusiones sobre hechos • Confrontación de ideas.
concretos del caso. • Preparación de propuesta
• Reflexión de cada definitiva.
participante.

Aprendizaje Orientado a Proyectos

Con la técnica de AOP los alumnos aprenderán a:
1) Construir sobre su propio conocimiento una situación real.
2) Colaborar a un ritmo apropiado y actuar con responsabilidad.
Problema: Discusión en un grupo reducido:

• Descripción de un situación • “¿Que proyecto proponemos
concreta y real. con base a los conocimientos
• Preparada por un equipo de adquiridos?”
docentes o propuesta por los • “¿Que deseamos resolver sobre
alumnos. el tema del curso?”
Producto terminado: Tópico seleccionado:

• Reporte técnico • Análisis y definición de
• Manual de usuario necesidades.
• Presentación • Planeación de actividades.

• Diseño y prototipo.
Actividades
Subtema Actividad de Aprendizaje
Introducción al middleware Utilizar ABP para abordar el

paradigma del middleware
Programación de Realizar un ejercicio práctico
Transacciones
CORBA Utilizar EC para abordar el
modelo de CORBA
RMI Realizar un ejercicio práctico
COM+ Realizar un ejercicio práctico
Web Services Realizar un ejercicio práctico

Actividades
Con base al estudio del tema 3 de tecnologías de
desarrollo, los alumnos propondrán por equipo, de forma
preliminar, el tópico de implementación de un sistema
distribuido trivial, con objeto de cubrir más adelante el tema 4,
Lenguajes de Programación.
Tema 4 Actividad de Aprendizaje
Implementación de un Utilizar AOP para abordar

sistema distribuido un proyecto sencillo.
Evaluación
Rúbrica de
evaluación para
el proceso de
ABP

Evaluación
Rúbrica de
evaluación para
el proceso de
EC
Evaluación
Rúbrica de evaluación para el proceso de AOP

Evaluación
Rúbrica de evaluación de Ejercicios Prácticos
3.1. Introducción al Middleware
Escenario Middleware

Introducción al Middleware
Escenario
 Un sistema distribuido organizado como un middleware:
o Sistema abierto independiente del fabricante.
o Sin dependencia del hardware y sistema operativo subyacente.
 DCE, CORBA, DCOM, …
Máquina A Máquina B Máquina C

Aplicaciones
Lenguajes de Programación
MIDDLEWARE
Sistema Sistema Sistema

Hardware Hardware Hardware
Red de Interconexión

 El paradigma significa "un diseño, ejemplo o modelo." En el estudio de
cualquier tema de gran complejidad, es útil para identificar los diseños
básicos o modelos y clasificar el detalle según estos modelos.
 Este escenario apunta para presentar una clasificación de los

paradigmas para las aplicaciones distribuidas basadas en el
middleware.
 Básicamente los middleware pueden clasificarse en tres categorías,

orientados a transacciones, a mensajes y a objetos, entonces el objeto de
estudio es la representación abstracta de los modelos en dirección del
middleware en la actualidad.
 El desarrollo de este trabajo deberá ser en grupo mediante el proceso

de aprendizaje basado en problemas.
Actividad 3.1
Utilizando la técnica de ABP discutir en equipo los modelos del middleware en la

actualidad y proponer una representación abstracta de ellos.
Foro de discusión Foro Middleware
Coloque su trabajo de equipo en Tarea en Equipo 3.1
Se proporciona Material de Apoyo 3.1, solamente como introducción.


El middleware es un software de conectividad que consiste en la habilitación de

un conjunto de servicios que permiten procesos múltiples corriendo sobre una o
más máquinas interactuando por una red. El Middleware es esencial para la
migración de aplicaciones de mainframe a aplicaciones cliente -servidor y para
mantener la comunicación de plataformas heterogéneas. Esta tecnología ha
evolucionado durante los años noventa para proporcionar interoperabilidad en
apoyo del movimiento a arquitecturas de cliente-servidor. Las publicaciones más
extensas de iniciativas del middleware han sido: Distributed Computing
Enviroment (DCE) de Open Software Foundation's, Common Object Request
Broker Architecture (CORBA) de Object Management Group's, Distributed
Component Object Model (COM/DCOM) de Microsoft's, entre otras.
Esquema del Middleware
La figura esquematiza el uso del middleware, son servicios con un conjunto de

software distribuido que existe entre la aplicación y el sistema operativo y
servicios de red en un nodo del sistema en la red.
Los servicios del middleware proporcionan un conjunto más funcional de

Interfaces de programación de aplicaciones (API) que el sistema operativo y que los
servicios de red para permitir una aplicación que permita:
 Localizar de forma transparente por la red, proporcionando interacción

con otra aplicación o servicio
 Ser independiente desde los servicios de red.
 Ser fiable y disponible.
 Aumentar en capacidad sin perdida de función.
Formas de Middleware
El middleware puede asumir las formas siguientes:
Monitores de procesamiento de transacciones (TP) que proveen herramientas y un

entorno para desarrollo y despliegue de las aplicaciones distribuidas.
Llamada a procedimientos remotos (RPCs) que permite distribuir la lógica de una

aplicación por la red. La lógica del programa en sistemas remotos puede
ejecutarse tan simplemente como llamando una rutina local.
El middleware orientado a mensaje (MOM) que proporciona el intercambio de

datos de programa a programa, habilitando la creación de aplicaciones
distribuidas. El MOM es análogo a envío de correo electrónico en el sentido que

es asincrónico y les exige a los destinatarios de mensajes interpretar su

significado y tomar medidas apropiadas.
Agentes de objetos para peticiones (ORB s) que habilitan los objetos que
comprenden una aplicación para ser distribuida y compartida por redes
heterogéneas.
Consideraciones útiles
El propósito principal de servicios del middleware es ayudar en la solución de

varios problemas de conectividad de la aplicación y de interoperabilidad. Sin
embargo, los servicios del middleware no son un remedio, debido a que:
 Hay un hueco entre los principios y práctica. Muchos servicios del

middleware populares usan aplicaciones propietarias (aplicaciones que
hacen dependencia en el producto de un sólo vendedor).
 El número de servicios del middleware es una barrera a usarlos. Para
guardar su entorno informático manejablemente simple, los
desarrolladores tienen que seleccionar un número pequeño de servicios
que satisfacen sus necesidades por la funcionalidad y fondos de la
plataforma.
 Mientras los servicios del middleware aumentan el nivel de abstracción de
programar aplicaciones distribuidas, todavía dejan al desarrollador de
aplicaciones con opciones de diseño pesadas. Por ejemplo, el
desarrollador todavía debe decidir que funcionalidad poner sobre el lado
del cliente y del servidor de una aplicación distribuida.
La clave para superar estos tres problemas es entender el problema de la

aplicación y el valor de servicios del middleware que puedan habilitar la
aplicación distribuida totalmente. Para determinar los tipos de servicios del
middleware requeridos, el desarrollador debe identificar las funciones
requeridas, qué entran en una de tres clases:
Los servicios de sistemas distribuidos que incluyan comunicaciones críticas,

programa-a-programa y servicios de administración de datos. Este tipo de
servicio incluye RPCs, MOMs y ORBs.
Aplicación que habilita servicios a los que dan acceso de las aplicaciones de
servicios distribuidos y la red subyacente. Este tipo de servicios incluye los
monitores de transacciones y los servicios de base de datos como el lenguaje de
consulta estructurada (SQL).
La administración de los servicios del middleware que habilite aplicaciones y

funciones del sistema que sean continuamente monitoreados para asegurar el
rendimiento óptimo del entorno distribuido.

Rúbrica para evaluación de tareas del proceso de ABP
Puntos de
Arriba del En el Debajo del
Atributos Atributo
Estándar Estándar Estándar
Obtenidos
(5 -4.5) (4 -3.5) (3-0)
Sus
Participación,
Sus intervenciones
pero sus
intervenciones mostraron
intervenciones
mostraron relación con
no estaban
bastante el escenario,
Definición del relacionadas
relación con pero no
Problema con el
el escenario y log raron
escenario ni
fueron la base aterrizarlas
condujeron
para abordar del todo para
para abordar
el problema. abordar el
el problema.
problema.
(10-9) (8.5 -7) (6.5 -0)
La La
información información La
reunida reunida información
incluye los incluye los reunida está
Profundidad de elementos elementos incompleta y
Estudio esenciales del esenciales del no incluye los
tema y un tema y un elementos
estudio en estudio esenciales del
profundidad normal del tema.
del tema. tema.
(5 -4.5) (4 -3.5) (3-0)
Su aportación Hizo
fue bastantes Hizo pocas
determinante aportaciones, aportaciones
para la pero le falto y sin relación
Solución/explicación
elaboración aterrizarlas en con las
del problema
del reporte propuestas posibles
final de la concretas de soluciones del
solución del solución al problema.
problema. problema.

3.2. Programación de Transacciones
Escenario Transacciones
Programación de Transacciones
Escenario
¿Qué es una transacción?

 Una transacción es un conjunto de
tareas relacionadas que se realizan
de forma satisfactoria o incorrecta
como una unidad. En términos de
procesamiento, las transacciones se
confirman o se anulan. Para que una
transacción se confirme, todos los
participantes deben garantizar la
permanencia de los cambios
efectuados en los datos. Los cambios
deben conservarse aunque el
sistema se bloquee o tengan lugar otros
eventos impre vistos.

La creación de una transacción completa puede requerir la cooperación de

varios componentes. En el ejemplo de la figura, la aplicación de entrada de
pedidos consta de componentes que, mediante DCOM (Distributed Component
Object Model), recuperan y procesan información de varios servidores.
MTS(Microsoft Transaction Server) proporciona servicios integrados de
programación que permiten a los programadores asegurarse de que toda la
transacción tiene éxito o se anula por completo, sin necesidad de escribir
grandes cantidades de código personalizado para controlar los mecanismos de
la transacción.
Escenario de Transacciones
 Si bien, las transacciones están clasificadas dentro de los tipos de

middleware. Las transacciones son frecuentemente usadas en
aplicaciones de bases de datos distribuidas, Microsoft las incorpora dentro de
su infraestructura, como se menciona en el ejemplo previo, sin
embargo las mejoras se presentan en COM+, que son los servicios de
aplicaciones basadas en componentes de Windows.
 Por el momento en este escenario trataremos un ejercicio sencillo de
transacciones y en el tema de COM+ trataremos las transacciones en
conjunto con la infraestructura de Microsoft para aplicaciones distribuidas.

Escenario de Transacciones
EJERCICIO
Utilice un manejador de base datos relacionales.

Cree una tabla llamada Cuentas con los campos Clave y Saldo.
Inserte 2 registros, la cuenta con clave 100 y la cuenta con clave 200; ambas con $1000.00
El código SQL para crear una transferencia bancaria de $100.00 de la cuenta 100 a la 200 es: UPDATE
Cuentas SET Saldo=Saldo - 100.00 WHERE Clave = 100
UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE Clave = 200
Ejecute las instrucciones de SQL para ver que resultados produce en las cuentas: SELECT
* FROM Cuentas
Ejecute sólo la primera instrucción
Cierre la aplicación con la que introduce los comandos SQL
Vuelva a entrar a la aplicación y consulte el contenido de la cuenta. Obviamente sólo quedó afectada
una cuenta y eso es una falta de consistencia en la información. Con esto se simula la falla de la
aplicación y el rompimiento de las propiedades ácidas.
Ahora ejecute el siguiente código
BEGIN TRANSACTION
UPDATE Cuentas SET Saldo=Saldo - 100.00 WHERE Clave = 100
UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE Clave = 200
COMMIT TRANSACTION
Analice el resultado
Ahora sólo ejecute sólo las primeras 2 líneas del código anterior que consta de 4 líneas. Cierre la
aplicación con la que introduce los comandos SQL
Vuelva a entrar a la aplicación y consulte el contenido de la cuenta.
Analice la importancia del manejo de transacciones.
Actividad 3.2
Programación de Transacciones
Realizar el ejercicio del Escenario Transacciones y colocar su reporte en Tarea

Individual 3.2
Se anexa Material de Apoyo 3.2 como consulta y ampliación de comprensión del

rubro de transacciones.

Rúbrica para evaluación Ejercicios Prácticos
Puntos de
Estándar Estándar
Obtenidos
(10-9) (8.5-7) (6.5-0)
La información
La información La información
revisada
revisada permitió revisada no
permitió a los
Aplicación de a los estudiantes permitió a los
estudiantes
la comprender con estudiantes
comprender
Información claridad los comprender
solamente los
ejercicios y los ejercicios y
programas. ejercicios y
programas. programas.
(10-9) (8.5-7) (6.5-0)
Los estudiantes
han demostrado
Los
el significado del
Los estudiantes estudiantes no
material
han demostrado han hecho
elaborando
el significado del contacto con
correctamente,
Conexiones material el material,
mientras
extienden y
correctamente sin incorporar
exp lican la
en el estudio del la información
información,
tema. en su estudio
incorporándola en
del tema.
el estudio del
tema.


3.2 Programación de Transacciones
Desde una apreciación general, el hablar de la comunicación entre objetos o

componentes a través de un middleware de objetos parece ser muy simple. Sin
embargo, se presentan varias implicaciones de mayor complejidad en el
contexto en el que trabajan los objetos implicados como:
 Transacciones
 Concurrencia
 Descubrimiento/Nombrado
 Seguridad
 Etc.
Para la Capa de Negocio de una aplicación el control de transacciones es crucial para

mantener la consistencia e integridad de las operaciones.
Una transacción es un conjunto de acciones que deben efectuarse como una

unidad indivisible de trabajo. Ciertamente al ejecutarse el conjunto de acciones
que conforma la transacción, puede ocurrir algún error físico o lógico en su
ejecución, y de ser así todas las acciones que habían sido efectuadas deben
revertirse. Esta acción ayuda a mantener la consistencia e integridad de la
información.
Este tipo de mecanismos deben conformarse en una serie de servicios

disponibles al programador y ofrecer la característica de TRANSPARENCIA. Es
decir, es transparente para el programador el revertir automáticamente las
acciones u operaciones efectuadas; el programa se limita a especificar el inicio

de la transacción e indicar en qué punto se efectúa la confirmación (commit) y

eventualmente, poder indicar en forma programática e intencional el retroceso
(rollback) de la transacción. Obviamente, en forma inherente si ocurre un error, se
llevará en forma automática el retroceso (rollback) de la operación.
Las transacciones deben de cumplir con 4 características básicas:
1. Atomicidad: “O todo o nada”. Es la característica inherente a la

transacción en la que o todas las acciones se efectúan exitosamente o
ninguna de ellas.
2. Consistencia: El efectuar exitosamente toda la transacción (commit) los
datos involucrados fueron manipulados en forma correcta; o si se revierte
(rollback) los datos quedan tal cual como estaban previamente al inicio de
la transacción.
3. Aislamiento: Es inherente la característica de concurrencia o bloqueo; ya
que mientras un proceso u objeto utiliza determinados datos, otro proceso
u objeto no debe modificarlos.
4. Durabilidad: Una vez efectuada una transacción, los datos deben
persistir o haberse almacenado en forma permanente.
Por las siglas de estas características en inglés resulta la palabra ACID, que
significa ácido. Por lo que suele llamarse “pruebas o características ácidas” el que
un administrador de transacciones cumpla con ellas.

EJERCICIO
1. Utilice un manejador de base datos relacional.

2. Cree una tabla llamada Cuentas con los campos Clave y Saldo.
3. Inserte 2 registros, la cuenta con clave 100 y la cuenta con clave 200;
ambas con $1000.00
4. El código SQL para crear una transferencia bancaria de $100.00 de la
cuenta 100 a la 200 es:
UPDATE Cuentas SET Saldo=Saldo - 100.00 WHERE

Clave = 100
UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE
Clave = 200
5. Ejecute las instrucciones de SQL para ver que resultados produce en

las cuentas:
SELECT * FROM Cuentas
6. Ejecute sólo la primera instrucción

7. Cierre la aplicación con la que introduce los comandos SQL
8. Vuelva a entrar a la aplicación y consulte el contenido de la cuenta.
Obviamente sólo quedó afectada una cuenta y eso es una falta de
consistencia en la información. Con esto se simula la falla de la
aplicación y el rompimiento de las propiedades ácidas.
9. Ahora ejecute el siguiente código
BEGIN TRANSACTION
UPDATE Cuentas SET Saldo=Saldo - 100.00 WHERE
Clave = 100
UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE
Clave = 200
COMMIT TRANSACTION
10. Analice el resultado
11. Ahora sólo ejecute sólo las primeras 2 líneas del código anterior que
consta de 4 líneas.
12. Cierre la aplicación con la que introduce los comandos SQL
13. Vuelva a entrar a la aplicación y consulte el contenido de la cuenta.
14. Analice la importancia del manejo de transacciones.

Las transacciones pueden clasificarse de varias formas.
Por el control de ejecución, particularmente por la relación que existe en el

tiempo de ejecución entre una acción y la siguiente dentro de la transacción, hay
transacciones síncronas o asíncronas.
La situación más común en una transacción, es que ésta dure muy poco tiempo,
algunos segundos (3 ó 4 segundos o menos es ideal, pero no una regla); por lo que la
diferencia de tiempo entre una acción y la siguiente es una fracción muy pequeña de
segundo. Este tiempo de transacción se denomina síncrona y son las que se tratan en
este curso.
Una transacción asíncrona es aquella donde existe un tiempo muy prolongado

entre una acción y la siguiente dentro de una transacción. Las plataformas y
mecanismos de control de transacciones tradicionales no están pensados para
este tipo de situaciones. El tiempo de diferencia puede variar de varios minutos,
horas o días. Para poder soportar transacciones asíncronas, se requiere una
infraestructura adicional basada en colas o queues de mensajes, tanto de salida
como de salida, entre el nodo o computadora cliente y la computadora o nodo
servidor.
Por la ubicación de los administradores de recursos involucrados en la

transacción conectados a través de la red, las transacciones pueden ser locales o
distribuidas.
La transacción será local cuando los administradores de recursos involucrados en

cada una de las acciones están en el mismo nodo o computadora.

La transacción será distribuida cuando los administradores de recursos

involucrados en las acciones de ésta están en nodos o computadoras distintas y se
comunican a través de la red.
Reiterando, una transacción trabajará en un ambiente de ejecución que le

proporcione las propiedades ácidas en forma transparente y automática. Esto
brinda o proporciona la simplicidad en la programación. El código creado
manejando transacciones en la capa de negocios es muy simple bajo este
contexto.
Las transacciones síncronas son las más comunes y deseadas en el manejo de

transacciones.

Como se ha visto en el modelo de aplicación, la capa o servicios de negocio

solicitan las operaciones con los datos a la capa o servicios de datos; esta
situación genera una pregunta interesante: Si la capa de negocio coordina la
transacción entre los componentes que pueden estar en el mismo nodo o nodos
diferentes ¿Cómo se controla la transacción en la capa de negocio en
coordinación con los diferentes nodos involucrados en la capa de datos?
En forma básica puede controlarse una transacción a partir de un componente u

objeto el cual solicita una transacción a un DBMS o Sistema Manejador de Base
de Datos. El mecanismo de intercambio de información se realiza a través del
envío y recepción de mensajes de requerimiento (request) y respuesta
(response). Para dar inicio a la transacción se envía un mensaje al DBMS de inicio
de transacción, y posteriormente según el caso, se envía el mensaje para confirmar la
transacción (commit) o revertirla (rollback).
Por otro lado, puede efectuarse una transacción distribuida a través de los
mecanismos que ofrecen manejadores de bases de datos distribuidas; sin
embargo, este esquema excluye la participación de objetos por lo tanto el
modelo de aplicación que divide la aplicación en capas. Ciertamente se efectúa
la transacción distribuida pero únicamente a nivel de los manejadores de bases
de datos.

Por lo exp uesto anteriormente, el control de la transacción debe efectuarse en la capa

de negocio.
La acción más recurrente o común en una transacción es solicitar operaciones a un

manejador de bases de datos.
Si existiese un componente en la capa de negocio que solicita una información,

éste se constituye en cliente; y si tuviéramos otro componente en la capa de
datos constituido en servidor que proporciona esta información comunicándose
con el DBMS bajo el contexto de una transacción tendríamos un “procesamiento
de transacciones en línea”; el cual, puede llevarse a cabo de dos formas:
 TP-Lite: Procesamiento ligero de transacciones realizado a través de

procedimientos o funciones de un API de un proveedor específico
 TP-Heavy: Procesamiento robusto de transacciones llevado a cabo por un
TP Monitor o monitor de procesamiento de transacciones.

Un TP monitor es un software especializado para administrar transacciones. En

sus orígenes, sólo controlaban las transacciones en la capa de datos.
Actualmente, es una función fundamental el administrar la transacción desde la
capa de negocio. Otra de sus características es controlar la transacción en forma
DISTRIBUIDA. Los TP monitors son capaces de controlar la transacciones, la
ruta de transacciones a través de todo el sistema, balancear la carga para su
ejecución y restaurar las condiciones del sistema en caso de fallas.
Dada la naturaleza de las aplicaciones cliente/servidor o distribuidas de

conformarse a través de un conjunto de objetos comunicándose entre sí, y
utilizar un elemento del middleware denominado ORB para lograr esta
comunicación.

Los objetos pueden disponerse en un nodo y constituirse como servidor de

objetos de aplicación. En forma inherente, debe darse soporte a la concurrencia.
Por tal motivo, deben existir Monitores de Transacciones con Objetos que
fungen como servidores de objetos de aplicación. Los cuales disponen los
objetos o componentes hacia los objetos o componentes que solicitan estos
servicios.
Dada la necesidad de las transacciones y todas sus implicaciones en

aplicaciones distribuidas, el monitor de transacciones el software fundamental
para administrarlas. Es una estructura de software preconstruida, ayuda a
desarrollar y administrar en forma más sencilla una aplicación C/S garantizando

en forma transparente y automática las propiedades ácidas; está optimizada de tal

forma que su diseño debe brindar un alto rendimiento.
Retomando la pregunta planteada en párrafos anteriores: ¿Cómo se controla la

transacción en la capa de negocio en coordinación con los diferentes nodos
involucrados en la capa de datos?; particularmente si esos nodos contienen
DBMSs (Manejadores de Bases de Datos) que a su vez administran
transacciones locales con los datos.
Existe un estándar de comunicación entre elementos involucrados en

transacciones distribuidas creados por una organización llamada XOpen, el
estándar se llama XA, por lo que el estándar se conoce como XOpen/XA.

Los elementos involucrados en transacciones distribuidas son:

1. Programas de aplicación del proceso cliente que contienen los objetos
que solicitan acciones involucradas en la transacción.
2. Administradores de recursos: Son componentes o sistemas que

proporcionan servicios para ejecutar las acciones de una transacción. Los
administradores de recursos más comunes son DBMSs.
3. El Administrador de Transacciones (TP Monitor comúnmente) es quien

coordina el flujo de información y control de la transacción.

4. Administrador de Comunicaciones que satisface los requerimientos de

enlace y control entre los administradores de recursos involucrados en la
transacción.
En términos generales, como el control de la transacción debe efectuarse en la

capa de negocio; de no existir un monitor de transacciones, el programador
tendría que programar toda la comunicación de información y control con los
administradores de recursos o DBMSs involucrados utilizando el protocolo
XOpen/XA.
El Administrador de Transacciones o TP Monitor abstrae la funcionalidad de

comunicación con los administradores de recursos, ofreciendo sus servicios a
través de un API de objetos para que sea utilizado por el programa cliente. El

TP Monitor se comunicará a través de XOpen/XA con los administradores de

recursos, los cuales, sus fabricantes ya implementan generalmente este
protocolo en sus productos. El administrador de comunicaciones coordina todo el
intercambio de información.
El flujo de información y control parte del programa de aplicación cliente. El cual

indica el inicio de transacción a través del API que se comunica con el TP
Monitor.
Cada acción que tenga que ver con un administrador de recursos se controla en
el TP Monitor, la cual se controla y direcciona a través de XOpen/XA. Cuando la
aplicación cliente indica la confirmación (commit) o reversión (rollback) el TP
Monitor coordina la ejecución o reversión en los administradores de recursos
involucrados.
3.2.1. Compromiso de 2 Fases (2-Phase Commit)
Dada la naturaleza de la participación de administradores de recursos

distribuidos a través de la red, donde cada uno también ofrece el control de la
transacción local, que en suma darán la transacción distribuida; la operación de
confirmación (COMMIT) también se complica. De hecho, surge el concepto de
Commit de 2 Fases (a veces traducido como compromiso o confirmación de 2
fases).
A partir de 1980, cada vez más fue requerido los procesos de commit y rollback en los
administradores de bases de datos. Al finales de los 80’s, el requerimiento de
transacción trascendió a ser distribuido con el objetivo de brindar integridad y
consistencia en la información.

De tal forma surge el Commit de 2 Fases, buscando la confirmación de la

transacción distribuida con la sincronización de todos los administradores de
recursos involucrados ya sea en commit o rollback. Req uiere de un elemento
coordinador de transacciones distribuidas en cada uno de los nodos que tenga un
administrador de recursos.
La primera fase de denomina de Preparación, el nodo que inicia la transacción

se convierte en el agente coordinador de la transacción, o también, se le
denomina coordinador global. Todos los administradores de recursos van abren
una transacción local aplicando las acciones solicitadas; quedando pendiente la
confirmación hasta que se concluyan todas las acciones involucradas en la
transacción.

En la segunda fase, ya una vez recibida la ejecución de las acciones por los
administradores de recursos quedando pendiente la confirmación local en cada uno.
Se manda la orden de confirmación en todos los administradores de recursos
para que confirmen. Si un administrador de recursos provoca un error, el
administrador de transacciones manda la señal de reversión a los
administradores de recursos que anteriormente habían tenido éxito, cada uno de
estos revierten su transacción local.
Todo el proceso de administración de transacción distribuida es transparente y

automático, para ello se emplean Tablas de Transacciones Pendientes y
Bitácoras (logs).

Actualmente muchos productos ofrecen el control transaccional y el soporte al

commit de 2 fases. Lo esperado es que haya transparencia en la aplicación,
pero algunos productos sólo permiten la programación específica, reduciendo en
forma importante la transparencia y automatización en la administración de
transacciones.
Actualmente se considera madura la tecnología de administración de

transacciones distribuidas. Al grado de utilizarse en aplicaciones críticas de
negocio como de tipo financiero, bancarios, etc.

Entre algunas de las limitaciones de la administración de transacciones

distribuidas son los esquemas propietarios de los algoritmos y en XOpen/XA no hay
un soporte de todos los proveedores, así como un diseño de origen basado en un API
de programación estructurada.
3.3. CORBA
CORBA
Escenario

¿Qué es CORBA?
 CORBA es un middeware o marco de trabajo estándar y abierto de
objetos distribuidos que permite a los componentes en la red ínter
operar en un ambiente común sin importar el lenguaje de desarrollo,
sistema operacional, tipo de red, etc.
 En esta arquitectura, los métodos de un objeto remoto pueden ser
invocados de forma transparente en un ambiente distribuido y
heterogéneo a través de un ORB (Object Request Broker).
 Además del objetivo básico de ejecutar simplemente métodos en
objetos remotos, CORBA adiciona un conjunto de servicios que
amplían las potencialidades de éstos objetos y conforman una
infraestructura sólida para el desarrollo de aplicaciones críticas de
negocio.
Arquitectura General de CORBA

Organización General de un Sistema

de CORBA
Proceso del Cliente Proceso del Servidor
Referencia Implementación
del Objeto del Objeto
IDL DSI
Skeleton
IDL DII ORB
Stubs Interface Object Adapter
ORB
IIOP (Internet Inter ORB Protocol)
Descripción de elementos
 ORB: Provee un mecanismo de interfaz y de comunicación transparente entre
la referencia de un objeto y su implementación. Ofrece los
servicios de localización, establecimiento de la conexión y la transmisión de
llamadas de métodos y valores de retorno.
 IIOP: Protocolo para la comunicación entre ORBs a través de TCP/IP. El ORB
se comunica a través de IIOP sin intervención del desarrollador.
 IDL (Interface Definition Language): Se utiliza para definir la interfaz para un
Objeto CORBA, independiente del leng uaje en que está desarrollado. Utiliza el
mecanismo de stub -skeleton (acopladores).
 Object Adapters: Proveen la implementación de tiempo de ejecución de las
siguientes responsabilidades:
o Generar e interpretar referencias de objetos. o
Invocar métodos.
o Garantizar la seguridad de las aplicaciones. o
Activar y desactivar objetos.
o Enlazar las referencias de objetos con las implementaciones.

Descripción de elementos
o Registrar las implementaciones de objetos.
 DII (Dynamic Invocation Interface): El DII permite al cliente aprender en
tiempo de ejecución las operaciones soportadas por el servidor y crear solicitudes,
sin stub, que son enviadas directamente al ORB.
 DSI (Dynamic Skeleton Interface): Contraparte de DII, permite al servidor
implementar una interfase no conocida en tiempo de ejecución, sin
intervención del Skeleton.
Procesos Cliente y Servidor

 Cliente CORBA
o Stubs del IDL del Cliente
o Inicializando el ORB
o Usando el Servicio de Nombres
o Invocando los Métodos Remotos
o Usando los Parámetros Out e Inout
 Servidor CORBA
o Skeleton del IDL del Servidor
o Implementación de Objetos CORBA
o Objetos CORBA y el Servicio de Nombres
o Esperando por la Invocación
o Usando los Parámetros In e Inout.

Escenario CORBA
Mediante la técnica de Estudio de Caso, los alumnos realizarán en equipo las
actividades siguientes:
 Investigar de forma individual el funcionamiento de CORBA.

o Su relación con los lenguajes de programación.
o Ejercitar con un ejemplo de implementación.
 Discutir en equipo las investigaciones individuales.
o General reporte de discusión.
Actividad 3.3
Estudio de Caso CORBA (Escenario CORBA)
Realizar investigación individual y colocar en Tarea Individual 3.3
Discutir en equipo las investigaciones y colocar reporte en Tarea en Equipo 3.3.

Utilice como apoyo el Foro CORBA.
Se anexa Material de Apoyo 3.3.

Rúbrica para evaluación de tareas del proceso de EC
Puntos de
Arriba del En el Debajo del
Atributos Atributo
Estándar Estándar Estándar
Obtenidos
(5 -4.5) (4 -3.5) (3-0)
Sus
Participación,
Sus intervenciones
pero sus
intervenciones mostraron
intervenciones
mostraron relación con
no estaban
bastante el escenario,
Definición del relacionadas
relación con pero no
Problema con el
el escenario y lograron
escenario ni
fueron la base aterrizarlas
condujeron
para abordar del todo para
para abordar
el problema. abordar el
el problema.
problema.
(10 -9 ) (8.5 -7) (6.5-0)
La La
La
información información
información
revisada revisada
revisada no
Aplicación de la permitió a los permitió a los permitió a los
estudiantes estudiantes
Información estudiantes
comprender comprender
comprender el
con claridad parcialmente
ejercicio de
el ejercicio de el ejercicio de
algoritmos.
algoritmos. algoritmos.
(5 -4.5) (4 -3.5) (3-0)
Su aportación Hizo
fue bastantes Hizo pocas
determinante aportaciones, aportaciones
para la pero le falto y sin relación
Solución/explicación
del problema elaboración aterrizarlas en con las
del reporte propuestas posibles
final de la concretas de soluciones del
solución del solución al problema.
problema. problema.

3.3 CORBA
3.3.1 Introducción
El Object Management Group (OMG) es un consorcio integrado por varias

industrias importantes, que ha desarrollado CORBA (Common Request Broker
Architecture). CORBA ofrece servicios de interoperabilidad e interconexión de
objetos. Los servicios de interoperabilidad e interconexión son normalmente
conocidos como servicios middleware.
Servicios Middleware
Para resolver los problemas inherentes a sistemas heterogéneos y distribuidos,

que dificultan la implementación de verdaderas aplicaciones empresariales, los
proveedores de software están ofreciendo interfaces de programación y
protocolos estándares. Estos servicios se denominan usualmente servicios
middleware, porque se encuentran en una capa intermedia, por encima del
sistema operativo y del software de red y por debajo de las aplicaciones de los
usuarios finales.
Un servicio middleware es un servicio de propósito general que se ubica entre

plataformas y aplicaciones. Por plataformas se entiende el conjunto de servicios
de bajo nivel ofrecidos por la arquitectura de un procesador y el conjunto de
API´s de un sistema operativo. Como ejemplos de plataformas se pueden citar:
Intel x86 y Win-32, Sun SPARCStation y Solaris, IBM RS/6000 y AIX, entre
otros.
Un servicio middleware está definido por las API´s y el conjunto de protocolos

que ofrece. Pueden existir varias implementaciones que satisfagan las
especificaciones de protocolos e interfaces. Los componentes middleware se
distinguen de aplicaciones finales y de servicios de plataformas específicas por
cuatro importantes propiedades:
 Son independientes de las aplicaciones y de las industrias para las que

éstas se desarrollan.
 Se pueden ejecutar en múltiples plataformas.
 Se encuentran distribuidos.
 Soportan interfaces y protocolos estándar.
CORBA es el estándar propuesto por el OMG. EL OMG fue fundado en 1989 y

es el más grande consorcio de industrias de la actualidad, con más de 700
compañías. Opera como una organización no comercial sin fines de lucro, cuyo

objetivo es lograr establecer todos los estándares necesarios para lograr

interoperabilidad en todos los niveles de un mercado de objetos.
Originalmente los esfuerzos de la OMG se centraron en resolver un problema

fundamental: cómo lograr que sistemas distribuidos orientados a objetos
implementados en diferentes lenguajes y ejecutándose en diferentes plataformas
interactúen entre ellos. Más allá de los problemas planteados por la computación
distribuida, problemas más simples como la falta de comunicación entre dos
sistemas generados por compiladores de C++ distintos que corren en la misma
plataforma frenaron los esfuerzos de integración no bien comenzados. Para
opacar aún más el escenario, distintos lenguajes de programación ofrecen
modelos de objetos distintos. Los primeros años de la OMG estuvieron
dedicados a resolver los principales problemas de cableado. Como resultado se
obtuvo la primera versión del Common Object Request Broker, publicado en
1991. Hoy en día, el último estándar aprobado de CORBA está por la versión
2.3, y la versión 3.0 está a punto de ser lanzada.
Desde sus principios, el objetivo de CORBA fue permitir la interconexión abierta

de distintos lenguajes, implementaciones y plataformas. De esta forma, CORBA
cumple con las cuatro propiedades enumeradas como deseables de los
servicios middleware. Para lograr estos objetivos, la OMG decidió no establecer
estándares binarios (como es el caso de COM); todo está estandarizado para
permitir implementaciones diferentes y permitir que aquellos proveedores que
desarrollan CORBA pueden ofrecer valor agregado. La contrapartida es la
imposibilidad de interactuar de manera eficiente a nivel binario. Todo producto
que sea compatible con CORBA debe utilizar los costosos protocolos de alto
nivel.
CORBA está constituido esencialmente de tres partes: un conjunto de interfaces

de invocación, el ORB (object request broker) y un conjunto de adaptadores de
objetos (objects adapters). CORBA va más allá de simples servicios
middleware, provee una infraestructura para construir aplicaciones orientadas a
objetos. Las interfaces definen los servicios que prestan los objetos, el ORB se
encarga de la localización e invocación de los métodos sobre los objetos y el
object adapter es quien liga la implementación del objeto con el ORB.
Para que las interfaces de invocación y los adaptadores de objetos funcionen

correctamente, se deben cumplir dos requisitos importantes. En primer lugar, las
interfaces de los objetos deben describirse en un lenguaje común. En segundo
lugar, todos los lenguajes en los que se quieran implementar los objetos deben
proveer un mapeo entre los elementos propios del lenguaje de programación y el
lenguaje común. La primera condición permite generalizar los mecanismos de
pasaje de parámetros (marshaling y unmarshaling). La segunda permite
relacionar llamadas de o a un lenguaje en particular con el lenguaje de
especificación común. Este lenguaje común fue una parte esencial de CORBA

desde sus orígenes y es conocido como el OMG IDL: Interfaz Definition

Language. Existen mapeos del OMG IDL a C, C++, Java y Smalltalk.
El desarrollo basado en componentes
El desarrollo basado en componentes que se puedan comprar y poner en

marcha sin mayores dificultades (Plug & Play) es una meta a alcanzar que
facilitaría la reutilidad de software. En esta sección se hace una breve
introducción al desarrollo basado en componentes y el rol que le compete a
CORBA en este ámbito.
Un componente ha sido definido en la European Conference on Object

Oriented Programming (ECOOP) de 1996 como una “una unidad de
composición con interfaces contractuales especificadas y dependencias de
contexto explícitas.” Un componente de software puede ser desarrollado
independientemente y utilizado por terceras partes para integrarlo mediante
composición a sus sistemas.” Los componentes son para crear software
utilizando composición, por eso es esencial que sean independientes y que se
presenten en formato binario, permitiendo así distintos vendedores e integración
robusta.
Para que un componente pueda ser integrado por terceras partes en sus
sistemas, éste deber ser suficientemente auto contenido y debe proveer una
especificación de lo que requiere y provee. En otras palabras, los componentes
deben encapsular su implementación e interactuar con otros componentes a
través de interfaces bien definidas.
Un componente no es un objeto. A diferencia de los objetos, los componentes no

tienen estado. Esto quiere decir que un componente no puede distinguirse de
una copia de sí mismo. Un componente puede tomar la forma de un archivo
ejecutable o una biblioteca dinámica que usualmente cobra vida a través de
objetos, pero no es este un requisito indispensable. De hecho, los primeros
componentes conocidos (aunque en su momento no se los haya definido así)
fueron las bibliotecas de procedimientos. Sin embargo, los objetos, con sus
características de encapsulamiento y polimorfismo, facilitan la construcción e
integración de componentes.
Y al hablar de objetos vale la pena distinguir aquí los objetos de las clases. Una clase
es una definición de propiedades y funcionalidades ha ser provistas por los objetos. A
partir de una clase es posible la instancia objetos. Los componentes pueden
contener una o más clases y serán los clientes de los componentes quienes
soliciten la creación de las instancias de estas clases.
Pero tomando el lugar del programador que debe integrar el componente a su

aplicación, surgen algunas incógnitas que debería resolver. El fabricante del

componente solamente ha entregado un archivo ejecutable que se debe iniciar

en la máquina en la que se ejecuta la aplicación y la interfaz definida en un
lenguaje de definición de interfaces (IDL, Interface Definition Language)
estándar. El programador desea ahora:
 Mapear la interfaz: ¿Cómo hace el programador para mapear las clases

que el componente provee al lenguaje en que realizará su
implementación final? Seguramente el lenguaje de programación elegido
provee mecanismos para definir clases, pero es necesario que la
definición que se haga de la clase en ese lenguaje corresponda a la
definición que dio el fabricante del componente.
 Crear objetos: ¿Cómo hace el programador para crear una instancia del
objeto Venta? Es necesario que exista un mecanismo para indicar al
componente que cree una instancia del objeto Venta. Una vez creada la
instancia ¿Cómo se logra acceder a sus propiedades o métodos?
 Transparencia: El componente sería de poca utilidad si su utilización no

fuera transparente. Si para cada llamada al componente el programador
tiene que utilizar un servicio del sistema operativo de llamada entre
procesos (IPC), o peor aún si el componente es remoto, un servicio de
llamada remota a procedimientos (RPC), está claro que dejaría el
componente de lado pues es más trabajo utilizarlo que hacer un programa
desde cero.
Estas son sólo algunas de las cuestiones que el programador tendrá que
resolver para poder utilizar el componente. En el caso de que el programador
llegara a comprar otro componente, es seguro que desea que los mecanismos
de utilización sean uniformes para no tener que resolverlas nuevamente. Los
servicios middleware que provee CORBA buscan resuelven estos problemas.
3.3.2 Generalidades de CORBA
CORBA es un Middeware o marco de trabajo estándar y abierto de objetos

distribuidos que permite a los componentes en la red ínter operar en un
ambiente común sin importar el lenguaje de desarrollo, sistema operacional, tipo
de red, etc. En esta arquitectura, los métodos de un objeto remoto pueden ser
invocados “transparentemente” en un ambiente distribuido y heterogéneo a
través de un ORB Object Request Broker). Además del objetivo básico de
ejecutar simplemente métodos en objetos remotos, CORBA adiciona un conjunto
de servicios que amplían las potencialidades de éstos objetos y conforman una
infraestructura sólida para el desarrollo de aplicaciones críticas de negocio.
CORBA es la respuesta del “Grupo de Gestión de Objetos” (Object

Management Group - OMG) a la necesidad de interoperabilidad ante la gran
proliferación de productos hardware y software. CORBA permite a una

aplicación comunicarse con otra sin importar el tipo de red, protocolo, sistema
operacional o lenguaje de desarrollo.
CORBA automatiza muchas tareas comunes y “pesadas” de programación de

redes tales como registro, localización y activación de objetos; manejo de
errores y excepciones; codificación y decodificación de parámetros, y protocolo
de transmisión.
En un ambiente CORBA, cada Implementación de Objeto, define bien su Interfaz

a través una especificación normalizada conocida como IDL (Interface
Definition Language) a través de la cual en forma Estática (en el momento de
compilación) o en forma Dinámica (en el momento de ejecución) un Cliente que
requiera el servicio de una Implementación de Objeto, puede ser ejecutada. Las
invocaciones a métodos remotos son enviadas por los clientes llamando objetos
locales llamados “Stubs” (generados por un compilador de IDL - Estático), el
cual intercepta dichas invocaciones y continúa el proceso de llevar y retornar
automáticamente dicha invocación. La Implementación del objeto, no tiene que
conocer el mecanismo por el cual un Cliente le ha invocado un servicio.
Cuando el Cliente y una Implementación de Objeto están distribuidos por una red,
usan el protocolo GIOP/IIOP suministrado por la arquitectura para lograr la
comunicación.
La forma en cómo una Implementación de Objeto (desarrollada por un

programador de aplicaciones) se conecta a un ORB, es a través de un
Adaptador de Objetos. Este adaptador recibe las peticiones por la red e invoca los
servicios a la implementación correspondiente.
Actualmente CORBA ya ha resuelto los problemas fundamentales de

interoperabilidad y comunicación entre objetos y se han definido y especificado un
conjunto de servicios comunes requeridos para la construcción de las
aplicaciones, pero donde hay gran actividad es en la especificación de objetos
comunes por dominio de aplicación o conocidas en CORBA como Interfaces de
Dominio. Allí se trabajan en áreas como Telecomunicaciones, Medicina,
Finanzas, Manufactura, etc.
CORBA esta fundamentado en dos modelos: un modelo de objetos, el cual

agrega todas las características de Orientación por Objetos como Tipos de
Datos, Abstracción, Polimorfismo y Herencia y un modelo de referencia o
arquitectura conocida como OMA (Object Management Architecture).
3.3.3 Object Management Group (OMG)
La OMG fue fundada en abril de 1989 por 11 compañías, en octubre de 1989, la

OMG comenzó operaciones independientes como una entidad sin ánimo de
lucro. A través de sus comités, la OMG desarrolla especificaciones

independientes de cualquier proveedor para la industria del software.

Actualmente el consorcio tiene más de 800 miembros. La OMG se esta
moviendo a establecer a CORBA como el “Middleware que esta en todas
partes” a través de sus especificaciones CORBA/IIOP, Servicios de Objetos,
Facilidades de Internet y Especificaciones de Dominio, entre otras.
La misión de la OMG es crear un mercado de software basados en

componentes introduciendo las tecnologías de objetos. Establecer guías y
especificaciones para proveer un marco común para el desarrollo de
aplicaciones. Conforme a estas especificaciones, será posible desarrollar en
ambientes heterogéneos a través de la gran variedad de productos hardware y
software existente.
La OMG define la administración de objetos como el desarrollo de software que

modela el mundo real a través de la representación de “objetos”. Estos objetos son
la encapsulación de los atributos, relaciones y métodos de software
identificables como compo nentes de un programa. La administración de objetos
facilita el desarrollo rápido de aplicaciones, facilidad de mantenimiento,
escalabilidad y reutilidad del software.
La OMG esta estructurado en tres grandes cuerpos: el Comité de Plataforma

Tecnológica (Platform Technology Committee - PTC), el Comité de Dominio
Tecnológico (Domain Technology Committee - DTC) y la Junta de Arquitectura
(Architecture Board). Dentro de los Comités Técnicos y Junta de Arquitectura,
trabajan las Fuerzas de Trabajo, Grupos de Interés Especial y Grupos de
Trabajo quienes llevan a cabo los procesos de adopción tecnológica de la OMG.
3.3.4 Object Management Architecture - OMA
Una de las metas principales de la arquitectura OMA, es introducir las

tecnologías orientadas a objetos como soporte a la nueva generación de
aplicaciones y sistemas distribuidos, por ello, un esquema de administración de
objetos representa los siguientes beneficios:
Interfaces de usuario orientadas a objetos.

Funcionalidades comunes en diferentes aplicaciones, tal como almacenamiento
y recuperación de objetos, correo de objetos, impresión, creación y borrado de
objetos.
Compartir información, desde el punto de vista de acceso múltiple a través de
aplicaciones.
La transición a un esquema orientado por objetos no quiere decir que las
aplicaciones existentes son obsoletas. Las aplicaciones existentes pueden ser
incorporadas en un ambiente orientado por objetos.
El Modelo de Objetos

Provee una representación organizada de los conceptos y terminología de

objetos. El modelo de la OMG es abstracto en el sentido que directamente no
realiza una tecnología particular, el modelo descrito aquí es un modelo de
objetos concreto.
Un sistema de objetos es una colección de objetos que aíslan las peticiones de

servicios (cli entes) de la provisión de los servicios por el encapsulamiento de las
interfaces.
El modelo de objetos es un ejemplo del modelo clásico de objetos, donde un

cliente envía un mensaje a un objeto. Conceptualmente, el objeto interpreta el
mensaje para decidir que servicio ejecutar. En este modelo, la selección de
métodos es ejecutada por el objeto o por el ORB.
Semántica de Objetos
Un sistema de objetos provee servicios a clientes. Un cliente de un servicio es

cualquier entidad capaz de requerir servicios.
Conceptos relevantes a un cliente:
Objeto: un objeto es una entidad identificable y encapsulada que provee uno o más
servicios que pueden ser requeridos por un cliente.
Requerimientos: los clientes solicitan un servicio enviando un requerimiento. Un

requerimiento es un evento. La información asociada a este evento consiste en
una operación, objeto destino, cero o más parámetros y contextos opcionales del
requerimiento.
Creación y Destrucción de Objetos
Aunque los objetos pueden ser creados o destruidos, desde el punto de vista del
cliente no existen mecanismos especiales para la creación o destrucción.
Tipos
Un tipo es una entidad identificable con un predicado asociado definido sobre

valores. Un valor satisface un tipo si el predicado es verdadero para este valor. Un
valor que satisface un tipo es llamado un miembro del tipo.
Un tipo de objeto es un tipo cuyos miembros son objetos. En otras palabras, un tipo
objeto es satisfecho solo por objetos.
 Tipos básicos: Enteros de 16 y 32 bits con y sin signo, números IEEE de

punto flotante de 32 y 64 bits, caracteres ISO Latin-1 (8859.1), booleano,

opaco de 8 bits, enumerados, string de longitud variable y tipo any el cual

representa cualquier posible tipo básico o construido.
 Tipos complejos: estructuras, uniones, secuencias, arreglos, interfaces,

etc.
Interfaces
Una Interfaz es una descripción de un conjunto de posibles operaciones que un

cliente puede requerir de un objeto. Un objeto satisface una Interfaz si este
puede ser especificado como el objeto destino en cada requerimiento potencial
descrito por la Interfaz.
Un tipo de Interfaz es un tipo que es satisfecho por cualquier objeto que

satisface una Interfaz particular.
Las Interfaces en OMG son especificadas en IDL (Interface Definition

Language). La herencia de Interfaces provee los mecanismos para permitir a un
objeto soportar múltiples Interfaces. La Interfaz principal es simplemente la
Interfaz más especifica que el objeto soporta y consiste en todas la operaciones en la
transitive closure del grafo de herencia de Interfaz.
Operaciones
Una Operación es una entidad identificable que denota un servicio que puede ser
requerido. Una operación es identificada por un identificador de operación y tiene
una firma que describe los valores legítimos de los parámetros requeridos y
resultados retornados.
Las excepciones son una indicación que un requerimiento de operación no ha

ejecutado exitosamente.
Un contexto de requerimiento provee información adicional y especifica de la

operación que puede afectar el rendimiento de un requerimiento.
Semántica de ejecución
Dos estilos de semántica de ejecución son definidos para el modelo de objeto:
 Al menos una vez: si un requerimiento de operación retorna

exitosamente, este fue ejecutado exactamente una sola vez, si este
retorna una indicación de excepción, este fue ejecutado al menos una
vez.

 Mejor esfuerzo: una operación de mejor esfuerzo es una operación de

requerimiento único, este no puede retornar cualquier resultado y el
solicitante nunca se sincroniza con la terminación.
Atributos
Una Interfaz puede tener atributos. Un atributo puede ser sólo lectura o
lecturaescritura.
Implementación de objetos
El modelo de implementación consiste en dos partes: el modelo de ejecución y

el modelo de construcción. El modelo de ejecución describe como los servicios
son ejecutados y el modelo de construcción describe como los servicios son
definidos.
 Modelo de ejecución: el servicio requerido es ejecutado en un sistema

computacional por ejecución de un código que opera sobre los mismos
datos. El código que es ejecutado para realizar un servicio es llamado
método. Un método es una descripción inmutable de una computación
que puede ser interpretada por el motor de ejecución. Un método tiene
unos atributos inmutables llamados "formato de método" que define el
conjunto de máquinas de ejecución que pueden interpretar el método. Un
motor de ejecución es una máquina abstracta (no un programa) que
puede interpretar métodos en ciertos formatos, causando que las
computaciones descritas sean realizadas. Un motor de ejecución define
un contexto dinámico para la ejecución de un método. La ejecución de un
método es llamada "activación de método".
 Modelo de construcción: una implementación de objeto o implementación

es una definición que provee la información necesaria para crear un
objeto y permitir al objeto participar en proveer un apropiado conjunto de
servicios. Una implementación típicamente incluye, entre otras cosas, la
definición de los métodos que operar sobre el estado de un objeto.
también incluye información acerca de los tipos intended del objeto.
Elementos de OMA
 Object Request Broker - ORB: representa el medio o bus de objetos a

través del cual se comunican todos los objetos participantes en el
sistema. El ORB es el corazón de comunicaciones del estándar. Este es
referido comercialmente como CORBA. Este provee una infraestructura
que permite a objetos comunicarse, independiente de la plataforma
especifica y técnicas usadas para implementar el objeto direccionado. El

ORB garantiza portabilidad e interoperabilidad de objetos sobre una red de

sistemas heterogéneos.
 Objetos de Servicio - CORBAServices, son un conjunto de objetos

genéricos, que son usados por muchos programas distribuidos, como
soporte a tareas muy comunes. Actualmente se tienen definidos los
siguientes objetos de servicio: Nombres, Ciclo de Vida, Persistencia,
Seguridad, Consulta, Propiedades, Transacciones, Eventos, Tiempo y
Negociador entre otros.
 Objetos de Dominio - CORBADomain, es un conjunto de objetos que

son comunes y estándares dentro de un dominio o mercado de
aplicación, se cuentan con dominios como: Telecomunicaciones,
Finanzas, Comercio Electrónico, Medicina, Transportes, Transportes, etc.
 Facilidades Comunes - CORBAFacilities, conjunto de objetos

orientados hacia las aplicaciones de usuario final como Administración de
Datos, Aplicaciones, Interfaces de Usuario, etc.
Objetos de Aplicación: son desarrollados por el programador. La
figura muestra los elementos de OMA.
3.3.5 Object Request Broker - ORB
El Object Request Broker (ORB) es el middleware que establece las

relaciones cliente/servidor entre objetos. Usando un ORB, un cliente puede
transparentemente invocar un método sobre un objeto remoto. El ORB
intercepta la llamada y es responsable de encontrar el objeto que implementa el
requerimiento, pasar los parámetros, invocar el método y retornar el resultado.
El cliente no tiene que preocuparse de donde esta implementado el objeto, su

lenguaje de desarrollo, sistema operacional o tipo de red. De esta forma el ORB

provee la interoperabilidad entre aplicaciones sobre diferentes máquinas en un

ambiente heterogéneo distribuido.
En el esquema actual de aplicaciones cliente/servidor, los desarrolladores usan

su propio diseño o un “estándar” para definir el protocolo a ser usado entre los
dispositivos. La definición de ese protocolo depende del lenguaje de
implementación, transporte de red y otros factores. Un ORB simplifica este
proceso, por ejemplo el protocolo es definido a través de una especificación de
las Interfaces conocida como IDL. Una vez se tiene claro las Interfaces, el
lenguaje de implementación o sistemas operacionales y de red, ya no es
relevante.
La especificación IDL de OMG provee una forma estándar de definir las

Interfaces a los objetos CORBA. La definición IDL es una especie de contrato entre
el desarrollador de un objeto y el cliente. IDL es independiente del lenguajes
de programación y se mapea a los lenguajes más típicos para desarrollar,
actualmente se encuentra generación de código a C, C++, SmallTalk, Java,
Ada, COBOL, etc.
Más importante aún, una solución basada en ORB, permite integrar aplicaciones
existentes, simplemente describiendo sus Interfaces en IDL y escribiendo los
"wrappers" que traslada entre el bus estandarizado y las Interfaces existentes.
Lo que permite en el ORB la interoperabilidad e independencia de muchos

factores, es la definición de los objetos en un lenguaje de especificación
totalmente independiente del lenguaje de implementación, este lenguaje se
conoce como Interface Definition Language (IDL)
Elementos de un ORB
Implementación del Objeto: realizado por el programador. Implementa las

operaciones especificadas en la definición IDL. La implementación puede ser
escrita en una variedad de lenguajes como C, C++, Java, SmallTalk, Ada, etc.
Cliente: entidad que invoca una operación en una Implementación de Objeto

remoto. De igual forma puede ser desarrollado en varios lenguajes y es
realizado por un programador de aplicaciones.
Núcleo ORB: provee mecanismos para transportar de manera

transparentemente requerimientos de Clientes hacia Implementaciones de
Objeto remotos. Es responsable de interceptar todas las llamadas del cliente,
localizar el objeto, codificar y enviar el requerimiento y esperar a respuesta, la cual
es retornada al Cliente.

Interfaz ORB : ofrece varias funciones de ayuda, tales como conversión de

referencia de objetos a texto y viceversa, creación de lista de argumentos para
invocación DII, entre otras.
Stubs y Skeleton IDL: Los stubs y skeleton sirven como “pegante” entre el
cliente y servidor respectivamente y el ORB. Son estáticos y generados en
tiempo de compilación por un compilador IDL el cual transforma las Interfaces IDL
hacia el lenguaje de desarrollo, esto reduce las posibilidades de errores al generar
automáticamente los stubs y skeleton.
Interfaz de Invocación Dinámica (DII): esta Interfaz permite a un cliente construir

dinámicamente un requerimiento sin tener un stub, lo cual significa que los
requerimientos son construidos en tiempo de ejecución. Otra ventaja de este
esquema es permitir llamadas sincrónicas de no bloqueo (deferred) y llamadas
asincrónicas de una sola vía (oneway)
Interfaz Skeleton Dinámica (DSI): cumple las mismas funciones de DII pero en el lado
del servidor. Permite que el ORB realice llamadas a una Implementación de Objeto
del cual no se tiene conocimiento de la Interfaz.
Adaptador de Objetos: este módulo asiste al ORB con la entrega de

requerimientos a los objetos y con la activación de objetos de acuerdo a varias
políticas. Un adaptador de objetos asocia una implementación de objetos con el
ORB. Actualmente se tienen definidos dos tipos de adaptadores: BOA (Basic
Object Adaptor) y POA (Portable Object Adaptor).
La figura muestra los elementos de un ORB.

Un ORB no tiene que ser implementado como un componente único. Las

Interfaces que ofrecen los ORB están organizadas en 3 categorías:
Operaciones para todas las implementaciones de ORB

Operaciones especificas a tipos particulares de Objetos
Operaciones especificas a estilos particulares de implementación de objetos.
El núcleo del ORB es el componente que provee la representación básica de

objetos y la comunicación de requerimientos.
Un cliente tiene acceso al objeto a través de una “Re ferencia al Objeto”, el

cliente solo conoce la Interfaz que este objeto tiene con el entorno.
Los clientes generalmente “ven” los objetos y el ORB bajo la perspectiva de un

lenguaje mapeado, trayendo el ORB a niveles del programador.
Una variedad de Implementaciones de Objetos se pueden soportar en CORBA,

incluyendo servidores separados, librerías, un programa por método, una
aplicación encapsulada, una base de datos orientada a objetos, etc.
Referencias de Objeto
Es la información necesaria para especificar un objeto dentro de un ORB. Tanto los

clientes como las implementaciones del objeto tienen una noción “opaca” de la
referencia de objeto de acuerdo al lenguaje de mapeo y así aislar la
representación real de estos.
Dos ORB pueden diferir en la elección de la representación de las Referencias de

Objeto.
Lenguaje de especificación de Interfaces
IDL es la forma de especificar las Interfaces de un objeto en el ambiente

CORBA. De estas defunciones en IDL, es posible mapearlos a una variedad de
lenguajes de programación o sistemas de objetos.
Este lenguaje de mapeo también define la interacción entre la invocación de los

objetos y los hilos de control en el cliente o implementación.
El lenguaje de mapeo provee llamadas sincrónicas, es decir, no retorna hasta que

se termine de ejecutar el método en la implementación del objeto.
Adaptador de objeto
Es la forma principal para acceder los servicios de una implementación de objeto

provistos por el ORB.

Los servicios provistos por el ORB a través de un Adaptador de Objetos incluye:

generación e interpretación de referencia de objetos, invocación de métodos,
seguridad de interacciones, activación/desactivación de objetos e
implementaciones, mapeo de referencias de objeto a implementaciones y
registro de implementaciones.
Un adaptador de objetos exporta una interfaz pública a la implementación del

objeto y una privada al skeleton.
Es responsable de las siguientes funciones:
 Generación e interpretación de referencias de objetos

 Invocación de métodos
 Seguridad de interacciones
 Activación/desactivación de objetos e implementaciones
 Mapeo de referencias de objeto a las correspondientes implementaciones
de objeto
 Registro de implementaciones
Ejemplos de Adaptadores de Objetos:
Basic Object Adapter: define una especificación que puede ser usada por
muchos objetos ORB con implementaciones convencionales. Para este
adaptador, las implementaciones son generalmente programas separados. Esto
permite activar un programa por: método, objeto y compartido para todas las
instancias del tipo de objeto. Si la implementación no esta activa, el BOA
comienza una.
Library Object Adapter: es utilizado por los objetos que tienen
implementaciones de librerías. Este accede el almacenamiento persistente en
archivos y no soporta activación o autenticación, ya que los objetos se asume que
están en los clientes.
Object-Oriented Database Adapter: usa una conexión a una OODB para
proveer acceso a los objetos almacenados. Los objetos pueden ser registrados
implícitamente.
Interfaz ORB
Son las Interfaces que directamente llegan al ORB y que son las mismas para
todas las implementaciones de ORBs y que no depende de la Interfaz de un
objeto o adaptador. Ya que muchas de las funcionalidades del ORB son
provistas a través del adaptador de objetos, stubs, skeleton o invocación
dinámica; quedan pocas operaciones comunes a través de todos los objetos.
Repositorio de Interfaces

Es un servicio que provee objetos persistentes que representan la información IDL

en forma disponible en tiempo de ejecución. También el IR es un lugar común
para almacenar información adicional asociada con Interfaces al ORB. (ej: debug,
librerías de stubs/skeleton, etc.).
Repositorio de implementación
Contiene información que permite al ORB localizar y activar implementaciones de

objetos, aunque esta información es muy dependiente de la implementación del ORB
o del ambiente operativo.
Ejemplos de implementaciones de ORB
Cliente e Implementación residen en el ORB: Si hay un mecanismo adecuado de

comunicaciones, un ORB puede ser implementado en rutinas residentes en el
cliente e implementaciones. Los stubs en el cliente pueden utilizar un esquema de
IPC o directamente acceder la localización de un servicio. El código enlazado con las
implementaciones es responsable de configurar las bases de datos apropiadas
para uso de los clientes
ORB basado en Servidor: administración centralizada. Todos los clientes e
implementaciones pueden comunicarse con uno o más servidores cuya función es
enrutar los requerimientos de clientes a implementaciones. Se utilizan IPC para
comunicación hacia el ORB .
ORB basado en sistema: para mejorar la seguridad, robustez y rendimiento, el

ORB puede ser provisto como un servicio del Sistema Operacional, pueden
existir optimizaciones como evitar el marshalling cuando ambos están en la
misma máquina.
ORB basado en librería: para objetos que son de “peso liviano” y cuyas
implementaciones pueden ser compartidas, la implementación del ORB podría
ser en una librería. En este caso, los stubs pueden ser los métodos reales. Esto
asume, que es posible para un cliente tener acceso a los datos para los objetos y que
la implementación confía en que el cliente no dañara los datos.
3.3.6 CORBA Services
OMA esta construida sobre un fundamento y arquitectura CORBA que desarrolla la

visión de la OMG de componentes de software plug-and-play.
Los CORBA Services especifican servicios básicos casi todos los objetos
necesitan.

Para cada componente de OMA, la OMG provee una especificación formal

descrita en OMG IDL (como invocar cada operación dentro de un objeto) y su
semántica en lenguaje inglés (que hace cada operación y las reglas de
comportamiento). Un proveedor no tiene que suministrar obligatoriamente
ningún servicio adicional al ORB, pero si este lo ofrece, deberá esta de acuerdo a la
especificación que para este servicio tiene la OMG.
Los CORBA Services proveen servicios a nivel de aplicación fundamentales

para las aplicaciones orientadas por objetos y componentes en entornos
distribuidos. La OMG ha definido alrededor de 15 servicios de objetos. Los
cuales son:
 Nombres  Persistencia
 Trader  Consulta
 Notificación  Relaciones
 Eventos  Concurrencia
 Transacciones  Externalización
 Seguridad  Licenciamiento
 Ciclo de vida  Tiempo
 Propiedades  Colección
De éstos 15 se destacan los siguientes servicios clave:
 Acceso a referencias de objetos a través de la red, soportada por el

servicio de Nombres y de Trader.
 Notificación de eventos importantes o cambios de estado en un objeto,
soportado por el servicio de Eventos y de Notificación.
 Soporte para semántica transaccional (two-phase commit y rollback)
soportado por el servicio de Transacciones.
 Soporte para seguridad, soportada por el servicio de Seguridad.
Nombres: permite a componentes descubrir otros componentes en un ambiente

distribuido, básicamente es un servicio de localización que asocia identificadores
a manejadores que proveen una forma de contactar el componente deseado en
un sistema distribuidos. Este asocia nombres - organizados jerárquicamente - a
objetos.
Ciclo de vida: básicamente es un servicio de configuración, define servicios y

convenciones para crear, borrar, copiar y mover componentes en un sistema
distribuido.
Eventos: implementa un modelo de comunicación desacoplado, basado en el

paradigma publicación/suscripción. En este modelo, uno o más publicadores
pueden enviar mensajes relacionados con un tópico específico, mientras que un
grupo de suscriptores reciben los mensajes asincrónicamente. Con estos

mecanismos, los publicadores pueden generar evento sin tener que conocer la
identificación de sus consumidores y viceversa. Hay dos acercamientos, modelo
Push y modelo Pull, en el modelo Push los publicadores toman la iniciativa de
iniciar la comunicación, en el modelo Pull, los suscriptores requieren eventos de
los publicadores.
Transacciones: gestiona interacciones entre objetos distribuidos estableciendo

puntos de Commit y delimitación de transacciones. Este servicio soporta varios
modelos y permite interoperabilidad entre diferentes arquitecturas de red y
modelos de programación.
Seguridad: controla la identificación de los elementos del sistema distribuido

(usuarios, objetos, componentes, etc) que permite verificar que un cliente esta
autorizado a acceder los servicios de una implementación remota.
Adicionalmente permite la comunicación segura sobre enlaces de comunicación
inseguros, ofreciendo confidencialidad e integridad de la información transmitida.
Tiempo: suministra información del tiempo y permite la definición de llamadas

periódicas.
Licenciamiento: controla la utilización de objetos específicos, inhibiendo uso

inadecuado de derechos y propiedad intelectual.
Propiedades: provee la habilidad de dinámicamente asociar propiedades a los

objetos los cuales pueden ser consultados o modificados por otros elementos.
Relaciones: permite la definición del papel ejecutado por objetos CORBA en una
relación.
Consulta : permite a los usuarios y objetos invocar operaciones de consulta sobre

colecciones de objetos.
Persistencia: provee mecanismos para retener y mantener el estado de objetos

persistentes.
Concurrencia: permite la coordinación de múltiples accesos a recursos

compartidos a través de la provisión de varios modelos de locks y permite
resolución flexible de conflictos.
Externalización: define convenciones y protocolos para representar el estado de

información relacionado a un objeto en la forma de una secuencia de datos,
permitiendo a esta información ser almacenada o transferida a otras
localizaciones.
3.3.7 CORBA Facilities Horizontales

Las facilidades CORBA tanto horizontales como verticales, son diseñadas para
completar la arquitectura entre los Servicios básicos de CORBA y las
aplicaciones específicas de industria. Con una arquitectura completa, las
compañías compartirán datos a nivel de aplicación y funcionalidades para la
integración de diferentes sistemas de información. Las facilidades representan
un punto medio entre una aplicación particular y los servicios y ORB.
La OMG ha definido como Facilidades Horizontales las siguientes:
 Interfaz de usuario
 Administración de información
 Administración de sistemas
 Administración de tareas
Hoy en día estas especificaciones han sido adheridas a ORBOS (ORB y

Servicios) y ya no están como un grupo aparte.
Específicamente a nivel de facilidades verticales la OMG ha definido las

siguientes:
Especificación para la administración de sistemas XCMF.

Facilidad para colar de impresión.
3.3.8 CORBA Facilities Verticales o de Dominio
La potencialidad que representa el lenguaje IDL para la especificación de un

objeto u componente ha permitido trabajar en la normalización de intereses
comunes para un sector de mercado particular y que una vez se llegue a un
acuerdo en cuanto a estas especificaciones, sería estándar dentro de este
mercado.
Para esto se ha creado el Domain Technology Committee (DTC) y esta a su

vez esta organizada en una serie de Domain Task Forces (DTF) los cuales
escriben documentos de requerimientos (RFI y RFP) para nuevas
especificaciones y evalúan y recomiendan especificaciones candidatas. Basados en
las recomendaciones de los DTF, el DTC conduce un proceso formal de votación
para asegurar que cumple todos los requerimientos del sector y no solo de quien haya
propuesto. Posteriormente estas recomendaciones requieren ser enviadas a la
Junta de Directores de la OMG para hacerla una especificación oficial. Actualmente
hay 8 DTF:
 Objetos de negocio
 Finanzas y seguros
 Comercio Electrónico
 Manufactura
 Salud o Medicina

 Telecomunicaciones
 Transportes
 Investigación de ciencias de la vida
También bajo la OMG pero que no tienen DTF se encuentran dos Grupos de Interés
Especial:
 Utilities (principalmente energía eléctrica)

 Estadística
Seis especificaciones ya han sido adoptadas oficialmente como estándares de

dominio vertical, ellos son:
 Facilidad Currency del DTF de Finanzas.

 Un conjunto de Habilitadores para la administración de datos de
productos, del DTF de manufactura.
 Servicio de Identificación de Personas (PIDS) de CORBAMed
 Servicio de Consulta Lexicon de CORBAMed
 Control y Administración de flujos de Audio/Vídeo, del DTF de
telecomunicaciones.
 Servicio de Notificación, del DTF de Telecomunicaciones.
3.3.9 Nuevas especificaciones de CORBA
Después que fue completada y normalizada la versión 2.0 en 1996, la OMG

continuo trabajando en la incorporación de aspectos importantes que deben ser
tenidos en cuenta en un sistema distribuido y ha ampliado su modelo de objetos para
incorporar aspectos como: múltiples Interfaces por objeto, paso de objetos por valor,
modelo de componentes, soporte para tiempo real y tolerancia a fallos entre otros.
CORBA 3.0 se refiere a una serie de nuevas especificaciones que unidas dan una
nueva dimensión a CORBA. Estas nuevas especificaciones están divididas en tres
categorías:
 Integración con Internet.

 Control de Calidad de Servicio
 Arquitectura de componentes CORBA
Por otro lado, han aumentado las especificaciones de mercados verticales, o lo

que en CORBA se conoce como Dominios Verticales y mediante la utilización de
IDL, existen muchos mercados estandarizando en CORBA (Finanzas, Seguros,
Comercio Electrónico, Medicina, Manufactura, Telecomunicaciones,
Transportes, Investigación y Objetos de Negocio).
A continuación se describen las características más importantes de los últimos

adelantos en CORBA 3.0:

Integración con Internet
Esta integración esta siendo desarrollada por la especificación “firewall”. La

especificación CORBA 3 define firewalls a nivel de transporte, de aplicación y
conexiones bidireccionales GIOP útiles para callbacks y notificación de eventos.
Los firewalls de transporte trabajan a nivel de TCP, para lo que la IANA ha

reservado los puertos bien conocidos 683 para IIOP y 684 para IIOP sobre SSL.
También hay una especificación de CORBA sobre SOCKS.
En CORBA es frecuente que un objeto invoque un método (callback) o notifique

de algún suceso a su cliente, por esto el objeto puede comportarse como cliente,
por esto generalmente se requiere abrir una nueva conexión TCP en sentido
inverso el cual puede ser detenido por un firewall. Bajo esta especificación, a
una conexión IIOP se le permite llevar invocaciones en el sentido inverso bajo
ciertas condiciones que no comprometan la seguridad de la conexión.
UML y MOF: Soporte para análisis y diseño
El modelado es una pieza clave en el desarrollo de software robusto, antes que

existiera UML de OMG, no había mecanismos estándares para intercambiar
modelos de una herramienta a otra.
UML es un lenguaje visual para el modelado e intercambio de modelos bien

definidos para el desarrollo de software. Aunque a un nivel básico UML suple
muchas de las necesidades de los usuarios, esta puede ser especializada para
incorporar aspectos que no contemplaban otras herramientas. Esta diseñado para
soportar herramientas y colaboración utilizando marcos de trabajo, patrones y
componentes.
UML define una notación gráfica para cada uno de los siguientes diagramas: de
casos, de uso, de clases, de comportamiento, de implementación incluyendo
diagramas de componentes y de desarrollo.
Modelo de componentes de CORBA (CORBABeans)
CORBA Components extiende el modelo de objeto de la OMG para incluir un

número de características importantes en un sistema distribuido. La noción de
componente puede no corresponder al modelo uno a uno ni de un objeto
CORBA, esta centrado más en la relación de un Componente con un conjunto
de Interfaces.
Los componentes tienen identificadores de instancias, así como propiedades que

son externamente accedidas y que soporta mecanismos de notificación (servicio
de eventos) y validación cuando alguna propiedad cambia.

Los componentes de CORBA serán trasladados a los lenguajes ya soportados, y a

otros modelos de componentes como los Java Beans. Igualmente se esta
trabajando en una especificación para un lenguaje de scripting que facilite el nivel
de usuario la utilización de componentes.
Control de la Calidad del Servicio
Mensajes Asincrónicos y Control de Calidad del Servicio.
La nueva especificación de Mensajería define un número de modos de

invocaciones asincrónicas e independientes del tiempo para CORBA el cua l
permite tanto invocaciones estáticas como dinámicas en cada modo. Las
invocaciones asincrónicas pueden ser realizadas de dos formas: censando
(polling) o callback.
Las políticas permite tener control de la Calidad del Servicio de las invocaciones,
los clientes y objetos pueden establecer control de ordenación (por tiempo,
prioridad, deadline), configurar prioridades, deadlines y tiempos de vida,
configurar tiempos de inicio y finalización para invocaciones sensibles al tiempo y
controlar las políticas de enrutamiento y número de saltos.
Tiempo Real, Tolerancia a Fallos y CORBA Mínimo.
Aunque ya hay muchos desarrollos de productos de tiempo real en CORBA y que

hay un grupo de trabajo en el área en la OMG, la incorporación de aspectos de
tiempo real en un ORB es opcional, es decir no es obligatorio que cumpla
requisitos de tiempo real para un proveedor de ORBs. Pero si un proveedor
ofrece esta característica en sus productos, deberá cumplir las especificaciones
definidas para tal caso. La primera especificación cubrirá aspectos como
Planificadores de prioridad fija, control de los recursos del ORB para
predictibilidad extremo a extremo y comunicaciones flexibles.
El nuevo Adaptador de Objetos Portable (POA), que permite a una

implementación acoplarse a un ORB es lo suficientemente robusto y flexible
para soportar redundancia y tolerancia a fallos en ambientes CORBA, pero aún
es necesario trabajar directamente en este campo por parte de la OMG. Así se
ha presentado una propuesta para tolerancia a fallos en modo de redundancia
activa y pasiva.
Aunque CORBA 2.0 especifica muchos requisitos para garantizar la

interoperabilidad entre proveedores de ORBs, hay ciertos casos en los cuales
una implementación “liviana” de un ORB sería altamente recomendable, por
ejemplo en implementaciones en chips o en sistemas embebidos. Para esto se
ha definido una RFP para CORBA mínimo que determine los requerimientos

mínimos que sí deben ser cumplidos para una especificación de “CORBA

Mínimo”.

Cuestionario
¿Qué problema la OMG está probando para resolver con CORBA?
¿Por qué la orientación a objetos ayuda a resolver el problema de

heterogeneidad?
¿Qué patrones de invocación de objetos soporta CORBA?
¿Cuál es la diferencia entre estilos de invocación síncrono y asincrónicos?
¿Qué es IDL y su utilidad?
¿Qué son los stubs y cómo se usan?
¿Qué son los skeletons y cómo se usan?
¿Cuál es la diferencia entre la invocación estática y dinámico y cómo se

soportan tanto en lado del cliente como del servidor?
¿Qué es un almacén de la interfaz?
¿Qué es un adaptador del objeto?
¿Cómo trabaja el registro del objeto y referencia del objeto?
¿Cuál es la diferencia entre el adaptador del objeto y el skeleton? ¿Qué
realiza un Adaptador del Objeto Portátil (POA)?
¿Qué es la activación / desactivación?
¿Qué es un objeto persistente?
¿Qué es un objeto transeúnte?
¿Cuál es la diferencia entre la llamada por referencia y llamada por valor?
¿Cómo la interoperabilidad del inter-orb se soporta?
¿Cuál es la diferencia entre GIOP e IIOP?
¿Qué transparencias proporciona CORBA?

Ejercicio Práctico

Escenario
Los programas del CORBA consisten en uno o más clientes y uno o más
servidores.
El ejemplo más simple es un cliente y un servidor. Los servidores en CORBA son a

menudo llamados servicios.
Los servicios simples exportan varios métodos y atributos mediante la Static

Skeleton Interface (SSI).
Los clientes tienen acceso a estos métodos y atributos que usan la Static
Invocation Interface (SII).
Los clientes tienen acceso a los servicios poniéndose en contacto con un

servicio bien conocido, llamado Lookup Service.
Definición de Interfaces con IDL
El Interface Definition Language (IDL) se usa para describir los métodos,

atributos, excepciones y tipos usados en su sistema distribuido. El código
siguiente muestra el archivo de IDL:
module library {
typedef struct _Book {
string isbn;
string title;
string author;
} Book;
typedef sequence<Book> BookList;
interface Library {
readonly attribute string name;
readonly attribute string address;
Book createBook(in string isbn, in string title, in string author);
BookList findBooksByTitle(in string title);
}
}
Guarde el archivo previo como 'library.idl' y lo compila usando el comando

siguiente:
idlj .fall library.idl

Se generan los archivos siguientes:
BookListHelper.java
Ésta es la clase del Auxiliador para el tipo de BookList (secuencia)
BookListHolder.java
Ésta es la clase del Poseedor para el tipo de BookList (secuencia)
Library.java
Ésta es la interfaz para el servicio de la Biblioteca Esta
clase extiende LibraryOperations
LibraryHelper.java
Ésta es la clase del Auxiliador para el tipo de la Biblioteca (interfaz)
LibraryHolder.java
Ésta es la clase del Poseedor para el tipo de la Biblioteca (interfaz)
LibraryOperations.java
Estas son las Operaciones de interfaz para la Biblioteca de interfaz Esta
interfaz define las operaciones en la Biblioteca
LibraryPOA.java
Éste es el POA (o server stub o skeleton) para la interfaz de la Biblioteca
_BookHelper.java
Ésta es la clase del Auxiliador para el tipo del Libro (estructura)
_BookHolder.java
Ésta es la clase del Poseedor para el tipo del Libro (estructura)
_LibraryStub.java
Ésta es la clase de client stub para la interfaz de la Biblioteca
Clases del poseedor (Holder)
Se usan clases del poseedor cuando un método define los parámetros out o inout,
dado que Java no los soporta nativamente. Ellos almacenan los valores de los
parámetros cuando ellos son pasados a un método (in) y/o después los métodos
regresan (out). Cualquier tipo que se usa como un parámetro (o valor devuelto) para
una operación debe tener una clase del Poseedor para cuando los parámetros in e
inout se usan.

Clases del auxiliador (Helper)
Las clases del auxiliador se usan para el suceso de ascenso y descenso.

Downcasting es similar a (MyObject)obj en Java, pero debido a las diferencias en
cómo la herencia trabaja en CORBA, debe usar el método narrow() en esta clase.
Upcasting es similar a (Object)myObj en Java, pero de nuevo debe usar el método
insert() en esta clase.
Implementación del servicio
Para implementar la interfaz de la Biblioteca, debemos crear una subclase de la

clase de POA abstracta (LibraryPOA) que define e implementa los métodos
descritos en a interfaz de las operaciones (LibraryOperations). Un ejemplo se
muestra:
package library;
import java.util.ArrayList;
public class LibraryServiceImpl extends LibraryPOA {
private ArrayList books = null;
public LibraryServiceImpl() {
books = new Arra yList();
_Book book1 = new _Book();
book1.title = "Java: How to Program";
book1.author = "Deitel";
book1.isbn = "123456";
books.add(book1);
book2.title = "XML for Beginners";
book2.author = "Colouris";
book2.isbn = "234567";
books.add(book2);
book3.title = "Distributed Systems";
book3.author = "Romero";
book3.isbn = "345678";
books.add(book3);
}
public String name() { return "The U of W Online Library"; }
public String address() { return "401 Sunset Ave."; }
public _Book createBook(String isbn, String title, String author) {
_Book newBook = new _Book();
newBook.title = title;
newBook.isbn = isbn;
newBook.author = autho r;
books.add(newBook); return
newBook;
}

public _Book[] findBooksByTitle (String title) {

ArrayList matchingBooks = new ArrayList(); for
(int i = 0; i < books.size(); i++) {
_Book book = (_Book)books.get(i); if
(title.equals(book.title)) {
matchingBooks.add(book);
}
}
_Book[] matches = new _Book[matchingBooks.size()];
for (int i = 0; i < matchingBooks.size(); i++) {
matches[i] = (_Book)matchingBooks.get(i);
}
return matches;
}
}
Aquí un ArrayList se usa para almacenar los libros. Ésta es una clase
predeterminada simple en Java que representa una matriz
dinámicamentedimensionada.
Registrador del servicio
Ahora, debe registrar el servicio con el lookup service. Esto puede hacerse en
la misma clase, pero aquí se implementa separadamente para la demostración.
package library;
import org.omg.CORBA.*;
import org.omg.CosNaming.*;
import org.omg.PortableServer.*;
public class LibraryRegistrar {
public static void main(String[] args) {
try {
// initialize the ORB
ORB orb = ORB.init(args, null);
// create an instance of the service implementation
LibraryServiceImpl service = new LibraryServiceImpl(); //
get a reference to the root POA
org.omg.CORBA.Object rootPOARef =
orb.resolve_initial_references("RootPOA");
POA rootPOA = POAHelper.narrow(rootPOARef);
// activate the POA

rootPOA.the_POAManager().activate();
// use the root POA to get an object

// reference for the service

org.omg.CORBA.Object serviceRef = null;
serviceRef = rootPOA.servant_to_reference(service);
// get a reference to the Naming service

org.omg.CORBA.Object namingRef =
orb.resolve_initial_references("NameService");
NamingContextExt naming =
NamingContextExtHelper.narrow(namingRef); //
create a name for the library service
NameComponent[] path = naming.to_name("Library");
// bind the name in the registry

naming.rebind(path, serviceRef);
// block and wait for requests

orb.run();
} catch (Exception e) {
System.err.println("Exception: "+e.getMessage());
e.printStackTrace();
}
}
}
Cliente
Los clientes de CORBA inicializan el ORB (meramente como los servidores)

primero, entonces buscan (normalmente usando el servicio de nombres) los
servicios para usar. Los servicios se usan entonces apropiadamente para el
propósito del cliente. Un cliente de ejemplo se muestra:
package libraryclient;
import library.*;
import org.omg.CORBA.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
public class LibraryClient {
public static void main(String args[]) {
try {
// create and initialize the ORB
ORB orb = ORB.init(args, null); //
get an object reference to the
// Naming service
org.omg.CORBA.Object namingRef =
orb.resolve_initial_references("NameService");

NamingContextExt naming =
NamingContextExtHelper.narrow(namingRef);
// use the Naming service to get an //

object reference to the service String
name = "Library";
org.omg.CORBA.Object libraryRef = naming.resolve_str(name);
Library library = LibraryHelper.narrow(libraryRef);
String libraryName = library.name();

System.out.println("Library Name: "+libraryName);
String libraryAddress = library.address();
System.out.println("Address: "+libraryAddress);
_Book matches1[] = library.findBooksByTitle("Java: How to Program");
System.out.println("Searching for \"Java: How to Program \":");
for (int i = 0; i < matches1.length; i++) {
System.out.println(" \t" + matches1[i].title + "," + matches1[i].author
+ "," +
matches1[i].isbn);
}
_Book newBook = library.createBook("4567890", "Java:

How to Program", "Deitel Jr.");
System.out.println("Created new book:");
System.out.println(" \t" + newBook.title + "," + newBook.author + "," +
newBook.isbn);
Book matches2[] = library.findBooksByTitle("Java: How to
Program");
System.out.println("Searching for \"Java: How to Program\"
(again):");
for (int i = 0; i < matches2.length; i++) {
System.out.println(" \t" + matches2[i].title + "," +
matches2[i].author + "," + matches2[i].isbn); }
System.err.println("Exception: " + e.getMessage()) ;
e.printStackTrace();
}
}
}
Compilación
Cree un directorio en su sistema para este ejemplo. Este directorio será llamado
~/corba_tutorial. Debe reemplazar este nombre de directorio con el directorio que
ha creado. Cree los directorios para el cliente y repare, como sigue:

mkdir ~/CORBA/client
mkdir ~/CORBA/service
Copie el archivo de IDL en el directorio ~/CORBA/service y compile el archivo de

IDL:
cd ~/CORBA/service
idlj -fall library.idl
El compilador idlj creará un directorio llamado ' library', dado que éste es el
nombre del módulo en el archivo de IDL que fue convertido en un paquete
cuando el IDL se mapeo a sus Java bindings. Por consistencia, se han puesto
también el servicio y archivos del registrador en este mismo paquete. Por
consiguiente, copie el servicio y código del registrador en los archivos
apropiadamente nombrados (LibraryServiceImpl.java y LibraryRegistrar.java,
respectivamente) en el directorio ~/corba_tutorial/service/library. Compile todos los
archivos en este directorio:
javac library/*.java
El servicio y registrador son ahora compilados y preparan para ejecutar. Puede

haber notado que el cliente está en un paquete diferente, libraryclient. Cree un
directorio para este archivo, representar este paquete, así como un directorio para
los archivos de servicio requeridos por el cliente.
mkdir ~/CORBA/client/libraryclient
mkdir ~/CORBA/client/library
Copie el código del cliente anteriormente en un archivo apropiadamente

nombrado (LibraryClient.java) en este directorio. Ahora, necesitamos copiar
encima de los archivos del servicio que es requerido por el cliente. (Si está
usando windows, use el 'copy' el comando en lugar de 'el cp' y asegure usar '\' como
el separador del archivo en lugar de '/' como se muestra aquí)
cd ~/CORBA
cp service/library/BookHelper.class client/library
cp service/library/BookListHelper.class client/library
cp service/library/Library.class client/library
cp service/library/LibraryHelper.class client/library
cp service/library/LibraryOperations.class client/library
cp service/library/_Book.class client/library
cp service/library/_BookHelper.class client/library
cp service/library/_LibraryStub.class client/library

Dado que el cliente y los archivos del servidor están en directorios

completamente diferentes, es más fácil decir si cualquier clase está relegada, ya
que el cliente no compilará, o no ejecutará. Esto lo hace más fácil cuando
queremos mover el cliente a otra máquina. Puede compilar el cliente ahora:
cd ~/CORBA/client
javac libraryclient/LibraryClient.java
Ejecución
El servicio y cliente están ahora listos para ejecutar. La primera cosa para hacer
es empezar un servicio de nombres, para que el registrador pueda registrar el
servicio cuando ejecuta. Esto debe hacerse antes que el registrador ejecute.
orbd -ORBInitialPort 1050 -ORBInitialHost localhost
El número 1050' representa el puerto de red dónde el servicio de nombres está

ejecutando. Puede usar cualquier valor para esto cuando le gusta. El nombre
'localhost' se refiere al nombre de dominio dónde el servicio de nombres está
ejecutando. Si ejecuta esto en una máquina remota, se asegura de notar su
nombre de dominio para el uso al ejecutar el registrador y cliente.
Podemos empezar el registrador que inicializará el servicio y lo registrará con el

servicio de nombres ahora. El registrador debe ejecutar antes que el cliente sea
ejecutado.
cd ~/CORBA/service
java library.LibraryRegistrar -ORBInitialPort 1050 -ORBInitialHost localhost
Finalmente, ejecute el cliente.
cd ~/CORBA/client
java libraryclient.LibraryClient -ORBInitialPort 1050 -ORBInitialHost Localhost
Está ahora listo para escribir un simple cliente/servicio CORBA. Mucho del
código en el ejemplo anterior puede ser considerado una plantilla del CORBA
estándar. Puede identificar la mayoría de este código dado que esta
documentado.
Un acercamiento recomendado es extraer el código de la plantilla para el cliente,

registrador y servicio, para el uso cuando crea sus propios clientes y servicios. Esto
lo salvará de la mecanografía e disminuye la preocupación por tantos errores de
compilación.

3.4. RMI
Escenario RMI
¿Qué es RMI?
 Invocación de Métodos Remotos (RMI) es una implementación orientada

a objetos del modelo de RPC. Sólo es un API para los programas Java.
 Con RMI, un servidor del objeto exporta un objeto remoto, el cual tiene
sus registros. El objeto proporciona métodos remotos que pueden
invocarse en programas clientes.
 Un objeto remoto se declara con una interfaz remota, una extensión de la
interfaz de Java.
 La interfaz remota es llevada a cabo por el servidor del objeto.
 Un cliente del objeto tiene acceso al objeto invocando los métodos
remotos asociados con los objetos que usan la sintaxis proporcionada por
las invocaciones de métodos remotas.
Arquitectura RMI
Registro de
Objetos
Soporta la
interfase con
Cliente del Servidor del
el programa Objeto Objeto
de aplicación
Stub Skeleton
Mapea la plataforma
independiente de la capa Capa de Referencia Remota
Stub/Skeleton a la
plataforma dependiente Capa de Transporte
de la capa de transporte,
moviliza los protocolos de
referencia remota
Activa, mantiene y
desactiva las
conexiones, y
moviliza el
protocolo de
transporte

Interacción entre Stub y Skeleton
stub skeleton Método

Remoto
Tiempo
Marshal parámetros;
Envía petición
Unmarshal parámetros
Invoca método
Ejecuta código
y regresa valor
Recibe valor de retorno

Marshal Contestación
Envía contestación
Unmarshall Contestación
Regresa valor
Escenario RMI
Definir su interfaz
remota 1
 Con base en el proceso Implemente

para aplicaciones RMI la interfaz 2
realizar el ejercicio RMI
(anexo)
javac
3
4 rmic
Server class (.class)
Implemente Client stub (.class) Server Skeleton (.class)
8 el cliente
Iniciar el RMI Registry 5

9 javac
Iniciar objetos del servidor 6

10 Inicie cliente
Registrar objetos remotos 7

Actividad 3.4
Actividad RMI
Realizar el Ejercicio RMI anexo y coloque su reporte en Tarea Individual 3.4
Ejercicio RMI
RMI es una tecnología de Middleware, RMI proviene de las siglas Remote

Method Invocation (o Invocación de Métodos Remotos).
Particularmente son tecnologías dependientes del lenguaje, y en ocasiones de algún

tipo de arquitectura o framework que lo soporta.
Obedece a las mismas reglas de todos los middleware de objetos. Tanto el

objeto cliente como el servidor requieren elementos middleware stub y skeleton.
JavaRMIEl concepto de JavaRMI se explicará a través del siguiente ejemplo

guiado por código.
EJERCICIO
/*** Intefaz remota para el ejemplo Hola, Mundo ***/
public interface InterfazHola extends Remote {
/*** Método remoto invocable ***/
public String saludar() throws RemoteException;
import java.rmi.server.*;
/*** Clase Remota para el ejemplo “Hola, Mundo!” ***/
public class Hola extends UnicastRemoteObject implements InterfazHola {

private String mensaje;
/*** Constructor de la clase ***/
public Hola (String msj) throws RemoteException {

mensaje = msj;
}

/*** Implementación del método remoto a invocar */
public String saludar() throws RemoteException {

return mensaje;
}
}
/*** Programa Cliente para el ejemplo: Hola, mundo. */
public static void main (String[] argv) {
try {
System.setSecurityManager (new RMISecurityManager() {

public void checkConnect (String host, int port) {}
public void checkConnect (String host, int port, Object context){}
}
InterfazHola hola = (InterfazHola) Naming.lookup ("//NombreHost/Hola");

System.out.println (hola.saludar());
System.out.println ("Excepción de ClienteHola: " + e);
}
}
}
/* Constructor */
public HelloServer() {
/** Programa Servidor del Ejemplo Hola,Mundo. */
public static void main (String[] argv) {

try {
System.setSecurityManager (new RMISecurityManager() {
public void checkConnect (String host, int port) {}
public void checkConnect (String host, int port, Object context){}
}
Naming.rebind ("//NombreHost/Hola", new Hola ("¡Hola, Mundo!"));

System.out.println ("ServidorHola listo.");
System.out.println ("Excepción de ServidorHola: " + e);
}
}

}grant codeBase "file:C:/dat/Java/Java_RMI/RMIEjemplo/-" {

permission java.security.AllPermission;
}
Arranque del Servicio de Registro
Arranque del servidor
start java -Djava.security.manager -Djava.security.policy=java.policy

ServidorHola
Arranque del cliente
start ClienteHola
Puntos de
Estándar
Estándar Obtenidos
(10-9) (8.5-7) (6.5-0)
La información La información La información
revisada permitió a revisada permitió revisada no
a los estudiantes permitió a los
Aplicación de los estudiantes
comprender con comprender estudiantes
la Información
claridad los solamente los comprender los
ejercicios y ejercicios y ejercicios y
programas. programas. programas.
(10-9) (8.5-7) (6.5-0)
Los estudiantes han
Los estudiantes
demostrado el Los estudiantes
no han hecho
significado del han demostrado
contacto con el
material elaborando el significado del
material,
Conexiones correctamente, material
Especialistas simplemente sin
mientras extienden incorporándolo
incorporar la
y explican la correctamente en
información en
información, el estudio del
su estudio del
incorporándola en el tema. tema.
estudio del tema.

3.5. COM+
Escenario COM+
.Net y COM+
 COM+ se refiere a la versión de COM que combina las características

basadas en servicios de Microsoft Transaction Server (MTS), con COM
distribuido (DCOM). COM+ proporciona un conjunto de servicios
orientados a la capa media. En particular, COM+ proporciona
administración de procesos, servicios de sincronización, un modelo de
transacción declara tivo y agrupación de conexiones a objetos y bases de
datos.
 Los servicios COM+ están principalmente orientados hacia el desarrollo

de la aplicación de capa intermedia y se enfoca en proporcionar
confiabilidad y escalabilidad para aplicaciones distribuidas a gran escala.
Estos servicios son complementarios a los servicios de programación
proporcionados por el Entorno .NET; y la BCL (Base Class Library)
proporciona acceso directo a ellos.
Capacidades de COM+
 Integración completa de MTS en COM

o Facilita el desarrollo de aplicaciones distribuidas mediante la
reducción del trabajo asociado con el desarrollo, la depuración, la
distribución y el mantenimiento de una aplicación que
anteriormente utilizaba COM para determinados servicios y MTS
para otros.
 Componentes en cola
o Los componentes en cola son una característica de los Servicios
de componentes que aprovecha las ventajas de MSMQ para
permitir que los componentes de servidores participen de forma
lógica en las transacciones mientras están fuera de línea o no
disponibles.
 Eventos de COM+
o Permite a los programadores de aplicaciones escribir código de
aplicaciones (llamados publicadores) que pueden notificar código
de aplicaciones del cliente (llamados suscriptores) cuando tiene
lugar un evento concreto.
Ejemplo de aplicación de entrada de pedidos mediante el uso de eventos de

COM+:
El servidor de inventarios de productos puede publicar un aviso cuando los

niveles de inventario descienden debajo de un determinado nivel.

Si un área se ve afectada por las condiciones de inventario, puede utilizar esa

información en sus aplicaciones con la suscripción al servicio de notificación de
eventos de software de inventario.
Se anexa material de apoyo para el tema de COM+, que se extiende por las
capacidades que presenta COM+, por lo que deberá realizar las actividades
siguientes:
 Resolver los cuestionarios del material de apoyo 3.5
 Realizar los ejercicios del material de apoyo 3.5
Actividad 3.5
Actividad COM+
Contestar los cuestionarios y realizar los ejercicios del Material de Apoyo 3.5.
Coloque el informe de su actividad en Tarea Individual 3.5

3.5. COM+
3.5.1. Introducción a los Servicios COM+
3.5.1.1. Historia de las aplicaciones basadas en servidor
Introducción
Cuando apareció el sistema operativo Microsoft Windows, se utilizó

principalmente para ejecutar aplicaciones independientes en equipos
personales. Con el paso del tiempo, se han ampliado las capacidades del
sistema operativo Windows para admitir aplicaciones que ofrecen cada vez más
posibilidades. El sistema operativo incluye un conjunto integrado de tecnologías,
llamado servicios de aplicaciones, que permite a las organizaciones crear y
personalizar rápidamente aplicaciones distribuidas mediante software basado en
componentes. Para ayudar a los programadores de aplicaciones a escribir
rápidamente software sofisticado que abarca operaciones tanto de clientes como de
servidores, los servicios de aplicaciones han evolucionado
considerablemente durante la década pasada.
Los servicios de aplicaciones de Windows, también conocidos como COM+,

constituyen la piedra angular de la arquitectura de Aplicaciones distribuidas de red
de Windows (Windows DNA).
Las aplicaciones distribuidas se crean con el fin de aprovechar la capacidad de

procesamiento que ofrecen los servidores, como los que se utilizan para
aplicaciones sectoriales y de bases de datos, y las capacidades de cliente de los
equipos personales y otros dispositivos. Al separar entre equipos distintos los
procesos utilizados en una aplicación, las organizaciones pueden crear software
escalable y flexible por medio de hardware de consumo.
Un buen ejemplo de aplicación distribuida sería el proceso de entrada de

pedidos de comercio electrónico, que integra datos y procesos desde diversas
ubicaciones, incluidos servidores y clientes. En el entorno de desarrollo actual,
dicho proceso suele combinar elementos del software tradicional, como una
base de datos, con las tecnologías basadas en Internet, como un explorador.

Componentes de software
Los componentes son los pilares de las aplicaciones distribuidas. Un

componente es un módulo de software escrito para controlar un tipo concreto de
información o un proceso en particular. Por ejemplo, se puede crear un registro de
cliente con un componente que proporcione el nombre, la dirección y otro tipo de
información distintiva. Cada componente se diseña de manera que pueda
modificarse fácilmente para ajustarse a unos requisitos determinados. De esta
manera, en vez de escribir el mismo tipo de código una y otra vez, los
programadores pueden utilizar código de software prefabricado y sólo necesitan
ajustar los elementos que son diferentes en cada aplicación. Los programadores
crean aplicaciones mediante la integración de componentes, de la misma
manera que puede construir una casa a partir de un conjunto de piezas
prefabricadas, como puertas, ventanas y armarios.
El software de componentes sirve para mucho más aparte de reducir la cantidad

de código que los programadores tienen que escribir desde el principio. Puesto
que las aplicaciones creadas con componentes pueden vincularse a través de
redes, el software de componentes también supone una manera eficaz de crear
aplicaciones distribuidas, que dividen el proceso entre los equipos cliente y
servidor.
Los servicios de aplicaciones basadas en componentes de Windows se basan

en COM+, la última generación del Modelo de objetos componentes (COM) de
Microsoft. Desde que apareció por primera vez a principios de los noventa, COM
ha sido una importante tecnología de Windows en constante evolución. Windows
presenta COM+, que constituye un elemento básico de la plataforma Windows.
Para comprender COM+, resulta útil comprender la evolución de COM, así como
los servicios de colas de transacciones y de mensajes. Está sección proporciona
una introducción a estas tres tecnologías antes de explicar sus mejoras en
COM+.

Aplicaciones distribuidas y COM
COM permite a los programadores de aplicaciones dividir aplicaciones de

software grandes y complejas en una serie de componentes creados
previamente, que son fáciles de comprender, programar y cambiar. Los
componentes pueden contener una lógica empresarial relevante para controlar
cada elemento de una transacción, como especificar la longitud adecuada de un
número de teléfono. Los programadores conectan entre sí los componentes para
crear un proceso empresarial. Este método reduce el costo de programación de
software y permite que las organizaciones puedan modificar fácilmente las
aplicaciones a medida que cambian las condiciones empresariales.
Para resolver las necesidades de los modelos de programación de aplicaciones

cada vez más sofisticados gracias a los equipos personales conectados en red,
COM ha evolucionado desde que se incluyó por primera vez con el sistema
operativo Windows NT Server 3.51. En concreto, Windows NT Server 4.0 amplió
COM en tres áreas principales. En primer lugar, COM distribuido (DCOM) amplió
el modelo COM para abarcar varios equipos conectados en red. En segundo
lugar, los Servicios de Microsoft Transaction Server (MTS) permitían a los
programadores crear aplicaciones basadas en componentes con transacciones
que abarcan componentes y bases de datos. En tercer lugar, los Servicios de
Microsoft Message Queue Server (MSMQ) permitían a los programadores
escribir aplicaciones con componentes que se ejecutan de forma asincrónica, con
pausas entre el comienzo y el final de un proceso.
Con Windows Server, estos servicios se han integrado y refinado aún más para
permitir a los programadores escribir software basado en componentes
complejos con menor cantidad de código personalizado.
Los servicios de aplicaciones COM de Windows están diseñados para admitir

una arquitectura de tres niveles (también llamada de n niveles o distribuida). La
arquitectura de n niveles separa una aplicación en tres componentes distintos:
 Presentación. Es la parte de la aplicación con la que interactúa un

usuario, como el formulario de pedidos utilizado en aplicaciones de
comercio electrónico.
 Lógica de la aplicación. Este componente contiene todas las reglas y la
lógica empresariales asociadas con la aplicación, como la aplicación de
comprobación de crédito utilizada para admitir una aplicación de comercio
electrónico.
 Datos. Se trata del mecanismo que almacena y administra los datos
asociados con la aplicación, como la información de inventario de un
producto para una aplicación de comercio electrónico. Habitualmente se
trata de bases de datos relacionales, pero puede incluir también otros
contenedores de almacenamiento, como un sistema de archivos.

Arquitectura de aplicaciones de tres niveles
La división de aplicaciones en las secciones de presentación, lógica de la

aplicación y datos da lugar a un modelo de programación simplificado que es la
manera estándar de crear aplicaciones que aprovechan las ventajas de las
comunicaciones de Internet y de Intranet. Si las organizaciones agregan más
hardware donde sea necesario, también podrán ampliar las aplicaciones de n
niveles para controlar más usuarios y mayor información.
El paso a un modelo de desarrollo de n niveles es el resultado de una gran

evolución del modelo de desarrollo de aplicaciones para equipos personales
durante la década anterior. A finales de los ochenta, las aplicaciones se
escribían por lo general para que se ejecutaran por completo en un único
equipo. A principios de los noventa, apareció el modelo cliente -servidor de dos
niveles. Esto permitió a los programadores descargar a los equipos cliente de
parte del trabajo con mayor procesamiento de datos y trasladarlo a servidores de
fondo con más capacidad. En este modelo de dos niveles, el software de
presentación (la interfaz de usuario) permaneció en el equipo personal, mientras
que la mayor parte del trabajo de procesamiento se trasladó al servidor. El
modelo de tres niveles agrega un elemento adicional de separación entre los
niveles de datos y de presentación, ya que permite controlar la lógica de
procesamiento en un servidor independiente de las funciones de base de datos y
de presentación.
El Modelo de objetos componentes
Para hacer posible la creación de aplicaciones distribuidas, tiene que haber una
manera de separar la aplicación en pilares más pequeños encargados de
funciones específicas. Además, estos pilares deben ser capaces de ejecutarse en
un único proceso, en varios procesos diferentes e incluso en máquinas
diferentes, de ahí el nombre distribuido. COM cumple estos requisitos previos,
además de proporcionar estos requisitos adicionales:

 Ubicación transparente. Se puede llamar a cada componente COM

dentro de un proceso, a través de procesos en un único equipo o a través
de varios equipos sin necesidad de volver a compilarlo.
 Independencia del lenguaje. COM es un estándar binario. Así, una
implementación de COM escrita en un lenguaje es compatible con otras
implementaciones de COM; es decir, es independiente del lenguaje. Esto
significa, por ejemplo, que un programador de Java puede reutilizar otros
componentes COM escritos en lenguajes como VBScript o C++. Esto
permite a los programadores crear una aplicación a partir de
componentes escritos en cualquier lenguaje que sea apropiado y
conveniente.
 Interfaces intuitivas. Las interfaces intuitivas proporcionan herramientas
y otras aplicaciones que permiten a los programadores descubrir las
interfaces y los parámetros admitidos por el componente. De esta forma, los
programadores pueden trabajar con el componente sin necesidad de
comprender su funcionamiento interno.
Una vez que COM se popularizó, los programadores se dieron cuenta de que
necesitaban que los componentes pudieran funcionar juntos a través de las
redes. Por esa razón, con Windows NT Server 4.0 Microsoft presentó el Modelo
de objetos componentes distribuido (DCOM), que amplía COM para que la
tecnología de componentes pueda funcionar a través de redes y de Internet,
como sucede en una arquitectura de n niveles. Desde su presentación, se ha
utilizado con frecuencia el término COM para incluir también las tecnologías
distribuidas DCOM.
Servicios de transacciones
A mediados de los noventa, Microsoft amplió la aplicabilidad de COM con la

aparición de Microsoft Transaction Server (MTS). En Windows NT 4.0, MTS es
una tecnología independiente que amplía el modelo de programación COM para
el desarrollo, distribución y administración de aplicaciones distribuidas basadas
en componentes.
MTS simplifica el desarrollo de aplicaciones en el nivel medio de la arquitectura

de n niveles, ya que proporciona gran parte de la infraestructura de software
necesaria para ejecutar la lógica empresarial que se ejecuta allí. MTS incluye
código de infraestructura para administración de conectividad, directorios,
seguridad, procesos y subprocesos, así como las conexiones de bases de datos
necesarias para crear una aplicación preparada para realizar transacciones.
Una transacción es un conjunto de eventos que se confirman o se deshacen

como una unidad: o suceden todos los eventos o ninguno de ellos. La creación
de una transacción completa puede requerir la cooperación de varios
componentes. En el ejemp lo de la figura, la aplicación de entrada de pedidos
consta de componentes que, mediante DCOM, recuperan y procesan

información de varios servidores. MTS proporciona servicios integrados de

programación que permiten a los programadores asegurarse de que toda la
transacción tiene éxito o se anula por completo, sin necesidad de escribir
grandes cantidades de código personalizado para controlar los mecanismos de
la transacción.
Servicios de transacciones
La manera más fácil de comprender cómo funcionan juntos MTS y COM es

observar un escenario típico, como el que se ilustra en la figura previa. Suponga que
un cliente solicita productos a través de Internet. Todo el sistema de entrada de
pedidos puede crearse mediante componentes COM que contengan la lógica
empresarial necesaria para procesar pedidos. Los elementos individuales del
pedido del cliente utilizarán con toda probabilidad varios procesos y bases de
datos, alojados en diferentes servidores.
Por ejemplo, el proceso utilizaría una base de datos con información de clientes para
registrar el nombre y la dirección del cliente, una base de datos de inventario
para asegurarse de que hay disponibilidad del producto para atender el pedido, una
base de datos de envío para realizar el seguimiento del envío y un proceso de
comprobación de crédito para asegurarse de que la tarjeta de crédito del cliente es
válida.
Cuando el cliente realiza el pedido, todos los procesos y las transacciones de

bases de datos deben registrarse como un conjunto. MTS supervisa toda la
transacción y sólo confirma todos los cambios si la transacción tiene éxito en su

totalidad. Si se interrumpe el proceso de pedido debido a un error de hardware o

en las comunicaciones, MTS anulará todo el pedido o lo mantendrá para su
procesamiento completo una vez restauradas las comunicaciones. Asimismo, si
el cliente cancela el pedido, MTS permite anular todos los procesos y entradas
de las bases de datos. Nota: Los Servicios de componentes no pueden anular
los cambios realizados en el sistema de archivos o en otros recursos sin
transacciones.
Antes de MTS, los programadores tenían que escribir secuencias de comandos y

componentes para hacer un seguimiento manual de los cambios solicitados y, en
caso de que éstos fallaran, restaurar los datos. Con MTS, los programadores sólo
tienen que designar que las secuencias de comandos o los componentes necesitan
transacciones. Esto significa que los programadores pueden poner juntas
aplicaciones que usan componentes sin tener que escribir el código
especializado necesario para tratar dichos problemas.
Entre las características básicas de MTS se incluyen:
 Transacciones automáticas. MTS admite transacciones automáticas,

que permiten configurar los requisitos de transacción de un componente
cuando se distribuye dicho componente. El resultado es un potencial
mucho mayor para la reutilización de objetos empresariales creados como
componentes MTS.
 Seguridad configurable. Al permitir a un administrador definir funciones
y especificar las interfaces y los componentes a los que pueden tener
acceso los clientes identificados para cada función, MTS simplifica en gran
medida el trabajo necesario para crear aplicaciones de servidor seguras.
Por ejemplo, un administrador puede designar que sólo aquellos clientes
identificados como administradores puedan cambiar el historial de crédito.
Nota: el modelo de seguridad de MTS se basa en la infraestruc tura
de seguridad de Windows.
 Agrupación de conexiones de bases de datos. Los componentes
pueden volver a utilizar conexiones existentes con una base de datos en lugar
de crear otras nuevas, lo que mejora notablemente el rendimiento y la
escalabilidad de las aplicaciones.
 Compatibilidad con diversas bases de datos y administradores de
recursos. Las aplicaciones basadas en MTS pueden tener acceso a
bases de datos de Microsoft SQL Server, Oracle y DB2, así como a otros
administradores de recursos como Servicios de Microsoft Message
Queue Server. También están disponibles los controladores de
Conectividad abierta de bases de datos (ODBC) compatible con MTS y Base
de datos de vinculación e incrustación de objetos (OLE DB) para muchas
otras bases de datos de proveedores terceros.
 Compatibilidad con subprocesos automática. Los programadores de
aplicaciones pueden escribir componentes de un único subproceso y, a
continuación, permitir a MTS asignar subprocesos a dichos componentes
según sea necesario.

 Administración de estado de componentes. Los componentes tienen

que abandonar cualquier estado de la memoria cuando finaliza cada
transacción. Esto facilita la creación de aplicaciones correctas a la vez
que permite compartir los recursos de manera eficaz. MTS también
proporciona el Administrador de propiedades compartidas (SPM) de
manera que los componentes puedan almacenar y recuperar
posteriormente su estado de la memoria.
 Aislamiento de procesos mediante paquetes. Las aplicaciones
individuales pueden agruparse en uno o más paquetes y cada paquete
puede ejecutarse en su propio proceso. Esto permite una mayor
tolerancia a errores, ya que si falla un único componente, eso supone
únicamente la inactividad del paquete en el que está ubicado ese
componente.
 Integración con transacciones de grandes sistemas. A través del
Integrador de transacciones COM, las transacciones MTS pueden iniciar y
controlar transacciones CICS en grandes sistemas de IBM.
 Una gran variedad de herramientas de desarrollo. MTS permite a los
programadores crear aplicaciones en cualquiera de los lenguajes más
conocidos en la actualidad, incluido el sistema de programación Visual
Basic, Java, C++ y Cobol.
Message Queue Server
Como puede no ser necesario completar todos los pasos del proceso de una
aplicación a la vez, muchas aplicaciones distribuidas necesitan poder controlar
los retardos entre una solicitud y su respuesta. En estas situaciones se utilizan
los Servicios de Message Queue Server (MSMQ). MSMQ es una tecnología
independiente que complementa las capacidades inherentes a COM y MTS.
MSMQ permite a las aplicaciones utilizar componentes que se comunican entre
sí de forma asincrónica mediante mensajes en cola, que es un concepto similar
al de un mensaje de correo electrónico que espera en una bandeja de entrada.
El hecho de que los programadores puedan escribir aplicaciones que no

requieren respuestas inmediatas de los equipos cliente o servidor les permite
proporcionar la flexibilidad necesaria para controlar pausas rutinarias en los
procesos empresariales. El uso de este servicio también ayuda a los
programadores a escribir aplicaciones de mayor disponibilidad y más escalables.

Servicios de Message Queue Server
Cuando los programadores escriben componentes que aprovechan las ventajas

de MSMQ, sus aplicaciones pueden enviar mensajes a otras aplicaciones sin
necesidad de esperar una respuesta (de hecho, la aplicación de destino podría
no estar ni siquiera en ejecución). Dichos mensajes se envían a una cola, donde
se almacenan hasta que una aplicación receptora los quita. Si se espera una
respuesta, el remitente puede comprobar una cola de respuesta cuando lo
desee.
La cola de mensajes es un método de comunicación flexible y confiable,
apropiado para diversos tipos de aplicaciones. Los programadores no tienen que
preocuparse por los detalles y la arquitectura del sistema se encarga de los
procesos de cola, incluso aunque el cliente y el servidor no estén ejecutándose
al mismo tiempo.
Por ejemplo, un programador puede utilizar MSMQ para escribir una aplicación que
permitirá a los clientes realizar pedidos a través de Internet, incluso si el servidor
Web encargado de la recepción no está disponible. Las colas de mensajes
también pueden utilizarse para realizar procesos de fondo más eficaces. Por
ejemplo, cuando un cliente realiza un pedido, no es necesario procesar todos los
componentes del pedido inmediatamente. En el ejemplo descrito anteriormente,
el departamento de envío no tiene que recibir el pedido del cliente hasta que se haya
completado el resto de la transacción. Con MSMQ, la aplicación de entrada de
pedidos puede seguir ejecutándose incluso si la aplicación de envíos no está
disponible.

Cuando se completa un pedido, un componente de entrada de pedidos envía un

mensaje a un almacén para indicar que hay que empaquetar y enviar el pedido.
Como no es necesario que el componente espere a que se envíe el pedido, esta
solicitud se realiza mediante MSMQ. Cuando es preciso, una aplicación del
almacén extrae los pedidos de una cola y se asegura de que se atienden
debidamente. Los programadores pueden utilizar servicios de transacciones con
MSMQ para asegurarse de que la transacción se completa correctamente.
Entre las características de MSMQ que admiten las capacidades anteriormente
descritas se incluyen:
 Acceso basado en COM. Es posible tener acceso a los servicios de

MSMQ a través de una interfaz sencilla proporcionada por componentes
COM. Esta configuración hace que sea elemental enviar y recibir
mensajes desde una secuencia de comandos en una página Active
Server de Servicios de Internet Information Server, una aplicación basada en
MTS o cualquier software que pueda utilizar COM.
 Integración con MTS. Las operaciones de MSMQ se pueden incluir
automáticamente en transacciones MTS para conservar la integridad de los
datos.
 Introducción automática en el diario de mensajes. Si así se solicita,
MSMQ conservará copias de los mensajes enviados o recibidos por las
aplicaciones. Los diarios proporcionan pistas de auditoria y pueden
realizar más fácilmente la recuperación de ciertas clases de error.
 Notificación automática. Si así se solicita, MSMQ puede notificar a una
aplicación de envío que los mensajes se recibieron y procesaron (o no)
correctamente. Este servicio permite a las aplicaciones de envío saber
cuándo pueden tratar los mensajes como entregados o, si se producen
errores, cuándo deben realizar acciones correctivas.
 Servicios integrados de integridad de datos, privacidad de datos y
firma digital. MSMQ puede firmar digitalmente y encriptar mensajes para
su transferencia a través de la red. Esta capacidad protege los mensajes
para que no se puedan ver o modificar durante la transmisión, incluso si
se envían a través de redes públicas como Internet, y garantiza que los
servidores no reciban mensajes de remitentes sin autorización.
 Capacidad para establecer la prioridad de los mensajes. MSMQ
permite asignar prioridades a los mensajes y las colas de mensajes, y
después se basa en dichas prioridades para enrutarlos y entregarlos. Las
prioridades permiten a las aplicaciones ocuparse primero de los mensajes más
importantes.
 Integración de aplicaciones simplificada. Las colas de mensajes
reducen en gran medida los requisitos de sincronización entre
aplicaciones, ya que es fácil traducir el contenido de los mensajes y las
interfaces basadas en mensajes ocultan las diferencias existentes entre
las diferentes arquitecturas de aplicaciones y tecnologías de bases de
datos.

 Independencia de protocolos de red. Todas las funciones y

características de las colas de mensajes funcionan independientemente
de los protocolos de red. Cualquier aplicación que conozca el nombre de
la cola de solicitudes de otra aplicación puede enviar solicitudes y recibir
respuestas, cualquiera que sea el tipo de red.
Al ofrecer comunicaciones asincrónicas flexibles y confiables entre aplicaciones

basadas en componentes, MSMQ desempeña un papel vital en los servicios de
componentes de Microsoft para Windows NT 4.0. Con Windows 2000, los
servicios de MSMQ están aún más estrechamente integrados con el modelo de
programación COM, como se describe en la próxima sección.
COM+
En Windows NT 4.0, COM y MTS simplificaron la programación de aplicaciones

distribuidas. En Windows 2000, COM y MTS se combinan para crear COM+, que
simplifica aún más la creación y el uso de componentes de software .
COM+ proporciona servicios que pueden utilizarse desde cualquier lenguaje o

herramienta de programación y permite una amplia interoperabilidad entre
componentes, independientemente de cómo se implementen. Para conseguirlo,
define un conjunto estándar de tipos de componentes y hace que todos los
componentes se describan a sí mismos por completo. Esto garantiza que todos
los componentes y servicios de sistemas compatibles con COM+ estarán
accesibles para todos los lenguajes y herramientas compatibles con COM+,
además de simplificar la distribución de componentes y aplicaciones que los
utilizan.
Las características suministradas con COM+ permiten que las aplicaciones se

ejecuten más rápido y se escalen mejor, a la vez que facilitan a los
programadores la integración de código con sistemas de varios proveedores.
Los componentes escritos con el modelo COM funcionarán con COM+. COM+
amplía también la compatibilidad de la plataforma Windows con la programación
basada en atributos, que permite utilizar los componentes de una manera más
flexible.
COM+ presenta varias capacidades nuevas, incluidas las siguientes:
Integración completa de MTS en COM. Como se mencionó anteriormente,

COM+ unifica los modelos de programación inherentes en los servicios COM y MTS.
También combina el código de infraestructura para trabajar con compone ntes
y el modelo de seguridad suministrado previamente por MTS. Esto facilita el
desarrollo de aplicaciones distribuidas mediante la reducción del trabajo
asociado con el desarrollo, la depuración, la distribución y el mantenimiento
de una aplicación que anteriormente utilizaba COM para determinados servicios
y MTS para otros.

Componentes en cola. Los componentes en cola son una característica de los

Servicios de componentes que aprovecha las ventajas de MSMQ para permitir
que los componentes de servidores participen de forma lógica en las
transacciones mientras están fuera de línea o no disponibles. Considere los
componentes en cola como la versión prefabricada de MSMQ (que sigue
estando disponible por separado). Si bien los programadores pueden utilizar
MSMQ para escribir aplicaciones que utilizan las capacidades suministradas por
los componentes en cola, tal desarrollo supone bastante carga de trabajo. La
programación con componentes en cola es mucho más rápida y no requiere el
aprendizaje de técnicas nuevas por parte del programador.
Los componentes en cola se utilizan habitualmente para las comunicaciones

entre dos servidores. Las solicitudes que afectan a un componente en cola se
registran, se ponen en cola y se reproducen de forma transparente más
adelante, cuando el componente solicitado está disponible. Dicho modelo resulta
especialmente útil en redes no confiables o en situaciones en las que uno de los
servidores no está siempre conectado a la red. Los componentes en cola
pueden ejecutarse inmediatamente si los servidores están conectados; de lo
contrario, el componente no puede retener la ejecución hasta que se realiza una
conexión.
Eventos de COM+. También conocido como servicio de eventos de publicación

y suscripción o Notificación de eventos, los eventos de COM+ constituyen una
herramienta de programación que permite a los programadores de aplicaciones
escribir código de aplicaciones (llamados publicadores) que pueden notificar
código de aplicaciones del cliente (llamados suscriptores) cuando tiene lugar un
evento concreto. Por ejemplo, los eventos de COM+ pueden ser útiles a los
programadores que utilizan componentes en cola para garantizar la entrega de
las tareas en cola.
Los eventos de COM+ usan un mecanismo de eventos de publicación y

suscripción por multidifusión que permite a diversos clientes suscribirse a
eventos publicados por varios servidores. El sistema de eventos de COM+
mantiene una base de datos de eventos con información acerca de varios
eventos, publicadores, suscriptores y suscripciones individuales.
Para ver su funcionamiento, observe de nuevo la aplicación de entrada de

pedidos descrita anteriormente. Mediante el uso de eventos de COM+, el
servidor de inventario de productos puede publicar un aviso cuando los niveles
de inventario de los elementos más populares descienden por debajo de un
determinado nivel. Los programadores que escriben aplicaciones para el
departamento de compras, o cualquier otra área de la organización que se vea
afectada por las condiciones del inventario, pueden utilizar esta información en
sus aplicaciones mediante la suscripción al servicio de notificación de eventos
de software de inventario.

COM+
3.5.1.2. La arquitectura de tiempo de ejecución de COM+
Introducción
COM ofrece una solución para desarrollar aplicaciones basadas en

componentes. Es bien sabido de todos que el trabajo que es necesario realizar
para escribir componentes COM es arduo y repetitivo. COM+ es más que una
nueva versión de COM: ofrece una completa infraestructura de servicios para
componentes. Los componentes se crean y se instalan en aplicaciones de
COM+ para poder generar aplicaciones escalables de servidor que permitan un
alto rendimiento con una sencilla implementación. (Si un componente no precisa
utilizar algún servicio, no se debe colocar en una aplicación de COM+.) La
escalabilidad y el buen rendimiento se logran diseñando aplicaciones desde el
exte rior para hacer uso de servicios como las transacciones, las agrupaciones
de objetos y la semántica de actividades.
.NET Framework ofrece otra forma de escribir aplicaciones basadas en

componentes y presenta ventajas sobre el modelo de programación de COM,
mejor compatibilidad de herramientas, el tiempo de ejecución en lenguaje común

(CLR) y una sintaxis de codificación mucho más sencilla. Se puede tener acceso
a la infraestructura de servicios de COM+ desde código administrado y no
administrado. Los servicios en código no administrado se conocen como
servicios de COM+. En .NET se hace referencia a estos servicios como
Enterprise Services o servicios empresariales. Derivar una clase de
ServicedComponent indica que los servicios los solicitará un componente. (Si un
componente no necesitara los servicios, no debería derivar de
ServicedComponent.) La compatibilidad de herramientas se ha mejorado para
permitir a los programadores escribir aplicaciones basadas en el servidor,
aunque la escalabilidad y el rendimiento aún pertenecen al campo de las
prácticas de programación. La idea básica que subyace en los servicios es
diseño para el rendimiento y la escalabilidad desde el exterior y
aprovechamiento de los Enterprise Services para una fácil implementación de
dichos patrones de diseño donde sea necesario.
Componentes con servicio
Un componente con servicio es una clase escrita en un lenguaje compatible con

CLS (Common Language Specification) y derivada directa o indirectamente de la
clase:
System.EnterpriseServices.ServicedComponent
Las clases configuradas de esta manera pueden estar alojadas en una

aplicación COM+ y puede utilizar los servicios COM+ por medio del espacio de
nombres EnterpriseServices. En la tabla siguiente se muestra un resumen de
servicios COM+ disponibles.
Los servicios COM+, como las transacciones automáticas o los componentes en

cola se pueden configurar de forma declarativa. Los atributos relacionados con
el servicio se aplican en tiempo de diseño y se crean las instancias de clases

que utilizan esos servicios. Algunos servicios se configuran llamando a métodos en

clases o interfaces relacionadas con el servicio. Ciertos servicios pueden pasar
de un objeto a otro. Por ejemplo, un objeto configurado de manera que requiera
una transacción puede extender esa transacción a un segundo objeto que también
admita o requiera transacciones.
El catálogo COM+ guarda la información de configuración que se aplica a la

implementación de una clase. En tiempo de ejecución, en función de los
atributos que aplique al código, COM+ crea una capa de servicio del contexto. La
siguiente ilustración muestra una transacción automática que pasa entre dos objetos
administrados alojados en COM+.
Aplicación COM+ con componentes con servicio alojados
Los servicios pueden fluir también entre objetos de COM+ y .NET Framework.
Cada entorno controla la implementación y ejecución de su código nativo; COM+
proporciona siempre el contexto del objeto.
Características de los servicios COM+
Una clase configurada posee un conjunto de COM+ estos son atributos

declarativos que especifican los servicios requeridos. En tiempo de ejecución,
COM+ se asegura que provee los servicios requeridos a los objetos. Estos
servicios se proveen mediante “contextos” los cuales se implementan como
objetos llamados “contexto del objeto”. Todas las clases son instanciadas en un
contexto y cada objeto vive precisamente en uno. Las clases que no están
configuradas ignoran sus contextos asociados.
Se tienen dos tipos de aplicaciones COM+:
 Aplicación de biblioteca, que es una colección de clases de componentes,

que cuando son instanciadas, son creadas dentro del proceso del cliente que
llama.
 Aplicación de servidor, que es una colección de clases de componentes, que

cuando son instanciadas son creadas en un proceso subrogado separado del
proceso del cliente que llama.

Una transacción es un conjunto de operaciones que son exitosas o fallidas como

unidad. Si ésta falla se le hace “Rollback” y la data permanece en su estado
original. De ser exitosa se hace un “Commit” y los cambios son tomados en
cuenta. Así de esta manera se preserva la integridad de la información. Las
transacciones en COM+ están a cargo del Coordinador de Transacciones
Distribuidas (Distributed Transaction Coordinator, DTC) el cual es un
componente del sistema operativo Windows.
La activación justo -a-tiempo (JIT) es el mecanismo usado por COM+ para evitar
el consumo de recursos por parte de los componentes mientras éstos están en
estado “ocioso”, es decir, el desarrollador puede instanciar sus objetos COM+ al
principio de su programa y dejarse de preocupar acerca del consumo de estos
ya que solo son activados cuando alguno de los métodos es llamado.
La seguridad es otro punto importante de las aplicaciones COM+. El primer

aspecto es concerniente a la autenticación, lo cual permite establecer
restricciones a quién tiene acceso a la aplicación y su funcionalidad. El otro
aspecto es el modelo de impersonación, en el cual es objeto asume la
información del cliente en el cual ha sido llamado.
Los eventos, mejor conocidos como modelo “publicador-suscriptor”. En este

enfoque se desarrolla una interfaz de eventos el cual se registra en COM+, luego
se procede a registrar las clases que se desean estén en disposición de
manipular los eventos definidos en la interfaz de eventos como sus criptores.
Esta arquitectura es usualmente llamada como eventos débilmente acoplados
“loosely-coupled”.
Pool de objetos, es la característica que permite tener un conjunto de objetos

disponibles para cualquier petición realizada del cliente sin incidir en costos de
creación e instanciación. Una vez “liberado” el objeto por parte del cliente este
vuelve al pool.
Cola de mensajes, permite trabajar en situaciones desconectadas. Este servicio se

encarga de registrar las llamadas a métodos de un cliente al servidor que es
disponible de manera que pueden “volverse” a hacer la llamada cuando el
servidor esté en línea nuevamente. El código del cliente permanece sin tener
conocimiento de que el servidor fue desconectado y los servicios de COM+ están
actuando como intermediarios.
Carga balanceada del componente (CLB) es un equipo con Windows Advanced

Server o Windows Data Server que sirve como administrador de otros servidores en la
granja. El CLB se encarga de distribuir las solicitudes de los objetos entre los
servidores disponibles.

Ejercicio Práctico: Componentes servidos con ensamblados
Para hacer uso de los componentes servidos es necesario utilizar el espacio de

nombres System.EnterpriseServices. Un componente servido de .NET es una
clase diseñada para hacer uso de dicho espacio de nombre y un ensamblado
servido es aquel que contiene al menos un componente servido. Para crear una
clase como un componente servido esta debe derivar de la clase
ServicedComponent y también debe definir un constructor público por defecto.
public class PruebaDeComPlus: ServicedComponent

{
public PruebaDeComPlus()
{
}
}
Hágase saber que para usar el espacio de nombres System.EnterpriseServices

es necesario agregar la referencia manualmente a System.EnterpriseServices.dll
ya sea por agregar referencias en el Visual Studio o agregando
/r:System.EnterpriseServices.dll si se compila desde la línea de comandos.
Los atributos definidos en System.EnterpriseServices son:
 Transaction
 ObjectPooling
 JustInTimeActivation
 EventClass
 ApplicationActivation
Para demostrar los componentes servidos, crearemos una clase que encapsula la
funcionalidad de la aplicación COM+ y crearemos un formulario para proveer una
interfaz gráfica desde el cual se harán las llamadas. A diferencia de otro
ensamblado de .NET estos requieren un tratamiento especial. A continuación se
muestra el conjunto de atributos del archivo AssemblyInfo.cs que han de ser
agregados para que nuestra aplicación pueda funcionar correctamente
(AssemblyInfo.cs del proyecto clsPruebaDeComPlus)
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationAccessControl(false)]
[assembly: ApplicationID("448934a3-324f-34d3-2343-129ab3c43b2c")]
[assembly: ApplicationName("DemoComponenteServido")]
[assembly: Description ("Demostración de COM+ en .NET")]
El primer atributo especifica el tipo de aplicación que es (en este caso esta será
de tipo biblioteca) esta información corresponde a la enumeración de
ActivationOption. El segundo atributo es la manera como se accede al control de

la aplicación. El tercer atributo es el GUID de la aplicación. El cuarto es el

nombre de la aplicación que será anfitrión de nuestro componente cuando este
sea importado a servicios de COM+. El quinto es la descripción del componente.
Hay dos maneras de implementar un ensamblado servido. La manera más

simple es copiar el ensamblado en el directorio de la aplicación COM+ esta
manera es conocida como “Registro dinámico” sin embargo hay un detalle, solo
los administradores podrán hacer uso del mismo ya que el ensamblado no es
colocado en el GAC (Global Assembly Cache). La otra manera es colocarlo en el
GAC y se conoce como “Registro manual”, se requiere que el ensamblado
posea un nombre fuerte (Strong name) y luego usemos el gacutil para
introducirlo en el GAC.
Gacutil -I ensamblado.dll
El próximo paso es registrar explícitamente el ensamblado antes de utilizarlo, esto

se hace mediante RegSvcs.exe. Cuando se ejecuta dicho utilitario contra un
ensamblado de .NET este creará una aplicación COM+ con el nombre
especificado en el atributo ApplicationName antes mencionado.
RegSvcs Componente [COM+App] [TypeLibrary.tlb]
Una vez hecho esto procedemos a probar nuestro aplicación COM+. Como se
muestra a continuación el registro de la aplicación fue exitoso.
Al dirigirnos a la consola de servicios de componentes podemos apreciar que

nuestra aplicación está ahí.

Al ejecutar la aplicación se registra en el visor de sucesos las acciones que se

están llevando a cabo así también ha de suceder si se genera algún error. A
continuación mostramos el visor de sucesos y los eventos generados desde
nuestra aplicación.
Igualmente podemos apreciar los resultados de la consulta procesada por el

componente.

En la consola de servicios de componentes se muestra la aplicación

ejecutándose junto con la aplicación del sistema.
Una manera de comprobar como se esta comportando la aplicación es mediante las

estadísticas de las transacciones. En la carpeta de Coordinador de
transacciones distribuidas y el nodo de estadísticas de transacciones como se
muestra a continuación.

Cada vez que se pulse el botón ejecutar query de nuestro formulario (cliente) se
podrá apreciar como se activan las barras de transacciones activas y se
incrementa la barra de transacciones ejecutadas. Aunque en este artículo solo
recuperamos información la misma técnica aplica para operaciones que tengan que
ver con manipulación (modificación) de la data.
Cuestionario
1. Liste cinco beneficios de soluciones componente-basado.
2. ¿Qué es una aplicación COM+?
3. ¿Para qué se utiliza el catálogo COM+?
4. ¿Qué es el contexto?
5. ¿Qué es ServicedComponent?
3.5.2. Servicios de Transacción
3.5.2.1. Introducción al proceso de la transacción
Una transacción es un conjunto de tareas relacionadas que se realizan de forma

satisfactoria o incorrecta como una unidad. En términos de procesamiento, las
transacciones se confirman o se anulan. Para que una transacción se confirme,

todos los participantes deben garantizar la permanencia de los cambios

efectuados en los datos. Los cambios deben conservarse aunque el sistema se
bloquee o tengan lugar otros eventos imprevistos.
Basta con que un solo participante no pueda garantizar este punto para que la
transacción falle en su totalidad. Todos los cambios efectuados en datos dentro
del ámbito de la transacción se deshacen hasta un punto específico establecido.
Propiedades ACID
El término ACID expresa la función que las transacciones desarrollan en

aplicaciones críticas para una misión. Acuñado por los pioneros en el
procesamiento de transacciones, el acrónimo ACID responde a los términos
atomicidad (atomicity), coherencia (consistency), aislamiento (isolation) y
permanencia (durability).
Estas propiedades garantizan un comportamiento predecible, reforzando la

función de las transacciones como proposiciones de todo o nada diseñadas para
reducir la carga de administración cuando hay muchas variables.
Atomicidad
Una transacción es una unidad de trabajo en la que se produce una serie de

operaciones entre las instrucciones BEGIN TRANSACTION y END
TRANSACTION de una aplicación. Una transacción se ejecuta exactamente una vez
y tiene carácter "atómico" (de subdivisión), es decir, el trabajo se realiza en su
totalidad o no se realiza en ningún caso.
Las operaciones asociadas a una transacción comparten normalmente un

objetivo común y son interdependientes. Si el sistema ejecutase únicamente una
parte de las operaciones, podría poner en peligro el objetivo final de la
transacción. La atomicidad elimina la posibilidad de procesar un subconjunto de
operaciones.
Coherencia
Una transacción es una unidad de integridad porque mantiene la coherencia de los

datos, transformando un estado coherente de datos en otro estado de datos
igualmente coherente.
La coherencia requiere que los datos enlazados mediante una transacción se

mantengan en términos de semántica. Una parte de la responsabilidad para
mantener la coherencia recae en el programador de la aplicación que debe
asegurarse de que ésta exija todas las restricciones de integridad conocidas. Por
ejemplo, en el desarrollo de una aplicación en la que se transfiere dinero, se

debe evitar el desplazamiento arbitrario de los puntos decimales durante la

transferencia.
Aislamiento
Una transacción es una unidad de aislamiento, permitiendo que transacciones

concurrentes se comporten como si cada una fuera la única transacción que se
ejecuta en el sistema.
El aislamiento requiere que parezca que cada transacción sea la única que
manipula el almacén de datos, aunque se puedan estar ejecutando otras
transacciones al mismo tiempo. Una transacción nunca debe ver las fases
intermedias de otra transacción.
Las transacciones alcanzan el nivel máximo de aislamiento cuando se pueden

serializar. En este nivel, los resultados obtenidos de un conjunto de
transacciones concurrentes son idénticos a los obtenidos mediante la ejecución en
serie de las transacciones. Como un alto grado de aislamiento puede limitar el
número de transacciones concurrentes, algunas aplicaciones reducen el nivel de
aislamiento en el intercambio para mejorar el rendimiento.
Permanencia
Una transacción también es una unidad de recuperación. Si una transacción se

realiza satisfactoriamente, el sistema garantiza que sus actualizaciones se
mantienen aunque el equipo falle inmediatamente después de la confirmación.
El registro especializado permite que el procedimiento de reinicio del sistema
complete las operaciones no finalizadas, garantizando la permanencia de a
transacción.
Transacciones distribuidas
Los sistemas de procesamiento de transacciones (TP) distribuidas se diseñan

para facilitar las transacciones que abarcan recursos heterogéneos relacionados
con transacciones en un entorno distribuido. Un sistema TP de transacciones
distribuidas permite a la aplicación combinar en una unidad transaccional
actividades tan diferentes como la recuperación de un mensaje de una cola de
Message Queuing, el almacenamiento del mensaje en una base de datos de
Microsoft SQL Server y la eliminación de todas las referencias existentes al
mensaje en una base de datos de Oracle Server. Como abarcan varios recursos
de datos, es importante que las transacciones distribuidas exijan las propiedades
ACID para mantener la coherencia de los datos en todos los recursos.
Un sistema TP de transacciones distribuidas está formado por varias entidades

cooperadoras, como se describe en las secciones que figuran a continuación.

Estas entidades son lógicas y pueden residir en el mismo equipo o en equipos

diferentes.
Supervisores del procesamiento de transacciones (TP)

Un supervisor TP consiste en software que se sitúa entre una aplicación
relacionada con transacciones y una colección de recursos. Maximiza las
actividades del sistema operativo, simplifica las comunicaciones de red y
conecta varios clientes con varias aplicaciones que tienen acceso potencial a
varios recursos de datos.
En lugar de crear una aplicación que administre un entorno distribuido

multiusuario, se crea una aplicación formada por solicitudes de transacciones
únicas. El supervisor cambia el tamaño de la aplicación según proceda.
El supervisor TP para Microsoft Windows 2000 es DTC (Coordinador de
transacciones distribuidas).
Administradores de transacciones
En una transacción distribuida, cada recurso participante tiene un administrador
de transacciones (TM) local para efectuar el seguimiento de las transacciones
entrantes y salientes en el equipo. El supervisor TP asigna a un TM la tarea
adicional de coordinar todas las actividades entre TM locales. El TM que
coordina las actividades de transacción recibe el nombre de TM principal o
coordinador.
Un TM coordina y administra todas las funciones del procesamiento de

transacciones, pero no está preparado para administrar datos directamente. Los
administradores de recursos controlan las actividades relacionadas con datos.
Administradores de recursos
Un administrador de recursos es un servicio de sistema que administra datos
persistentes o permanentes en bases de datos, colas de mensajes permanentes o
sistemas de archivos transaccionales. El administrador de recursos almacena datos
y realiza su recuperación ante un error del sistema.
SQL Server y Message Queuing proporcionan administradores de recursos que

participan en transacciones distribuidas. Oracle, Sybase, Informix, IBM (para IBM
DB2) e Ingres también proporcionan administradores de recursos
compatibles para los correspondientes productos de base de datos.
Dispensadores de recursos
Un dispensador de recursos administra los estados no permanentes que pueden
aparecer en las transacciones. Por ejemplo, el dispensador de recursos de Open
Database Connectivity (ODBC) administra grupos de conexiones de bases de
datos, reclamando cada conexión cuando deja de ser necesaria.

3.5.2.2. Servicios de transacciones de .NET
Una de las ventajas de utilizar COM+ para albergar componentes es la

posibilidad de cambiar el comportamiento de dichos componentes sin tener que
escribir nuevo código, por ejemplo para marcar la compatibilidad de
transacciones de un componente como Requerida. Al definir un botón de opción
en un componente COM+ dentro del complemento de servicios de componentes
MMC cada vez que se crea el componente, el proceso tiene lugar en el contexto
de una transacción COM+. Cuando un compone nte utiliza transacciones COM+,
todas las transacciones de bases de datos están controladas por el Coordinador
de transacciones distribuidas (DTC). La figura muestra un ejemplo de selección
de la opción de transacción necesaria dentro de la interfaz de Servicios de
componente.
Componente COM+ de ejemplo que requiere una transacción
Definir la seguridad para el componente resulta tan fácil como definir la

compatibilidad de transacciones. Se puede decidir qué usuarios podrán ejecutar
cada componente, e incluso cada método, sin necesidad de volver a compilar el
código. Estas opciones se seleccionan mediante el complemento de servicios
COM+.

Ejercicio Práctico: Creación de un componente de transacciones COM+
Hay una serie de pasos que se deben seguir para obtener un componente .NET
que funcione con servicios COM+. Para empezar, debemos crear una clase que
se derive de la clase System.EnterpriseServices.ServicedComponent. Esta clase
de base proporciona todos las propiedades y los métodos necesarios para
interactuar con los servicios COM+. Deberemos marcar la clase para que
requiera una nueva transacción y los métodos creados para que puedan
completar la transacción automáticamente si no se producen errores. Vamos a
ponerlo en práctica:
Abra Microsoft Visual Studio .NET y cree un nuevo proyecto ClassLibrary.
Cambie el nombre del archivo Clase1.vb a COMPlusServices.vb.
Abra el archivo COMPlusServices.vb y cambie el nombre de clase de Clase1 a

COMPlusServices.
Escriba el siguiente código en esta nueva clase:
Imports System.EnterpriseServices
Imports System.Reflection
'*** **
'Detalles de registro de COM+
'Nombre de la aplicación COM+

<Assembly: ApplicationNameAttribute("ComPlusExample")>
'Ensamblado de nombre seguro

<Assembly: _
AssemblyKeyFileAttribute("bin/ComPlusExample.snk")>
'*** **
<TransactionAttribute(TransactionOption.Required)> _
Public Class COMPlusServices
Inherits ServicedComponent
Public Sub New()

MyBase.New()
End Sub
<AutoComplete()> Public Function DoTransaction() _ As

String
Return "COM+ funciona correctamente"
End Function
End Class

Este código empieza importando un par de espacios de nombre para tener que
escribir menos al declarar componentes.
5. A continuación tienen lugar los detalles de registro de COM+. Introduzca

la siguiente línea de código:
'Proporcionar el nombre de aplicación COM+

<Assembly: ApplicationNameAttribute("ComPlusExample")>
Esta línea asigna un valor de ComPlusExample a ApplicationNameAttribute. Este

es el nombre de la aplicación COM+ una vez que se haya registrado en el catálogo
COM+. Después de la primera vez que se llama a este componente, al abrir la
carpeta de aplicaciones COM+ en el complemento MMC, lo verá como nombre de
aplicación.
La siguiente parte del código declara el atributo AssemblyKeyFileAttribute:
<Assembly: _ AssemblyKeyFileAttribute("bin/ComPlusExample.snk")>
Este código indica al catálogo COM+ la ubicación del nombre seguro. El archivo
.SNK, que crearemos más tarde, es el que describe el componente para COM+.
A continuación, crearemos por fin el nombre de clase, COMPlusServices,

utilizando el código siguiente.
<TransactionAttribute(TransactionOption.Required)> _
Public Public Class COMPlusServices
El atributo junto a este nombre de clase indica a COM+ que desea definir el
atributo de transacción como Necesario. Agregar esta línea de código es lo
mismo que abrir el complemento de aplicaciones COM+ y definir este atributo de
forma manual, como se muestra en la figura de la sección anterior.
La siguiente línea de código en la clase hereda de ServicedComponent dentro del

espacio de nombres System.EnterpriseServices.
Inherits ServicedComponent
Si no incluye esta línea, no podrá hacer que funcione este componente bajo
COM+.
Adición de un método de transacción
Una vez que la configuración de esta clase se haya completado, puede crear un
método que efectúe alguna acción. La función DoTransaction en el código

escrito devuelve un valor de cadena, pero mostrará la sintaxis que debe

utilizarse para que este método participe en la transacción.
<AutoComplete()> Public Function DoTransaction() As String

Return "COM+ funciona correctamente"
End Function
Es importante anteponer este método con el atributo <AutoComplete()>. Esto

significa que mientras no haya una excepción en este método, se llamará
automáticamente a SetComplete cuando el método termine. Si se produjera una
excepción en el método, el tiempo de ejecución de .NET llamaría al método
SetAbort de forma automática.
Creación de un nombre seguro
Antes de compilar el componente, es necesario asignar un nombre seguro al

ensamblado de dicho componente. De lo contrario, el catálogo COM+ no
reconocerá al componente y no podrá registrarlo. En realidad, ya hemos hecho esto
con el atributo AssemblyKeyFile que utilizamos anteriormente, pero ahora
necesitamos crear el nombre seguro y asignarle un GUID con el ensamblado
utilizando la Herramienta de nombre seguro (Sn.exe).
1. Abra una línea de comandos.
2. Para crear el nombre seguro, introduzca lo siguiente en la línea de

comando y, a continuación, presione Intro.
sn -k ComPlusExample.snk
3. Copie el archivo ComPlusExample.snk del directorio raíz del disco duro

(seguramente C:/) en el directorio bin dentro de la carpeta donde se
encuentre el proyecto.
Ahora necesitará compilar este programa para generar los archivos necesarios y
registrar este componente con COM+. En Visual Studio .NET, en el menú
Generar, haga clic en Generar.
Generación de una aplicación cliente de ejemplo
Una vez generado el componente, necesitará generar una aplicación cliente para
llamar a este componente y comprobar su funcionamiento. Cree una aplicación
de consola simple en la que el método Main del archivo de módulo cree una
instancia del nuevo componente y llame al método DoTransaction(). Los principales
pasos son los siguientes:
1. En Visual Basic .NET, cree un nuevo proyecto de aplicación de consola.

2. Agregue una referencia al componente que ha creado.
3. Escriba el siguiente código:
Module modMain
Sub Main()
Dim objCOMPlus As New _
COMPlusJumpStart.COMPlusServices()
Console.WriteLine(objCOMPlus.DoTransaction)
Console.ReadLine()
End Sub
End Module
Prueba
Por último estamos ya preparados para ejecutar esta aplicación y comprobar su

funcionamiento.
1. Abra el complemento de servicios de componentes MMC y compruebe

que su componente se registró dinámicamente en el catálogo COM+.
Debería ver algo similar a la figura siguiente.
2. Compile y ejecute la aplicación de consola.
El nuevo componente atendido por .NET en el catálogo COM+

Cuestionario
1. Nombre las cuatro propiedades ACID de transacciones.
2. ¿Cuál es el servicio de transacciones distribuidas coordinadas para las

aplicaciones COM+?
3. Liste las configuraciones de atributo de transacción que un componente

COM+ puede tener.
4. ¿Qué pasa a un componente si una llamada a uno de sus métodos

regresa y su bit dispuesto se ha establecido en True?
5. ¿Cómo puede crear un cliente que no hereda desde la clase

ServicedComponent para los servicios de transacciones de .NET?
6. Nombre los cuatro niveles de aislamiento de transacción soportados para

los componentes servidos.
3.5.3. Seguridad en Aplicaciones
3.5.3.1. Introducción a la seguridad de la aplicación
Seguridad de acceso al código (CAS)
La seguridad de .NET Framework ofrece la posibilidad de que el código tenga

acceso a los recursos únicamente si se le concede permiso para ello. .NET
Framework emplea el concepto de permisos para expresar esta característica,
que representa el derecho del código para utilizar recursos protegidos. El código,
por su parte, solicita los permisos que le son necesarios. Y .NET Framework le
concede las clases de permisos de acceso. Alternativamente, se pueden escribir
las clases de permisos personalizadas. Los permisos se pueden emplear para
indicar a .NET Framework exactamente para qué recursos y tareas necesita el
código autorización. Cualquier ruta de código a través de
System.EnterpriseServices solicita permisos de código no administrado.
La seguridad de acceso al código en .NET es muy útil en el caso de las

aplicaciones en las que el código se descarga desde Internet y su autor no
resulta de mucha confianza. Típicamente, las aplicaciones que utilizan
componentes facilitados como servicio son de completa confianza, requieren
que se dé el flujo de la seguridad entre múltiples procesos y permiten la
configuración de las funciones durante la fase de implementación. Estas son las
características expuestas por la seguridad basada en funciones de COM+.

Cualquier ruta de código a través de System.EnterpriseServices solicita

permisos de código no administrado. Esto implica lo siguiente:
 Es necesario contar con permisos de código no administrado para poder

activar y realizar llamadas de contexto cruzado en los componentes
facilitados como servicio.
 Si se pasa una referencia a un componente facilitado a un código que no

resulta de confianza, no se puede llamar a los métodos definidos en
ServicedComponent desde él. Sin embargo, sí que se puede llamar a los
métodos personalizados definidos en una clase derivada de
ServicedComponent en ciertas circunstancias: las llamadas desde código
que no es de confianza se pueden realizar en aquellos métodos
personalizados que no requieren el cambio de contexto, servicios de
intercepción y si su implementación no realiza llamadas a los miembros de
System.EnterpriseServices.
Asimismo, en la versión 1 de .NET, la pila de seguridad no se copia cuando tiene

lugar un cambio de subproceso, por lo que los permisos de seguridad
personalizados no se deben emplear con los componentes facilitados como
servicio.
Seguridad basada en funciones (RBS)
System.EnterpriseServices ofrece unos servicios de seguridad a los objetos de .NET

que reflejan la funcionalidad de los mecanismos de seguridad de COM+. Cuando
una aplicación de servidor de COM+ se emplea para alojar los componentes,
las características de RBS requieren que el protocolo de transporte de DCOM
se utilice para activar los componentes desde un cliente remoto. En la siguiente
sección se proporciona más información sobre el acceso remoto. La identidad y el
contexto de llamadas de seguridad de COM+ se encuentran por tanto
disponibles en el código administrado. Además, CoImpersonateClient,
CoInitializeSecurity y CoRevertClient son llamadas conocidas que se emplean
por norma general en el lado del servidor, mientras que CoSetProxyBlanket sólo se
utiliza con el cliente.
Ciertas opciones de seguridad no se almacenan en los metadatos utilizando
atributos, por ejemplo, agregando usuarios a funciones y estableciendo la
identidad de la seguridad del proceso. Sin embargo, los atributos de nivel de
ensamblado se pueden emplear para configurar lo que aparece en la ficha de
seguridad del explorador de COM+ para una aplicación de servidor de COM+:
Habilitar la autorización en la aplicación
(ApplicationAccessControlAttribute(bool)). Se debe establecer como true para
que ofrezca compatibilidad con RBS.

El nivel de seguridad
(ApplicationAccessControlAttri bute(AccessChecksLevelOption)). Si se establece

en AccessChecksLevelOption.Application, los usuarios asignados a las
funciones en la aplicación se agregan al descriptor de seguridad del proceso, y
la comprobación detallada de las funciones en los niveles de componente,
método e interfaz se desactiva. Las comprobaciones de la seguridad se llevan a
cabo, por tanto, sólo a nivel de la aplicación y las aplicaciones de biblioteca
confían exclusivamente en el proceso de host para la seguridad a nivel de
proceso. Si el atributo se define en
AccessChecksLevelOption.ApplicationComponent, entonces los usuarios
asignados a las funciones en la aplicación se agregan al descriptor de la
seguridad del proceso y las comprobaciones de la seguridad basada en
funciones se realizan en la aplicación. Asimismo, estas comprobaciones se
deben habilitar para cada componente que requiera RBS mediante la aplicación
del atributo ComponentAccessControl en la clase. En una aplicación de
biblioteca, las comprobaciones de la seguridad basada en funciones se realizan
como si se tratara de una aplicación de servidor. La propiedad de seguridad se
incluye en el contexto para todos los objetos de la aplicación y el contexto de la
llamada de seguridad se encuentra disponible. Si un objeto cuenta con una
configuración con el contexto de su creador, se activa en su propio contexto. La
seguridad basada en funciones programática se basa en la disponibilidad del
contexto de llamada de seguridad.
Para que una comprobación de acceso significativa funcione en las aplicaciones de
biblioteca de COM+, seleccione realizarlas a nivel de componente y proceso. Las
selecciones de representación y autenticación corresponden a las propiedades
ImpersonationLevel y Authentication del atributo
ApplicationAccessControl.
El atributo SecurityRole se puede aplicar al nivel de ensamblado, clase o

método. Cuando se aplica a nivel de ensamblado, los usuarios de esa función
pueden activar cualquier componente de la aplicación. Cuando se aplica a nivel
de clase, los usuarios de esa función pueden, además, llamar a cualquier
método del componente. Las funciones de nivel de clase y aplicación se pueden
configurar en metadatos, o administrativamente, mediante el acceso al catálogo
COM+.
Configuración de RBS a nivel de ensamblado mediante metadatos:
[assembly: ApplicationAccessControl(true,
AccessCheckLevel=AccessChecksLevelOption.ApplicationComponent)] //
agrega NTAuthority\everyone a esta función
[assembly:SecurityRole("TestRole1",true)]
// agrega usuarios a las funciones administrativamente
[assembly:SecurityRole("TestRole2")]
Configuración de RBS a nivel de clase en metadatos:

AccessCheckLevel=AccessChecksLevelOption.ApplicationComponent)]
…
[ComponentAccessControl()]
[SecurityRole ("TestRole2")]
public class Foo : ServicedComponent
{
public void Method1() {}
}
RBS en los niveles de clase o ensamblado se puede configurar

administrativamente puesto que dichas entidades existen en el catálogo COM+
después del registro del ensamblado. No obstante, como se mencionó
anteriormente, los métodos de clase no aparecen en el catálogo COM+. Para
configurar RBS en los métodos, la clase debe implementar los de una interfaz y
emplear el atributo SecureMethod en el nivel de clase, o bien SecureMethod o
SecurityRole en el nivel de método. Además, los atributos deben aparecer en la
implementación de métodos de clase, no el método de interfaz en la definición
de la misma.
La forma más sencilla de utilizar RBS en los métodos es aplicar el atributo
SecureMethod en el nivel de clase y, a continuación, configurar las funciones (ya
sea administrativamente o colocando el atributo SecurityRole en los métodos).
Interface IFoo
{
void Method1();
void Method2();
}
[SecureMethod]
public class Foo : ServicedComponent, IFoo
{
// Agregar funciones a este método administrativamente
// "RoleX" se agrega al catálogo para este método
SecurityRole("RoleX")
}
El uso de SecureMethod a nivel de clase permite configurar administrativamente

todos los métodos de las interfaces con las funciones del catálogo COM+. Si la
clase implementa dos interfaces, cada una de ellas con el mismo nombre de
método, y las funciones se configuran administrativamente, será necesario
establecerlas en ambos métodos como aparecen en el catálogo COM+ (a menos

que la clase implemente el método específico, por ejemplo, IF oo.Method1). Sin

embargo, si se emplea el atributo SecurityRole en el método de clase, todos los
métodos con el mismo nombre se configuran automáticamente con esa función
cuando se registre el ensamblado.
El atributo SecureMethod también se puede colocar en el nivel de método.
Interface IFoo
{
void Method1();
void Method2();
}
public class Foo : ServicedComponent, IFoo
{
// Agregar funciones a este método administrativamente
[SecureMethod] // O utilizar SecurityRole (se traduce en
SecureMethod++)
}
En el ejemplo, IFoo y ambos métodos aparecen en el catálogo COM+ y por tanto las
funciones se pueden configurar administrativamente en cualquier método, si bien, el
RBS de nivel de método sólo se fuerza en Method1. Utilice SecureMethod
o SecurityRole en todos los métodos que se requerirán para participar en la
seguridad RBS a nivel de método, o bien, coloque SecureMethod en el nivel de
método como se señaló anteriormente.
Siempre que se configura RBS a nivel de método, se solicita la función
Marshaller: cuando se realizan llamadas a métodos y RBS no se ha configurado
en éstos, la infraestructura de componentes facilitados como servicio realiza las
llamadas en IRemoteDispatch. Cuando se realizan y RBS se ha configurado en
los métodos (cuando el atributo SecureMethod está presente), la llamada tiene
lugar utilizando DCOM con la interfaz asociada al método. Por consiguiente,
DCOM garantiza que RBS se fuerza a nivel de método. No obstante, como se
comentó en las secciones Activación e Intercepción, la interoperabilidad COM y
RSCP realizarán las llamadas en IManagedObject (para poder permitir que los
activadores remotos activen la referencia en su espacio) y en
IServicedComponentInfo (para realizar consultas al objeto remoto). Estas
interfaces se asocian a los componentes facilitados como servicio. Puesto que el
componente se configura para que realice comprobaciones a nivel de método, es
necesario asociar una función a estas interfaces si se desea que la
infraestructura realice las llamadas correctamente.
Por ello se agrega una función Marshaller a la aplicación cuando se registra el
ensamblado; a continuación, se deberá agregar a los usuarios

administrativamente a la misma. En la mayoría de las ocasiones son todos los

usuarios de la aplicación los que se incorporan a dicha función. Resulta algo
distinto a lo que ocurría co n COM+ no administrado, donde la configuración de
RBS en los métodos no requería este pasó de configuración adicional.
Incorporar automáticamente a todos los usuarios a esta función durante la fase
de registro constituye un riesgo potencial, puesto que ahora cualquiera podría
activar (pero no llamar) los componentes donde antes no tenía derechos. La
función Marshaller también se agrega a la interfaz IDisposable para permitir a los
clientes deshacerse del objeto. Una alternativa a esta función es que los
usuarios agreguen las funciones relevantes a cada una de las tres interfaces
mencionadas.
3.5.3.2. Implementación de seguridad basada en función de COM+
Cuando hay muchos usuarios enviando llamadas a componentes COM que

funcionan bajo COM+, es necesario comprobar que sólo los usuarios
especificados tienen acceso a ciertos componentes. COM+ permite definir
funciones y asignarles usuarios de NT. Una vez que estas funciones se han
definido, puede asignar las funciones que funcionarán con cada componente e
incluso qué métodos de cada componente se pueden ejecutar.
Vamos a agregar un método a esta misma clase COMPlusServices para

incorporar seguridad basada en funciones. Crearemos una función llamada
Managers (Supervisores) y comprobaremos si el usuario que efectúa la llamada está
en la función Managers en el nuevo método.
Pasos para agregar seguridad basada en funciones
En lugar de modificar directamente la aplicación COM+ desde el complemento

de servicios de componentes MMC para agregar la función de seguridad,
agregaremos un nuevo atributo al proyecto. Utilizaremos la clase
SecurityRoleAttribute para agregar la nueva función de Managers. El constructor
para esta clase tiene dos argumentos: role (cadena) y everyone (booleano). El
argumento role especifica la función que se creará y el argumento everyone
especifica si el grupo integrado Everyone se agrega o no a los usuarios de la
función.
Agregue una nueva función de seguridad a la aplicación COM+ introduciendo el

siguiente código justo debajo del comentario de detalles de registro de COM+.
'*** **
'Atributo de seguridad basada en funciones
<Assembly: SecurityRoleAttribute("Managers", False)>

1. Cambie el nivel de seguridad para realizar comprobaciones de acceso en los

procesos y en los componentes. Esto permite a la aplicación COM+ tener un
contexto de llamadas de seguridad.
2. Traiga a primer plano el complemento de servicios COM+.
3. Haga clic en la ficha Seguridad y cambie el nivel de seguridad, como se
muestra en la figura.
Definir la propiedad de nivel de seguridad en el catálogo COM+
Como alternativa al proceso manual, se puede agregar un atributo al

componente ordenándole que realice comprobaciones de acceso. El código
siguiente debe agregarse en la sección de detalles de registro de COM+, en la parte
superior de la clase COMPlusServices.
<Assembly: ApplicationAccessCont rolAttribute

(AccessChecksLevel:=AccessChecksLevelOption.ApplicationComponent)>

Comprobación de funciones de seguridad
Ahora agregaremos un nuevo método a la clase denominado IsManager. Este

método comprobará si el usuario es miembro de la función Managers. El método
consiste en una función que devuelve un valor booleano que indica si el usuario
que ejecuta la llamada forma parte o no de la función Managers. Para obtener
acceso al contexto de seguridad del usuario que llame al método, es necesario
utilizar la clase SecurityCallContext. Llamando al método CurrrentCall se obtiene
el contexto del usuario actual. A continuación, llamaremos al método
IsCallerInRole, pasando Managers como nombre de la función.
Agregue el método indicado a continuación a la clase COMPlusServices.
Public Function IsManager() As Boolean

Dim objCallContext As SecurityCallContext = _SecurityCallContext.CurrentCall
IsManager = _ objCallContext.IsCallerInRole("Managers")
End Function
A continuación, será necesario volver a generar el componente y probar este

nuevo método.
Desde el menú Generar de Visual Studio .NET, haga clic en Volver a generar
solución.
Prueba
Modifique el código del método Sub Main() en la aplicación cliente de consola. El

código debería ser similar a este:
Sub Main()
Dim objCOMPlus As New _
COMPlusJumpStart.COMPlusServices()
Console.WriteLine(objCOMPlus.IsManager().ToString)
Console.ReadLine()
End Sub
1. Ejecute la aplicación de consola desde el símbolo de sistema introduciendo

el nombre del archivo ejecutable que hemos compilado.
La primera vez que se ejecuta el código, se obtendrá una excepción que indica
que se denegó el acceso porque no se ha agregado ningún usuario a la función
Managers. Para resolver este problema, hay que agregar el usuario actual a
Managers y volver a ejecutar la aplicación. Una vez hecho esto, no debería
producirse la excepción. Es conveniente agregar código de control de
excepciones. La aplicación cliente debería tener este aspecto con el código de
control de excepciones:

Sub Main()
Try
Dim objCOMPlus As New _ COMPlusJumpStart.COMPlusServices()
Console.WriteLine(objCOMPlus.IsManager().ToString)
Console.ReadLine()
Catch objException As Exception
Console.WriteLine("Se produjo un error. " _ & "Detalles: "
_&objException.Message)
Console.ReadLine()
End Try
End Sub
3.5.3.3. Autenticación y personificación
La seguridad se refiere al control del acceso a una variedad de recursos, como

componentes de la aplicación, datos y hardware. La mayoría de las medidas de
seguridad se basan en cuatro conceptos:
Autenticación
La autenticación es el proceso de confirmación de la identidad, que es la primera

capa del controlde seguridad. Antes de que una aplicación pueda autorizar el
acceso a un recurso, debe confirmar la identidad del solicitante. El solicitante
establece una identidad aportando algún tipo de credenciales, que sólo conocen
el solicitante y el host que autentica. En algunos casos, puede que el solicitante
desee verificar la identidad del host que autentica, lo que se denomina
autenticación mutua.
Autorización
La autorización es el proceso que consiste en verificar si un usuario autenticado

tiene permiso para obtener acceso a un recurso determinado, siendo ésta la
siguiente capa de seguridad tras la autenticación. La confirmación de la
identidad del solicitante por parte del host que autentica no implica
necesariamente que el solicitante autenticado tenga los permisos necesarios
para obtener acceso a un recurso determinado. Por ejemplo, suponga que un
equipo ATM le autentica a través de una combinación de su tarjeta ATM y NIP.
Aún así, sólo estará autorizado para obtener acceso a su cuenta bancaria. Para
obtener más información.
Protección de datos
La protección de datos es el proceso que consiste en proporcionar
confidencialidad, integridad y no repudio a los datos. Los datos requieren
protección no sólo cuando están en tránsito sino también cuando están

almacenados. Independientemente de la forma que tengan los datos, una vez que
entran en canales de comunicación no protegidos, se vuelven vulnerables a los
ataques.
El cifrado de los datos proporciona confidencialidad a éstos. El cifrado de datos

utiliza un algoritmo de cifrado junto con una clave de cifrado con el fin de que los
datos no tengan valor para las personas que no dispongan del algoritmo y de la
clave correcta para descifrar los datos. La clave de cifrado es una variable
adicional que se utiliza en el algoritmo. Una clave de cifrado contiene un valor
numérico limitado por el número de bits que contiene la clave. Aunque una clave
de 40 bits contiene 240 ó 1.099.511.627.776 valores de clave posibles, un equipo
normal podría realizar una búsqueda exhaustiva de todos los valores de clave
posibles en aproximadamente una semana. Sin embargo, si la clave de cifrado
se compone de 128 bits, para que se produzca un ataque por fuerza bruta se
tendrían que probar hasta 2128 o 3,4 x 1038 valores. Cada bit adicional duplica el
número de valores posibles. Las claves de cifrado permiten que varios usuarios
utilicen un algoritmo público sin que afecte a los datos cifrados con el algoritmo.
Dado que la clave de cifrado determina el rigor del cifrado, todos los algoritmos
de cifrado son vulnerables a los ataques por fuerza bruta. Estos ataques
consisten en el intento sistemático de descifrar los datos utilizando todas las
claves posibles. Por ejemplo, si la clave de cifrado utilizada para cifrar los datos
sólo se compone de cuatro bits, para que se produzca un ataque por fuerza
bruta que afecte a los datos sólo tienen que probarse hasta dieciséis valores de
clave de cifrado. Para obtener más información, vea Criptografía.
La integridad de los datos se obtiene mediante algoritmos hash, firmas digitales y
códigos de autenticación de mensajes.
Para garantizar la integridad de los datos, puede enviarse un hash de dichos

datos para que los acompañe. El receptor podrá entonces comparar el hash que
calcula en función de los datos recibidos con el hash que acompaña a los datos
recibidos. Si ambos coinciden, los datos recibidos deberán ser los mismos que
los datos a partir de los cuales se creó el hash recibido. Un hash es una cadena
de números y caracteres que tiene una longitud fija. Se calcula utilizando un
algoritmo hash, como MD5 (Message Digest 5) o SHA -1 (Secure Hash
Algorithm). El cálculo del hash es una operación unidireccional que no se puede
invertir para volver a crear los datos originales.
La firma digital va un paso más allá del simple cálculo del hash y cifra el hash
calculado utilizando una clave privada. Este paso adicional puede impedir que
un atacante intercepte los datos y el hash que los acompaña, modifique los
datos y, después, simplemente vuelva a calcular el nuevo hash de los datos
modificados. Como una firma digital es un hash cifrado, el atacante necesitaría
obtener acceso a la clave privada original utilizada para crear la firma digital
original. Las firmas digitales pueden verificarse en el receptor final mediante la
clave pública asociada. Las firmas digitales pueden utilizarse para exigir la no

repudiación de los datos, que puede utilizarse más adelante para comprobar el
origen, contenido y marca de hora de los datos. Para obtener más información, vea
Algoritmos hash y firmas digitales.
Algunas tecnologías, como SSL/TLS, utilizan códigos de autenticación de

mensajes (MAC) para verificar que no se han modificado los datos mientras
estaban en tránsito. Sin embargo, como los códigos MAC utilizan una clave
común para el cifrado y la verificación, no pueden utilizarse para exigir la no
repudiación de los datos. Para obtener más información, vea Códigos de
autenticación de mensajes de canal S.
Auditoría
La auditoría es el proceso que consiste en registrar y supervisar los eventos que se

producen en un sistema y que son importantes para la seguridad. La auditoría
constituye una fuente clave para el estudio de la seguridad. Para obtener más
información, vea Registro de eventos.
Lamentablemente, la auditoría es un proceso pasivo que sólo puede detectar
problemas de seguridad una vez que la aplicación se vea afectada. Puede
llevarse a cabo una supervisión activa mediante el Monitor de rendimiento de
Windows para que se realicen comentarios en tiempo real. Para obtener más
información, vea Supervisión del rendimiento.
Cuestionario
1. ¿Si la seguridad se habilita para una aplicación COM+, cómo determina el

COM SCM si un cliente particular es permitido para comenzar una
aplicación servidor COM+?
2. ¿Cómo un objeto de Servicios .NET puede programáticamente tomar

decisiones basadas en el rol de miembros solicitantes?
3. ¿Cómo un objeto de Servicios .NET puede obtener detalles relacionando

el aumento de flujo de solicitantes?
4. ¿Qué configuraciones de seguridad de una biblioteca de aplicación

hereda de su proceso huésped y cuál puede anularse específicamente?

3.5.4. Componentes en Cola
3.5.4.1. Introducción a la creación de colas
El servicio de componentes en cola de COM+ proporciona una manera fácil de llamar

y ejecutar compone ntes de manera asincrónica utilizando Microsoft Message
Queuing. El procesamiento se puede producir independientemente de la
disponibilidad o accesibilidad del remitente o el receptor.
Para utilizar este servicio, la clase debe derivar directa o indirectamente de la clase
System.EnterpriseServices.ServicedComponent.
La propiedad MaxListenerThreads indica el número máximo de subprocesos
simultáneos de agente de escucha de componentes en cola. El intervalo válido
para este valor va de 0 a 1000. Para una aplicación recién creada, el valor deriva
del algoritmo usado actualmente para determinar el número predeterminado de
subprocesos de agente de escucha: 16 multiplicado por el número de unidades
de procesamiento (CPU) del servidor. Este valor no impone el número de
subprocesos que se ejecutan en todo momento, sólo el número máximo de
subprocesos posibles. En un servidor inactivo sólo habría un subproceso en
ejecución hasta que se encontraran más mensajes en la cola. Entonces, el
servidor crearía más subprocesos según fuera necesario hasta llegar al valor de
MaxListenerThreads. En el ejemplo siguiente se establece en 64 el número
máximo de subprocesos de agente de escucha de componentes en cola.
Nota La cadena proporcionada al método Marshal.BindToMoniker puede
contener parámetros opcionales para especificar el nombre del equipo así como otro
tipo de información. Vea la sección "Desarrollar componentes en cola" de Platform
SDK si desea obtener más información.
[Visual Basic]
<ApplicationQueuingAttribute(QueueListenerEnabled := _
true, MaxListenerThreads := 64 )>
[C#]
[ApplicationQueuingAttribute(QueueListenerEnabled = true, MaxListenerThreads
= 64 )]
En el ejemplo siguiente que se compone de dos partes, se muestra cómo se

implementa una clase QComponent en el servidor para mostrar un mensaje de
manera asincrónica y se utiliza un cliente para llamar al método DisplayMessage en un
componente en cola.
Servidor
[Visual Basic]
Imports System.Reflection
Imports System.EnterpriseServices
Imports System

<assembly: A pplicationName("QCDemoSvr")>
<assembly: ApplicationActivation(ActivationOption.Server)>
<assembly: ApplicationQueuing(Enabled := True, _
QueueListenerEnabled := True)>
<assembly: AssemblyKeyFile("QCDemoSvr.snk")>
Namespace QCDemo
Public Interface IQComponent
Sub DisplayMessage(msg As String)
End Interface
<InterfaceQueuing(Interface := "IQComponent")> _
Public Class QComponent
Inherits ServicedComponent Implements IQComponent
Public Sub DisplayMessage(msg As String) implements _
IQComponent.DisplayMessage
MessageBox.Show(msg, "Processing message")
End Sub 'DisplayMessage
End Class
End Namespace
[C#]
using System.Reflection;
using System.EnterpriseServices;
[assembly: ApplicationName("QCDemoSvr")]
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationQueuing(Enabled=true, QueueListenerEnabled=true)]
[assembly: AssemblyKeyFile("QCDemoSvr.snk")]
namespace QCDemo
{
public interface IQComponent
{
void DisplayMessage(string msg);
}
[InterfaceQueuing(Interface = "IQComponent"]
public class QComponent : ServicedComponent, IQComponent
{
public void DisplayMessage(string msg)
{
MessageBox.Show(msg, "Processing message");
}
}
}

Client
[Visual Basic]
Protected Sub Send_Click(sender As Object, e As System.EventArgs) _
Handles send.Click
Dim iQc As IQComponent = Nothing
Try
iQc =
CType(Marshal.BindToMoniker("que ue:/new:QCDemo.QComponent"), _
IQComponent)
Catch l as Exception
Console.Writeline("Caught Exception: " & l.Message)
End Try
iQc.DisplayMessage(messageToSend.Text)
Marshal.ReleaseComObject(iQc)
End Sub 'Send_Click
[C#]
protected void Send_Click (object sender, System.EventArgs e)
{
IQComponent iQc = null;
try
{
iQc = (IQComponent)
Marshal.BindToMoniker("queue:/new:QCDemo.QComponent");
}
catch
{
MessageBox.Show("Cannot create Queued Component");
}
iQc.DisplayMessage (messageToSend.Text);
Marshal.ReleaseComObject(iQc);
}
3.5.4.2. Desarrollo de componentes en cola Uso
de los componentes en cola
El proceso de agregar soporte para colas en aplicaciones COM+ resulta

bastante sencillo. Sólo es necesario asegurarse de que la aplicación se está
ejecutando como aplicación de servidor (fuera de proceso) y, a continuación,
definir las propiedades Queued y Listen en la ficha Colas. Una vez definidos
estos valores, la aplicación cliente puede llamar a componentes de forma
sincrónica o asincrónica. Lo bueno de esta característica es que no hay que
cambiar el código de un objeto COM; sólo es necesario cambiar sus
propiedades en el catálogo de COM+.

La plataforma .NET admite componentes en cola y, como es de esperar, se

puede aplicar dicho soporte para colas en componentes mediante atributos, en lugar
de hacerlo de forma manual cambiando el catálogo de COM+.
Vamos a agregar un método a la clase COMPlusServices y a llamarlo de forma
asincrónica mediante los servicios de componentes en cola COM+ de una
aplicación .NET cliente.
Haga que su aplicación COM+ sea una aplicación de servidor (fuera de
proceso). Esto es necesario para componentes en cola. Para hacerlo mediante
atributos, agregue el siguiente código al proyecto:
'*** **
<Assembly: ApplicationActivationAttribute(ActivationOption.Server)>
Agregue soporte para colas al componente. Hágalo accesible a colas MSMQ de

manera que pueda considerar su propia cola para procesar mensajes. Este es el
código para hacerlo mediante atributos:
'*** **
<Assembly: ApplicationQue uingAttribute(Enabled:=True,

QueueListenerEnabled:=True)>
Agregue un método llamado QueueTest a la clase. Asegúrese de que es una

subrutina. No debe devolver ningún valor. Defínalo para que escriba un mensaje
en el Registro de aplicaciones de Windows.El código debería ser similar a este:
Public Sub QueueTest()

System.Diagnostics.EventLog.WriteEntry(_
"COMPlusServces", "Prueba de cola", _
Diagnostics.EventLogEntryType.Error)
End Sub
Eso es todo. Al menos todo lo necesario para habilitar un componente y que

funcione como componente COM+ en cola.
Prueba
Ahora deberemos probar este componente en cola creando otra aplicación de

consola para llamarlo.
1. Cree una nueva aplicación de consola.

2. Agregue el siguiente código al procedimiento Sub Main de esta aplicación de
consola.

Sub Main()
Dim objTest As COMPlusJumpStart.COMPlusServices
Dim strMoniker
strMoniker = _ "queue:/new:COMPlusJumpStart.COMPlusServices"
objTest = GetObject(strMoniker)
objTest.QueueTest()
End Sub
Este código llama al método QueueTest del componente de forma asincrónica. Para
llamar al método de forma sincrónica, habría que llamarlo como al resto de los
métodos del componente.
Ahora podemos ejecutar esta aplicación de consola para comprobar el

funcionamiento de este componente en cola.
3.5.4.3. Componentes en cola y transacciones
Cuestionario
1. Liste tres ventajas de usar la mensajería asincrónica en un entorno de los

sistemas distribuidos.
2. Explique el propósito del grabador, oyente y componentes del jugador.
3. Liste dos factores que representen que una interfaz es impropia para la
operación en cola.
4. Liste tres consideraciones generales del diseño de sistemas que utilizan

componentes en cola.
5. ¿Cómo un cliente se instancia en componente en cola?
6. Liste dos maneras de devolver las contestaciones asincrónicas de un

componente en cola a un cliente.
7. ¿Qué efecto realiza marcando una aplicación como en cola?
8. ¿Qué interfaces realiza un implemento de clase de excepción?

3.5.5. Despliegue y Administración de Aplicaciones

3.5.5.1. Despliegue de una aplicación COM+ construida usando los
servicios .NET
Comenzaremos con la descripción de algunas de las principales diferencias entre

MTS y COM+. A continuación trataremos la herramienta administrativa Servicios
de componentes y su utilización en tres de las tareas administrativas más comunes
del sistema:
 Distribución de las aplicaciones

 Establecimiento de la seguridad basada en funciones y la identidad de
seguridad de una aplicación
 Administración del agrupamiento de los objetos para conseguir un
rendimiento óptimo del sistema.
De MTS a COM+
Muchos usuarios de IIS ya conocen Microsoft Transaction Server (MTS) y su

interfaz de usuario correspondiente, MTS Explorer. Se puede concebir COM+ como
un conjunto de servicios que combinan el modelo de objetos componentes (COM)
tradicional con MTS en los sistemas Windows 2000. Con la introducción de COM+,
la funcionalidad de MTS se ha fundido con el sistema operativo. Como podrá
comprobar, COM+ también amplía y mejora los servicios que se encuentran
disponibles con MTS.
Si ha utilizado con anterioridad MTS y MTS Explorer, se encontrará con algunos

cambios significativos cuando inicie la herramienta administrativa Servicios de
componentes. De modo destacado, los paquetes MTS ahora reciben el nombre de
aplicaciones COM+.
La idea de aplicación COM no es tan nueva. Sencillamente se trata del término

que se emplea para referirse a los grupos de componentes COM desarrollados
para trabajar conjuntamente. En las aplicaciones COM tradicionales, los
componentes debían instalarse mediante la configuración de las entradas en el
Registro antes de poder ejecutarse. Esta tarea normalmente se llevaba a cabo
con la utilidad Regsvr32. En el caso de COM+, este paso se realiza
automáticamente cuando configura los componentes como aplicación COM+.
Los componentes COM todavía se pueden seguir registrando en Windows 2000
mediante la utilidad Regsvr32 y seguirán existiendo en el entorno COM+ como
componentes sin configurar. Los componentes sin configurar no aparecen en
pantalla dentro de la herramienta administrativa Servicios de componentes y no
usan los nuevos servicios COM+. No obstante, cuando se ejecutan estos
componentes, utilizan algunas partes de la infraestructura de COM+ para
ejecutar aplicaciones COM+ distribuidas.

Las aplicaciones COM+ constan de uno o varios componentes COM. La clase

COM es la implementación con nombre, concreta, de una o varias interfaces. La
clase expone sus interfaces, que proporcionan un conjunto de funciones
relacionadas entre sí denominadas métodos. El Objeto COM es un ejemplo de
clase COM. Un componente COM es una unidad binaria de código que crea
objetos COM (entre los que se incluyen el código de empaquetamiento y de
registro).
La clase COM se identifica mediante un identificador de clase (CLSID) y a veces

también con un identificador de programa (ProgID). Una interfaz es un grupo de
funciones relacionadas entre sí que especifican un contrato. Éste incluye con el
nombre, la firma y la semántica de la interfaz, y el formato de ordenación en
búfer.
Cada interfaz se identifica con un identificador IID. La sintaxis de la interfaz se

define en las bibliotecas de tipo e IDL. Las interfaces de la clase deberían
dividirse en conjuntos de métodos manejables y coherentes. Recuerde que las
interfaces son inmutables, el contrato COM establece que no se pueden
modificar. Cualquier modificación (como agregar métodos) exige la definición de
una interfaz nueva.
Distribuir aplicaciones COM+
Mientras que el programador de aplicaciones utiliza COM+ para escribir

componentes e integrarlos como aplicaciones, la labor del administrador del
sistema es, generalmente, instalar, distribuir y configurar las aplicaciones COM+
y sus componentes. Normalmente, el programador entregará una aplicación
COM+ configurada en parte al administrador del sistema. O bien la aplicación
puede provenir de una fuente externa, por ejemplo, de la adquisición de una
aplicación COM+ a un proveedor de software independiente (ISV). El
administrador puede entonces personalizar la aplicación para uno o varios
entornos específicos (por ejemplo, mediante la incorporación de las cuentas de

usuario a las funciones y los nombres de usuario en un clúster de la aplicación).

Entre las tareas típicamente administrativas se incluyen:
 Instalar una aplicación COM+ parcialmente configurada en un equipo

administrativo.
 Proporcionar atributos específicos del entorno, como los miembros de
función y el tamaño del grupo de objetos.
 Configurar la identidad (la cuenta de usuario de Windows 2000) con la
que se va a ejecutar una aplicación COM+.
 Reexportar la aplicación COM+ totalmente configurada.
 Crear un proxy de aplicación (cuando se vaya a tener acceso a la
aplicación de modo remoto).
Cuando la aplicación se ha configurado completamente para un entorno

específico, el administrador puede entonces distribuirla entre los equipos de
prueba o producción. Esto implica la instalación de la aplicación completa COM+ ya
configurada en uno o varios equipos.
La herramienta administrativa Servicios de componentes facilita la distribución

de las aplicaciones COM+ entre múltiples servidores con la ayuda del Asistente
para exportación de las aplicaciones. Puede utilizar la herramienta administrativa
Servicios de componentes para crear paquetes de instalación destinados a las
aplicaciones COM+ y los proxy de la aplicación. COM+ genera paquetes de
instalación admitidos por Windows Installer que, en un único archivo, contienen
las piezas necesarias para instalar una aplicación COM+ en otro equipo.
El archivo .msi que contiene una aplicación COM+ sólo puede ser instalado en
equipos que admitan Servicios COM+ 1.0 (en la actualidad, sólo Windows 2000).
Como ventaja adicional, las aplicaciones COM+ que utilizan Windows Installer
aparecen en el panel de contro l de Agregar o quitar programas, a menos que se
modifique el archivo .msi mediante una herramienta de edición de Windows
Installer.

El archivo .msi que genera la herramienta administrativa Servicios de

componentes contiene:
 Tablas de Windows Installer con información de registro COM+.

 Un archivo .apl que contiene los atributos de la aplicación.
 Bibliotecas DLL y de tipos que describen las interfaces que se
implementan en las clases de la aplicación COM+.
Además, la herramienta administrativa Servicios de componentes genera un

archivo contenedor (.cab). Este archivo engloba el archivo .msi, permitiendo así la
distribución de la aplicación COM+ a través de Internet Explorer.
Instalar los proxy de al aplicación COM+
Para tener acceso a una aplicación de servidor COM+ remotamente desde otro
equipo (cliente), el equipo cliente debe tener un subconjunto de atributos de la
aplicación del servidor que se haya instalado, incluidas bibliotecas DLL de proxy
o código auxiliar, y bibliotecas DLL y de tipos destinadas al uso remoto de la
interfaz DCOM. Este subconjunto recibe el nombre de proxy de aplicación.
A través de la herramienta administrativa Servicios de componentes, puede

exportar fácilmente una aplicación de servidor COM+ como si fuera un proxy de
aplicación. Los proxy de aplicación que genera COM+ son paquetes estándar de
instalación de Windows Installer. Tras la instalación, aparecen los proxy de
aplicación en el panel de control de Agregar o quitar programas en el equipo
cliente.
Cuando se genera un proxy de aplicación, COM+ proporciona automáticamente

la siguiente información. Esta información es obligatoria para que el proxy de
aplicación tenga acceso de forma remota a la aplicación COM+ de servidor.
 Información de la identidad de la clase (CLSID y ProgID); un proxy de

aplicación admite hasta dos identificadores de programa (ProgID).
 La identidad de la aplicación y la relación de las clases hacia las
aplicaciones (AppID).
 Información de ubicación por aplicación (nombre del servidor remoto).
 Ordenación de la información para todas las interfaces expuestas por la
aplicación (por ejemplo, bibliotecas de tipo y proxy o código auxiliar).
 Nombres de cola MSMQ e identificadores (si se ha habilitado el servicio
de componentes en cola en la aplicación).
 Atributos de método, interfaz y clase, excepto la información de funciones.
 Atributos de la aplicación.
Al contrario que las aplicaciones de servidor COM+, los proxies de aplicación se

pueden instalar en cualquier sistema operativo que admita DCOM y Windows
Installer. Los clientes de otras plataformas de Windows también pueden tener

acceso a las aplicaciones COM+ que se ejecutan en los servidores de

Windows 2000. Respecto a los equipos en los que no se ejecuta Windows 2000 (y
que, por consiguiente, carecen de COM+), sólo se instala el subconjunto de la
información exigida para funcionar de modo remoto con DCOM. Esta
información se instala en el Registro de Windows. Cuando se instala un proxy de
aplicación (archivo .msi) en equipos donde no se ejecuta Windows 2000, debe
ejecutarse Windows Installer. Windows Installer está disponible en formato
redistribuible como parte del SDK de la plataforma.
Configurar la seguridad de COM+
Las funciones de seguridad modelan e imponen una directiva de control de

acceso a la aplicación COM+. Las funciones son categorías de usuarios que se
han definido para la aplicación con el propósito de determinar los permisos de
acceso a los recursos de la aplicación. El programador asigna las funciones
(como si se tratara de categorías simbólicas de usuario) a la aplicación y
potencialmente a las estructuras más refinadas que incluya, como componentes,
interfaces, métodos o recursos particulares de aplicación. Estas asignaciones de
funciones se utilizan por tanto para determinar qué categorías de usuario tienen
permiso para tener acceso a qué elementos dentro de la aplicación.
Cuando una aplicación emplea una seguridad basada en funciones, en cada

llamada que se haga en la aplicación se comprueba la pertenencia como
miembro de la función de llamada. Si quien realiza la llamada no pertenece a una
función que tenga permiso de acceso al elemento que ha sido llamado, la llamada
fracasará. Quienes realizan las llamadas tienen garantizado su acceso a la aplicación
o a sus recursos estrictamente según las restricciones definidas en las funciones a las
que pertenecen.
La labor del administrador del sistema es poblar las funciones que define la
aplicación con los grupos y las cuentas de usuario de Windows 2000. Esta es
una fase crucial en la aplicación de la directiva de seguridad de la aplicación. Se
deben asignar los usuarios a las funciones que representan correctamente sus
relaciones con los datos y recursos a los que podrían tener acceso a través de la
aplicación.
La mejor forma de poblar estas funciones con usuarios es utilizar los grupos de
Windows 2000. En primer lugar, se asigna una cuenta de usuario a los grupos
en cuestión y, después, se asegura que a estos grupos se les asignan las
funciones adecuadas. El uso de los grupos de Windows 2000 para poblar
funciones le facilita la administración de grandes cantidades de usuarios.
En entornos informáticos de empresa, suele ser difícil hacer un seguimiento

eficaz de cada usuario dentro de la organización y determinar la forma en que se
asigna a a política de seguridad basada en las funciones particular de cada
aplicación. A medida que aumenta el número de usuarios, administradores y

aplicaciones, esta tarea se vuelve cada vez más complicada. La solución más
escalable es la de asignar grupos de us uarios a las funciones de la aplicación
COM+.
Antes de asignar grupos a las funciones, es necesario que se asegure de haber

comprendido la política de seguridad de la aplicación. Teóricamente, las
funciones deberían llevar nombres que sugirieran quiénes deberían pertenecer a
ellas, como "Jefes" y "Narradores". Además, hay descripciones para cada
función a la que usted puede tener acceso mediante la herramienta
administrativa Servicios de componentes, que pueden describir los tipos de
usuario que deberían pertenecer a la función. Sin embargo, si no está seguro de qué
grupos de usuarios pertenecen a qué funciones, consulte la documentación que
acompaña a la aplicación o pregunte al programador.
Puede utilizar la herramienta administrativa Servicios de componentes tanto para

realizar las asignaciones iniciales de las distintas funciones durante la instalación de la
aplicación como para efectuar cualquier cambio necesario durante el tiempo de
vida de la aplicación.
Agrupación de objetos
La agrupación de objetos es un servicio automático que ofrece COM+, que le

permite configurar un componente para tener copias activas de éste en un
grupo, listas para que cualquier cliente que solicite el componente pueda
utilizarlas. Puede configurar administrativamente y controlar el grupo que se
mantiene para un determinado componente, especificando las características que
posee, como el tamaño del grupo y la solicitud de creación de valores de tiempo de
espera. Cuando la aplicación se está ejecutando, COM+ le administra el grupo,
controlando los detalles de la activación y reutilización de los objetos de acuerdo
con los criterios que haya especificado.

Puede conseguir un rendimiento muy significativo y escalar las ventajas si

reutiliza los objetos de este modo, particularmente cuando se han diseñado para
sacar el máximo partido de la reutilización. Usted puede configurar
administrativamente la agrupación de objetos para obtener el máximo partido de los
recursos de hardware disponibles. La configuración del grupo puede variar a medida
que cambien los recursos de hardware disponibles. También puede gobernar el
uso de los recursos con la administración del grupo.
Cuando configure un componente que vaya a ser agrupado, COM+ mantendrá

copias de éste en un grupo, listas para que cualquier cliente que solicite el
componente las active. Cualquier solicitud de creación de objetos se tratará a
través del administrador del grupo.
Al iniciarse la aplicación, el grupo se poblará hasta el nivel mínimo que usted haya
especificado administrativamente, mientras prospera la creación de objetos.
Cuando el cliente solicita la entrada del componente, el grupo satisfará su petición y
servirá los componentes por orden de llegada. Si no hay ningún objeto del grupo
disponible y el grupo no se encuentra aún en su máximo nivel especificado, se crea y
activa un nuevo objeto para el cliente.
Cuando el grupo alcanza su nivel máximo, las solicitudes del cliente entran en la
cola de trabajo. Cada solicitud recibe el primer objeto disponible del grupo. El
número de objetos, tanto activados como desactivados, no sobrepasará nunca el
valor máximo del grupo. El tiempo de espera de las solicitudes de creación de
objetos se agotará después de un período especificado administrativamente, de
modo que usted pueda controlar el tiempo que tienen que esperar los clientes
para la creación de objetos. Siempre que sea posible, COM+ intentará reutilizar

un objeto una vez que el cliente lo libere, hasta que el grupo alcance su nivel
máximo.
Puede utilizar el tamaño máximo de grupo para precisar con mucha exactitud el
modo en que utiliza los recursos. Por ejemplo, si tiene licencia para un cierto
número de conexiones de base de datos, puede controlar cuántas conexiones tiene
abiertas en cualquier momento.
Al reflexionar acerca de los pa trones de uso de los clientes, las características de

uso de los objetos y los recursos físicos como la memoria y las conexiones, es
probable que descubra un equilibrio óptimo a la hora de ajustar el
rendimiento. La agrupación de objetos irá menguando en su rendimiento tras
alcanzar un cierto punto. Usted puede determinar el rendimiento que desea y
equilibrarlo frente a los recursos que son necesarios para conseguirlo. Con el
agrupamiento, tiene control sobre el uso de los recursos.
Cuestionario
1. Liste las limitaciones de usar el registro dinámico.
2. ¿Cuáles son los contenidos del archivo .msi que se crea cuándo exporta
una aplicación COM+?
3. Liste las fases de repetición al usar la herramienta de COMREPL.
4. Liste los pasos para crear una aplicación COM+ .

Puntos de
Estándar Estándar
Obtenidos
(10-9) (8.5-7) (6.5-0)
La información
revisada
permitió a los
la estudiantes
comprender con estudiantes
Información comprender
claridad los comprender
solamente los
ejercicios y los ejercicios y
programas. ejercicios y
(10-9) (8.5-7) (6.5-0)
Los estudiantes
han demostrado
Los
el significado del
material
elaborando
Conexiones correctamente,
material el material,
mientras
extienden y
explican la
información,
tema. en su estudio
incorporándola en
del tema.
el estudio del
tema.
3.6. Web Services
Escenario Web Services
Sistemas de Objetos Distribuidos y Protocolos
 El paradigma de objetos distribuidos tiene amplia aceptación en

aplicaciones distribuidas, por lo que un gran número de mecanismos
basados sobre el paradigma están disponibles, entre ellos los que hemos
tratado hasta el momento:
o Common Object Request Broker Architecture (CORBA).

o Java Remote Method Invocation (RMI).

o Distributed Component Object Model (DCOM, COM+),
o Mecanismos que soportan el Simple Object Access Protocol
(SOAP).
 Este último es utilizado en los Web Services:
o Un servicio Web XML es un componente de software o una
aplicación que expone sus funciones programáticamente a través
de Internet o la intranet utilizando los protocolos estándar de
Internet como son Simple Object Access Protocol (SOAP) para
comunicación entre programas, y XML para representación de
datos.
Estándares de Web Services
Los servicios Web se registran y anuncian utilizando los siguientes servicios y

protocolos:
 XML (extensible Markup Language), Estructura, describe e intercambia
información. Independientemente de múltiples formas, todas las
tecnologías de servicios Web se basan en XML. El diseño de XML se deriva
de dos fuentes principales: SGML (Standard Generalizad Markup Language) y
de HTML ( Hipertexto Markup Language).
 UDDI (Universal Description, Discovery and Integration), es un protocolo
para describir los componentes disponibles de servicios Web. Este
estándar permite a las empresas registrarse en un tipo de directorio
sección amarilla de Internet que les ayuda anunciar sus servicios, de tal
forma que las compañías se puedan encontrarse unas a otras y realizar
transacciones en el Web. El proceso de registro y consultas se realiza
utilizando mecanismos basados en XML y HTTP. En el proyecto UDDI se
trabaja para proveer un método de acceso común a los metadatos
necesarios para determinar su un elemento de código previamente
elaborado es suficiente, y si lo es, cómo accederlo.
 SOAP (Simple Object Access Protocol) es un protocolo para iniciar las
conversaciones con un servicio UDDI. El SOAP simplifica el acceso a los
objetos, permitiendo a las aplicaciones invocar métodos objeto o
funciones, que residen en sistemas remotos. Una aplicación SOAP crea
una un petición bloque en XML. proporcionando los datos necesarios para el
método remoto así como la ubicación misma del objeto remoto.
 WSDL (Web Service Description Language), es el estándar propuesto
para la descripción de los servicios Web, el cual consiste en un lenguaje
de definición de interfaz (IDL - Interface Definition Language) de servicio
basado en XML, que define la interfaz de servicio y sus características de
implementación. El WSDL es apuntado en los registros UDDI y describe
los mensajes SOAP que definen un servicio Web en particular.
 ebXML (e-business XML) define componentes centrales, procesos,
registros y almacenajes comerciales, servicios de mensajes, acuerdos de
intercambio comercial, y seguridad.

Esquema de Implementación de un Servicio Web Un

proveedor de servicio crea un servicio Web
El proveedor de servicio utiliza WSDL para describir el servicio (a un registro
UDDI)
El proveedor de servicio registra el servicio (en un registro UDDI y/o a un
registro/depósito ebXML )
Otro servicio o usuario localiza y solicita el servicio registrado al consultar los
registros UDDI y/o ebXML
El servicio o usuario solicitante escribe una aplicación que liga el servicio
registrado utilizando SOAP (en el caso de UDDI) y/o ebXML
Se intercambian datos y mensajes XML sobre HTTP
Ejercicio Práctico de Web Services
Creación de una Aplicación Web Services en Visual Studio .Net
Paso1: Un servicio Web desde un punto de vista del servidor IIS funciona
exactamente igual que una aplicación Web. Se aloja en un directorio virtual y
utiliza para su funcionamiento archivos .ASMX, en vez de las páginas .ASPX que
utilizamos en ASP .NET.

 Crear un directorio físico donde almacenaremos los archivos necesarios

para el funcionamiento de nuestro servicio Web. Suponiendo que su
directorio raíz de su servidor Web IIS sea el directorio raíz por defecto
(“c:\inetpub \wwwroot\”), crearemos un nuevo directorio llamado
“WSDemo”.
 Ejecutar la consola de administración de IIS. Esta se encuentra en el
Panel de Control, icono de Herramientas Administrativas e icono de
Administrador de Servicios de Internet.
 Ejecutar la consola de administración de IIS. Esta se encuentra en el
Panel de Control, icono de Herramientas Administrativas e icono de
Administrador de Servicios de Internet.
 Seleccionamos y desplegamos la rama del Servidor Web
Predeterminado, y veremos nuestra carpeta denominada “WSDemo”.
 Haremos clic con el botón derecho sobre esta carpeta, y elegiremos la
opción Propiedades.
 En la pestaña Directorio, pulsaremos el botón de Crear. Esta operación lo
que realiza es crear una nueva aplicación Web de IIS en este directorio
físico. A partir de este momento, podremos acceder a la dirección
“http://localhost/WSDemo”, e IIS nos la servirá dentro del marco que el
define para las aplicaciones Web.
 Pulsamos Aceptar y salimos de todas las ventanas.
Paso2: A continuación escribimos el código del servicio:

 Debemos indicar que vamos a utilizar elementos pertenecientes a la clase
System.WebServices using System.Web.Services;
 Delante de los métodos que queramos que sean accesibles por la Web
añadiremos la cláusula [WebMethod], indica al sistema en tiempo de
ejecución que es un método llamado a través de HTTP.
 Todo Web Service debe ser identificado de forma única en Internet, la
manera de hacer esto es suministrando una dirección URL. Esta URL
debe ser declarada en un atributo antes de la declaración de la clase:
[WebService(Namespace=“http://localhost/WSDemo”)]
Paso3: Solicitamos el Build (Generar) del proyecto e inmediatamente podemos

acceder al servicio a través del navegador web.
El código de nuestra página “wsdemo.asmx” es el siguiente:
<%@ WebService Language="c#" Class="demo WS" %>

using System;
using System.Web;
using System.Web.Services;
namespace WS
{
[WebService(Namespace="http://localhost/WSDemo/")]
public class wsdemo : System.Web.Services.WebService

{
public wsdemo()
{}
[WebMethod]
Public Function LlamadaMetodoWSdemo() As String
{
return "Respuesta a wsdemo";
}
}
}
Actividad 3.6
Actividad Web Services
Realizar el ejercicio práctico del Escenario Web Services, colocar informe en

Tarea Individual 3.6

Puntos de
Estándar
Estándar Obtenidos
(10-9) (8.5-7) (6.5-0)
La información
revisada
permitió a los
estudiantes
la comprender con estudia ntes
comprender
Informació n claridad los comprender
solamente los los ejercicios y
ejercicios y
ejercicios y
programas.
(10-9) (8.5-7) (6.5-0)
Los estudiantes
han demostrado
Los
el significado del
material
elaborando
Conexiones correctamente,
material el material,
Especialistas mientras
incorporándolo simplemente
extienden y
explican la
información,
tema. en su estudio
incorporándola en del tema.
el estudio del
tema.

4. Lenguajes de Programación
4.1. Lenguajes y Plataformas de Desarrollo
Actividad 4.1
Actividad Lenguaje y Plataformas de Desarrollo
Antes de iniciar o durante su proyecto final, revisar el Material de Apoyo 4.1

Nota: Esta actividad no tiene evaluación.
4.1.1 Antecedentes
Inicialmente, los computadores eran grandes centros de computación con

entidad propia en centros de investigación o gubernamentales y Universidades. Con
la introducción de los PC en los 80, todos pudieron tener parte de esa capacidad
de cómputo. Los PC, mucho más baratos que minis o mainframes, fueron una gran
aportación para empresas y particulares.
Aunque el computador personal estaba pensado para ser un elemento de

computación autónomo y no formar redes de computadores, la posibilidad de
compartir recursos gracias a la comunicación de varios PC, supone una ventaja
que los fabricantes no pudieron ignorar, empezando así la carrera hacia los
sistemas distribuidos, que tratan de sumar lo mejor de microcomputadores y
supercomputadores a la vez creando un computador virtual a partir de varios
PC.
Orientado a Procedimiento
La comunicación entre dos PC en sistemas UNIX, mejoró mucho cuando BSD

introdujo el concepto de socket, que permitía que la comunicación entre
procesos sitos en computadores distintos no fuera mucho más complicada que
la de un programa que supiese leer y escribir archivos. Los programas que
emplean sockets establecen un protocolo de comunicación para poder
entenderse.
El RPC, de Sun Microsystems, es el siguiente nivel de abstracción y permite

realizar llamadas a procedimientos independientemente de su localización,
buscando con ello la transparencia de acceso para el programador.
Orientada a Objetos

Las tecnologías Orientadas a Objeto, hacen que estas abstracciones orientadas a

procedimiento resulten inadecuadas, y propicia la aparición de sistemas como
CORBA, RMI y COM/DCOM.
El término sistema distribuido hace referencia al uso de objetos por parte de

otros que pueden estar situados o no en la misma máquina, de forma casi
transparente. Los objetos servidores que ofrecen servicios, y de objetos cliente, que
los usan, aunque esta distinción carece de sentido en sistemas distribuidos, donde un
objeto puede adoptar simultáneamente ambos roles.
4.1. 2 Java y las Redes
SUN
Java es un entorno de computación introducido al público en 1995 por Sun

Microsystems. Considerado como lenguaje de programación, es simplemente un
lenguaje cuya sintaxis recuerda la del C++, y tiene, respecto a este, ventajas,
que el marketing de la compañía trata de resaltar, e inconvenientes, que trata de
ocultar, sin embargo, las librerías de clases y el que todos sus programas se
ejecuten en una máquina virtual lo convierten en un lenguaje altamente portátil,
muy apto para una red con computadores y sistemas operativos tan
heterogéneos como Internet.
Máquinas Virtuales
El secreto de la portabilidad binaria de los programas java reside en las

máquinas virtuales. Los compiladores Java no generan binarios para una
arquitectura real, sino para una inexistente máquina virtual Java, por lo que para usar
los binarios, se necesita un emulador encargado de traducir instrucciones del
programa a primitivas de la arquitectura anfitriona.
4.1.3 Sistemas Distribuidos en Java
RMI
RMI fue el primer framework para crear sistemas distribuidos que apareció para
Java. Además, viene integrado en cualquier máquina virtual Java posterior a la
1.0 y está pensado para hacer fácil la creación de sistemas distribuidos a partir de
una aplicación cuyas clases ya estén implementadas.
CORBA: El estándar de sistemas distribuidos
CORBA es el estándar para la creación de sistemas distribuidos creado por el

Object Management Group (OMG). Pensado para ser independiente del

lenguaje, rápidamente aparecieron implementaciones en las que se podía usar casi

cualquier lenguaje.
DCOM: La alternativa de Microsoft.
Aunque objeto y componente tienen significado distintos, el nombre utilizado en las

tecnologías de Microsoft COM y DCOM, versión distribuida de COM es
componente. COM/DCOM es un sistema de componentes implementado en todos
los sistemas operativos que fabrica Microsoft. La tecnología para crear sistemas
distribuidos proporcionada por Microsoft es una versión orientada a componentes
del sistema RPC ya comentado.
4.1.4 CORBA.
CORBA, Common Object Request Broker Architecture, es una tecnología para crear
sistemas distribuidos, creada por un consorcio de fabricantes, agrupados bajo el
OMG.
El estándar CORBA define qué ha de incluir una implementación estándar, pero no

cómo se han de hacer. Esta tarea se deja de la mano de los diferentes
fabricantes. Esta es una de las principales características de CORBA: permite una
total libertad a los implementadores siempre que estos respeten unos mínimos
orientados a la interoperabilidad entre implementaciones.
Ventajas
Disponibilidad y Versatilidad
Muchas arquitecturas y sistemas operativos cuentan con una implementación de

CORBA, lo que hace suponer que se puede usar CORBA en virtualmente
cualquier proyecto de sistemas distribuidos.
Eficiencia
La libertad de desarrollo ha favorecido la existencia de una pléyade de

implementaciones del estándar que se adaptan a multitud de posibles
necesidades de los usuarios, generando una competencia que favorece aquellas
implementaciones de mayor calidad y con más características.
Adaptación a Lenguajes de programación
Además, es posible emplear los servicios de CORBA desde cualquier lenguaje de

programación, desde C++, C ó Java, hasta COBOL ó Ada.

Inconvenientes
Complejidad
Permitir la interoperabilidad de distintos lenguajes, arquitecturas y sistemas

operativos hace que sea un estándar bastante complejo, y su uso no sea tan
transparente al programador como sería deseable:
1. Hay que usar un compilador que traduce una serie de tipos de datos
estándares a los tipos del lenguaje en el que se vaya a programar (IDL).
2. Hay que ser conscientes a la hora de diseñar qué objetos van a ser
remotos y cuáles no (los remotos sufren restricciones en cuanto a sus
capacidades con respecto a un objeto normal).
3. Es necesario emplear tipos de datos que no son los que proporciona de

manera habitual el lenguaje de programación (muchas veces hay que
emplear tipos de datos adaptados de IDL).
Incompatibilidad entre implementaciones
Muchas empresas ofrecen implementaciones CORBA, si bien el grado de

cumplimiento es diverso. Las divergencias entre ORBs radican en detalles que,
aunque no hacen imposible aplicar en uno el mismo diseño de un programa
pensado para otro, hacen cuela adaptación sea fastidiosa. Cuestiones como la
colocación de librerías o las diferentes formas de implementar la gestión de la
concurrencia, hacen difícil la portabilidad del código y obligan al programador a
reciclarse cuando quiere cambiar de ORB. Además, donde el estándar no
concreta, las implementaciones pueden variar entre sí, lo que da lugar a
molestas incompatibilidades que complican la vida al usuario.
Los ORBs.
Los ORBs, Object Request Brokers, núcleo de cualquier implementación

CORBA, transmiten los mensajes que se intercambian cliente y servidor, para lo que
se ocupan de:
1. Canalizar las comunicaciones entre los objetos locales y los remotos.

2. Empaquetar los parámetros que el cliente pasa al método remoto y el

resultado que el método devuelve al cliente.
3. Localizar al objeto remoto a partir de una referencia.
El IDL
IDL (Interface Definition Language) es un lenguaje de programación pensado

exclusivamente para especificar los interfaces de las clases cuyas instancias
queremos hacer públicas a objetos remotos que las usaran como clientes.
La necesidad de un IDL viene dada por la independencia de CORBA respecto a

la arquitectura y al lenguaje de programación. Distintos lenguajes soportan
diferentes tipos de datos y tienen distintas formas de especificar clases. Incluso
limitándonos aun lenguaje, la ordenación y el tamaño de un tipo de datos
determinado no tiene porqué ser el mismo entre arquitecturas diferentes (por
ejemplo, no es lo mismo un entero en un 386 con MS-DOS que en un UltraSparc
con Solaris 7).
IDL pone de acuerdo a distintos lenguajes en el formato y tamaño de sus

especificaciones. El compilador de IDL transforma una especificación neutral
para la plataforma y el lenguaje en otra que puedan entender dicho lenguaje y
plataforma.
El IIOP: Interoperabilidad entre ORB.
CORBA es neutral respecto al protocolo de red utilizado para comunicar cliente y

servidor. Para ello especifica el GIOP (General Inter ORB Protocol) que define a muy
alto nivel la comunicación entre ORBs diferentes. Para redes de tipo TCP/IP se
emplea una instancia de GIOP conocida como IIOP (Internet InterORB
Protocol). Gracias a IIOP, es posible que objetos que emplean ORBs de
fabricantes distintos puedan interoperar en redes como Internet.
Gestión de la concurrencia.
El comportamiento de un objeto situado en un servidor cuando dos o más

clientes quieren hacer uso de sus servicios viene determinado por la política de
gestión de la concurrencia que se haya programado en el ORB. CORBA incluye
varias políticas que definen cuándo y cómo activa el ORB los objetos en el
servidor para atender peticiones.
Desafortunadamente, si se utiliza un mismo proceso para atender todas las

peticiones que se hagan, o si se crea uno nuevo para atender cada una de las

peticiones es algo de lo que se va a tener que ocupar el programador, aunque

algunos ORBs pueden asistir al programador en esa tarea.
Servicio de nombrado.
En CORBA hay varias formas de que un objeto situado en una máquina pueda
referirse a otro remoto.
IOR
Número de gran lo ngitud, que permite identificar de manera única y global a un

objeto que ofrece sus servicios en un entorno distribuido. Lo genera
automáticamente el ORB de forma que no pueda haber dos objetos con el
mismo identificador por muy grande que sea la red. Usa para ello datos
aleatorios, y otros escogidos a partir del computador sobre el que se ejecuta, la
implementación del ORB, etc.
Asignación de Nombres
Dándole previamente un nombre al objeto, otro que quiera usar sus servicios
podría emplear una notación tipo URL como
iiop://nombre_host:puerto/nombre_objeto6. Así, si en máquina.inf.uniovi.es,
existe el objeto dns, cualquiera que quiera acceder a dns sólo tiene que solicitar
a su ORB una referencia a iiop://máquina.inf.uniovi.es/dns. Esta forma de
nombrado es más fácil de recordar para la mayor parte de los seres humanos,
aunque seremos nosotros los que tendremos que asegurarnos de su unicidad
(aunque solo dentro de los límites de la máquina en la que se registre).
Ambos sistemas de nombrado tienen el inconveniente de no ser transparentes

en cuanto a la localización ya que, si movemos los objetos servidores,
tendremos que adecuar a los objetos clientes para que los busquen en otro lado.
Servicios adicionales de CORBA.
Las implementaciones CORBA pueden ofrecer servicios adicionales

voluntariamente (aunque no es necesario para ser certificado de compatibilidad
CORBA por el OMG).
Un ejemplo de estas facilidades es el sistema de suscripción de eventos, que

permite que un objeto se suscriba a eventos generados por otro. El propósito de
este servicio es el de mejorar la eficiencia disminuyendo el tráfico de la red. Por
ejemplo, si hay varios objetos clientes esperando a que suceda algo en el objeto
que presta servicio en el servidor, en vez de hacer poleo (polling), podrían
solicitarle a este que les envíe una notificación cuando eso ocurra.
Seguridad.

El estándar CORBA no se preocupa de la seguridad implementada en el sistema

distribuido. Si por alguna razón se requiere restringir el uso de los recursos
controlados por un determinado objeto, debe hacerlo el usuario.
Integración de CORBA en Java
CORBA, como especificación, es absolutamente independiente de la plataforma

o el lenguaje, por lo que no han tardado en aparecer implementaciones de
CORBA con soporte de Java (como VisiBroker ó como ORBacus por ejemplo).
Esto se traduce principalmente en un traductor IDL, tipos básicos de Java y en

un framework, que permiten acceder a la librería de servicios del ORB. Algunas
de estas librerías son nativas, en vez de emplear implementaciones 100% Java
para soportar Java, lo que puede dar algunos problemas de portabilidad o
imposibilitar la ejecución de aplicaciones dentro de los navegadores con soporte
para Java.
Pero la integración Java-CORBA incluirá interesantes mejoras cuando OMG

introduzca la nueva versión del estándar, CORBA 3.0. De hecho, parte de la
mejora en esta integración es justo lo inverso de lo que había hasta ahora: una
correspondencia java -idl. Al contrario que el compilador de IDL a Java, que
convierte una especificación en formato neutral en clases que puede usar un
compilador java, el traductor java-idl extraerá la interfaz de las clases java y las
traducirá a una especificación IDL, por lo que será más fácil emplear clases java
por programas que usen CORBA y que estén implementados en otros lenguajes.
Limitaciones e Inconvenientes CORBA.
1. El sistema no es transparente al programador. Las diferencias para el

programador que quiera usar un determinado objeto con respecto a las de
emplear uno local, se reducen a la inicialización del mismo. En vez de
inicializarlo normalmente, hay que pedir al ORB (vía IOR o usando un
nombre más inteligible), una referencia al objeto remoto y luego convertirlo al tipo
de objeto a manejar.
2. Los objetos remotos se pueden usar por referencia, pero no por valor. Así,
cuando se haga uso de los métodos de un objeto remoto (al que se accede
por referencia), solo se le pueden pasar como parámetros (y el método solo
podrá devolver como resultado) tipos de datos contemplados en el IDL.
Afortunadamente, este problema queda resuelto con CORBA 3, que sí
soporta el paso de parámetros por valor.

3. Múltiples implementaciones de CORBA dan lugar a múltiples

incompatibilidades. El estándar CORBA define a alto nivel qué funciones
debe proporcionar un ORB y cómo han de interoperar estos entre sí, lo que
garantiza cierto grado de compatibilidad, pero el cómo se ofrezca esa
funcionalidad al programador es algo que está al libre albedrío del fabricante
del ORB. Es más, parte de la funcionalidad del estándar CORBA no es de
obligado cumplimiento por parte de las compañías fabricantes para poder
anunciarse como CORBA-compliant. En estas condiciones es muy difícil
pensar que un programa que haya sido programado pensando en un ORB
concreto, pueda funcionar bien con una simple recompilación.
4. El estándar CORBA está poco preparado para usarse en entornos

embebidos (electrónica de consumo, asistentes digitales) o que requieran
soporte de tiempo real. Para el primer caso, se diseñó en CORBA 3 un
subconjunto llamado Minumum CORBA que, al ser más ligero, encaja mejor
en los sistemas embebidos, donde el control del consumo de recursos es
vital. Para solucionar el segundo problema, CORBA 3introducirá Real -Time
CORBA, que introducirá modelos de prioridad para conseguir un
comportamiento predecible de los programas que lo usen.
4.1.5 RMI
RMI (Remote Method Invocation) es parte de la librería de clases de Java que

permite la creación de sistemas distribuidos en Java.
Características particulares de RMI.
Al contrario que otras tecnologías de sistemas distribuidos, RMI no busca la

colaboración de objetos de distintas plataformas, programados indiferentes
lenguajes, Java se encarga de solucionarlos problemas de heterogeneidad. Así,
su API es más sencillo y natural al no contemplar que tipos de datos (y sus
tamaños) existan o no en los lenguajes en los que se implementan cliente y
servidor.
Gestión de la concurrencia.
La gestión de la concurrencia en RMI, como muchas de las cosas que lo

diferencian de CORBA es extraordinariamente sencilla e inflexible. Para cada
cliente que trate de acceder a un objeto remoto, el servidor creará un nuevo hilo
que se encargará de darle servicio. Si varios hilos del mismo cliente realizan
distintas peticiones al servidor, compartirán un mismo hilo en el servidor.
Servicio de nombrado.
El nombrado de objetos es sencillo pero dependiente del computador donde

resida el objeto servidor en cada instante. Aún así, está pensado de tal forma

que difícilmente su uso creará problemas al usuario, ya que emplea la notación URL
del tipo rmi://nombre_host:puerto/nombre_objeto.
Un programa que acompaña a las implementaciones Java es el RMIRegistry. El

registro rmi (rmiregistry) comunica objetos clientes con servidores.
Conceptualmente, cuando un cliente quiere obtener una referencia a un objeto
remoto, pregunta por él al rmiregistry donde resida dicho objeto. El registro lleva
la cuenta de los objetos exportados que residen en esa máquina (ya que todos
ellos han sido dados de alta en el registro por el programa que se haya
encargado de crearlos e inicializarlos), por lo que comprueba que la solicitud del
cliente puede ser atendida, y caso de ser así, devuelve la referencia esperada.
El RMIRegistry puede ser ejecutado como servicio de Windows NT o como

demonio en UNIX (y similares).
Paso de parámetros por valor y serialización.
RMI soporta que objetos clientes puedan emplear objetos remotos por valor y por
referencia. El uso de un objeto remoto por referencia no es nada nuevo,
cualquier objeto expo rtado ante el RMIRegistry se pasa automáticamente por
referencia a cualquier cliente que quiera usarlo.
La novedad es el paso de objetos por valor, para lo que se emplea la librería de

serialización del API de Java. Para pasar un objeto por valor del servidor el
cliente, debe implementar una clase abstracta que les obliga a definir cómo
almacenar en un flujo de datos (como por ejemplo un archivo) los datos
importantes del objeto serializable y cómo reconstruirlo a partir de esos mismos
datos. Muchas de las clases del API de Java ya son serializables por lo que
otras clases que las usen (por herencia o agregación) no tienen que ocuparse de
serializarlas.
Cuando se necesita llevar un objeto serializable de una máquina a otra (porque sea
un parámetro de un método de un objeto remoto que empleamos por referencia,
o porque sea el resultado que devuelve dicho método al cliente), se serializa, se lleva
el flujo de una máquina a la otra, y una vez en el computador huésped, se reconstruye
y se usa.
La ventaja del paso por valor en un sistema distribuido radica en que se

minimiza el tráfico en la red ya que, una vez recibido el objeto, todas las
comunicaciones con él serán locales.
Seguridad.
Por defecto, RMI no incluye ninguna facilidad para restringir el uso de las clases
desde clientes no autorizados, aunque el usuario siempre puede suplir parte de
esta funcionalidad usando los servicios del sistema operativo, o haciendo ese

trabajo él mismo. Aún así, no se puede confiar en la seguridad de un sistema

solo porque se haya autentificado al usuario al inicio de la conexión si es que el
canal de comunicación no es seguro. La plataforma Java 2incluye el soporte de
comunicaciones seguras en RMI usando el estándar SSL (Secure Sockets
Layer).
4.1.6 DCOM/COM/COM+
COM se refiere tanto a especificación como aplicación, desarrollado por

Microsoft que provee una infraestructura para integración de componentes.
Soporta interoperabilidad y reutilidad de objetos distribuidos.
COM define una interfaz de programación de aplicaciones (API) para permitir la

creación de componentes para el uso integrando las aplicaciones
personalizadas o permitir componentes diversos para interactuar. Sin embargo
para interactuar, los componentes deben adherir a una estructura binaria
especificada por Microsoft. Con tal de que los componentes adhieran a esta
estructura binaria, los componentes escritos en lenguajes diferentes pueden
interoperar.
Distributed COM (DCOM) es una extensión a COM que permite interacción de

componentes basados en red. Mientras los procesos de COM pueden ejecutar en la
misma máquina pero la extensión de DCOM permite extender los procesos por una
red en espacios direccionables diferentes. Con DCOM, componentes que operan
en una variedad de plataformas pueden interactuar, con tal de que DCOM esté
disponible dentro del entorno.
Es mejor considerar COM y DCOM como una sola tecnología que provee un rango
de servicios a la interacción del componente, de servicios que promueven la
integración del componente en una sola plataforma, a la interacción del
componente por las redes heterogéneas. De hecho, se unen COM y sus
extensiones de DCOM en un solo tiempo de ejecución. Este solo tiempo de
ejecución proporciona cercanía y acceso remoto.
MTS extiende las capacidades del COM con servicios como transacción y
seguridad. COM+ es la evolución de COM. COM+ integra servicios de MTS y
mensaje en cola en COM y hace COM que se programa más fácil a través de
una integración más íntima con lenguajes de Microsoft como Visual Basic, Visual
C++ y J++.
4.1.7 Interoperabilidad de Plataformas
Afortunadamente para los usuarios que necesitan crear un sistema distribuido,

existen modos de poder utilizar un objeto cliente implementado según un

estándar de sistemas distribuidos, desde otro diferente. Un ejemplo es la

integración entre COM y CORBA desarrollada por IONA Technologies.
Asimismo, OMG y Sun están trabajando para hacer que CORBA y RMI sean
interoperables de manera transparente al programador y al usuario. Además, la
plataforma Java 2 viene con soporte de RMI y de CORBA simultáneamente.
El rendimiento es menor, lo que se agrava especialmente si la comunicación entre

dos objetos implementados en estándares distintos es intensa. Además, la
interoperabilidad suele suponer tener que conformarse con el mínimo común
denominador de las facilidades que incorporen los sistemas originales.
4.2. Desarrollo de un Sistema Distribuido

4.2.1 Caso de Estudio: IIOP.NET y un Servicio de Chat
Introducción
EJB (Enterprise Java Beans) es una tecnología establecida para implementar

componentes de software en una plataforma Java. EBJ puede usarse para crear
sistemas de objetos distribuidos y confía en Java RMI/IIOP para intercambiar los
mensajes; EJB también puede exponerse como servicios Web.
En la visión de Microsoft, la próxima generación de sistemas distribuidos es

comunicar con Web Services. Web Services son mayores cuando integran
sistemas heterogéneos flojamente acoplados, pero tiene sus limitaciones
también: no tiene n el apoyo por las referencias del objeto remotas. En la
práctica, son sin estado y más cercano a una llamada del método remota que a un
sistema del objeto distribuido.
J2EE y .NET son dos mundos similares pero desarticulados: pueden

actualmente interactuar sólo usando juntos Web Services. Ambas plataformas
ofrecen grandes mecanismos por construir los sistemas de objeto distribuidos
herméticamente acoplados: Remoting de .NET y RMI de Java, pero ambos
confían en estándares incompatibles. Aunque, Remoting .NET es configurable:
un formateador diferente para la serialización y deserialización de los objetos
junto con un canal de transporte diferente puede proporcionarse fácilmente.

Vista general de un canal .NET
Es posible acceder a un componente .NET desde un Java mediante un canal

remoto personalizado llamado IIOP.NET. Pero también en la dirección opuesta:
cómo tener acceso a un Java EJB el servicio de un cliente de .NET también
utilizando el canal remoto IIOP.NET, ninguna modificación en el sitio de EJB se
requiere para este propósito. Esto último es el caso de estudio de esta sección.
Alrededor de IIOP.NET
IIOP.NET es un canal remoto de .NET basado en el protocolo de IIOP. IIOP es el

protocolo definido por el estándar de CORBA, el mismo usado por Java
RMI/IIOP. IIOP.NET actúa como un ORB (agente para peticiones de objetos de
CORBA); él convierte el tipo de sistema .NET al tipo de sistema CORBA y
viceversa, haciendo los objetos definidos en su aplicación accesible a otros
ORBs. RMI/IIOP implementa un subconjunto de las funcionalidades del ORB
(debido a algunas limitaciones en sistemas tipo Java) y proporciona las mismas
características como IIOP.NET para el Plataforma de J2EE.
Vista general de un el sistema de objeto distribuido
Usando IIOP.NET casi es tan simple como usando el remoto .NET predefinido.
La aplicación siguiente le mostrará cómo tener acceso a un Java EJB desde un
servicio cliente de .NET, usando IIOP.NET. Se selecciono IIOP.NET porque es
libre, actualmente disponible y tiene una herramienta para generar el IDL
automáticamente.

Práctica: Un servicio de conversación (chat) usando IIOP.NET
Escenario
Para mostrar cómo tener acceso a un EJB desde .NET, usaremos un simple
ejemplo pero no trivial: un servicio de charla. El servicio es un EJB que permite
usuarios para registrar y eliminar un oyente por recibir los mensajes sometidos
en la sala de conversación; el EJB gestiona la lista de clientes y despacha los
mensajes a todos los clientes registrados. En seguida las interfaces y clases de
Java se usan para comunicar con el servicio; ellas deben ser convertidas a los
archivos de IDL para permitir el acceso de otros clientes de CORBA.
Un Mensaje contiene el nombre del remitente y su mensaje. El mensaje es

mapeado a un tipo de valor de CORBA, es decir un objeto que es serializado y
enviado a una máquina remota, en lugar de ser remotamente accedido.
public class Message implements Serializable {

private String m_originator;
private String m_msg;
public Message() { ... }

public Message(String msg, String originator) { ... }
public String getMsg() { ... }
public String getOriginator() { ... }
}
La interfaz MessageListener debe ser implementada por todos clientes de la sala de

conversación que desean recibir los mensajes de conversación. La interfaz
extiende java.rmi.Remote debido a que los clientes son remotos y la
comunicación se realizará con RMI/IIOP.
public interface MessageListener extends java.rmi.Remote {

/* notify the listener, that a new message has arrived. */
public void notifyMessage(Message msg) throws java.rmi.RemoteException;
}
Finalmente, la interfaz de la sala de conversación define las características

soportado por el bean sin estado, que permite enviar los mensajes y administrar la
lista de oyentes. La interfaz de inicio contiene sólo la llamada para crear un nuevo
componente y no se muestra aquí.
public interface Chatroom extends EJBObject { /*

post message in chat-room */
public void broadCast(Message msg)
throws java.rmi.RemoteException;

/* register a client, interested in chatroom messages */

public void registerMe(MessageListener listener, String forUser)
throws java.rmi.RemoteException, AlreadyRegisteredException;
/* unregister the client with the name userName. */

public void unregisterMe(String userName)
throws java.rmi.RemoteException, NotRegisteredException;
}
La sala de conversación funciona según el diagrama de secuencia de UML

siguiente:
Diagrama de secuencia de la sala de conversación
Paso 1: Instale IIOP.NET
Construir y ejecutar el ejercicio, necesita un Java SDK por lo menos 1.3, un

servidor de la aplicación (suponemos IBM WebSphere 5.0), el Framework .NET
SDK 1.0 o 1.1, el Microsoft J# SDK versión 1.0 o 1.1 e IIOP.NET (por lo menos
1.3.1).
El IIOP.NET contiene los directorios:

 IIOPChannel contiene el código del canal
 CLSToIDLGenerator contiene un generador para crear los archivos de

definición IDL desde un assembly de .NET.
 IDLToCLSCompiler contiene un generador para crear archivos CLS

(.Asamblies multi-módulos de .NET) desde las definiciones de IDL.
 Contienen ejemplos y tutoriales.
Antes de construir IIOP.NET, copie los archivos lib\ir.idl y lib\orb.idl del directorio Java
SDK en el directorio IDL IIOP.NET y establezca el entorno de variable
WAS_HOME para el directorio de aplicación de servidor de WebSphere.
Compile todo mediante nmake.
Paso 2: Implementación del EJB
Dado las definiciones anteriores, la aplicación del EJB realmente es clara .

Creamos la clase Message, las interfaces MessageListener y Chatroom
conteniendo las definiciones mostradas anteriormente.
Para la implementación del bean, se proporcionan tres archivos: la interfaz de inicio

del bean en la interfaz ChatroomHome, el propio bean en ChatroomBean, y la
implementación clase administración en ChatroomServer. La administración es
realizada en una clase separada única debido a que esta debe ser la misma para
cada bean (considerando que cada cliente consigue una instancia del bean diferente)
y el acceso a las estructuras deben sincronizarse. El bean remite las llamadas a la
clase de administración del cliente:
public void registerMe(MessageListener listener,

String forUser) throws AlreadyRegisteredException {
ChatroomServer server = ChatroomServer.getSingleton();
server.addClient(listener, forUser);
}
public void unregisterMe(String userName) throws NotRegisteredException {

server.removeClient(userName);
}
public void broadCast(Message msg) {

MessageListener[] listeners = server.getClients();
for (int i = 0; i < listeners.length; i++) {
try {

listeners[i].notifyMessage(msg); }
catch (Exception e) {
System.err.println("error sending msg: " + e);
System.err.println("--> removing listener");
server.removeListener(listeners[i]);
}
}
}
Difundiendo el mensaje se hace en el propio bean de Java para minimizar el

gasto de tiempo en la sala de conversación (durante la cual la sala de
conversación se bloquea). Enviando los mensajes puede tomar un tiempo largo,
en particular cuando un cliente no esta disponible. La solución ideal aquí sería
un CORBA unidireccional llamada asincrónica, pero esto no es posible en EJB;
la manera propuesta de llevando a cabo esto requiere usando el Servicio de
Java Mensaje (JMS); pero, por causa de simplicidad, se permitirá cada bean
mandar los mensajes.
La aplicación de ChatroomClient consiste en una instancia única que se ocupa de la

lista de clientes:
public class ChatroomServer {

private static ChatroomServer s_chatroomServer = new ChatroomServer();
private Hashtable m_clients = new Hashtable();
private ChatroomServer() { super(); }
public static ChatroomServer getSingleton() { return s_chatroomServer; }

public synchronized void addClient(MessageListener ml, String forUser)
throws AlreadyRegisteredException {
if (!m_clients.containsKey(forUser)) {
m_clients.put(forUser, ml);
} else {
throw new AlreadyRegisteredException(
"a message listener is already registered for user: "
+ forUser);
}
}
public synchronized void removeClient(String forUser)

throws NotRegisteredException {
if (m_clients.containsKey(forUser)) {
m_clients.remove(forUser);
} else {
throw new NotRegisteredException(
"no message listener registered for the user: " + forUser);

}
}
public synchronized void removeListener(MessageListener listener) {

m_clients.values().remove(listener);
}
public synchronized MessageListener[] getClients() {

MessageListener[] result = new MessageListener[m_clients.size()];
result = (MessageListener[])(m_clients.values().toArray(result));
return result;
}
}
Note que el método de implementación getClients () devuelve una copia de la lista
del oyente para evitar los problemas de la sincronización.
Paso 3: Generación de los archivos de IDL
Una vez que el servicio es implementado, el próximo paso es la generación de

archivos de IDL que describen la interfaz de servicio mediante el modelo del
CORBA.
Cada servidor de la aplicación proporciona su propia manera de generar el IDL,

porque cada servidor de la aplicación funciona con versiones diferentes de
especificaciones del EJB que a su vez tienen las interfaces diferentes.
Refiérase a la documentación de servidor de aplicación para el procedimiento

exacto para generar los archivos de IDL.
El paso 4: Generación de los módulos CLS desde los archivos de IDL
De los archivos de IDL, la herramienta IDLToCLSCompiler genera un assembly

multimódulo CLS que contiene las clases e interfaces requeridas para acceder al
servicio basado en EJB.
¿Por qué el generador crea un netmodule en lugar de un stub de C#? Bien, hay unas
razones, pero los más importantes son la simplicidad y portabilidad. Primero,
los netmodules son bastante fáciles de generar usando la interfaz de reflexión
emitada de .NET; el código fuente generador requeriría algún algoritmo
pretty-printing. Segundo, los netmodules contienen las definiciones en la forma CLS,
lo cual se entiende por todos los lenguajes conforme a .NET, así no le importa si
su código está en C# o Visual Basic.
Invoque el generador que especifica el directorio de salida (- o) y los archivos idl para
usar.

IDLToCLSCompiler.exe -o ..\bin chatroom

ch\elca\iiop\demo\ejbChatroom\Chatroom.idl
ch\elca\iiop\demo\ejbChatroom \ChatroomHome.idl
El generador le recordará que debe proporcionar la implementación para

algunas clases: éstas son las clases que implementa el valuetypes del CORBA;
en .NET estas clases están definidas con el atributo Serializable (no confunda el
valuetypes de CORBA con clase de valuetype de .NET). El contenido de estas
clases se duplica al sistema designado, así los métodos que proporciona
también deben estar disponibles en el sistema remoto. Debido a que el IDL no
contiene ningún código, tiene que proporcionar este código (este esfuerzo
normalmente se limita al constructor de la clase).
En nuestro caso, las clases a ser implementadas son la

NotRegisteredException, AlreadyRegisteredException y Message definido por
nuestro servicio; y Throwable, _Exception, CreateException, RemoveException
(definido por Java, RMI o el EJB). Algún EJBs puede requerir la definición de
adicional clases.
Nuestra aplicación de esas clases esta en ExceptionImpl.cs y MessageImpl.cs.
using System;
namespace ch.elca.iiop.demo.ejbChatroom {
///<SUMMARY>
/// Implementation of the CORBA value type Message ///
</SUMMARY>
[Serializable] public class MessageImpl : Message {

public MessageImpl() { }
public MessageImpl(string originator, string msg) {
m_originator = originator;
m_msg = msg;
}
public override string fromUser {
get { return m_originator; }
}
public override string msg {
get { return m_msg; }
}
}
}
Tenga presente que IIOP.NET buscará para la clase ClassImpl como

implementación para la clase valuetype de CORBA. Así, las clases para proveer son
nombradas NotRegisteredExceptionImpl, AlreadyRegisteredExceptionImpl, y así
sucesivamente.

Paso 5: Implementación del cliente en C#
El cliente proporciona una interfaz del usuario para coleccionar los mensajes del
usuario, invoque el servicio y despliegue la información enviada por el servicio. Un
simple GUI es utilizado; independientemente de la interfaz del usuario, hay unas
cosas importantes para hacer. Primero, registre el canal IIOP.NET, conecte al EJB y
consigue un caso del servicio.
// register IIOP.NET channel

IiopChannel channel = new IiopChannel(callbackPort);
ChannelServices.RegisterChannel(channel);
// get the naming service

RmiIiopInit init = new RmiIiopInit(ejbNameServiceHost,
ejbNameServicePort);
NamingContext nameService = (NamingContext)init.GetService(
"NameServiceServerRoot");
NameComponent[] name = new NameComponent[] {

new NameComponent("demo", ""),
new NameComponent("chatroomHome", "") };
// get the chatroom home interface

ChatroomHome home = (ChatroomHome) nameService.resolve(name);
Chatroom chatroom = home.create();
El ejbNameServiceHost y ejbNameServicePort, y el nombre del componente

dependen sobre el servidor de la aplicación y la forma del servicio es
configurada y registrada allí.
Para poder recibir los mensajes, el cliente debe registrar a un oyente, es decir un
objeto remoto que implementa la interfaz MessageListener.
m_listener = new MessageListenerImpl(m_usernameTextbox.Text, this);

m_chatroom.registerMe(m_listener, m_listener.userName);
Ahora la sala de conversación está lista ser usado. Enviando un mensaje al

cuarto es simple:
MessageImpl msg = new MessageImpl(m_listener.userName,

m_messageTextbox.Text);
try {
m_chatroom.broadCast(msg); }
catch (Exception ex) {
Console.WriteLine("exception encountered, while broadcasting: " + ex);

MessageBox.Show("an exception occured, while broadcasting!");

}
Este código realiza una invocación del método sincrónico, es decir espera para
el servidor para completar la difusión y retorno. Sin embargo, esto no es
obligatorio, como los regresos de llamada no resultan y el cliente no tiene la
necesidad de sincronizar con el servidor. Así, una invocación asincrónica
también es posible:
delegue BroadCastDelegate nulo (mensaje del Mensaje);
delegate void BroadCastDelegate(Message msg);
MessageImpl msg = new MessageImpl(m_listener.userName,

m_messageTextbox.Text);
try {
BroadCastDelegate bcd = new BroadCastDelegate(m_chatroom.broadCast); //
async call to broadcast
bcd.BeginInvoke(msg, null, null); //
do not wait for response
} catch (Exception ex) {
Console.WriteLine("exception encountered, while broadcasting: " + ex);
MessageBox.Show("an exception occured, while broadcasting!");
}
El método oyente notifyMessage() se llamará por los servicios EJB siempre que un
nuevo mensaje esté disponible. Este método lleva a cabo el proceso de llamadas
entrantes por el cliente.
Paso 6: Ejecución de la aplicación
En el lado del servidor, el Makefile para el servicio EJB Websphere

automáticamente registra al servidor de la aplicación, para que necesite arrancar el
servidor (en caso de que ya no está corriendo).
En el lado del cliente, lance la aplicación; entonces establezca su nombre,

conecte al servidor y podrá enviar y recibir los mensajes.

La interfaz de usuario del cliente .NET

Acceso de un EJB desde .NET usando IIOP.NET
4.2 Desarrollo de un Sistema Distribuido
Actividad 4.2
Desarrollo de un Proyecto Final
Utilizar la técnica de Aprendizaje Orientado a Proyectos, descrito en el rubro de

Panorama General del tema 3 de tecnologías de desarrollo, para desarrollar un
sencillo proyecto de sistema distribuido, propuesto por ustedes.
Rúbrica para evaluación del proceso de AOP
Puntos de
Estándar Estándar Obtenidos
(10-9) (8.5-7) (6.5-0)
El producto final La
Trabajo en equipo
del equipo ha presentación es
con asignación de
sido compartido el resultado del
Colaboración con todo el roles y todos se
esfuerzo de un
esfuerzan en
equipo y grupo, pero
llevar a cabo sus
representa algo solamente han
responsabilidades.
que habría sido contribuido

Material Sistemas Distribuidos PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Material Sistemas Distribuidos PDF

Cargado por

Copyright:

Formatos disponibles

Resumen Sistemas Distribuidos

1. Entender y emplear los conceptos principales que caracterizan a los sistemas

2. Distinguir los temas más importantes sobre la implementación de sistemas

3. Desarrollar una aplicación de sistema distribuido en una plataforma de

4. Apreciar las ventajas y desventajas del ambiente distribuido en aplicaciones de

APRENDIZAJE BASADO EN PROBLEMAS (ABP)

La técnica de aprendizaje basado en problemas esta orientada al constructivismo, que

1. Presentación del problema o tema

La técnica de comprobación de lectura tiene como finalidad fomentar en el alumno la

La técnica de comprobación de lectura es una de las más empleadas en los

ESTUDIO DE CASOS (EC)

El estudio de casos difiere de los sistemas de enseñanza tradicionales porque

de decisiones para la solución a situaciones reales muy específicas. El proceso

1. Presentación del caso

APRENDIZAJE ORIENTADO A PROYECTOS (AOP)

La técnica de aprendizaje orientado a proyectos permite consolidar el proceso de

· Distributed Systems, Concepts and Design.

· Distributed Systems: Principles and Paradigms

· Distributed Computing: Principles and Applications

Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. VI

Tareas que se integran: TI (1) y TE (1)

· Rúbrica de evaluación de ejercicios prácticos como Evaluación Ejercicios.

· Rúbrica de evaluación de aprendizaje basado en problemas como Evaluación

Tareas que se integran: TE (3.1)

· Rúbrica de evaluación de estudio de casos como Evaluación EC.

Tareas que se integran: TI (3.3) y TE (3.3)

· Rúbrica de evaluación de aprendizaje orientado a proyectos como Evaluación

Tareas que se integran: TE (4.2)

3. TECNOLOGÍAS DE DESARROLLO ........................................................................................................... 91

Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. VIII

• Los conceptos fundamentales que caracterizan a los sistemas distribuidos.

• Las ventajas y desventajas que presentan los sistemas distribuidos.

• La evolución de los sistemas distribuidos.

· Utilice tablas, ilustraciones, mapas mentales o en su caso mapas conceptuales.

· Consultar por lo menos otra fuente de información y mencionarla, con el fin de

· La síntesis no debe de exceder más de seis cuartillas.

· Agregar sus objetivos de aprendizaje que desea alcanzar del curso.

Discutir en equipo las características que muestran los sistemas distribuidos y

· Intercambien sus mensajes de discusión en el Foro Actividad 1.2

Una vez completada la Actividad 1.2, colocar su documento en Tarea en Equipo

Nota Importante: Ambas actividades 1.1 y 1.2 serán evaluadas de acuerdo a la

Se pueden resaltar las siguientes peculiaridades del tema:

Es un área de cambios constantes, debido al vertiginoso avance de tecnologías, tanto

La complejidad de un sistema distribuido que abarca gran cantidad de

Sin embargo, existe ya un cuerpo de principios fundamentales, de ideas básicas

El temario del curso trata de identificar aspectos esenciales de lo que es un

Consideramos de primera importancia formar alumnos que puedan resolver

Primero, es esta un área de cambios constantes, debido al vertiginoso avance

Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. 2

interactiva, telefonía celular, comunicadores personales (pagers) que pueden

Segundo, la enorme complejidad de un sistema distribuido, que se aprecia al

1.1.1 ¿Qué es un Sistema Distribuido?

Antes de definir lo que es un Sistema Distribuido, vamos a definir un término

La Computación Distribuida hace referencia a cualquier evento en el cual se

Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. 3

Una de las primeras caracterizaciones de un Sistema Distribuido fue realizada por

 Está compuesto por varios recursos informáticos de propósito general,

 Existencia de varias computadoras. En general, cada una con su propio

Como lo hemos observado, el término de Computación Distribuida se define de

Modelo Paracurricular - Desarrollador de Software - 2004 - V.1.0. 4

1.1.2 Características de un Sistema Distribuidos

Cualquier diseñador de sistemas debe tener los conocimientos necesarios para