IntroduccionSistemasDistribuidos SE PDF

Introduccin a los Sistemas Distribuidos
CURSO
INTRODUCCIN A LOS
SISTEMAS DISTRIBUIDOS
Modelo Paracurricular Desarrollador de Software 2004 V.1.0.
BIENVENIDA
Nos es grato recibirte en esta iniciativa de preparacin y actualizacin de tus
conocimientos en el panorama que presentan las aplicaciones de los sistemas
distribuidos en la industria del Software.
Este curso de introduccin a los sistemas distribuidos presenta tanto las bases
tericas como la aplicacin prctica en plataformas actuales de desarrollo, al final
del mismo, contars con los conocimientos fundamentales requeridos en los
desarrolladores de software modernos.
Bienvenido(a) al curso de introduccin a los sistemas distribuidos, desendote
mucho xito en el curso y aprovechamiento del mismo.
INTENCIN EDUCATIVA
Contribuir al fortalecimiento de tu formacin profesional en los temas relevantes de
tecnologas de la informacin, especialmente en el campo de los sistemas
distribuidos, los cuales se han popularizado por la alta demanda de aplicaciones
de Internet. Con ello tendrs ms 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 ms importantes sobre la implementacin de sistemas
distribuidos.
3. Desarrollar una aplicacin de sistema distribuido en una plataforma de
desarrollo conveniente.
4. Apreciar las ventajas y desventajas del ambiente distribuido en aplicaciones de
computacin mvil.
INTRODUCCIN
El proyecto PROSOFT surge como una alternativa en la capacitacin y formacin
de estudiantes y profesionales de la informtica, a travs de cursos, que
II

comprenden desde temas bsicos hasta avanzados, estructurados de acuerdo a
estrategias didcticas comprobadas y metas de aprendizaje alcanzables.
Especialmente, el curso de Introduccin a los Sistemas Distribuidos comprende
temas fundamentales como el paradigma cliente -servidor, middleware y
computacin mvil. Temas que encierran aspectos representativos y novedosos
de los ambientes distribuidos con aplicacin prctica en plataforma de tecnologas
como Java, .NET y CORBA.
Es importante destacar que por la intensidad de la temtica del curso, en principio
se aplican tcnicas didcticas orientadas a un aprendizaje basado en problemas y
que en conjunto con la comprobacin de lecturas y ejercicios, los participantes en
forma individual y grupal estarn en posibilidades de alcanzar metas comunes
para:
Proponer la solucin de un problema.
Decidir en el estudio de un caso.
El diseo y desarrollo de un proyecto.
De tal forma que el curso esta organizado de la manera siguiente:
El tema 1, Introduccin, trata sobre los fundamentos, ventajas, desventajas y
evolucin de los sistemas distribuidos, se realizarn actividades de lectura y
anlisis de la informacin.
El tema 2, Arquitectura cliente-servidor, muestra conceptos fundamentales de
este paradigma sobre los cuales, para su mejor comprensin, se llevarn a cabo
ejercicios prcticos de sockets, RPC y modelado de capas.
El tema 3, Tecnologas de desarrollo, se analizar el concepto de middleware y
su importante papel en el paradigma de los ambientes distribuidos, se plantean
ejercicios prcticos de las tecnologas Java y .Net que van en direccin de estos
ambientes. Por otro lado CORBA se tratar como un caso de estudio.
El tema 4, Lenguajes de programacin, hasta este punto una vez tratados los
temas previos, se estar en posibilidad de desarrollar un pequeo proyecto de
implementacin de un sistema distribuido.
El tema 5, Computacin mvil, siendo un tema notable dentro de los ambientes
distribuidos, se abordan los antecedentes, paradigmas y lenguajes de
programacin. Realizarn un ejercicio prctico de aplicacin mvil.
Ahora bien, los exhortamos a cubrir en orden y forma las actividades de
aprendizaje de cada uno de los temas, con la finalidad de que alcance un nivel
satisfactorio del curso.
III
Agradecimiento y Reconocimiento
Despus de una ardua tarea de investigacin se ha logrado la creacin de una
obra vasta en conocimiento en el desarrollo de las Tecnologas de la Informacin y
Comunicacin.
La presente obra no hubiera sido posible sin la valiosa aportacin de destacados
autores y especialistas en la materia. Es por ello que a manera de reconocimiento
queremos agradecer su participacin:
INTRODUCCIN A LOS SISTEMAS DISTRIBUIDOS

Mtro. Sergio Gonzlez Nava
Universidad La Salle
Ing. Guillermo Cheang Len
CETYS Universidad Campus Mexicali
M. en C. Eiso Jorge Kashiwamoto Yabuta
Instituto Latinoamericano de la Comunicacin Educativa,
Universidad La Salle
IV
METODOLOGA
Se emplearn diferentes tcnicas didcticas para cubrir los temas del curso y se
har referencia en las actividades de aprendizaje sobre el manejo de ellas y la
forma de evaluacin basada en rbricas. Las tcnicas didcticas son las
siguientes:
APRENDIZAJE BASADO EN PROBLEMAS (ABP)
La tcnica 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 sntesis,
conclusiones o realizacin de metas de aprendizaje. En esta tcnica 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. Presentacin 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. Investigacin individual
7. Discusin y reporte.
8. Si todava hay ideas y preguntas sigue paso 3
9. Integracin de solucin.
COMPROBACIN DE LECTURA
La tcnica de comprobacin 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 tcnica de comprobacin de lectura es una de las ms empleadas en los
procesos de enseanza-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 enseanza tradicionales porque
exige que el alumno tome parte activa en el anlisis de los problemas y en la toma
de decisiones para la solucin a situaciones reales muy especficas. El proceso
que se siga para tomar decisiones y las decisiones mismas, sustentadas en un
anlisis 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. Presentacin del caso
2. Preparacin individual
3. Grupos de discusin
4. Plenaria
APRENDIZAJE ORIENTADO A PROYECTOS (AOP)
La tcnica de aprendizaje orientado a proyectos permite consolidar el proceso de
aprendizaje en un proyecto final que representa una conexin con la realidad,
dado que en pequeos 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 INFORMACIN
Referencias bibliografas:
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/
VI
REGLAS Y EVALUACIN
El curso tiene una serie de actividades que sirven como medio para que los
alumnos encuentren significado y propicien la construccin de los conocimientos
bajo las estrategias didcticas que el programa seala. No se trata de ejercicios
memorsticos o de una labor informativa del tutor sino de desafos, ejercicios e
investigaciones desarrolladas por los alumnos con un enfoque de aprendizaje
cooperativo e independiente. Los alumnos debern entregar con oportunidad las
tareas individuales y en equipo determinadas para cada tema y con el formato
adecuado. El informe de los ejercicios prcticos que deban presentar tiene la
modalidad de que detallen o amplen el funcionamiento de ellos o en su caso la
compilacin correspondiente. Los alumnos debern participar interactivamente
mediante los apoyos de e-mail, foros, y Chat para retroalimentar su trabajo en
equipo y comunicacin con el tutor. Rbrica de evaluacin de comprobacin de
lecturas como Evaluacin Sntesis.
Tareas que se integran: TI (1) y TE (1)
Rbrica de evaluacin de ejercicios prcticos como Evaluacin 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).
Rbrica de evaluacin de aprendizaje basado en problemas como Evaluacin
ABP.
Tareas que se integran: TE (3.1)
Rbrica de evaluacin de estudio de casos como Evaluacin EC.
Tareas que se integran: TI (3.3) y TE (3.3)
Rbrica de evaluacin de aprendizaje orientado a proyectos como Evaluacin
AOP.
Tareas que se integran: TE (4.2)
VII
CONTENIDO
BIENVENIDA.....................................................................................................................................................................II
INTENCIN EDUCATIVA ...........................................................................................................................................II
OBJETIVOS GENERALES ...........................................................................................................................................II
INTRODUCCIN .............................................................................................................................................................II
METODOLOGA ..............................................................................................................................................................V
FUENTES DE INFORMACIN.................................................................................................................................VI
REGLAS Y EVALUACIN.......................................................................................................................................VII
1.
INTRODUC CIN ................................................................................................................................................... 1

1.1.
1.2.
1.3.
1.4.
2.
ARQUITECTURA CLIENTE SERVIDOR ..................................................................................................33

2.1.
2.2.
2.3.
3.
FUNDAMENTOS .................................................................................................................................................3
VENTAJAS Y FACTORES DE DISTRIBUCIN.................................................................................................23
DESVENTAJAS Y FACTORES A CONSIDERAR...............................................................................................25
EVOLUCIN.....................................................................................................................................................26
FUNDAMENTOS DE A RQUITECTURA CLIENTE SERVIDOR .........................................................................33

COMUNICACIN ENTRE PROCESOS ..............................................................................................................40
M ODELO DE CAPAS........................................................................................................................................80
TECNOLOGAS DE DESARROLLO............................................................................................................ 91
3.1.
INTRODUCCIN AL MIDDLEWARE................................................................................................................98
3.2.
PROGRAMACIN DE TRANSACCIONES......................................................................................................104
3.2 PROGRAMACIN DE TRANSACCIONES ...............................................................................................................108
3.3.
CORBA ........................................................................................................................................................124
3.4.
RMI ...............................................................................................................................................................161
3.5.
COM+ ...........................................................................................................................................................166
3.6.
W EB SERVICES.............................................................................................................................................221
4.
LENGUAJES DE PROGRAMACIN.........................................................................................................227
4.1.
4.2.
5.
LENGUAJES Y PLATAFORMAS DE DESARROLLO.....................................................................................227

DESARROLLO DE UN SISTEMA DISTRIBUIDO ...........................................................................................237
COMPUTACIN MVIL...............................................................................................................................248
5.1.
5.2.
5.3.
5.4.
A NTECEDENTES EN COMPUTACIN M VIL .............................................................................................248

PARADIGMAS DE LA COMPUTACIN MVIL .............................................................................................260
LENGUAJES Y A MBIENTES DE PROGRAMACIN DE COMPUTACIN M VIL .......................................263
A PLICACIONES MVILES............................................................................................................................293
VIII
1. Introduccin
Objetivos
Al trmino del estudio del tema de introduccin, el participante comprender:
Los conceptos fundamentales que caracterizan a los sistemas distribuidos.
Las ventajas y desventajas que presentan los sistemas distribuidos.
La evolucin de los sistemas distribuidos.
Actividades (1)
Actividad 1.1
Realizar una sntesis sobre los conceptos de introduccin 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 informacin y mencionarla, con el fin de
enriquecer su trabajo de sntesis.
La sntesis no debe de exceder ms 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 caractersticas que muestran los sistemas distribuidos y
elaborar una sntesis.
Intercambien sus mensajes de discusin 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 sern evaluadas de acuerdo a la
rbrica localizada en Evaluacin Sntesis.
Introduccin
La computacin distribuida ha ido tomando ms y ms importancia con el impresionante
desarrollo de las telecomunicaciones y conforme los avances tecnolgicos han hecho
posible la construccin 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, telefona, enviar correos electrnicos, obtener
informacin 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 tecnologas,
tanto de hardware como de software de nuevas ideas, modelos conceptuales y
herramientas matemticas.
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 bsicas
subyacentes que permiten entender muchos de los aspectos de un sistema
distribuido. El objetivo de este curso es introducir al alumno a modelos, tcnicas
y conceptos relevantes, independientemente de las tecnologas del momento.
Desarrollar en el alumno una capacidad de anlisis, 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 presentacin coherente y continua,
buscando que los temas presentados parezcan suceder unos a otros de manera
natural. Ms que aspirar a un alcance en cantidad de los temas presentados, es
decir, de informacin, 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
crtica y creadora. Pensamos que la manera de lograr esto es: a) logrando un
entendimiento a fondo, y b) aprendiendo resolver problemas difciles;
enfocndose en material esencial, en principios fundamentales subyacentes no
solo a las tecnologas 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 tecnologas, tanto de hardware como de software: las redes de computadoras
cambian constantemente, incorporando lneas de comunicacin ms rpidas
cada vez, y de nuevos tipos, como fibra ptica y redes mviles de radio. Nuevas
arquitecturas como ATM, sistemas cada vez mas sofisticados de televisin

interactiva, telefona celular, comunicadores personales (pagers) que pueden
transmitir adems de recibir. Multiprocesadores ms poderosos, redes de
estaciones de trabajo. Se generan constantemente nuevas ideas, y modelos
conceptuales que cambian nuestra manera de ver el cmputo y manejo de
informacin distribuida; quizs el ejemplo ms dramtico es Web, pero existen
otros como las listas de correo y noticias electrnicas, nuevos lenguajes y
paradigmas, que generan nuevos problemas fascinantes y que cambian las
suposiciones de problemas conocidos (por ejemplo, la relacin entre la velocidad
de procesamiento y la de transmisin). Entre tanto, se descubren nuevas y ms
poderosas herramientas matemticas para solucionar los problemas, como
probabilidad, lgebra combinatoria y topologa.
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 comunicacin : cdigos para deteccin de errores,
protocolos de enlaces, problemas de ruteo, congestin, ATM, etc.
Sincronizacin: exclusin mutua, relojes, abrazos mortales, etc. Manejo de
procesos: administracin de recursos, threads, tolerancia a fallas, tiempo real,
calendarizacin, etc. Seguridad y criptologa. Uso compartido de memoria.
Especificacin, modelado y verificacin. Complejidad y anlisis 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 trmino
ms general: La Computacin Distribuida, podemos definirla de muchas
maneras, este trmino se utiliza indiscriminadamente para referirse a cualquier
sistema en el que mltiples agentes autnomos, cada uno con capacidades de
cmputo individual, se comunican entre s y afectan mutuamente su
comportamiento. Los agentes, usualmente llamados procesadores, procesos o
nodos, pueden ser desde computadoras completas hasta autmatas celulares
con capacidad de cmputo y memoria muy limitados que se pueden comunicar
mediante mensajes.
La Computacin 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 trmino
computacional que sea distribuido. Podemos decir entonces, que la
Computacin Distribuida se refiere a los servicios que provee un Sistema de
Computacin 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 informticos de propsito general,

tanto fsicos como lgicos, que pueden asignarse dinmicamente a tareas
concretas.
Estos recursos estn distribuidos fsicamente, 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 distribucin es transparente, permitiendo que los servicios
puedan ser solicitados especificando simplemente su nombre (no su
localizacin).
El funcionamiento de los recursos fsicos y lgicos est caracterizado por
una autonoma coordinada.
A pesar del tiempo transcurrido, esta definicin sigue siendo, en esencia, vlida.
As, para Coulouris un sistema distribuido es aqul que est compuesto por
varias computadoras autnomas conectadas mediante una red de
comunicaciones y equipadas con programas que les permitan coordinar sus
actividades y compartir recursos. Bal ofrece una definicin muy similar: ``Un
sistema de computacin distribuida est compuesto por varios procesadores
autnomos que no comparten memoria principal, pero cooperan mediante el
paso de mensajes sobre una red de comunicaciones''. Y segn Schroeder, todo
sistema distribuido tiene tres caractersticas bsicas:
Existencia de varias computadoras. En general, cada una con su propio

procesador, memoria local, subsistema de entrada/salida y quizs incluso
memoria persistente.
Interconexin. Existen vas que permiten la comunicacin entre las
computadoras, a travs de las cuales pueden transmitir informacin.
Estado compartido. Las computadoras cooperan para mantener algn tipo
de estado compartido. El funcionamiento correcto del sistema se
describirse como el mantenimiento de una serie de invariantes globales
que requiere la coordinacin de varias computadoras.
Como lo hemos observado, el trmino de Computacin Distribuida se define de

varias maneras y lo mismo se aplica al trmino de Sistema Distribuido, as que
en lugar de seguir dando ms definiciones de estos trminos, nos
concentraremos en el anlisis de las caractersticas ms importantes de los
Sistemas Distribuidos, de esta manera podremos construir una definicin propia
de lo que es un Sistema Distribuido al finalizar este captulo.
Una caracterstica 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 organizacin interna del sistema distribuido. Otra
caracterstica 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 interaccin.
Todo Sistema Distribuido bebe tambin ser relativamente fcil 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 ningn momento que estas partes estn
siendo reemplazadas o reparadas, o que se han agregado nuevas partes al
sistema para poder dar servicio a ms usuarios o aplicaciones.
1.1.2 Caractersticas de un Sistema Distribuidos
Cualquier diseador 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
continuacin explicaremos cada una de las caractersticas de los Sistemas
Distribuidos, segn Coulouris son estas caractersticas, los desafos 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 slo se
aplica a las redes y al hardware de las computadoras, sino tambin a los
sistemas operativos, los lenguajes de programacin 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
implementacin de los protocolos de Internet para cada una de esas redes.
Figura 1. Un esquema clsico de la conexin a Internet

Otro ejemplo lo podemos ver en los lenguajes de programacin y en las
aplicaciones escritas por diferentes programadores; en el caso de los lenguajes
de programacin es importante tener en cuenta las diferencias que puede haber
en la representacin 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 estndares comunes para la comunicacin en red y para la
representacin de los datos elementales y las estructuras de datos en los
mensajes, ya que si no se cuenta con dichas similitudes, los programas no
podrn comunicarse entre s aunque se hayan desarrollado en el mismo
lenguaje de programacin.
Un trmino que no podemos dejar de mencionar al hablar de heterogeneidad es
el de Middleware (Figura 2); este trmino se aplica a la capa de software que
provee una abstraccin de programacin, as como un enmascaramiento de la
heterogeneidad subyacente de las redes, hardware, sistemas operativos y
lenguajes de programacin; adems, el Middleware proporciona un modelo
computacional uniforme al alcance de programadores de servidores y
aplicaciones distribuidas que permite la invocacin sobre objetos remotos,
notificacin 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 describirn con ms detalle en el captulo
3 de este curso.
Figura 2. Un sistema distribuido organizado como Middleware

Otro trmino importante para este apartado es el de cdigo mvil, que se emplea
para referirse al cdigo que pude ser enviado de una computadora a otra para
que esta ltima la ejecute, un ejemplo de un cdigo mvil 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 cdigo de este tipo
podemos encontrarno s con el problema de que el conjunto de instrucciones (a
nivel mquina) de una computadora puede no ser el apropiado para otra
mquina, 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 mquinas
virtuales, las cuales proveen un modo de crear cdigo ejecutable sobre cualquier
hardware, ya que el compilador de un lenguaje concreto generar un cdigo
para una mquina virtual y esta se encargar de traducir dicho cdigo al
apropiado para un hardware particular, as, un compilador de Java producir un
cdigo para la mquina virtual de Java, y esta ltima slo necesitar ser
implementada una sola vez para cada mquina en la que se va a ejecutar.
1.1.2.2 Extensibilidad y Apertura
La extensibilidad y la apertura son dos caractersticas de un sistema distribuido
que estn 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 caractersticas.
Un sistema distribuido abierto es un sistema que ofrece servicios desarrollados
de acuerdo a reglas estandarizadas que describen la sintaxis y la semntica 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 envan y
se reciben a travs de dicha red. Estas reglas son formalizadas en protocolos.
En el caso de los sistemas distribuidos, los servicios se especifican
generalmente a travs de interfaces que por lo general son descritas en un
Lenguaje de Definicin de Interfaz (IDL por sus siglas en ingles), dicho lenguaje
especifica los nombres de las funciones que estn disponibles as como los

parmetros de entrada, los valores de salida y los posibles errores que pueden
obtenerse al invocarse dichas funciones.
Si la definicin 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 tambin permite que cada dos
desarrolladores independientes construya n su propia implementacin de dichas
interfaces, lo cual conlleva al desarrollo de dos sistemas distribuidos
desarrollados por separado que operan de la misma manera.
Una especificacin se considera adecuada cuando es completa y neutral.
Completa significa que todo lo necesario para hacer una implementacin de la
interfaz ha sido especificado y que no ser necesario que el propio desarrollador
sea quien agregue detalles especficos de la implementacin. Neutral significa
que las especificaciones no deben tener ninguna tendencia hacia como se debe
de hacer la implementacin de dicha especificacin. La completitud y la
neutralidad son muy importantes para la interoperabilidad y la portabilidad, que
son caractersticas que complementan la apertura de un sistema distribuido. La
interoperabilidad, tambin conocida como compatibilidad, caracteriza el grado en
el que la implementacin de sistemas o componentes de diferentes fabricantes
pueden coexistir y trabajar juntos, siempre y cuando se utilicen los servicios
como este especificado por el estndar comn bajo el cual dichos sistemas
fueron desarrollados. La portabilidad por su parte caracteriza a que nivel puede
ser ejecutada una aplicacin 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 mdulos o componentes relativamente pequeos y
fciles de reemplazar, esto implica que adems de definir las especificaciones y
la documentacin de las interfaces de alto nivel a las que tienen acceso los
usuarios y las aplicaciones, tambin es necesario definir las especificaciones de
las interfaces de las partes internas que componen el sistema y describir de que
manera interactan entre s.

1.1.2.3 Seguridad
La gran mayora de la informacin que maneja un sistema distribuido tiene un
alto valor para los usuarios de dicho sistema, y es por eso que la seguridad de la
informacin juega un papel clave al momento de desarrollar dicho sistema.
La seguridad de la informacin es todo lo que concierne a asegurar que no
ocurrirn cosas malas con los mensajes que envan los clientes para solicitar
informacin a un servidor, y por su puesto, con la informacin que estos reciben
como respuesta a sus peticiones. No basta con asegurar que estos mensajes
sern transmitidos de forma oculta, sino que tambi n hay que asegurar que la
informacin 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 fcil de obtener.
La seguridad debe ofrecer los siguientes servicios:
Confidencialidad, es decir, el manejo privado de la informacin: proteger la
informacin de ser accedida por usuarios no autorizados.
Autentificacin, o capacidad de asegurar la identidad de un usuario.
Integridad, que asegura que la informacin que empleamos no ha sido
manipulada, alterada o corrompida desde el origen.
No repudio, de una operacin de emisin y recepcin de informacin por
parte de los agentes.
Control de acceso a la informacin y/o recursos administrados por un
sistema.
Disponibilidad de los recursos necesarios de un sistema cuando estos sean
requeridos, lo que protege la informacin contra interferencia con los
procedimientos de acceso a los recursos.
El alto valor de que tiene la informacin es la razn principal por la que esta se
puede ver amenazada de muchas formas, entre las principales podemos
encontrar:
Interrupcin: Destruye la informacin o la inutiliza. Ataca la disponibilidad.
Interceptacin: Obtiene acceso a informacin. Ataca la confidencialidad.

Modificacin: Modifica la informacin. Ataca la integridad.
Fabricacin: Falsifica la informacin. Ataca la autenticidad.
Para defenderse de este tipo de amenazas se han desarrollado diversas

tcnicas de encriptacin, firmas digitales, implementacin de barreras
perimetrales (firewalls), modelos de seguridad internos y externos, etc. Sin
embargo, estas tcnicas parecen no ser suficientes para evitar que intrusos
logren interferir con el flujo de informacin ptimo de un sistema, ya que
encuentran formas de brincarse las barreras de seguridad de muchas
organizaciones y adems siguen ideando nuevas formas de atacar y amenazar
la informacin, un ejemplo de estos nuevos ataques son los ataques de
denegacin de servicio. Estos ataques consisten en bombardear un servicio con
un gran nmero de peticiones simultneas (y por lo general intiles) de modo
que el sistema se colapse, obstaculizando el servicio a los usuarios que desean
utilizarlo. Como hoy en da la capacidad de los sistemas distribuidos ha crecido
mucho, en ocasiones resulta muy difcil o incluso imposible bloquear el servicio
utilizando una sola computadora atacante, por lo que ahora se han desarrollado
los ataques de denegacin 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 ms robusto
posible, que a pesar de no ser inmune a todo tipo de ataques, si ser capaz de
frenar la gran mayora de dichos ataques. Algunas recomendaciones muy tiles
para los desarrolladores, administradores e implementadotes de un sistema
distribuido se presentan a continuacin:
a) Efectuar un anlisis 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
10

cules involucran ms 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 funcin directa a las prdidas que
ocasionara el que ste deje de operar, as como en funcin de cun 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 informacin
representa para una organizacin; pero una simple PC Windows de la misma
organizacin conectada directamente al Internet (sin firewall/proxy de por
medio) tambin lo representa, debido a que puede ser objeto de un ataque
desde el exterior, con el posible riesgo de fcil propagacin hacia otros
computadores de nuestra red.
b) Lo ms valioso debe alejarse de lo ms vulnerable
En la frmula del "riesgo" propuesta arriba, es evidente que los componentes de
nuestro sistema con alto valor y alta vulnerabilidad sern 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 prdida 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 electrnico deben dar cara a Internet (siendo vulnerables en
principio) y a la vez manejar informacin muy costosa (como transacciones con
tarjeta de crdito.) Esto los convierte en un sistema de alto riesgo. Sin embargo
es casi universal la separacin que se efecta entre los componentes dedicados
a dar cara a Internet (como los Web Servers) y los componentes que manipulan
la informacin comercial (generalmente sistemas DBMS.) En trminos prcticos,
esto significa que el hacker no puede acceder directamente al DBMS (lo que
sera catastrfico), y slo podra atacar al Web Server, lo que en principio no
acarrea mayo res consecuencias.
11

c) Mantener las cosas simples
Un sistema complejo es ms difcil de asegurar y potencialmente proporciona
una mayor cantidad de puertas abiertas a los atacantes. En general, es
recomendable intentar dividir el problema mediante la simplificacin de la
configuracin, 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 ms sencillamente como: no confiar el sistema a un
nico mecanismo de seguridad.
La informacin fluye a travs de los distintos componentes y/o capas del sistema
y son muchas las instancias en las que se puede mejorar su seguridad. La
recomendacin 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
conexin a Internet.) Por tanto se invierte esfuerzo y dinero en controlar este
nico punto bajo la asuncin 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 organizacin.
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 informacin al interior de
cada componente involucrado.
Encriptar tanto como sea posible
La encriptacin es un tema complejo pero cuya implementacin resulta cada vez
ms sencilla conforme aparecen ms productos. Los cambios del ao pasado en
la legislacin norteamericana con respecto a la exportacin de productos que
encriptan, son un incentivo claro para que los desarrolladores y vendedores se
interesen ms en el tema.
En general, los canales de comunicacin ms vulnerables o de mayor cercana
al pblico requieren una encriptacin "ms fuerte", es decir, ms difcil de
descifrar por los curiosos o atacantes. Cierta informacin conlleva ms riesgo
que otra, y por tanto requerir un nivel de encriptacin diferenciado. Las
herramientas capaces de hacer esto son muchas, dependiendo del contexto en
que nos encontremos. Por ejemplo, los sistemas DBMS ms avanzados
12

incorporan la encriptacin como una opcin normal para los datos almacenados,
generalmente bajo esquemas propietarios.
La tecnologa de encriptacin de informacin destinada a pasar a travs de la
red ha evolucionado bastante, hacindose popular el trmino VPN para hacer
referencia a canales que encriptan la informacin de un modo ms o menos
transparente. Hay soluciones propietarias as como estndares relativamente
implementados como IP Sec. Ciertas aplicaciones estndares han recibido
soluciones de encriptacin tambin estndar. El caso del Web encriptado bajo
SSL (HTTPS) junto con la industria de certificados digitales es el caso ms
conspicuo. De igual modo los estndares para correo electrnico PGP (o
derivados) y S/MIME son integrados cada vez con mayor frecuencia en las
aplicaciones de los usuarios finales.
En nuestra organizacin deberamos encriptar todo lo que sea posible. La razn
de esto es evidente si de lo que se trata es de enviar un mensaje privado por
Internet. Sin embargo, al interior de la organizacin la encriptacin puede ayudar
tambin. Naturalmente hay que sopesar los inconvenientes que trae la
encriptacin en trminos de incomodidad de uso, costo de licencias, ciclos de
CPU, etctera; con el hecho de que cierta informacin es definitivamente de
carcter pblico y por tanto no tiene sentido que est encriptada.
Adems de estas hay muchas ms recomendaciones de seguridad que
podemos mencionar, por ejemplo: no confiar en la autenticacin estndar, no
usar la configuracin "estndar", educar a los usuarios, ejecutar slo los
servicios imprescindibles, mantenerse al da con las actualizaciones y hacer
chequeos regulares, establecer planes de contingencia y sistemas de respaldo,
mantener contacto con el proveedor de lneas de comunicacin, no permitir
conexiones directas desde la red interna a Internet, hacer uso de una red
perimtrica o zona desmilitarizada, prcticas de programacin segura, vigilancia,
establecimiento de polticas, etc.
1.1.2.4 Escalabilidad
La escalabilidad es una de las caractersticas ms importantes para los
desarrolladores de un sistema distribuido. Se dice que un sistema es escalable
si logra conservar su efectividad cuando hay el nmero de recursos y el nmero
de usuarios incrementa significativamente. La escalabilidad de un sistema pude
medirse en tres aspectos diferentes:
Con respecto a su tamao: lo que significa que se pueden agregar ms usuarios
y ms recursos al sistema de una manera muy fcil.
Con respecto a su localizacin o rea de implementacin: lo que significa que
tanto los usuarios como los recursos pueden estar en locaciones remotas y
separadas el uno del otro.
13

Con respecto a su administracin: lo que significa que puede ser fcil de
administrar a pesar de que se utiliza en diferentes organizaciones
independientes que cuentan con diferentes polticas de seguridad y que hacen
un uso particular del sistema. Desafortunadamente, un sistema que es escalable
en uno o ms 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 ms alto es muy comn que
surja algn tipo de problema. Si consideramos la escalabilidad con respecto al
tamao de un sistema, nos encontramos con las limitaciones que presentan los
servicios, los datos y los algoritmos centralizados.
En muchos sistemas distribuidos es comn 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
nmero de usuarios crece, y a pesar de tener una capacidad de procesamiento y
almacenamiento virtualmente ilimitada, la comunicacin con este servidor puede
llegar a tener un lmite y eventualmente impedir el crecimiento del sistema.
Desafortunadamente el uso de un slo servidor puede ser inevitable, ya que por
lo general tenemos servicios que trabajan con informacin muy sensible y que
tiene que ser lo ms segura posible, por lo que el tener esta informacin
almacenada en diferentes servidores puede llegar a poner la informacin en
riesgo y hacer el sistema ms vulnerable.
De la misma manera, el almacenamiento centralizado de la informacin puede
ser un grave problema para un sistema distribuido, ya que a pesar de que un
slo servidor nos puede ofrecer la capacidad de almacenamiento que
necesitamos, es muy poco probable que dicho servidor permita el acceso
simultneo a miles o incluso millones de usuarios que desean consultar la
informacin 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 podra dar una respuesta a los millones de
usuarios de Internet que accedan este servicio simultneamente.
El uso de algoritmos centralizados es en teora la solucin ptima a un problema
de computacin distribuida, sin embargo, en la prctica 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 slo punto en el que se computan dichos datos pudiese sobrecargar
parte de la red con todos los mensajes que necesita enviar y recibir, adems de
que el computo de toda la informacin en una sola mquina tiene ms riesgo a
fallos y puede resultar ms tardada. La solucin a este problema es el uso de
algoritmos descentralizados, los cuales cuentan con ciertas caractersticas que
14

los diferencian de los algoritmos centralizados, entre las que podemos
mencionar:
Ninguna mquina tiene informacin completa del estado del sistema.
Cada mquina toma decisiones propias basndose solamente en informacin
local.
Problemas o fallos de una mquina 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 ejecucin de un algoritmo
descentralizado, este mismo procedimiento pudiese ser muy complicado o
incluso imposible si el algoritmo esta distribuido en una red ms amplia, por lo
que no se debe de depender en la existencia de un reloj global para hacer
posible la ejecucin de un algoritmo de este tipo.
Por otro lado tenemos los problemas de la escalabilidad con respecto a la
localizacin o rea de implementacin de un sistema distribuido. Una de las
principales razones por las cuales resulta difcil escalar los sistemas distribuidos
que existen actualmente, es que dichos sistemas fueron diseados para trabajar
redes de acceso locales (LANs) y que estn basados en una comunicacin
sncrona. En este tipo de comunicacin el cliente hace la solicitud de un servicio
y hace un bloqueo de la comunicacin hasta que recibe la respuesta. Este
acercamiento por lo general trabaja bien en LANs en las que la comunicacin
entre dos mquinas por lo general no toma ms de algunos cientos de
microsegundos. En el caso de las WANs, tenemos que tomar en cuenta que la
comunicacin 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 comunicacin en una WAN es poco
confiable y en la gran mayora 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 ms fcil el desarrollo
de sistemas distribuidos.
La escalabilidad con respecto a la localizacin o rea de implementacin 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 implementacin ser
imitada gracias a los problemas de desempeo y confiabilidad que trae consigo
la implementacin en un rea de redes extensa. Adems, los componentes
centralizados tambin provocan el desperdicio de recursos de red.
Finalmente, podemos mencionar los problemas que acarrea la escalabilidad de
la administracin de un sistema distribuido. Este problema se da cuando un
sistema distribuido de expande a otro dominio, que por lo general contar con
15

diferentes polticas de uso y pago de recursos, administracin 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, y restringir el acceso a los servicios y datos que no estn a
disponibilidad de los usuarios del mismo.
El nuevo dominio tiene que protegerse de ataques malignos provenientes del
sistema distribuido. Bsicamente, el nuevo dominio no sabe que tipo de
informacin puede esperar del cdigo enviado por el nuevo dominio por lo que
pudiera decidir limitar los permisos de acceso a dicho cdigo.
Tcnicas 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 tcnicas de escalabilidad: eliminar la
latencia de las comunicaciones, distribucin y replicacin.
Eliminar la latencia de las comunicaciones es til en el caso de querer lograr la
escalabilidad geogrfica de un sistema, la idea bsica es simple: tratar de evitar
la espera de respuestas a las peticiones que se hagan a servicios remotos lo
ms que se pueda. Esencialmente, esto significa que se tiene que construir la
aplicacin que realiza las peticiones de tal manera que use solamente mtodos
de comunicacin asncronos, es decir, que el cliente enva la peticin al servidor,
mientras espera la respuesta el cliente aprovecha ese tiempo para realizar
tareas locales ms importantes y cuando recibe la respuesta del servidor, el
proceso que se estaba realizando se interrumpe y se atiende la respuesta
recibida. Esta solucin parece fcil, sin embargo, hay muchas aplicaciones que
no pueden hacer un uso efectivo de la comunicacin asncrona, por ejemplo,
aplicaciones interactivas en las que el usuario no tiene nada mejor que hacer
ms que esperar la respuesta del servidor, por que esta se tiene que dar lo ms
rpido que sea posible. En dichos casos, es mucho mejor solucionar el problema
de la latencia reduciendo el trfico generado entre el cliente y el servidor cuando
se comunican entre s; esto lo podemos lograr moviendo parte de la
computacin 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 tcnica importante para lograr la escalabilidad es la distribucin, que
consiste en tomar un elemento, separarlo en partes pequeas y distribuir esas
partes en todo el sistema. Un ejemplo de un sistema distribuido que hace uso de
la distribucin es el servicio de nombre de dominio (DNS), el cual esta distribuido
en diferentes servidores que permiten el acceso a la misma informacin a todos
16

los usuarios, sin necesidad de tener un slo servidor que proporcione este
servicio.
En la mayora de los casos, los problemas de escalabilidad los vemos reflejados
en el rendimiento del sistema, por lo que generalmente la replicacin de los
componentes del sistema distribuido puede resultar ser una buena idea. La
replicacin aumenta la disponibilidad de los componentes del sistema y adems
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 algn componente ms cerca, tambin mejora el rendimiento del
sistema puesto que soluciona los problemas de latencia de las comunicaciones
que ya mencionamos anteriormente.
Una forma especial de replicacin es el Cacheo, el cual consiste en guardar una
copia de algn recurso (por lo general, de datos) de forma temporal en un lugar
cercano al cliente, para que ste lo pueda acceder ms fcilmente. En contraste
con la replicacin, el cachear un recurso es una decisin que es tomada por el
cliente, y no por los diseadotes 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
pginas Web estticas, por ejemplo, pudiese ser bastante tolerable, sin
embargo, en el caso de pginas dinmicas o de sistemas en tiempo real, la
replicacin puede traer consigo muchos problemas.
1.1.2.5 Tratamiento de Fallos
El fallo tanto del hardware como el software es algo prcticamente inevitable, y
por ms confiable que pueda parecer algn 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 difcil, pero que se
puede lograr si se utilizan las tcnicas adecuadas, segn el sistema que se
desee proteger. Algunas de las tcnicas ms comunes son:
Deteccin de Fallos: obviamente no es posible tratar un fallo si este no se ha
detectado, sin embargo, la deteccin de un fallo dentro de un sistema distribuido
puede no ser tan sencillo como parece, recordemos que adems de
17

componentes de hardware y software, los sistemas distribuidos operan gracias a
la transmisin de mensajes, y el funcionamiento del sistema depende en gran
parte de estas transmisiones de datos entre los diferentes componentes; un fallo
en la transmisin de datos entre componentes no es fcil detectar, pero es algo
que podemos esperar (dependiendo del medio por el que se haga la transmisin
y otras condiciones) y al saber que existe la posibilidad de ese fallo, podemos
monitorear y aplicar tcnicas que aseguren que dicha transmisin 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 reenvo del mensaje, y de esta manera el
usuario nunca notar que hubo un problema. Otro ejemplo lo dan las tcnicas de
redundancia que explicaremos ms adelante, pero que bsicamente 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 aplicacin 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 rpido 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 daino para el mismo
sistema, puesto que hay problemas que mientras son arreglados pueden afectar
el rendimiento de otros componentes del sistema que s estn trabajando.
Recuperacin 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 adems, 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 bitcora de las transacciones que se realizan y de acuerdo a esta
bitcora se decide reconstruir o retractar las transacciones hechas sobre la base
de datos antes de que se interrumpiera el funcionamiento de la misma.
18

Redundancia: un sistema distribuido puede lograr ser tolerante a fallos gracias a
la utilizacin de componentes redundantes dentro del sistema. La redundancia
se logra con la replicacin 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 comunicacin, etc. Es muy importante tomar en cuenta
que todos los componentes que estn replicados en el sistema deben
mantenerse actualizados para evitar problemas de consistencia, y adems, la
actualizacin de la informacin entre dichos componentes no debe de tener un
efecto significativo para las necesidades de transmisin de datos del sistema.
Las tcnicas antes mencionadas no son las nicas, pero si las ms utilizadas,
estas tcnicas 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, tambin 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 slo 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 ms simple de
lograr este objetivo es ejecutar cada transaccin sola, una despus de otra. Sin
embargo, esto puede afectar mucho el desempeo de un sistema distribuido
dado que el nivel de concurrencia se reduce al mnimo. El nivel de concurrencia,
es decir, el nmero de transacciones simultneas activas, es probablemente el
parmetro ms importante en sistemas distribuidos. Por lo tanto, los
mecanismos de control de concurrencia buscan encontrar un balance entre el
mantenimiento de la consistencia de los datos y el mantenimiento de un alto
nivel de concurrencia.
Si no se hace un adecuado control de concurrencia, se pueden presentar dos
anomalas. En primer lugar, se pueden perder actualizaciones provocando que
los efectos de algunas transacciones no se reflejen en los datos almacenados.
En segundo trmino, pueden presentarse recuperaciones de informacin
inconsistentes. Las tcnicas que se utilizan para asegurar un control de
concurrencia de un sistema distribuido, como hilos, semforos, candados, etc.,
se discutirn ms adelante, en la parte de anlisis de la arquitectura de clienteservidor.
19
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 estn distribuidos fsicamente en varias computadoras.
1.1.2.7.1 Tipos de Transparencia
Segn el Manual de Referencia ANSA y el Modelo de Referencia para el
Procesamiento Distribuido Abierto de la Organizacin Internacional de
Estndares (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 representacin de los
datos y la manera en que los recursos son accedidos.
Transparencia de Ubicacin: oculta la localizacin de los recursos y permite el
acceso a los mismos sin la necesidad de conocer su localizacin.
Transparencia de Migracin: oculta que un recurso o un cliente del sistema sea
reubicado, lo que permite hacer dichas reubicaciones sin afectar la operacin de
los usuarios y los servicios.
Transparencia de Recolocacin: oculta que un recurso o un cliente del sistema
pueda moverse a una ubicacin diferente mientras estn en uso.
Transparencia de Replicacin: oculta la existencia de mltiples 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 recuperacin 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 mquinas.
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 disear la
interfaz de llamadas al sistema de modo que no sea visible la existencia de
varios procesadores.
20

No es transparente un sistema donde el acceso a los archivos remotos se
realice mediante:
El establecimiento explcito de una conexin en la red con un servidor remoto.
El envo 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 disear un sistema que cuente con las
caractersticas necesarias para lograr la transparencia en tantos aspectos como
sea posible. Los dos ms importantes son la transparencia de acceso y la
transparencia de ubicacin, 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 ubicacin de los mismos, lo que al mismo tiempo
nos conduce a tener transparencia de ubicacin dentro del sistema.
Como no se sabe donde estn localizados los recursos, tampoco se debe de
saber si estos se mueven a una nueva ubicacin, se este o no utilizando el
sistema, esto es lo que se conoce como transparencia de Migracin y
Recolocacin respectivamente.
Ejemplos de transparencia de acceso, ubicacin y migracin 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 pgina, 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
conexin inalmbrica 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 recolocacin y permita que el cliente
siga conectado a pesar de cambiar su ubicacin fsica.
Por otro lado, la replicacin 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 replicacin distribuida organizado jerrquicamente que hace
posible el acceso simultneo a millones de usuarios que requieren de la
informacin que contiene esta base de datos, sin embargo, la transparencia de
la replicacin 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 ubicacin, puesto que de otra manera sera
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 simultneo a un mismo recurso; es entonces muy comn que varios
usuarios intenten hacer uso del mismo recurso al mismo tiempo y que traten de
21

competir por el uso de dicho recurso; en estos casos la transparencia de
concurrencia nos ayuda a ocultar al usuario que adems de l, hay otros usando
o intentando usar el mismo recurso. El reto ms interesante de esta parte del
diseo de un sistema distribuido es que tambin se tiene que considerar la
consistencia de los datos que se almacenarn en el sistema, por lo que habr
que tomar decisiones en cuanto a las tcnicas de candados y de uso de
semforos 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 ms desafiantes de esta tarea es saber distinguir entre recursos que estn
fallando y recursos que simplemente estn siendo accedidos por muchos
usuarios y cuya respuesta puede alentarse. Es importante tener un buen
esquema de replicacin y de balanceo de cargas para evitar estas situaciones,
pero al ser prcticamente inevitables es necesario considerar que hacer cuando
el sistema esta en una situacin 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 caracterstica generalmente deseable
para cualquier sistema distribuido, hay situaciones en las que el pretender
enmascarar todos los aspectos relacionados con la distribucin de los
componentes del sistema puede no ser lo ms ptimo; en algunas ocasiones es
mejor hacer del conocimiento del usuario que el sistema esta compuesto por
varios elementos y que por ms ptima que sea la transmisin de mensajes o la
distribucin y replicacin de componentes, habr cierto tiempo de respuesta
mnimo entre cada transaccin que es imposible evitar.
Hay tambin una relacin 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
replicacin en un sistema, es necesario que el usuario sepa que para garanti zar
la consistencia de la informacin 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 operacin se lleva a
cabo.
Es muy importante considerar la transparencia como uno de los principales
objetivos del diseo e implementacin de un sistema distribuido, sin embargo, es
importante tener en consideracin otros factores que pueden ser afectados por
la transparencia, principalmente el desempeo general del sistema.
22
1.2. Ventajas y Factores de Distribucin

En general, los sistemas distribuidos exhiben algunas ventajas sobre los
sistemas centralizados que se describen enseguida.
1.2.1 Factores Estratgicos
Hoy en da, los clientes, proveedores y compaas se encuentran generalmente
en diferentes localidades alejados los unos de los otros. Debido a que todos
estos utilizan computadoras, las redes de informacin que los unen y que les
permiten interactuar pueden ofrecer a las empresas mayor competitividad.
1.2.2 Costos de Equipo
El cociente precio/desempeo de la suma del poder de los procesadores
separados, contra el poder de uno solo centralizado, es mejor cuando estn
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 nmero 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 mayora de los usuarios de los servicios computacionales son cada vez
ms cultos y competentes por lo que dichos usua rios desean operar sus propios
sistemas, a su manera, por lo que no estn contentos con los sistemas
centralizados que llevan el control sobre los sistemas que son desarrollados,
cundo, cmo y por quines son operados. La computacin distribuida ofrece a
los usuarios estar ms 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 mdulos
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 mquinas, lo que trae como consecuencia la reduccin del
costo y tiempo de desarrollo de una nueva aplicacin.
1.2.5 Interfaces de Usuarios
La mayora de las estaciones de trabajo que se utilizan hoy en da soportan el
uso de interfaces grficas sofisticadas con dispositivos de sealamiento y
sistemas de audio y video; esta tecnologa resulta ser muy atractiva
especialmente para usuarios con diferentes estilos de aprendizaje que por lo
23

general se decepcionan por los tradicionales repotes o interfaces presentadas
en formato de texto o con grficos de poca calidad.
1.2.6 Flexibilidad y Facilidad de Configuracin
Los sistemas distribuidos, y en general la computacin descentralizada, ofrece
muchas opciones para mejorar el desempeo y la fiabilidad de un sistema
mediante el uso de procesos y datos redundantes.
1.2.7 Explotacin del Hardware
Las estaciones de trabajo y computadoras personales permiten el desarrollo de
software especializado que hace uso de las caractersticas especficas del
hardware de la estacin 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 configuracin se le conoce comnmente como
configuracin cliente-servidor y se explicar a detalle ms 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 ms
se requiera.
1.2.9 Crecimiento
El poder total del sistema puede irse incrementando al aadir pequeos
sistemas, lo cual es mucho ms difcil en un sistema centralizado y caro.
Por otro lado, los sistemas distribuidos tambin exhiben algunas ventajas sobre
sistemas aislados. Estas ventajas son:
Compartir datos: un sistema distribuido permite compartir datos ms fcilmente
que los sistemas aislados, que tendran 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 sinergtico.
Comunicaciones: la comunicacin persona a persona es factible en los sistemas
distribuidos, en los sistemas aislados no.
24

Flexibilidad: La distribucin de las cargas de trabajo es factible en el sistema
distribuido, se puede incrementar el poder de cmputo.
1.3. Desventajas y Factores a Considerar

As como los sistemas distribuidos exhiben grandes ventajas, tambin se
pueden identificar algunas desventajas, algunas de ellas tan serias que han
frenado la produccin comercial de sistemas distribuidos en la actualidad.
1.3.1 Falta de Estndares
La falta de estndares 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 aplicacin. El desarrollo y us o de
estndares 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 comn ver este tipo de problemas en un sistema distribuido.
1.3.2 Complejidad del Diseo
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 solucin
generan mucha sobrecarga al sistema hacindolo ineficiente. El verificar, por
ejemplo, quines tienen acceso a algunos recursos y quines no, el aplicar los
mecanismos de proteccin 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 Administracin
Hasta ahora muchos de los problemas de administracin 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 planeacin de sistemas de informacin de acuerdo a la
cambiante tecnologa que hay hoy en da, el manejo de recursos distribuidos y el
diseo de la estructura organizacional para la computacin distribuida.
1.3.4 Seguridad e Integridad
La distribucin de datos y de programas en mltiples localidades pueden crear
muchos problemas de seguridad e integridad que no con fciles de solucionar y
que por lo general requieren tambin 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.
25
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 estn disponibles antes
de llegar a tomar una decisin cobre cual es la mejor. Por el lado contrario, el
tener muchas opciones nos permite disear un sistema que este conformado por
los elementos que mejor satisfagan las necesidades de los usuarios.
1.4. Evolucin
1.4.1 Etapas de la evolucin de los sistemas distribuidos
La computacin distribuida ha evolucionado en los ltimos veinte aos y
continuar evolucionando por muchos aos ms. Durante esta evolucin, hemos
acumulado muchos trminos tal como procesamiento distribuido, procesamiento
distribuido cooperativo, procesamiento distribuido de datos, computacin clienteservidor, computacin en red y computacin en sper-red. Brevemente veremos
la evolucin y trataremos de poner en perspectiva algunos de stos trminos.
Durante los 70s, la computacin distribuida estaba caracterizada por
mainframes y mini computadoras interconectadas a travs 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 informacin a travs de
emulacin 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 travs de emulacin de terminal. En
algunos casos, los archivos eran transferidos entre mainframes y mini
computadoras a travs de paquetes de transferencia de archivos. Muchos
paquetes de transferencia de archivos y emulacin de terminal fueron
desarrollados en este periodo. Aunque se realiz mucha investigacin en bases
de datos distribuidas en este periodo, esta tecnologa no fue utilizada ni
comercializada. Dos trminos se volvieron populares en esta poca: (1)
procesamiento distribuido que se refiere a procesos de aplicaciones en mltiples
computadoras y (2) procesamiento distribuido de datos que se refiere a datos
como a procesos en diferentes computadoras. Independientemente de los
trminos utilizados, las tecnologas de intercambio de informacin fueron
transferencia de archivos y emulacin de terminales.
Durante los 80s sucedieron tres cambios fundamentales: proliferacin de
computadoras de escritorio (desktop computers), disponibilidad de redes de
rea local (LANs) y el uso comn 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 computacin distribuida consistan
de mainframes, mini computadoras y computadoras de escritorio,
26

interconectadas a travs de LANs y WANs. Adems de procesamiento
distribuido y procesamiento distribuido de datos, el trmino computacin en red
se volvi popular para describir a las redes como un valor agregado a las
computadoras. Aunque alguna paquetera de bases de datos distribuidas y
cliente -servidor salieron al mercado, lo ms utilizado segua siendo transferencia
de archivos y emulacin de terminal.
Durante los 90s 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, proliferacin de poderosas y baratas computadoras de escritorio y
computadoras porttiles, nfasis en estndares y disponibilidad de redes de
transferencia de datos sumamente rpidas (100 Mbps y ms para LANs, WANs
y redes de rea metropolitana MANs). Los sistemas de computacin distribuida
de esta poca consistan en muchas computadoras de diferentes capacidades y
de diferentes fabricantes conectadas a travs de reas geogrficas grandes
sobre redes de alta transferencia de datos de difere ntes proveedores. Adems
de los trminos utilizados anteriormente, el trmino procesamiento cooperativo
distribuido entra en boga porque seala la caracterstica principal de stos
sistemas que permiten el intercambio de informacin interactivamente entre los
procesos de diferentes computadoras. La computacin Cliente -Servidor (C-S) es
la forma ms 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
travs de una red. La computacin C-S representa un gran avance con respecto
a los sistemas distribuidos basados en la emulacin de terminal y transferencia
de archivos.
En la actualidad, los Sistemas de Computacin Distribuida hacen que toda la red
computacional parezca como una sola gran computadora donde diferentes
actividades se llevarn a cabo en diferentes computadoras. Estos sistemas
tambin incluyen supercomputadoras conectadas a travs de redes Gigabit por
segundo, y supervisados por software de administracin (Sistemas Operativos
Distribuidos). Dichos sistemas, llamados sper computacin en red, son
ampliamente utilizados debido a su gran potencial.
Por otro lado, el desarrollo en computacin neuronal es de gran inters porque
intenta simular los procesos de pensamiento del cerebro humano. Bsicamente,
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 estn interconectadas entre
s a travs 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
27

neuronas estn interconectadas de muchas maneras. Sin embargo, una neurona
aislada es lenta. Computadoras muy rpidas conectadas a travs de redes
sumamente rpidas crean grandes oportunidades para el desarrollo de nuevas
aplicaciones en inteligencia artificial, medicina, ingeniera, finanzas, etctera.
1.4.2 Impacto de la orientacin a objetos y componentes
Para entender el proceso que llev al nacimiento del concepto que hoy se
conoce como orientacin a objetos habra que volver unas cuantas dcadas
atrs, hasta la poca en la que reinaban FORTRAN y BASIC.
La programacin de ese tiempo o de ese entonces estaba dedicada a procesos
lineales (poca de la programacin lineal), en los cuales las tareas se
ejecutaban una a una en una secuencia preestablecida. Pero ese enfoque
funcion sin problemas durante los primeros aos, hasta que los requerimientos
comenzaron a crecer en tamao y complejidad, por lo tanto cada vez se volva
ms difcil agregar adaptaciones y ampliaciones a los programas ya existentes.
La programacin estructurada atac este problema descomponiendo los
procesos complejos en otros ms sencillos (es una actividad conocida como
descomposicin modular), y as permiti la reutilizacin de las partes comunes a
toda una aplicacin a travs de procedimientos y funciones. Para completar la
descomposicin modular se usaba la metodologa hacia abajo (topdown),
yendo de lo general a lo particular. Se buscaba, primero, entender cul era la
funcin principal que se necesitaba representar y se la iba subdividiendo en
tareas menos complejas. Se intentaba que cada mdulo fuera lo ms
independiente posible del resto para, a futuro, poder restringir el impacto de los
cambios en reas especficas de la aplicacin.
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 programacin. La
orientacin a objetos propuls el encapsulamiento de comportamientos y datos
en un solo conjunto, apartndose del esquema tradicional, en el cual se
consideraba de manera aislada la informacin que se quera manipular de la
lgica para conseguirla. Las ventajas que prometa esa nueva perspectiva eran
facilitar la colaboracin 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
difundindose cada vez ms. Hoy en da, de ninguna manera podemos ignorarlo
como programadores. No creo que alguien considere la creacin de un nuevo
lenguaje sin incorporar orientacin a objetos en su estructura. As, los lenguajes
estructurados (o basados en procedimientos) siguen siendo el primer contacto
formal con la programacin.
28

La idea fundamental detrs de cua lquier lenguaje de programacin orientado a
objetos es combinar en un mismo elemento informacin y funciones que puedan
actuar sobre ella; comportamiento y propiedades fusionados en una sola
entidad. La informacin contenida en un objeto est representada por sus
atributos. Cuando se define un atributo o un mtodo como privado, solamente el
objeto en cuestin puede accederlo; lo contrario ocurre con aquellos atributos o
mtodos definidos como pblicos, que pueden ser accedidos por cualquier otro
objeto. El conjunto de atributos y mtodos pblicos 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 implementacin 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 adems, que la nica manera de acceder a la informacin
contenida en un objeto es a travs de sus mtodos. A pesar de que es posible
definir atributos pblicos, esto no se considera un buen diseo 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
informacin de otros slo si existen mtodos pblicos para ese fin (getters y
setters). As, la informacin se mantiene protegida de alteraciones accidentales
o no deseadas.
Esto tiene una importancia tremenda. Imaginemos que por error hubiramos
implementado el atributo dimetro como pblico. Cualquier otro objeto podra
modificar destrozando la abstraccin del mundo real que tratamos de
representar. Disear un sistema orientado a objetos tambin 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 especificacin
(como el plano de una casa) y una plantilla o molde para la creacin de objetos.
Es la definicin conceptual de un objeto y, como tal, describe todas las
caractersticas de un tipo particular de objetos, sus atributos, mtodos y los
correspondientes privilegios de acceso.
Cuando escribimos un programa, definimos clases, una por cada tipo de objeto,
para que puedan utilizarse en la creacin o en la instanciacin de nuevos
objetos en memoria durante la ejecucin de la aplicacin. "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
29

sistema, y podemos pensar en las clases como tipos de datos, al igual que int o
char, pero con una responsabilidad especfica en el sistema.
As, una clase Vlvula define el comportamiento de todas las instancias (de
todas las vlvulas) que tengamos en nuestro sistema. A pesar de representar
entidades distintas (cada una con su propio estado), todas se comportarn
exactamente igual o del mismo modo. Si durante nuestro proceso de diseo
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 situacin dentro de la orientacin a objetos creando una nueva
clase derivada de la existente, que retiene o "hereda" los mtodos 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 petrleo, la
vlvula), supongamos que una vez que tenemos nuestro sistema funcionando,
los ingenieros deciden incorporar otro tipo de vlvula, una que proporcione un
mayor grado de apertura (o en todo caso que es ms sofisticada que las
dems), junto con un nuevo mtodo para abrir la vlvula en la posicin deseada
y otros mtodos privados que permiten conectarla a sensores de posicin para
saber cul es su estado.
A travs de la herencia, los cambios que hagamos a nuestro modelo se
propagarn de padres a hijos y as atravesarn todos los niveles que definamos.
Podemos construir jerarquas de clases para transmitir estos cambios
automticamente.
Polimorfismo:
Significa, literalmente, muchas formas. Es una caracterstica de la orientacin 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 podramos incluir la inicializacin 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 especficas
asociadas con esa operacin difieren de un objeto a otro.
30

La forma ms comn de implementar este tipo de polimorfismo es a travs de
una clase con un mtodo abstracto (solamente su definicin, no tiene
implementacin) que es heredado a varias subclases. Cada una de ellas
redefine este mtodo 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 redefinicin del
mtodo en las subclases sea totalmente inconsistente con las intenciones
originales de ese mtodo en la superclase.
Tambin podemos tener polimorfismo por overriding de un mtodo. Para eso
definimos conjuntos diferentes de argumentos bajo el nombre de un nico
mtodo. La accin especfica a seguir en cada caso estar determinada por la
naturaleza de los parmetros que reciba ese mtodo.
Una buena jerarqua de clases ser la base la reutilizacin del cdigo en el que
hayamos invertido tiempo y esfuerzo para desarrollar y probar. Con el
encapsulamiento podremos modificar las implementaciones de los mtodos sin
alterar el cdigo existente que depende de la interfaz de nuestras clases.
Integrando en un todo las dos anteriores, el polimorfismo nos permitir crear el
cdigo para que se pueda mantener, sencillo de interpretar y flexible.
La OOP (Programacin Orientada a Objetos) no es slo clases:
Si vamos a ser estrictos, las clases no son una parte esencial de la OOP (sigla
en ingls). Pero dada la influencia de C++ y Java, la mayora de las personas
piensa que usar clases es la nica manera de escribir un programa con
orientacin a objetos. En realidad existen dos formas de abordar a la orientacin
a objetos en un lenguaje: mediante clases (como en todos los lenguajes
comerciales, tales como C++, C#, Java y otros) y a travs de prototipos (como
en Self, Kevo, Omega, todos lenguajes de uso acadmico).
En los primeros, las clases se utilizan como "fbricas" de objetos. En los ltimos
no se necesita la nocin de clase; los objetos pueden crearse de la nada en
forma visual o por herencia (a partir de otro objeto), y el cdigo resultante es
mucho ms claro.
1.4.3 Internet y nueva tecnologa en la red
Internet surge como consecuencia del establecimiento de estndares de
sistemas abiertos. Estos esquemas permitieron la creacin una red de redes. De
hecho, Internet proviene del ingls inter-networking.
Particularmente el protocolo TCP/IP fue uno de los estndares que favoreci la
conexin a travs de Internet y las aplicaciones que podan trabajar sobre este
protocolo.
31
Conceptualmente, generalmente se confunde la programacin para Internet y la

programacin Web; ste ltimo es un subconjunto del primero. La programacin
Web utiliza el protocolo HTTP (Hyper Text Transfer Protocol).
Tradicionalmente la utilizacin de aplicaciones Web se efecta 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 travs de servicios.
Tarea Individual
Entregar la sntesis del tema de introduccin en documento Word, con el nombre
INTRODUCCION.DOC
Tarea en Equipo
Entregar la sntesis en equipo sobre las caractersticas de sistemas distribuidos,
como CARACTERISTICAS.DOC.
32
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 continuacin se plantean:
1.
Qu entiende por Arquitectura Cliente Servidor?
2.
Cules son los elementos de una Arquitectura Cliente Servidor?
3.
Qu caractersticas muestra el modelo Cliente Servidor?
4.
Cules 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 adems es conveniente que

consulte otra fuente de informacin 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 terico y de fundamentos requeridos en el inicio del
curso, ms adelante esto nos servir como base en aplicaciones prcticas.
Material de Apoyo 2.1

2.1.1 Definiciones Bsicas
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 informacin, que se sustenta en la
idea de repartir el tratamiento de la informacin y los datos por todo el sistema
informtico, permitiendo mejorar el rendimiento del sistema global de
informacin
33
2. En trminos de arquitectura:
Los distintos aspectos que caracterizan a una aplicacin (proceso,
almacenamiento, control y operaciones de entrada y salida de datos) en el
sentido ms amplio, estn situados en ms de un computador, los cuales se
encuentran interconectados mediante una red de comunicaciones.
3. IBM define al modelo Cliente/Servidor
Es la tecnologa que proporciona al usuario final el acceso transparente a las
aplicaciones, datos, servicios de cmputo o cualquier otro recurso del grupo de
trabajo y/o, a travs de la organizacin, en mltiples 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 mltiples requerimientos de trabajo a travs de redes LAN
o WAN. La ubicacin de los datos o de las aplicaciones es totalmente
transparente para el cliente.
Un Servidor es cualquier recurso de cmputo dedicado a responder a los
requerimientos del cliente. Los servidores pueden estar conectados a los
clientes a travs de redes LANs o WANs, para proveer de mltiples servicios a
los clientes tales como impresin, acceso a bases de datos, fax, procesamiento
de imgenes, etc. Es importante mencionar que un servidor no es
necesariamente un dispositivo fsico (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 ms a fondo las
caractersticas 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 estndares, convenciones, reglas y procesos, permite
integrar una amplia gama de productos y servicios informticos, de manera que
pueden ser utilizados eficazmente dentro de la organizacin.
34

Debemos sealar que para seleccionar el modelo de una arquitectura, hay que
partir del contexto tecnolgico y organizativo del momento y, que la arquitectura
Cliente/Servidor requiere una determinada especializacin de cada uno de los
diferente s componentes que la integran.
En esta aproximacin, 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
aplicacin de un sistema de informacin est caracterizada por tres
componentes bsicos:
Presentacin/Captacin de Informacin
Procesos
Almacenamiento de la Informacin
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 Estacin 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
informacin y en el que se realiza una parte mayoritaria de los procesos.
Se trata de un fenmeno en el sector informtico. Aquellos responsables
informticos que se oponen a la utilizacin de los terminales no programables,
acaban siendo marginados por la presin 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 ubicacin de los puestos de trabajo, dadas
las ventajas de la red.
Los Servidores o Back-End. Una mquina que suministra una serie de
servicios como Bases de Datos, Archivos, Comunicaciones,...). Los Servidores,
segn la especializacin y los requerimientos de los servicios que debe
suministrar pueden ser:
o Mainframes
o Minicomputadoras
o Especializados (dispositivos de red, imagen, etc.)
35
Una caracterstica a considerar es que los diferentes servicios, segn 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 conexin fsica y la
transferencia de datos entre los distintos equipos de la red.
Infraestructura de comunicaciones
Componentes Hardware y Software que permiten la comunicacin y su gestin,
entre los clientes y los servidores.
La arquitectura Cliente/Servidor es el resultado de la integracin de dos culturas.
Por un lado, la del Mainframe que aporta capacidad de almacenamiento,
integridad y acceso a la informacin y, por el otro, la del computador que aporta
facilidad de uso (cultura de PC), bajo costo, presentacin atractiva (aspecto
ldico) y una amplia oferta en productos y aplicaciones.
2.1.3 Caractersticas del modelo Cliente/Servidor
En el modelo Cliente/Servidor podemos encontrar las siguientes caractersticas:
1. El Cliente y el Servidor pueden actuar como una sola entidad y tambin
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 mltiples 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
actualizacin o por reemplazo tecnolgico, se realizan de una manera
transparente para el usuario final.
5. La interrelacin entre el hardware y el software estn 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 mltiples funciones al mismo
tiempo que presenta una imagen de un slo sistema a las estaciones Clientes.
Esto se logra combinando los recursos de cmputo que se encuentran
fsicamente separados en un sistema lgico, proporcionando de esta manera el
servicio ms efectivo para el usuario final.
36
Tambin es importante hacer notar que las funciones Cliente/Servidor pueden

ser dinmicas. 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 organizacin, dentro de
una arquitectura informtica descentralizada y heterognea.
6. Adems se constituye como el nexo de unin ms adecuado para reconciliar
los sistemas de informacin basados en mainframes o minicomputadoras, con
aquellos otros sustentados en entornos informticos pequeos y estaciones de
trabajo.
7. Designa un modelo de construccin de sistemas informticos de carcter
distribuido.
8. Su representacin tpica 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 informacin de la organizacin, al
tiempo que puede acceder a los recursos de este host central y otros sistemas
de la organizacin 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 informacin.
En conclusin, Cliente/Servidor puede incluir mltiples 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 implantacin involucra diferentes tipos de estndares:
APPC, TCP/IP, OSI, NFS, DRDA corriendo sobre DOS, OS/2, Windows o PC
UNIX, en Token-Ring, Ethernet, FDDI o medio coaxial, slo por mencionar
algunas de las posibilidades. Dependiendo de estas caractersticas y de su
combinacin, es el grado de complejidad de una solucin 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 ms ha promovido el uso de sistemas
Cliente/S ervidor, es la existencia de plataformas de hardware cada vez ms
baratas. Esta constituye a su vez una de las ms palpables ventajas de este
esquema, la posibilidad de utilizar mquinas considerablemente ms baratas
que las requeridas por una solucin centralizada, basada en sistemas grandes.
Adems, se pueden utilizar componentes, tanto de hardware como de software,
de varios fabricantes, lo cual contribuye considerablemente a la reduccin de
costos y favorece la flexibilidad en la implantacin y actualizacin de soluciones.
37
b) El esquema Cliente/Servidor facilita la integracin entre sistemas diferentes y

comparte informacin permitiendo, por ejemplo que las mquinas ya existentes
puedan ser utilizadas pero con interfaces ms 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 grficas interactivas, los sistemas construidos
bajo este esquema tienen mayor interaccin ms intuitiva con el usuario. El uso
de interfaces grficas para el usuario, el esquema Cliente/Servidor presenta la
ventaja, con respecto a uno centralizado, de que no es siempre necesario
transmitir informacin grfica 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 ms
rpido el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear
las herramientas existentes (por ejemplo los servidores de SQL o las
herramientas de ms bajo nivel como los sockets o el RPC).
e) La estructura inherentemente modular facilita adems la integracin de
nuevas tecnologas y el crecimiento de la infraestructura computacional,
favoreciendo as la escalabilidad de las soluciones.
f) El esquema Cliente/Servidor contribuye adems, a proporcionar, a los
diferentes departamentos de una organizacin, soluciones locales, pero
permitiendo la integracin de la informacin re levante a nivel global.
El esquema Cliente/Servidor tiene algunos inconvenientes que se mencionan a
continuacin:
a) Tiene escasas herramientas para la administracin y ajuste del desempeo
de los sistemas.
b) En el desarrollo de aplicaciones Cliente/Servidor se deben considerar los
aspectos, que se mencionan a continuacin:
Los clientes y los servidores debern utilizar el mismo mecanismo (por

ejemplo sockets o RPC), lo cual implica que se deben tener
mecanismos generales que existan en diferentes plataformas.
Adems, 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. Tambin se puede recurrir
a otras tcnicas como el encripcin.
El desempeo. Problemas de este estilo pueden presentarse por
congestin en la red, dificultad de trfico de datos, etc.
38
Un aspecto directamente relacionado con lo anterior es el de cmo

distribuir los datos en la red. En el caso de una organizacin, por
ejemplo, ste puede ser hecho por departamentos, geogrficamente, 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 simultneas.
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 Impresin:
Servicios que permiten compartir archivos, bases de datos, impresoras y
graficadores (plotters). Administracin de las colas de impresin en diferentes
dispositivos.
b) Servicios de Comunicaciones:
Aseguran que cada componente fsico 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 heterogneos.
c) Servicio de Administracin:
Administracin de Sistemas involucra administracin de cambios, de problemas,
operaciones, configuracin y rendimiento.
Administracin de Cambios: es definida como las actividades involucradas en la
planeacin, programacin, distribucin, instalacin y registro de hardware y
software en una red distribuida.
Administracin de Problemas: involucra la determinacin de los mismos, la
identificacin de su origen en una red y su solucin.
Administracin de Operaciones: es definida como la administracin del uso de
los sistemas y de los recursos para soportar la carga de trabajo de la
organizacin, la cual incluye operaciones automatizadas y remotas.
Administracin de Configuracin: es el manejo de las relaciones lgicas y fsicas
entre los recursos de la red.
39

Administracin del Rendimiento: es un conjunto de actividades tales como la
recopilacin de datos de desempeo, afinamiento, distribucin de carga de
trabajo y el planeamiento de la capacidad para las redes distribuidas.
Administracin de Sistemas: tambin incluye servicios de respaldo, recuperacin
de datos, seguridad de recursos de cmputo y distribucin y mantenimiento de
software.
d) Servicios de Aplicacin:
Si el recurso compartido es una parte de una aplicacin (una funcin de la
aplicacin), estamos hablando de servicios de aplicacin. Cada uno de los
procesadores participantes en un ambiente Cliente/Servidor puede mantener
parte del cdigo de la aplicacin, el cual debe ser compartido por todos ellos
(interoperabilidad). Esto significa que las partes de una aplicacin pueden ser
distribuidas en varios procesadores, locales o remotos.
El diseo de las funciones de la aplicacin no debe estar ligado a un
computador, lo que permite transportar la aplicacin de un procesador a otro, sin
modificaciones (portabilidad).
Una ventaja derivada de esto, es que la aplicacin puede estar ptimamente
ubicada dentro de una red en base a las necesidades: de recursos de cmputo y
de la organizacin.
Tarea Individual 2.1
Entregar el cuestionario de Fundamentos de Arquitectura C/S en documento
Word, con el nombre FUNDAMENTOSCS.DOC
2.2. Comunicacin entre Procesos

Objetivos 2.2
Objetivos Comunicacin entre Procesos
Con la finalidad de enfatizar los conceptos ms representativos del entorno de
comunicacin entre procesos se realizarn dos ejercicios prcticos 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 mayora de los servicios Web y las aplicaciones de acceso remoto actuales
utilizan un enfoque de llamadas a procedimientos remotos (RPC, Remote
40

Procedure Call). Se crea lo que parece ser una llamada de funcin 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 Comunicacin 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 comunicacin entre
procesos.
EJERCICIO SOCKETS TCP

En aplicaciones Cliente Servidor, el servidor proporciona algn servicio, como
procesamiento de consultas en base de datos o envo 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 comunicacin
que ocurre entre el cliente y el servidor debe ser confiable. Es decir, ningn 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 conexin, 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 informacin a transmitir es importante, no se puede perder ningn
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 comunicacin, 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
41

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 prctico 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 conexin de los clientes. Su mtodo accept
toma una peticin de conexin de la cola, o si la cola est vaca, se bloquea
hasta que lle ga una peticin. El resultado de ejecutar accept es una instancia de
Socket, a travs 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 adems se conecta con el servicio. Esta clase proporciona
los mtodos 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 ms 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:
42

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 conexin 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 aplicacin cliente/servidor
de eco, es decir, el servidor repite lo mismo que le enva el cliente, hasta que el
cliente quiere finalizar el servicio, para lo cual enva la palabra "Bye" al servidor.
CDIGO DEL CLIENTE
Analizar el siguiente cdigo 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 mquina 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()));
43
// 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 conexin");
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 reenva 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);
// Enva a la salida estndar la respuesta del servidor
linea = entrada.readLine();
System.out.println("Respuesta servidor: " + linea);
// Si es "Bye" es que finaliza la comunicacin
if (linea.equals("Bye")) break;
}
System.out.println("IOException: " + e.getMessage());
}
// Libera recursos
salida.close();
entrada.close();
stdIn.close();
socketCliente.close();
}
}
CDIGO DEL SERVIDOR
44

Analizar el siguiente cdigo 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);
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 peticin de un cliente
// abriendo un socket para el cliente
socketCliente = socketServidor.accept();
System.out.println("Connexin 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;
}
45

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 comunicacin 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 comunicacin de ms alto nivel.
Los RPC permiten llamar a una funcin que est en otro programa y
generalmente en otra mquina, para lo cual el paso de parmetros a la funcin
remota se efecta a travs de algn protocolo de representacin de datos (XDR,
eXternal Data Representation).
Mientras que a nivel de la capa de transporte el concepto de puerto existe para
poder enviar informacin entre procesos, los RPC definen un concepto llamado
nmero de programa. Este, junto con el uso de la versin del programa permite
que los servidores y clientes puedan comunicarse.
Programacin con RPCs
Dentro de las funciones para programar con RPC existen tres niveles:
Nivel alto: En la prctica se usa slo para aplicaciones muy especficas

con poca utilidad.
Nivel Bajo: Es en donde se pueden mezclar programacin 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 implementacin bajo Sockets. En
este nivel representaremos nuestro ejercicio prctico.
En este ejercicio prctico trataremos el uso de RPC de Sun.

ESCENARIO
46

En este ejercicio veremos como se implementa un servidor y un cliente para
obtener la hora de una mquina, con RPCs.
Analizar los programas.
PROGRAMA SERVIDOR
El programa servidor (listado 1) llama a la funcin registerrpc, sus primeros tres
parmetros son: el nmero de programa a registrar, el nmero de versin de
programa y el nmero de procedimiento a registrar.
Listado 1:
/*
Ejemplo del uso de los RPC de Sun
Este programa permite obtener la hora de una mquina
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, versin 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;
}
47
El cuarto parmetro es el nombre de una funcin de "C" (esto es, la direccin de

la fun-cin), de tal forma que cuando el cliente llame a este programa, versin y
nmero de procedi-miento, el mecanismo de RPCs llamar a la funcin
"servidor_hora" con un parmetro de llamada de tipo "xdr_void" (en este caso
ningn parmetro), y con un valor de regreso de tipo xdrcadena_32.
Despus, el programa servidor llama a la funcin "svc_run", la cual a su vez se
queda en un ciclo infinito en espera de RPCs; esta funcin al recibir la peticin
del procedimien-to "PlDEHORA_NUM" llamar a la funcin "servidor_hora" la
que simplemente regresa la direccin 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 funcin "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 mquina
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 mquina 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){
48
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 funcin "callRPC" recibe ocho parmetros. Estos son:
1) El nombre de la mquina hacia donde se enva el RPC.
2) El nmero de programa que se quiere llamar.
3) La versin del programa.
4) El nmero de procedimiento que se quiere llamar.
5) xdr del tipo de argumento de llamada.
6) La direccin del argumento de llamada
7) xdr del argumento de regreso.
8) La direccin del argumento de regreso.
La funcin "callrpc" trabaja bajo el proto-colo de UDP, para un manejo de
retransmisin.
Si despus de cierto tiempo no llega una contestacin "callRPC" simplemente
reintenta, despus de cierto nmero de reintentos "callRPC" regresa un error de
'timeout', pero si la contestacin llega y no hubo error "callRPC' regresa un 0.
En el archivo def_RPC.h (listado 3), estn definidos los nmeros de programa,
versin y procedimiento, adems de la funcin xdr_cadena_32.
Listado 3
/*
Definiciones para rpcs del ejemplo de hora
Sirven tanto para el cliente como el servidor
*/
#define HORA_PROG 555555555 /* Nmero del programa */
#define HORA_VERS
/* versin */
#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;
49

struct tm *s_tiempo;
char *cad_hora;
}
XDRs
El archivo xdrhora.c (listado 4) tiene la de-finicin de la funcin xdr_cadena_32,
que per-mite manejar cadenas de hasta 32 caracteres con los RPCs.
Los xdrs constituyen simultneamente un protocolo de presentacin de datos y
una implementacin 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) &&
50

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 estn en
representacin interna de una mquina y se convierten al formato de
representacin externa lo que permite intercambiar in-formacin entre mquinas
con representaciones de datos distintas; deserializar es el proceso inverso.
2.2. Comunicacin entre Procesos

2.2.1 Generalidades de IPC
El rendimiento de un sistema de computacin distribuida depende en gran
medida de la comunicacin rpida entre procesos. Esta ltima depende de dos
partes: las primitivas de comunicacin entre procesos y el protocolo de
transporte sobre el cual trabajan esas primitivas.
La comunicacin 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 comunicacin entre
procesos remotos. Los tres ms comunes estn basados e n:
Paso de mensajes
Llamado a procedimientos remotos
Transacciones
El orden en la lista anterior indica que cada forma de comunicacin puede ser
construida en base a la anterior. En otras palabras, a mayor nmero, mayor nivel
de abstraccin.
Paso de mensajes
51

Un mensaje es una coleccin 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 comunicacin orientada a mensajes est ntimamente ligada al modelo
cliente -servidor. El proceso cliente enva un mensaje (peticin) a un proceso
servidor y espera una respuesta o contina ejecutndose.
Las primitivas de comunicacin 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 semnticas de las primitivas:
1. Direccionamiento
Para que un cliente pueda enviar un mensaje a un servidor, debe conocer
la direccin de ste.
Existen varios mtodos por los que un cliente puede conocer o determinar la
direccin del servidor, a continuacin se mencionan tres de ellas:
Asignacin numrica fija predeterminada.- en este caso la direccin 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 podra funcionar en un sistema particularmente sencillo, es necesaria
una forma ms sofisticada de direccionamiento. Aqu cabe sealar que no se ha
determinado que es lo que significa el nmero asignado, es decir, no especifica
si es la identificacin de un proceso o de un equipo.
Asignacin aleatoria de nmero de proceso.- este mtodo consiste en dejar

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

grande y disperso, como el espacio de enteros de 64 bits. La probabilidad de
que dos procesos elijan el mismo nmero es muy pequea. Este mtodo puede
utilizarse en sistemas grandes. Sin embargo existe el problema de saber a que
mquina enviar el mensaje?. Para ello el emisor podra enviar un paquete
especial de localizacin con la direccin del proceso destino. Puesto que es un
paquete de transmisin, ser recibido por todas las mquinas de la red. Todos
los ncleos verifican si la direccin es la suya y, en caso de que lo sea, regresa
el mensaje de aqu estoy con su direccin en la red (nmero de mquina).
Servidor de nombres.- aunque el esquema anterior es transparente, la

transmisin provoca carga adicional en el sistema. Esta carga se puede evitar
mediante una mquina adicional para la asociacin a alto nivel (es decir en
ASCII) de los nombres de servicios con las direcciones de las mquinas. 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 nmeros en binario de las mquinas o procesos. Cada vez que se
ejecute un cliente, en su primer intento por utilizar el servidor, el cliente enva
una solicitud de cuestionamiento a un servidor especial de asociaciones, el cual
se conoce como servidor de nombres para pedirle el nmero de mquina donde
se localiza en ese momento el servidor.
53
2. Primitivas de Comunicacin
Primitivas con bloqueo o sin bloqueo.- una primitiva tiene una semntica sin
bloqueo cuando su ejecucin no produce un retardo en el proceso que la invoca;
de otra manera la primitiva es con bloqueo.
Existen bsicamente cuatro tipos de comunicacin para este tipo de primitivas:
1. Send con bloqueo (CPU inactivo durante la transmisin de los mensajes)
2. Send sin bloqueo, sin copia (no se puede sobrescribir hasta que el mensaje
haya sido ledo)
3. Send sin bloqueo, con copia (se desperdicia el tiempo del CPU para la copia
adicional)
4. Send sin bloqueo, con interrupcin (dificulta la programacin)
54

Primitivas almacenadas con buffer y no almacenadas.- cuando se efecta un
intercambio de mensajes se presentan dos casos en relacin a donde se va a
almacenar la informacin. En el primero de estos es el proceso servidor el que
destina una rea para recibir un mensaje al efectuar la operacin receive (no
almacenado); mientras que en el segund o el proceso servidor solicita la creacin
de un buzn para alojar los mensajes que a ser recibidos mientras los puede
procesar (almacenamiento con buffers).
En sistemas sin buffer, la ejecucin 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 ejecucin. Ambos
procesos se sincronizan o se encuentran cuando el mensaje es transferido.
Los sistemas con buffer son ms difciles 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 semntica de send para
hacerlo no confiable. El sistema no da garanta alguna acerca de la entrega de
mensajes. La implantacin de una comunicacin se deja enteramente en manos
de los usuarios
El segundo mtodo exige que el ncleo de la mquina receptora enve un
reconocimiento al ncleo de la mquina emisora. Slo cuando se reciba este
reconocimiento, el ncleo emisor liberar al proceso usuario (cliente). El
reconocimiento va de un ncleo 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 ncleo del servidor, la respuesta del servidor de
regreso al cliente es reconocida por el ncleo del cliente. As una solicitud de
respuesta consta de cuatro mensajes.
55

El tercer mtodo aprovecha el hecho de que la comunicacin cliente-servidor se
estructura como una solicitud del cliente al servidor, seguida de una respuesta
del servidor al cliente. En este mtodo, el cliente se bloquea despus de enviar
un mensaje. El ncleo del servidor no enva 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 ncleo emisor puede
volver a enviar la solicitud para protegerse contra la posibilidad de una prdida
del mens aje.
Una consideracin ms dentro de la comunicacin por paso de mensajes es la
determinacin del receptor o receptores de un mensaje. Se tienen tres opciones:
Transmisin a un slo receptor (unicast)
Transmisin radial (broadcast)
Transmisin radial mltiple (multicast)
Llamados a Procedimientos Remotos
El llamado a procedimientos remotos (RPC) implica que un proceso cliente enva
una peticin 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 cmputo
centralizado. Una de las principales ventajas de este esquema de comunicacin
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
lenguaje de programacin y manejar los tipos de datos
traducindolos en llamadas a servicios del nivel de Transporte
mecanismo RPC est asociado con servicios en los niveles de
Sesin en el modelo OSI:
escritas en un
de alto nivel
en una red. El
Presentacin y
Las primitivas de comunicacin 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.
56

Transacciones
Dentro de los sistemas distribuidos, hay muchos casos en que una sola
comunicacin no resuelve problemas especficos de interaccin entre dos
procesos (por ejemplo, un retiro de una cuenta bancaria). La interaccin entre
los procesos puede ser una secuencia de comunicaciones y clculos. En estas
situaciones, es adecuado operar en base a transacciones.
El concepto de transaccin se desarroll en sistemas de manejo de bases de
datos para mantener la consistencia de la informacin almacenada. Los
mecanismos de transacciones simplifican la construccin de sistemas
confiables, y son transparentes para las aplicaciones de usuario (nivel de Sesin
en el modelo OSI).
En general, el trmino transaccin describe una secuencia de operaciones sobre
una o ms 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 transaccin no
se puede cancelar (al menos que se aplique otra transaccin).
Los sistemas de transacciones deben soportar las siguientes operaciones:

terminacin, concurrencia y recuperacin (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 enva peticiones a los
N esclavos solicitando algunas operaciones. Cada esclavo verifica si puede
atender la peticin. Si en efecto puede, el esclavo almacena la peticin y el
estado inicial del objeto en cuestin, bloquea el objeto (para que las peticiones
de otros maestros no puedan interferir), y enva un mensaje confirmando su
disposicin a realizar el trabajo. De otro modo, enva un mensaje rechazando la
peticin.
57

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 ms esclavos rechazan la peticin
inicial, el maestro aborta la operacin y pide a los esclavos que desbloqueen su
objeto y restablezcan su estado inicial.
Un esclavo puede caerse despus de recibir una peticin y antes de ejecutar su
trabajo. En este caso, el esclavo puede recuperarse cuando es reactivado, en
base al estado inicial y a la peticin que debe tener almacenados.
58

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 jerrquica (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
abstraccin.
Cada capa deber efectuar una funcin bien definida.
La funcin que realizar cada capa deber seleccionarse con la intencin de
definir protocolos normalizados internacionalmente.
Los lmites de las capas debern seleccionarse tomando en cuenta la
minimizacin del flujo de informacin a travs de las interfaces.
El nmero de capas deber ser lo suficientemente grande para que funciones
diferentes no tengan que ponerse juntas en la misma capa y, por otra tambin
deber ser suficientemente pequeas para que su arquitectura no llegue a ser
difcil de manejar.
Capa Fsica
Comprende:
Transmisin de cadenas de bits, sin importar su estructura, a travs de algn
medio fsico.
Caractersticas:
a) Mecnicas (conectores, cables, etc.).
b) Elctricas (voltajes, tcnicas de modulacin, etc.).
c) Funcionales (por ejemplo, definicin 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:
Deteccin y control de errores producidos en la capa fsica.
Sincronizacin de la transmisin.
59

Control de acceso al medio de comunicacin (redes locales).
Activacin, mantenimiento y desactivacin de enlaces entre dos o ms nodos.
Control de flujo (control, por parte del nodo receptor, de la cantidad de datos
aceptados o la velocidad de transmisin).
Ejemplos:
SDLC, HDLC, LAPB, LLC (IEEE 802.2).
Capa de Red ( Inter-red)
Comprende:
Entrega de paquetes entre dos o ms nodos a travs de inter-redes

(redes de redes), proporcionando independencia de las tecnologas de
transmisin de datos o de conmutacin usadas entre los sistemas
conectados.
Establecimiento, mantenimiento y terminacin de conexiones (en
servicios orientados a la cone xin).
Ejemplos:
CLNP de OSI
IP de la familia TCP/IP
IPX de Novell
X.25 PLP (Packet-Level Protocol)
Capa de Transporte
Comprende:
Comunicacin entre procesos residentes en distintos sistemas, permitiendo

"multiplexar" dos o ms enlaces proceso-a-proceso sobre un solo canal de
comunicacin.
En servicios orientados a la conexin, entrega de datos confiable por medio
de recuperacin de errores, secuenciacin de paquetes, control de flujo y
control de retardos en la transmisin.
Ejemplos:
TP0-TP4 de OSI
TCP y UDP de la familia TCP/IP
SPX de Novell
Capa de Sesin
Comprende:
Control y sincronizacin de dilogos o sesiones.
60
Control de puntos de verificacin (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 Presentacin ( Representacin)
Comprende:
Representacin y/o sintaxis de los datos.

Encripcin de informacin.
Compresin de datos.
Ejemplos:
ASN.1 (Abstract Syntax Notation) de OSI
XDR (External Data Representation) de Sun Microsystems
DES (Data Encryption Standard)
Capa de Aplicacin
Comprende:
Aplicaciones de red.
Interfaces de programacin 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)
Emulacin de terminal (Telnet de TCP/IP)
Correo electrnico (X.400 de CCITT, SMTP de TCP/IP)
Administracin de redes (SNMP de TCP/IP, CMIP de OSI)
Servicios de directorio (OSI Directory Services, X.500 de CCITT)
61
62

2.2.3 Protocolos TCP/IP
La familia de protocolos conocida como TCP/IP fue desarrollada a mediados de
los aos 70s por la Universidad de Stanford y a
l compaa Bolt, Beranek and
Newman. Quien patrocin su desarrollo fue el Departamento de Defensa de E.U.
a travs 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 das conecta a
ms de 30,000 subredes y 2.5 millones de computadoras en unos 107 pases.
La tabla 1 muestra algunos de los protocolos ms 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.
Internet Control Message

Protocol (ICMP)
Controla la transmisin de mensajes 3

de error y de control entre nodos y
gateways.
Address Resolution Protocol

(ARP)
Mapea direcciones IP a direcciones

fsicas.
Reverse Address Resolution

Protocol (RARP)
Mapea direcciones fsicas a

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

nodos.
User Datagram Protocol

(UDP)
Entrega no confiable y sin conexin

de paquetes entre nodos.
File Transfer Protocol (FTP)
Transferencia de archivos.
5-7
Telnet
Emulacin de terminal.
5-7
Tabla 1.- Protocolos TCP/IP ms comunes.
63

La figura 1 muestra las capas de la arquitectura TCP/IP. Al igual que en el
modelo OSI, cada capa en la mquina fuente se comunica con la misma capa de
la mquina 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 Fsicas y Direcciones IP
Cada nodo tiene una direccin fsica (llamada direccin MAC en el contexto de
redes locales) asociada con el dispositivo de hardware que lo conecta con la red.
Por ejemplo, en Ethernet, una direccin fsica es un nmero de 6 bytes; las
redes X.25 usan el estndar X.121 que define direcciones fsicas como nmeros
de 14 dgitos.
La direccin IP de un nodo es una direccin lgica (independiente del hardware).
Consiste de 32 bits (4 bytes) que identifican tanto a la red como al host particular
dentro de esa red.
Tpicamente, las direcciones IP se representan en notacin decimal con puntos.
(Por ejemplo, 129.71.6.17 corresponde a 0x81.0x47.0x6.0x11).
64

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 fsicas 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 direccin IP se divide en dos partes: la porcin de red y la porcin de host.
La divisin de cuntos bits corresponden a cada porcin queda definida por la
clase de direccin. Se manejan tres clases principales, denominadas A, B y C.
Una direccin clase A consta de 1 byte para la porcin de red y 3 bytes para el
host. El bit ms significativo de la porcin de red es siempre 0. Esto permite 126
redes clase A (1 a 126) con ms de 16 millones de nodos en cada una.
Una direccin clase B consta de 2 bytes para la porcin de red y 2 bytes para el
host. Los bits ms significativos de la porcin de red son siempre 10. As, es
posible tener 16 mil (214) redes clase B con ms de 65,000 nodos cada una.
Una direccin clase C consta de 3 bytes para la porcin de red y 1 byte para la
porcin de host. Los tres bits ms significativos de la porcin de red son siempre
110. Esto permite aproximadamente dos millones de redes clase C con un
mximo de 254 nodos cada una.
Direcciones Reservadas
Direcciones de red. Estas son direcciones IP donde la porcin de host est
puesta en ceros. Por ejemplo, 129.47.0.0 es la direccin de una red clase B.
Direcciones de broadcast. Estas son direcciones donde la porcin de host est
puesta en unos.
Direccin de loopback. La direccin 127.0.0.0 est diseada para pruebas y
comunicacin entre procesos en forma local. Un paquete enviado a la direccin
de red 127 no debe aparecer jams en ninguna red.
65

Protocolos
El Protocolo IP
IP proporciona un servicio de entrega de paquetes no confiable y sin conexin.
El servicio es no confiable porque la entrega de un paquete no est garantizada.
Un paquete puede ser ruteado errneamente, duplicado o puede desaparecer
en su camino al destino final. El servicio es sin conexin 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 fsica. Sin embargo, durante su viaje un paquete puede cruzar
distintos tipos de redes con marcos de tamao 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 informacin
entre procesos especficos residentes en distintas mquinas. 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 especficas (por ejemplo, Telnet utiliza el puerto 23). Otros nmeros
de puerto son asignados dinmicamente.
Dentro de la familia TCP/IP se manejan principalmente dos protocolos de
transporte: UDP y TCP.
66

El Protocolo UDP
UDP provee un servicio de transporte no confiable y sin conexin. Cada
datagrama UDP es encapsulado en uno o ms datagramas IP.
UDP se utiliza en aplicaciones que requieren intercambiar poca informacin, o
donde el costo de establecer una conexin 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 conexin.
TCP mantiene un circuito virtual entre dos aplicaciones, controlando las formas
en que esta conexin 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 prdida o duplicacin de
paquetes.
2.2.4 Sockets
Introduccin
La interfaz de sockets es una API (Application Programming Interface) que
permite el desarrollo de programas donde se requiera comunicacin entre
procesos, ya sea local o remotamente, con base en distintos protocolos de
comunicacin (principalmente TCP/IP, XNS y mecanismos de comunicacin
entre procesos de Unix).
El uso ms comn 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 funcin del sistema operativo
que se est usando as como del lenguaje de programacin. Originalmente, la
interfaz de sockets fue desarrollada para el Unix de Berkeley (lase 4.1cBSD),
hacia el ao 1982. No sorprende que esta herramienta se haya diseado en
lenguaje C.
En sistemas Unix existe otra API de comunicaciones estndar, el Transport
Layer Interface (TLI) del Unix System V de la AT&T. sta tambin fue
desarrollada en lenguaje C y en trminos 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.
67

Qu es un socket?
Definicin Informal
Un socket es un extremo o un punto terminal de un canal de comunicacin entre
dos procesos. Obviamente, para formar un canal de comunicacin se requieren
dos sockets, a los cuales se les conoce como socket local y socket remoto. La
comunicacin a travs de una conexin 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 tambin 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).
Definicin Formal
Una conexin de red entre dos procesos queda completamente definida por una
asociacin, la cual es una quinteta formada de la siguiente manera:
{protocolo, direccin_local, proceso_local, direccin_remota, puerto_remoto}
Un ejemplo de asociacin 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 asociacin, se puede definir un socket como una
media-asociacin, la cual tiene dos posibles definiciones:
{protocolo, direccin_local, proceso_local}
{protocolo, direccin_remota, proceso_remoto}
A una media-asociacin tambin se le llama direccin 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 estn
familiarizados con el manejo de archivos por medio de las operaciones bsicas
open-read-write-close. La interfaz de sockets intenta que la programacin en
ambientes distribuidos se realice con las mismas operaciones, slo que en lugar
de actuar sobre un archivo actan sobre un punto terminal de un canal de
comunicaciones (socket). De esta manera tenemos las siguientes analogas:
68

Operaciones sobre un archivo
open(archivo)
Operaciones sobre un socket

open(socket)
read(archivo, datos)
read(socket, datos)
o
receive(socket, datos)
write(socket, datos)
o
send(socket, datos)
close(socket)
write(archivo, datos)
close(archivo)
En realidad las operaciones sobre sockets son ms complicadas.

Por ejemplo, la accin de abrir un socket se divide en tres pasos:
Crear el socket (local).
Asociar la interfaz de red y el nmero 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 relacin cliente-servidor es asimtrica. Antes de establecer una conexin en
red se requiere que el programa sepa qu funcin (cliente o servidor) va a
desempear.
Una conexin de red puede ser orientada a la conexin o sin conexin. La
primera se parece ms al manejo de archivos que la segunda, dado que, una
vez que se ha establecido (es decir, abierto) una conexin, las operaciones de
entrada/salida se aplican sobre el mismo proceso pareja. En el caso de un
protocolo sin conexin, no existe una operacin de open debido a que cada
operacin de entrada/salida sobre la red se puede hacer con un proceso distinto
en un host distinto.
La definicin de asociacin comprende cinco parmetros, para una conexin de
red se requieren manejar ms parmetros que para operaciones de
entrada/salida sobre archivos.
La API de red debe soportar diferentes protocolos de comunicacin. 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 algn
mecanismo genrico para operar sobre cualquier protocolo.
69
Principales Llamadas de Sockets

La interfaz de sockets comprende decenas de llamadas a funcin. El uso y la
semntica de cada funcin depende del contexto en que se aplica, influyendo
aspectos como el tipo de protocolo de transporte utilizado (orientado a la
conexin o sin conexin) y el rol del programa (lado cliente o lado servidor). A
continuacin se presentan slo las llamadas elementales.
Socket
Una aplicacin 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
family
Tipo
int
type
int
protocol
int
Significado
Familia de protocolos (AF_INET para
TCP/IP).
Tipo de servicio (SOCK_STREAM para TCP
o SOCK_DGRAM para UDP).
Nmero de protocolo para la familia de
protocolos dada; normalmente 0.
Connect
Despus de crear un socket, un cliente llama a connect para establecer una
conexin activa a un servidor remoto.
Uso:
retcode = connect (socket, addr, addrlen);
Argumentos:
Argumento
socket
addr
addrlen
Tipo
int
sockaddr *
int
Significado
Descriptor del socket.
Punto de conexin en la mquina remota.
Longitud del segundo argumento.
Write
Tanto clientes como servidores usan write para enviar informacin a travs de
una conexin de red. Esta funcin se usa principalmente sobre TCP.
70
Uso:
retcode = write (socket, buf, buflen);
Argumentos:
Argumento
socket
buf
buflen
Tipo
int
char *
int
Significado
Apuntador al buffer que contiene los datos.
Longitud en bytes del buffer.
Read
La llamada read es usada tanto por clientes como por servidores para recibir
datos de una conexin de red, principalmente sobre TCP.
Uso:
retcode = read (socket, buf, buflen);
Argumentos:
Argumento
socket
buf
buflen
Close
Tipo
int
char *
int
Significado
Apuntador al buffer que recibe los datos.
Longitud en bytes del buffer.
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:
Argumento
socket
Tipo
int
Significado
Bind
Cuando se crea un socket, ste no sabe cules son las direcciones local y
remota de la conexin. Una aplicacin llama a bind para especificar la direccin
local del socket. Esta llamada es usada principalmente por servidores para
indicar el puerto conocido en el cual esperarn conexiones.
71

Uso:
retcode = bind (socket, localaddr, addrlen);
Argumentos:
Argumento
socket
localaddr
Tipo
int
sockaddr *
addrlen
int
Significado
Apuntador a la estructura que especifica la
direccin IP y el nmero de puerto de
protocolo.
Tamao 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 conexin llaman a listen para poner un socket en modo pasivo,
es decir, listo para aceptar peticiones de conexin. Esta llamada no aplica para
UDP.
Uso:
retcode = listen (socket, queuelen);
Argumentos:
Argumento
socket
Queuelen
Tipo
int
int
Significado
Tamao de la cola de conexiones
pendientes.
Accept
Despus de que un servidor llama a socket para crear un socket, bind para
especificar la direccin local, y listen para poner el socket en modo pasivo, se
llama a la funcin accept con el fin de crear un nuevo socket que atienda a la
nueva conexin. El socket original, que maneja un puerto conocido, se usa
para aceptar otras peticiones de conexin.
Uso:
newsock = accept (socket, addr, addrlen);
Argumentos:
Argumento
socket
Tipo
int
Significado
Descriptor del socket original.
72

addr
sockaddr *
addrlen
int *
Apuntador a una estructura de direccin

TCP/IP. Accept llena la estructura con la
direccin IP y el nmero de puerto de
protocolo de la mquina remota
Apuntador a un entero que inicialmente
especifica el tamao del argumento addr y,
cuando la llamada regresa, especifica el
nmero de bytes almacenados en addr.
Las figuras 1 y 2 ejemplifican la secuencia en que se efecta el envo y

recepcin de datos para comunicaciones orientadas a conexin y no orientadas
a conexin; y las figuras 3 y 4 muestran las secuencias tpicas de llamadas
hechas por un cliente y un servidor usando los protocolos TCP y UDP,
respectivamente.
73
74
2.2.5 Remote Procedure Call (RPC)

Introduccin
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 funcin del acoplador es empacar los argumentos
para el procedimiento remoto, posiblemente ponerlos en un formato estndar
(como se comentar ms adelante) y luego construir uno o ms mensajes de
red. El empaquetamiento de los argumentos del cliente en un mensaje de red
recibe el nombre de alineacin (en ingls, marshaling).
El acoplador del cliente enva 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 conexin o uno sin conexin, dependiendo del producto
utilizado.
Un acoplador del servidor en el sistema remoto espera la llegada de la peticin
del cliente. Este componente obtiene o desalinea a partir de los mensajes de
(accin conocida en ingls como unmarshaling) y posiblemente convierte su
formato.
El acoplador del servidor ejecuta un llamado a procedimiento local para invocar
a la funcin real del lado servidor, pasndole los argumentos que recibi en los
mensajes de red del acoplador del cliente.
75
Cuando el procedimiento del lado servidor termina, regresa el control al

acoplador del servidor, entregndole algn o algunos valores de regreso.
El acoplador del servidor convierte los valores de regreso, si es necesario, y los
alinea en uno o ms mensajes de red para enviarlos de vuelta al acoplador del
cliente.
Los mensajes se transfieren de regreso a travs de la red al acoplador del
cliente.
El acoplador del cliente lee los mensajes del kernel local.
Despus 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 parmetros.
Asociacin entre el cliente y el servidor.
Protocolo de transporte.
Manejo de excepciones.
Semntica de la llamada.
Representacin de datos.
Rendimiento.
76

1. Paso de Parmetros
El paso de parmetros entre cliente y servidor puede no ser transparente. Los
parmetros 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 parmetros que se pasan por referencia (es decir, cuando se
pasa la direccin de una variable en lugar de su valor). Obviamente el servidor
no puede hacer referencias directamente a la memoria del sistema cliente.
La solucin tpica consiste en slo permitir el paso de argumentos por valor.
Para cada procedimiento remoto se define especficamente cules son los
parmetros de entrada y cules son los parmetros de regreso.
2. Asociacin entre el cliente y el servidor
La asociacin 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 implementacin de
RPC, entre ellos podemos mencionar UDP, TCP, SPX, TP. Cabe sealar que
estos no fueron diseados especficamente para dicho fin.
4. Manejo de excepciones
Dentro de una llamada a una funcin remota hay muchas cosas que pueden
fallar. Podemos experimentar problemas con la red, con nuestra mquina o
incluso con la mquina 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. Tambin puede suceder que el
cliente salga de su sesin de Internet cuando todava no se termina de ejecutar
el procedimiento remoto, lo que generara un fallo cuando el servidor intente
mandar el resultado o la conclusin del procedimiento al usuario.
Para todos estos problemas se debe tener un manejo de excepciones, las
cules son generadas cuando se suscita algunos de los problemas que
mencionamos. Las excepciones son una lista de valores numricos que
representan el fallo que ocurri.
77

5. Semntica de la llamada
Cuando se hace una invocacin a un procedimiento local, no hay ninguna duda
respecto a cuntas 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 despus de cierto
tiempo, no sabemos cuntas 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.
Prdida de mensajes de solicitud.- este es un caso sencillo, ya que lo nico que
es necesario hacer es que el ncleo inicialice un cronmetro al enviar la
solicitud. Si el tiempo se termina antes de que regrese una respuesta o
reconocimiento, el ncleo vuelve a enviar el mensaje.
Prdida de mensajes de respuesta.- la prdida de las respuestas es ms difcil
de enfrentar. La solucin ms obvia es basarse de nuevo en un cronmetro. Si
no llega una respuesta en un periodo razonable, solo hay que volver a enviar la
solicitud. El problema con esta solucin es que el ncleo del cliente no est
seguro de la razn por la que no hubo respuesta. Se perdi la respuesta?
Ocurre que el servidor es lento?. Esto puede ser la diferencia.
Cuando una operacin, tal como un llamado a procedimiento, se puede ejecutar
cualquier nmero de veces sin causar ningn dao, se dice que es
idempotente. Ejemplos de procedimientos idempotentes son: una funcin que
regrese la hora del da, una funcin para calcular la raz cuadrada, un
procedimiento para leer los primeros 512 bytes de un archivo en disco y una
funcin para obtener el saldo actual de una cuenta bancaria. Ejemplos de
procedimientos que no son idempotentes son: una funcin para agregar 512
bytes al final de un archivo en disco, una funcin 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 mtodo sera que el
ncleo del cliente asigne un nmero secuencial a las solicitudes. Si el ncleo del
servidor mantiene un registro del nmero secuencial de recepcin ms reciente
de cada uno de los ncleos clientes que lo utilizan, el ncleo servidor podr
indicar la diferencia entre una solicitud original y una retransmisin. Una
proteccin adicional es tener un bit en el encabezado del mensaje para distinguir
las solicitudes de las retransmisiones.
Fallos del servidor.- este tambin se relaciona con la idempotencia, pero por
desgracia no se puede resolver mediante nmeros secuenciales.
78

La razn 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 despus 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 peticin, las cosas se
confunden ms: es posible que la peticin original se haya retardado en algn
punto de la red pero que tarde o temprano se haya ejecutado, y que la peticin
retransmitida tambin se haya ejecutado.
Hay tres semnticas posibles en RPC:
Exactamente una vez significa que el procedimiento remoto fue ejecutado una
vez, nada ms. Este tipo de operacin es difcil de lograr debido a la posibilidad
de cadas de los servidores.
Como mximo una vez significa que el procedimiento remoto no fue ejecutado o
que fue ejecutado cuando ms una vez. Si el cliente obtiene un regreso normal,
sabemos que el procedimiento remoto fue ejecutado una vez. Pero si se obtiene
una condicin 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
ocasin pero posiblemente ms veces. Esto es tpico para procedimientos
idempotentes: el cliente se mantiene transmitiendo su peticin hasta que recibe
una respuesta vlida. Pero si el cliente tiene que enviar su peticin ms de una
vez para recibir una respuesta vlida, hay una posibilidad de que el
procedimiento remoto fue ejecutado ms de una vez.
6. Representacin de datos
Un elemento que afecta a la comunicacin entre dos equipos distintos es la
forma de representacin de los datos. Para solucionar esta problemtica es
necesario definir un estndar de representacin.
7. Rendimiento
En relacin a este punto es necesario sealar que cada mquina en conjuncin
con el sistema operativo con que cuenta, representa una problemtica 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 cdigo relacionado con estos procedimientos.
79
2.3. Modelo de Capas

Actividad 2.3
Para estudiar el Modelo de Capas o de Aplicacin para disear programas
estudiaremos algunos fundamentos tericos y posteriormente se plantearn
escenarios de una aplicacin modelada
Instrucciones
Coloque los programas solicitados en Tarea Individual 2.3
Material 2.3.
Una estrategia fundamental para disear aplicaciones, particularmente aquellas

basadas en componentes, consiste en utilizar el modelo de aplicacin.
El modelo de aplicacin sugiere modelar las aplicaciones por capas. El trmino
capa deriva del trmino en ingls tier (no proviene del trmino layer en ingls).
Independientemente del nmero de capas que se empleen para disear una
aplicacin, son bsicamente 3 tipos de servicios que pueden proveer estas
capas:
Servicios de usuario o presentacin
Servicios de negocio
Servicios de datos
80
Cuando una aplicacin se disea a una capa, estos 3 tipos de servicios se

encuentran fusionados en el cdigo de este componente.
Cuando se disea 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 presentacin y servicios de negocio

Servicios de negocio y servicios de datos
La combinacin exclusiva de servicios de presentacin con servicios de datos en

una capa es invlida.
Las aplicaciones diseadas a mayor nmero de capas son posibles, ya que
aunque estos servicios persisten, las capas pueden comenzar a estratificarse en
subcapas y es en dnde aparecen un mayor nmero 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 aplicacin de 4
capas. A partir de la tercera capa, podemos hablar de modelos multicapa o ncapas.
Los servicios de usuario o presentacin 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 presentacin son proporcionados por una Interfaz
Grfica del Usuario (GUI Graphic User Interface). Cuando el usuario es un
programa o componente, los servicios de presentacin son proporcionados a
travs de una API o interfaz programtica.
81

Aunque la capa de presentacin no debe procesar informacin puesto que
corresponde a la capa de negocio; es vlido que la capa de presentacin tenga
cdigo de procesamiento para validar entrada de datos en forma bsica o
formatear informacin de salida.
Los Servicios o Reglas de Negocio de una aplicacin corresponden a los

algoritmos principales de sta. El emplear el trmino Negocio no implica que
forzosamente correspondan a algoritmos de aplicaciones administrativas; sino
que, como se ha denotado, es cualquier algoritmo principal de la aplicacin. Por
ejemplo, en un programa que pida nmeros 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 travs de la tecnologa de componentes
basada en objetos. El empleo del paradigma de la orientacin a objetos nos
hace recurrir a un conjunto de herramientas denominadas Monitores de
Transacciones (tambin conocidos en ingls 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 aplicacin de crditos hipotecarios, en un punto de
ejecucin de la misma se requerir que para otorgar un crdito 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
aplicacin deber realizar una serie de consultas y clculos para autorizar el
crdito. Este tipo de algoritmos corresponden a las reglas de negocio.
82
La capa de datos realiza los servicios u operaciones de manipulacin de bajo

nivel de base de datos.
Los servicios u operaciones podrn ser los de insercin, borrado, modificacin y
consulta en una base datos.
Como se coment en la seccin anterior, la capa de negocio solicita estos
servicios ms no los implementa o lleva a cabo. La capa de datos si los
implementa.
83

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 dnde se localizan los datos, como se implementa el acceso a
los mismos y los pormenores de ste.
Ejemplo a 2 Capas
Cliente
Presentacin
Presentacin
Presentacin
(Servicios de Usuario)
Reglas de Negocio
(Lgica de Aplicacin)
Cliente
Red
Reglas de Negocio
Reglas de Negocio
Red
Datos y Recursos
(Servicios de Datos)
Presentacin
Reglas de Negocio
Datos y Recursos
Datos
Datos
Servidor
Servidor
En el modelado a 2 capas, existen 2 formas en que las capas pueden

fusionarse:
1) Capa de presentacin Capa de negocio, o
2) Capa de negocio Capa de datos
Ejemplo a 3 Capas
Presentacin
Presentacin
Cliente
Red
Reglas de Negocio
Reglas de Negocio
Middleware
+
Servidor1
Red
Datos y Recursos
Datos
Servidor2
Base de Datos
84

En el modelado a 3 capas, los servicios se distribuyen para cada uno de estos
tipos de servicios: presentacin, negocio y datos.
Por ejemplo, para una aplicacin diseada a 3 capas podemos tener una
aplicacin cuya capa de presentacin pueda ser provista de dos formas. Una de
ellas a travs de la interfaz grfica que puede ser construida con un lenguaje de
programacin. La otra a travs de un navegador para Internet (browser)
empleando pginas Web (construidas en forma esttica o dinmica).
La capa de negocio puede ser implementada a travs tecnologa de
componentes. Y la capa de datos a travs de componentes de acceso a
manejadores de bases de datos.
Existe una discusin respecto a la implementacin de la capa de datos. Algunos
autores o diseadores 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 interacten con
el manejador de bases de datos y los procedimientos almacenados; y todos
estos elementos
85
Escenario 2.3.
La aplicacin del ejemplo consiste en una interfaz grfica que solicita al usuario
su nombre y fecha de nacimiento. A travs de dos botones principales, el
primero Calcular edad y el segundo Guardar. Calcular edad obtendr la
fecha de sistema y calcular la diferencia en aos entre sta y la fecha de
nacimiento capturada. Guardar almacenar la informacin en una base de
datos.
Una propuesta o sugerencia de la interfaz grfica.
86
Pseudocdigo para disear la aplicacin a 1 capa
Pseudocdigo para disear la aplicacin a 2 capas
87
Pseudocdigo para disear la aplicacin a 3 capas
88
89

Rbrica para evaluacin de ejercicios prcticos
Atributos
Aplicacin de
la
Informacin
Conexiones
Especialistas
Arriba del
Estndar
(10-9)
La informacin
revisada permiti
a los estudiantes
comprender con
claridad los
ejercicios y
programas.
(10-9)
Los estudiantes
han demostrado el
significado del
material
elaborando
correctamente,
mientras
extienden y
explican la
informacin,
incorporndola en
el estudio del
tema.
Debajo del
Estndar
En el Estndar
Puntos de
Atributo
Obtenidos
(8.5-7)
(6.5-0)
La informacin La informacin
revisada permiti revisada no
a los estudiantes permiti a los
comprender
estudiantes
solamente los
comprender
ejercicios y
los ejercicios y
programas.
programas.
(8.5-7)
(6.5-0)
Los estudiantes
han demostrado
el significado del
material
incorporndolo
correctamente
en el estudio del
tema.
Los
estudiantes no
han hecho
contacto con el
material,
simplemente
sin incorporar
la informacin
en su estudio
del tema.
Total de Puntos Obtenidos
90
3. Tecnologas de Desarrollo
Panorama General
Tecnologas de Desarrollo Sistemas

Distribuidos
Definicin de Actividades
Agenda
Metodologa Actividades
Evaluacin
91
Metodologa
Introduccin
Estrategias de Aprendizaje
o Aprendizaje Basado en Problemas
o Estudio de Casos
o Aprendizaje Orientado a Proyectos
Introduccin
En el sentido de abordar el tema de tecnologas de desarrollo
dentro de los sistemas distribuidos se plantearan las bases para
que los alumnos trabajen en un ambiente de colaboracin a
travs de los pasos de las tcnicas didcticas de aprendizaje
basado en problemas (ABP), estudio de casos (EC) y
aprendizaje orientado a proyectos (AOP).
Al incorporar las estructuras de estas tcnicas se identifican los
roles dentro de los grupos o equipos de alumnos, as como del
profesor o tutor.
92
Aprendizaje Basado en Problemas

Con la tcnica de ABP los alumnos aprendern a:
1) Identificar sus necesidades de aprendizaje.
2) Dirigir su aprendizaje utilizando recursos adecuados.
3) Proveer a los dems con muestras de su aprendizaje.
4) Actuar en general en forma responsable.
Problema:
Discusin en un grupo reducido:
Descripcin de un conjunto de
problemas o sucesos.
Qu es lo que ya s sobre el
problema?.
Preparado por un equipo de

docentes.
Qu es lo que necesito saber

sobre el problema?
Adquirimos una mejor

comprensin de los procesos
involucrados en el problema?
Estudio individual:
Exploracin de los diversos

recursos de aprendizaje.
Fuentes externas de
informacin.
Integracin de los
conocimientos de varias
disciplinas.
93
ABP, Roles y Apoyos en General

Dinmica ABP:
Presentacin del problema.
Anlisis, construccin de hiptesis
e identificacin de la informacin
necesaria.
Enumeracin de las reas de duda.
Bsqueda de la informacin
Discusin de la hiptesis segn los
datos.
Replanteamiento / Conclusiones.
Actividades ABP:
Resumen de que saben y que
necesitan investigar.
Distribucin de tareas y forma de
recolectar la investigacin, como
colocar todo junto.
Evaluacin y retroalomentacin.
Roles:
o Equipo de Trabajo (Miembro,
Moderador y/o Secretario).
Investigacin individual.
Discusin grupal.
Discusin plenaria.
o Tutor o Profesor.
Planteamiento del problema.
Seguimiento e integracin.
Apoyos:
o Chat
o Foro
o E-mail
o Fuentes de Informacin
Estudio de Casos
Con la tcnica de EC los alumnos aprendern a:
1) Analizar y ejercitar sobre un caso tpico de estudio.
2) Colaborar y dirigir el aprendizaje utilizando recursos adecuados.
3) Defender el conocimiento adquirido y actuar en forma responsable.
Problema:
Estudio individual:
Descripcin de una situacin

real pero abordable.
Exploracin de los diversos

recursos de aprendizaje.
Preparada por un equipo de

docentes.
Identificacin de alternativas.
Discusin entre grupos:
Defensa de postura.
Reflexin de cada
participante.
Conclusiones sobre hechos

concretos del caso.
Integracin de propuesta.
Intercambio de propuestas.
Confrontacin de ideas.
Preparacin de propuesta
definitiva.
94
Aprendizaje Orientado a Proyectos

Con la tcnica de AOP los alumnos aprendern a:
1) Construir sobre su propio conocimiento una situacin real.
2) Colaborar a un ritmo apropiado y actuar con responsabilidad.
Problema:
Descripcin de un situacin
concreta y real.
Preparada por un equipo de

docentes o propuesta por los
alumnos.
Que proyecto proponemos

con base a los conocimientos
adquiridos?
Que deseamos resolver sobre

el tema del curso?
Producto terminado:
Reporte tcnico
Tpico seleccionado:
Anlisis y definicin de
necesidades.
Planeacin de actividades.
Manual de usuario
Presentacin
Diseo y prototipo.
Actividades
Subtema
Actividad de Aprendizaje
Introduccin al middleware
Utilizar ABP para abordar el

paradigma del middleware
Programacin de
Transacciones
CORBA
Realizar un ejercicio prctico
RMI
Utilizar EC para abordar el

modelo de CORBA
COM+
Web Services
95
Actividades
Con base al estudio del tema 3 de tecnologas de
desarrollo, los alumnos propondrn por equipo, de forma
preliminar, el tpico de implementacin de un sistema
distribuido trivial, con objeto de cubrir ms adelante el
tema 4, Lenguajes de Programacin.
Tema 4
Implementacin de un
sistema distribuido
Actividad de Aprendizaje
Utilizar AOP para abordar
un proyecto sencillo.
Evaluacin
Rbrica de
evaluacin para
el proceso de
ABP
96
Evaluacin
Rbrica de
evaluacin para
el proceso de
EC
Evaluacin
Rbrica de evaluacin para el proceso de AOP
97
Evaluacin
Rbrica de evaluacin de Ejercicios Prcticos
3.1. Introduccin al Middleware

Escenario Middleware
98
Introduccin 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,
Mquina A
Mquina B
Aplicaciones
Mquina C
Lenguajes de Programacin
MIDDLEWARE
Sistema
Hardware
Sistema
Hardware
Sistema
Hardware
Red de Interconexin
99
El paradigma significa "un diseo, ejemplo o modelo." En el estudio de

cualquier tema de gran complejidad, es til para identificar los diseos
bsicos o modelos y clasificar el detalle segn estos modelos.
Este escenario apunta para presentar una clasificacin de los

paradigmas para las aplicaciones distribuidas basadas en el
middleware.
Bsicamente los middleware pueden clasificarse en tres categoras,

orientados a transacciones, a mensajes y a objetos, entonces el objeto
de estudio es la representacin abstracta de los modelos en direccin
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 tcnica de ABP discutir en equipo los modelos del middleware en la
actualidad y proponer una representacin abstracta de ellos.
Foro de discusin Foro Middleware
Coloque su trabajo de equipo en Tarea en Equipo 3.1
Se proporciona Material de Apoyo 3.1, solamente como introduccin.
100

El middleware es un software de conectividad que consiste en la habilitacin de
un conjunto de servicios que permiten procesos mltiples corriendo sobre una o
ms mquinas interactuando por una red. El Middleware es esencial para la
migracin de aplicaciones de mainframe a aplicaciones cliente -servidor y para
mantener la comunicacin de plataformas heterogneas. Esta tecnologa ha
evolucionado durante los aos noventa para proporcionar interoperabilidad en
apoyo del movimiento a arquitecturas de cliente-servidor. Las publicaciones ms
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 aplicacin y el sistema operativo y
servicios de red en un nodo del sistema en la red.
Los servicios del middleware proporcionan un conjunto ms funcional de
Interfaces de programacin de aplicaciones (API) que el sistema operativo y que
los servicios de red para permitir una aplicacin que permita:
Localizar de forma transparente por la red, proporcionando interaccin

con otra aplicacin o servicio
Ser independiente desde los servicios de red.
Ser fiable y disponible.
Aumentar en capacidad sin perdida de funcin.
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 lgica de
una aplicacin por la red. La lgica 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 creacin de aplicaciones
distribuidas. El MOM es anlogo a envo de correo electrnico en el sentido que
101

es asincrnico 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 aplicacin para ser distribuida y compartida por redes
heterogneas.
Consideraciones tiles
El propsito principal de servicios del middleware es ayudar en la solucin de
varios problemas de conectividad de la aplicacin y de interoperabilidad. Sin
embargo, los servicios del middleware no son un remedio, debido a que:
Hay un hueco entre los principios y prctica. Muchos servicios del

middleware populares usan aplicaciones propietarias (aplicaciones que
hacen dependencia en el producto de un slo vendedor).
El nmero de servicios del middleware es una barrera a usarlos. Para
guardar su entorno informtico manejablemente simple, los
desarrolladores tienen que seleccionar un nmero pequeo de servicios
que satisfacen sus necesidades por la funcionalidad y fondos de la
plataforma.
Mientras los servicios del middleware aumentan el nivel de abstraccin de
programar aplicaciones distribuidas, todava dejan al desarrollador de
aplicaciones con opciones de diseo pesadas. Por ejemplo, el
desarrollador todava debe decidir que funcionalidad poner sobre el lado
del cliente y del servidor de una aplicacin distribuida.
La clave para superar estos tres problemas es entender el problema de la

aplicacin y el valor de servicios del middleware que puedan habilitar la
aplicacin 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 crticas,
programa-a-programa y servicios de administracin de datos. Este tipo de
servicio incluye RPCs, MOMs y ORBs.
Aplicacin 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 administracin de los servicios del middleware que habilite aplicaciones y
funciones del sistema que sean continuamente monitoreados para asegurar el
rendimiento ptimo del entorno distribuido.
102

Rbrica para evaluacin de tareas del proceso de ABP
Atributos
Definicin del
Problema
Profundidad de
Estudio
Arriba del
Estndar
En el
Estndar
Debajo del
Estndar
(5 -4.5)
(4 -3.5)
(3-0)
Sus
intervenciones
mostraron
bastante
relacin con
el escenario y
fueron la base
para abordar
el problema.
Sus
intervenciones
mostraron
relacin con
el escenario,
pero no
lograron
aterrizarlas
del todo para
abordar el
problema.
Participacin,
pero sus
intervenciones
no estaban
relacionadas
con el
escenario ni
condujeron
para abordar
el problema.
(10-9 )
(8.5 -7)
(6.5 -0)
La
La
informacin
informacin
reunida
reunida
incluye los
incluye los
elementos
elementos
esenciales del esenciales del
tema y un
tema y un
estudio en
estudio
profundidad
normal del
del tema.
tema.
(5 -4.5)
(4 -3.5)
Puntos de
Atributo
Obtenidos
La
informacin
reunida est
incompleta y
no incluye los
elementos
esenciales del
tema.
(3-0)
Su aportacin
Hizo
Hizo pocas
fue
bastantes
determinante aportaciones, aportaciones
para la
pero le falto y sin relacin
Solucin/explicacin
elaboracin aterrizarlas en
con las
del problema
del reporte
propuestas
posibles
final de la
concretas de soluciones del
solucin del
solucin al
problema.
problema.
problema.
103
3.2. Programacin de Transacciones

Escenario Transacciones
Programacin de Transacciones
Escenario
Qu es una transaccin?
Una transaccin es un conjunto de

tareas relacionadas que se realizan
de forma satisfactoria o incorrecta
como una unidad. En trminos de
procesamiento, las transacciones se
confirman o se anulan. Para que una
transaccin 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.
104
La creacin de una transaccin completa puede requerir la cooperacin de
varios componentes. En el ejemplo de la figura, la aplicacin de entrada de
pedidos consta de componentes que, mediante DCOM (Distributed Component
Object Model), recuperan y procesan informacin de varios servidores.
MTS(Microsoft Transaction Server) proporciona servicios integrados de
programacin que permiten a los programadores asegurarse de que toda la
transaccin tiene xito o se anula por completo, sin necesidad de escribir
grandes cantidades de cdigo personalizado para controlar los mecanismos de
la transaccin.
Escenario de Transacciones
Si bien, las transacciones estn 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.
105
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 cdigo 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 slo la primera instruccin
Cierre la aplicacin con la que introduce los comandos SQL
Vuelva a entrar a la aplicacin y consulte el contenido de la cuenta. Obviamente slo qued
afectada una cuenta y eso es una falta de consistencia en la informacin. Con esto se simula
la falla de la aplicacin y el rompimiento de las propiedades cidas.
Ahora ejecute el siguiente cdigo
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 slo ejecute slo las primeras 2 lneas del cdigo anterior que consta de 4 lneas.
Cierre la aplicacin con la que introduce los comandos SQL
Vuelva a entrar a la aplicacin y consulte el contenido de la cuenta.
Analice la importancia del manejo de transacciones.
Actividad 3.2
Programacin 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 ampliacin de comprensin del
rubro de transacciones.
106
Rbrica para evaluacin Ejercicios Prcticos
Atributos
Arriba del
Estndar
En el Estndar
Debajo del
Estndar
Puntos de
Atributo
Obtenidos
(10-9 )
(8.5-7)
(6.5-0)
La informacin
La informacin
La info rmacin
revisada
revisada permiti
revisada no
permiti a los
Aplicacin de a los estudiantes
permiti a los
estudiantes
la
comprender con
estudiantes
comprender
Informacin
claridad los
comprender
solamente los
ejercicios y
los ejercicios y
ejercicios y
programas.
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
el material,
material
mientras
Especialistas
incorporndolo simplemente
extienden y
correctamente sin incorporar
exp lican la
en el estudio del la informacin
informacin,
en su estudio
tema.
incorporndola en
del tema.
el estudio del
tema.
107

3.2 Programacin de Transacciones
Desde una apreciacin general, el hablar de la comunicacin entre objetos o

componentes a travs 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 aplicacin el control de transacciones es crucial
para mantener la consistencia e integridad de las operaciones.
Una transaccin es un conjunto de acciones que deben efectuarse como una
unidad indivisible de trabajo. Ciertamente al ejecutarse el conjunto de acciones
que conforma la transaccin, puede ocurrir algn error fsico o lgico en su
ejecucin, y de ser as todas las acciones que haban sido efectuadas deben
revertirse. Esta accin ayuda a mantener la consistencia e integridad de la
informacin.
Este tipo de mecanismos deben conformarse en una serie de servicios
disponibles al programador y ofrecer la caracterstica de TRANSPARENCIA. Es
decir, es transparente para el programador el revertir automticamente las
acciones u operaciones efectuadas; el programa se limita a especificar el inicio
108

de la transaccin e indicar en qu punto se efecta la confirmacin (commit) y
eventualmente, poder indicar en forma programtica e intencional el retroceso
(rollback) de la transaccin. Obviamente, en forma inherente si ocurre un error,
se llevar en forma automtica el retroceso (rollback) de la operacin.
Las transacciones deben de cumplir con 4 caractersticas bsicas:

1. Atomicidad: O todo o nada. Es la caracterstica inherente a la
transaccin en la que o todas las acciones se efectan exitosamente o
ninguna de ellas.
2. Consistencia: El efectuar exitosamente toda la transaccin (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 transaccin.
3. Aislamiento: Es inherente la caracterstica 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 transaccin, los datos deben
persistir o haberse almacenado en forma permanente.
Por las siglas de estas caractersticas en ingls resulta la palabra ACID, que
significa cido. Por lo que suele llamarse pruebas o caractersticas cidas el
que un administrador de transacciones cumpla con ellas.
109

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 cdigo 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 slo la primera instruccin
7. Cierre la aplicacin con la que introduce los comandos SQL
8. Vuelva a entrar a la aplicacin y consulte el contenido de la cuenta.
Obviamente slo qued afectada una cuenta y eso es una falta de
consistencia en la informacin. Con esto se simula la falla de la
aplicacin y el rompimiento de las propiedades cidas.
9. Ahora ejecute el siguiente cdigo
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 slo ejecute slo las primeras 2 lneas del cdigo anterior que
consta de 4 lneas.
12. Cierre la aplicacin con la que introduce los comandos SQL
13. Vuelva a entrar a la aplicacin y consulte el contenido de la cuenta.
14. Analice la importancia del manejo de transacciones.
110
Las transacciones pueden clasificarse de varias formas.

Por el control de ejecucin, particularmente por la relacin que existe en el
tiempo de ejecucin entre una accin y la siguiente dentro de la transaccin, hay
transacciones sncronas o asncronas.
La situacin ms comn en una transaccin, 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 accin y la siguiente es una fraccin muy
pequea de segundo. Este tiempo de transaccin se denomina sncrona y son
las que se tratan en este curso.
Una transaccin asncrona es aquella donde existe un tiempo muy prolongado
entre una accin y la siguiente dentro de una transaccin. Las plataformas y
mecanismos de control de transacciones tradicionales no estn pensados para
este tipo de situaciones. El tiempo de diferencia puede variar de varios minutos,
horas o das. Para poder soportar transacciones asncronas, 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 ubicacin de los administradores de recursos involucrados en la
transaccin conectados a travs de la red, las transacciones pueden ser locales
o distribuidas.
La transaccin ser local cuando los administradores de recursos involucrados
en cada una de las acciones estn en el mismo nodo o computadora.
111

La transaccin ser distribuida cuando los administradores de recursos
involucrados en las acciones de sta estn en nodos o computadoras distintas y
se comunican a travs de la red.
Reiterando, una transaccin trabajar en un ambiente de ejecucin que le

proporcione las propiedades cidas en forma transparente y automtica. Esto
brinda o proporciona la simplicidad en la programacin. El cdigo creado
manejando transacciones en la capa de negocios es muy simple bajo este
contexto.
Las transacciones sncronas son las ms comunes y deseadas en el manejo de
transacciones.
112
Como se ha visto en el modelo de aplicacin, la capa o servicios de negocio

solicitan las operaciones con los datos a la capa o servicios de datos; esta
situacin genera una pregunta interesante: Si la capa de negocio coordina la
transaccin entre los componentes que pueden estar en el mismo nodo o nodos
diferentes Cmo se controla la transaccin en la capa de negocio en
coordinacin con los diferentes nodos involucrados en la capa de datos?
En forma bsica puede controlarse una transaccin a partir de un componente u
objeto el cual solicita una transaccin a un DBMS o Sistema Manejador de Base
de Datos. El mecanismo de intercambio de informacin se realiza a travs del
envo y recepcin de mensajes de requerimiento (request) y respuesta
(response). Para dar inicio a la transaccin se enva un mensaje al DBMS de
inicio de transaccin, y posteriormente segn el caso, se enva el mensaje para
confirmar la transaccin (commit) o revertirla (rollback).
Por otro lado, puede efectuarse una transaccin distribuida a travs de los
mecanismos que ofrecen manejadores de bases de datos distribuidas; sin
embargo, este esquema excluye la participacin de objetos por lo tanto el
modelo de aplicacin que divide la aplicacin en capas. Ciertamente se efecta
la transaccin distribuida pero nicamente a nivel de los manejadores de bases
de datos.
113
Por lo exp uesto anteriormente, el control de la transaccin debe efectuarse en la

capa de negocio.
La accin ms recurrente o comn en una transaccin es solicitar operaciones a
un manejador de bases de datos.
Si existiese un componente en la capa de negocio que solicita una informacin,
ste se constituye en cliente; y si tuviramos otro componente en la capa de
datos constituido en servidor que proporciona esta informacin comunicndose
con el DBMS bajo el contexto de una transaccin tendramos un procesamiento
de transacciones en lnea; el cual, puede llevarse a cabo de dos formas:
TP-Lite: Procesamiento ligero de transacciones realizado a travs de

procedimientos o funciones de un API de un proveedor especfico
TP-Heavy: Procesamiento robusto de transacciones llevado a cabo por un
TP Monitor o monitor de procesamiento de transacciones.
114
Un TP monitor es un software especializado para administrar transacciones. En

sus orgenes, slo controlaban las transacciones en la capa de datos.
Actualmente, es una funcin fundamental el administrar la transaccin desde la
capa de negocio. Otra de sus caractersticas es controlar la transaccin en forma
DISTRIBUIDA. Los TP monitors son capaces de controlar la transacciones, la
ruta de transacciones a travs de todo el sistema, balancear la carga para su
ejecucin y restaurar las condiciones del sistema en caso de fallas.
Dada la naturaleza de las aplicaciones cliente/servidor o distribuidas de

conformarse a travs de un conjunto de objetos comunicndose entre s, y
utilizar un elemento del middleware denominado ORB para lograr esta
comunicacin.
115

Los objetos pueden disponerse en un nodo y constituirse como servidor de
objetos de aplicacin. 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 aplicacin. 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 ms sencilla una aplicacin C/S garantizando
116

en forma transparente y automtica las propiedades cidas; est optimizada de
tal forma que su diseo debe brindar un alto rendimiento.
Retomando la pregunta planteada en prrafos anteriores: Cmo se controla la

transaccin en la capa de negocio en coordinacin 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 estndar de comunicacin entre elementos involucrados en
transacciones distribuidas creados por una organizacin llamada XOpen, el
estndar se llama XA, por lo que el estndar se conoce como XOpen/XA.
117
Los elementos involucrados en transacciones distribuidas son:

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

proporcionan servicios para ejecutar las acciones de una transaccin. Los
administradores de recursos ms comunes son DBMSs.
3. El Administrador de Transacciones (TP Monitor comnmente) es quien

coordina el flujo de informacin y control de la transaccin.
118
4. Administrador de Comunicaciones que satisface los requerimientos de

enlace y control entre los administradores de recursos involucrados en la
transaccin.
En trminos generales, como el control de la transaccin debe efectuarse en la

capa de negocio; de no existir un monitor de transacciones, el programador
tendra que programar toda la comunicacin de informacin 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
comunicacin con los administradores de recursos, ofreciendo sus servicios a
travs de un API de objetos para que sea utilizado por el programa cliente. El
119

TP Monitor se comunicar a travs 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 informacin.
El flujo de informacin y control parte del programa de aplicacin cliente. El cual
indica el inicio de transaccin a travs del API que se comunica con el TP
Monitor.
Cada accin que tenga que ver con un administrador de recursos se controla en
el TP Monitor, la cual se controla y direcciona a travs de XOpen/XA. Cuando la
aplicacin cliente indica la confirmacin (commit) o reversin (rollback) el TP
Monitor coordina la ejecucin o reversin en los administradores de recursos
involucrados.
3.2.1. Compromiso de 2 Fases (2-Phase Commit)
Dada la naturaleza de la participacin de administradores de recursos

distribuidos a travs de la red, donde cada uno tambin ofrece el control de la
transaccin local, que en suma darn la transaccin distribuida; la operacin de
confirmacin (COMMIT) tambin se complica. De hecho, surge el concepto de
Commit de 2 Fases (a veces traducido como compromiso o confirmacin de 2
fases).
A partir de 1980, cada vez ms fue requerido los procesos de commit y rollback
en los administradores de bases de datos. Al finales de los 80s, el requerimiento
de transaccin trascendi a ser distribuido con el objetivo de brindar integridad y
consistencia en la informacin.
120
De tal forma surge el Commit de 2 Fases, buscando la confirmacin de la

transaccin distribuida con la sincronizacin 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 Preparacin, el nodo que inicia la transaccin

se convierte en el agente coordinador de la transaccin, o tambin, se le
denomina coordinador global. Todos los administradores de recursos van abren
una transaccin local aplicando las acciones solicitadas; quedando pendiente la
confirmacin hasta que se concluyan todas las acciones involucradas en la
transaccin.
121
En la segunda fase, ya una vez recibida la ejecucin de las acciones por los
administradores de recursos quedando pendiente la confirmacin local en cada
uno. Se manda la orden de confirmacin en todos los administradores de
recursos para que confirmen. Si un administrador de recursos provoca un error,
el administrador de transacciones manda la seal de reversin a los
administradores de recursos que anteriormente haban tenido xito, cada uno de
estos revierten su transaccin local.
Todo el proceso de administracin de transaccin distribuida es transparente y

automtico, para ello se emplean Tablas de Transacciones Pendientes y
Bitcoras (logs).
122
Actualmente muchos productos ofrecen el control transaccional y el soporte al

commit de 2 fases. Lo esperado es que haya transparencia en la aplicacin,
pero algunos productos slo permiten la programacin especfica, reduciendo en
forma importante la transparencia y automatizacin en la administracin de
transacciones.
Actualmente se considera madura la tecnologa de administracin de

transacciones distribuidas. Al grado de utilizarse en aplicaciones crticas de
negocio como de tipo financiero, bancarios, etc.
123
Entre algunas de las limitaciones de la administracin 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 diseo de origen basado
en un API de programacin estructurada.
3.3. CORBA
CORBA
Escenario
124
Qu es CORBA?
CORBA es un middeware o marco de trabajo estndar y abierto de

objetos distribuidos que permite a los componentes en la red nter
operar en un ambiente comn sin importar el lenguaje de desarrollo,
sistema operacional, tipo de red, etc.
En esta arquitectura, los mtodos de un objeto remoto pueden ser
invocados de forma transparente en un ambiente distribuido y
heterogneo a travs de un ORB (Object Request Broker).
Adems del objetivo bsico de ejecutar simplemente mtodos en
objetos remotos, CORBA adiciona un conjunto de servicios que
amplan las potencialidades de stos objetos y conforman una
infraestructura slida para el desarrollo de aplicaciones crticas de
negocio.
Arquitectura General de CORBA
125
Organizacin General de un Sistema

de CORBA
Proceso del Cliente
Proceso del Servidor
Referencia
del Objeto
Implementacin
del Objeto
IDL
DII
Stubs
IDL
Skeleton
ORB
Interface
E DSI
Object Adapter
ORB
IIOP (Internet Inter ORB Protocol)
Descripcin de elementos
ORB: Provee un mecanismo de interfaz y de comunicacin transparente

entre la referencia de un objeto y su implementacin. Ofrece los
servicios de localizacin, establecimiento de la conexin y la transmisin
de llamadas de mtodos y valores de retorno.
IIOP: Protocolo para la comunicacin entre ORBs a travs de TCP/IP. El
ORB se comunica a travs de IIOP sin intervencin 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 implementacin de tiempo de ejecucin de
las siguientes responsabilidades:
o Generar e interpretar referencias de objetos.
o Invocar mtodos.
o Garantizar la seguridad de las aplicaciones.
o Activar y desactivar objetos.
o Enlazar las referencias de objetos con las implementaciones.
126
Descripcin de elementos
o Registrar las implementaciones de objetos.
DII (Dynamic Invocation Interface): El DII permite al cliente aprender en

tiempo de ejecucin 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 ejecucin, sin
intervencin 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 Mtodos Remotos
o Usando los Parmetros Out e Inout
Servidor CORBA
o Skeleton del IDL del Servidor
o Implementacin de Objetos CORBA
o Objetos CORBA y el Servicio de Nombres
o Esperando por la Invocacin
o Usando los Parmetros In e Inout.
127
Escenario CORBA
Mediante la tcnica de Estudio de Caso, los alumnos realizarn en equipo las
actividades siguientes:
Investigar de forma individual el funcionamiento de CORBA.

o Su relacin con los lenguajes de programacin.
o Ejercitar con un ejemplo de implementacin.
Discutir en equipo las investigaciones individuales.
o General reporte de discusin.
Actividad 3.3
Estudio de Caso CORBA (Escenario CORBA)
Realizar investigacin 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.
128
Rbrica para evaluacin de tareas del proceso de EC
Atributos
Arriba del
Estndar
En el
Estndar
Debajo del
Estndar
Puntos de
Atributo
Obtenidos
(5 -4.5)
(4 -3.5)
(3-0)
Sus
Participacin,
Sus
intervenciones
pero sus
intervenciones mostraron
intervenciones
mostraron
relacin con
no estaban
bastante
el escenario,
Definicin del
relacionadas
relacin 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
informacin
informacin
informacin
revisada
revisada
revisada no
permiti a los permiti a los
Aplicacin de la
permiti a los
estudiantes
estudiantes
Informacin
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 aportacin
Hizo
Hizo pocas
fue
bastantes
determinante aportaciones, aportaciones
para la
pero le falto y sin relacin
Solucin/explicacin
elaboracin aterrizarlas en
con las
del problema
del reporte
propuestas
posibles
final de la
concretas de soluciones del
solucin del
solucin al
problema.
problema.
problema.
129

3.3 CORBA
3.3.1 Introduccin
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 interconexin de
objetos. Los servicios de interoperabilidad e interconexin son normalmente
conocidos como servicios middleware.
Servicios Middleware
Para resolver los problemas inherentes a sistemas heterogneos y distribuidos,
que dificultan la implementacin de verdaderas aplicaciones empresariales, los
proveedores de software estn ofreciendo interfaces de programacin y
protocolos estndares. 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 propsito 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
APIs 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 APIs 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 especficas por
cuatro importantes propiedades:
Son independientes de las aplicaciones y de las industrias para las que

stas se desarrollan.
Se pueden ejecutar en mltiples plataformas.
Se encuentran distribuidos.
Soportan interfaces y protocolos estndar.
CORBA es el estndar propuesto por el OMG. EL OMG fue fundado en 1989 y

es el ms grande consorcio de industrias de la actualidad, con ms de 700
compaas. Opera como una organizacin no comercial sin fines de lucro, cuyo
130

objetivo es lograr establecer todos los estndares 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: cmo lograr que sistemas distribuidos orientados a objetos
implementados en diferentes lenguajes y ejecutndose en diferentes plataformas
interacten entre ellos. Ms all de los problemas planteados por la computacin
distribuida, problemas ms simples como la falta de comunicacin entre dos
sistemas generados por compiladores de C++ distintos que corren en la misma
plataforma frenaron los esfuerzos de integracin no bien comenzados. Para
opacar an ms el escenario, distintos lenguajes de programacin ofrecen
modelos de objetos distintos. Los primeros aos de la OMG estuvieron
dedicados a resolver los principales problemas de cableado. Como resultado se
obtuvo la primera versin del Common Object Request Broker, publicado en
1991. Hoy en da, el ltimo estndar aprobado de CORBA est por la versin
2.3, y la versin 3.0 est a punto de ser lanzada.
Desde sus principios, el objetivo de CORBA fue permitir la interconexin 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
estndares 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 invocacin, el ORB (object request broker) y un conjunto de adaptadores de
objetos (objects adapters). CORBA va ms all de simples servicios
middleware, provee una i nfraestructura para construir aplicaciones orientadas a
objetos. Las interfaces definen los servicios que prestan los objetos, el ORB se
encarga de la localizacin e invocacin de los mtodos sobre los objetos y el
object adapter es quien liga la implementacin del objeto con el ORB.
Para que las interfaces de invocacin 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 comn. 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 programacin y el
lenguaje comn. La primera condicin permite generalizar los mecanismos de
pasaje de parmetros (marshaling y unmarshaling). La segunda permite
relacionar llamadas de o a un lenguaje en particular con el lenguaje de
especificacin comn. Este lenguaje comn fue una parte esencial de CORBA
131

desde sus orgenes 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
facilitara la reutilidad de software. En esta seccin se hace una breve
introduccin 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
composicin con interfaces contractuales especificadas y dependencias de
contexto explcitas. Un componente de software puede ser desarrollado
independientemente y utilizado por terceras partes para integrarlo mediante
composicin a sus sistemas. Los componentes son para crear software
utilizando composicin, por eso es esencial que sean independientes y que se
presenten en formato binario, permitiendo as distintos vendedores e integracin
robusta.
Para que un componente pueda ser integrado por terceras partes en sus
sistemas, ste deber ser suficientemente auto contenido y debe proveer una
especificacin de lo que requiere y provee. En otras palabras, los componentes
deben encapsular su implementacin e interactuar con otros componentes a
travs 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 dinmica que usualmente cobra vida a travs 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
caractersticas de encapsulamiento y polimorfismo, facilitan la construccin e
integracin de componentes.
Y al hablar de objetos vale la pena distinguir aqu los objetos de las clases. Una
clase es una definicin 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 ms clases y sern los clientes de los componentes
quienes soliciten la creacin de las instancias de estas clases.
Pero tomando el lugar del programador que debe integrar el componente a su
aplicacin, surgen algunas incgnitas que debera resolver. El fabricante del
132

componente solamente ha entregado un archivo ejecutable que se debe iniciar
en la mquina en la que se ejecuta la aplicacin y la interfaz definida en un
lenguaje de definicin de interfaces (IDL, Interface Definition Language)
estndar. El programador desea ahora:
Mapear la interfaz: Cmo hace el programador para mapear las clases

que el componente provee al lenguaje en que realizar su
implementacin final? Seguramente el lenguaje de programacin elegido
provee mecanismos para definir clases, pero es necesario que la
definicin que se haga de la clase en ese lenguaje corresponda a la
definicin que dio el fabricante del componente.
Crear objetos: Cmo 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 Cmo se logra acceder a sus propiedades o mtodos?
Transparencia: El componente sera de poca utilidad si su utilizacin 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 an si el componente es remoto, un servicio de
llamada remota a procedimientos (RPC), est claro que dejara el
componente de lado pues es ms trabajo utilizarlo que hacer un programa
desde cero.
Estas son slo 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 utilizacin 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 estndar y abierto de objetos
distribuidos que permite a los componentes en la red nter operar en un
ambiente comn sin importar el lenguaje de desarrollo, sistema operacional, tipo
de red, etc. En esta arquitectura, los mtodos de un objeto remoto pueden ser
invocados transparentemente en un ambiente distribuido y heterogneo a
travs de un ORB (Object Request Broker). Adems del objetivo bsico de
ejecutar simplemente mtodos en objetos remotos, CORBA adiciona un conjunto
de servicios que amplan las potencialidades de stos objetos y conforman una
infraestructura slida para el desarrollo de aplicaciones crticas de negocio.
CORBA es la respuesta del Grupo de Gestin de Objetos (Object
Management Group OMG) a la necesidad de interoperabilidad ante la gran
proliferacin de productos hardware y software. CORBA permite a una
133

aplicacin comunicarse con otra sin importar el tipo de red, protocolo, sistema
operacional o lenguaje de desarrollo.
CORBA automatiza muchas tareas comunes y pesadas de programacin de
redes tales como registro, localizacin y activacin de objetos; manejo de
errores y excepciones; codificacin y decodificacin de parmetros, y protocolo
de transmisin.
En un ambiente CORBA, cada Implementacin de Objeto, define bien su Interfaz
a travs una especificacin normalizada conocida como IDL (Interface
Definition Language) a travs de la cual en forma Esttica (en el momento de
compilacin) o en forma Dinmica (en el momento de ejecucin) un Cliente que
requiera el servicio de una Implementacin de Objeto, puede ser ejecutada. Las
invocaciones a mtodos remotos son enviadas por los clientes llamando objetos
locales llamados Stubs (generados por un compilador de IDL - Esttico), el
cual intercepta dichas invocaciones y contina el proceso de llevar y retornar
automticamente dicha invocacin. La Implementacin del objeto, no tiene que
conocer el mecanismo por el cual un Cliente le ha invocado un servicio.
Cuando el Cliente y una Implementacin de Objeto estn distribuidos por una
red, usan el protocolo GIOP/IIOP suministrado por la arquitectura para lograr la
comunicacin.
La forma en cmo una Implementacin de Objeto (desarrollada por un
programador de aplicaciones) se conecta a un ORB, es a travs de un
Adaptador de Objetos. Este adaptador recibe las peticiones por la red e invoca
los servicios a la implementacin correspondiente.
Actualmente CORBA ya ha resuelto los problemas fundamentales de
interoperabilidad y comunicacin entre objetos y se han definido y especificado
un conjunto de servicios comunes requeridos para la construccin de las
aplicaciones, pero donde hay gran actividad es en la especificacin de objetos
comunes por dominio de aplicacin 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 caractersticas de Orientacin por Objetos como Tipos de
Datos, Abstraccin, 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 compaas, en octubre de 1989, la
OMG comenz operaciones independientes como una entidad sin nimo de
lucro. A travs de sus comits, la OMG desarrolla especificaciones
134

independientes de cualquier proveedor para la industria del software.
Actualmente el consorcio tiene ms de 800 miembros. La OMG se esta
moviendo a establecer a CORBA como el Middleware que esta en todas
partes a travs de sus especificaciones CORBA/IIOP, Servicios de Objetos,
Facilidades de Internet y Especificaciones de Dominio, entre otras.
La misin de la OMG es crear un mercado de software basados en
componentes introduciendo las tecnologas de objetos. Establecer guas y
especificaciones para proveer un marco comn para el desarrollo de
aplicaciones. Conforme a estas especificaciones, ser posible desarrollar en
ambientes heterogneos a travs de la gran variedad de productos hardware y
software existente.
La OMG define la administracin de objetos como el desarrollo de software que
modela el mundo real a travs de la representacin de objetos. Estos objetos
son la encapsulacin de los atributos, relaciones y mtodos de software
identificables como compo nentes de un programa. La administracin de objetos
facilita el desarrollo rpido de aplicaciones, facilidad de mantenimiento,
escalabilidad y reutilidad del software.
La OMG esta estructurado en tres grandes cuerpos: el Comit de Plataforma
Tecnolgica (Platform Technology Committee - PTC), el Comit de Dominio
Tecnolgico (Domain Technology Committee - DTC) y la Junta de Arquitectura
(Architecture Board). Dentro de los Comits Tcnicos y Junta de Arquitectura,
trabajan las Fuerzas de Trabajo, Grupos de Inters Especial y Grupos de
Trabajo quienes llevan a cabo los procesos de adopcin tecnolgica de la OMG.
3.3.4 Object Management Architecture - OMA
Una de las metas principales de la arquitectura OMA, es introducir las
tecnologas orientadas a objetos como soporte a la nueva generacin de
aplicaciones y sistemas distribuidos, por ello, un esquema de administracin de
objetos representa los siguientes beneficios:
Interfaces de usuario orientadas a objetos.
Funcionalidades comunes en diferentes aplicaciones, tal como almacenamiento
y recuperacin de objetos, correo de objetos, impresin, creacin y borrado de
objetos.
Compartir informacin, desde el punto de vista de acceso mltiple a travs de
aplicaciones.
La transicin 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
135

Provee una representacin organizada de los conceptos y terminologa de
objetos. El modelo de la OMG es abstracto en el sentido que directamente no
realiza una tecnologa particular, el modelo descrito aqu es un modelo de
objetos concreto.
Un sistema de objetos es una coleccin de objetos que aslan las peticiones de
servicios (cli entes) de la provisin de los servicios por el encapsulamiento de las
interfaces.
El modelo de objetos es un ejemplo del modelo clsico de objetos, donde un
cliente enva un mensaje a un objeto. Conceptualmente, el objeto interpreta el
mensaje para decidir que servicio ejecutar. En este modelo, la seleccin de
mtodos es ejecutada por el objeto o por el ORB.
Semntica 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
ms servicios que pueden ser requeridos por un cliente.
Requerimientos: los clientes solicitan un servicio enviando un requerimiento. Un
requerimiento es un evento. La informacin asociada a este evento consiste en
una operacin, objeto destino, cero o ms parmetros y contextos opcionales del
requerimiento.
Creacin y Destruccin de Objetos
Aunque los objetos pueden ser creados o destruidos, desde el punto de vista del
cliente no existen mecanismos especiales para la creacin o destruccin.
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 bsicos: Enteros de 16 y 32 bits con y sin signo, nmeros IEEE de

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

opaco de 8 bits, enumerados, string de longitud variable y tipo any el
cual representa cualquier posible tipo bsico o construido.
Tipos complejos: estructuras, uniones, secuencias, arreglos, interfaces,

etc.
Interfaces
Una Interfaz es una descripcin 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 mltiples Interfaces. La Interfaz principal es simplemente la
Interfaz ms especifica que el objeto soporta y consiste en todas la operaciones
en la transitive closure del grafo de herencia de Interfaz.
Operaciones
Una Operacin es una entidad identificable que denota un servicio que puede
ser requerido. Una operacin es identificada por un identificador de operacin y
tiene una firma que describe los valores legtimos de los parmetros requeridos
y resultados retornados.
Las excepciones son una indicacin que un requerimiento de operacin no ha
ejecutado exitosamente.
Un contexto de requerimiento provee informacin adicional y especifica de la
operacin que puede afectar el rendimiento de un requerimiento.
Semntica de ejecucin
Dos estilos de semntica de ejecucin son definidos para el modelo de objeto:
Al menos una vez: si un requerimiento de operacin retorna

exitosamente, este fue ejecutado exactamente una sola vez, si este
retorna una indicacin de excepcin, este fue ejecutado al menos una
vez.
137
Mejor esfuerzo: una operacin de mejor esfuerzo es una operacin de

requerimiento nico, este no puede retornar cualquier resultado y el
solicitante nunca se sincroniza con la terminacin.
Atributos
Una Interfaz puede tener atributos. Un atributo puede ser slo lectura o lecturaescritura.
Implementacin de objetos
El modelo de implementacin consiste en dos partes: el modelo de ejecucin y
el modelo de construccin. El modelo de ejecucin describe como los servicios
son ejecutados y el modelo de construccin describe como los servicios son
definidos.
Modelo de ejecucin: el servicio requerido es ejecutado en un sistema

computacional por ejecucin de un cdigo que opera sobre los mismos
datos. El cdigo que es ejecutado para realizar un servicio es llamado
mtodo. Un mtodo es una descripcin inmutable de una computacin
que puede ser interpretada por el motor de ejecucin. Un mtodo tiene
unos atributos inmutables llamados "formato de mtodo" que define el
conjunto de mquinas de ejecucin que pueden interpretar el mtodo. Un
motor de ejecucin es una mquina abstracta (no un programa) que
puede interpretar mtodos en ciertos formatos, causando que las
computaciones descritas sean realizadas. Un motor de ejecucin define
un contexto dinmico para la ejecucin de un mtodo. La ejecucin de un
mtodo es llamada "activacin de mtodo".
Modelo de construccin: una implementacin de objeto o implementacin

es una definicin que provee la informacin necesaria para crear un
objeto y permitir al objeto participar en proveer un apropiado conjunto de
servicios. Una implementacin tpicamente incluye, entre otras cosas, la
definicin de los mtodos que operar sobre el estado de un objeto.
tambin incluye informacin acerca de los tipos intended del objeto.
Elementos de OMA
Object Request Broker ORB: representa el medio o bus de objetos a

travs del cual se comunican todos los objetos participantes en el
sistema. El ORB es el corazn de comunicaciones del estndar. Este es
referido comercialmente como CORBA. Este provee una infraestructura
que permite a objetos comunicarse, independiente de la plataforma
especifica y tcnicas usadas para implementar el objeto direccionado. El
138

ORB garantiza portabilidad e interoperabilidad de objetos sobre una red
de sistemas heterogneos.
Objetos de Servicio CORBAServices, son un conjunto de objetos

genricos, 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 estndares dentro de un dominio o mercado de
aplicacin, se cuentan con dominios como: Telecomunicaciones,
Finanzas, Comercio Electrnico, Medicina, Transportes, Transportes, etc.
Facilidades Comunes CORBAFacilities, conjunto de objetos

orientados hacia las aplicaciones de usuario final como Administracin de
Datos, Aplicaciones, Interfaces de Usuario, etc.
Objetos de Aplicacin: 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 mtodo sobre un objeto remoto. El ORB
intercepta la llamada y es responsable de encontrar el objeto que implementa el
requerimiento, pasar los parmetros, invocar el mtodo 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
139

provee la interoperabilidad entre aplicaciones sobre diferentes mquinas en un
ambiente heterogneo distribuido.
En el esquema actual de aplicaciones cliente/servidor, los desarrolladores usan
su propio diseo o un estndar para definir el protocolo a ser usado entre los
dispositivos. La definicin de ese protocolo depende del lenguaje de
implementacin, transporte de red y otros factores. Un ORB simplifica este
proceso, por ejemplo el protocolo es definido a travs de una especificacin de
las Interfaces conocida como IDL. Una vez se tiene claro las Interfaces, el
lenguaje de implementacin o sistemas operacionales y de red, ya no es
relevante.
La especificacin IDL de OMG provee una forma estndar de definir las
Interfaces a los objetos CORBA. La definicin IDL es una especie de contrato
entre el desarrollador de un objeto y el cliente. IDL es independiente del
lenguajes de programacin y se mapea a los lenguajes ms tpicos para
desarrollar, actualmente se encuentra generacin de cdigo a C, C++,
SmallTalk, Java, Ada, COBOL, etc.
Ms importante an, una solucin basada en ORB, permite integrar aplicaciones
existentes, simplemente describiendo sus Interfaces en IDL y escribiendo los
"wrappers" que traslada entre el bus esta ndarizado y las Interfaces existentes.
Lo que permite en el ORB la interoperabilidad e independencia de muchos
factores, es la definicin de los objetos en un lenguaje de especificacin
totalmente independiente del lenguaje de implementacin, este lenguaje se
conoce como Interface Definition Language (IDL)
Elementos de un ORB
Implementacin del Objeto: realizado por el programador. Implementa las
operaciones especificadas en la definicin IDL. La implementacin puede ser
escrita en una variedad de lenguajes como C, C++, Java, SmallTalk, Ada, etc.
Cliente: entidad que invoca una operacin en una Implementacin de Objeto
remoto. De igual forma puede ser desarrollado en varios lenguajes y es
realizado por un programador de aplicaciones.
Ncleo 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
l respuesta, la
cual es retornada al Cliente.
140

Interfaz ORB : ofrece varias funciones de ayuda, tales como conversin de
referencia de objetos a texto y viceversa, creacin de lista de argumentos para
invocacin DII, entre otras.
Stubs y Skeleton IDL: Los stubs y skeleton sirven como pegante entre el
cliente y servidor respectivamente y el ORB. Son estticos y generados en
tiempo de compilacin por un compilador IDL el cual transforma las Interfaces
IDL hacia el lenguaje de desarrollo, esto reduce las posibilidades de errores al
generar automticamente los stubs y skeleton.
Interfaz de Invocacin Dinmica (DII): esta Interfaz permite a un cliente construir
dinmicamente un requerimiento sin tener un stub, lo cual significa que los
requerimientos son construidos en tiempo de ejecucin. Otra ventaja de este
esquema es permitir llamadas sincrnicas de no bloqueo (deferred) y llamadas
asincrnicas de una sola va (oneway)
Interfaz Skeleton Dinmica (DSI): cumple las mismas funciones de DII pero en
el lado del servidor. Permite que el ORB realice llamadas a una Implementacin
de Objeto del cual no se tiene conocimiento de la Interfaz.
Adaptador de Objetos: este mdulo asiste al ORB con la entrega de
requerimientos a los objetos y con la activacin de objetos de acuerdo a varias
polticas. Un adaptador de objetos asocia una implementacin 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.
141

Un ORB no tiene que ser implementado como un componente nico. Las
Interfaces que ofrecen los ORB estn organizadas en 3 categoras:
Operaciones para todas las implementaciones de ORB
Operaciones especificas a tipos particulares de Objetos
Operaciones especificas a estilos particulares de implementacin de objetos.
El ncleo del ORB es el componente que provee la representacin bsica de
objetos y la comunicacin de requerimientos.
Un cliente tiene acceso al objeto a travs 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, libreras, un programa por mtodo, una
aplicacin encapsulada, una base de datos orientada a objetos, etc.
Referencias de Objeto
Es la informacin necesaria para especificar un objeto dentro de un ORB. Tanto
los clientes como las implementaciones del objeto tienen una nocin opaca de
la referencia de objeto de acuerdo al lenguaje de mapeo y as aislar la
representacin real de estos.
Dos ORB pueden diferir en la eleccin de la representacin de las Referencias
de Objeto.
Lenguaje de especificacin 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 programacin o sistemas de objetos.
Este lenguaje de mapeo tambin define la interaccin entre la invocacin de los
objetos y los hilos de control en el cliente o implementacin.
El lenguaje de mapeo provee llamadas sincrnicas, es decir, no retorna hasta
que se termine de ejecutar el mtodo en la implementacin del objeto.
Adaptador de objeto
Es la forma principal para acceder los servicios de una implementacin de objeto
provistos por el ORB.
142
Los servicios provistos por el ORB a travs de un Adaptador de Objetos incluye:

generacin e interpretacin de referencia de objetos, invocacin de mtodos,
seguridad de interacciones, activacin/desactivacin de objetos e
implementaciones, mapeo de referencias de objeto a implementaciones y
registro de implementaciones.
Un adaptador de objetos exporta una interfaz pblica a la implementacin del
objeto y una privada al skeleton.
Es responsable de las siguientes funciones:
Generacin e interpretacin de referencias de objetos

Invocacin de mtodos
Seguridad de interacciones
Activacin/desactivacin 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 especificacin 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: mtodo, objeto y compartido para todas las
instancias del tipo de objeto. Si la implementacin no esta activa, el BOA
comienza una.
Library Object Adapter: es utilizado por los objetos que tienen
implementaciones de libreras. Este accede el almacenamiento persistente en
archivos y no soporta activacin o autenticacin, ya que los objetos se asume
que estn en los clientes.
Object-Oriented Database Adapter: usa una conexin a una OODB para
proveer acceso a los objetos almacenados. Los objetos pueden ser registrados
implcitamente.
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 travs del adaptador de objetos, stubs, skeleton o invocacin
dinmica; quedan pocas operaciones comunes a travs de todos los objetos.
Repositorio de Interfaces
143
Es un servicio que provee objetos persistentes que representan la informacin

IDL en forma disponible en tiempo de ejecucin. Tambin el IR es un lugar
comn para almacenar informacin adicional asociada con Interfaces al ORB.
(ej: debug, libreras de stubs/skeleton, etc.).
Repositorio de implementacin
Contiene informacin que permite al ORB localizar y activar implementaciones
de objetos, aunque esta informacin es muy dependiente de la implementacin
del ORB o del ambiente operativo.
Ejemplos de implementaciones de ORB
Cliente e Implementacin 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 localizacin de un servicio. El cdigo enlazado
con las implementaciones es responsable de configurar las bases de datos
apropiadas para uso de los clientes
ORB basado en Servidor: administracin centralizada. Todos los clientes e
implementaciones pueden comunicarse con uno o ms servidores cuya funcin
es enrutar los requerimientos de clientes a implementaciones. Se utilizan IPC
para comunicacin 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 estn en la
misma mquina.
ORB basado en librera: para objetos que son de peso liviano y cuyas
implementaciones pueden ser compartidas, la implementacin del ORB podra
ser en una librera. En este caso, los stubs pueden ser los mtodos reales. Esto
asume, que es posible para un cliente tener acceso a los datos para los objetos
y que la implementacin confa en que el cliente no daara los datos.
3.3.6 CORBA Services
OMA esta construida sobre un fundamento y arquitectura CORBA que desarrolla
la visin de la OMG de componentes de software plug-and-play.
Los CORBA Services especifican servicios bsicos casi todos los objetos
necesitan.
144

Para cada componente de OMA, la OMG provee una especificacin formal
descrita en OMG IDL (como invocar cada operacin dentro de un objeto) y su
semntica en lenguaje ingls (que hace cada operacin y las reglas de
comportamiento). Un proveedor no tiene que suministrar obligatoriamente
ningn servicio adicional al ORB, pero si este lo ofrece, deber esta de acuerdo
a la especificacin que para este servicio tiene la OMG.
Los CORBA Services proveen servicios a nivel de aplicacin 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
Trader
Notificacin
Eventos
Transacciones
Seguridad
Ciclo de vida
Propiedades
Persistencia
Consulta
Relaciones
Concurrencia
Externalizacin
Licenciamiento
Tiempo
Coleccin
De stos 15 se destacan los siguientes servicios clave:
Acceso a referencias de objetos a travs de la red, soportada por el

servicio de Nombres y de Trader.
Notificacin de eventos importantes o cambios de estado en un objeto,
soportado por el servicio de Eventos y de Notificacin.
Soporte para semntica 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, bsicamente es un servicio de localizacin que asocia identificadores
a manejadores que proveen una forma de contactar el componente deseado en
un sistema distribuidos. Este asocia nombres - organizados jerrquicamente - a
objetos.
Ciclo de vida: bsicamente es un servicio de configuracin, define servicios y
convenciones para crear, borrar, copiar y mover componentes en un sistema
distribuido.
Eventos: implementa un modelo de comunicacin desacoplado, basado en el
paradigma publicacin/suscripcin. En este modelo, uno o ms publicadores
pueden enviar mensajes relacionados con un tpico especfico, mientras que un
grupo de suscriptores reciben los mensajes asincrnicamente. Con estos
145

mecanismos, los publicadores pueden generar evento sin tener que conocer la
identificacin 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 comunicacin, en el modelo Pull, los suscriptores requieren eventos de
los publicadores.
Transacciones: gestiona interacciones entre objetos distribuidos estableciendo
puntos de Commit y delimitacin de transacciones. Este servicio soporta varios
modelos y permite interoperabilidad entre diferentes arquitecturas de red y
modelos de programacin.
Seguridad: controla la identificacin de los elementos del sistema distribuido
(usuarios, objetos, componentes, etc) que permite verificar que un cliente esta
autorizado a acceder los servicios de una implementacin remota.
Adicionalmente permite la comunicacin segura sobre enlaces de comunicacin
inseguros, ofreciendo confidencialidad e integridad de la informacin transmitida.
Tiempo: suministra informacin del tiempo y permite la definicin de llamadas
peridicas.
Licenciamiento: controla la utilizacin de objetos especficos, inhibiendo uso
inadecuado de derechos y propiedad intelectual.
Propiedades: provee la habilidad de dinmicamente asociar propiedades a los
objetos los cuales pueden ser consultados o modificados por otros elementos.
Relaciones: permite la definicin del papel ejecutado por objetos CORBA en una
relacin.
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 coordinacin de mltiples accesos a recursos
compartidos a travs de la provisin de varios modelos de locks y permite
resolucin flexible de conflictos.
Externalizacin: define convenciones y protocolos para representar el estado de
informacin relacionado a un objeto en la forma de una secuencia de datos,
permitiendo a esta informacin ser almacenada o transferida a otras
localizaciones.
3.3.7 CORBA Facilities Horizontales
146

Las facilidades CORBA tanto horizontales como verticales, son diseadas para
completar la arquitectura entre los Servicios bsicos de CORBA y las
aplicaciones especficas de industria. Con una arquitectura completa, las
compaas compartirn datos a nivel de aplicacin y funcionalidades para la
integracin de diferentes sistemas de informacin. Las facilidades representan
un punto medio entre una aplicacin particular y los servicios y ORB.
La OMG ha definido como Facilidades Horizontales las siguientes:
Interfaz de usuario
Administracin de informacin
Administracin de sistemas
Administracin de tareas
Hoy en da estas especificaciones han sido adheridas a ORBOS (ORB y

Servicios) y ya no estn como un grupo aparte.
Especficamente a nivel de facilidades verticales la OMG ha definido
siguientes:
las
Especificacin para la administracin de sistemas XCMF.

Facilidad para colar de impresin.
3.3.8 CORBA Facilities Verticales o de Dominio
La potencialidad que representa el lenguaje IDL para la especificacin de un
objeto u componente ha permitido trabajar en la normalizacin de intereses
comunes para un sector de mercado particular y que una vez se llegue a un
acuerdo en cuanto a estas especificaciones, sera estndar 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 evalan y recomiendan especificaciones candidatas. Basados
en las recomendaciones de los DTF, el DTC conduce un proceso formal de
votacin 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 especificacin
oficial. Actualmente hay 8 DTF:
Objetos de negocio
Finanzas y seguros
Comercio Electrnico
Manufactura
Salud o Medicina
147
Telecomunicaciones
Transportes
Investigacin de ciencias de la vida
Tambin bajo la OMG pero que no tienen DTF se encuentran dos Grupos de
Inters Especial:
Utilities (principalmente energa elctrica)

Estadstica
Seis especificaciones ya han sido adoptadas oficialmente como estndares de

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

Un conjunto de Habilitadores para la administracin de datos de
productos, del DTF de manufactura.
Servicio de Identificacin de Personas (PIDS) de CORBAMed
Servicio de Consulta Lexicon de CORBAMed
Control y Administracin de flujos de Audio/Vdeo, del DTF de
telecomunicaciones.
Servicio de Notificacin, del DTF de Telecomunicaciones.
3.3.9 Nuevas especificaciones de CORBA

Despus que fue completada y normalizada la versin 2.0 en 1996, la OMG
continuo trabajando en la incorporacin de aspectos importantes que deben ser
tenidos en cuenta en un sistema distribuido y ha ampliado su modelo de objetos
para incorporar aspectos como: mltiples 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 dimensin a CORBA. Estas nuevas especificaciones
estn divididas en tres categoras:
Integracin 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 utilizacin de
IDL, existen muchos mercados estandarizando en CORBA (Finanzas, Seguros,
Comercio Electrnico,
Medicina, Manufactura,
Telecomunicaciones,
Transportes, Investigacin y Objetos de Negocio).
A continuacin se describen las caractersticas ms importantes de los ltimos
adelantos en CORBA 3.0:
148

Integracin con Internet
Esta integracin esta siendo desarrollada por la especificacin firewall. La
especificacin CORBA 3 define firewalls a nivel de transporte, de aplicacin y
conexiones bidireccionales GIOP tiles para callbacks y notificacin 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.
Tambin hay una especificacin de CORBA sobre SOCKS.
En CORBA es frecuente que un objeto invoque un mtodo (callback) o notifique
de algn suceso a su cliente, por esto el objeto puede comportarse como cliente,
por esto generalmente se requiere abrir una nueva conexin TCP en sentido
inverso el cual puede ser detenido por un firewall. Bajo esta especificacin, a
una conexin IIOP se le permite llevar invocaciones en el sentido inverso bajo
ciertas condiciones que no comprometan la seguridad de la conexin.
UML y MOF: Soporte para anlisis y diseo
El modelado es una pieza clave en el desarrollo de software robusto, antes que
existiera UML de OMG, no haba mecanismos estndares 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 bsico UML suple
muchas de las necesidades de los usuarios, esta puede ser especializada para
incorporar aspectos que no contemplaban otras herramientas. Esta diseado
para soportar herramientas y colaboracin utilizando marcos de trabajo,
patrones y componentes.
UML define una notacin grfica para cada uno de los siguientes diagramas: de
casos, de uso, de clases, de comportamiento, de implementacin 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
nmero de caractersticas importantes en un sistema distribuido. La nocin de
componente puede no corresponder al modelo uno a uno ni de un objeto
CORBA, esta centrado ms en la relacin 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 notificacin
(servicio de eventos) y validacin cuando alguna propiedad cambia.
149

Los componentes de CORBA sern trasladados a los lenguajes ya soportados, y
a otros modelos de componentes como los Java Beans. Igualmente se esta
trabajando en una especificacin para un lenguaje de scripting que facilite el
nivel de usuario la utilizacin de componentes.
Control de la Calidad del Servicio
Mensajes Asincrnicos y Control de Calidad del Servicio.
La nueva especificacin de Mensajera define un nmero de modos de
invocaciones asincrnicas e independientes del tiempo para CORBA el cua l
permite tanto invocaciones estticas como dinmicas en cada modo. Las
invocaciones asincrnicas pueden ser realizadas de dos formas: censando
(polling) o callback.
Las polticas permite tener control de la Calidad del Servicio de las invocaciones,
los clientes y objetos pueden establecer control de ordenacin (por tiempo,
prioridad, deadline), configurar prioridades, deadlines y tiempos de vida,
configurar tiempos de inicio y finalizacin para invocaciones sensibles al tiempo
y controlar las polticas de enrutamiento y nmero de saltos.
Tiempo Real, Tolerancia a Fallos y CORBA Mnimo.
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 incorporacin 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 caracterstica en sus productos, deber cumplir las especificaciones
definidas para tal caso. La primera especificacin 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
implementacin acoplarse a un ORB es lo suficientemente robusto y flexible
para soportar redundancia y tolerancia a fallos en ambientes CORBA, pero an
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 implementacin liviana de un ORB sera altamente recomendable, por
ejemplo en implementaciones en chips o en sistemas embebidos. Para esto se
ha definido una RFP para CORBA mnimo que determine los requerimientos
150

mnimos que s deben ser cumplidos para una especificacin de CORBA
Mnimo.
151

Cuestionario
Qu problema la OMG est probando para resolver con CORBA?
Por qu la orientacin a objetos ayuda a resolver el problema de
heterogeneidad?
Qu patrones de invocacin de objetos soporta CORBA?
Cul es la diferencia entre estilos de invocacin sncrono y asincrnicos?
Qu es IDL y su utilidad?
Qu son los stubs y cmo se usan?
Qu son los skeletons y cmo se usan?
Cul es la diferencia entre la invocacin esttica y dinmico y cmo se
soportan tanto en lado del cliente como del servidor?
Qu es un almacn de la interfaz?
Qu es un adaptador del objeto?
Cmo trabaja el registro del objeto y referencia del objeto?
Cul es la diferencia entre el adaptador del objeto y el skeleton?
Qu realiza un Adaptador del Objeto Porttil (POA)?
Qu es la activacin / desactivacin?
Qu es un objeto persistente?
Qu es un objeto transente?
Cul es la diferencia entre la llamada por referencia y llamada por valor?
Cmo la interoperabilidad del inter-orb se soporta?
Cul es la diferencia entre GIOP e IIOP?
Qu transparencias proporciona CORBA?
Ejercicio Prctico
152

Escenario
Los programas del CORBA consisten en uno o ms clientes y uno o ms
servidores.
El ejemplo ms simple es un cliente y un servidor. Los servidores en CORBA
son a menudo llamados servicios.
Los servicios simples exportan varios mtodos y atributos mediante la Static
Skeleton Interface (SSI).
Los clientes tienen acceso a estos mtodos y atributos que usan la Static
Invocation Interface (SII).
Los clientes tienen acceso a los servicios ponindose en contacto con un
servicio bien conocido, llamado Lookup Service.
Definicin de Interfaces con IDL
El Interface Definition Language (IDL) se usa para describir los mtodos,
atributos, excepciones y tipos usados en su sistema distribuido. El cdigo
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
153

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 mtodo define los parmetros out o
inout, dado que Java no los soporta nativamente. Ellos almacenan los valores
de los parmetros cuando ellos son pasados a un mtodo (in) y/o despus los
mtodos regresan (out). Cualquier tipo que se usa como un parmetro (o valor
devuelto) para una operacin debe tener una clase del Poseedor para cuando
los parmetros in e inout se usan.
154

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 cmo la herencia trabaja en CORBA, debe usar el mtodo narrow() en esta
clase. Upcasting es similar a (Object)myObj en Java, pero de nuevo debe usar
el mtodo insert() en esta clase.
Implementacin 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 mtodos
descritos en la 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;
}
155
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 dinmicamentedimensionada.
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 demostracin.
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 implementatio n
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
156

// 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
propsito 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");
157

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();
}
}
}
Compilacin
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:
158
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 mdulo 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
tambin el servicio y archivos del registrador en este mismo paquete. Por
consiguiente, copie el servicio y cdigo 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 directori o
para los archivos de servicio requeridos por el cliente.
mkdir ~/CORBA/client/libraryclient
mkdir ~/CORBA/client/library
Copie el cdigo 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
159

Dado que el cliente y los archivos del servidor estn en directorios
completamente diferentes, es ms fcil decir si cualquier clase est relegada, ya
que el cliente no compilar, o no ejecutar. Esto lo hace ms fcil cuando
queremos mover el cliente a otra mquina. Puede compilar el cliente ahora:
cd ~/CORBA/client
javac libraryclient/LibraryClient.java
Ejecucin
El servicio y cliente estn 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 nmero 1050' representa el puerto de red dnde el servicio de nombres est
ejecutando. Puede usar cualquier valor para esto cuando le gusta. El nombre
'localhost' se refiere al nombre de dominio dnde el servicio de nombres est
ejecutando. Si ejecuta esto en una mquina 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
cdigo en el ejemplo anterior puede ser considerado una plantilla del CORBA
estndar. Puede identificar la mayora de este cdigo dado que esta
documentado.
Un acercamiento recomendado es extraer el cdigo de la plantilla para el cliente,
registrador y servicio, para el uso cuando crea sus propios clientes y servicios.
Esto lo salvar de la mecanografa e disminuye la preocupacin por tantos
errores de compilacin.
160
3.4. RMI
Escenario RMI
Qu es RMI?
Invocacin de Mtodos Remotos (RMI) es una implementacin orientada

a objetos del modelo de RPC. Slo 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 mtodos remotos que pueden
invocarse en programas clientes.
Un objeto remoto se declara con una interfaz remota, una extensin 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 mtodos
remotos asociados con los objetos que usan la sintaxis proporcionada por
las invocaciones de mtodos remotas.
Arquitectura RMI
Registro de
Objetos
Soporta la
interfase con
el programa
de aplicacin
Mapea la plataforma
independiente de la capa
Stub/Skeleton a la
plataforma dependiente
de la capa de transporte,
moviliza los protocolos de
referencia remota
Cliente del
Objeto
Servidor del
Objeto
Stub
Skeleton
Capa de Referencia Remota
Capa de Transporte
Activa, mantiene y
desactiva las
conexiones, y
moviliza el
protocolo de
transporte
161

Interaccin entre Stub y Skeleton
stub
Mtodo
Remoto
skeleton
Tiempo
Marshal parmetros;
Enva peticin
Unmarshal parmetros
Invoca mtodo
Ejecuta cdigo
y regresa valor
Recibe valor de retorno
Marshal Contestacin
Enva contestacin
Unmarshall Contesta cin
Regresa valor
Escenario RMI
Definir su interfaz
remota
Con base en el proceso

para aplicaciones RMI
realizar el ejercicio RMI
(anexo)
Implemente
la interfaz
javac
3
4
rmic
Server class (.class)
Implemente
el cliente
10
Client stub (.class)
javac
Inicie cliente
Server Skeleton (.class)
Iniciar el RMI Registry
Iniciar objetos del servidor

Registrar objetos remotos
6
7
162
Actividad 3.4
Actividad RMI
Realizar el Ejercicio RMI anexo y coloque su reporte en Tarea Individual 3.4
Ejercicio RMI
RMI es una tecnologa de Middleware, RMI proviene de las siglas Remote
Method Invocation (o Invocacin de Mtodos Remotos).
Particularmente son tecnologas dependientes del lenguaje, y en ocasiones de
algn 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 travs del siguiente ejemplo
guiado por cdigo.
EJERCICIO
/*** Intefaz remota para el ejemplo Hola, Mundo ***/
public interface InterfazHola extends Remote {
/*** Mtodo 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;
}
163

/*** Implementacin del mtodo 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 ("Excepcin 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 ("Excepcin de ServidorHola: " + e);
}
}
164

}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
Atributos
Arriba del
Estndar
En el Estndar
Debajo del
Estndar
Puntos de
Atributo
Obtenidos
(10-9)
(8.5-7)
(6.5-0)
La informacin
La informacin La informacin
revisada permiti a revisada permiti
revisada no
los estudiantes
a los estudiantes permiti a los
Aplicacin de
comprender con
comprender
estudiantes
la Informacin
claridad los
solamente los comprender los
ejercicios y
ejercicios y
ejercicios y
programas.
programas.
programas.
(10-9)
Los estudiantes han
demostrado el
significado del
material elaborando
Conexiones
correctamente,
Especialistas mientras extienden
y explican la
informacin,
incorporndola en el
estudio del tema.
(8.5-7)
(6.5-0)
Los estudiantes
Los estudiantes
no han hecho
han demostrado
contacto con el
el significado del
material,
material
simplemente sin
incorporndolo
incorporar la
correctamente en
informacin en
el estudio del
su estudio del
tema.
tema.
165
3.5. COM+
Escenario COM+
.Net y COM+
COM+ se refiere a la versin de COM que combina las caractersticas

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
administracin de procesos, servicios de sincronizacin, un modelo de
transaccin declara tivo y agrupacin de conexiones a objetos y bases de
datos.
Los servicios COM+ estn principalmente orientados hacia el desarrollo

de la aplicacin 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 programacin
proporcionados por el Entorno .NET; y la BCL (Base Class Library)
proporciona acceso directo a ellos.
Capacidades de COM+
Integracin completa de MTS en COM

o Facilita el desarrollo de aplicaciones distribuidas mediante la
reduccin del trabajo asociado con el desarrollo, la depuracin, la
distribucin y el mantenimiento de una aplicacin que
anteriormente utilizaba COM para determinados servicios y MTS
para otros.
Componentes en cola
o Los componentes en cola son una caracterstica de los Servicios
de componentes que aprovecha las ventajas de MSMQ para
permitir que los componentes de servidores participen de forma
lgica en las transacciones mientras estn fuera de lnea o no
disponibles.
Eventos de COM+
o Permite a los programadores de aplicaciones escribir cdigo de
aplicaciones (llamados publicadores) que pueden notificar cdigo
de aplicaciones del cliente (llamados suscriptores) cuando tiene
lugar un evento concreto.
Ejemplo de aplicacin 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.
166

Si un rea se ve afectada por las condiciones de inventario, puede utilizar esa
informacin en sus aplicaciones con la suscripcin al servicio de notificacin 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
167
3.5. COM+
3.5.1. Introduccin a los Servicios COM+
3.5.1.1.
Historia de las aplicaciones basadas en servidor
Introduccin
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 ms
posibilidades. El sistema operativo incluye un conjunto integrado de tecnologas,
llamado servicios de aplicaciones, que permite a las organizaciones crear y
personalizar rpidamente aplicaciones distribuidas mediante software basado en
componentes. Para ayudar a los programadores de aplicaciones a escribir
rpidamente software sofisticado que abarca operaciones tanto de clientes como
de
servidores,
los
servicios
de
aplicaciones
han
evolucionado
considerablemente durante la dcada pasada.
Los servicios de aplicaciones de Windows, tambin 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 aplicacin, las organizaciones pueden crear software
escalable y flexible por medio de hardware de consumo.
Un buen ejemplo de aplicacin distribuida sera el proceso de entrada de
pedidos de comercio electrnico, 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 tecnologas basadas en Internet, como un explorador.
168
Componentes de software
Los componentes son los pilares de las aplicaciones distribuidas. Un
componente es un mdulo de software escrito para controlar un tipo concreto de
informacin o un proceso en particular. Por ejemplo, se puede crear un registro
de cliente con un componente que proporcione el nombre, la direccin y otro tipo
de informacin distintiva. Cada componente se disea de manera que pueda
modificarse fcilmente para ajustarse a unos requisitos determinados. De esta
manera, en vez de escribir el mismo tipo de cdigo una y otra vez, los
programadores pueden utilizar cdigo de software prefabricado y slo necesitan
ajustar los elementos que son diferentes en cada aplicacin. Los programadores
crean aplicaciones mediante la integracin 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 ms aparte de reducir la cantidad
de cdigo que los programadores tienen que escribir desde el principio. Puesto
que las aplicaciones creadas con componentes pueden vincularse a travs de
redes, el software de componentes tambin 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 generacin del Modelo de objetos componentes (COM) de
Microsoft. Desde que apareci por primera vez a principios de los noventa, COM
ha sido una importante tecnologa de Windows en constante evolucin. Windows
presenta COM+, que constituye un elemento bsico de la plataforma Windows.
Para comprender COM+, resulta til comprender la evolucin de COM, as como
los servicios de colas de transacciones y de mensajes. Est seccin proporciona
una introduccin a estas tres tecnologas antes de explicar sus mejoras en
COM+.
169

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 fciles de comprender, programar y cambiar. Los
componentes pueden contener una lgica empresarial relevante para controlar
cada elemento de una transaccin, como especificar la longitud adecuada de un
nmero de telfono. Los programadores conectan entre s los componentes para
crear un proceso empresarial. Este mtodo reduce el costo de programacin de
software y permite que las organizaciones puedan modificar fcilmente las
aplicaciones a medida que cambian las condiciones empresariales.
Para resolver las necesidades de los modelos de programacin de aplicaciones
cada vez ms 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) permitan 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) permitan a los programadores
escribir aplicaciones con componentes que se ejecutan de forma asincrnica,
con pausas entre el comienzo y el fina l de un proceso.
Con Windows Server, estos servicios se han integrado y refinado an ms para
permitir a los programadores escribir software basado en componentes
complejos con menor cantidad de cdigo personalizado.
Los servicios de aplicaciones COM de Windows estn diseados para admitir
una arquitectura de tres niveles (tambin llamada de n niveles o distribuida). La
arquitectura de n niveles separa una aplicacin en tres componentes distintos:
Presentacin. Es la parte de la aplicacin con la que interacta un

usuario, como el formulario de pedidos utilizado en aplicaciones de
comercio electrnico.
Lgica de la aplicacin. Este componente contiene todas las reglas y la
lgica empresariales asociadas con la aplicacin, como la aplicacin de
comprobacin de crdito utilizada para admitir una aplicacin de comercio
electrnico.
Datos. Se trata del mecanismo que almacena y administra los datos
asociados con la aplicacin, como la informacin de inventario de un
producto para una aplicacin de comercio electrnico. Habitualmente se
trata de bases de datos relacionales, pero puede incluir tambin otros
contenedores de almacenamiento, como un sistema de archivos.
170
Arquitectura de aplicaciones de tres niveles

La divisin de aplicaciones en las secciones de presentacin, lgica de la
aplicacin y datos da lugar a un modelo de programacin simplificado que es la
manera estndar de crear aplicaciones que aprovechan las ventajas de las
comunicaciones de Internet y de Intranet. Si las organizaciones agregan ms
hardware donde sea necesario, tambin podrn ampliar las aplicaciones de n
niveles para controlar ms usuarios y mayor informacin.
El paso a un modelo de desarrollo de n niveles es el resultado de una gran
evolucin del modelo de desarrollo de aplicaciones para equipos personales
durante la dcada anterior. A finales de los ochenta, las aplicaciones se
escriban 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 da tos y trasladarlo a servidores de
fondo con ms capacidad. En este modelo de dos niveles, el software de
presentacin (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 separacin entre los
niveles de datos y de presentacin, ya que permite controlar la lgica de
procesamiento en un servidor independiente de las funciones de base de datos y
de presentacin.
El Modelo de objetos componentes
Para hacer posible la creacin de aplicaciones distribuidas, tiene que haber una
manera de separar la aplicacin en pilares ms pequeos encargados de
funciones especficas. Adems, estos pilares deben ser capaces de ejecutarse
en un nico proceso, en varios procesos diferentes e incluso en mquinas
diferentes, de ah el nombre distribuido. COM cumple estos requisitos previos,
adems de proporcionar estos requisitos adicionales:
171
Ubicacin transparente. Se puede llamar a cada componente COM

dentro de un proceso, a travs de procesos en un nico equipo o a travs
de varios equipos sin necesidad de volver a compilarlo.
Independencia del lenguaje. COM es un estndar binario. As, una
implementacin 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 aplicacin 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 parmetros 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 travs de las
redes. Por esa razn, con Windows NT Server 4.0 Microsoft present el Modelo
de objetos componentes distribuido (DCOM), que ampla COM para que la
tecnologa de componentes pueda funcionar a travs de redes y de Internet,
como sucede en una arquitectura de n niveles. Desde su presentacin, se ha
utilizado con frecuencia el trmino COM para incluir tambin las tecnologas
distribuidas DCOM.
Servicios de transacciones
A mediados de los noventa, Microsoft ampli la aplicabilidad de COM con la
aparicin de Microsoft Transaction Server (MTS). En Windows NT 4.0, MTS es
una tecnologa independiente que ampla el modelo de programacin COM para
el desarrollo, distribucin y administracin 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 lgica empresarial que se ejecuta all. MTS incluye
cdigo de infraestructura para administracin de conectividad, directorios,
seguridad, procesos y subprocesos, as como las conexiones de bases de datos
necesarias para crear una aplicacin preparada para realizar transacciones.
Una transaccin es un conjunto de eventos que se confirman o se deshacen
como una unidad: o suceden todos los eventos o ninguno de ellos. La creacin
de una transaccin completa puede requerir la cooperacin de varios
componentes. En el ejemp lo de la figura, la aplicacin de entrada de pedidos
consta de componentes que, mediante DCOM, recuperan y procesan
172

informacin de varios servidores. MTS proporciona servicios integrados de
programacin que permiten a los programadores asegurarse de que toda la
transaccin tiene xito o se anula por completo, sin necesidad de escribir
grandes cantidades de cdigo personalizado para controlar los mecanismos de
la transaccin.
Servicios de transacciones
La manera ms fcil de comprender cmo funcionan juntos MTS y COM es
observar un escenario tpico, como el que se ilustra en la figura previa. Suponga
que un cliente solicita productos a travs de Internet. Todo el sistema de entrada
de pedidos puede crearse mediante componentes COM que contengan la lgica
empresarial necesaria para procesar pedidos. Los elementos individuales del
pedido del cliente utilizarn con toda probabilidad varios procesos y bases de
datos, alojados en diferentes servidores.
Por ejemplo, el proceso utilizara una base de datos con informacin de clientes
para registrar el nombre y la direccin 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 envo para realizar el seguimiento del envo y
un proceso de comprobacin de crdito para asegurarse de que la tarjeta de
crdito del cliente es vlida.
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
transaccin y slo confirma todos los cambios si la transaccin tiene xito en su
173

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 tenan 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
slo 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 cdigo
especializado necesario para tratar dichos problemas.
Entre las caractersticas bsicas de MTS se incluyen:
Transacciones automticas. MTS admite transacciones automticas,

que permiten configurar los requisitos de transaccin de un componente
cuando se distribuye dicho componente. El resultado es un potencial
mucho mayor para la reutilizacin 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 funcin, MTS simplifica en
gran medida el trabajo necesario para crear aplicaciones de servidor
seguras. Por ejemplo, un administrador puede designar que slo aquellos
clientes identificados como administradores puedan cambiar el historial de
crdito. Nota: el modelo de seguridad de MTS se basa en la
infraestruc tura de seguridad de Windows.
Agrupacin 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. Tambin estn disponibles los controladores de
Conectividad abierta de bases de datos (ODBC) compatible con MTS y
Base de datos de vinculacin e incrustacin de objetos (OLE DB) para
muchas otras bases de datos de proveedores terceros.
Compatibilidad con subprocesos automtica. Los programadores de
aplicaciones pueden escribir componentes de un nico subproceso y, a
continuacin, permitir a MTS asignar subprocesos a dichos componentes
segn sea necesario.
174
Administracin de estado de componentes. Los componentes tienen

que abandonar cualquier estado de la memoria cuando finaliza cada
transaccin. Esto facilita la creacin de aplicaciones correctas a la vez
que permite compartir los recursos de manera eficaz. MTS tambin
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 ms 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 travs 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 ms
conocidos en la actualidad, incluido el sistema de programacin Visual
Basic, Java, C++ y Cobol.
Message Queue Server

Como puede no ser necesario completar todos los pasos del proceso de una
aplicacin 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 tecnologa
independiente que complementa las capacidades inherentes a COM y MTS.
MSMQ permite a las aplicaciones utilizar componentes que se comunican entre
s de forma asincrnica mediante mensajes en cola, que es un concepto similar
al de un mensaje de correo electrnico 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 tambin ayuda a los
programadores a escribir aplicaciones de mayor disponibilidad y ms escalables.
175
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 aplicacin de destino podra
no estar ni siquiera en ejecucin). Dichos mensajes se envan a una cola, donde
se almacenan hasta que una aplicacin 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 mtodo de comunicacin 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 estn ejecutndose
al mismo tiempo.
Por ejemplo, un programador puede utilizar MSMQ para escribir una aplicacin
que permitir a los clientes realizar pedidos a travs de Internet, incluso si el
servidor Web encargado de la recepcin no est disponible. Las colas de
mensajes tambin pueden utilizarse para realizar procesos de fondo ms
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 envo no tiene que recibir el pedido
del cliente hasta que se haya completado el resto de la transaccin. Con MSMQ,
la aplicacin de entrada de pedidos puede seguir ejecutndose incluso si la
aplicacin de envos no est disponible.
176
Cuando se completa un pedido, un componente de entrada de pedidos enva un

mensaje a un almacn para indicar que hay que empaquetar y enviar el pedido.
Como no es necesario que el componente espere a que se enve el pedido, esta
solicitud se realiza mediante MSMQ. Cuando es preciso, una aplicacin del
almacn 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 transaccin se completa correctamente.
Entre las caractersticas de MSMQ que admiten las capacidades anteriormente
descritas se incluyen:
Acceso basado en COM. Es posible tener acceso a los servicios de

MSMQ a travs de una interfaz sencilla proporcionada por componentes
COM. Esta configuracin hace que sea elemental enviar y recibir
mensajes desde una secuencia de comandos en una pgina Active
Server de Servicios de Internet Information Server, una aplicacin basada
en MTS o cualquier software que pueda utilizar COM.
Integracin con MTS. Las operaciones de MSMQ se pueden incluir
automticamente en transacciones MTS para conservar la integridad de
los datos.
Introduccin automtica 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 ms fcilmente la recuperacin de ciertas clases de error.
Notificacin automtica. Si as se solicita, MSMQ puede notificar a una
aplicacin de envo que los mensajes se recibieron y procesaron (o no)
correctamente. Este servicio permite a las aplicaciones de envo saber
cundo pueden tratar los mensajes como entregados o, si se producen
errores, cundo 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 travs de la red. Esta capacidad protege los mensajes
para que no se puedan ver o modificar durante la transmisin, incluso si
se envan a travs de redes pblicas como Internet, y garantiza que los
servidores no reciban mensajes de remitentes sin autorizacin.
Capacidad para establecer la prioridad de los mensajes. MSMQ
permite asignar prioridades a los mensajes y las colas de mensajes, y
despus se basa en dichas prioridades para enrutarlos y entregarlos. Las
prioridades permiten a las aplicaciones ocuparse primero de los mensajes
ms importantes.
Integracin de aplicaciones simplificada. Las colas de mensajes
reducen en gran medida los requisitos de sincronizacin entre
aplicaciones, ya que es fcil traducir el contenido de los mensajes y las
interfaces basadas en mensajes ocultan las diferencias existentes entre
las diferentes arquitecturas de aplicaciones y tecnologas de bases de
datos.
177
Independencia de protocolos de red. Todas las funciones y

caractersticas de las colas de mensajes funcionan independientemente
de los protocolos de red. Cualquier aplicacin que conozca el nombre de
la cola de solicitudes de otra aplicacin puede enviar solicitudes y recibir
respuestas, cualquiera que sea el tipo de red.
Al ofrecer comunicaciones asincrnicas flexibles y confiables entre aplicaciones

basadas en componentes, MSMQ desempea un papel vital en los servicios de
componentes de Microsoft para Windows NT 4.0. Con Windows 2000, los
servicios de MSMQ estn an ms estrechamente integrados con el modelo de
programacin COM, como se describe en la prxima seccin.
COM+
En Windows NT 4.0, COM y MTS simplificaron la programacin de aplicaciones
distribuidas. En Windows 2000, COM y MTS se combinan para crear COM+, que
simplifica an ms la creacin y el uso de componentes de software .
COM+ proporciona servicios que pueden utilizarse desde cualquier lenguaje o
herramienta de programacin y permite una amplia interoperabilidad entre
componentes, independientemente de cmo se implementen. Para conseguirlo,
define un conjunto estndar 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+ estarn
accesibles para todos los lenguajes y herramientas compatibles con COM+,
adems de simplificar la distribucin de componentes y aplicaciones que los
utilizan.
Las caractersticas suministradas con COM+ permiten que las aplicaciones se
ejecuten ms rpido y se escalen mejor, a la vez que facilitan a los
programadores la integracin de cdigo con sistemas de varios proveedores.
Los componentes escritos con el modelo COM funcionarn con COM+. COM+
ampla tambin la compatibilidad de la plataforma Windows con la programacin
basada en atributos, que permite utilizar los componentes de una manera ms
flexible.
COM+ presenta varias capacidades nuevas, incluidas las siguientes:
Integracin completa de MTS en COM. Como se mencion anteriormente,
COM+ unifica los modelos de programacin inherentes en los servicios COM y
MTS. Tambin combina el cdigo 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 reduccin del
trabajo asociado con el desarrollo, la depuracin, la distribucin y el
mantenimiento de una aplicacin que anteriormente utilizaba COM para
determinados servicios y MTS para otros.
178

Componentes en cola. Los componentes en cola son una caracterstica de los
Servicios de componentes que aprovecha las ventajas de MSMQ para permitir
que los componentes de servidores participen de forma lgica en las
transacciones mientras estn fuera de lnea o no disponibles. Considere los
componentes en cola como la versin 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
programacin con componentes en cola es mucho ms rpida y no requiere el
aprendizaje de tcnicas 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 ms
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 estn conectados; de lo
contrario, el componente no puede retener la ejecucin hasta que se realiza una
conexin.
Eventos de COM+. Tambin conocido como servicio de eventos de publicacin
y suscripcin o Notificacin de eventos, los eventos de COM+ constituyen una
herramienta de programacin que permite a los programadores de aplicaciones
escribir cdigo de aplicaciones (llamados publicadores) que pueden notificar
cdigo 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 publicacin y
suscripcin por multidifusin 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 informacin acerca de varios
eventos, publicadores, suscriptores y suscripciones individuales.
Para ver su funcionamiento, observe de nuevo la aplicacin 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 ms populares descienden por debajo de un
determinado nivel. Los programadores que escriben aplicaciones para el
departamento de compras, o cualquier otra rea de la organizacin que se vea
afectada por las condiciones del inventario, pueden utilizar esta informacin en
sus aplicaciones mediante la suscripcin al servicio de notificacin de eventos
de software de inventario.
179
COM+
3.5.1.2.
La arquitectura de tiempo de ejecucin de COM+
Introduccin
COM ofrece una solucin 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 ms que una
nueva versin 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 implementacin. (Si un componente no precisa
utilizar algn servicio, no se debe colocar en una aplicacin de COM+.) La
escalabilidad y el buen rendimiento se logran diseando aplicaciones desde el
exte rior para hacer uso de servicios como las transacciones, las agrupaciones
de objetos y la semntica de actividades.
.NET Framework ofrece otra forma de escribir aplicaciones basadas en
componentes y presenta ventajas sobre el modelo de programacin de COM,
mejor compatibilidad de herramientas, el tiempo de ejecucin en lenguaje comn
180

(CLR) y una sintaxis de codificacin mucho ms sencilla. Se puede tener acceso
a la infraestructura de servicios de COM+ desde cdigo administrado y no
administrado. Los servicios en cdigo 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 debera 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 an pertenecen al campo de las
prcticas de programacin. La idea bsica que subyace en los servicios es
diseo para el rendimiento y la escalabilidad desde el exterior y
aprovechamiento de los Enterprise Services para una fcil implementacin de
dichos patrones de diseo 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
aplicacin 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 automticas o los componentes en

cola se pueden configurar de forma declarativa. Los atributos relacionados con
el servicio se aplican en tiempo de diseo y se crean las instancias de clases
181

que utilizan esos servicios. Algunos servicios se configuran llamando a mtodos
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 transaccin puede extender esa transaccin a un segundo objeto
que tambin admita o requiera transacciones.
El catlogo COM+ guarda la informacin de configuracin que se aplica a la
implementacin de una clase. En tiempo de ejecucin, en funcin de los
atributos que aplique al cdigo, COM+ crea una capa de servicio del contexto.
La siguiente ilustracin muestra una transaccin automtica que pasa entre dos
objetos administrados alojados en COM+.
Aplicacin COM+ con componentes con servicio alojados
Los servicios pueden fluir tambin entre objetos de COM+ y .NET Framework.
Cada entorno controla la implementacin y ejecucin de su cdigo nativo; COM+
proporciona siempre el contexto del objeto.
Caractersticas de los servicios COM+
Una clase configurada posee un conjunto de COM+ estos son atributos
declarativos que especifican los servicios requeridos. En tiempo de ejecucin,
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 estn
configuradas ignoran sus contextos asociados.
Se tienen dos tipos de aplicaciones COM+:
Aplicacin de biblioteca, que es una coleccin de clases de componentes,

que cuando son instanciadas, son creadas dentro del proceso del cliente que
llama.
Aplicacin de servidor, que es una coleccin de clases de componentes, que

cuando son instanciadas son creadas en un proceso subrogado separado del
proceso del cliente que llama.
182

Una transaccin 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 informacin. Las
transacciones en COM+ estn a cargo del Coordinador de Transacciones
Distribuidas (Distributed Transaction Coordinator, DTC) el cual es un
componente del sistema operativo Windows.
La activacin justo -a-tiempo (JIT) es el mecanismo usado por COM+ para evitar
el consumo de recursos por parte de los componentes mientras stos estn 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 mtodos es llamado.
La seguridad es otro punto importante de las aplicaciones COM+. El primer
aspecto es concerniente a la autenticacin, lo cual permite establecer
restricciones a quin tiene acceso a la aplicacin y su funcionalidad. El otro
aspecto es el modelo de impersonacin, en el cual es objeto asume la
informacin 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 estn en disposicin de
manipular los eventos definidos en la interfaz de eventos como sus criptores.
Esta arquitectura es usualmente llamada como eventos dbilmente acoplados
loosely-coupled.
Pool de objetos, es la caracterstica que permite tener un conjunto de objetos
disponibles para cualquier peticin realizada del cliente sin incidir en costos de
creacin e instanciacin. 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 mtodos de un cliente al servidor que es
disponible de manera que pueden volverse a hacer la llamada cuando el
servidor est en lnea nuevamente. El cdigo del cliente permanece sin tener
conocimiento de que el servidor fue desconectado y los servicios de COM+
estn 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.
183

Ejercicio Prctico: 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 diseada 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 tambin debe definir un constructor pblico por defecto.
public class PruebaDeComPlus: ServicedComponent
{
public PruebaDeComPlus()
{
}
}
Hgase 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 lnea 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 aplicacin COM+ y crearemos un formulario para proveer
una interfaz grfica desde el cual se harn las llamadas. A diferencia de otro
ensamblado de .NET estos requieren un tratamiento especial. A continuacin se
muestra el conjunto de atributos del archivo AssemblyInfo.cs que han de ser
agregados para que nuestra aplicacin 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 ("Demostracin de COM+ en .NET")]
El primer atributo especifica el tipo de aplicacin que es (en este caso esta ser
de tipo biblioteca) esta informacin corresponde a la enumeracin de
ActivationOption. El segundo atributo es la manera como se accede al control de
184

la aplicacin. El tercer atributo es el GUID de la aplicacin. El cuarto es el
nombre de la aplicacin que ser anfitrin de nuestro componente cuando este
sea importado a servicios de COM+. El quinto es la descripcin del componente.
Hay dos maneras de implementar un ensamblado servido. La manera ms
simple es copiar el ensamblado en el directorio de la aplicacin COM+ esta
manera es conocida como Registro dinmico sin embargo hay un detalle, solo
los administradores podrn 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 prximo paso es registrar explcitamente el ensamblado antes de utilizarlo,
esto se hace mediante RegSvcs.exe. Cuando se ejecuta dicho utilitario contra un
ensamblado de .NET este crear una aplicacin 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 aplicacin COM+. Como se
muestra a continuacin el registro de la aplicacin fue exitoso.
Al dirigirnos a la consola de servicios de componentes podemos apreciar que

nuestra aplicacin est ah.
185
Al ejecutar la aplicacin se registra en el visor de sucesos las acciones que se

estn llevando a cabo as tambin ha de suceder si se genera algn error. A
continuacin mostramos el visor de sucesos y los eventos generados desde
nuestra aplicacin.
Igualmente podemos apreciar los resultados de la consulta procesada por el

componente.
186
En la consola de servicios de componentes se muestra la aplicacin

ejecutndose junto con la aplicacin del sistema.
Una manera de comprobar como se esta comportando la aplicacin es mediante

las estadsticas de las transacciones. En la carpeta de Coordinador de
transacciones distribuidas y el nodo de estadsticas de transacciones como se
muestra a continuacin.
187
Cada vez que se pulse el botn ejecutar query de nuestro formulario (cliente) se
podr apreciar como se activan las barras de transaccio nes activas y se
incrementa la barra de transacciones ejecutadas. Aunque en este artculo solo
recuperamos informacin la misma tcnica aplica para operaciones que tengan
que ver con manipulacin (modificacin) de la data.
Cuestionario
1. Liste cinco beneficios de soluciones componente-basado.
2. Qu es una aplicacin COM+?
3. Para qu se utiliza el catlogo COM+?
4. Qu es el contexto?
5. Qu es ServicedComponent?
3.5.2. Servicios de Transaccin
3.5.2.1.
Introduccin al proceso de la transaccin
Una transaccin es un conjunto de tareas relacionadas que se realizan de forma
satisfactoria o incorrecta como una unidad. En trminos de procesamiento, las
transacciones se confirman o se anulan. Para que una transaccin se confirme,
188

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
transaccin falle en su totalidad. Todos los cambios efectuados en datos dentro
del mbito de la transaccin se deshacen hasta un punto especfico establecido.
Propiedades ACID
El trmino ACID expresa la funcin que las transacciones desarrollan en
aplicaciones crticas para una misin. Acuado por los pioneros en el
procesamiento de transacciones, el acrnimo ACID responde a los trminos
atomicidad (atomicity), coherencia (consistency), aislamiento (isolation) y
permanencia (durability).
Estas propiedades garantizan un comportamiento predecible, reforzando la
funcin de las transacciones como proposiciones de todo o nada diseadas para
reducir la carga de administracin cuando hay muchas variables.
Atomicidad
Una transaccin es una unidad de trabajo en la que se produce una serie de
operaciones entre las instrucciones BEGIN TRANSACTION y END
TRANSACTION de una aplicacin. Una transaccin se ejecuta exactamente una
vez y tiene carcter "atmico" (de subdivisin), es decir, el trabajo se realiza en
su totalidad o no se realiza en ningn caso.
Las operaciones asociadas a una transaccin comparten normalmente un
objetivo comn y son interdependientes. Si el sistema ejecutase nicamente una
parte de las operaciones, podra poner en peligro el objetivo final de la
transaccin. La atomicidad elimina la posibilidad de procesar un subconjunto de
operaciones.
Coherencia
Una transaccin 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 transaccin se
mantengan en trminos de semntica. Una parte de la responsabilidad para
mantener la coherencia recae en el programador de la aplicacin que debe
asegurarse de que sta exija todas las restricciones de integridad conocidas. Por
ejemplo, en el desarrollo de una aplicacin en la que se transfiere dinero, se
189

debe evitar el desplazamiento arbitrario de los puntos decimales durante la
transferencia.
Aislamiento
Una transaccin es una unidad de aislamiento, permitiendo que transacciones
concurrentes se comporten como si cada una fuera la nica transaccin que se
ejecuta en el sistema.
El aislamiento requiere que parezca que cada transaccin sea la nica que
manipula el almacn de datos, aunque se puedan estar ejecutando otras
transacciones al mismo tiempo. Una transaccin nunca debe ver las fases
intermedias de otra transaccin.
Las transacciones alcanzan el nivel mximo de aislamiento cuando se pueden
serializar. En este nivel, los resultados obtenidos de un conjunto de
transacciones concurrentes son idnticos a los obtenidos mediante la ejecucin
en serie de las transacciones. Como un alto grado de aislamiento puede limitar
el nmero de transacciones concurrentes, algunas aplicaciones reducen el nivel
de aislamiento en el intercambio para mejorar el rendimiento.
Permanencia
Una transaccin tambin es una unidad de recuperacin. Si una transaccin se
realiza satisfactoriamente, el sistema garantiza que sus actualizaciones se
mantienen aunque el equipo falle inmediatamente despus de la confirmacin.
El registro especializado permite que el procedimiento de reinicio del sistema
complete las operaciones no finalizadas, garantizando la permanencia de a
l
transaccin.
Transacciones distribuidas
Los sistemas de procesamiento de transacciones (TP) distribuidas se disean
para facilitar las transacciones que abarcan recursos heterogneos relacionados
con transacciones en un entorno distribuido. Un sistema TP de transacciones
distribuidas permite a la aplicacin combinar en una unidad transaccional
actividades tan diferentes como la recuperacin de un mensaje de una cola de
Message Queuing, el almacenamiento del mensaje en una base de datos de
Microsoft SQL Server y la eliminacin 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 continuacin.
190

Estas entidades son lgicas 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 sita entre una aplicacin
relacionada con transacciones y una coleccin 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 aplicacin que administre un entorno distribuido
multiusuario, se crea una aplicacin formada por solicitudes de transacciones
nicas. El supervisor cambia el tamao de la aplicacin segn proceda.
El supervisor TP para Microsoft Windows 2000 es DTC (Coordinador de
transacciones distribuidas).
Administradores de transacciones
En una transaccin 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 transaccin 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 recuperacin 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 tambin 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 conexin cuando deja de ser necesaria.
191

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 cdigo, por ejemplo para marcar la compatibilidad de
transacciones de un componente como Requerida. Al definir un botn de opcin
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 transaccin COM+. Cuando un compone nte utiliza transacciones COM+,
todas las transacciones de bases de datos estn controladas por el Coordinador
de transacciones distribuidas (DTC). La figura muestra un ejemplo de seleccin
de la opcin de transaccin necesaria dentro de la interfaz de Servicios de
componente.
Componente COM+ de ejemplo que requiere una transaccin

Definir la seguridad para el componente resulta tan fcil como definir la
compatibilidad de transacciones. Se puede decidir qu usuarios podrn ejecutar
cada componente, e incluso cada mtodo, sin necesidad de volver a compilar el
cdigo. Estas opciones se seleccionan mediante el complemento de servicios
COM+.
192

Ejercicio Prctico: Creacin 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 mtodos necesarios para
interactuar con los servicios COM+. Deberemos marcar la clase para que
requiera una nueva transaccin y los mtodos creados para que puedan
completar la transaccin automticamente si no se producen errores. Vamos a
ponerlo en prctica:
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 cdigo en esta nueva clase:
Imports System.EnterpriseServices
Imports System.Reflection
'********************************************
'Detalles de registro de COM+
'Nombre de la aplicacin 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
193

Este cdigo empieza importando un par de espacios de nombre para tener que
escribir menos al declarar componentes.
5. A continuacin tienen lugar los detalles de registro de COM+. Introduzca
la siguiente lnea de cdigo:
'Proporcionar el nombre de aplicacin COM+
<Assembly: ApplicationNameAttribute("ComPlusExample")>
Esta lnea asigna un valor de ComPlusExample a ApplicationNameAttribute.
Este es el nombre de la aplicacin COM+ una vez que se haya registrado en el
catlogo COM+. Despus 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 aplicacin.
La siguiente parte del cdigo declara el atributo AssemblyKeyFileAttribute:
<Assembly: _ AssemblyKeyFileAttribute("bin/ComPlusExample.snk")>
Este cdigo indica al catlogo COM+ la ubicacin del nombre seguro. El archivo
.SNK, que crearemos ms tarde, es el que describe el componente para COM+.
A continuacin, crearemos por fin el nombre de clase, COMPlusServices,
utilizando el cdigo 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 transaccin como Necesario. Agregar esta lnea de cdigo 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 seccin anterior.
La siguiente lnea de cdigo en la clase hereda de ServicedComponent dentro
del espacio de nombres System.EnterpriseServices.
Inherits ServicedComponent
Si no incluye esta lnea, no podr hacer que funcione este componente bajo
COM+.
Adicin de un mtodo de transaccin
Una vez que la configuracin de esta clase se haya completado, puede crear un
mtodo que efecte alguna accin. La funcin DoTransaction en el cdigo
194

escrito devuelve un valor de cadena, pero mostrar la sintaxis que debe
utilizarse para que este mtodo participe en la transaccin.
<AutoComplete()> Public Function DoTransaction() As String
Return "COM+ funciona correctamente"
End Function
Es importante anteponer este mtodo con el atributo <AutoComplete()>. Esto
significa que mientras no haya una excepcin en este mtodo, se llamar
automticamente a SetComplete cuando el mtodo termine. Si se produjera una
excepcin en el mtodo, el tiempo de ejecucin de .NET llamara al mtodo
SetAbort de forma automtica.
Creacin de un nombre seguro
Antes de compilar el componente, es necesario asignar un nombre seguro al
ensamblado de dicho componente. De lo contrario, el catlogo 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 lnea de comandos.
2. Para crear el nombre seguro, introduzca lo siguiente en la lnea de
comando y, a continuacin, presione Intro.
sn -k ComPlusExample.snk
3. Copie el archivo ComPlusExample.snk del directorio raz 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.
Generacin de una aplicacin cliente de ejemplo
Una vez generado el componente, necesitar generar una aplicacin cliente
para llamar a este componente y comprobar su funcionamiento. Cree una
aplicacin de consola simple en la que el mtodo Main del archivo de mdulo
cree una instancia del nuevo componente y llame al mtodo DoTransaction().
Los principales pasos son los siguientes:
1. En Visual Basic .NET, cree un nuevo proyecto de aplicacin de consola.
195
2. Agregue una referencia al componente que ha creado.

3. Escriba el siguiente cdigo:
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 aplicacin y comprobar su
funcionamiento.
1. Abra el complemento de servicios de componentes MMC y compruebe
que su componente se registr dinmicamente en el catlogo COM+.
Debera ver algo similar a la figura siguiente.
2. Compile y ejecute la aplicacin de consola.
El nuevo componente atendido por .NET en el catlogo COM+
196
Cuestionario
1. Nombre las cuatro propiedades ACID de transacciones.
2. Cul es el servicio de transacciones distribuidas coordinadas para las
aplicaciones COM+?
3. Liste las configuraciones de atributo de transaccin que un componente
COM+ puede tener.
4. Qu pasa a un componente si una llamada a uno de sus mtodos
regresa y su bit dispuesto se ha establecido en True?
5. Cmo 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 transaccin soportados para
los componentes servidos.
3.5.3. Seguridad en Aplicaciones
3.5.3.1.
Introduccin a la seguridad de la aplicacin
Seguridad de acceso al cdigo (CAS)

La seguridad de .NET Framework ofrece la posibilidad de que el cdigo tenga
acceso a los recursos nicamente si se le concede permiso para ello. .NET
Framework emplea el concepto de permisos para expresar esta caracterstica,
que representa el derecho del cdigo para utilizar recursos protegidos. El cdigo,
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
cdigo
autorizacin.
Cualquier
ruta
de
cdigo
a
travs
de
System.EnterpriseServices solicita permisos de cdigo no administrado.
La seguridad de acceso al cdigo en .NET es muy til en el caso de las
aplicaciones en las que el cdigo se descarga desde Internet y su autor no
resulta de mucha confianza. Tpicamente, las aplicaciones que utilizan
componentes facilitados como servicio son de completa confianza, requieren
que se d el flujo de la seguridad entre mltiples procesos y permiten la
configuracin de las funciones durante la fase de implementacin. Estas son las
caractersticas expuestas por la seguridad basada en funciones de COM+.
197

Cualquier ruta de cdigo a travs de System.EnterpriseServices solicita
permisos de cdigo no administrado. Esto implica lo siguiente:
Es necesario contar con permisos de cdigo 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 cdigo que no

resulta de confianza, no se puede llamar a los mtodos definidos en
ServicedComponent desde l. Sin embargo, s que se puede llamar a los
mtodos personalizados definidos en una clase derivada de
ServicedComponent en ciertas circunstancias: las llamadas desde cdigo
que no es de confianza se pueden realizar en aquellos mtodos
personalizados que no requieren el cambio de contexto, servicios de
intercepcin y si su implementacin no realiza llamadas a los miembros de
System.EnterpriseServices.
Asimismo, en la versin 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 aplicacin de servidor de COM+ se emplea para alojar los
componentes, las caractersticas de RBS requieren que el protocolo de
transporte de DCOM se utilice para activar los componentes desde un cliente
remoto. En la siguiente seccin se proporciona ms informacin sobre el acceso
remoto. La identidad y el contexto de llamadas de seguridad de COM+ se
encuentran por tanto disponibles en el cdigo administrado. Adems,
CoImpersonateClient, CoInitializeSecurity y CoRevertClient son llamadas
conocidas que se emplean por norma general en el lado del servidor, mientras
que CoSetProxyBlanket slo 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 aplicacin de servidor de COM+:
Habilitar
la
autorizacin
en
la
aplicacin
(ApplicationAccessControlAttribute(bool)). Se debe establecer como true para
que ofrezca compatibilidad con RBS.
198

El nivel de seguridad
(ApplicationAccessControlAttri bute(AccessChecksLevelOption)). Si se establece
en AccessChecksLevelOption.Application, los usuarios asignados a las
funciones en la aplicacin se agregan al descriptor de seguridad del proceso, y
la comprobacin detallada de las funciones en los niveles de componente,
mtodo e interfaz se desactiva. Las comprobaciones de la seguridad se llevan a
cabo, por tanto, slo a nivel de la aplicacin y las aplicaciones de biblioteca
confan 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 aplicacin se agregan al descriptor de la
seguridad del proceso y las comprobaciones de la seguridad basada en
funciones se realizan en la aplicacin. Asimismo, estas comprobaciones se
deben habilitar para cada componente que requiera RBS mediante la aplicacin
del atributo ComponentAccessControl en la clase. En una aplicacin de
biblioteca, las comprobaciones de la seguridad basada en funciones se realizan
como si se tratara de una aplicacin de servidor. La propiedad de seguridad se
incluye en el contexto para todos los objetos de la aplicacin y el contexto de la
llamada de seguridad se encuentra disponible. Si un objeto cuenta con una
configuracin con el contexto de su creador, se activa en su propio contexto. La
seguridad basada en funciones programtica se basa en la disponibilidad del
contexto de llamada de seguridad.
Para que una comprobacin de acceso significativa funcione en las aplicaciones
de biblioteca de COM+, seleccione realizarlas a nivel de componente y proceso.
Las selecciones de representacin y autenticacin corresponden a las
propiedades ImpersonationLevel y Authentication del atributo
ApplicationAccessControl.
El atributo SecurityRole se puede aplicar al nivel de ensamblado, clase o
mtodo. Cuando se aplica a nivel de ensamblado, los usuarios de esa funcin
pueden activar cualquier componente de la aplicacin. Cuando se aplica a nivel
de clase, los usuarios de esa funcin pueden, adems, llamar a cualquier
mtodo del componente. Las funciones de nivel de clase y aplicacin se pueden
configurar en metadatos, o administrativamente, mediante el acceso al catlogo
COM+.
Configuracin de RBS a nivel de ensamblado mediante metadatos:
[assembly: ApplicationAccessControl(true,
AccessCheckLevel=AccessChecksLevelOption.ApplicationComponent)]
// agrega NTAuthority\everyone a esta funcin
[assembly:SecurityRole("TestRole1",true)]
// agrega usuarios a las funciones administrativamente
[assembly:SecurityRole("TestRole2")]
Configuracin de RBS a nivel de clase en metadatos:
199

[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 catlogo COM+
despus del registro del ensamblado. No obstante, como se mencion
anteriormente, los mtodos de clase no aparecen en el catlogo COM+. Para
configurar RBS en los mtodos, 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 mtodo. Adems, los atributos deben aparecer en la
implementacin de mtodos de clase, no el mtodo de interfaz en la definicin
de la misma.
La forma ms sencilla de utilizar RBS en los mtodos es aplicar el atributo
SecureMethod en el nivel de clase y, a continuacin, configurar las funciones (ya
sea administrativamente o colocando el atributo SecurityRole en los mtodos).
Interface IFoo
{
void Method1();
void Method2();
}
[SecureMethod]
public class Foo : ServicedComponent, IFoo
{
// Agregar funciones a este mtodo administrativamente
// "RoleX" se agrega al catlogo para este mtodo
SecurityRole("RoleX")
}
El uso de SecureMethod a nivel de clase permite configurar administrativamente
todos los mtodos de las interfaces con las funciones del catlogo COM+. Si la
clase implementa dos interfaces, cada una de ellas con el mismo nombre de
mtodo, y las funciones se configuran administrativamente, ser necesario
establecerlas en ambos mtodos como aparecen en el catlogo COM+ (a menos
200

que la clase implemente el mtodo especfico, por ejemplo, IF oo.Method1). Sin
embargo, si se emplea el atributo SecurityRole en el mtodo de clase, todos los
mtodos con el mismo nombre se configuran automticamente con esa funcin
cuando se registre el ensamblado.
El atributo SecureMethod tambin se puede colocar en el nivel de mtodo.
Interface IFoo
{
void Method1();
void Method2();
}
public class Foo : ServicedComponent, IFoo
{
// Agregar funciones a este mtodo administrativamente
[SecureMethod] // O utilizar SecurityRole (se traduce en
SecureMethod++)
}
En el ejemplo, IFoo y ambos mtodos aparecen en el catlogo COM+ y por tanto
las funciones se pueden configurar administrativamente en cualquier mtodo, si
bien, el RBS de nivel de mtodo slo se fuerza en Method1. Utilice
SecureMethod o SecurityRole en todos los mtodos que se requerirn para
participar en la seguridad RBS a nivel de mtodo, o bien, coloque SecureMethod
en el nivel de mtodo como se seal anteriormente.
Siempre que se configura RBS a nivel de mtodo, se solicita la funcin
Marshaller: cuando se realizan llamadas a mtodos 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 mtodos (cuando el atributo SecureMethod est presente), la llamada tiene
lugar utilizando DCOM con la interfaz asociada al mtodo. Por consiguiente,
DCOM garantiza que RBS se fuerza a nivel de mtodo. No obstante, como se
coment en las secciones Activacin e Intercepcin, la interoperabilidad COM y
RSCP realizarn 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 mtodo,
es necesario asociar una funcin a estas interfaces si se desea que la
infraestructura realice las llamadas correctamente.
Por ello se agrega una funcin Marshaller a la aplicacin cuando se registra el
ensamblado; a continuacin, se deber agregar a los usuarios
201

administrativamente a la misma. En la mayora de las ocasiones son todos los
usuarios de la aplicacin los que se incorporan a dicha funcin. Resulta algo
distinto a lo que ocurra co n COM+ no administrado, donde la configuracin de
RBS en los mtodos no requera este pas de configuracin adicional.
Incorporar automticamente a todos los usuarios a esta funcin durante la fase
de registro constituye un riesgo potencial, puesto que ahora cualquiera podra
activar (pero no llamar) los componentes donde antes no tena derechos. La
funcin Marshaller tambin se agrega a la interfaz IDisposable para permitir a los
clientes deshacerse del objeto. Una alternativa a esta funcin es que los
usuarios agreguen las funciones relevantes a cada una de las tres interfaces
mencionadas.
3.5.3.2.
Implementacin de seguridad basada en funcin de COM+
Cuando hay muchos usuarios enviando llamadas a componentes COM que

funcionan bajo COM+, es necesario comprobar que slo 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 funcionarn con cada componente e
incluso qu mtodos de cada componente se pueden ejecutar.
Vamos a agregar un mtodo a esta misma clase COMPlusServices para
incorporar seguridad basada en funciones. Crearemos una funcin llamada
Managers (Supervisores) y comprobaremos si el usuario que efecta la llamada
est en la funcin Managers en el nuevo mtodo.
Pasos para agregar seguridad basada en funciones
En lugar de modificar directamente la aplicacin COM+ desde el complemento
de servicios de componentes MMC para agregar la funcin de seguridad,
agregaremos un nuevo atributo al proyecto. Utilizaremos la clase
SecurityRoleAttribute para agregar la nueva funcin de Managers. El constructor
para esta clase tiene dos argumentos: role (cadena) y everyone (booleano). El
argumento role especifica la funcin que se crear y el argumento everyone
especifica si el grupo integrado Everyone se agrega o no a los usuarios de la
funcin.
Agregue una nueva funcin de seguridad a la aplicacin COM+ introduciendo el
siguiente cdigo justo debajo del comentario de detalles de registro de COM+.
'********************************************
'Atributo de seguridad basada en funciones
<Assembly: SecurityRoleAttribute("Managers", False)>
202

1. Cambie el nivel de seguridad para realizar comprobaciones de acceso en los
procesos y en los componentes. Esto permite a la aplicacin 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 catlogo COM+

Como alternativa al proceso manual, se puede agregar un atributo al
componente ordenndole que realice comprobaciones de acceso. El cdigo
siguiente debe agregarse en la seccin de detalles de registro de COM+, en la
parte superior de la clase COMPlusServices.
<Assembly: ApplicationAccessCont rolAttribute
(AccessChecksLevel:=AccessChecksLevelOption.ApplicationComponent)>
203

Comprobacin de funciones de seguridad
Ahora agregaremos un nuevo mtodo a la clase denominado IsManager. Este
mtodo comprobar si el usuario es miembro de la funcin Managers. El mtodo
consiste en una funcin que devuelve un valor booleano que indica si el usuario
que ejecuta la llamada forma parte o no de la funcin Managers. Para obtener
acceso al contexto de seguridad del usuario que llame al mtodo, es necesario
utilizar la clase SecurityCallContext. Llamando al mtodo CurrrentCall se obtiene
el contexto del usuario actual. A continuacin, llamaremos al mtodo
IsCallerInRole, pasando Managers como nombre de la funcin.
Agregue el mtodo indicado a continuacin a la clase COMPlusServices.
Public Function IsManager() As Boolean
Dim objCallContext As SecurityCallContext = _ SecurityCallContext.CurrentCall
IsManager = _ objCallContext.IsCallerInRole("Managers")
End Function
A continuacin, ser necesario volver a generar el componente y probar este
nuevo mtodo.
Desde el men Generar de Visual Studio .NET, haga clic en Volver a generar
solucin.
Prueba
Modifique el cdigo del mtodo Sub Main() en la aplicacin cliente de consola. El
cdigo debera ser similar a este:
Sub Main()
Dim objCOMPlus As New _
COMPlusJumpStart.COMPlusServices()
Console.WriteLine(objCOMPlus.IsManager().ToString)
Console.ReadLine()
End Sub
1. Ejecute la aplicacin de consola desde el smbolo de sistema introduciendo
el nombre del archivo ejecutable que hemos compilado.
La primera vez que se ejecuta el cdigo, se obtendr una excepcin que indica
que se deneg el acceso porque no se ha agregado ningn usuario a la funcin
Managers. Para resolver este problema, hay que agregar el usuario actual a
Managers y volver a ejecutar la aplicacin. Una vez hecho esto, no debera
producirse la excepcin. Es conveniente agregar cdigo de control de
excepciones. La aplicacin cliente debera tener este aspecto con el cdigo de
control de excepciones:
204

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.
Autenticacin y personificacin
La seguridad se refiere al control del acceso a una variedad de recursos, como

componentes de la aplicacin, datos y hardware. La mayora de las medidas de
seguridad se basan en cuatro conceptos:
Autenticacin
La autenticacin es el proceso de confirmacin de la identidad, que es la primera
capa del control de seguridad. Antes de que una aplicacin pueda autorizar el
acceso a un recurso, debe confirmar la identidad del solicitante. El solicitante
establece una identidad aportando algn tipo de credenciales, que slo 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
autenticacin mutua.
Autorizacin
La autorizacin 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 autenticacin. La confirmacin 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 travs de una combinacin de su tarjeta ATM y NIP.
An as, slo estar autorizado para obtener acceso a su cuenta bancaria. Para
obtener ms informacin.
Proteccin de datos
La proteccin de datos es el proceso que consiste en proporcionar
confidencialidad, integridad y no repudio a los datos. Los datos requieren
proteccin no slo cuando estn en trnsito sino tambin cuando estn
205

almacenados. Independientemente de la forma que tengan los datos, una vez
que entran en canales de comunicacin 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
numrico limitado por el nmero 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 podra realizar una bsqueda 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
tendran que probar hasta 2128 o 3,4 x 1038 valores. Cada bit adicional duplica el
nmero de valores posibles. Las claves de cifrado permiten que varios usuarios
utilicen un algoritmo pblico 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 sistemtico de descifrar los datos utilizando todas las
claves posibles. Por ejemplo, si la clave de cifrado utilizada para cifrar los datos
slo se compone de cuatro bits, para que se produzca un ataque por fuerza
bruta que afecte a los datos slo tienen que probarse hasta diecisis valores de
clave de cifrado. Para obtener ms informacin, vea Criptografa.
La integridad de los datos se obtiene mediante algoritmos hash, firmas digitales
y cdigos de autenticacin de mensajes.
Para garantizar la integridad de los datos, puede enviarse un hash de dichos
datos para que los acompae. El receptor podr entonces comparar el hash que
calcula en funcin de los datos recibidos con el hash que acompaa a los datos
recibidos. Si ambos coinciden, los datos recibidos debern ser los mismos que
los datos a partir de los cuales se cre el hash recibido. Un hash es una cadena
de nmeros 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 clculo del hash es una operacin unidireccional que no se puede
invertir para volver a crear los datos originales.
La firma digital va un paso ms all del simple clculo 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 acompaa, modifique los
datos y, despus, simplemente vuelva a calcular el nuevo hash de los datos
modificados. Como una firma digital es un hash cifrado, el atacante necesitara
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 pblica asociada. Las firmas digitales pueden utilizarse para exigir la no
206

repudiacin de los datos, que puede utilizarse ms adelante para comprobar el
origen, contenido y marca de hora de los datos. Para obtener ms informacin,
vea Algoritmos hash y firmas digitales.
Algunas tecnologas, como SSL/TLS, utilizan cdigos de autenticacin de
mensajes (MAC) para verificar que no se han modificado los datos mientras
estaban en trnsito. Sin embargo, como los cdigos MAC utilizan una clave
comn para el cifrado y la verificacin, no pueden utilizarse para exigir la no
repudiacin de los datos. Para obtener ms informacin, vea Cdigos de
autenticacin de mensajes de canal S.
Auditora
La auditora 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 auditora
constituye una fuente clave para el estudio de la seguridad. Para obtener ms
informacin, vea Registro de eventos.
Lamentablemente, la auditora es un proceso pasivo que slo puede detectar
problemas de seguridad una vez que la aplicacin se vea afectada. Puede
llevarse a cabo una supervisin activa mediante el Monitor de rendimiento de
Windows para que se realicen comentarios en tiempo real. Para obtener ms
informacin, vea Supervisin del rendimiento.
Cuestionario
1. Si la seguridad se habilita para una aplicacin COM+, cmo determina el
COM SCM si un cliente particular es permitido para comenzar una
aplicacin servidor COM+?
2. Cmo un objeto de Servicios .NET puede programticamente tomar
decisiones basadas en el rol de miembros solicitantes?
3. Cmo un objeto de Servicios .NET puede obtener detalles relacionando
el aumento de flujo de solicitantes?
4. Qu configuraciones de seguridad de una biblioteca de aplicacin
hereda de su proceso husped y cul puede anularse especficamente?
207
3.5.4. Componentes en Cola

3.5.4.1.
Introduccin a la creacin de colas
El servicio de componentes en cola de COM+ proporciona una manera fcil de

llamar y ejecutar compone ntes de manera asincrnica 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 nmero mximo de subprocesos
simultneos de agente de escucha de componentes en cola. El intervalo vlido
para este valor va de 0 a 1000. Para una aplicacin recin creada, el valor deriva
del algoritmo usado actualmente para determinar el nmero predeterminado de
subprocesos de agente de escucha: 16 multiplicado por el nmero de unidades
de procesamiento (CPU) del servidor. Este valor no impone el nmero de
subprocesos que se ejecutan en todo momento, slo el nmero mximo de
subprocesos posibles. En un servidor inactivo slo habra un subproceso en
ejecucin hasta que se encontraran ms mensajes en la cola. Entonces, el
servidor creara ms subprocesos segn fuera necesario hasta llegar al valor de
MaxListenerThreads. En el ejemplo siguiente se establece en 64 el nmero
mximo de subprocesos de agente de escucha de componentes en cola.
Nota La cadena proporcionada al mtodo Marshal.BindToMoniker puede
contener parmetros opcionales para especificar el nombre del equipo as como
otro tipo de informacin. Vea la seccin "Desarrollar componentes en cola" de
Platform SDK si desea obtener ms informacin.
[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 cmo se
implementa una clase QComponent en el servidor para mostrar un mensaje de
manera asincrnica y se utiliza un cliente para llamar al mtodo DisplayMessage
en un componente en cola.
Servidor
[Visual Basic]
Imports System.Reflection
Imports System.EnterpriseServices
Imports System
208

<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");
}
}
}
209

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. Slo es necesario asegurarse de que la aplicacin se est
ejecutando como aplicacin de servidor (fuera de proceso) y, a continuacin,
definir las propiedades Queued y Listen en la ficha Colas. Una vez definidos
estos valores, la aplicacin cliente puede llamar a componentes de forma
sincrnica o asincrnica. Lo bueno de esta caracterstica es que no hay que
cambiar el cdigo de un objeto COM; slo es necesario cambiar sus
propiedades en el catlogo de COM+.
210

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 catlogo de COM+.
Vamos a agregar un mtodo a la clase COMPlusServices y a llamarlo de forma
asincrnica mediante los servicios de componentes en cola COM+ de una
aplicacin .NET cliente.
Haga que su aplicacin COM+ sea una aplicacin de servidor (fuera de
proceso). Esto es necesario para componentes en cola. Para hacerlo mediante
atributos, agregue el siguiente cdigo al proyecto:
'********************************************
<Assembly: ApplicationActivationAttribute(ActivationOption.Server)>
Agregue soporte para colas al componente. Hgalo accesible a colas MSMQ de
manera que pueda considerar su propia cola para procesar mensajes. Este es el
cdigo para hacerlo mediante atributos:
'********************************************
<Assembly: ApplicationQue uingAttribute(Enabled:=True,
QueueListenerEnabled:=True)>
Agregue un mtodo llamado QueueTest a la clase. Asegrese de que es una
subrutina. No debe devolver ningn valor. Defnalo para que escriba un mensaje
en el Registro de aplicaciones de Windows. El cdigo debera 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 aplicacin de
consola para llamarlo.
1. Cree una nueva aplicacin de consola.
2. Agregue el siguiente cdigo al procedimiento Sub Main de esta aplicacin de
consola.
211

Sub Main()
Dim objTest As COMPlusJumpStart.COMPlusServices
Dim strMoniker
strMoniker = _ "queue:/new:COMPlusJumpStart.COMPlusServices"
objTest = GetObject(strMoniker)
objTest.QueueTest()
End Sub
Este cdigo llama al mtodo QueueTest del componente de forma asincrnica.
Para llamar al mtodo de forma sincrnica, habra que llamarlo como al resto de
los mtodos del componente.
Ahora podemos ejecutar esta aplicacin 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 mensajera asincrnica en un entorno de los
sistemas distribuidos.
2. Explique el propsito del grabador, oyente y componentes del jugador.
3. Liste dos factores que representen que una interfaz es impropia para la
operacin en cola.
4. Liste tres consideraciones generales del diseo de sistemas que utilizan
componentes en cola.
5. Cmo un cliente se instancia en componente en cola?
6. Liste dos maneras de devolver las contestaciones asincrnicas de un
componente en cola a un cliente.
7. Qu efecto realiza marcando una aplicacin como en cola?
8. Qu interfaces realiza un implemento de clase de excepcin?
212
3.5.5. Despliegue y Administracin de Aplicaciones

3.5.5.1. Despliegue de una aplicacin COM+ construida usando los
servicios .NET
Comenzaremos con la descripcin de algunas de las principales diferencias
entre MTS y COM+. A continuacin trataremos la herramienta administrativa
Servicios de componentes y su utilizacin en tres de las tareas administrativas
ms comunes del sistema:
Distribucin de las aplicaciones

Establecimiento de la seguridad basada en funciones y la identidad de
seguridad de una aplicacin
Administracin 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 introduccin
de COM+, la funcionalidad de MTS se ha fundido con el sistema operativo.
Como podr comprobar, COM+ tambin ampla 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 aplicacin COM no es tan nueva. Sencillamente se trata del trmino
que se emplea para referirse a los grupos de componentes COM desarrollados
para trabajar conjuntamente. En las aplicaciones COM tradicionales, los
componentes deban instalarse mediante la configuracin 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
automticamente cuando configura los componentes como aplicacin COM+.
Los componentes COM todava se pueden seguir registrando en Windows 2000
mediante la utilidad Regsvr32 y seguirn 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.
213

Las aplicaciones COM+ constan de uno o varios componentes COM. La clase
COM es la implementacin con nombre, concreta, de una o varias interfaces. La
clase expone sus interfaces, que proporcionan un conjunto de funciones
relacionadas entre s denominadas mtodos. El Objeto COM es un ejemplo de
clase COM. Un componente COM es una unidad binaria de cdigo que crea
objetos COM (entre los que se incluyen el cdigo de empaquetamiento y de
registro).
La clase COM se identifica mediante un identificador de clase (CLSID) y a veces

tambin 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 semntica de la interfaz, y el formato de ordenacin en
bfer.
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 deberan
dividirse en conjuntos de mtodos manejables y coherentes. Recuerde que las
interfaces son inmutables, el contrato COM establece que no se pueden
modificar. Cualquier modificacin (como agregar mtodos) exige la definicin 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 aplicacin
COM+ configurada en parte al administrador del sistema. O bien la aplicacin
puede provenir de una fuente externa, por ejemplo, de la adquisicin de una
aplicacin COM+ a un proveedor de software independiente (ISV). El
administrador puede entonces personalizar la aplicacin para uno o varios
entornos especficos (por ejemplo, mediante la incorporacin de las cuentas de
214

usuario a las funciones y los nombres de usuario en un clster de la aplicacin).
Entre las tareas tpicamente administrativas se incluyen:
Instalar una aplicacin COM+ parcialmente configurada en un equipo

administrativo.
Proporcionar atributos especficos del entorno, como los miembros de
funcin y el tamao del grupo de objetos.
Configurar la identidad (la cuenta de usuario de Windows 2000) con la
que se va a ejecutar una aplicacin COM+.
Reexportar la aplicacin COM+ totalmente configurada.
Crear un proxy de aplicacin (cuando se vaya a tener acceso a la
aplicacin de modo remoto).
Cuando la aplicacin se ha configurado completamente para un entorno

especfico, el administrador puede entonces distribuirla entre los equipos de
prueba o produccin. Esto implica la instalacin de la aplicacin completa COM+
ya configurada en uno o varios equipos.
La herramienta administrativa Servicios de componentes facilita la distribucin
de las aplicaciones COM+ entre mltiples servidores con la ayuda del Asistente
para exportacin de las aplicaciones. Puede utilizar la herramienta administrativa
Servicios de componentes para crear paquetes de instalacin destinados a las
aplicaciones COM+ y los proxy de la aplicacin. COM+ genera paquetes de
instalacin admitidos por Windows Installer que, en un nico archivo, contienen
las piezas necesarias para instalar una aplicacin COM+ en otro equipo.
El archivo .msi que contiene una aplicacin COM+ slo puede ser instalado en
equipos que admitan Servicios COM+ 1.0 (en la actualidad, slo 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 edicin de Windows
Installer.
215

El archivo .msi que genera la herramienta administrativa Servicios de
componentes contiene:
Tablas de Windows Installer con informacin de registro COM+.

Un archivo .apl que contiene los atributos de la aplicacin.
Bibliotecas DLL y de tipos que describen las interfaces que se
implementan en las clases de la aplicacin COM+.
Adems, la herramienta administrativa Servicios de componentes genera un

archivo contenedor (.cab). Este archivo engloba el archivo .msi, permitiendo as
la distribucin de la aplicacin COM+ a travs de Internet Explorer.
Instalar los proxy de al aplicacin COM+
Para tener acceso a una aplicacin de servidor COM+ remotamente desde otro
equipo (cliente), el equipo cliente debe tener un subconjunto de atributos de la
aplicacin del servidor que se haya instalado, incluidas bibliotecas DLL de proxy
o cdigo auxiliar, y bibliotecas DLL y de tipos destinadas al uso remoto de la
interfaz DCOM. Este subconjunto recibe el nombre de proxy de aplicacin.
A travs de la herramienta administrativa Servicios de componentes, puede
exportar fcilmente una aplicacin de servidor COM+ como si fuera un proxy de
aplicacin. Los proxy de aplicacin que genera COM+ son paquetes estndar de
instalacin de Windows Installer. Tras la instalacin, aparecen los proxy de
aplicacin en el panel de control de Agregar o quitar programas en el equipo
cliente.
Cuando se genera un proxy de aplicacin, COM+ proporciona automticamente
la siguiente informacin. Esta informacin es obligatoria para que el proxy de
aplicacin tenga acceso de forma remota a la aplicacin COM+ de servidor.
Informacin de la identidad de la clase (CLSID y ProgID); un proxy de

aplicacin admite hasta dos identificadores de programa (ProgID).
La identidad de la aplicacin y la relacin de las clases hacia las
aplicaciones (AppID).
Informacin de ubicacin por aplicacin (nombre del servidor remoto).
Ordenacin de la informacin para todas las interfaces expuestas por la
aplicacin (por ejemplo, bibliotecas de tipo y proxy o cdigo auxiliar).
Nombres de cola MSMQ e identificadores (si se ha habilitado el servicio
de componentes en cola en la aplicacin).
Atributos de mtodo, interfaz y clase, excepto la informacin de funciones.
Atributos de la aplicacin.
Al contrario que las aplicaciones de servidor COM+, los proxies de aplicacin se

pueden instalar en cualquier sistema operativo que admita DCOM y Windows
Installer. Los clientes de otras plataformas de Windows tambin pueden tener
216

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+), slo se instala el subconjunto de la
informacin exigida para funcionar de modo remoto con DCOM. Esta
informacin se instala en el Registro de Windows. Cuando se instala un proxy de
aplicacin (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 aplicacin COM+. Las funciones son categoras de usuarios que se
han definido para la aplicacin con el propsito de determinar los permisos de
acceso a los recursos de la aplicacin. El programador asigna las funciones
(como si se tratara de categoras simblicas de usuario) a la aplicacin y
potencialmente a las estructuras ms refinadas que incluya, como componentes,
interfaces, mtodos o recursos particulares de aplicacin. Estas asignaciones de
funciones se utilizan por tanto para determinar qu categoras de usuario tienen
permiso para tener acceso a qu elementos dentro de la aplicacin.
Cuando una aplicacin emplea una seguridad basada en funciones, en cada
llamada que se haga en la aplicacin se comprueba la pertenencia como
miembro de la funcin de llamada. Si quien realiza la llamada no pertenece a
una funcin que tenga permiso de acceso al elemento que ha sido llamado, la
llamada fracasar. Quienes realizan las llamadas tienen garantizado su acceso a
la aplicacin o a sus recursos estrictamente segn las restricciones definidas en
las funciones a las que pertenecen.
La labor del administrador del sistema es poblar las funciones que define la
aplicacin con los grupos y las cuentas de usuario de Windows 2000. Esta es
una fase crucial en la aplicacin de la directiva de seguridad de la aplicacin. Se
deben asignar los usuarios a las funciones que representan correctamente sus
relaciones con los datos y recursos a los que podran tener acceso a travs de la
aplicacin.
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 cuestin y, despus, 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 administracin de grandes cantidades de usuarios.
En entornos informticos de empresa, suele ser difcil hacer un seguimiento
eficaz de cada usuario dentro de la organizacin y determinar la forma en que se
asigna a a
l poltica de seguridad basada en las funciones particular de cada
aplicacin. A medida que aumenta el nmero de usuarios, administradores y
217

aplicaciones, esta tarea se vuelve cada vez ms complicada. La solucin ms
escalable es la de asignar grupos de us uarios a las funciones de la aplicacin
COM+.
Antes de asignar grupos a las funciones, es necesario que se asegure de haber
comprendido la poltica de seguridad de la aplicacin. Tericamente, las
funciones deberan llevar nombres que sugirieran quines deberan pertenecer a
ellas, como "Jefes" y "Narradores". Adems, hay descripciones para cada
funcin a la que usted puede tener acceso mediante la herramienta
administrativa Servicios de componentes, que pueden describir los tipos de
usuario que deberan pertenecer a la funcin. Sin embargo, si no est seguro de
qu grupos de usuarios pertenecen a qu funciones, consulte la documentacin
que acompaa a la aplicacin o pregunte al programador.
Puede utilizar la herramienta administrativa Servicios de componentes tanto para

realizar las asignaciones iniciales de las distintas funciones durante la instalacin
de la aplicacin como para efectuar cualquier cambio necesario durante el
tiempo de vida de la aplicacin.
Agrupacin de objetos
La agrupacin de objetos es un servicio automtico 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 caractersticas
que posee, como el tamao del grupo y la solicitud de creacin de valores de
tiempo de espera. Cuando la aplicacin se est ejecutando, COM+ le administra
el grupo, controlando los detalles de la activacin y reutilizacin de los objetos
de acuerdo con los criterios que haya especificado.
218
Puede conseguir un rendimiento muy significativo y escalar las ventajas si

reutiliza los objetos de este modo, particularmente cuando se han diseado para
sacar el mximo partido de la reutilizacin. Usted puede configurar
administrativamente la agrupacin de objetos para obtener el mximo partido de
los recursos de hardware disponibles. La configuracin del grupo puede variar a
medida que cambien los recursos de hardware disponibles. Tambin puede
gobernar el uso de los recursos con la administracin 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 creacin de objetos se tratar a
travs del administrador del grupo.
Al iniciarse la aplicacin, el grupo se poblar hasta el nivel mnimo que usted
haya especificado administrativamente, mientras prospera la creacin de
objetos. Cuando el cliente solicita la entrada del componente, el grupo satisfar
su peticin y servir los componentes por orden de llegada. Si no hay ningn
objeto del grupo disponible y el grupo no se encuentra an en su mximo nivel
especificado, se crea y activa un nuevo objeto para el cliente.
Cuando el grupo alcanza su nivel mximo, las solicitudes del cliente entran en la
cola de trabajo. Cada solicitud recibe el primer objeto disponible del grupo. El
nmero de objetos, tanto activados como desactivados, no sobrepasar nunca el
valor mximo del grupo. El tiempo de espera de las solicitudes de creacin de
objetos se agotar despus de un perodo especificado administrativamente, de
modo que usted pueda controlar el tiempo que tienen que esperar los clientes
para la creacin de objetos. Siempre que sea posible, COM+ intentar reutilizar
219

un objeto una vez que el cliente lo libere, hasta que el grupo alcance su nivel
mximo.
Puede utilizar el tamao mximo de grupo para precisar con mucha exactitud el
modo en que utiliza los recursos. Por ejemplo, si tiene licencia para un cierto
nmero de conexiones de base de datos, puede controlar cuntas conexiones
tiene abiertas en cualquier momento.
Al reflexionar acerca de los pa trones de uso de los clientes, las caractersticas
de uso de los objetos y los recursos fsicos como la memoria y las conexiones,
es probable que descubra un equilibrio ptimo a la hora de ajustar el
rendimiento. La agrupacin 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 dinmico.
2. Cules son los contenidos del archivo .msi que se crea cundo exporta
una aplicacin COM+?
3. Liste las fases de repeticin al usar la herramienta de COMREPL.
4. Liste los pasos para crear una aplicacin COM+ .
220

Atributos
Arriba del
Estndar
En el Estndar
Debajo del
Estndar
Puntos de
Atributo
Obtenidos
(10-9 )
(8.5-7)
(6.5-0)
La informacin
La informacin
La informacin
revisada
revisada permiti
revisada no
permiti a los
permiti a los
estudiantes
la
comprender con
estudiantes
comprender
Informacin
claridad los
comprender
solamente los
ejercicios y
los ejercicios y
ejercicios y
programas.
programas.
programas.
(10-9 )
(8.5-7)
(6.5-0)
Los estudiantes
han demostrado
Los
el significado del
material
elaborando
correctamente,
Conexiones
material
el material,
mientras
Especialistas
extienden y
explican la
informacin,
en su estudio
tema.
incorporndola 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 aceptacin en

aplicaciones distribuidas, por lo que un gran nmero de mecanismos
basados sobre el paradigma estn disponibles, entre ellos los que hemos
tratado hasta el momento:
o Common Object Request Broker Architecture (CORBA).
221
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
aplicacin que expone sus funciones programticamente a travs
de Internet o la intranet utilizando los protocolos estndar de
Internet como son Simple Object Access Protocol (SOAP) para
comunicacin entre programas, y XML para representacin de
datos.
Estndares de Web Services

Los servicios Web se registran y anuncian utilizando los siguientes servicios y
protocolos:
XML (extensible Markup Language), Estructura, describe e intercambia
informacin. Independientemente de mltiples formas, todas las
tecnologas de servicios Web se basan en XML. El diseo 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
estndar permite a las empresas registrarse en un tipo de directorio
seccin amarilla de Internet que les ayuda anunciar sus servicios, de tal
forma que las compaas 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 mtodo de acceso comn a los metadatos
necesarios para determinar su un elemento de cdigo previamente
elaborado es suficiente, y si lo es, cmo 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 mtodos objeto o
funciones, que residen en sistemas remotos. Una aplicacin SOAP crea
una un peticin bloque en XML. proporcionando los datos necesarios para
el mtodo remoto as como la ubicacin misma del objeto remoto.
WSDL (Web Service Description Language), es el estndar propuesto
para la descripcin de los servicios Web, el cual consiste en un lenguaje
de definicin de interfaz (IDL - Interface Definition Language) de servicio
basado en XML, que define la interfaz de servicio y sus caractersticas de
implementacin. 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.
222
Esquema de Implementacin 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/depsito 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 aplicacin que liga el servicio
registrado utilizando SOAP (en el caso de UDDI) y/o ebXML
Se intercambian datos y mensajes XML sobre HTTP
Ejercicio Prctico de Web Services

Creacin de una Aplicacin Web Services en Visual Studio .Net
Paso1: Un servicio Web desde un punto de vista del servidor IIS funciona
exactamente igual que una aplicacin Web. Se aloja en un directorio virtual y
utiliza para su funcionamiento archivos .ASMX, en vez de las pginas .ASPX
que utilizamos en ASP .NET.
223
Crear un directorio fsico donde almacenaremos los archivos necesarios

para el funcionamiento de nuestro servicio Web. Suponiendo que su
directorio raz de su servidor Web IIS sea el directorio raz por defecto
(c:\inetpub \wwwroot\), crearemos un nuevo directorio llamado
WSDemo.
Ejecutar la consola de administracin 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 administracin 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 botn derecho sobre esta carpeta, y elegiremos la
opcin Propiedades.
En la pestaa Directorio, pulsaremos el botn de Crear. Esta operacin lo
que realiza es crear una nueva aplicacin Web de IIS en este directorio
fsico. A partir de este momento, podremos acceder a la direccin
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 continuacin escribimos el cdigo del servicio:

Debemos indicar que vamos a utilizar elementos pertenecientes a la clase
System.WebServices using System.Web.Services;
Delante de los mtodos que queramos que sean accesibles por la Web
aadiremos la clusula [WebMethod], indica al sistema en tiempo de
ejecucin que es un mtodo llamado a travs de HTTP.
Todo Web Service debe ser identificado de forma nica en Internet, la
manera de hacer esto es suministrando una direccin URL. Esta URL
debe ser declarada en un atributo antes de la declaracin de la clase:
[WebService(Namespace=http://localhost/WSDemo)]
Paso3: Solicitamos el Build (Generar) del proyecto e inmediatamente podemos
acceder al servicio a travs del navegador web.
El cdigo de nuestra pgina 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
224

{
public wsdemo()
{}
[WebMethod]
Public Function LlamadaMetodoWSdemo() As String
{
return "Respuesta a wsdemo";
}
}
}
Actividad 3.6
Actividad Web Services
Realizar el ejercicio prctico del Escenario Web Services, colocar informe en
Tarea Individual 3.6
225
Atributos
Arriba del
Estndar
En el Estndar
Debajo del
Estndar
Puntos de
Atributo
Obtenidos
(10-9 )
(8.5-7)
(6.5-0)
La informacin
La informacin
La informacin
revisada
revisada permiti
revisada no
permiti a los
permiti a los
estudiantes
la
comprender con
estudia ntes
comprender
Informaci n
claridad los
comprender
solamente los
ejercicios y
los ejercicios y
ejercicios y
programas.
programas.
programas.
(10-9 )
(8.5-7)
(6.5-0)
Los estudiantes
han demostrado
Los
el significado del
material
elaborando
correctamente,
Conexiones
el material,
material
mientras
Especialistas
extienden y
explican la
informacin,
tema.
en su estudio
incorporndola en
del tema.
el estudio del
tema.
226
4. Lenguajes de Programacin
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 evaluacin.
4.1.1 Antecedentes
Inicialmente, los computadores eran grandes centros de computacin con
entidad propia en centros de investigacin o gubernamentales y Universidades.
Con la introduccin de los PC en los 80, todos pudieron tener parte de esa
capacidad de cmputo. Los PC, mucho ms baratos que minis o mainframes,
fueron una gran aportacin para empresas y particulares.
Aunque el computador personal estaba pensado para ser un elemento de
computacin autnomo y no formar redes de computadores, la posibilidad de
compartir recursos gracias a la comunicacin 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 comunicacin entre dos PC en sistemas UNIX, mejor mucho cuando BSD
introdujo el concepto de socket, que permita que la comunicacin entre
procesos sitos en computadores distintos no fuera mucho ms complicada que
la de un programa que supiese leer y escribir archivos. Los programas que
emplean sockets establecen un protocolo de comunicacin para poder
entenderse.
El RPC, de Sun Microsystems, es el siguiente nivel de abstraccin y permite
realizar llamadas a procedimientos independientemente de su localizacin,
buscando con ello la transparencia de acceso para el programador.
Orientada a Objetos
227
Las tecnologas Orientadas a Objeto, hacen que estas abstracciones orientadas

a procedimiento resulten inadecuadas, y propicia la aparicin de sistemas como
CORBA, RMI y COM/DCOM.
El trmino sistema distribuido hace referencia al uso de objetos por parte de
otros que pueden estar situados o no en la misma mquina, de forma casi
transparente. Los objetos servidores que ofrecen servicios, y de objetos cliente,
que los usan, aunque esta distincin carece de sentido en sistemas distribuidos,
donde un objeto puede adoptar simultneamente ambos roles.
4.1. 2 Java y las Redes
SUN
Java es un entorno de computacin introducido al pblico en 1995 por Sun
Microsystems. Considerado como lenguaje de programacin, es simplemente un
lenguaje cuya sintaxis recuerda la del C++, y tiene, respecto a este, ventajas,
que el marketing de la compaa trata de resaltar, e inconvenientes, que trata de
ocultar, sin embargo, las libreras de clases y el que todos sus programas se
ejecuten en una mquina virtual lo convierten en un lenguaje altamente porttil,
muy apto para una red con computadores y sistemas operativos tan
heterogneos como Internet.
Mquinas Virtuales
El secreto de la portabilidad binaria de los programas java reside en las
mquinas virtuales. Los compiladores Java no generan binarios para una
arquitectura real, sino para una inexistente mquina 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. Adems, viene integrado en cualquier mquina virtual Java posterior a la
1.0 y est pensado para hacer fcil la creacin de sistemas distribuidos a partir
de una aplicacin cuyas clases ya estn implementadas.
CORBA: El estndar de sistemas distribuidos
CORBA es el estndar para la creacin de sistemas distribuidos creado por el
Object Management Group (OMG). Pensado para ser independiente del
228

lenguaje, rpidamente aparecieron implementaciones en las que se poda usar
casi cualquier lenguaje.
DCOM: La alternativa de Microsoft.

Aunque objeto y componente tienen significado distintos, el nombre utilizado en
las tecnologas de Microsoft COM y DCOM, versin distribuida de COM es
componente. COM/DCOM es un sistema de componentes implementado en
todos los sistemas operativos que fabrica Microsoft. La tecnologa para crear
sistemas distribuidos proporcionada por Microsoft es una versin orientada a
componentes del sistema RPC ya comentado.
4.1.4 CORBA.
CORBA, Common Object Request Broker Architecture, es una tecnologa para
crear sistemas distribuidos, creada por un consorcio de fabricantes, agrupados
bajo el OMG.
El estndar CORBA define qu ha de incluir una implementacin estndar, pero
no cmo se han de hacer. Esta tarea se deja de la mano de los diferentes
fabricantes. Esta es una de las principales caractersticas de CORBA: permite
una total libertad a los implementadores siempre que estos respeten unos
mnimos orientados a la interoperabilidad entre implementaciones.
Ventajas
Disponibilidad y Versatilidad
Muchas arquitecturas y sistemas operativos cuentan con una implementacin 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 plyade de
implementaciones del estndar que se adaptan a multitud de posibles
necesidades de los usuarios, generando una competencia que favorece aquellas
implementaciones de mayor calidad y con ms caractersticas.
Adaptacin a Lenguajes de programacin
Adems, es posible emplear los servicios de CORBA desde cualquier lenguaje de
programacin, desde C++, C Java, hasta COBOL Ada.
229
Inconvenientes
Complejidad
Permitir la interoperabilidad de distintos lenguajes, arquitecturas y sistemas
operativos hace que sea un estndar bastante complejo, y su uso no sea tan
transparente al programador como sera deseable:
1. Hay que usar un compilador que traduce una serie de tipos de datos
estndares a los tipos del lenguaje en el que se vaya a programar (IDL).
2. Hay que ser conscientes a la hora de disear qu objetos van a ser
remotos y cules 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 programacin (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 diseo de un programa
pensado para otro, hacen cuela adaptacin sea fastidiosa. Cuestiones como la
colocacin de libreras o las diferentes formas de implementar la gestin de la
concurrencia, hacen difcil la portabilidad del cdigo y obligan al programador a
reciclarse cuando quiere cambiar de ORB. Adems, donde el estndar 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, ncleo de cualquier implementacin
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.
230

2. Empaquetar los parmetros que el cliente pasa al mtodo remoto y el
resultado que el mtodo devuelve al cliente.
3. Localizar al objeto remoto a partir de una referencia.
El IDL
IDL (Interface Definition Language) es un lenguaje de programacin pensado
exclusivamente para especificar los interfaces de las clases cuyas instancias
queremos hacer pblicas 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 programacin. Distintos lenguajes soportan
diferentes tipos de datos y tienen distintas formas de especificar clases. Incluso
limitndonos aun lenguaje, la ordenacin y el tamao 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 tamao de sus
especificaciones. El compilador de IDL transforma una especificacin 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 comunicacin 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.
Gestin de la concurrencia.
El comportamiento de un objeto situado en un servidor cuando dos o ms
clientes quieren hacer uso de sus servicios viene determinado por la poltica de
gestin de la concurrencia que se haya programado en el ORB. CORBA incluye
varias polticas que definen cundo y cmo 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
231

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 mquina pueda
referirse a otro remoto.
IOR
Nmero 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
automticamente 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
implementacin del ORB, etc.
Asignacin de Nombres
Dndole previamente un nombre al objeto, otro que quiera usar sus servicios
podra
emplear
una
notacin
tipo
URL
como
iiop://nombre_host:puerto/nombre_objeto6. As, si en mquina.inf.uniovi.es,
existe el objeto dns, cualquiera que quiera acceder a dns slo tiene que solicitar
a su ORB una referencia a iiop://mquina.inf.uniovi.es/dns. Esta forma de
nombrado es ms fcil 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 lmites de la mquina en la que se registre).
Ambos sistemas de nombrado tienen el inconveniente de no ser transparentes
en cuanto a la localizacin 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 suscripcin de eventos, que
permite que un objeto se suscriba a eventos generados por otro. El propsito de
este servicio es el de mejorar la eficiencia disminuyendo el trfico 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), podran
solicitarle a este que les enve una notificacin cuando eso ocurra.
Seguridad.
232
El estndar CORBA no se preocupa de la seguridad implementada en el sistema

distribuido. Si por alguna razn se requiere restringir el uso de los recursos
controlados por un determinado objeto, debe hacerlo el usuario.
Integracin de CORBA en Java

CORBA, como especificacin, 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 bsicos de Java y en
un framework, que permiten acceder a la librera de servicios del ORB. Algunas
de estas libreras son nativas, en vez de emplear implementaciones 100% Java
para soportar Java, lo que puede dar algunos problemas de portabilidad o
imposibilitar la ejecucin de aplicaciones dentro de los navegadores con soporte
para Java.
Pero la integracin Java-CORBA incluir interesantes mejoras cuando OMG
introduzca la nueva versin del estndar, CORBA 3.0. De hecho, parte de la
mejora en esta integracin es justo lo inverso de lo que haba hasta ahora: una
correspondencia java -idl. Al contrario que el compilador de IDL a Java, que
convierte una especificacin 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 especificacin IDL, por lo que ser ms fcil emplear clases java
por programas que usen CORBA y que estn 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 inicializacin del mismo. En vez de
inicializarlo normalmente, hay que pedir al ORB (va IOR o usando un
nombre ms 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 mtodos de un objeto remoto (al que se accede
por referencia), solo se le pueden pasar como parmetros (y el mtodo 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 parmetros por valor.
233

3. Mltiples implementaciones de CORBA dan lugar a mltiples
incompatibilidades. El estndar CORBA define a alto nivel qu funciones
debe proporcionar un ORB y cmo han de interoperar estos entre s, lo que
garantiza cierto grado de compatibilidad, pero el cmo se ofrezca esa
funcionalidad al programador es algo que est al libre albedro del fabricante
del ORB. Es ms, parte de la funcionalidad del estndar CORBA no es de
obligado cumplimiento por parte de las compaas fabricantes para poder
anunciarse como CORBA-compliant. En estas condiciones es muy difcil
pensar que un programa que haya sido programado pensando en un ORB
concreto, pueda funcionar bien con una simple recompilacin.
4. El estndar CORBA est poco preparado para usarse en entornos
embebidos (electrnica 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 ms 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 librera de clases de Java que
permite la creacin de sistemas distribuidos en Java.
Caractersticas particulares de RMI.
Al contrario que otras tecnologas de sistemas distribuidos, RMI no busca la
colaboracin de objetos de distintas plataformas, programados indiferentes
lenguajes, Java se encarga de solucionarlos problemas de heterogeneidad. As,
su API es ms sencillo y natural al no contemplar que tipos de datos (y sus
tamaos) existan o no en los lenguajes en los que se implementan cliente y
servidor.
Gestin de la concurrencia.
La gestin 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, compartirn 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. An as, est pensado de tal forma
234

que difcilmente su uso crear problemas al usuario, ya que emplea la notacin
URL del tipo rmi://nombre_host:puerto/nombre_objeto.
Un programa que acompaa 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 mquina (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 parmetros por valor y serializacin.
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 automticamente por
referencia a cualquier cliente que quiera usarlo.
La novedad es el paso de objetos por valor, para lo que se emplea la librera de
serializacin del API de Java. Para pasar un objeto por valor del servidor el
cliente, debe implementar una clase abstracta que les obliga a definir cmo
almacenar en un flujo de datos (como por ejemplo un archivo) los datos
importantes del objeto serializable y cmo 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 agregacin) no tienen que ocuparse de
serializarlas.
Cuando se necesita llevar un objeto serializable de una mquina a otra (porque
sea un parmetro de un mtodo de un objeto remoto que empleamos por
referencia, o porque sea el resultado que devuelve dicho mtodo al cliente), se
serializa, se lleva el flujo de una mquina a la otra, y una vez en el computador
husped, se reconstruye y se usa.
La ventaja del paso por valor en un sistema distribuido radica en que se
minimiza el trfico en la red ya que, una vez recibido el objeto, todas las
comunicaciones con l sern 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
235

trabajo l mismo. An as, no se puede confiar en la seguridad de un sistema
solo porque se haya autentificado al usuario al inicio de la conexin si es que el
canal de comunicacin no es seguro. La plataforma Java 2incluye el soporte de
comunicaciones seguras en RMI usando el estndar SSL (Secure Sockets
Layer).
4.1.6 DCOM/COM/COM+
COM se refiere tanto a especificacin como aplicacin, desarrollado por
Microsoft que provee una infraestructura para integracin de componentes.
Soporta interoperabilidad y reutilidad de objetos distribuidos.
COM define una interfaz de programacin de aplicaciones (API) para permitir la
creacin 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 extensin a COM que permite interaccin de
componentes basados en red. Mientras los procesos de COM pueden ejecutar
en la misma mquina pero la extensin 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 tecnologa que provee un
rango de servicios a la interaccin del componente, de servicios que promueven
la integracin del componente en una sola plataforma, a la interaccin del
componente por las redes heterogneas. De hecho, se unen COM y sus
extensiones de DCOM en un solo tiempo de ejecucin. Este solo tiempo de
ejecucin proporciona cercana y acceso remoto.
MTS extiende las capacidades del COM con servicios como transaccin y
seguridad. COM+ es la evolucin de COM. COM+ integra servicios de MTS y
mensaje en cola en COM y hace COM que se programa ms fcil a travs de
una integracin ms 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 segn un
236

estndar de sistemas distribuidos, desde otro diferente. Un ejemplo es la
integracin entre COM y CORBA desarrollada por IONA Technologies.
Asimismo, OMG y Sun estn trabajando para hacer que CORBA y RMI sean
interoperables de manera transparente al programador y al usuario. Adems, la
plataforma Java 2 viene con soporte de RMI y de CORBA simultneamente.
El rendimiento es menor, lo que se agrava especialmente si la comunicacin
entre dos objetos implementados en estndares distintos es intensa. Adems, la
interoperabilidad suele suponer tener que conformarse con el mnimo comn
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
Introduccin
EJB (Enterprise Java Beans) es una tecnologa establecida para implementar
componentes de software en una plataforma Java. EBJ puede usarse para crear
sistemas de objetos distribuidos y confa en Java RMI/IIOP para intercambiar los
mensajes; EJB tambin puede exponerse como servicios Web.
En la visin de Microsoft, la prxima generacin de sistemas distribuidos es
comunicar con Web Services. Web Services son mayores cuando integran
sistemas heterogneos flojamente acoplados, pero tiene sus limitaciones
tambin: no tiene n el apoyo por las referencias del objeto remotas. En la
prctica, son sin estado y ms cercano a una llamada del mtodo remota que a
un sistema del objeto distribuido.
J2EE y .NET son dos mundos similares pero desarticulados: pueden
actualmente interactuar slo usando juntos Web Services. Ambas plataformas
ofrecen grandes mecanismos por construir los sistemas de objeto distribuidos
hermticamente acoplados: Remoting de .NET y RMI de Java, pero ambos
confan en estndares incompatibles. Aunque, Remoting .NET es configurable:
un formateador diferente para la serializacin y deserializacin de los objetos
junto con un canal de transporte diferente puede proporcionarse fcilmente.
237
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 tambin en la direccin opuesta:
cmo tener acceso a un Java EJB el servicio de un cliente de .NET tambin
utilizando el canal remoto IIOP.NET, ninguna modificacin en el sitio de EJB se
requiere para este propsito. Esto ltimo es el caso de estudio de esta seccin.
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 estndar de CORBA, el mismo usado por Java
RMI/IIOP. IIOP.NET acta 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 aplicacin 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
caractersticas 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 aplicacin siguiente le mostrar cmo 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
automticamente.
238
Prctica: Un servicio de conversacin (chat) usando IIOP.NET

Escenario
Para mostrar cmo 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 conversacin; 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 mquina 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 conversacin que desean recibir los mensajes de conversacin. La interfaz
extiende java.rmi.Remote debido a que los clientes son remotos y la
comunicacin 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 conversacin define las caractersticas
soportado por el bean sin estado, que permite enviar los mensajes y administrar
la lista de oyentes. La interfaz de inicio contiene slo 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;
239
/* 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 conversacin funciona segn el diagrama de secuencia de UML
siguiente:
Diagrama de secuencia de la sala de conversacin

Paso 1: Instale IIOP.NET
Construir y ejecutar el ejercicio, necesita un Java SDK por lo menos 1.3, un
servidor de la aplicacin (suponemos IBM WebSphere 5.0), el Framework .NET
SDK 1.0 o 1.1, el Microsoft J# SDK versin 1.0 o 1.1 e IIOP.NET (por lo menos
1.3.1).
El IIOP.NET contiene los directorios:
240
IIOPChannel contiene el cdigo del canal
CLSToIDLGenerator contiene un generador para crear los archivos de

definicin IDL desde un assembly de .NET.
IDLToCLSCompiler contiene un generador para crear archivos CLS

(.Asamblies multi-mdulos 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 aplicacin de servidor de WebSphere.
Compile todo mediante nmake.
Paso 2: Implementacin del EJB
Dado las definiciones anteriores, la aplicacin del EJB realmente es clara .
Creamos la clase Message, las interfaces MessageListener y Chatroom
conteniendo las definiciones mostradas anteriormente.
Para la implementacin del bean, se proporcionan tres archivos: la interfaz de
inicio del bean en la interfaz ChatroomHome, el propio bean en ChatroomBean,
y la implementacin clase administracin en ChatroomServer. La administracin
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 administracin 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 {
241

listeners[i].notifyMessage(msg);
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 conversacin (durante la cual la sala de
conversacin se bloquea). Enviando los mensajes puede tomar un tiempo largo,
en particular cuando un cliente no esta disponible. La solucin ideal aqu sera
un CORBA unidireccional llamada asincrnica, 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 aplicacin 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);
242

}
}
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 mtodo de implementacin getClients () devuelve una copia de la
lista del oyente para evitar los problemas de la sincronizacin.
Paso 3: Generacin de los archivos de IDL
Una vez que el servicio es implementado, el prximo paso es la generacin de
archivos de IDL que describen la interfaz de servicio mediante el modelo del
CORBA.
Cada servidor de la aplicacin proporciona su propia manera de generar el IDL,
porque cada servidor de la aplicacin funciona con versiones diferentes de
especificaciones del EJB que a su vez tienen las interfaces diferentes.
Refirase a la documentacin de servidor de aplicacin para el procedimiento
exacto para generar los archivos de IDL.
El paso 4: Generacin de los mdulos CLS desde los archivos de IDL
De los archivos de IDL, la herramienta IDLToCLSCompiler genera un assembly
multimdulo 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 ms importantes son la simplicidad y portabilidad.
Primero, los netmodules son bastante fciles de generar usando la interfaz de
reflexin emitada de .NET; el cdigo fuente generador requerira algn 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 cdigo est en C# o Visual Basic.
Invoque el generador que especifica el directorio de salida (- o) y los archivos idl
para usar.
243

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 implementacin para
algunas clases: stas son las clases que implementa el valuetypes del CORBA;
en .NET estas clases estn 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 mtodos que proporciona
tambin deben estar disponibles en el sistema remoto. Debido a que el IDL no
contiene ningn cdigo, tiene que proporcionar este cdigo (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). Algn EJBs puede requerir la definicin de
adicional clases.
Nuestra aplicacin 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
implementacin para la clase valuetype de CORBA. As, las clases para proveer
son nombradas NotRegisteredExceptionImpl, AlreadyRegisteredExceptionImpl, y
as sucesivamente.
244
Paso 5: Implementacin del cliente en C#

El cliente proporciona una interfaz del usuario para coleccionar los mensajes del
usuario, invoque el servicio y despliegue la informacin 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 aplicacin 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 conversacin 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);
245

MessageBox.Show("an exception occured, while broadcasting!");
}
Este cdigo realiza una invocacin del mtodo sincrnico, es decir espera para
el servidor para completar la difusin 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 invocacin asincrnica
tambin 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 mtodo oyente notifyMessage() se llamar por los servicios EJB siempre que
un nuevo mensaje est disponible. Este mtodo lleva a cabo el proceso de
llamadas entrantes por el cliente.
Paso 6: Ejecucin de la aplicacin
En el lado del servidor, el Makefile para el servicio EJB Websphere
automticamente registra al servidor de la aplicacin, para que necesite arrancar
el servidor (en caso de que ya no est corriendo).
En el lado del cliente, lance la aplicacin; entonces establezca su nombre,
conecte al servidor y podr enviar y recibir los mensajes.
246
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 tcnica de Aprendizaje Orientado a Proyectos, descrito en el rubro de
Panorama General del tema 3 de tecnologas de desarrollo, para desarrollar un
sencillo proyecto de sistema distribuido, propuesto por ustedes.
Rbrica para evaluacin del proceso de AOP
Atributos
Arriba del
Estndar
En el Estndar
Debajo del
Estndar
Puntos de
Atributo
Obtenidos
(10-9)
(8.5 -7)
(6.5-0)
El producto final
La
Trabajo en equipo
del equipo ha
presentacin es
con asignacin de
sido compartido
el resultado del
roles y todos se
Colaboracin con todo el
esfuerzo de un
esfuerzan en
equipo y
grupo, pero
llevar a cabo sus
representa algo
solamente han
responsabilidades.
que habra sido
contribuido
247

posible llevar a
cabo
individualmente.
(10-9)
Contenido
(8.5 -7)
algunos
miembros del
grupo.
(6.5-0)
El proyecto se
El proyecto
presenta de
presenta metas
El proyecto
cualquier
claras
presenta
manera, de
informacin de
relacionadas
forma
con un tpico o
una manera
apresurada o
precisa y
asunto
todava sin
importante. El
organizada. El
finalizar.
proyecto es til proyecto es til
Presenta
dentro del curso.
ms all del
errores o malas
curso.
comprensiones.
5. Computacin Mvil
Actividades Computacin Mvil
Revisar el Material de Apoyo 5 y realizar las tareas siguientes:
1. Realizar un mapa mental por cada uno de los rubros siguientes sobre
computacin mvil:
1.1 Antecedentes
1.2 Paradigmas
1.3 Lenguajes y Ambientes de Programacin
2. Realizar el ejercicio sobre Aplicaciones Mviles.
Nota: Si no cuenta con software para mapas mentales, puede realizarlos a mano
y enviar escaneados.
5.1. Antecedentes en Computacin Mvil.

5.1.1. Introduccin a la comunicacin inalmbrica.
248

El simple hecho de ser seres humanos nos hace desenvolvernos en medios
donde tenemos que estar comunicados. Por eso la gran importancia de la
transmisin y la recepcin de informacin, y en la poca actual donde los
computadores hacen parte de la cotidianidad, es necesario establecer medios de
comunicacin eficaces entre ellos.
Los sistemas distribuidos utilizan redes de rea local, redes de rea extendida e
interredes para comunicarse. Los cambios en las necesidades de los usuarios
han producido la irrupcin de las redes inalmbricas.
La tecnologa inalmbrica es una de las ms prometedoras y discutidas en esta
dcada para poder comunicar computadoras. La conexin de computadoras
mediante Ondas de Radio o Luz Infrarroja, actualmente est siendo
ampliamente investigada. Las Redes Inalmbricas facilitan la operacin en
lugares donde la computadora no puede permanecer en un solo lugar, como en
almacenes o en oficinas que se encuentren en varios pisos. Pero la realidad es
que esta tecnologa est todava en paales y se deben de resolver varios
obstculos tcnicos y de regulacin antes de que las redes inalmbricas sean
utilizadas de una manera general en los sistemas de cmputo de la actualidad.
No se espera que las redes inalmbricas lleguen a remplazar a las redes
cableadas. Estas ofrecen velocidades de transmisin mayores que las logradas
con la tecnologa inalmbrica. Mientras que las redes inalmbricas actuales
ofrecen velocidades de 2 Mbps, las redes cableadas ofrecen velocidades de 10
Mbps y se espera que alcancen velocidades de hasta 100 Mbps. Los sistemas
de Cable de Fibra ptica logran velocidades an mayores, y pensando
futuristamente se espera que las redes inalmbricas alcancen velocidades de
solo 10 Mbps.
Sin embargo se pueden mezclar las redes cableadas y las inalmbricas, y de
esta manera generar una "Red Hbrida" y poder resolver los ltimos metros
hacia la estacin. Se puede considerar que el sistema cableado sea la parte
principal y la inalmbrica le proporcione movilidad adicional al equipo y el
operador se pueda desplazar con facilidad dentro de un almacn o una oficina.
5.1.2 Conceptos de Comunicacin Inalmbrica.
5.1.2.1. Propagacin de seal.
Las comunicaciones inalmbricas pueden, en un principio, desarrollarse en
medios que soporten ondas sonoras, de radio o luminosas. Sin embargo nos
concentraremos en la propagacin de las ondas electromagnticas de radio
dentro del rango de frecuencias que va desde algunos cientos de MHz a unos
pocos GHz.
249

El espectro electromagntico, el recurso natural de las comunicaciones por el
espacio, se encuentra en su punto mximo de congestionamiento. Esto
constituye evidencia de que a pesar del uso extenso de medios de transmisin
como la fibra ptica; la transmisin de informacin por el aire contina siendo el
mecanismo ms econmico y verstil de cuantos existen para el transporte de
informacin. Las ondas electromagnticas viajan desde una antena transmisora
hasta otra receptora. EL flujo de informacin que estamos proponiendo se
realizara a travs de dos dispositivos emisores receptores (antenas) que
obtendrn la seal anloga del medio fsico en que se encuentren,
posteriormente esta seal ha de ser sometida a un proceso de converso anlogo
digital o viceversa segn sea el caso, finalmente con la informacin digital se
hace su captura a travs del puerto paralelo y de esta manera los computadoras
pueden trabajar con dicha informacin.
5.1.2.2 Desvanecimiento de la Seales
El desvanecimiento de la seal es la perdida de informacin que se da por el
medio de propagacin de la informacin. En general, toda seal enviada esta
sujeta a las variaciones naturales de las condiciones atmosfricas debidas a
efectos climatolgicos de origen local y tambin extraterrestre, como el caso de
las manchas solares y la radiacin csmica las cuales ejercen un efecto muy
marcado sobre la ionosfera.
Sin embargo el estudio sistemtico de los mecanismos y las condiciones que los
favorecen, ha permitido el uso confiable de la propagacin de ondas de radio en
el espacio para comunicaciones de largo alcance. A pesar de las muchas
variables y factores que tienden a degradar la calidad de las comunicaciones
obtenidas, los ingenieros de comunicaciones han desarrollado tcnicas tales
como la diversidad espacial y de frecuencia, que mejoran considerablemente la
confiabilidad y calidad de las transmisiones por ondas de radio.
5.1.2.3. Ancho de Banda
El Ancho de Banda, es el espectro de frecuencia que soporta un medio de
transmisin y su unidad de medida es el Hertz. El ancho de Banda es la regin
comprendida entre las frecuencias mnimas y mximas que puede transmitir el
medio.
250
El ancho de banda es un componente muy importante en las comunicaciones de

datos, ya que la capacidad (medida en bit por segundos) de un canal de
comunicaciones, depende del ancho de banda del camino. Si en el canal de
comunicaciones se incrementa el ancho de banda de 3 khz (300-3300 Hz) a 23
Khz, podra transmitirse todas las caractersticas de la voz. Esto tambin es
vlido para la transmisin de datos. Se consigue una tasa de transmisin de
datos mejor cuando mayor sea el ancho de banda.
El ancho de banda total de un sistema de una red es la medida de la
productividad (throughput), del volumen del trfico que puede ser transferido a
travs de la red en un intervalo de tiempo dado. En muchas tecnologas de red
local, como Ethernet, se utiliza toda la capacidad de transmisin de la red en
cada transmisin y el ancho de banda es igual a la tasa de transferencia de
datos (es la velocidad a la cual se pueden transferir datos entre dos
computadoras en una red). En cambio, la mayora de las redes de rea extensa
los mensajes pueden ser transmitidos simultneamente sobre varios canales
diferentes, de modo que el ancho de banda no guarda una relacin directa con
la tasa de transferencia. Por lo que el ancho de banda depender esencialmente
de la tecnologa de la red utilizada.
El ancho de banda se suele asimilar al dimetro de una tubera que sirviese para
canalizar el flujo de datos. Pero esa simplificacin es excesiva. De entrada el
ancho de banda es la capacidad de una lnea para transmitir informacin.
Algunos sistemas de comunicacin no utilizan la forma analgica (CA) de
transmisin. Una forma ms sencilla la constituye la transmisin por corriente
continua (CC). Las seales CC se parecen a las ondas cuadradas simtricas
que slo pueden tomar los valores discretos de 1 y 0. Sin embargo, el transmisor
CC no emplea la forma de onda oscilante, sino la existencia o no de pulsaciones
de energa elctrica. Adems la seal CC se transmite tal como es, sin
superponerla con ninguna otra seal o frecuencia.
Si bien, tanto las seales CC como las CA se pueden emplear para transmitir
flujos de informacin digital, el modo CA se utiliza para transmisin de larga
distancia.
251
La Red Telefnica est diseada para transmitir la voz, que es una seal con un
ancho de banda pequeo. Para obtener suficiente fidelidad en la voz, se
requiere un espectro de frecuencia de 300 Hz a 3,300 Hz. Este espectro de
frecuencia de los circuitos limita el nmero de bits por segundo, alcanzable. Los
factores que limitan la capacidad de transmisin son el ancho de banda, la
potencia de la seal y el ruido en el conductor.
La Tasa de Transferencia define la capacidad de bits trasmitidos por segundo,
emite en BPS (Bits por Segundo). Es directamente proporcional al ancho de
banda.
Modos de Transmisin
El modo Banda Base utiliza todo el ancho de banda, por tanto en un instante
dado slo puede transmitir una seal. En este modo de transmisin, la seal no
es modulada, no es adecuada para la transmisin a largas distancias, ni para
instalaciones sometidas a nivel alto de ruidos e interferencias.
El modo Banda Ancha modula la informacin sobre ondas portadoras
analgicas, por lo que se requiere de equipos de transformacin llamados
Modem-Modulado/Demodulador- , es ms inmune a los ruidos, pero ms caro y
difcil de instalar.
252
5.1.2.4. Modulacin de seales

Muchas seales de entrada no pueden ser enviadas directamente hacia el canal,
como vienen del transductor. Para eso se modifica una onda portadora, cuyas
propiedades se adaptan mejor al medio de comunicacin en cuestin, para
representar el mensaje.
Aqu presentamos algunas definiciones:
"La modulacin es la alteracin sistemtica de una onda portadora de acuerdo
con el mensaje (seal modulada) y puede ser tambin una codificacin".
"Las seales de banda base producidas por diferentes fuentes de informacin no
son siempre adecuadas para la transmisin directa a travs de un a canal dado.
Estas seales son en ocasiones fuertemente modificadas para facilitar su
transmisin."
Una portadora es una seal senoidal de alta frecuencia, y uno de sus
parmetros (tal como la amplitud, la frecuencia o la fase) se vara en proporcin
a la seal de banda base. Dependiendo del parmetro que se module, se
obtiene la modulacin en amplitud (AM), la modulacin en frecuencia (FM), o la
modulacin en fase (PM).
253
Es interesante hacer hincapi en que muchas formas de comunicacin no

elctricas tambin encierran un proceso de modulacin, y la voz es un buen
ejemplo. Cuando una persona habla, los movimientos de la boca ocurren de una
manera ms bien lenta, del orden de los 10 Hz, que realmente no pueden
producir ondas acsticas que se propaguen. La transmisin de la voz se hace
por medio de la generacin de tonos portadores, de alta frecuencia, en las
cuerdas vocales, tonos que son modulados por los msculos y rganos de la
cavidad oral. Lo que el odo capta como voz, es una onda acstica modulada,
muy similar a una onda elctrica modulada.
Razones Para Modular
Existen varias razones para modular, entre ellas:
Facilita la PROPAGACIN de la seal de informacin por cable o por el
aire.
254
Ordena el RADIOESPECTRO, distribuyendo canales a cada informacin

distinta.
Disminuye DIMENSIONES de antenas.
Optimiza el ancho de banda de cada canal
Evita INTERFERENCIA entre canales.
Protege a la Informacin de las degradaciones por RUIDO.
Define la CALIDAD de la informacin trasmitida.
Modulacin para facilidad de radiacin: Una radiacin eficiente de energa

electromagntica requiere de elementos radiadores (antenas) cuyas
dimensiones fsicas sern por lo menos de 1/10 de su longitud de onda. Pero
muchas seales, especialmente de audio, tienen componentes de frecuencia del
orden de los 100 Hz o menores, para lo cual necesitaran antenas de unos 300
km de longitud si se radiaran directamente. Utilizando la propiedad de traslacin
de frecuencias de la modulacin, estas seales se pueden sobreponer sobre
una portadora de alta frecuencia, con lo que se logra una reduccin sustancial
del tamao de la antena. Por ejemplo, en la banda de radio de FM, donde las
portadoras estn en el intervalo de 88 a 108 MHz, las antenas no deben ser
mayores de un metro.
donde ? es la longitud de onda en mts.

c es la velocidad de la luz (3 x 10 8 m/s)
f es la frecuencia en Hz
Modulacin para reducir el ruido y la interferencia: Se ha dicho que es
imposible eliminar totalmente el ruido del sistema. Y aunque es posible eliminar
la interferencia, puede no ser prctico. Por fortuna, ciertos tipos de modulacin
tiene la til propiedad de suprimir tanto el ruido como la interferencia. La
supresin, sin embargo, ocurre a un cierto precio; generalmente requiere de un
ancho de banda de transmisin mucho mayor que el de la seal original; de ah
la designacin del ruido de banda ancha. Este convenio de ancho de banda para
la reduccin del ruido es uno de los intereses y a veces desventajosos aspectos
del diseo de un sistema de comunicacin.
Modulacin por asignacin de frecuencia: El propietario de un aparato de
radio o televisin puede seleccionar una de varias estaciones, an cuando todas
las estaciones estn transmitiendo material de un programa similar en el mismo
medio de transmisin. Es posible seleccionar y separar cualquiera de las
estaciones, dado que cada una tiene asignada una frecuencia portadora
diferente. Si no fuera por la modulacin, solo operara una estacin en un rea
dada. Dos o ms estaciones que transmitan directamente en el mismo medio,
sin modulacin, producirn una mezcla intil de seales interferentes.
255
Fuente: COFETEL
Modulacin para multicanalizacin: A menudo se desea transmitir muchas

seales en forma simultnea entre dos puntos. Las tcnicas de multicanalizacin
son formas intrnsecas de modulacin, permiten la transmisin de mltiples
seales sobre un canal, de tal manera que cada seal puede ser captada en el
extremo receptor. Las aplicaciones de la multicanalizacin comprenden
telemetra de datos, emisin de FM estereofnica y telefona de larga distancia.
Es muy comn, por ejemplo, tener hasta 1,800 conversaciones telefnicas de
ciudad a ciudad, multicanalizadas y transmitidas sobre un cable coaxial de un
dimetro menor de un centmetro.
Modulacin para superar las limitaciones del equipo: El diseo de un
sistema queda generalmente a la disponibilidad de equipo, el cual a menudo
presenta inconvenientes en relacin con las frecuencias involucradas. La
modulacin se puede usar para situar una seal en la parte del espectro de
frecuencia donde las limitaciones del equipo sean mnimas o donde se
encuentren ms fcilmente los requisitos de diseo. Para este propsito, los
dispositivos de modulacin se encuentran tambin en los receptores, como
ocurre en los transmisores.
256

Como Se Modula
Frecuentemente se utilizan dispositivos electrnicos SEMICONDUCTORES con
caractersticas no lineales (diodos, transistores, bulbos), resistencias,
inductancias, capacitores y combinaciones entre ellos. Estos realizan procesos
elctricos cuyo funcionamiento es descrito de su representacin matemtica.
s(t) = A sen (wt + @ )
donde:
A es la amplitud de la portadora (voltios)
w es la frecuencia angular de la portadora (rad/seg)
@ es el ngulo de fase de la portadora (rad)
Tipos De Modulacin
Existen bsicamente dos tipos de modulacin:
Modulacin Analgica: Se realiza a partir de seales analgicas de

informacin, por ejemplo la voz humana, audio y video en su forma
elctrica. Algunos ejemplos de Modulacin Analgica son: AM, FM, PM.
Modulacin Digital: Se lleva a cabo a partir de seales generadas por
fuentes digitales, por ejemplo una computadora. Algunos ejemplos de
Modulacin Digital son: ASK, FSK, PSK, QAM.
Relaciones Entre el Canal Y la Seal

Depende del medio o canal, ya que hay unos mejores que otros, aunque
tambin depende del tipo de modulacin y aplicacin.
Los principales efectos que sufre la seal al propagarse son:
Atenuacin
Desvanecimiento
Ruido Blanco aditivo
Interferencia externa
Ruido de fase
Reflexin de seales
Refraccin
Difraccin
Dispersin
Relaciones Entre Modulacin Y el Canal

El canal influye fuertemente en la eleccin del tipo de modulacin de un sistema
de comunicaciones, principalmente debido al ruido.
257

El canal nos afecta negativamente en la comunicacin ya que genera Distorsin,
Interferencia y Atenuacin. En cambio, la modulacin nos da inmunidad al ruido,
proteccin de la calidad de la informacin y nos ayuda a evitar la interferencia.
5.1.3. Localizacin en espectro de frecuencia

En las siguientes tablas vemos los espectros de frecuencias que se tienen
contemplados y los sistemas que utilizan cada una de ellas.
Banda
VLF
Significado
Very Low Frecuency
Rango de frecuencias
3 KHz-30 KHz
LF
Low Frecuency
30 KHz-300 KHz
MF
Medium Frecuency
300 KHz-3 MHz
HF
High Frecuency
3 MHz-30 MHz
VHF
Very High Frecuency
30 MHz-300 MHz
UHF
Ultra High Frecuency
300 MHz-3 GHz
SHF
Super High
Frecuency
3 GHz 30 GHz
EHF
Extremely High
Frecuency
30 GHz en adelante
Infrarrojo
300 GHz-430 THz
Luz visible
430 THz-750 THz
Servicios
Radio navegacin de largo
alcance y comunicacin
submarina
Navegacin martima, control de
trfico areo
Radio AM, radio martima,
buscadores autodireccionables
(RDF)
Radioaficionados, comunicaciones
militares, larga distancia, aviones y
barcos.
Radio FM, TV, radio AM de
aviones y ayuda a la navegacin
area.
TV UHF, telefona mvil, WLL
(Wireless Lo cal Loop),
comunicaciones mviles,
comunicacin microondas (a partir
de 1 GHz)
Servicios por satlite y
microondas, MMDS (Multichannel
Multipoint Distribution Service),
LMDS (Local Multipoint
Distribution Service), Radar.
Radar, satlite, LMDS
WPANs (Wireless Personal Area
Networks)
Fibras pticas
258

Esta tabla muestra las especificaciones de las normas de la IEEE en cuanto a
comunicaciones inalmbricas se refiere, lo cul est contemplado en el estndar
IEEE 802.11 en sus diferentes versiones.
Especificacin
Estatus
Mxima tasa de
bits
IEEE 802.11
Utilizado por la mayora de 2 Mbps
fabricantes de WLANs
IEEE 802.11b
Especificacin reciente
11 Mbps
IEEE 802.11g
En desarrollo
54 Mbps
HiperLAN
Desarrollado por ETSI
24 Mbps
Bluetooh
Promovido por 3Com,
1 Mbps
Ericson, IBM, Intel
Microsoft, Motorola, Nokia
y Toshiba.
IEEE: Institute of Electrical and Electronic Engineers
ETSI: European Telecomunications Standards Institute
Frecuencia de
operacin
2.4 GHz
2.4 GHz
5.0 GHz
5.0 GHz
2.4 GHz
5.1.4. Diferencias entre sistemas almbricos e inalmbricos.
Los sistemas inalmbricos estn reduciendo costos en cuanto al canal de

transmisin.
En cuanto a la tecnologa utilizada el hardware de los sistemas
inalmbricos es ms costoso por el momento, aunque se piensa que en
un futuro sern del mismo o similar valor.
Con la tecnologa se facilitan la operacin en lugares donde la
computadora no puede permanecer en un solo lugar o estemos en
movimiento constante.
Las redes cableadas ofrecen velocidades de transmisin mayores que las
logradas con la tecnologa inalmbrica.
El hardware empleado para los sistemas inalmbricos es ms pequeo
que el que se utiliza en los sistemas almbricos.
5.1.5. Sistemas Mviles

Los avances tecnolgicos en la miniaturizacin de dispositivos y en redes
inalmbricas han llevado cada vez mas a la integracin de dispositivos de
computaciones pequeos y porttiles, estos dispositivos incluyen laptops,
dispositivos de mano (handheld) entre los que se incluyen asistentes digitales
personales (PDA), telfonos mviles, videocmaras, cmaras digitales.
259

La facilidad de transporte de muchos de estos dispositivos, junto con su
capacidad para conectarse adecuadamente en diferentes lugares, hacen posible
los sistemas mviles.
Sistemas Distribuidos: Marco conceptual y base algortmica que sirve de base
para abordar trabajos que involucran a dos o ms computadoras conectados en
red. En la dcada de los noventa surge el campo de la computacin mvil,
basada en los principios de los sistemas distribuidos y a partir de la necesidad
de integrar, en este tipo de arquitectura de computadoras, clientes mviles.
Conceptos asociados a este paradigma, actualmente un campo muy activo en
investigacin y desarrollo, son:
Sistemas de redes mviles, acceso de informacin mvil, soporte para
aplicaciones adaptativas, tcnicas de ahorro de energa, sensibilidad respecto
de la localizacin.
Como una extensin de los sistemas distribuidos y de la computacin mvil
surge la computacin ubicua.
Examinando los requisitos impuestos al "hardware" de los dispositivos, se
distinguen fundamentalmente tres:
Miniaturizacin. La invisibilidad y dotar de capacidades de computacin

a todos dispositivos que nos rodean hacen de la miniaturizacin de los
microprocesadores un requisito fundamental.
Baja potencia . El desarrollo de los procesadores ha tenido siempre el
objetivo de aumentar su rendimiento. Para estas aplicaciones, la
necesidad de disponer de procesadores de baja potencia es prioritaria.
Es necesario desarrollar microprocesadores que funcionen en un gran
rango de voltajes y que estn provistos de mecanismos automticos para
el ahorro de energa.
Conexin sin hilos. La interconexin de todos los elementos que
constituyen un entorno perspicaz y la incorporacin del paradigma de la
computacin mvil tienen como consecuencia la necesidad de establecer
comunicaciones sin hilos. Aqu surge el desafo de desarrollar para las
comunicaciones, el soporte fsico, un gran ancho de banda. Este campo
es muy activo en investigacin y desarrollo ya que sta tecnologa
permitir el avance en otros campos en las telecomunicaciones y los
sistemas de informacin.
5.2. Paradigmas de la computacin mvil

5.2.1 Sistemas de comunicacin inalmbrica.
Para que esta comunicacin inalmbrica entre diversos dispositivos sea posible,
existen actualmente dos tipos de tecnologas: por infrarrojos y radiofrecuencia
260

5.2.1.1 Comunicacin por radiofrecuencia (RF)
La comunicacin por radiofrecuencia tiene todas las cartas en la mano para ser
el estndar de las comunicaciones futuras. Su principal base reside en la
posibilidad de transmitir a mayor distancia, incluso a travs de obstculos entre
el emisor y el receptor. Sin embargo, las ondas electromagnticas tampoco
estn libres de inconvenientes, como el de las posibles interferencias con otros
aparatos que emitan en el mismo rango. Esta es una cuestin que ya est
siendo abordada por diversos organismos oficiales de todo el mundo con el
objetivo de ampliar el espacio electromagntico y ofrecer a los fabricantes de
este tipo de dispositivos otras posibilidades de frecuencia.
5.2.1.2 Comunicacin por Infrarrojo (IR)
A pesar de que el infrarrojo tiene mucho tiempo de vida y de la cantidad de
soluciones que se comercializan basadas en esta comunicacin, es muy
probable que la tecnologa por infrarrojos o IrDA tenga los das contados. Se
basa en rayos luminosos que se mueven en el espectro infrarrojo y permite la
comunicacin bidireccional entre dos extremos a velocidades que oscilan entre
los 9.600 bps y los 4 Mbps. Sus limitaciones se encuentran en su corto alcance y
en la necesidad de mantener los dos extremos de la comunicacin en lnea y sin
obstculos para que sea realmente efectiva.
Los sistemas de comunicacin por infrarrojo utilizan muy altas frecuencias, justo
abajo del espectro de la luz visible para transportar datos. Como la luz, el
infrarrojo no puede penetrar objetos opacos, ya sea directamente (lnea de vista)
o indirectamente (tecnologa difundida/reflectiva). El alto desempeo del
infrarrojo directo es imprctico para usuarios mviles pero su uso es
prcticamente para conectar dos redes fijas. La tecnologa reflectiva no requiere
lnea de vista pero est limitada a cuartos individuales en zonas relativamente
cercanas.
5.2.1.3 Sistemas Celulares
La idea de un sistema celular consiste en un sistema basado en varios niveles
de celdas: un transmisor de gran potencia (celda grande) con muchos
transmisores de baja potencia (celdas pequeas) cada una proporcionando
cobertura a slo una pequea porcin del rea de servicio. A cada estacin base
se le asigna una porcin del nmero total de canales disponibles en el sistema
completo, y a las estaciones base cercanas se les asignan diferentes grupos de
canales de forma que los canales disponibles son asignados en un nmero
relativamente pequeo de estaciones base vecinas. A las estaciones base
vecinas se les asigna diferentes grupos de canales de forma que las
interferencias entre las estaciones base (y entre los usuarios mviles bajo su
control) se reducen. Espaciando sistemticamente las estaciones base y sus
grupos de canales a travs de un mercado, los canales disponibles se
distribuyen a travs de una regin y pueden ser reutilizadas tantas veces como
261

sea necesario, siempre que la interferencia entre estaciones con el mismo canal
se mantenga por debajo de unos niveles aceptables.
5.2.1.4 Comunicacin Va Satlite
Los enlaces satelitales son comunicaciones por medio de microondas donde uno
de los extremos de la conexin se encuentra en el espacio y el otro en la tierra,
en forma de estacin terrestre, que es la encargada de hacer la conexin entre
el satlite y el usuario final.
Un factor limitante para la comunicacin microondas es que tiene que existir una
lnea recta entre los dos puntos pero como la tierra es esfrica esta lnea se ve
limitada en tamao entonces, colocando, ya sea el receptor o el transmisor, en el
espacio
se
cubre
un
rea
ms
grande
de
superficie.
Los sistemas de satlites y de microondas utilizan frecuencias que estn en el
rango de los MHz y GHz, usualmente utilizan diferentes frecuencias para evitar
interferencias pero comparten algunas b andas de frecuencias.
Elementos de un sistema satelital
El siguiente grfico muestra un diagrama sencillo de un enlace va satlite,
ntese que los trminos UPLINK y DOWNLINK aparecen en la figura, el primero
se refiere al enlace de la tierra al satlite y la segunda del satlite a la tierra.
Enlace de Subida
(Uplink)
Enlace de Bajada
(Downlink)
Enlace Terrestre
Enlace Terrestre
Estaciones Terrenas
Las comunicaciones va satlite poseen numerosas ventajas sobre las

comunicaciones terrestres, la siguiente es una lista de algunas de estas
ventajas:
262
El costo de un satlite es independiente a la distancia que valla a cubrir.

La comunicacin entre dos estaciones terrestres no necesita de un gran
nmero de repetidoras puesto que solo se utiliza un satlite.
Las poblaciones pueden ser cubiertas con una sola seal de satlite, sin
tener que preocuparse en gran medida del problema de los obstculos.
Grandes cantidades de ancho de bandas estn disponibles en los
circuitos satelitales generando mayores velocidades en la transmisin de
voz, data y vdeo sin hacer uso de un costoso enlace telefnico.
Estas ventajas poseen sus contrapartes, alguna de ellas son:
El retardo entre el UPLINK y el DOWNLINK esta alrededor de un cuarto

de segundo, o de medio segundo para una seal de eco.
La absorcin por la lluvia es proporcional a la frecuencia de la onda
Conexiones satelitales multiplexadas imponen un retardo que afectan las
comunicaciones de voz, por lo cual son generalmente evitadas.
5.3. Lenguajes y Ambientes de Programacin de Computacin

Mvil
5.3.1 Estndares y tecnologas de comunicacin inalmbrica
5.3.1.1 Servicios de telecomunicaciones inalmbricas y terrestres
En muy poco tiempo la informacin que sea consultada por una computadora
personal se podr hacer con un telfono celular u algn otro dispositivo porttil.
La globalizacin de las comunicaciones inalmbricas ha permitido el desarrollo
de nuevos estndares y productos que muy pronto brindarn cambios en
nuestras actividades.
Los estndares inalmbricos tales como IEEE 802.11, IEEE 802.15, Bluetooth ,
HiperLAN/2, HomeRF en combinacin con otras tecnologas no tan nuevas
como la telefona celular aunado con nuevos protocolos como el WAP permitirn
la interconexin de las redes actuales e Internet a dispositivos mviles como
telfonos celulares, PDAs , radiolocalizadores (pagers) de dos vas y otros
dispositivos porttiles.
Estas tecnologas inalmbricas utilizan tcnicas avanzadas de modulacin que
permiten un gran nivel de seguridad as como resistencia a la interferencia de
dispositivos electrnicos y a otros usuarios. Adems, la mayora de los usuarios
podrn compartir una banda de frecuencia sin interferencia. Ms an, estas
nuevas tecnologas utilizan bandas de frecuencias sin licencia, que permiten el
uso libre para el uso de la frecuencia.
263

Algunos de los servicios de telecomunicaciones terrestre e inalmbrica son
MMDS, LMDS, WLL, GSM, IS -54, CDMA.
5.3.1.2. Fijos (MMDS, LMDS, WLL)
Otras tecnologas WAN/MAN que permiten el acceso a Internet a altas
velocidades son MMDS, LMDS, WLL, enlaces de microondas terrestres, va
lser infrarrojo y comunicaciones va satlite.
Estndar MMDS y LMDS
Con MMDS es posible la provisin de Internet a altas velocidades en el rango de
decenas de Mbps a distancias de ms de 40 kilmetros, limitndola nicamente
la curvatura de la tierra y la lnea de vista. Con LMDS se puede transferir
informacin hasta en el rango de Gbps, debido a que trabaja en una banda de
frecuencia mayor [20-30 GHz] y con mas capacidad de canal, pero funciona en
celdas con cobertura de 5 a 8 kilmetros.
Por ltimo en esta categora el acceso a Internet va satlite ha jugado un papel
preponderante hoy en da. La ventaja ms importante de las comunicaciones va
satlite en el acceso a Internet es la gran cobertura que tiene, alta capacidad en
el orden de decenas de Mbps, provee accesos ms directos a las dorsales
satelitales, las comunicaciones va satlite pueden penetrar reas remotas
donde otros medios de transmisin seran imposibles de llegar. En otras
palabras la comunicacin va satlite es capaz de dar acceso a Internet hasta en
una isla a miles de kilmetros de distancia. Quiz este sea el medio inalmbrico
ms caro al principio debido a que hay que comprar infraestructura costosa
como las estaciones terrenas y pagar las altas mensualidades de ancho de
banda a un proveedor satelital. Existen opciones satelitales mucho ms
econmicas para usuarios residenciales o para pequeas oficinas. Estos
sistemas que operan de manera hbrida y asimtrica utilizan pequeos platos
reflectores para la recepcin de la informacin de Internet y empleando otro
medio alternativo para el regreso de la informacin, ya sea mediante una lnea
privada de menos ancho de banda o mediante un mdem casero. Este sistema
permite la recepcin de Internet a velocidades de hasta 400 Kbps, un ejemplo de
este servicio es DirecPC. Existen tambin sistemas satelitales econmicos pero
que operan de manera bidireccional para pequeos negocios o para
proveedores
de
Internet
mediante
pequeas
estaciones
terrenas
transmisoras/receptoras.
Estndar WLL
WLL (Wireless Local Loop) es una importante tecnologa que permite servicios
telefnicos que incrementan ms el desarrollo de los diferentes pases que los
sistemas cableados. Las capacidades de un sistema WLL est basado en la
aplicacin TDMA (IS-54), el CDMA (IS -95A) y el ETSI GSM las cuales son
264

comparadas dependiendo de las necesidades e instalaciones existentes. Dentro
de las ventajas de la tecnologa WLL tenemos:
Tiempo de implantacin mucho ms rpido que la convencional.
Potencial para un costo menor que el cable convencional; disminucin de
costos en la electrnica versus costos de mano de obra en aumento.
Gastos menores de mantenimiento. Elimina las averas provocadas por
los instaladores tanto en las labores de reacomodos o instalacin de
nuevos usuarios, como tambin, en muchos tipos de daos fsicos.
Elimina las posibilidades de robos de cables.
Proporciona una cobertura econmica para zonas suburbanas o rurales
de gran crecimiento y donde en la actualidad es muy costoso disponer de
instalaciones de cables.
Pueden tambin utilizarse en zonas urbanas en entornos competitivos o
donde se requieren incorporar adiciones a la capacidad existente de la
red convencional.
5.3.1.3. Mviles (GSM, IS-54, CDMA)
Estndar GSM
GSM (Global System for Mobile Communications) es una plataforma de red
inteligente 100 % digital que ofrece capacidades y servicios que superan los
sistemas celulares convencionales. GSM proporciona a sus usuarios las
siguientes ventajas: Universalidad, inviolabilidad, p rivacidad.
Un sistema GSM est basado, principalmente, en tres subsistemas: el
Subsistema de Red y de Conmutacin, el Subsistema de la Radio Base y el
Subsistema de Soporte de Operacin.
Concepto De Red PLMN-GSM
El estndar GSM define una red telefnica mvil terrestre (PLMN) completa, de
naturaleza digital y de servicios integrados, que comprende el acceso radio con
estructura celular, la transmisin, conmutacin y sealizacin especficas para
soportar las funciones de movilidad y los mecanismos de seguridad para el
establecimiento de las llamadas y la proteccin de la informacin transmitida
durante stas.
La red PLMN-GSM proporciona a usuarios fijos y mviles la intercomunicacin
con abonados o con recursos de otras redes fijas o mviles, incluidos los
servicios asociados a ellas.
Sin embargo tiene un grado de conectividad limitado. Estrictamente hablando,
como red, slo puede manejar internamente llamadas entre estaciones mviles
que dependan de una misma central. Para todas las dems llamadas entre
mviles que requieran la intervencin de diferentes centrales y las llamadas en
265

que intervenga una terminal de red de telefnica convencional, se requiere el
concurso de la PSTN (red telefnica bsica). Por ello, en la PLMN-GSM no hay
jerarqua de conmutacin y la transmisin utiliza la norma PCM con canales de
64 kbit/s.
Una de las caractersticas ms importantes es la especificacin de interfaces
abiertas entre las distintas unidades funcionales de la red, en el marco del
modelo OSI y siguiendo la normativa ISDN para la caracterizacin de la
sealizacin y las funciones de red.
Servicios Proporcionados Por La Red GSM
Los servicios bsicos ofrecidos son los de telefona y datos, que comprenden
transmisiones de textos, imgenes, fax, ficheros y mensajes.
El servicio bsico de telefona es similar al que prestan las redes clsicas fijas.
El usuario puede realizar y recibir llamadas hacia/desde cualquier red telefnica.
Este servicio tiene asociado el de mensajera vocal que permite el
almacenamiento de los mensajes para su posterior recuperacin.
Los servicios de datos utilizan la red GSM principalmente como red de acceso.
Es posible entablar comunicacin con diferentes redes destino a velocidades de
datos comprendidas entre 300 y 9600 bit/s, en modo sncrono o asncrono. Los
servicios de datos en modo circuito pueden ser de tipo transparente o no
transparente (con deteccin de errores y retransmisin). En el modo
transparente la red usa el protocolo RLP (Radio Link Protocol), con un sistema
de control de errores que realiza la deteccin de errores y la retransmisin
consiguiente.
El tipo de conexin y las caractersticas de los servicios de datos, dependen de
la red destinataria. Para la PSTN, que es de naturaleza analgica, se requiere el
uso de un mdem en el punto de interconexin GSM-PSTN.
En el caso de la ISDN hace falta disponer de un adaptador de velocidad de 9,6
kbit/s en GSM a 64 kbit/s en ISDN.
Para las redes pblicas de datos con conmutacin de paquetes, PSPDN, la
conexin depende de la norma usada en esa red: es directa en caso X25 y
requiere la intervencin de la PSTN o ISDN con la norma PAD X.28 asncrona,
o con la norma X.32 sncrona.
El servicio de mensajes cortos, SMS (Short Message Service) permite el
intercambio de mensajes breves, de hasta 160 caracteres, que pueden leerse
en la pantalla del equipo porttil o en la de un PC dotado de programas para la
gestin del servicio.
Los mensajes del servicio SMS llegan a sus destinatarios aunque stos no estn
disponibles (terminal apagado) o su lnea est ocupada. Una vez que el terminal
266

se encuentra en el estado activo desocupado, la red genera una llamada
indicando al usuario que tiene uno o ms mensajes depositados en su buzn.
Este servicio es similar al de radiolocalizacin (paging) pero ms completo ya
que permite el intercambio bidireccional, el almacenamiento y envo y el acuse
de recibo de los mensajes entregados.
Otro servicio interesante es el de difusin celular, SMS-CB (Cell Broadcasting),
mediante el cual pueden difundirse mensajes a grupos de usuarios situados en
determinadas clulas.
Los servicios suplementarios enriquecen las prestaciones de los teleservicios
bsicos. Brindan al usuario la posibilidad de eleccin del tratamiento de las
llamadas entrantes o salientes: prohibiciones, desvos, le facilitan informacin
sobre la llamada: aviso de tasacin, identificacin de lnea llamante, indicacin
de llamada en espera ole permiten ejercer ciertas funciones como retencin,
multiconferencia, etc.
Estndar CDMA
Uno de los puntos ms importantes en un sistema mvil, como la telefona
celular, es la forma en como se accede al medio de comunicacin. A estas
tcnicas se le conocen como "acceso mltiple". Mltiple significa que muchos
usuarios pueden estar conversando simultneamente. Es decir, una gran
cantidad de subscriptores en un servicio mvil comparten un conjunto de
canales de radio y cualquier usuario puede contender para acceder cualquiera
de los canales disponibles. Un canal puede ser visto como una porcin del
espectro radioelctrico, el cual es asignado temporalmente para un propsito
especifico, tal como una llamada telefnica. Una tcnica de acceso mltiple
define como se divide el espectro de frecuencias en canales y como los canales
son asignados a los mltiples usuarios en el sistema. Visto de otra manera, el
seleccionar una tcnica eficiente de acceso mltiple significa que los operadores
telefnicos (carriers) obtendrn ms ganancias al acomodar ms usuarios en
sus redes inalmbricas.
Las tcnicas de acceso mltiple son utilizadas en el ambiente de las
comunicaciones para que varios dispositivos [computadoras, telfonos, radios,
etc.] puedan acceder al medio o canal de comunicacin de manera ordenada.
Sin las tcnicas de acceso mltiple, las comunicaciones entre dispositivos sera
un caos. Las tcnicas de acceso mltiple nos permiten compartir un mismo canal
de comunicacin para varios usuarios.
CDMA es un trmino genrico que define una interfa z de aire inalmbrica
basada en la tecnologa de espectro extendido (spread spectrum). Para
telefona celular, CDMA es una tcnica de acceso mltiple especificada por la
TIA (Telecommunications Industry Association - Asociacin de Industriales
de las Telecomunicaciones) como IS-95. En marzo de 1992, la TIA estableci
267

el subcomit TR 45.5 con la finalidad de desarrollar un estndar de telefona
celular digital con espectro extendido. En julio de 1993, la TIA dio su aprobacin
al estndar CDMA IS-95.
Los sistemas IS-95 dividen el espectro en portadoras de 1.25 MHz. Unos de los
aspectos nicos de CDMA es que a pesar de que existe un nmero fijo de
llamadas telefnicas que pueden ser manipuladas por un proveedor de servicios
de telefona (carrier), ste no es un nmero fijo. La capacidad del sistema va a
depender de muchos factores.
Cada dispositivo que utiliza CDMA est programado con un pseudocdigo, el
cual es usado para extender una seal de baja potencia sobre un espectro de
frecuencia amplio. La estacin base utiliza el mismo cdigo en forma invertida
(todos los ceros son unos y los unos ceros) para des-extender y reconstruir la
seal original. Todos los otros cdigos permanecen extendidos, indistinguibles
del ruido de fondo.
Hoy en da existen muchas variantes, pero el CDMA original es conocido como
cdmaOne bajo una marca registrada de Qualcomm. A CDMA se le caracteriza
por su alta capacidad y celdas de radio pequeo, que emplea espectro
extendido y un esquema de codificacin especial y lo mejor de todo es muy
eficiente en potencia.
Estndar AMPS (IS-54)
AMPS (Advanced Mobile Phone Service) est definido no solo por un
estndar, sino por muchos estndares. Todos los estndares son desarrollados
por el comit TR-45 de la TIA. An las interfaces de radio son definidas por
varias familias de estndares, una para cada tecnologa (Anloga, NAMPS,
TDMA y CDMA). El roaming automtico es posible gracias al estndar TIA IS -41
que provee handoff entre sistemas, envo de llamadas, envo de corto-mensajes
y validacin y autenticacin a travs de un protocolo de paso de mensajes entre
sistemas. El IS -41 fue desarrollado por el subcomit TIA TR-45.2.
Uno de los estndares mas importantes de interfaz de radio para AMPS es:
Estndar IS-54 TDMA Celular Digital
Los sistemas digitales TDMA llevan su nombre de la sigla en Ingls Time
Division Multiple Access, dividiendo un canal sencillo en un nmero de 'slots'
de tiempo (timeslots), con cada usuario obteniendo uno de cada varios slots .
Esto triplica la capacidad de las frecuencias celulares, dividiendo un canal
celular de 30 Khz en 3 timeslots, los cuales soportan 3 usuarios en alternacin
estricta. Sistemas futuros posiblemente utilicen codificadores de voz de media
rata, lo cual permitir 6 usuarios en un canal de 30 Khz. La primera
implementacin de celular digital AMPS utilizaba TDMA, en el estndar IS -54 de
la TIA (tambin conocido como D-AMPS). Este requiere la digitalizacin de la
268

voz, comprimirla y transmitirla en intervalos regulares. Siguiendo el IS -54, el cual
provea un canal de voz TDMA, el IS-136 es la siguiente generacin la cual
utiliza tambin TDMA en el canal de control. De esta manera TDMA, se puede
definir como el IS -54 y el IS -136. Actualmente Hughes Network Systems est
promocionando el concepto de E-TDMA, el cual utiliza asignacin dinmica de
timeslots , para evitar el desperdicio de timeslots cuando en un lado de la
conversacin est en silencio. Entre gente que no se habla simultneamente en
el telfono, esta tcnica puede casi doblar la eficiencia del espectro de TDMA
una vez mas, a cerca de 10:1 sobre sistemas anlogos.
5.3.1.4 Bluetooth y Servicios de Datos inalmbricos
Bluetooth es una tecnologa utilizada para conectividad inalmbrica de corto
alcance entre dispositivos tales como PDAs (Personal Digital Assistance),
telfonos celulares, teclados, mquinas de fax, computadoras de escritorio y
porttiles, mdems, proyectores, impresoras, etc. El principal mercado es la
transferencia de datos y voz entre dispositivos y computadoras personales. El
enfoque de Bluetooth es similar a la tecnologa de infrarrojo conocida como
IrDA (Infrared Data Association). Sin embargo, Bluetooth, es una tecnologa
de radiofrecuencia (RF) que utiliza la banda de espectro disperso de 2.4 GHz.
Muchas veces tambin se le confunde con el estndar IEEE 802.11, otra
tecnologa de RF de corto alcance. IEEE 802.11 ofrece ms caudal eficaz pero
necesita ms potencia de transmisin y ofrece menos opciones de conectividad
que Bluetooth para el caso de aplicaciones de voz.
Debido a que Bluetooth funciona con RF no est sujeto a tales limitaciones. Las
distancia de conexin en Bluetooth puede ser de hasta 10 metros o ms
dependiendo del incremento de la potencia del transmisor, pero los dispositivos
no necesitan estar en lnea de vista ya que las seales de RF pueden atravesar
paredes y otros objetos no metlicos sin ningn problema.
Bluetooth puede ser usado para aplicaciones en redes residenciales o en
pequeas oficinas, ambientes que son conocidos como WPANs (Wireless
Personal Area Network). Una de las ventajas de las tecnologas inalmbricas
es que evitan el problema de alambrar las paredes de las casas u oficinas.
Bluetooth opera en la banda 2.4 GHz bajo la tecnologa de radio conocida como
espectro disperso. La banda de operacin est dividida en canales de 1 MHz, a
1 megasmbolo por segundo puede obtenerse al ancho de banda mximo por
canal. Con el esquema de modulacin empleado, GFSK (Gaussian Frequency
Shift Keying), esto equivale a 1 Mbps. Utilizando GFSK, un 1 binario representa
una desviacin positiva de la portadora nominal de la frecuencia, mientras que
un 0 representa una desviacin negativa. Despus de cada paquete, ambos
dispositivos re-sintonizan su radio transmisor a una frecuencia diferente,
saltando de un canal a otro canal de radio; esta tcnica se le conoce como
269

espectro disperso con salto en frecuencia (FHSS, Frequency Hopping Spread
Spectrum).
De esta manera, los dispositivos Bluetooth utilizan toda la banda de 2.4 GHz y
si una transmisin se interfiere sobre un canal, una retransmisin siempre
ocurrir sobre un canal diferente con la esperanza de que este canal est libre.
Cada ranura de tiempo tiene una duracin de 625 microsegundos y
generalmente los dispositivos saltan una vez por paquete, o sea, saltan cada
ranura, cada 3 ranuras o cada 5 ranuras. Como Bluetooth fue diseado para
aplicaciones mviles de poca potencia, la potencia del radio transmisor debe ser
minimizada. Tres diferentes clases de niveles de potencias estn definidas, las
cuales proveen rangos de operacin de aproximadamente 10, 20 y 100 metros:
El ms bajo nivel de potencia cubre 10 metros, el ms alto nivel logra cubrir
distancias de hasta 100 metros.
Aunado a las distancias cortas de conexin de Bluetooth en materia de ancho
de banda soporta hasta 780 Kbps, los cuales pueden ser utilizados para
transferir unidireccionalmente 721 Kbps y 57.6 Kbps en la direccin de retorno o
hasta 432.6 Kbps de manera simtrica en ambas direcciones. Aunque estas
velocidades estn limitadas para cierto tipo de aplicaciones como video,
aplicaciones como transferencia de archivos e impresin caen perfectas en tal
ancho de banda.
Bluetooth permite manipular simultneamente transmisiones de voz y datos. Es
capaz de soportar un canal de datos asncrono y hasta tres canales de voz
asncronos o un canal que soporte ambos, voz y datos. La capacidad combinada
con los dispositivos del tipo "ad hoc" permite soluciones superiores para
dispositivos mviles y aplicaciones de Internet. Esta combinacin permite
soluciones innova doras como un dispositivo de manos libres para llamadas de
voz, impresin a mquinas de fax y sincronizacin automtica a PDAs, laptops y
aplicaciones de libreta de direcciones de telfonos celulares.
La especificacin Bluetooth
La especificacin de Bluetooth cubre desde el transceptor de radio hasta
varias interfaces de protocolos basados tanto en hardware como en software.
Algunos elementos clave y protocolos de la arquitectura de Bluetooth son
descritos a continuacin. Control de enlace: el hardware del control de enlace
controla la transmisin y recepcin de radio as como el procesamiento de la
seal digital requerida para el protocolo de banda base. Sus funciones incluyen
establecimientos de conexiones, soporte para enlaces asncronos (datos) y
sncronos (voz), correccin de error y autentificacin. El microcdigo del
administrador de enlaces desempea funciones a bajo nivel para el
establecimiento de enlaces, autentificacin y configuracin de los enlaces.
Topologa de la red: los dispositivos Bluetooth son generalmente organizados
en grupos de 2 a 8 llamados picoceldas o picoredes, consistente de un
270

dispositivo maestro y uno o ms dispositivos esclavos. Un dispositivo puede
pertenecer a ms de una picocelda y comportarse como un esclavo en ambas o
un maestro en una picocelda y como esclavo en otra.
Como Bluetooth opera en una banda de uso libre conocida como ISM
(Industrial, Scientific, and Medical) donde otros dispositivos de uso comn la
utilizan como es el caso de puertas de cocheras, telfonos inalmbricos, hornos
de microondas, slo por nombrar algunos. Para que los dispositivos Bluetooth
puedan coexistir y operar confiablemente con los otros dispositivos, cada
picocelda es sincronizada a una frecuencia especfica del patrn de salto por
frecuencia. Este patrn, que salta a 1,600 frecuencias diferentes por segundo,
es nico para una picocelda en particular. Cada "salto" de frecuencia es una
ranura de tiempo durante la cual los paquetes de datos son transferidos. Un
paquete puede abarcar hasta 5 ranuras de tiempo, en la cual la frecuencia
permanece constante durante la duracin de esa transferencia.
Si los dispositivos van a saltar a las nuevas frecuencias despus de cada
paquete, ellos deben ponerse de acuerdo en la secuencia de las frecuencias que
utilizarn. Como los dispositivos Bluetooth operan en 2 modos: como maestro y
como esclavo. Si el maestro asigna la secuencia de salto de frecuencia. Los
esclavos sincronizan al dispositivo maestro en tiempo y frecuencia seguido de la
secuencia de salto del dispositivo maestro.
Enlaces de banda base: La banda base de Bluetooth provee canales de
transmisin para voz y datos y es capaz de soportar un enlace asncrono de
datos y hasta tres enlaces de voz asncronos (o un enlace soportando ambos).
Los enlaces orientados a conexin sncronos (SCO) son tpicamente empleados
para transmisiones de voz. Esos enlaces son conexiones simtricas punto a
punto que reservan ranuras de tiempo para garantizar la transmisin a tiempo. Al
dispositivo esclavo siempre se le permitir responder durante la ranura de
tiempo inmediatamente seguido de una transmisin tipo SCO del maestro. Un
dispositivo maestro puede soportar hasta tres enlaces SCO a uno o varios
esclavos, pero un solo esclavo puede soportar slo enlaces SCO para diferentes
dispositivos maestros. Los paquetes SCO nunca son retransmitidos.
Los enlaces orientados a no-conexin (ACL, Asynchronous Connectionless)
son tpicamente empleados para transmisin de datos. Las transmisiones sobre
estos enlaces son establecidas en base por ranura (en ranuras no reservadas
para enlaces SCO). Los enlaces ACL soportan transferencias punto-multipunto
de datos asncronos como sncronos. Despus de una transmisin ACL del
maestro, slo el dispositivo esclavo direccionado puede responder durante la
siguiente ranura de tiempo o si el dispositivo no est direccionado, los paquetes
son considerados como mensajes difundidos (broadcast). La mayora de los
enlaces ACL incluyen retransmisin de paquetes. Administrador de enlaces: La
mquina de estado de banda base es controlada por el administrador de
enlaces. Este microcdigo provee el control del enlace basado en hardware para
271

configuracin, seguridad y control de enlaces. Sus capacidades incluyen
autentificacin y servicios de seguridad, monitoreo de calidad de servicio y
control del estado de banda base. El administrador de enlaces se comunica con
los dems utilizando el protocolo LMP (Link Management Protocol), el cual
utiliza los servicios bsicos de banda base. Los paquetes LMP, los cuales son
enviados sobre los enlaces ACL, son diferenciados de los paquetes L2CAP
(Logical Link Control and Adaptation Protocol) por un bit en el encabezado
del ACL. Ellos son siempre enviados como paquetes de una ranura y una
prioridad alta que los paquetes L2CAP. Esto ayuda el aseguramiento de la
integridad del enlace bajo una alta demanda de trfico.
El Controlador de Interface del host (Host controller interface, HCI): Por
encima del administrador de enlaces se encuentra el HCI. Este protocolo basado
en hardware es usado para aislar la banda base de Bluetooth y el administrador
de enlaces de un protocolo de transporte tal como el RS-232 o USB (Universal
Serial Bus). Esto permite una interface estndar para el hardware de Bluetooth.
Un manejador de dispositivos HCI en el host es usado para interactuar una
aplicacin Bluetooth con el protocolo de transporte. Actualmente existen tres
mecanismos de transporte soportados: USB, RS-232 y el UART (Universal
Asynchronous Receiver-Transmitter). Utilizando HCI, una aplicacin
Bluetooth puede acceder al hardware de Bluetooth sin el conocimiento de la
capa de transporte o de otros detalles de implementacin del hardware.
Protocolos basados en software: el resto de los protocolos son
implementados en software. La capa ms baja de L2CAP provee la interface con
el administrador de enlaces y permite la interoperabilidad entre dispositivos
Bluetooth. Provee la multicanalizacin de protocolos, lo cual permite el soporte
de otros protocolos de ms alto nivel tales como TCP/IP. El L2CAP opera sobre
un enlace del tipo ACL en banda base y provee enlaces punto-multipunto para
transferencias sncronas como asncronas. L2CAP provee servicios a los
protocolos de los niveles superiores al transmitir paquetes de datos sobre los
canales L2CAP. Existen tres tipos de canales L2CAP: canales bidireccionales
que transportan comandos; canales orientados a conexin para conexiones
punto-punto y bidireccionales; y canales unidireccionales orientados a noconexin que soporten conexiones punto-multipunto, permitiendo que una
entidad local L2CAP sea conectada a un grupo de dispositivos remotos.
Varios protocolos interactan con la capa de enlace L2CAP tales como SDP y
RFCOMM. El protocolo SDP (Service Discovery Protocol) provee un medio
para determinar que servicios Bluetooth estn disponibles en un dispositivo
particular.
Un dispositivo Bluetooth puede actuar como un cliente SDP solicitando
servicios o como un servidor SDP proveyendo servicios, o ambos. Un simple
dispositivo Bluetooth tendr no ms de un servidor SDP, pero puede actuar
como un cliente para ms de un dispositivo remoto. El protocolo SDP provee
acceso slo a informacin acerca de servicios, la utilizacin de esos servicios
272

deber ser provedo por otro protocolo. RFCOMM es un protocolo de transporte
que provee transferencia de datos serial. Una entidad de emulacin de puertos
es usada para mapear la comunicacin de la interface de la programacin de
aplicaciones (API, Applications Programming Interface) a los servicios de
RFCOMM, permitiendo que el software legado opere en un dispositivo
Bluetooth. TCS (Telephony Control Protocol Specification), un protocolo
para aplicaciones de telefona es provedo para control de llamadas de voz y
datos a travs de sealizacin. La sealizacin tanto para punto-punto y puntomultipunto son soportados utilizando los canales L2CAP, la voz o los datos son
transferidos directamente desde la banda base sobre los enlaces SCO.
Bluetooth tambin soporta el protocolo de sesin conocido como IrOBEX (IrDA
Object Exchange Protocol), definido por IrDA. Este protocolo puede operar
sobre las capas de transporte, incluyendo RFCOMM y TCP/IP. Para dispositivos
Bluetooth, solo OBEX orientado a conexin es soportado. Tres perfiles de
aplicacin han sido desarrollados usando OBEX. Estos incluyen funcionalidades
de sincronizacin para directorios telefnicos, calendarios, mensajes, etc.;
funcionalidades de transferencia de archivos y Object Push para soporte de
tarjetas de presentacin.
Las primeras tecnologas inalmbricas para equipos de computo utilizaban
tecnologa Spread Spectrum o infrarroja.
Espectro Amplio (Spread Spectrum), fue desarrollado para fines militares y su
funcionamiento consta en dividir las seales informativas en varias frecuencias,
estas frecuencias comnmente son las de 902-928 MHz y de 2.4 -2.484 GHz
(tambin llamada ISM Industrial-Scientific and Medical radio frequency),este
ltimo rango de frecuencias es utilizado por telfonos inalmbricos (NO
celulares),controles de puertas elctricas, entre otros; la ventaja de operacin en
esta frecuencia es que no requiere permiso gubernamental para ser utili zada a
diferencia de otras frecuencias. Tecnologa Infrarroja
La Tecnologa infrarroja opera en la banda de 300,000 GHz pero su uso es ms
limitado que Spread Spectrum, ya que una transmisin infrarroja requiere de
una lnea-visual directa entre los apara tos que estn realizando la transmisin,
este tipo de implementacin es utilizada por controles de televisin y Vdeos.
Es un estndar que utiliza FHSS, capaz de transmitir a velocidades de 1 Mbps y
es apoyado por ms de 2000 empresas de tecnologa. Bluetooth ha surgido
ltimamente como un posible substituto a todo tipo de cable anexado a una
computadora , debido a su costo y el apoyo de cientos de empresas. A su
velocidad (1 Mbps) ser capaz de sustituir las conexiones clsicas de cables
paralelos y serial es, ya que es 3 y 6 veces ms rpido (respectivamente) que
estas conexiones en amplio uso en cualquier computadora.
273

Esto trae una cantidad interminable de posibilidades desde impresoras,
monitores, conexiones de porttiles (Laptops), teclados, ratones y otros
dispositivos. Esta tecnologa es capaz de transmitir informacin efectivamente
hasta una distancia de 10 metros entre aparatos que utilicen transmisores
"Bluetooth", debido que se emplea FHSS el "Hopping Pattern" de Bluetooth
es de 1600 veces por segundo, lo cual asegura que la transmisin de datos sea
altamente segura.
5.3.1.5 Estndares de redes inalmbricas: IEEE 802.11
El estndar IEE 802.11 de LAN Inalmbrica esta diseado para soportar
comunicaciones a velocidades hasta de 11Mbps sobre una distancia de hasta
150 metro entre dispositivos equipados con transmisores/receptores
inalmbricos simples. En este sentido la IEEE ha desarrollado varios estndares
en que lo que LAN se refiere. La especificacin IEEE 802.11 define redes
locales inalmbricas que emplean ondas de radio en la banda de 2.4 GHz y 5
GHz conocido como espectro esparcido. Las velocidades tpicas de esta
tecnologa son 11 Mbps en la especificacin IEEE 802.11b y est en desarrollo
la especificacin IEEE 802.11a en la banda de 5 GHz que alcanzar velocidades
de hasta 54 Mbps.
El estndar IEEE 802.11 extiende el principio de sensible a la portadora (CSMA)
utilizando la tecnologa de Ethernet (IEEE 802.3) para adecuar las
caractersticas de la comunicacin sin hilos. Las estaciones IE EE 802.11 utilizan
como medio de transmisin seales de radio (en la banda de los 2,4 Ghz.) o
seales de infrarrojos. Utilizan tcnicas de seleccin de frecuencia y de salto de
frecuencia para evitar las interferencias externas y mutuas redes LAN
inalmbricas independientes. Cuando se utiliza ondas de radio en lugar de
cables como medio de transmisin surgen varios problemas, estos problemas se
derivan del hecho de que los mecanismos de deteccin de portadora y de
colisiones empleados por Ethernet son efectivos slo cuando la potencia de la
seal es aproximadamente la misma a lo largo de toda la red. Dado a que la
potencia de la seal no es uniforme a lo largo del espacio en el que las redes
LANs inalmbricas trabajan, la deteccin de la portadora y de las colisiones
puede fallar de alguno de los siguientes modos:
Estaciones ocultas, la deteccin de la portadora puede fallar en la
deteccin de la transmisin de otra estacin.
Atenuacin, debido a la ley del inverso del cuadrado de la propagacin
de las ondas electromagnticas, la potencia de la seal de radio
disminuye rpidamente con la distancia al transmisor.
Enmascaramiento de colisiones, desgraciadamente la tcnica de
escuchar utilizada por Ethernet para detectar las colisiones no es muy
efectiva en las redes va radio.
El aspecto de seguridad, el estndar IEEE 802.11, requiere de un
intercambio de autentificacin para cada estacin que se conecte a la
274

red mediante el cual se demuestre el conocimiento
compartida.
de una clave
5.3.1.6 Sistemas de Comunicacin por satlite

Esencialmente, un satlite es un repetidor de radio en el cielo (transponder). Un
sistema de satlite consiste de un transponder, una estacin en tierra, para
controlar el funcionamiento y una red de usuario, de las estaciones terrestres,
que proporciona las facilidades para transmisin y recepcin de trfico de
comunicaciones, a travs del sistema de satlite. Las transmisiones de satlites
se catalogan como bus o carga til. La de bus incluye mecanismos de control
que apoyan la operacin de carga til. La de carga til es la informacin del
usuario que ser transportada a travs del sistema. Aunque en los ltimos aos
los nuevos servicios de datos y radioemisin de televisin son mas y ms
demandados, la transmisin de las seales de telfono de voz convencional (en
forma analgica o digital).
Satlites Orbitales
Los satlites mencionados, hasta el momento, son llamados satlites orbitales o
no sncronos. Los satlites no sncronos giran alrededor de la Tierra en un
patrn elptico o circular de baja altitud. Si el satlite esta girando en la misma
direccin de la rotacin de la Tierra y a una velocidad angular superior que la de
la Tierra, la rbita se llama rbita progrado. Si el satlite esta girando en la
direccin opuesta a la rotacin de la Tierra o en la misma direccin, pero a una
velocidad angular menor a la de la Tierra, la rbita se llama rbita retrograda.
Consecuentemente, los satlites no sncronos estn alejndose continuamente o
cayendo a tierra, y no permanecen estacionarios en relacin a ningn punto
particular de la tierra. Por lo tanto los satlites no sncronos se tienen que usar
cuando estn disponibles, lo cual puede ser un corto periodo de tiempo, como
15 minutos por rbita. Otra desventaja de los satlites orbitales es la necesidad
de usar un equipo costoso y complicado para rastreo en las estaciones
terrestres. Cada estacin terrestre debe localizar el satlite conforme esta
disponible en cada rbita, y despus unir su antena al satlite y localizarlo
cuando pasa por arriba. Una gran ventaja de los satlites orbitales es que los
motores de propulsin no se requieren a bordo de los satlites para mantenerlos
en sus rbitas respectivas.
275

Satlites Geoestacionarios
Los satlites geoestacionarios o geosncro nos son satlites que giran en un
patrn circular, con una velocidad angular igual a la de la Tierra.
Consecuentemente permanecen en una posicin fija con respecto a un punto
especfico en la tierra. Una ventaja obvia es que estn disponibles para todas las
estaciones de la tierra, dentro de su sombra, 100% de las veces. La sombra de
un satlite incluye todas las estaciones de la tierra que tienen un camino visible
a l y estn dentro del patrn de radiacin de las antenas del satlite. Una
desventaja obvia es que a bordo, se requieren de dispositivos de propulsin
sofisticados y pesados para mantenerlos fijos en una rbita. El tiempo de rbita
de un satlite geosncrono es de 24 horas igual que la tierra.
Clasificaciones Orbitales, Espaciamiento Y Asignaciones De Frecuencia
Hay dos clasificaciones principales para los satlites de comunicaciones:
hiladores (spinners) y satlites estabilizadores de tres ejes. Los satlites
espinar, utilizan el movimiento angular de su cuerpo giratorio para proporcionar
una estabilidad de giro. Con un estabilizador de tres ejes, el cuerpo permanece
fijo en relacin a la superficie de la Tierra, mientras que el subsistema interno
proporciona una estabilizacin de giro.
Los satlites geosncronos deben compartir espacio y espectro de frecuencia
limitados, dentro de un arco especfico, en una rbita geoestacionaria,
aproximadamente a 22,300 millas, arriba del Ecuador. La posicin en la ranura
depende de la banda de frecuencia de comunicacin utilizada. Los satlites
trabajando, casi o en la misma frecuencia, deben estar lo suficientemente
separados en el espacio para evitar interferir uno con otro. Hay un lmite realista
del nmero de estructuras satelitales que pueden estar estacionadas, en un rea
especfica en el espacio. La separacin espacial requerida depende de las
siguientes variables:
Ancho del haz y radiacin del lbulo lateral de la estacin terrena y

antenas del satlite.
Frecuencia de la portadora de RF.
Tcnica de codificacin o de modulacin usada.
Lmites aceptables de interferencia.
Potencia de la portadora de transmisin.
Generalmente, se requieren de 3 a 6 de separacin espacial dependiendo de

las variables establecidas anteriormente.
Las frecuencias de la portadora, ms comunes, usadas para las comunicaciones
por satlite, son las bandas 6/4 y 14/12 GHz. El primer nmero es la frecuencia
de subida (ascendente) (estacin terrena a transponder) y el segundo nmero
276

es la frecuencia de bajada (descendente) (transponder a estacin terrena).
Diferentes frecuencias de subida y de bajada se usan para prevenir que ocurra
repeticin. Entre mas alta sea la frecuencia de la portadora, ms pequeo es el
dimetro requerido de la antena para una ganancia especfica. La mayora de
los satlites domsticos utilizan la banda 6/4 GHz.
Desafortunadamente, esta banda tambin se usa extensamente para los
sistemas de microondas terrestres. Se debe tener cuidado cuando se disea una
red satelital para evitar interferencia de, o interferencia con enlaces de
microondas establecidas.
Modelos De Enlace Del Sistema Satelital
Esencialmente, un sistema satelital consiste de tres secciones bsicas: una
subida, un transponder satelital y una bajada.
Modelo de subida
El principal componente dentro de la seccin de subida satelital, es el transmisor
de estacin terrena. Un tpico transmisor de la estacin terrena consiste de un
modulador de IF, un convertidor de microondas de IF a RF, un amplificador de
alta potencia (HPA) y algn medio para limitar la banda del ltimo espectro de
salida (por ejemplo, un filtro pasa-bandas de salida). El modulador de IF se
convierte la IF convierte las seales de banda base de entrada a una frecuencia
intermedia modulada en FM, en PSK o en QAM. El convertidor (mezclador y
filtro pasa-bandas) convierte la IF a una frecuencia de portadora de RF
apropiada. El HPA proporciona una sensibilidad de entrada adecuada y potencia
de salida para propagar la seal al transponder del satlite. Los HPA
comnmente usados son klystons y tubos de onda progresiva.
Transponder
Un tpico transponder satelital consta de un dispositivo para limitar la banda de
entrada (BPF), un amplificador de bajo ruido de entrada (LNA), un sistema que
traslada frecuencias, un amplificador de potencia de bajo nivel y un filtro pasabandas de salida. Este transponder es un repetidor de RF a RF. Otras
configuraciones de transponder son los repetidores de IF, y de banda base,
semejantes a los que se usan en los repetidores de microondas.
Modelo de bajada
Un receptor de estacin terrena incluye un BPF de entrada, un LNA y un
convertidor de RF a IF. Nuevamente, el BPF limita la potencia del ruido de
entrada al LNA. El LNA es un dispositivo altamente sensible, con poco ruido, tal
como un amplificador de diodo tnel o un amplificador paramtrico. El
277

convertidor de RF a IF es una combinacin de filtro mezclador /pasa-bandas que
convierte la seal de RF recibida a una frecuencia de IF.
Enlaces cruzados
Ocasionalmente, hay aplicaciones en donde es necesario comunicarse entre
satlites. Esto se realiza usando enlaces cruzados entre satlites o enlaces
intersatelitales (ISL). Una desventaja de usar un ISL es que el transmisor y
receptor son enviados ambos al espacio. Consecuentemente la potencia de
salida del transmisor y la sensibilidad de e ntrada del receptor se limitan.
5.3.1.6.1 Elementos de un Sistema Satelital
Su objetivo es el establecimiento de comunicaciones mviles, mediante satlites
en rbita, entre estaciones terrenas fijas y estaciones terrenas mviles.
Comunicacin Va Microondas
Antes de comenzar a describir los componentes de un sistema satelital,
debemos comprender la comunicacin va microondas, ya que la comunicacin
satelital se basa en los principios de dicha comunicacin.
Bsicamente un enlace va microondas consiste en tres componentes
fundamentales: El Transmisor, El receptor y El Canal Areo. El Transmisor es el
responsable de modular una seal digital a la frecuencia utilizada para transmitir,
El Canal Areo representa un camino abierto entre el transmisor y el receptor, y
como es de esperarse el receptor es el encargado de capturar la seal
transmitida y llevarla de nuevo a seal digital.
El factor limitante de la propagacin de la seal en enlaces microondas es la
distancia que se debe cubrir entre el transmisor y el receptor, adems esta
distancia debe ser libre de obstculos. Otro aspecto que se debe sealar es que
en estos enlaces, el camino entre el receptor y el transmisor debe tener una
altura mnima sobre los obstculos en la va, para compensar este efecto se
utilizan torres para ajustar dichas alturas.
Antenas y Torres De Microondas
La distancia cubierta por enlaces microondas puede ser incrementada por el uso
de repetidoras, las cuales amplifican y redireccionan la seal, es importante
destacar que los obstculos de la seal pueden ser salvados a travs de
reflectores pasivos. Las siguientes figuras muestran como trabaja un repetidor y
como se ven los reflectores pasivos.
278
Antena
Recepcin
Amplificador
de Ruido
Bajo
Convertidor
de Frecuencia
Controlador
(Driver)
Amplificador
de Salida
Antena
Transmisin
48 Canales VF
Terminal C
Repetidor
96 Canales VF
48 Canales VF
Terminal A
Repetidor
Principal
o Repetidor
de Canal
Repetidor
Terminal B
La seal de microondas transmitidas es distorsionada y atenuada mientras viaja

desde el transmisor hasta el receptor, estas atenuaciones y distorsiones son
causadas por una perdida de poder dependiente a la distancia, reflexin y
refraccin debido a obstculos y superficies reflectoras, y a prdidas
atmosfricas.
La siguiente es una lista de frecuencias utilizadas por los sistemas de
microondas:
Common Carrier
2.110
1.850
2.160
2.130
3.700
2.180
5.925
2.500
10.700
6.575
12.200
Operational Fixed
2.130 GHz
1.990 GHz
2.180 GHz
2.150 GHz
4.200 GHz
2.200 GHz
6.425 GHz
2.690 GHz
11.700 GHz
6.875 GHz
12.700 GHz
279
Debido al uso de las frecuencias antes mencionadas algunas de las ventajas

son:
Antenas relativamente pequeas son efectivas.

A estas frecuencias las ondas de radio se comportan como ondas de luz,
por ello la seal puede ser enfocada utilizando antenas parablicas y
antenas de embudo, adems pueden ser reflejadas con reflectores
pasivos.
Otra ventaja es el ancho de banda, que va de 2 a 24 GHz.
El uso de estas frecuencias tambin posee desventajas:
Las frecuencias son susceptibles a un fenmeno llamado Disminucin de

Multicamino (Multipath Fafing), lo que causa profundas disminuciones en
el poder de las seales recibidas.
A estas frecuencias las prdidas ambientales se transforman en un factor
importante, la absorcin de poder causada por la lluvia puede afectar
dramticamente el rendimiento del canal.
Componentes de un Sistema Satelital

Bsicamente, los enlaces satelitales son iguales a los de microondas excepto
que uno de los extremos de la conexin se encuentra en el espacio, como se
haba mencionado un factor limitante para la comunicacin microondas es que
tiene que existir una lnea recta entre los dos puntos pero como la tierra es
esfrica esta lnea se ve limitada en tamao entonces, colocando sea el receptor
o el transmisor en el espacio se cubre un rea ms grande de superficie.
Los componentes principales de un sistema satelital son:
Estacin Terrena transmisora

Transponder satelital [Satlite]
Estacin terrena receptora
Espacio (atmsfera)
El siguiente grfico muestra un diagrama sencillo de un enlace va satlite,

ntese que los trminos UPLINK y DOWNLINK aparecen en la figura, el primero
se refiere al enlace de la tierra al satlite y la segunda del satlite a la tierra.
280
Enlace de Subida
(Uplink)
Enlace de Bajada
(Downlink)
Enlace Terrestre
Enlace Terrestre
Estaciones Terrenas
Los satlites de comunicacin estn frecuentemente ubicados en lo que

llamamos Orbitas Geosincronizadas, lo que significa que el satlite circular la
tierra a la misma velocidad en que esta rota lo que lo hace parecer inmvil desde
la tierra. Una ventaja de esto es que el satlite siempre esta a la disposicin para
su uso. Un satlite para estar en este tipo de rbitas debe ser posicionado a
13.937,5 Kms. de altura, con lo que es posible cubrir a toda la tierra utilizando
solo tres satlites como lo muestra la figura.
Tierra
Un satlite no puede retransmitir una seal a la misma frecuencia a la que es

recibida, si esto ocurriese el satlite interferira con la seal de la estacin
terrestre, por esto el satlite tiene que convertir la seal recibida de una
frecuencia a otra antes de retransmitirla, para hacer esto lo hacemos con algo
llamado "Transponders".
Otro punto que cabe destacar es que existen satlites que se encargan de
regenerar la seal recibida antes de retransmitirla, pero estos solo pueden ser
utili zados para seales digitales, mientras que los satlites que no lo hacen
pueden trabajar con ambos tipos de seales (Anlogas y Digitales).
281
La estacin terrena transmisora se caracteriza por el P.I.R.E (Potencia

Isotrpica Radiada Efectiva). Esto de hecho esta relacionado a la potencia del
transmisor y la ganancia de la antena en la frecuencia de transmisin.
La estacin terrena receptora se caracteriza por una figura de mrito (G/T) y la
Frecuencia Intermedia (IF) de banda ancha.
Una estacin terrena satelital es un conjunto de equipo de comunicaciones y de
cmputo que puede ser terrestre (fijo y mvil), martimo o aeronutico. Las
estaciones terrenas pueden ser usadas en forma general para transmitir y recibir
del satlite. Pero en aplicaciones especiales solo pueden recibir o solo pueden
transmitir. A continuacin se enumeran cada uno de los subsistemas bsicos
que integran una estacin terrena satelital.
Plato Reflector (antena): Es el punto por el cul el la estacin terrestre

puede enviar informacin hacia el satlite o puede recibir una seal, con
informacin, proveniente del satlite.
Amplificador de Potencia [HPA, High Power Amplifier]: Al Amplificador
de Alta Potencia [HPA] tambin se le conoce como Transmisor o
Transceptor [Transceiver] ya que est en la parte Transmisora. Existen
varias versiones de HPAs, dependiendo de la potencia radiada y de otros
factores. Los hay de estado slido, los SSPA (Solid State Power
Amplifier) o SSHPA, los hay analgicos de de Tubos de Vaco, los TWTs
(Travelling Wave Tube), los KPA (Klystron Power Amplifiers). Los
SSPAs generalmente se usan para potencias bajas, los TWTs y los
Klystron se utilizan para potencias muy altas.
Amplificador de Bajo Ruido (Receptor), LNA: (Low Noise Amplifier):
Conversor de subida/bajada (Up/down converter): Un conversor de
subida y bajada, se puede conseguir a parte, y generalmente convierten
frecuencias de IF (Frecuencia Intermedia) a RF (Radio Frecuencia)
cuando es UpConverter y de RF a IF cuando es DownConverter. La
frecuencias de IF son generalmente de 70 MHz, 140 MHz y la mas comn
es la banda L (950-1550 MHz aprox). La RF puede ser Banda C, Ku, Ka,
etc.
El conversor de subida/bajada tambin puede estar integrado junto con el
LNA. Cuando es as, se le conoce como LNB (Low Noise Block):
entonces un LNB = LNA + Up/Down Converter
Modem satelital (modulador, demodulador): Se encarga de modular
las seales que provienen de los equipos que estn co nectados a travs
del MUX y de demodular las seales que vienen del Satlite hacia dichos
equipos, podramos decir que es el traductor de seales de los sistemas
hacia el satlite y viceversa.
MUX: El MUX es el encargado de multiplexar, que es dar varias salidas a
la lnea que viene del MODEM Satelital, dichas salidas van a dar a
282

diferentes dispositivos, los cules aprovechan la seal de entrada del
MODEM Satelital y adems pueden enviar informacin hacia l.
Diagrama genrico de una estacin terrena transmisora/receptora

Cada elemento en la cadena de recepcin puede ser asignada a una
temperatura de ruido, la cual es una medida de potencia de ruido contribuida por
el elemento por unidad de ancho de banda. Esas contribuciones son
combinadas para reflejar la potencia de ruido por la distribucin de la ganancia a
travs de la cadena. En general, la temperatura de ruido de el sistema es
determinado primariamente por la antena, al amplificador de bajo ruido (LNA) y
los componentes de acople de esos elementos. La suma de pequeas prdidas,
tales como la atenuacin en el cable, entre el LNA y la antena puede resultar en
degradacin significante de la figura de mrito G/T.
El transponder tambin juega un papel bien importante en un enlace satelital,
ste se encue ntra dentro del satlite y cuyas funciones bsicas son las
siguientes:
Amplificacin de la seal
Aislamiento de canales adyacentes
Traslacin de frecuencias
Por ltimo, tambin el ambiente determina en gran medida el xito o el fracaso

de un enlace satelital y es aqu donde se generan las mayores prdidas,
ocasionadas por el largo trayecto de la seal propagada desde un satlite en el
caso ms extremo 36,000 Kms. de distancia.
Los principales factores que ocasionan la degradacin de la seal se encuentran
la lluvia, la nieve, la absorcin atmosfrica, las prdidas por el espacio libre,
entre otras.
283
5.3.2 Redes inalmbricas

Al igual que las redes tradicionales almbricas vamos a clasificar a las redes
inalmbricas en:
WWAN / WMAN (Wireless Wide Area Network/ Wireless Metropolitan

Area Network)
WLAN (Wireless Local Area Network)
5.3.2.1 IP Mvil
Una mquina en la red tiene siempre tiene una direccin IP, la cul se conforma
con una parte fijada por la subred en que se encuentra (prefijo de red) y otra
parte pertenece directamente a la direccin de la mquina. Esta direccin IP le
sirve al router para que pueda hacer llegar los paquetes o datagramas que un
usuario en la red le enva a otro, ya sea dentro de la misma red o en una red
diferente, o incluso en subredes diferentes.
Si un mquina cambia de red, tiene que cambiar su direccin IP, esto har que
las conexiones (TCP) que tuviera abiertas se terminan., adems todos los
paquetes que eran enviados hacia ella, no podrn ser entregados porque se
encuentra en una red diferente y como ya lo mencionamos su direccin IP habr
cambiado.
Aun ms complicado es el hecho de que aun si no cambiramos su direccin IP,
la mquina continuara sin recibir los paquetes e incluso dejara de comunicarse
con cualquier mquina, ya que ni siquiera tendra forma de comunicarse con las
mquinas dentro de su red, precisamente porque no cambiamos la direccin IP.
El IP mvil es una tecnologa que permite que un nodo de red ("nodo mvil")
emigre de su "casa" red a otras redes, o dentro del mismo dominio de la
administracin, o a otros dominios administrativos. El IP mvil puede seguir una
computadora principal mvil sin necesitar cambiar la direccin IP del mvil a lo
largo de sus pasos por diferentes redes.
Este mvil se puede pensar como la cooperacin de tres subsistemas
importantes. Primero, hay un mecanismo del descub rimiento definido de modo
que las computadoras mviles puedan determinar sus nuevas puntas de
conexin (direccin de su nueva red) conforme se mueven de lugar al lugar
dentro del Internet. En segundo lugar, una vez que la computadora mvil sepa la
direccin IP en su nueva punta de conexin, se coloca con un agente que lo
representa en su red casera.
284

Sin el IP mvil, uno de los dos mecanismos siguientes se debe emplear para
que un nodo cambie su punta de la conexin sin perder su capacidad de
comunicarse:
El nodo debe cambiar su direccin IP siempre que cambie su punta de la

conexin.
Las rutas a la mquina especfica en cuestin se deben propagar a travs
de la porcin relevante de la infraestructura del enrutamiento de Internet.
Esto es que alguien tendra que recordar las redes por donde va
cambiando la direccin IP de la maquina.
Ambas alternativas son inaceptables en nuestro caso. El primer caso hace

imposible que un nodo mantenga comunicacin con otros nodos cuando el nodo
cambia de localizacin (cambia su direccin IP). El segundo tiene problemas
severos de escalamiento considerando el crecimiento explosivo en ventas de
computadoras porttiles, ya que entre ms computadoras porttiles tendramos
que recordar ms direcciones y adems las direcciones de todas las redes por
donde se est moviendo el nodo.
El IP mvil fue ideado para resolver las metas siguientes para los nodos mviles
que no se mueven con ms frecuencia que una vez por segundo. Permite a los
nodos moverse a partir de una subred a otra. Es conveniente para la movilidad a
travs de medios heterogneos como para la movilidad a travs de medios
homogneos.
Fundamentos de IP Mvil
El terminal mvil tiene dos direcciones IP:
Direccin Local (Home Address): Es fija, es con la que el terminal

mantiene las conexiones con otras mquinas y corresponde con su red
local.
Direccin de Auxilio (Care-of Address): Es cambiante, es la que
corresponde a la red en que se encuentre el mvil en un momento dado.
En la red local, un Agente Local (Home Agent) sabe qu Direccin de Auxilio

tiene en cada momento el terminal mvil:
Recoge los datagramas destinados a la Direccin Local del terminal

mvil
Los reenva dentro de un nuevo datagrama dirigido a la Direccin de
Auxilio (tnel).
Como podemos ver el Agente Local funciona como un intermediario entre las
mquinas que se quieren comunicar con la terminal mvil, ya que recibe los
mensajes que va n hacia a ella y despus los reenva, por lo tanto, este Agente
285

conoce la direccin actual de la terminal mvil. Esto lo logra sabiendo la
direccin local, que es fija, y adems l sabe la direccin de auxilio que en el
instante preciso de la comunicacin tiene, porque sabemos que en el siguiente
instante esta direccin puede cambiar.
Fases del IP Mvil
Las Fases que comprenden al direccionamiento mvil de IP son las siguientes:
Descubrimiento de la Direccin de Auxilio por parte de la terminal mvil

en cada paso por diferentes redes.
Registro de la Direccin de Auxilio en el Agente Local para que l pueda
hacer la conexin o tuneleo de los datagramas.
Tnel desde el Agente Local a la Direccin de Auxilio para que la
informacin sea entregada a la terminal mvil.
Problemas de IP Mvil
Algunos problemas que conlleva el uso de IP Mvil son los siguientes:
El encaminamiento en tringulo es ineficiente: esto es porque,

dependemos de la velocidad de la mquina que esta funcionando como
agente y si esta falla toda la comunicacin se pierde.
La creacin de tneles nos genera costos extras en nuestras conexiones.
Cuello de botella en el Agente Local: esto es debido a la carga de
registros que tiene que manejar.
Implicaciones de seguridad en cortafuegos: esto es porque el Agente
Local es el que esta dando salida a todos los paquetes, si no se protege
dicha mquina, entonces todos los paquetes que son enviados y recibidos
pueden ser tomados.
5.3.2.2 LANs inalmbricas

WLAN son las siglas en ingls de Wireless Local Area Network. Es un sistema
de comunicacin de datos flexible muy utilizado como alternativa a la LAN
cableada o como una extensin de sta. Las WLAN han adquirido importancia
en muchos campos incluido el de la medicina.
286
Una WLAN transmite y recibe datos utilizando ondas electromagnticas, en

lugar del par trenzado, coaxial o fibra ptica utilizado en las LAN
convencionales, y que proporciona conectividad inalmbrica de igual a igual
(peer to peer), dentro de un edificio, de una pequea rea residencial/urbana o
de un campus universitario. En EEUU proliferan estas redes para acceso a
Internet, en donde hay ms de 4.000 zonas de acceso, y en Europa es previsible
que pronto se extiendan.
Las WLAN se encuadran dentro de los estndares desarrollados por el IEEE
(Instituto de Ingenieros Elctricos y Electrnicos) para redes locales
inalmbricas. Otras tecnologas como HyperLAN apoyada por el ETSI, y el
nuevo estndar HomeRF para el hogar, tambin pretenden acercarnos a un
mundo sin cables y, en algunos casos, son capaces de operar en conjuncin y
sin interferirse entre s. Otro aspecto a destacar es la integracin de las WLAN
en entornos de redes mviles de 3G (UMTS) para cubrir las zonas de alta
concentracin de usuarios (los denominados hot spots), como solucin de
acceso pblico a la red de comunicaciones mviles.
Como todos los estndares 802 para redes locales del IEEE, en el caso de las
WLAN, tambin se centran en los dos niveles inferiores del modelo OSI, el fsico
y el de enlace, por lo que es posible correr por encima cualquier protocolo
(TCP/IP o cualquier otro) o aplicacin, soportando los sistemas operativos de red
habituales, lo que supone una gran ventaja para los usuarios que pueden seguir
utilizando sus aplicaciones habituales, con independencia del medio empleado,
sea por red de cable o por radio. La especificacin IEEE 802.11 define redes
locales inalmbricas que emplean ondas de radio en la banda de 2.4 GHz y 5
GHz conocido como espectro esparcido. Las velocidades tpicas de esta
tecnologa son 11 Mbps en la especificacin IEEE 802.11b y est en desarrollo
la especificacin IEEE 802.11a en la banda de 5 GHz que alcanzar velocidades
de hasta 54 Mbps.
Las redes locales inalmbricas se han vuelto muy populares hoy en da, stas
pueden proveer acceso a Internet por ejemplo a estudiantes alrededor de un
287

campus universitario utilizando una computadora porttil provista con una tarjeta
con acceso inalmbrico.
Una de las reas de mayor potencial en la evolucin futura de las
telecomunicaciones es la transmisin inalmbrica digital de banda ancha.
Idealmente, un sistema inalmbrico de banda ancha permitira la transmisin de
cualquier tipo de informacin digitalizada (audio, vdeo, datos) desde cualquier
lugar y en cualquier momento, con posibilidad de transmitir en tiempo real de ser
necesario. Entre las ventajas de un sistema inalmbrico sobre uno cableado
podemos mencionar:
Movilidad: la cual apoya la productividad y la efectividad con que se presta el
servicio. Aunque los costos iniciales son mayores que los que supondra un
sistema cableado, a lo largo del tiempo los gastos de operacin pueden ser
significativamente menores. Menor tiempo de instalacin y puesta en marcha del
sistema. La instalacin es ms sencilla. Existe completa flexibilidad en cuanto a
la configuracin del sistema. Se pueden tener diversas topologas para
satisfacer los requerimientos de aplicaciones e instalaciones especficas.
La aparicin de un sistema de esta naturaleza requiere la conjuncin de varios
factores, entre las que podemos mencionar:
Utilizacin de tcnicas de espectro esparcido, que en combinacin con

esquemas de sectorizacin y/o celularizacin permitirn un uso ms
eficiente del cada vez ms congestionado (y costoso) espectro
radioelctrico.
Desarrollo de sistemas de microondas econmicos y compactos que
operen a frecuencias cada vez ms altas.
Nuevos y mejores modelos de propagacin que permitan una mejor
prediccin de los factores que afectan la calidad del servicio, tales como
los efectos de tra yectorias mltiples, prdidas por ocultamiento y
atenuacin por lluvia, entre otros.
Desarrollo de "antenas inteligentes" que compensen las variaciones en el
canal de transmisin y que minimicen los efectos de la interferencia cocanal.
Tcnicas de modulacin robustas que permitan altas velocidades de
transmisin con bajo BER en presencia de condiciones adversas.
Esquemas de enrutamiento apropiados que garanticen cobertura
adecuada y al mismo tiempo calidad de servicio.
Nueva legislacin conducente a una mejor administracin y control del
espectro radioelctrico.
Aunque no todos los factores mencionados existen en la actualidad, un sistema

inalmbrico es en muchos casos es la alternativa ms atractiva en aplicaciones
tales como telefona, interconexin de redes, acceso a Internet de alta velocidad,
teleconferencia, etc.
288

Ejemplos de uso: ventas al pormenor, almacenes, manufacturacin, etc., de
modo que se transmite la informacin en tiempo real a un procesador central.
Cada da se reconocen ms este tipo de redes es un amplio nmero de
negocios y se augura una gran extensin de las mismas y altas ganancias.
Es clara la alta dependencia en los negocios de las redes de comunicacin. Por
ello la posibilidad de compartir informacin sin que sea necesario buscar una
conexin fsica permite mayor movilidad y comodidad. As mismo la red puede
ser ms extensa sin tener que mover o instalar cables.
Respecto a la red tradicional la red sin cable ofrece las siguientes ventajas:
Movilidad: Informacin en tiempo real en cualquier lugar de la

organizacin o empresa para todo usuario de la red. El que se obtenga en
tiempo real supone mayor productividad y posibilidades de servicio.
Facilidad de instalacin: Evita obras para tirar cable por muros y techos.
Flexibilidad: Permite llegar donde el cable no puede.
Reduccin de costos: Cuando se dan cambios frecuentes o el entorno es
muy dinmico el costo inicialmente ms alto de la red sin cable es
significativamente ms bajo, adems de tener mayor tiempo de vida
y menor gasto de instalacin.
Escalabilidad: El cambio de topologa de red es sencillo y trata igual a las
redes grandes o pequeas.
Cmo trabajan las WLAN

Se utilizan ondas de radio o infrarrojos para llevar la informacin de un punto a
otro sin necesidad de un medio fsico. Las ondas de radio son normalmente
referidas a portadoras de radio ya que stas nicamente realizan la funcin de
llevar la energa a un receptor remoto. Los datos a transmitir se superponer a la
portadora de radio y de este modo pueden ser extrados exactamente en el
receptor final. Esto es llamado modulacin de la portadora por la informacin
que est siendo transmitida. De este modo la seal ocupa ms ancho de banda
que una sola frecuencia. Varias portadoras pueden existir en igual tiempo y
espacio sin interferir entre ellas, si las ondas son transmitidas a distintas
frecuencias de radio. Para extraer los datos el receptor se sita en una
determinada frecuencia ignorando el resto. En una configuracin tpica de LAN
sin cable los puntos de acceso (transceiver) conectan la red cableada de un
lugar fijo mediante cableado normalizado. EL punto de acceso recibe la
informacin, la almacena y transmite entre la WLAN y la LAN cableada. Un
nico punto de acceso puede soportar un pequeo grupo de usuarios y puede
funcionar en un rango de al menos treinta metros y hasta varios cientos.
El punto de acceso (o la antena conectada al punto de acceso) es normalmente
colocado en alto pero podra colocarse en cualquier lugar en que se obtenga la
cobertura de radio deseada.
289

El usuario final accede a la red WLAN a travs de adaptadores. Estos
proporcionan una interfaz entre el sistema de operacin de red del cliente (NOS:
Network Operating System) y las ondas, va una antena. La naturaleza de la
conexin sin cable es transparente al sistema del cliente.
Configuraciones de la WLAN
Pueden ser simples o complejas. La ms bsica se da entre dos computadoras
equipados con tarjetas adaptadoras para WLAN, de modo que pueden poner en
funcionamiento una red independiente siempre que estn dentro del rea que
cubre cada uno. Esto es llamado red de igual a igual.
Cada cliente tendra nicamente acceso a los recursos de otro cliente pero no a
un servidor central. Este tipo de redes no requiere administracin o
preconfiguracin.
Red Peer to Peer
Instalando un Punto de Acceso (APs) se puede doblar el rango al cul los
dispositivos pueden comunicarse, pues actan como repetidores. Desde que el
punto de acceso se conecta a la red cableada cualquier cliente tiene acceso a
los recursos del servidor y adems actan como mediadores en el trfico de la
red en la vecindad ms inmediata. Cada punto de acceso puede servir a varios
clientes, segn la naturaleza y nmero de transmisiones que tienen lugar.
Existen muchas aplicaciones en el mundo real con entre 15 y 50 dispositivos
cliente en un solo punto de acceso.
Cliente y punto de acceso
Los puntos de acceso tienen un rango finito, del orden de 150m en lugares
cerrados y 300m en zonas abiertas. En zonas grandes como por ejemplo un
campus universitario o un edificio es probablemente necesario ms de un punto
de acceso. La meta es cubrir el rea con clulas que solapen sus reas de modo
que los clientes puedan moverse sin cortes entre un grupo de puntos de acceso.
Esto es llamado "roaming".
Mltiples puntos de acceso y "roaming"
Para resolver problemas particulares de topologa, el diseador de la red puede
elegir usar un Punto de Extensin (EPs) para aumentar el nmero de puntos de
acceso a la red, de modo que funcionan como tales pero no estn enganchados
a la red cableada como los puntos de acceso. Los puntos de extensin
funcionan como su nombre indica: extienden el rango de la red retransmitiendo
las seales de un cliente a un punto de acceso o a otro punto de extensin. Los
puntos de extensin pueden encadenarse para pasar mensajes entre un punto
de acceso y clientes lejanos de modo que se construye un "puente" entre
ambos.
290

Uso de un punto de extensin
Uno de los ltimos componentes a considerar en el equipo de una WLAN es la
antena direccional. Por ejemplo: se quiere una Lan sin cable a otro edificio a
1Km de distancia. Una solucin puede ser instalar una antena en cada edificio
con lnea de visin directa. La antena del primer edificio est conectada a la red
cableada mediante un punto de acceso. Igualmente en el segundo edificio se
conecta un punto de acceso, lo cul permite una conexin sin cable en esta
aplicacin.
5.3.2.3 WANs inalmbricas
WWAN (Wireless Wide Area Networks) son redes extensas sin cables.
Ejemplos de este tipo de redes son las redes de telefona mvil: GSM, GPRS,
TDMA, etc.
El alcance de una WWAN puede llegar hasta 30 km, lo que ofrece a los usuarios
un modo de seguir conectados mientras se desplazan o estn alejados de otra
infraestructura de red.
Las redes de rea amplia inalmbricas transmiten los datos mediante seales de
telefona mvil, a travs de un proveedor de servicios de telefona mvil, con
velocidades de conexin similares a las de acceso telefnico de 56K. Las
velocidades de descarga estn limitadas a 53 Kbps. Las velocidades de carga
son inferiores (unos 30 Kbps). Las velocidades pueden variar segn el estado de
la lnea y el fabricante del mdem. Es necesario disponer de una lnea telefnica
analgica y del servicio. (El alcance y la velocidad varan segn el entorno y
otros factores.)
Su alcance ofrece a los usuarios un modo de conectarse mientras se desplazan
o estn alejados de otra infraestructura de red.
Redes inalmbricas tipo WAN/MAN :
291
Telefona celular analgica y celular

Radiolocalizacin de dos vas (pagers)
Radio enlaces terrestres de microondas
Lser/infrarrojo
WLL (Wireless Local Loop)
LMDS/MMDS
Comunicaciones por satlite
En la categora MAN/WAN tenemos primeramente al acceso a Internet por

medio de telefona celular. Aunque originalmente la telefona celular fue utilizada
para la transferencia de voz, muy pronto se desarrollaron protocolos para poder
transferir datos a travs de esta tecnologa inalmbrica. La primera de ellas fue
CDPD (Celullar Digital Packet Data), desarrollada a mediados de los 90s por
AT&T. CDPD provee la transmisin inalmbrica de datos digitales como Internet
a travs de la telefona celular.
Actualmente provee transferencias hasta 14.4 Kbps si se emplea la tcnica de
acceso mltiple CDMA (Code Division Multiple Access), mientras que en
TDMA (Time Division Multiple Access) est limitada a 9.6 Kbps. CDPD se
utiliza actualmente para transmitir mensajes breves a PDAs y correo electrnico
a telfonos celulares. Es posible el acceso limitado a Internet debido a que
CDPD est basado en el protocolo de Internet TCP/IP. Con CDPD es posible
transferir datos a travs de redes pblicas basadas en circuitos como en
paquetes. En un futuro cercano aparecern nuevos servicios con ms alta
velocidad basados en CDPD a travs de redes basadas en paquetes.
Otro protocolo que provee acceso a Internet es WAP (Wireless Access
Protocol). Con WAP son posibles las comunicaciones de datos entre redes
inalmbricas a celulares y otros dispositivos porttiles como PDAs,
radiolocalizadores, telfonos inteligentes, etc.
Las especificaciones de WAP soportan la mayora de los servicios y protocolos
de las redes celulares de hoy en da tales como GSM, PDC, TDMA, CDMA y
CDPD. Uno de los principales objetivos de la especificacin WAP es permitir que
dispositivos porttiles se interconecten con las redes inalmbricas
independientemente de sistemas operativos y protocolos.
Es por eso que WAP utiliza un lenguaje conocido como WML (Wireless Markup
Language) que permite la conexin entre las redes y los dispositivos porttiles.
Otras tecnologas WAN/MAN que permiten el acceso a Internet a altas
velocidades son MMDS, LMDS, WLL, enlaces de microondas terrestres, va
lser infrarrojo y comunicaciones va satlite.
292
5.4. Aplicaciones Mviles

Las aplicaciones para dispositivos mviles bsicamente son programas capaces
de ejecutarse en ambientes operativos reducidos. Tales ambientes o sistemas
operativos reducidos o compactos se instalan en dispositivos mviles como PDA
(Personal Digital Assistant), como por ejemplo, Pocket PC, Palm, Smart Phone,
etc.
Los dos tipos de aplicaciones tpicas para dispositivos mviles son:
1. Aplicaciones Stand-Alone: Son aplicaciones que directamente se
instalan sobre el dispositivo mvil.
2. Aplicaciones Web: El dispositivo mvil nicamente utiliza un navegador
para Internet y se conecta por red (almbrica o inalmbrica) al servidor
Web que hospeda la aplicacin.
A continuacin se ejemplifica la creacin
correspondientes a estos dos tipos de programas.
de
aplicaciones
sencillas
EJERCICIO
Creacin de una Aplicacin Windows para una Pocket PC.
En el siguiente ejemplo, vamos a crear una aplicacin Windows para una Pocket
PC y una Aplicacin Web, la cul vamos a acceder desde la Pocket PC.
Primero veremos la creacin de la Aplicacin para SmartDevice en C#, la cul
despus se va a correr en el emulador de una Pocket PC.
1. Damos clic en Visual Studio .NET 2003
293
2. Seleccionamos Archivo -> Nuevo -> Proyecto

3. Nos va a aparecer la siguiente ventana, dentro de la cul haremos clic
en Proyectos de Visual C# y despus en Aplicacin para SmartDevice.
4. Damos un Nombre y una Ubicacin para nuestro Proyecto.

5. En la siguiente pantalla, seleccionamos Pocket PC y Aplicacin para
Windows.
294
6. Esta es la ventana de desarrollo de nuestra Aplicacin para

SmartDevice.
7. Del cuadro de herramientas arrastre dos Botones y una Etiqueta .
295
8. Dentro de las propiedades del button1, ajustamos el campo Text a

SI.
9. Hacemos lo mismo para el button2, solo que Text lo ajustamos a NO.

10. Dentro de las propiedades del label1, ajustamos Text a vaco, sin
texto.
11. Damos doble clic en el campo de button1 y veremos el cdigo para
dicho botn.
296
12. Dentro del mtodo button1_Clic colocamos la siguiente lnea

label1.Text = "Diste clic en " + button1.Text;
13. Hacemos lo mismo pero con el button2 y colocamos la siguiente lnea

label1.Text = "Diste clic en " + button2.Text;
14. Los mtodos deben quedar como se ve en la siguiente figura.
297

15. Seleccione Generar -> Generar Solucin. El programa debe generarse
sin problemas.
16. Seleccione Depurar -> Iniciar.

17. En el cuadro de texto seleccione Emulador de Pocket PC 2002 y de
clic en Implementar.
18. Se abre el emulador del Pocket PC y la Aplicacin que generamos.
298
19. Corra la Aplicacin. De clic en alguno de los botones. Vea las salidas
que genera el programa.
299

Creacin de una Aplicacin Web ASP.NET para Pocket PC
En el siguiente ejemplo, vamos a crear una aplicacin Web ASP.NET para que
sea accedido desde una Pocket PC. La aplicacin se crear primero en el IIS de
una mquina, para posteriormente acceder a dicha WebForm por medio de la
Pocket PC.
Primero crearemos la Aplicacin ASP.NET.
1. Damos clic en Visual Studio .NET 2003
2. Seleccionamos Archivo -> Nuevo -> Proyecto

3. Nos va a aparecer la siguiente ventana, dentro de la cul haremos clic en
Proyectos de Visual C# y despus en Aplicacin para SmartDevice.
300
4. Damos un Nombre y una Ubicacin para nuestro Proyecto.

5. Esta es la ventana de desarrollo de la Aplicacin Web ASP.NET
301

6. Seleccionamos dos botones y una etiqueta, del cuadro de controles y los
colocamos en la WebForm
7. Dentro de las propiedades del Button1, ajustamos la propiedad Text a

SI.
302
8. Dentro de las propiedades del Button2, ajustamos la propiedad Text a

NO.
9. Dentro de las propiedades del Label1, ajustamos la propiedad Text a
vaco.
10. Seleccione Generar -> Generar Solucin. El programa debe generarse sin
errores.
303
11. Seleccione Depurar -> Iniciar

12. Se abre una nueva ventana del Browser con la direccin donde se genero
su Aplicacin Web ASP.NET
304
13. Ahora vuelva a abrir la Aplicacin que gener anteriormente para

SmartDevice y corra de nuevo el emulador.
14. Para abrir de nuevo la Aplicacin anterior seleccione la Pestaa Pgina
de Inicio dentro de Visual Studio .NET.
15. Seleccione el Proyecto de SmartDevice con el nombre que le haya
puesto.
16. Seleccione Depurar -> Iniciar. En el cuadro de Texto seleccione Emulador
de Pocket PC 2002 y de clic en Implementar.
305

17. Una vez abierto el emulador de clic en el Icono de Windows y seleccione
Explorer.
18. En la ventana del Explorador seleccione Ver -> Barra de Direcciones
306

19. En la Barra de Direcciones copie la direccin de la Aplicacin Web que
gener, solo que en vez de poner local, coloque la direccin IP de la
mquina de donde desea correr la Aplicacin Web.
La direccin debe ser del tipo:
http://XXX.XXX.XXX.XXX/WebApplication1/WebForm1.aspx
20. Pruebe la Aplicacin. Los resultados deben ser los siguientes
307

Atributos
Arriba del
Estndar
En el Estndar
Debajo del
Estndar
Puntos de
Atributo
Obtenidos
(10-9 )
(8.5-7)
(6.5-0)
La informacin
La informacin
La informacin
revisada
revisada permiti
revisada no
permiti a los
permiti a los
estudiantes
la
comprender con
estudiantes
comprender
Informacin
claridad los
comprender
solamente los
ejercicios y
los ejercicios y
ejercicios y
programas.
programas.
programas.
(10-9 )
(8.5-7)
(6.5-0)
Los estudiantes
han demostrado
Los
el significado del
material
elaborando
correctamente,
Conexiones
material
el material,
mientras
Especialistas
extienden y
explican la
informacin,
en su estudio
tema.
incorporndola en
del tema.
el estudio del
tema.
308

IntroduccionSistemasDistribuidos SE PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IntroduccionSistemasDistribuidos SE PDF

Uploaded by

Copyright:

Available Formats

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

INTRODUCCIN A LOS SISTEMAS DISTRIBUIDOS

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

INTRODUC CIN ................................................................................................................................................... 1

ARQUITECTURA CLIENTE SERVIDOR ..................................................................................................33

FUNDAMENTOS DE A RQUITECTURA CLIENTE SERVIDOR .........................................................................33

LENGUAJES Y PLATAFORMAS DE DESARROLLO.....................................................................................227

A NTECEDENTES EN COMPUTACIN M VIL .............................................................................................248

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Una de las primeras caracterizaciones de un Sistema Distribuido fue realizada

Est compuesto por varios recursos informticos de propsito general,

Existencia de varias computadoras. En general, cada una con su propio

Como lo hemos observado, el trmino de Computacin Distribuida se define de

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Figura 1. Un esquema clsico de la conexin a Internet

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Figura 2. Un sistema distribuido organizado como Middleware

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Interceptacin: Obtiene acceso a informacin. Ataca la confidencialidad.

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Fabricacin: Falsifica la informacin. Ataca la autenticidad.

Para defenderse de este tipo de amenazas se han desarrollado diversas

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.

Introduccin a los Sistemas Distribuidos

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.