2 Cap2

Metodologa de acceso remoto a plantas industriales
CAPITULO 2
SISTEMAS DISTRIBUIDOS EN ENTORNOS

INTRANET / INTRANETS
2.
Sistemas distribuidos en entornos Internet / INTRANET

2.1
Internet / intranet
2.1.1
TCP / IP en entornos industriales
2.1.2
IPv4 vs. IPv6
2.2
Arquitecturas distribuidas no orientadas a objetos
2.2.1
Sockets
2.2.2
HTML
2.2.3
Servicios Web
2.2.4
Protocolos de gestin de red
2.3
Arquitecturas distribuidas orientadas a objetos
2.3.1
CORBA
2.3.2
COM / DCOM / COM+
2.3.3
Java / RMI
2.3.4
Integracin de arquitecturas distribuidas en navegadores Web
2.4
Estndares basados en arquitecturas distribuidas
2.4.1
OPC
2.4.2
Profinet
2.5
Seguridad en redes Internet / intranet
2.5.1
Cortafuegos
2.5.2
Nociones bsicas de criptografa
2.5.3
Protocolo SSL (Secure Sockets Layer)
2.5.4
Seguridad en sistemas distribuidos
2.5.5
Kerberos
2.5.6
Mecanismos de autenticacin
2.6
Conclusiones
Captulo 2 Sistemas distribuidos en entornos Internet / Intranet
2-1
2. SISTEMAS DISTRIBUIDOS EN ENTORNOS INTERNET /

INTRANET
En este captulo se hace un anlisis de las diferentes tecnologas susceptibles de ser
utilizadas en los sistemas industriales de acceso remoto. Se han considerado
tecnologas orientadas a objetos y no orientadas a objetos. Tambin se han
considerado algunos estndares basados en las arquitecturas distribuidas analizadas
que han sido ampliamente adoptados en la industria como es el caso de OPC o el
prometedor Profinet. Por otra parte, dado el inters que en una tecnologa de acceso
requiere la seguridad, tambin se presenta un breve panorama de las tcnicas ms
habituales para el establecimiento de conexiones seguras.
2.1
INTERNET / INTRANET
Internet es una red de ordenadores pblica basada en tecnologa de conmutacin de

paquetes que conecta diferentes subredes de ordenadores a lo largo de todo el
planeta. Surgi como resultado del programa ARPANET (Advanced Research Projects
Agency Network) emprendido en el ao 1969 por el departamento de defensa
americano. El objetivo era conseguir la comunicacin entre los ordenadores situados
en diversos centros de investigacin de los Estados Unidos. A partir de esta fecha, el
tamao de la red inicial ha ido creciendo exponencialmente hasta llegar a la situacin
actual en la que Internet es omnipresente. Paralelamente se han ido desarrollando
una serie de protocolos para dar respuesta a nuevos requisitos de comunicacin. As
se desarroll la familia de protocolos TCP / IP (RFC 1180, 1991; Stevens, W., R.,
1994). Las siglas TCP / IP, que toman el nombre de dos de los protocolos centrales
de la familia (TCP, Transmission Control Protocol e IP, Internet Protocol), engloban al
conjunto de protocolos que hacen posible la comunicacin entre ordenadores a
travs de Internet. Este conjunto de protocolos recibe la denominacin ms comn
de: Tecnologas Internet. Estos protocolos se organizan por capas, en un enfoque
similar al modelo de referencia OSI de ISO (ISO 7498-1, 1994; Zimmermann, H.,
1980), siendo cada capa responsable de un aspecto determinado de las
2-2
comunicaciones. Sin embargo, al ser los protocolos TCP / IP previos al modelo OSI
de ISO los nombres y funcionalidades de las capas involucradas son distintos.
Entre los protocolos definidos en TCP / IP caben sealar los protocolos de red,
transporte y aplicacin:
Red: IP (Internet Protocol, RFC 791, 1981). Gestiona el encaminamiento de los

paquetes a travs de la red Internet.
Transporte: Este nivel proporciona un flujo de datos entre dos, o ms

ordenadores. Existen dos alternativas: TCP (Transmission Control Protocol, RFC
793, 1981) que crea un circuito virtual que proporciona un flujo de datos
fiable entre dos ordenadores y UDP (User Datagram Protocol, RFC 768, 1981)
que slo enva paquetes (datagramas) de un ordenador a otro sin ningn tipo
de garantas.
Aplicacin: En el nivel de aplicacin se gestionan los detalles de aplicaciones

particulares. Algunos de los protocolos de este nivel permiten: acceder a
ordenadores remotos (Telnet; RFC 854, 1983), enviar mensajes de correo
electrnico (SMTP, Simple Mail Transfer Protocol; RFC 821, 1982; RFC 822,
1982), intercambiar ficheros (FTP, File Transfer Protocol; RFC 959, 1985) o
navegar a travs de documentos de hipertexto (HTTP, Hypertext Transfer
Protocol, RFC 2616, 1999).
2.1.1 TCP / IP en entornos industriales

Con el crecimiento de Internet los protocolos TCP / IP han llegado a ser los
protocolos ms extendidos en redes corporativas, fundamentalmente debido a su
versatilidad y aptitud para conectar computadores en redes heterogneas. Sin
embargo, los sistemas de control industriales presentan ciertas peculiaridades que han
sido tradicionalmente resueltas por protocolos propietarios (que restringan la
interoperabilidad entre las aplicaciones). Esta situacin est empezando a cambiar y
en la actualidad los protocolos TCP / IP se estn empezando a utilizar tambin en
entornos industriales. Tal y como se explica en Maciel y Ritter (1998) esta
2-3
transformacin se justifica en gran parte por razones econmicas, as como por su

elevada madurez y flexibilidad.
La adopcin de protocolos propietarios tena ciertas ventajas sobre unos protocolos
estndar. Normalmente, los protocolos propietarios aaden menor carga sobre la red
a la vez que requieren dispositivos con menos recursos. Como contrapartida, los
protocolos propietarios dificultan enormemente la integracin de dispositivos de
diferentes fabricantes dentro de una red nica y exigen un conocimiento de
soluciones personalizadas por parte de los desarrolladores de sistemas de control
distribuidos.
Como ya se ha comentado en el captulo de Introduccin, a medida que los
microprocesadores han ido aumentando en capacidad de clculo y disminuyendo en
coste ha sido posible la introduccin de tecnologas ms complejas que permiten una
mejor integracin de los sistemas de control. Esta tendencia ha jugado un papel clave
en la popularizacin de TCP / IP ya que se contaba con dispositivos de mayores
prestaciones que compensaban la prdida de eficiencia resultante de usar unos
protocolos estndar frente a soluciones propietarias. Adems, el uso de tecnologas
de red de alta velocidad como ATM (Asynchronous Transfer Mode), FDDI (Fiber
Distributed Data Interface) o Fast Ethernet permiten obtener buenos tiempos de
respuesta con tecnologas probadas y disponibles.
Conviene, por tanto mencionar las caractersticas ms relevantes de los protocolos
TCP / IP para ver qu pueden aportar en el campo de los sistemas de control
industriales.
Cuando se utilizan los protocolos TCP / IP en una red se requiere que la pila de
protocolos TCP / IP est incluida en todos los dispositivos y que adems, estos
dispositivos cuenten con una direccin IP. Todas las comunicaciones se efectuarn
de la misma manera utilizando alguno de los protocolos de la familia TCP / IP, lo
que facilitar la integracin de dispositivos en aplicaciones distribuidas. Incluso es
posible utilizar aplicaciones estndar (telnet ftp, Navegadores Web, etc) para acceder
directamente a los dispositivos de la planta que implementen dicho protocolo.
2-4
Estos nuevos dispositivos requieren unas prestaciones y un espacio de memoria

mnimos para implementar la pila de protocolos IP. As, una implementacin
software de la pila de protocolos TCP / IP requiere como mnimo 30 KB de
memoria de cdigo y 10 KB de memoria RAM (Maciel y Ritter, 1998). Lo cual
imposibilita usar los protocolos TCP / IP con dispositivos basados en
microprocesadores de 4 u 8 bits.
Ventajas e inconvenientes de IP en sistemas de control
En trminos econmicos es evidente que el uso de tecnologa estndar y abierta en
lugar de tecnologas propietarias produce interesantes beneficios: Por un lado, el
coste de un sistema abierto suele ser menor ya que es habitual la existencia en el
mercado de diversos fabricantes de un producto dado. Por otra parte, tambin hay
un mayor nmero de profesionales formados que pueden mantener los sistemas, lo
que reduce los costes de mantenimiento y formacin.
Adems, al estar los protocolos TCP / IP adoptados por un gran nmero de
fabricantes estos protocolos facilitan la integracin de sus equipos.
Como desventajas habra que sealar su menor rendimiento frente a los protocolos
propietarios, especficamente diseados para ser utilizados en aplicaciones de control.
Por otra parte, cuando se usan los protocolos TCP / IP resulta necesario utilizar
dispositivos hardware con mayores prestaciones, sobre todo en trminos de memoria
y capacidad de clculo.
2.1.2 IPv4 vs. IPv6
En la actualidad la versin ms utilizada del protocolo IP sobre el que descansan el
resto de protocolos de TCP / IP es la versin 4 (IPv4, RFC 791, 1981). No obstante,
IPv4 es un protocolo relativamente antiguo, y como se ha podido constatar necesita
cierta actualizacin. Algunos de los problemas que presenta son:
Un espacio de direcciones limitado: IP define un campo de direccin de

32 bits con lo que se permite un mximo de 4000 millones de direcciones
posibles (232). En principio se podra pensar que este nmero es suficiente,
2-5
sin embargo, la estructura de las direcciones IP (en dos niveles: nmero de

red y nmero de computador) resulta una forma poco econmica de utilizar
el espacio de direcciones (con lo que muchas direcciones se pierden).
Por si esto fuera poco hay que resaltar el espectacular crecimiento de Internet
durante los ltimos aos. As en determinadas reas, como por ejemplo los
entornos industriales, se tiende a asociar una direccin IP a cada uno de los
dispositivos conectados, incluso los ms sencillos como son los sensores o
actuadores, con lo que el nmero de direcciones IP requeridas es muy
elevado.
Direcciones IP determinadas por la topologa de la red: Las direcciones

IP asignadas a los dispositivos vienen determinadas por la topologa de la red.
As, un cambio en la topologa obliga a reorganizar las direcciones IP de los
dispositivos. Las nuevas tecnologas como las redes inalmbricas requieren
que el protocolo de red se adapte a topologas dinmicas que permitan
conectar dispositivos inalmbricos mviles a una red.
Inexistencia de mecanismos de autoconfiguracin: Para que el

ordenador o dispositivo permita el acceso a Internet debe ser configurado
correctamente. Adems, esta configuracin debe adaptarse a la topologa de
la red.
Inexistencia de mecanismos intrnsecos de seguridad: El protocolo

IPv4 no introduce mecanismos de seguridad, con lo que es necesario
introducirlos en los protocolos superiores disminuyendo la eficiencia de la
arquitectura de comunicaciones.
Ineficiente gestin de la calidad de servicio en las conexiones: IPv4 no

introduce mecanismos que permitan gestionar la calidad de servicio. Por ello,
es necesario introducirla en protocolos de nivel superior.
La siguiente versin de los protocolos TCP / IP, IPv6 (RFC 2460, 1998; Stallings,
W., 2000; Huitema, C., 1996), est disponible desde hace ya algn tiempo. Aunque
introduce interesantes ventajas sobre su antecesor, IPv4, su implantacin est
2-6
resultando bastante lenta (de momento slo est disponible en dominios locales o
islas). Las razones de esta implantacin tan lenta hay que buscarlas en el propio xito
de IPv4. Este xito ha creado una situacin de inercia provocada por la amplia base
de aplicaciones sobre IPv4 existentes. Adems, se han introducido una serie de
mecanismos que han permitido exprimir al mximo el protocolo IPv4. Un buen
ejemplo de estos mecanismos es NAT (Network Address Translation, RFC 1631, 1994).
Este mecanismo permite utilizar direcciones IP dinmicas entre un computador y un
servidor NAT, de forma que hacia el exterior todo el trfico se enmascara como
generado por el servidor NAT siendo necesaria una nica direccin IP externa.
No obstante, como se ha comentado anteriormente, las perspectivas inmediatas
indican que el nmero de dispositivos conectados a Internet seguir creciendo,
incluso a mayor velocidad. Como ejemplo, en los entornos industriales ya se ha
apuntado la tendencia de que cada dispositivo de control, incluso los ms pequeos,
requerir una direccin IP. Esto est aumentando la necesidad de direcciones IP, lo
que har en breve plazo inevitable el paso a IPv6.
Este protocolo introduce las siguientes mejoras sobre IPv4:
Un espacio de direcciones IP ampliado: IPv6 utiliza direcciones de 128

bits en lugar de las direcciones de 32 bits de IPv4. Esto supone un fuerte
incremento del espacio de direcciones. Como curiosidad, IPv6 permitira
disponer del orden de 6 x 1023 direcciones IP por cada metro cuadrado de la
superficie de la Tierra.
Introduccin de cabeceras opcionales: IPv6 introduce mecanismos que

permiten identificar diferentes tipos de trfico. Esto se consigue con la
introduccin de cabeceras opcionales situadas entre la cabecera IPv6 y la
cabecera de la capa de transporte. Estas cabeceras no se examinan ni
procesan por ningn dispositivo de encaminamiento (router) en la trayectoria
del paquete. As, se optimiza el envo de los paquetes a travs de la red.
Mecanismos para la asignacin de recursos: En lugar del campo tipo de

servicio de IPv4, IPv6 habilita el etiquetado de los paquetes como
pertenecientes a un flujo de trfico particular para el que el emisor solicita un
2-7
tratamiento especial. Esto ayuda al tratamiento del trfico especializado

como, por ejemplo, el de vdeo en tiempo real. Estos mismos mecanismos
pueden ser utilizados, a nivel de protocolo de red, para establecer unos
parmetros determinados de calidad de servicio, de gran inters en algunas
operaciones tpicas del acceso remoto como la monitorizacin de plantas
industriales.
Permite la autoconfiguracin de los ordenadores: Por autoconfiguracin

se entiende que un ordenador sea capaz de descubrir y registrar todos los
parmetros necesarios para conectarse a Internet.
Capacidad de adaptarse dinmicamente a nuevas topologas de red:

As se resolver el problema de conectar dispositivos mviles a Internet, por
ejemplo a redes inalmbricas.
Estas mejoras hacen suponer que, aunque lentamente, su aplicacin se vaya

afianzando. As, las mejoras sealadas en este apartado resuelven algunos de los
problemas actualmente presentes en el acceso remoto a plantas industriales.
2.2
ARQUITECTURAS
DISTRIBUIDAS
NO
ORIENTADAS
OBJETOS
2.2.1 Sockets
Se trata del mtodo de comunicacin entre dos mquinas proporcionado por los
protocolos TCP / IP ms primitivo. Los sockets fueron introducidos en 1981 para
proporcionar comunicaciones entre sistemas UNIX sobre TCP / IP. Hoy en da los
sockets son soportados por la inmensa mayora de los sistemas operativos.
Aunque, en teora, se pueden crear nuevos tipos de sockets, las alternativas ms
extendidas son las siguientes:
Sockets tipo datagrama: Proporcionan una interfaz para usar el protocolo

UDP. UDP enva los datos sobre la red como paquetes independientes
2-8
(datagramas), sin garantizar que stos llegan a destino. UDP incluye cdigos
para detectar errores aunque no intenta detectar paquetes duplicados ni
establecer ningn mecanismo de secuencia. Por tanto, los datos pueden
perderse, duplicarse o recibirse en un orden incorrecto. Como ventajas, se
trata de un protocolo muy rpido y que aade una sobrecarga mnima.
Estas caractersticas hacen a los sockets de este tipo adecuados para algunas
aplicaciones de control. Podrn utilizarse en aquellas aplicaciones en las que
se requiera introducir una sobrecarga mnima y la prdida de algunos datos
no sea un inconveniente severo. En Flammini y otros (2002) puede
encontrarse un ejemplo de cmo el protocolo UDP es utilizado por sensores
inteligentes para enviar informacin a otros nodos en aplicaciones de control.
Sockets tipo stream: Proporcionan una interfaz al protocolo TCP. Este

protocolo, al contrario que UDP, mantiene circuitos virtuales que permiten
un servicio de conexin seguro sobre una sesin. El protocolo TCP se
encarga del control de flujo entre los nodos que toman parte en la
comunicacin, del reensamblado de los paquetes y del mantenimiento de las
conexiones. Por tanto, este tipo de sockets garantiza una comunicacin en la
que se asegura que los paquetes se envan sin errores ni duplicacin y en la
que los paquetes han sido reensamblados en orden. Sin embargo, este
protocolo es ms pesado que UDP, requiere mayor sobrecarga de
programacin y mayores recursos en los dispositivos.
Ventajas e inconvenientes de los sockets

Los sockets son un mecanismo de comunicacin entre aplicaciones bastante primitivo
y farragoso de utilizar. La programacin de aplicaciones complejas utilizando
directamente esta tecnologa es algo a evitar siempre que sea posible. Sin embargo,
no hay que olvidar que los sockets son la base sobre la que se construyen la mayora de
los mecanismos de comunicacin utilizados para interconectar aplicaciones sobre
TCP / IP que se vern a continuacin.
Como principal ventaja cabra sealar que son la alternativa que requiere menos
recursos en los dispositivos involucrados.
2-9
2.2.2 HTML
Los documentos HTML (HyperText Markup Language) constituyen una alternativa
interesante para ser utilizada en el rea de control. Se trata de documentos
autodescriptivos de hipertexto que permiten ser utilizados junto a navegadores Web
(Internet Explorer, Netscape, etc) para lanzar comandos sobre servidores remotos
que a su vez pueden efectuar determinadas acciones sobre plantas industriales.
Para enviar y recibir los documentos HTML sobre una red TCP / IP es necesario
usar el protocolo HTTP (Hypertext Transfer Protocol, RFC 2616, 1999). La primera
versin de este protocolo est disponible desde 1990, con lo que se trata de un
protocolo ya maduro. Este protocolo se usa para acceder a recursos que reciben el
nombre de URLs (Uniform Resource Locators, RFC 1630, 1994).
A continuacin se describe, a grandes rasgos, el funcionamiento bsico del protocolo
HTTP. Los clientes (que normalmente reciben el nombre de Navegadores Web)
solicitan una pgina Web indicada por un URL a un servidor HTTP. Cuando reciben
el documento HTML solicitan todos los recursos (imgenes, etc) asociados a la
pgina. Una vez que tras cierto nmero de peticiones el navegador ha recibido toda la
informacin relacionada con el documento se encargar de reconstruirlo para
mostrarlo sobre la pantalla del ordenador cliente acorde al lenguaje HTML (que es
autodescriptivo). El usuario remoto tendr entonces la opcin de solicitar otro
recurso URL pinchando sobre cualquier otro enlace. HTTP establece una conexin
por cada peticin de forma que el nuevo recurso URL solicitado puede estar
localizado en otro servidor Web. El cliente debe esperar a recibir una respuesta antes
de enviar otra peticin.
Como se puede ver en la Figura 2-1 los servidores Web pueden aceptar comandos
(incluso con parmetros, a travs de formularios) de forma que deleguen las acciones
solicitadas de forma remota sobre dispositivos determinados.
De hecho, existen en el mercado diversos dispositivos industriales que ya ofrecen
servidores Web empotrados. Por ejemplo, existen servidores Web que pueden
integrarse en PLCs (P.e. la gama de procesadores de comunicaciones de Siemens CP
443-1 IT / 343-1 IT, http://www.ad.siemens.de). Tambin existen servidores Web
2-10
para los sistemas empotrados construidos sobre los sistemas operativos de tiempo
real
ms
habituales:
VxWorks
(http://www.windriver.com),
QNX
(http://www.qnx.com) o Linux-RT (http://www.realtimelinuxfoundation.org). As

dichos dispositivos pueden ofrecer informacin de proceso a usuarios remotos a
travs de pginas Web que permiten hacer determinadas operaciones (tpicamente
operaciones de configuracin y monitorizacin).
Cliente
Navegador
Web
Servidor
Protocolo
HTTP
Internet
Documentos
HTML
Servidor Web
Disco
Figura 2-1 Solicitud de pginas Web usando el protocolo HTTP.
Incluso entre los dispositivos de campo ms sencillos, como son los sensores y
actuadores de campo, se pueden encontrar Web empotrados. En Schneeman (1999),
o Coelho, C.N. y otros (2002) pueden encontrarse ejemplos de ello.
Documentos estticos vs. documentos dinmicos
Los documentos HTML pueden ser estticos o dinmicos. En el primer caso, el
contenido del documento es siempre el mismo. Los documentos estticos slo
permiten mostrar datos en un formato previamente creado por los diseadores del
documento con lo que slo resultan interesantes en aplicaciones muy sencillas o para
obtener informacin que no cambia frecuentemente como son, por ejemplo, las
caractersticas de los dispositivos.
2-11
Ms interesantes son los documentos dinmicos. En este caso se permite una mayor
interaccin entre los clientes remotos y los servidores Web. La capacidad de
procesamiento que sustenta las pginas dinmicas se puede llevar a cabo siguiendo
alguno de los siguientes modelos:
Pginas activas en el cliente: En este modelo el procesamiento del

documento se realiza ntegramente en el equipo del usuario. El propio
documento lleva el cdigo que indica al cliente cmo debe procesarlo.
Pginas activas en el servidor: Procesamiento de los documentos en el

equipo donde reside el servidor Web. En este caso es el servidor quin
modifica las pginas previamente a su envo a travs de la Web.
Pginas activas en el cliente y en el servidor: Se trata de un modelo mixto

en el que procesamiento se reparte entre el cliente y el servidor.
La principal ventaja de que el procesamiento de las pginas se efecte en el cliente es

la descarga de trabajo que se le proporciona al servidor al transferir parte del
cmputo al cliente. Esto es especialmente interesante en aquellas aplicaciones en las
que es necesaria gran capacidad de clculo por parte del servidor, cualquier
mecanismo que permita aliviar la carga de proceso sobre el servidor mejorar el
rendimiento global de la aplicacin. Adems, si se usa adecuadamente este modelo se
reducir el ancho de banda utilizado en la comunicacin entre servidores y clientes.
Este esquema de funcionamiento slo puede ser utilizado para preparar la
informacin recibida de los servidores antes de mostrarla en los clientes o como fase
previa antes de enviarla a los servidores en un formato determinado. Sin embargo, en
las aplicaciones industriales, los servidores deben actualizar los contenidos de las
pginas Web con informacin generada por los dispositivos de las plantas
controladas. Por tanto, es evidente que los entornos industriales requieren una
solucin que mezcle pginas activas en el servidor y en el cliente.
En Bobadilla, J. (1999) puede encontrarse una descripcin ms detallada de las
diferentes tecnologas que se pueden utilizar para crear pginas Web dinmicas. A
continuacin se har una breve presentacin de las tcnicas ms interesantes, dejando
2-12
las alternativas orientadas a objetos para un apartado posterior de este mismo

captulo.
Pginas Web dinmicas en el cliente
Las pginas Web se consideran dinmicas en el cliente cuando estn diseadas para
que se ejecute cdigo relacionado con la pgina descargada desde el servidor en el
equipo del usuario. Las tcnicas ms utilizadas son:
Lenguajes de script: Los scripts de una pgina Web permiten la ejecucin de

cdigo en los clientes, normalmente asociado a eventos que se generan a
partir de las acciones que realiza el usuario sobre la pgina (normalmente con
el ratn o teclado). El cdigo de los scripts se descarga de los servidores Web y
se ejecuta directamente en el navegador Web. No obstante, estos lenguajes de
script presentan fuertes restricciones, debido fundamentalmente a razones de
seguridad. Los lenguajes ms utilizados son JavaScript y VisualBasic Script.
Applets Java: Un applet Java es una aplicacin Java (http://java.sun.com) que

se ejecuta sobre un navegador Web. Este funcionamiento permite crear
pginas Web muy vistosas e interactivas con gran potencia, flexibilidad y
eficiencia. Los applets presentan ciertas caractersticas especiales. As, los
applets se vinculan a una pgina Web de forma que permite enviar como
objetos de una pgina Web programas que se ejecutarn en el navegador del
ordenador cliente. Los applets se envan a travs de la red en forma de bytecodes,
una especie de cdigo intermedio que es interpretado por la mquina virtual
Java. El nico requisito de configuracin en el ordenador cliente es que ste
cuente con un navegador Web que tenga alguna mquina virtual Java (JVM,
Java Virtual Machine) instalada.
Por razones de seguridad, los applets presentan ciertas restricciones. La
llamada Java SandBox se encarga de gestionar el acceso del applet a los recursos
del sistema. As se permite que se realicen, o no, determinadas operaciones
que pueden ser crticas en trminos de seguridad, como son la descarga de
ficheros sobre la mquina cliente o la manipulacin de los mismos. Los
navegadores Web ms habituales incluyen alguna mquina virtual Java, o se
2-13
pueden configurar para que utilicen alguna. Los applets Java estn escritos en
el lenguaje Java, muy extendido en Internet. Esta caracterstica los convierte
en un mecanismo bastante habitual en el cliente.
Componentes ActiveX: Otra alternativa similar a los applets Java es el uso de

componentes ActiveX. Un componente ActiveX es un fragmento de cdigo
y datos desarrollado con la tecnologa ActiveX que a su vez se basa en la
tecnologa COM (Component Object Model) de Microsoft. Los componentes
ActiveX pueden crearse con los entornos de programacin tpicos de
Microsoft: Visual Basic, Visual C++, etc.
Al igual que los applets Java, los componentes ActiveX tambin se vinculan a
las pginas Web, de forma que una vez que se ha obtenido un documento
HTML se solicitarn nuevas peticiones dedicadas a obtener, entre otros
recursos, los correspondientes componentes ActiveX relacionados con el
documento Web descargado.
Los componentes ActiveX no permiten una configuracin segura al estilo de
los applets Java, por lo que parecen menos indicados para aquellas aplicaciones
que requieren cierto grado de seguridad. Adems, al contrario que los applets
Java, en los que el cdigo enviado es un cdigo intermedio interpretado por
la mquina virtual Java, en el caso de los componentes ActiveX el cdigo
enviado es binario por lo que slo puede ejecutarse en aquellas plataformas y
sistemas operativos para los que fue compilado, normalmente plataformas
Windows, limitando la portabilidad a otras plataformas.
Pginas Web dinmicas en el servidor

Las pginas Web dinmicas en el servidor se caracterizan porque las operaciones
asociadas a las pginas se realizan en el equipo servidor. As, en el modelo puro de
pginas activas en el servidor, los navegadores de los clientes slo reciben
documentos HTML que se muestran en el formato correspondiente.
Dado que en los sistemas industriales la informacin se genera en la planta, los
dispositivos servidores Web deben integrar dicha informacin en el documento
2-14
HTML que se descargarn los clientes. Por tanto, siempre que se utilice HTML, parte
del proceso se ejecutar obligatoriamente en los servidores de pginas Web.
Entre las alternativas disponibles ms utilizadas se encuentran:
Mecanismos propietarios: Toman informacin directamente de los

dispositivos. P.e. los PLCs con servidores Web empotrados o los servidores
Web introducidos en otros dispositivos inteligentes. En Coelho, C. N. y otros
(2002) se presenta una arquitectura a nivel de circuito integrado que permite
el acceso a dispositivos sencillos de bajo coste.
Programas CGI (Common Gateway Interface): Aunque todava se

utilizan tienden los CGIs a desaparecer. El uso de los CGIs se basa en
programas
escritos
en
diversos
lenguajes
de
programacin
(fundamentalmente Perl y C) que son asociados a las rdenes POST del

protocolo HTTP. As, cada vez que se enva un mensaje al servidor, ste
ejecuta el programa asociado.
Aunque este mtodo es conceptualmente sencillo, presenta algunos
inconvenientes. Por un lado, se trata de un mecanismo bastante ineficiente,
sobre todo a medida que aumenta el nmero de clientes conectados
simultneamente. Por otro lado, el mantenimiento de las pginas Web que se
devuelven al cliente resulta farragoso, ya que los programas CGI tienen que
construir los documentos HTML que se envan a los clientes.
Servlets: Otra opcin es utilizar directamente programas Java en el servidor.

Los programas se ejecutan en el servidor y reciben el nombre de servlets. Estos
programas Java se integran en los servidores Web ms utilizados (p.e.
Apache, Microsoft IIS, etc). Al igual que los CGIs los servlets son pequeos
programas, en este caso escritos en Java, que se cargan en el servidor Web
para gestionar las peticiones de los clientes. Sin embargo, en este caso el
rendimiento es mejor que en el caso anterior.
2-15
Ventajas e inconvenientes del uso de HTTP / HTML

El protocolo HTTP se ha convertido en un estndar de facto en Internet, lo cual es
una ventaja de partida. Su uso permite enviar documentos que son interpretados por
los navegadores Web (Internet Explorer, Netscape Navigator, Opera, ...etc). Estos
navegadores son sencillos de utilizar. De hecho, un gran nmero de usuarios ya estn
familiarizados con ellos. Adems, los navegadores Web estn disponibles para las
plataformas y sistemas operativos ms habituales.
Este protocolo est ganando adeptos en el entorno de los sistemas de control debido
a su popularidad y sencillez. De hecho, empiezan a aparecer dispositivos comerciales
en el mercado que ofrecen acceso a informacin de planta a travs de este protocolo.
Sin embargo, el uso exclusivo del protocolo HTTP no satisface gran parte de las
necesidades que se requieren al acceder a plantas industriales. As, por ejemplo, el
funcionamiento tpico del protocolo HTTP se basa en la arquitectura cliente /
servidor. El cliente solicita un dato al servidor y ste atiende su peticin. Este
planteamiento es poco eficiente y no parece indicado para muchas aplicaciones.
Adems, los mecanismos ms habituales de ejecutar operaciones en los servidores
Web sobrecargan en gran medida las aplicaciones, disminuyendo el rendimiento
global. El hecho de que el protocolo HTTP no mantenga el estado de la conexin
tambin dificulta la operacin de las aplicaciones.
Para resolver esta situacin resulta necesario introducir nuevos mecanismos que
ofrezcan soluciones a esta problemtica. Por ejemplo, la integracin HTTP con
algunas arquitecturas distribuidas orientadas a objetos. Ms adelante se analizar
cmo esta integracin puede resolver algunos de los inconvenientes del uso de
HTTP.
2.2.3 Servicios Web
Los servicios Web (W3C Recommendation, 2004a; Box, D., 2000; Gokhale, A. y
otros, 2002; Jong de, I., 2003) son una tecnologa distribuida emergente relativamente
nueva. De hecho, su primera versin apareci en el ao 2000. Los servicios Web
utilizan XML (Extensible Markup Language, W3C Recommendation, 2004b) para
2-16
permitir a las aplicaciones intercambiar datos a travs de la Web. XML es un

metalenguaje, es decir, un lenguaje que permite describir otros lenguajes. Los
servicios Web, por tanto, utilizarn XML para construir servicios autodescriptivos
liberando a los usuarios de los servicios Web de conocer los detalles de
implementacin de los servicios como son el modelo de los objetos, el lenguaje de
programacin utilizado, la plataforma de ejecucin, etc. El nico requisito necesario
para que las aplicaciones utilicen servicios Web es que stas sean capaces de enviar y
recibir mensajes sobre HTTP.
Los servicios Web fueron diseados para mejorar las transacciones entre empresas
(B2B, Business to Business). El objetivo era permitir que unas aplicaciones pudieran
intercambiar informacin con otras. En ltima instancia, los servicios Web
proporcionan unos servicios que se pueden combinar con otros ya existentes para
proporcionar servicios ms elaborados. Es decir, los servicios Web facilitan la
creacin de aplicaciones complejas combinando varios de estos servicios que estn
distribuidos a travs de Internet.
Funcionamiento bsico de los servicios Web
En el ncleo de los servicios Web se encuentra el protocolo SOAP (Simple Object
Access Protocol). SOAP implementa un protocolo RPC (Remote Procedure Call) sobre
HTTP con una estructura de mensajes basada en XML (Sturm, J., 2000). La
especificacin de SOAP (W3C Recommendation, 2003) incluye:
1. Una sintaxis para definir los mensajes, que contar con una cabecera opcional
y un cuerpo del mensaje. Todo ello es agrupado en una entidad que recibe el
nombre de envelope.
2. Un conjunto de reglas para la construccin de los mensajes.
3. Una serie de convenciones para representar los RPCs del protocolo que
permiten el envo de los mensajes.
A continuacin se muestran los conceptos bsicos del modelo de intercambio de
mensajes de SOAP. Una vez que las aplicaciones locales reciben un mensaje deben
procesarlo como sigue:
2-17
1. Identificar las distintas partes del mensaje.

2. Verificar que las partes identificadas en la fase anterior son comprensibles
para la aplicacin local y procesarlas como corresponda (si el mensaje no es
comprensible simplemente se descarta).
3. En caso de que la aplicacin local no sea el destinatario final, es necesario
quitar aquellas partes del mensaje relativas al destino del mensaje,
identificadas en el primer paso, y reenviar el cuerpo del mensaje a la direccin
definitiva.
Como se ha indicado, uno de los puntos clave de los servicios Web es que son
autodescriptivos. Los interfaces de los servicios disponibles se suelen describir con el
lenguaje WSDL (Web Services Description Language). WSDL es un lenguaje basado en
XML que permite describir los servicios Web disponibles en la red en un formato
entendible por otras computadoras. Haciendo uso de este lenguaje se describen la
localizacin de los servicios, las operaciones soportadas, as como el formato de los
mensajes intercambiados. WSDL no especifica ningn protocolo subyacente aunque
lo ms habitual es utilizar SOAP sobre HTTP.
El enfoque propuesto por los servicios Web prev el uso de directorios pblicos
como respuesta a la proliferacin de servicios. Estos directorios deberan permitir el
registro y bsqueda de los servicios Web disponibles. Precisamente, el protocolo
UDDI (Universal Description Discovery and Integration) se encarga de esta tarea. Este
protocolo proporciona mecanismos para permitir a los proveedores de los servicios
registrar sus servicios. As, los usuarios de los servicios podrn solicitar aqullos que
sean de su inters. En cierto modo, una entrada UDDI es como un registro en las
pginas amarillas. Por su parte, este protocolo tambin se implementa como un
servicio Web y, por tanto, utiliza SOAP como protocolo para el envo de los
mensajes.
La Figura 2-2 muestra la relacin entre los protocolos utilizados en los servicios Web.
2-18
UDDI
WSDL
2. Registrar
3. Buscar
1. Crear
4. SOAP
Cliente Web
Servicio Web
Figura 2-2 Componentes de los servicios Web
Caractersticas del modelo distribuido de los servicios Web

Los servicios Web se basan en un modelo de envo de mensajes en lugar de un
paradigma orientado a objetos, como es el caso de las arquitecturas distribuidas
orientadas a objetos que se analizarn posteriormente. En realidad, a pesar del
nombre de SOAP (Simple Object Access Protocol) este protocolo no trata con objetos. La
naturaleza de los servicios Web, basada en mensajes, convierte a esta arquitectura en
una alternativa especialmente indicada en entornos dbilmente acoplados.
Respecto a la comunicacin entre los usuarios y proveedores de servicios, las
aplicaciones basadas en servicios Web se conectan a otros servicios utilizando los
URLs que implcitamente incluyen la direccin IP del servidor del servicio.
Un inconveniente de los servicios Web, debida a su naturaleza basada en trfico
HTTP, es que no se mantiene estado de conexin ni se permite ningn mecanismo
de persistencia.
Uno de los puntos fuertes de los servicios Web es precisamente el trfico a travs de
cortafuegos. Dado que los servicios Web se envan utilizando como base el
2-19
protocolo http, normalmente no suele haber problemas para que el trfico pueda
atravesar los cortafuegos sin requerir ningn cambio en la configuracin de los
mismos. El trfico sobre HTTP seguro (utilizando SSL, Secure Socket Layer) se
gestiona de igual forma.
Lee, C. y otros (2002) proponen el uso de los servicios Web en sistemas distribuidos
de control en base a sus similitudes con otras arquitecturas distribuidas orientadas a
objetos como CORBA o DCOM. En este caso, se sustituiran las referencias a los
objetos por los URLs de los correspondientes servicios Web. Sin embargo, no
existen servicios estandarizados de seguridad ni de distribucin de eventos como en
el caso de CORBA o DCOM. Por tanto, estos aspectos de seguridad debern ser
tratados de forma propietaria. Existen diversas soluciones propuestas por algunas
empresas aunque todava ninguna ha sido estandarizada.
Ventajas e inconvenientes de los servicios Web
A continuacin se resumen las principales ventajas e inconvenientes de los servicios
Web cuando se aplican a entornos industriales (Lee, C. y otros, 2002).
Por un lado cabe sealar su interoperabilidad. Cualquier servicio Web puede
interactuar con cualquier otro servicio Web. El protocolo SOAP permite que
cualquier servicio pueda ser ofrecido o utilizado independientemente del lenguaje en
que se haya desarrollado.
Adems, los servicios Web cuentan con la ventaja de estar apoyados por un gran
nmero de empresas, incluyendo IBM y Microsoft. Esta caracterstica, junto al hecho
de basarse en tecnologas ampliamente extendidas como HTTP y XML hacen
suponer que ser adoptar por la comunidad de sistemas abiertos.
El hecho de que los servicios Web utilicen HTTP como protocolo de transporte les
proporciona un buen funcionamiento a la hora de trabajar sobre Internet ya que las
infraestructuras actuales, incluyendo la configuracin de los cortafuegos, etc, est
diseada fundamentalmente para el trfico de dicho protocolo.
2-20
Los servicios Web permiten un elevado grado de independencia de lenguajes y

plataformas. Adems, el hecho de estar diseados para que las aplicaciones puedan
intercambiar informacin entre s, les auguran un futuro interesante.
Una de sus principales ventajas es tambin una de sus mayores desventajas: la
carencia de estndares sobre l y por debajo. SOAP puede ser tan simple como los
diseadores de aplicaciones quieran. En un caso puede ser muy complejo y a la vez
muy flexible mientras que en otro caso puede ser muy sencillo y poco flexible.
A pesar de las ventajas anteriormente expuestas los servicios Web presentan varios
inconvenientes:
Se trata de una tecnologa en desarrollo. Actualmente se estn definiendo estndares
especficos para aspectos fundamentales como son la seguridad, etc, sin embargo
hasta la fecha no existen tales. Tambin carecen de los servicios estndares de las
arquitecturas distribuidas: eventos, notificaciones, etc.
Introducen mayor sobrecarga sobre la red que otras arquitecturas. Esto se debe a que
la informacin se transmite en modo texto frente a otras arquitecturas que la envan
en modo binario. Adems, el relleno de los mensajes SOAP requiere aadir
informacin en el esqueleto del mensaje. Por otro lado, el hecho de concentrar todo
el trfico de las aplicaciones a travs de un nico puerto, puede afectar al rendimiento
de los cortafuegos.
El hecho de ser una arquitectura orientada a mensajes que no mantiene el estado de
conexin limita la posibilidad de realizar algunas operaciones como, por ejemplo, la
distribucin de alarmas en entornos de Internet.
A pesar de estos inconvenientes parece posible que en un futuro los servicios Web
puedan colaborar con las arquitecturas distribuidas orientadas a objetos. stas se
utilizaran en entornos fuertemente acoplados (cuando las aplicaciones distribuidas
requieren una elevada interaccin entre los nodos) debido a que permiten una mejor
integracin entre los nodos y proporcionan unos servicios de apoyo ms potentes
(seguridad, distribucin de eventos, etc.), mientras que los servicios Web se utilizaran
para la integracin de aplicaciones en niveles superiores. Adems, los servicios Web
2-21
cuentan con la ventaja de ofrecer una excelente integracin con el protocolo HTTP,
incluso en aquellas aplicaciones distribuidas separadas por cortafuegos.
2.2.4 Protocolos de gestin de red
En redes complejas se hace necesario utilizar herramientas que faciliten la gestin de
las mismas. Estas herramientas, que colaboran en la deteccin y resolucin de
problemas, normalmente se integran en los llamados sistemas de gestin de red. Los
sistemas de gestin de red consideran la totalidad de una red como una arquitectura
unificada. As, se asigna a cada nodo una direccin y una serie de etiquetas. Para
ilustrar el funcionamiento de los sistemas de gestin de red, a continuacin se indican
cules son las operaciones ms relevantes:
Gestin de la configuracin: Se entiende por gestin de la configuracin

aquellas tareas relacionadas con la monitorizacin del estado de la red as
como de las tareas que permiten la organizacin de la misma.
Gestin de fallos: Consiste en detectar, diagnosticar, solucionar e informar

acerca de congestiones, degradacin o fallos en el medio fsico, bien en los
enlaces de datos o bien en las rutas de transmisin de la red.
Gestin del rendimiento: Permite construir estadsticas, histricos, etc.

encaminados a evaluar el rendimiento de la red. Estas operaciones ayudan en
las tareas de configuracin.
Este tipo de sistemas est compuesto por tres elementos fundamentales:
Agentes: Son los elementos activos de gestin de la red. En realidad

cualquier computadora monitorizada por el sistema de gestin de red ser un
agente.
Base de informacin de gestin: El mtodo ms habitual de gestionar una

red se basa en la gestin de informacin acerca de sus recursos. Por tanto, a
cada recurso se le asocia un conjunto de variables que representan los
2-22
diferentes aspectos del mismo a monitorizar. Este conjunto de informacin

recibe el nombre de base de informacin de gestin.
Protocolo de gestin de red: Tambin se hace necesario el uso de

protocolos especficos para este tipo de sistemas. Estos protocolos ofrecern
unas operaciones adecuadas para gestionar las redes.
En realidad, los protocolos de gestin de red no fueron diseados para ser utilizados
en entornos industriales. Sin embargo, como veremos, presentan una serie de
caractersticas que hacen interesante su aplicacin en entornos industriales. De
hecho, existen trabajos que proponen el uso de estos protocolos como mecanismo
sencillo de monitorizacin de plantas industriales.
Existen diversos protocolos de red propietarios que no se analizan en este estudio
porque se consideran fuera de mbito de inters del presente trabajo. El protocolo de
gestin de red ms extendido, sin duda, es SNMP diseado el entorno TCP / IP. El
modelo OSI de ISO tambin propuso su propio protocolo de gestin de red, CMIP,
aunque ste cuenta con escasa aceptacin.
2.2.4.1
SNMP
SNMP (Simple Network Management Protocol, RFC 1157, 1990) es el principal protocolo
de gestin de red empleado en redes de tipo TCP / IP (Stallings, W., 2000). El
principio bsico sobre el que se elabor fue la creacin rpida y eficiente de un
protocolo de gestin simple, que fuera capaz de hacer frente a las necesidades de
monitorizacin y control que pudieran surgir en una red de tipo Internet.
Este protocolo representa los datos de gestin de red en una estructura de rbol
llamada Management Information Base (MIB) en la que cada rama y cada hoja tienen un
indentificador nico llamado Object Identifier (OID). A cada hoja se le asigna un valor.
Los clientes SNMP (gestores) al conectarse a un dispositivo monitorizado que
soporte SNMP (agentes) usan la MIB para obtener informacin acerca de l.
La MIB es una representacin esttica de todos los agentes gestionados. Dado que
SNMP no proporciona mecanismos para descargar la estructura completa de la MIB
2-23
de un agente, la relacin entre los identificadores de la informacin (OIDs) y el

contenido de los mismos necesita ser transferido al gestor utilizando mecanismos que
quedan fuera de SNMP (Normalmente, esto se hace por el administrador del sistema
al configurar los dispositivos).
SNMP se basa en el protocolo UDP sobre IP. Como es bien sabido se trata de un
protocolo no orientado a conexin. Este hecho asegura un funcionamiento bastante
eficiente con escasa sobrecarga. Sin embargo, UDP presenta el inconveniente de que
no garantiza la distribucin de los paquetes, de forma que algunos datos pueden
perderse en la conexin sin que el emisor se percate. SNMP proporciona algunos
mecanismos para gestionar la prdida de estos paquetes aunque toda la lgica para el
reenvo las peticiones no entregadas y la prevencin de ejecuciones duplicadas de
solicitudes debe ser implementada directamente dentro de los gestores y agentes.
Los principales comandos que proporciona SNMP son los siguientes:
GET: Comando con el que un gestor solicita una variable de la MIB de un

agente a partir de su OID. Permite hacer operaciones de lectura de un agente.
SET: Comando que permite que un gestor pueda solicitar a un agente que
modifique un dato de su MIB a partir de su OID. Permite hacer operaciones
de escritura en un OID de un agente.
TRAP: Permite que los agentes informen sin previa solicitud a los gestores
para informarles de que se han dado determinadas condiciones en el agente.
Aunque existe un conjunto de condiciones predefinidas tambin es posible la
definicin de nuevas condiciones. Puede utilizarse para comunicar alarmas.
Tal y como se apunta en Maciel, C. D. y Ritter, C. M. (1998) SNMP puede ser usado
para interconectar dispositivos de plantas industriales. La MIB puede ser utilizada
para representar los datos de proceso controlados por un dispositivo (p.e. un PLC).
Por otra parte, los comandos descritos anteriormente (GET, SET y TRAP) permiten
enviar datos a otros dispositivos.
2-24
Otro ejemplo del uso de SNMP en entornos industriales puede encontrarse en

Kunes, M. y Sauter, T. (2001). En dicho trabajo se propone usar la estructura de
rbol de la MIB para modelar buses de campo. Se propone el uso de gateways que
interaccionen con plantas industriales interconectadas por buses de campo. Estos
gateways almacenan un modelo de la planta representado por una estructura de tipo
MIB. Dado que las operaciones tpicas en los buses de campo consisten en lectura,
escritura y envo de alarmas, los comandos del protocolo SNMP se adecan bastante
bien a estas operaciones.
Ventajas e inconvenientes de SNMP
Este interesante enfoque se adapta razonablemente bien cuando las plantas
controladas son relativamente sencillas, ya que no se permiten operaciones
complejas. Adems el uso del protocolo SNMP cuenta con algunos inconvenientes
que se detallarn a continuacin (Sauter, T. y otros, 2002):
Adaptacin a plantas complejas: El enfoque de SNMP slo permite

operaciones de lectura y escritura de variables, no adaptndose a otras
operaciones ms complejas.
Informacin dinmica: La MIB es una estructura esttica lo que no permite

actualizaciones dinmicas de la estructura de la red.
Seguridad: Otro punto dbil del uso de SNMP en entornos industriales es la

carencia de mecanismos de seguridad. La versin de SNMP utilizada ms
comnmente es la versin 1, la cual no proporciona mecanismos de
seguridad. A pesar de que la versin 3 introduce ciertas mejoras, esta versin
todava no se utiliza de forma generalizada.
Trfico a travs de cortafuegos: Como se ha sealado SNMP se basa en el

protocolo UDP y normalmente no se permite que los datagramas UDP pasen
a travs de los cortafuegos.
2-25
2.2.4.2 CMIP
El protocolo de gestin de red propuesto en el modelo OSI de ISO recibe el
nombre de CMIP (Common Management Information Protocol, ISO 9596; 1998,
http://www.iso.org).
El diseo de CMIP intenta solucionar los errores y fallos que aparecan en SNMP
cuando el tamao y detalle de los gestores de red aumentaba. Su diseo es similar a
SNMP por lo que se usan PDUs (Protocol Data Unit) como variables y para
monitorizar la red.
En CMIP las variables son unas estructuras de datos complejas con muchos
atributos, que incluyen:
Variables de atributos: Representan las caractersticas de las variables.
Variables de comportamiento: Indican qu acciones se pueden realizar.
Notificaciones: Generan un de evento cuando se dan determinadas

circunstancias.
Ventajas e inconvenientes de CMIP

Se trata de un protocolo ms complejo que SNMP que resuelve algunos de sus
inconvenientes:
Mayor capacidad funcional: Permite operaciones ms complejas que

SNMP.
Menor sobrecarga de la red: Al no utilizar el mecanismo de sondeo la

sobrecarga sobre la red es menor.
Mejor comportamiento en el intercambio de grandes cantidades de

datos: Los tipos de datos que se define se adaptan mejor a altos niveles de
trfico.
Mayor seguridad: Proporciona mecanismos de seguridad efectivos.
2-26
Sin embargo, presenta serios inconvenientes:
Escasa implantacin: Se trata de un protocolo escasamente utilizado

debido a que a pesar de que la pirmide OSI siempre se toma como
referencia
en
comunicaciones
frente
al
modelo
de
Internet,
su
implementacin es mnima.
Agentes muy complejos: Requiere agentes muy pesados con gran capacidad
de proceso y recursos elevados de memoria por lo que no parece ser la
opcin ms indicada para equipos sencillos como algunos de los encontrados
en los entornos industriales.
2.3
ARQUITECTURAS DISTRIBUIDAS ORIENTADAS A OBJETOS
Como se coment en el captulo de Introduccin, en los sistemas de control es cada

vez mas frecuente que los algoritmos de control se encuentren distribuidos entre un
nmero determinado de dispositivos formando aplicaciones distribuidas. Este tipo de
aplicaciones se caracteriza porque los componentes software residen en varios nodos
de una red y cooperan entre s. Es en este tipo de aplicaciones donde las arquitecturas
distribuidas orientadas a objetos, cuya caracterstica fundamental es facilitar la labor
de comunicar los diversos objetos distribuidos a travs de la red (que puede ser local
o no), ofrecen un esquema en el que especificar los diversos componentes software
de la aplicacin, junto con unos servicios especialmente indicados para el manejo de
los diferentes objetos distribuidos (Aldrich y otros, 1998; Dollimore, 1997; Guijun y
otros, 1998).
Los objetos distribuidos aportan, por extensin, todas las ventajas tradicionales de las
tecnologas orientadas a objetos en cuanto a flexibilidad, modularidad, reutilizacin
de cdigo, escalabilidad... etc en los sistemas distribuidos.
La introduccin de este tipo de arquitecturas en los sistemas de control aporta una
serie de ventajas aadidas como son:
Las aplicaciones distribuidas independizan la funcionalidad de la aplicacin de

la problemtica de las comunicaciones.
2-27
Permiten construir modelos orientados a objetos de dispositivos fsicos.

Dado que los dispositivos de planta cuentan cada vez con mayor grado de
inteligencia, se hace incluso posible la construccin de componentes que
cuenten con interfaces software orientados a objetos que sean fcilmente
integrables en aplicaciones distribuidas.
Aportan una serie de servicios que facilitan las tareas de desarrollo de

aplicaciones (como pueden ser, por ejemplo, los servicios de nombres,
distribucin de eventos o seguridad).
Ofrecen mecanismos para implementar la tolerancia a fallos (por ejemplo,

duplicando los dispositivos crticos de forma que si stos fallan la red se
reconfigure automticamente para que un segundo dispositivo asuma las
labores del que fall) .
Aunque existen otras arquitecturas distribuidas orientadas a objetos, lo cierto es que

las tres grandes alternativas disponibles son: CORBA, DCOM y Java / RMI. Entre
las tres constituyen la inmensa mayora de los sistemas distribuidos en
funcionamiento. A continuacin se presentar una breve descripcin de cada una de
ellas. Existe abundante bibliografa que compara las caractersticas de estas
tecnologas. Algunos ejemplos son: Pritchard, J. (1999), Orfali, R. y Harkey, D.
(1998), Raj, G. S. (1998), Diskin, D. y Chubin, S. (1998).
2.3.1 CORBA
En esta seccin se presenta una breve descripcin de CORBA (Common Object Request
Broker Architecture). Para ms informacin se puede acudir a Vinosky, S., (1997) o a
Henning, M. y Vinosky, S. (1999) o directamente a la web de el OMG (Object
Management Group, http://www.omg.org).
Object Management Architecture (OMA)
El OMG es la asociacin que promueve el uso de CORBA. Esta asociacin se form
en 1989 con el objetivo de desarrollar, adoptar y promocionar estndares para el
desarrollo e implementacin de aplicaciones distribuidas en entornos heterogneos.
2-28
Desde entonces hasta la actualidad el OMG ha ido creciendo en nmero de socios

hasta convertirse en la actualidad en el mayor consorcio de software del mundo con
ms de 800 miembros (fabricantes de software, integradores de sistemas y usuarios
finales).
Su principal contribucin por el momento ha consistido en ofrecer una arquitectura
marco para el desarrollo de aplicaciones distribuidas orientadas a objetos basada en
unas especificaciones para las interfaces de los objetos utilizados. Esta arquitectura
marco se conoce con el nombre de arquitectura de gestin de objetos (Object
Management Architecture, OMA).
La OMA est compuesta por un modelo de objetos y un modelo de referencia. El
modelo de objetos define cmo se describen los objetos en entornos distribuidos
mientras que el modelo de referencia refleja las interacciones entre dichos objetos.
En el modelo de objetos de OMA, un objeto es una entidad encapsulada cuyos
servicios pueden ser accedidos a travs de interfaces bien definidas. Los clientes
hacen peticiones a estos objetos sobre los que delegan las acciones solicitadas sin
preocuparse ni de la implementacin ni de la localizacin de dichos objetos en el
sistema distribuido de forma que los clientes slo necesitan conocer su interfaz.
Por su parte, el modelo de referencia OMA se encarga de facilitar la comunicacin
entre los clientes y los objetos distribuidos. Para ello se propone el uso de un
intermediario que recibe el nombre de ORB (Object Request Broker). Adems, se
definen cuatro categoras de interfaces de objetos que utilizan el ORB que son las
siguientes (Ver Figura 2-3):
Interfaces de aplicacin: Son las interfaces desarrolladas especficamente

para los objetos distribuidos de una aplicacin determinada. Evidentemente,
al depender estos objetos de la aplicacin no hay ninguna estandarizacin en
este tipo de interfaces.
Servicios comunes de objetos: Son interfaces de objetos que ofrecen

servicios fundamentales frecuentes en diversas aplicaciones. Se encargan de
aumentar y complementar la funcionalidad del ORB. Entre los servicios
2-29
disponibles ms interesantes caben sealar: Notificaciones, Eventos,

Seguridad, Nombres, etc. Dado el inters de estos servicios en el desarrollo
de aplicaciones CORBA se detallarn sus principales caractersticas en un
apartado posterior.
Facilidades comunes: Se trata de un conjunto de servicios que pueden ser

compartidos por muchas aplicaciones, aunque no son tan bsicos como los
Servicios Comunes de Objetos.
Interfaces de dominio: Estas interfaces ofrecen servicios orientados hacia

dominios de aplicacin especficos. Algunos de los dominios disponibles son
las telecomunicaciones, medicina, finanzas, etc.
Interfaces
de
aplicacin
Interfaces
de
dominio
Facilidades
comunes
Object Request Broker (ORB)
Servicios
comunes de
objetos
Figura 2-3 Categoras de interfaces del modelo de referencia de OMA.
Desde sus orgenes, la mayor parte del trabajo realizado por el OMG se ha centrado
en la especificacin del componente central de la arquitectura: el ORB. Esto ha sido
as debido a que el resto de los componentes de la OMA dependen del
funcionamiento del ORB.
Common Object Request Broker Architecture (CORBA)
Una de las primeras especificaciones que fueron adoptadas por el OMG fue la
especificacin CORBA. sta detalla las interfaces y caractersticas del componente
ORB dentro de la arquitectura de la OMA. Hay varias especificaciones de CORBA,
siendo la ltima de ellas la especificacin CORBA 3.0 (OMG, 2004a).
2-30
A grandes rasgos, se puede decir que CORBA es un middleware. Los clientes

simplemente invocan un mtodo de un objeto servidor y no tienen que preocuparse
de la localizacin de dicho objeto, pueden usar el objeto remoto como si estuviese en
el espacio de memoria del cliente.
Implementacin
Objeto CORBA
Cliente
Interfaz de
invocacin
dinmica
Soporte IDL
Cliente
(Stub)
Interfaz
del
ORB
Esqueleto
dinmico IDL
(DSI)
Esqueleto
esttico IDL
(Skeleton)
Adaptador de Objetos
Ncleo del ORB
Figura 2-4 Principales componentes de CORBA
A continuacin se describirn los principales componentes de CORBA (Figura 2-4)

que son los siguientes:
Object Request Broker (ORB)
Constituye el ncleo de la arquitectura CORBA. Se puede decir que es el bus por el
cual se comunican los objetos localizados tanto local como remotamente.
El ORB es el encargado de llevar a cabo la comunicacin entre los objetos
distribuidos. Esto se hace por medio de un intercambio de mensajes entre la
aplicacin que requiere un servicio de un objeto servidor y el objeto que ofrece el
servicio. El papel del ORB consiste en hacer transparente al programador la
comunicacin entre los objetos CORBA.
Entre las principales funciones del ORB se encuentran: localizar el objeto que ofrece
el servicio (servidor), hacer que reciba la llamada correctamente y devolver los
resultados al objeto cliente. Tambin se encarga de las tareas de creacin y activacin
de los objetos servidores.
2-31
Como se puede ver en la Figura 2-4 el ORB no interacta directamente con los
clientes y objetos servidores sino que en el caso de invocacin esttica lo hace a
travs de una serie de interfaces (Stubs y Skeletons) y en el caso de invocacin dinmica
a travs de los correspondientes interfaces dinmicos.
Interface Definition Language (IDL)
Para que los clientes puedan hacer peticiones sobre los objetos distribuidos CORBA
es necesario que conozcan las operaciones que se pueden llevar a cabo sobre dichos
objetos. En el enfoque orientado a interfaces que propone el OMG resulta necesario
el uso de un lenguaje comn de definicin de interfaces que especifique las
operaciones y tipos que los objetos CORBA soportan. Este lenguaje de interfaces
recibe el nombre de Interface Definition Language (IDL).
Hay que resaltar que se trata de un lenguaje puramente declarativo (que no define
detalles de implementacin) cuya sintaxis resulta similar a la de las clases en C++ o
las interfaces de Java. Independientemente de esta definicin los objetos servidores
estarn implementados en sus respectivos lenguajes de programacin (C/C++, Java,
Ada...). As, lo nico que un cliente necesita para invocar un mtodo de un objeto
CORBA es conocer su definicin en trminos del lenguaje IDL. Detalles tales como
el lenguaje de programacin usado, la localizacin fsica del objeto en la red o el
sistema operativo utilizado permanecen transparentes para los clientes.
Para dar una idea de la estructura de IDL a continuacin se muestra el esqueleto IDL
para una interfaz: (Para ms informacin se puede acudir a Henning, M. y Vinosky,
S., 1999).
// Nombre de un mdulo que agrupa varias interfaces
Module <identifier> {
<type declarations>;
<constant declarations>;
<exception declarations>;
2-32
// Nombre de los interfaces IDL

interface <identifier> [:inheritance] {
<type declarations>;
<constant declarations>;
<attribute declarations>;
// Mtodos CORBA
[<op_type>] <identifier>(<parameters>)
[raises exception] [context];
}
Posteriormente, se utilizar un compilador de IDL para precompilar el fichero con la

especificacin IDL. El precompilador generar cdigo fuente, p.e. unas libreras
especficas o unas clases para los lenguajes de programacin de los objetos finales as
como los tipos de datos necesarios. Existen precompiladores de IDL para una gran
multitud de lenguajes de programacin (C, C++, Java, Ada95, ... etc.).
En caso de que los lenguajes de programacin escogidos tanto en la parte servidora
como en la cliente sean diferentes habr que precompilar dos veces. Una vez para el
cliente, con un precompilador especfico para el lenguaje de programacin que se usa
en la parte cliente, y otra vez para la parte servidora, con otro precompilador que
genere cdigo en el lenguaje que est implementado el servidor.
El cdigo fuente generado por los precompiladores se llamar Stub para los clientes y
Skeletons para los servidores. Los Stubs se encargarn de realizar las peticiones
requeridas por los clientes al ORB mientras que los Skeletons entregan las peticiones a
los objetos CORBA.
Nota: Stubs y Skeletons son utilizados nicamente en la invocacin esttica de
CORBA. Dado que en este trabajo slo se pretende hacer una breve introduccin al
funcionamiento de CORBA no se hace referencia a la invocacin dinmica de
CORBA debido a su mayor complejidad.
2-33
Adaptadores de objetos (Object Adapters)

Los adaptadores de objetos son un mecanismo para mantener el ORB tan simple
como sea posible. Este componente de CORBA sirve como enlace entre los objetos
CORBA y el propio ORB.
As, los adaptadores de objetos se encargan de las siguientes tareas:
Registro de los objetos CORBA.
Generacin de las referencias de los objetos CORBA que manejan los

clientes.
Ejecucin de los procesos servidores que activan los objetos CORBA.
Gestin de las peticiones sobre los objetos CORBA por parte de mltiples
clientes remotos evitando posibles interbloqueos.
Atencin de las solicitudes de servicio desde los clientes remotos a los

objetos CORBA.
Los adaptadores de objetos sufrieron una evolucin importante con la aparicin de la

especificacin CORBA 2.2 que introdujo el Portable Object Adapter (POA). El POA
proporciona una adaptador de objetos estndar que se utiliza de igual manera con
ORBs de distintos fabricantes lo que facilita la interoperatividad.
Protocolos de interoperabilidad (IIOP, GIOP, ESIOP)
Los protocolos de interoperatividad definen los tipos de mensajes usados por los
ORBs para intercambiar informacin entre ellos. Un ejemplo de aplicacin de estos
mensajes son los mensajes que se intercambian para actualizar los objetos CORBA
disponibles en la red, las llamadas a los objetos CORBA, la devolucin de los datos
solicitados,... etc. Estos protocolos son, en ltima instancia, quienes permiten
efectuar todas las operaciones solicitadas por los clientes a los objetos CORBA.
2-34
Es importante sealar que no se trata de protocolos propietarios sino que al estar

definidos por el OMG, estos protocolos permiten la interoperabilidad entre ORBs
de diferentes fabricantes siempre que se satisfaga la especificacin CORBA. Por
tanto, resultan un apartado fundamental de la arquitectura OMA.
Los protocolos de interoperabilidad definidos por el momento son:
GIOP (General Inter-ORB Protocol) En realidad GIOP no es un protocolo concreto
que puede usarse directamente para comunicar dos ORBs. Por el contrario, GIOP
describe cmo pueden crearse protocolos especficos que sigan un modelo
propuesto. La especificacin GIOP define lo siguiente:
Unos requisitos para los protocolos de transporte subyacentes (Protocolos

orientados a conexin, conexiones full-duplex, un servicio de trasporte fiable,
etc.)
Una representacin comn en formato binario para los datos

intercambiados entre los distintos ORBs.
Un conjunto de tipos de mensaje bsicos con los que se efectuarn todas las
operaciones CORBA (Peticin de un servicio, respuesta, mensajes de
error...)
IIOP (Internet Inter-ORB Protocol) Se trata de un caso particular del protocolo GIOP.
En el caso de IIOP los protocolos subyacentes utilizados pertenecen a la familia de
protocolos TCP / IP. IIOP es un protocolo obligatorio para cualquier
implementacin CORBA desde la especificacin CORBA 2.0. Es el principal
protocolo usado por los ORB CORBA en la actualidad.
ESIOPs (Environment-Specific Inter-ORB Protocol) Son protocolos que se usan para la
integracin con redes especficas. Hay varias implementaciones. Algunos de estos
protocolos se utilizan en ORBs que tienen misiones crticas. Tambin incluyen
opciones avanzadas como la seguridad Kerberos, directorios globales, tiempo
distribuido etc. Algunas versiones de estos protocolos permiten usar tanto
protocolos orientados a conexin como no orientados a conexin.
2-35
Servicios comunes de objetos

Son servicios que simplifican la construccin de aplicaciones distribuidas. Los
servicios CORBA complementan y aumentan la funcionalidad del ORB. Por ejemplo
el servicio de nombres ayuda a localizar los componentes distribuidos utilizando una
cadena de caracteres en lugar de una referencia numrica (sin sentido para el
programador). Estos servicios de soporte no son estrictamente necesarios. Sin
embargo, en la prctica, unos buenos servicios de soporte marcan una gran diferencia
al desarrollar aplicaciones distribuidas flexibles y extensibles. Aunque estos servicios
estn definidos dentro de la OMA, los productos CORBA de distintos vendedores
no suelen integrar toda la funcionalidad de todos los servicios, sino que se
diferencian en los servicios que ofrecen. ste es, por tanto, uno de los aspectos ms
importantes a tener en cuenta al elegir un ORB especfico.
Cuando se activa un objeto servidor que soporta CORBA, se registran en el ORB los
servicios que ofrece. Si estos servicios son llamados desde algn cliente el ORB pasa
la llamada al servidor que lo tenga registrado. As, por ejemplo, a partir del cdigo
fuente de un objeto CORBA se puede desarrollar un objeto con unas caractersticas
determinadas que definirn su comportamiento en terminos de concurrencia,
persistencia, etc.
Algunos de los servicios ms interesantes soportados son (Sus especificaciones
pueden ser encontradas en http://www.omg.org ):
1. Servicio de ciclo de vida: Define operaciones para crear, copiar, mover y
borrar componentes del bus.
2. Servicio de persistencia: Proporciona una interfaz simple para almacenar
datos de forma persistente en diferentes tipos de servidores de
almacenamiento. Estos datos se suelen almacenar en bases de datos de
objetos orientadas a objetos (ODBMS, Object Database Management Systems),
bases de datos relacionales (RDBMS, Relational Database Management Systems) o
archivos planos.
2-36
3. Servicio de nombres: Permite a los componentes del bus localizar otros

componentes por un nombre en lugar de utilizar directamente las referencias
a objetos, poco representativas para los programadores. El servicio tambin
permite dar de alta entradas a los objetos en directorios de red existentes o
contextos de nombres estandarizados con el objeto de que su bsqueda sea
ms sencilla.
4. Servicio de eventos / notificaciones: La arquitectura CORBA bsica sigue
el modelo cliente / servidor. Es decir, los clientes CORBA solicitan acciones
de los objetos CORBA. Sin embargo, a veces es necesario que sean los
objetos CORBA quienes notifiquen a los clientes la ocurrencia de
determinados eventos. Para resolver estas necesidades el OMG proporciona
los servicios de eventos y notificaciones. En realidad, el servicio de
notificaciones es una mejora respecto al servicio de eventos con el que es
compatible. Ambos servicios se basan en el uso de unos objetos CORBA
bien definidos que reciben el nombre de Canal de Eventos / Notificaciones. As,
los clientes CORBA pueden registrarse dinmicamente para conocer eventos
especficos que tienen lugar en los objetos CORBA.
5. Servicios de seguridad: Se trata de una compleja especificacin en la que se
detalla cmo se debe gestionar la seguridad en CORBA. Proporciona una
estructura para la seguridad de objetos distribuidos. Tambin soporta
autentificacin, acceso a listas de control, confidencialidad y no-repudiacin.
En el apartado de seguridad se har una breve descripcin del servicio de
seguridad de CORBA.
6. Servicio de control de concurrencia: Proporciona un gestor de bloqueos
para efectuar transacciones o ejecutar threads.
7. Servicios de reloj: Proporciona interfaces para sincronizar tiempos en un
entorno de objetos distribuidos. Tambin proporciona operaciones para
definir y gestionar eventos disparados por tiempo.
2-37
CORBA en Tiempo Real

Dado que en principio CORBA no est diseado para trabajar en sistemas de tiempo
real, al implementar CORBA en este tipo de sistemas aparecan algunos problemas.
Los dos problemas principales resultaban ser las limitaciones de memoria de los
sistemas empotrados y las relaciones entre CORBA y los sistemas operativos
multitarea en tiempo real sobre los cuales se ejecutan los sistemas empotrados.
Sin embargo, esta situacin est cambiando. El OMG ha definido nuevas
especificaciones que se adaptan mejor a los sistemas empotrados. Fundamentalmente
stas son:
ORBs ms escalables, de forma que se adecen mejor a entornos con

limitaciones de memoria (Minimum Standard, OMG, 2002b).
Extensiones opcionales a CORBA estndar que permiten sincronizar el

funcionamiento de los ORBs con el de los sistemas operativos de tiempo
real subyacentes. (Real-Time CORBA specification, OMG, 2002c).
Extensiones de CORBA para sistemas de tiempo real

Una de las caractersticas bsicas de los sistemas de tiempo real es que deben exhibir
un comportamiento temporal predecible. Este requisito se traduce en la necesidad de
acotar en el tiempo todas las operaciones realizadas por los componentes del sistema.
Esto es igualmente vlido para el comportamiento de CORBA y, por tanto, se debe
conseguir acotar el tiempo empleado en las invocaciones de los mtodos de los
objetos CORBA. Para conseguir este comportamiento, los recursos del sistema se
han de gestionar de forma eficiente.
Las especificaciones de CORBA en tiempo real (CORBA-RT) se orientan, por tanto,
hacia la consecucin de esta predictibilidad, para que CORBA pueda integrarse en
sistemas de tiempo real. En realidad, esto implica que se deben proporcionar
mecanismos para controlar el uso del procesador, memoria y los recursos de red
(Schmidt, D.C y Kuhns, F., 2000):
2-38
Con respecto al uso del procesador, se asignan prioridades a los objetos

CORBA. Estas prioridades se hacen corresponder con las prioridades de las
tareas / hilos de ejecucin del sistema operativo de tiempo real (Real Time
Operating System, RTOS) subyacente. As, se consigue que el conjunto del
sistema de tiempo real sea planificable.
En cuanto a la memoria, se hace uso del mecanismo llamado threadpool. Este

mecanismo consiste en limitar el nmero de threads usados por un subsistema
CORBA. As se evita la creacin dinmica de threads limitando la cantidad de
memoria utilizada por una aplicacin. Adems, se consigue acotar los tiempos
de ejecucin de los threads. Los threadpools introducen una serie de parmetros
que permiten configurarlos. Por ejemplo, la cantidad de memoria reservada
para las colas de peticiones a los objetos CORBA.
Las aplicaciones distribuidas en tiempo real tambin requieren el uso de

mecanismos de sincronizacin a nivel del ORB. Estos mecanismos, adems,
deben asegurar la consistencia semntica con los mecanismos de
sincronizacin internos de los sistemas operativos de tiempo real
subyacentes.
Tambin se debe asegurar la integracin de los planificadores utilizados

internamente por los sistemas operativos subyacentes (VxWorks, QNX,
Linux-RT, etc.). En esta lnea CORBA-RT define un servicio de planificacin
global. Este servicio es un objeto CORBA que es responsable de asignar los
recursos del sistema para conseguir los requisitos de calidad de servicio
(Quality of Service, QoS) que la aplicacin distribuida necesita. Las aplicaciones
pueden usar el servicio de planificacin en tiempo real para especificar los
requisitos de clculo de sus operaciones en trminos de varios parmetros
como, por ejemplo, el tiempo de ejecucin en peor caso o el periodo de
activacin.
Por ltimo, los recursos de red se controlan permitiendo a la aplicacin

seleccionar y configurar los diversos protocolos de red disponibles y tomar
decisiones acerca del nmero mximo de conexiones que pueden aceptarse.
2-39
Evidentemente, la eleccin de un protocolo de red concreto puede contribuir

de forma determinante a la predictibilidad de las operaciones de red.
CORBA-RT no especifica ningn protocolo de tiempo real, dado que, al
menos de momento, no parece haber un nico protocolo que satisfaga todos
los requisitos de las aplicaciones de tiempo real. Por el contrario, CORBA-RT
proporciona un esqueleto para la seleccin y configuracin de cualquier
protocolo usado en un entorno en particular.
Modelo de componentes CORBA (CCM)
Los miembros del consorcio OMG detectaron la necesidad de que la arquitectura
CORBA contase con un modelo de componentes. Esta necesidad dio lugar a la
propuesta de un modelo de componentes que recibe el nombre de CCM (CORBA
Component Model, OMG, 1999). No obstante, este modelo no ha adquirido cierto peso
hasta que en 2001 fue integrado en la especificacin de CORBA 3.0.
El uso de componentes pretende reducir los tiempos de construccin de nuevas
aplicaciones utilizando un enfoque basado en el ensamblaje de componentes
software binarios en lugar de la reutilizacin de cdigo fuente. Este plantamiento
permite que los programadores utilicen componentes a partir de sus interfaces
desentendindose completamente de su implementacin.
El CCM es posterior a otros modelos de componentes, fundamentalmente el modelo
de componentes de Microsoft, COM+ y el modelo de componentes de Java, EJB.
En comparacin con ellos, CCM es el primer modelo de componentes totalmente
multiplataforma, multilenguaje, multivendedor, etc. Algunas de las principales
caractersticas que el CCM propone son:
Un modelo de componentes abstracto: Este modelo aade nuevas

extensiones al IDL de CORBA y al modelo de objetos.
Un esqueleto para la construccin de los componentes: Este

esqueleto se basa en un lenguaje de definicin de los componentes
(Component Implementation Definition Language, CIDL). Este esqueleto
integra los servicios de CORBA: Seguridad, Eventos, Nombres, etc.
2-40
Un modelo de programacin para el contenedor del componente:

Este modelo permite navegar y visualizar las interfaces de los
componentes a travs de interfaces genricas.
Mecanismos de encapsulacin: Estos mecanismos permiten ocultar el

cdigo incluido en el componente.
Interoperabilidad con los componentes de Java: Dado que en la

actualidad existe un gran nmero de componentes EJBs desarrollados, el
CCM permite interoperar con estos componentes.
Metamodelos para las interfaces de componentes: Utilizan modelos

XML para describir los componentes.
CORBA en entornos industriales

Varios autores proponen el uso de CORBA para la construccin de aplicaciones
distribuidas en entornos industriales. Sanz, R. y Alonso, M. (2001) analizan las
caractersticas de CORBA para ser aplicada a entornos industriales y concluyen que
en la actualidad es la arquitectura distribuida que mejor se adapta a las caractersticas
de dichos entornos, fundamentalmente debido a su robustez, su buen
comportamiento en aplicaciones que requieren tolerancia a fallos y a la existencia de
especificaciones dirigidas a los sistemas empotrados (CORBA minimum) y con
requisitos de tiempo real (CORBA-RT).
Otros autores (Guyonet, G. y otros, 1997; Seinturier L y otros, 1999), han mapeado los
servicios MMS de MAP en CORBA para obtener servicios de nivel de planta en
entornos de fabricacin que permitiesen la colaboracin de dispositivos industriales.
Ariza, T. (2000) analiza la integracin de dispositivos de fabricacin en sistemas de
gestin basados en CORBA. El modelo propuesto tambin utiliza los servicios MMS
como base para esta integracin.
Otro sector donde la arquitectura CORBA tambin ha sido propuesta es en el campo
de las subestaciones elctricas. As, en Sanz, R. y otros (2002) se sugiere el mapeo en
CORBA de los objetos definidos en el estndar IEC 61850.
2-41
Tambin se pueden encontrar en la bibliografa trabajos que utilizan CORBA para

acceder a dispositivos especficos. Por ejemplo, Marn, R. y Sanz, P.J. (2002)
proponen el uso de CORBA para teleoperar un robot a travs de la Web y SangHoon, K. y otros (2002) presentan una arquitectura para acceder a un control
numrico a travs de un servidor Web. Estos trabajos permiten monitorizacin,
simulacin y control remoto. Sin embargo, estas soluciones no resuelven las
necesidades de las plantas complejas formadas por varios dispositivos.
Ventajas e inconvenientes de CORBA
En primer lugar CORBA es una arquitectura diseada desde sus orgenes para
facilitar la construccin de aplicaciones distribuidas. Se puede decir que es una
arquitectura inherentemente distribuida resultado de un esfuerzo de estandarizacin
importante que ha permitido que sea apoyada por un gran nmero de fabricantes y
soportada para un gran nmero de plataformas (hay incluso diversos productos
CORBA
ofertados
como
software
libre,
ver
http://www.omg.org
/technology/corba/corbadownloads.htm). Como resultado se ha obtenido una

arquitectura muy madura, potente y fiable. Gracias a estas caractersticas, en la
actualidad CORBA es la arquitectura distribuida orientada a objetos ms empleada
cuando se necesita construir sistemas complejos.
Adems, cuenta con otras ventajas como son la excelente integracin de CORBA
con Java as como unos excelentes servicios de apoyo: Nombres, Eventos /
Notificaciones, Seguridad, etc. Tambin existen especificaciones orientadas a sectores
particulares que pueden ser de gran inters en los entornos industriales como son las
especificaciones CORBA-RT y CORBA minimum (orientada a permitir la
construccin de sistemas empotrados lo ms ligeros posible).
CORBA tambin cuenta con un modelo de componentes, CCM. Aunque este
modelo es relativamente nuevo y es menos maduro que los de sus competidores,
fundamentalmente COM+ y EJB, se prev que su uso se extienda en un futuro.
Por otra parte, aunque precisamente una de las mayores ventajas de CORBA es que
es el resultado de un gran esfuerzo de estandarizacin en el que se han visto
involucrados diversos fabricantes, paradjicamente es tambin una de sus principales
2-42
debilidades ya que el desarrollo de nuevas especificaciones debe ser consensuado

entre los fabricantes implicados. Este hecho ralentiza la evolucin de CORBA y
adems hace que las nuevas especificaciones tiendan a ser conservadoras. Otro de
los inconvenientes de CORBA radica en su complejidad, ya que dominar
completamente CORBA requiere un esfuerzo importante.
2.3.2 COM / DCOM / COM+
DCOM es la arquitectura distribuida orientada a objetos propuesta por Microsoft
(Microsoft Corporation, 1996, Box, D., 1998; Lwy, J. 2001). DCOM es el acrnimo
de Distributed Component Object Model y es una evolucin de COM (Component Object
Model) en la que se han introducido mecanismos para facilitar la construccin de
aplicaciones distribuidas.
A grandes rasgos su funcionamiento y objetivos son similares a los de la arquitectura
CORBA, sin embargo, hay ciertas diferencias que comentaremos a continuacin.
Orgenes
Mientras que la arquitectura CORBA fue diseada desde sus orgenes para ser un
estndar que permitiese la llamada a mtodos de objetos distribuidos en una red, no
sucede lo mismo con DCOM. Los orgenes de DCOM hay que buscarlos en OLE
1.0 (Object Linking and Embedding) que era un estndar para el intercambio de
informacin entre aplicaciones de Windows. OLE permita que la aplicacin
contenedora de un objeto incrustado lo cediera a la aplicacin con la que fue
creado para que sta lo manipulase. De esta forma las aplicaciones podan
intercambiar datos.
Esta funcionalidad se ampli an ms con COM. La idea fundamental era que para
permitir una comunicacin eficiente entre aplicaciones sera til una aproximacin
orientada a componentes cercana al sistema operativo. Lo que pretende COM es ser
un protocolo de comunicacin e integracin de componentes genrico, unificado y
extensible. En l se basan actualmente OLE 2.0, ActiveX y los controles OCX.
2-43
Posteriormente se desarroll DCOM que es una extensin de COM para trabajar con
objetos distribuidos. Ms adelante cambi el nombre de la tecnologa COM /
DCOM por COM+ (Lwy, J. 2001) de forma que integrase una serie de servicios
(transacciones, concurrencia, seguridad, gestin de colas, eventos,...) que
anteriormente funcionaban por separado como Microsoft Transaction Service (MTS) o
Microsoft Queuing Service (MSMQ). Sin embargo, se trata de la misma tecnologa en
todos los casos.
Estructura y funcionamiento de COM / DCOM
Es interesante resaltar que el enfoque de COM / DCOM no es exactamente
orientado a objetos sino orientado a componentes. El trmino orientacin a
componentes lleva asociadas diferentes prioridades que el trmino orientacin a
objetos. As, mientras que en la orientacin a objetos se hace especial hincapi en la
herencia, encapsulacin y reutilizacin de objetos dentro del cdigo de nuevas
aplicaciones, la orientacin a componentes se centra en la instalacin y uso de
componentes binarios que son insertados en las aplicaciones que los usan.
Por consiguiente, las propiedades de los componentes COM son distintas de los
objetos CORBA. Por ejemplo, COM no proporciona herencia autntica sino que usa
un modelo de reutilizacin de los objetos antiguos incorporndolos dentro de los
nuevos.
Los componentes llevan la encapsulacin a un nivel mximo al exponer slo una
interfaz pblica. El cdigo fuente de un componente es totalmente desconocido para
las aplicaciones que lo usan. De forma que, aspectos, como el lenguaje de
programacin o la localizacin fsica del componente, permanecen desconocidos
para el cliente.
Este enfoque permite que los componentes tengan su propia independencia de
forma que desde el punto de vista externo el beneficio radique en que cualquier
componente pueda ser insertado en un conjunto diverso de aplicaciones cliente.
En una situacin ideal dos componentes distintos que soporten la misma interfaz
podran ser intercambiados. La principal prioridad en este caso es la insercin de
2-44
componentes intercambiables en aplicaciones mientras que la reutilizacin de cdigo

permanece como una propiedad de menor prioridad.
COM es la arquitectura basada en componentes ms utilizada en la actualidad. Ello
no es sorprendente dado que COM es la arquitectura de componentes utilizada
dentro de Microsoft Windows, el sistema operativo ms extendido. Por otra parte,
conviene no olvidar que COM est enfocado a resolver los problemas de
comunicacin dentro de un sistema operativo de usuario en el que se puedan integrar
fcilmente diversas aplicaciones de oficina. Ello requiere un entorno de
funcionamiento optimizado que permita a las aplicaciones utilizar los componentes
COM instalados. A continuacin se muestran cules son los principales mecanismos
que permiten esta integracin.
Tipos de servidores
COM soporta los siguientes tres tipos de servidores para implementar componentes:
Servidor interno: Un servidor interno se implementa como una librera

dinmica (DLL) que se ejecuta dentro del mismo espacio de proceso que la
aplicacin. El efecto en el rendimiento de la aplicacin es mnimo porque un
servidor interno se localiza dentro del mismo proceso que el cliente. Estos
servidores se conocen comnmente como controles ActiveX. Son muy
rpidos pero no permiten ningn tipo de transporte como en CORBA. Estn
ms orientados al intercambio de informacin entre aplicaciones dentro de
una misma mquina.
Servidor local: Un servidor local se ejecuta en un proceso separado en el

mismo ordenador. La comunicacin entre una aplicacin y un servidor local
se consigue por el sistema de ejecucin de COM utilizando un protocolo de
comunicacin entre procesos de alta velocidad interno al sistema operativo.
En este caso la sobrecarga es un orden de magnitud mayor que cuando se usa
un servidor interno.
Servidor remoto: Un servidor remoto se ejecuta en un computador remoto.

DCOM extiende COM proporcionando una infraestructura basada en RPC
2-45
que se usa para gestionar la comunicacin entre la aplicacin y el servidor

remoto. Comparando la sobrecarga con la de un servidor local en este caso
sta es un orden de magnitud mayor que en el caso del servidor local. No
obstante, ste es el nico caso en el que se puede hablar de verdaderos
sistemas distribuidos.
COM IDL
Lo que s comparten CORBA y COM es la filosofa de separacin entre el cdigo
binario y las interfaces de acceso a l. Se puede afirmar que un objeto COM es la
suma de una interfaz y cdigo binario. Al igual que en CORBA, en COM tambin
existe un lenguaje de definicin de interfaces que en COM tambin recibe el nombre
de IDL. Sin embargo, aunque el IDL de COM tiene ciertas similitudes con el
lenguaje IDL de CORBA no es compatible con l.
Los diseadores de los componentes COM pueden describir sus interfaces, mtodos
y propiedades haciendo uso del IDL. Las aplicaciones cliente utilizan la definicin del
IDL del componente COM en lugar de detalles especficos de la implementacin.
Este mtodo permite usar ms de una interfaz para un objeto binario (o clase COM)
que podran aislar aspectos particulares del objeto binario. Es decir, las interfaces
IDL no tienen por qu describir la totalidad del componente.
Como consecuencia, se pueden crear interfaces con funciones genricas para usarlas
luego en mltiples objetos COM diferentes que implementan los mtodos
especificados de su manera particular, consiguiendo polimorfismo en cierto modo.
Cliente COM
Servidor COM
Proxy (*.DLL)
Stub (*.DLL)
RPC
COM / DCOM
COM / DCOM
Figura 2-5 Capas de comunicacin en COM / DCOM
Al igual que en CORBA se definen ciertas interfaces que permiten el acceso a los
objetos (que reciben el nombre de Stubs y Skeletons) en DCOM se definen unas
interfaces equivalentes que en este caso reciben los nombres de Proxies y Stubs. En la
2-46
arquitectura DCOM los Proxies y Stubs son empaquetados en sendas libreras

dinmicas (Dynamic Link Library, DLL) que a su vez se registran en el registro de
Windows. As, el sistema de ejecucin de COM busca entonces en el registro para
encontrar las correspondientes libreras Stub y Skeleton asociadas a las interfaces
utilizados. La Figura 2-5 ilustra este comportamiento.
Identificacin de interfaces y objetos en COM/DCOM
En el servidor
Para que los clientes puedan utilizar las interfaces COM es necesario introducir algn
mecanismo que permita identificar las interfaces registradas en el servidor. Para
eliminar posibles colisiones de nombres al disear las interfaces COM se les asigna
un nombre binario nico. Este nombre binario se denomina GUID (Globally Unique
Identifier). Los GUIDs son unos identificadores de 128 bits generados con una
funcin de la API (Application Program Interface) de COM. El mecanismo utilizado para
la generacin de los GUID hace que la posibilidad de generar dos identificadores
iguales sea prcticamente nula. Una vez definida la interfaz, el nombre asignado no se
puede modificar a posteriori.
Para que una aplicacin pueda utilizar un componente COM es necesario haber
registrado su GUID. En este caso se genera un CLSID (Class Identifier) que permitir
a la aplicacin utilizar el componente COM. El CLSID se aade junto con el objeto
(servidor) COM correspondiente en el registro de Windows bajo la categora de
HKEY_CLASSES_ROOT.
En el cliente
En el cliente se accede a los objetos COM mediante unas funciones de la API de
COM que permiten obtener referencias a objetos COM precisamente a partir de los
GUIDs. Con el CLSID un cliente puede crear una instancia de un objeto COM y
obtener un puntero a la interfaz predefinida.
2-47
Servicios de DCOM
El hecho de que COM sea una arquitectura de componentes madura tiene sus
ventajas. As, miles de componentes ya han sido desarrollados y pueden ser utilizados
para crear nuevas aplicaciones. Adems, existen diversas herramientas que aceleran el
desarrollo de nuevos componentes y aplicaciones basadas en componentes ya
existentes.
De forma similar a CORBA, Microsoft tambin proporciona servicios avanzados
tales como el Microsoft Transaction Service (MTS) o el Microsoft Queuing Service (MSMQ)
que facilitan la creacin de aplicaciones complejas con COM. Estos servicios han
sido integrados junto a DCOM en la plataforma COM+ donde, entre otros, reciben
los nombres de servicios de transacciones, concurrencia, seguridad o eventos.
Concretamente, MTS gestiona el entorno de ejecucin de COM. Adems de iniciar y
sealar la finalizacin de transacciones colabora en otros aspectos importantes en
sistemas distribuidos como son la seguridad, gestin de recursos y la monitorizacin
de los sistemas. En COM+ este servicio ha sido dividido entre los servicios de
seguridad, concurrencia y control de transacciones.
Por su parte, MSMQ proporciona un servicio de mensajera en COM. Su
funcionalidad es equivalente al servicio de Eventos de CORBA. Este servicio
resuelve las necesidades de comunicacin de forma asncrona desde los servidores
hacia los clientes. COM+ introduce mejoras con el denominado servicio de eventos
al proporcionar un servicio de mensajera ms potente y sencillo de manejar. El
modelo propuesto en COM+ es ms cercano al servicio de notificaciones de
CORBA. Se basa en el modelo publicista / subscriptor de forma que los
subscriptores que quieran recibir eventos se registran en un objeto comn que est
encargado de distribuir los eventos recibidos desde el publicista.
Puentes CORBA-DCOM
Una vez que se han analizado las caractersticas de COM y CORBA, las dos
arquitecturas distribuidas ms extendidas, se puede observar que tanto una como la
otra proporcionan distintas ventajas, lo que las convierte en ms idneas en un
2-48
entorno u otro. Es por ello que resulta interesante utilizar puentes que permitan la
interoperatibilidad entre CORBA y DCOM. En sistemas pequeos se pueden utilizar
soluciones diseadas ad hoc sin embargo, en sistemas grandes es conveniente el uso
de soluciones comerciales.
En la especificacin de CORBA 2.2 se puede encontrar una descripcin detallada de
los mecanismos que se han propuesto para conseguir la interoperatibilidad entre las
arquitecturas CORBA y DCOM.
DCOM en entornos industriales
As como CORBA es directamente utilizado en entornos industriales, DCOM suele
ser usado de forma indirecta, fundamentalmente a travs de los componentes OPC o
Profinet. En Blanco, P.M. y otros (2003) es posible encontrar una comparativa entre
diversos fabricantes de sistemas de control de la produccin (Manufacturing Execution
Systems, MES). Algunos de estos fabricantes tambin ofrecen paquetes SCADA. En el
estudio se concluye cmo en los paquetes comerciales analizados se usan
mayormente los objetos DCOM / OPC frente a CORBA. Esta preeminencia de
COM en soluciones cerradas se justifica sobre todo debido a la excelente integracin
de DCOM en entornos Windows. Sin embargo, CORBA parece ms adecuado en
aquellos casos que hay que construir aplicaciones distribuidas abiertas o en aquellos
casos en los que estn involucradas diferentes plataformas.
Ventajas e inconvenientes de DCOM
La principal ventaja de COM / DCOM es su excelente integracin con la gama de
sistemas operativos Microsoft Windows, que no hay que olvidar que son los ms
extendidos en la actualidad. Por otra parte, esta excelente integracin con los
entornos Windows se basa en soluciones especficas que no son vlidas para otras
plataformas, por lo que tambin es su principal debilidad.
Por otra parte, COM es la arquitectura basada en componentes ms madura en la
actualidad. Esto junto a la excelente integracin con soluciones Windows ha
convertido a esta arquitectura en la ms popular a nivel comercial, dado que muchas
soluciones de los fabricantes se basan en entornos Windows. Este hecho se ha
2-49
traducido en que sea adoptada como ncleo de estndares industriales como OPC o
Profinet (evaluados ms adelante), lo que le otorga una ventaja adicional.
Brevemente, OPC es un estndar de comunicacin, basado en componentes DCOM
que proporciona una serie de servicios bsicos tpicamente utilizados en plantas
industriales. OPC est adquiriendo gran relevancia en la industria. Por su parte
Profinet es una arquitectura que pretende integrar en redes de tipo Ethernet diversos
dispositivos industriales.
Sin embargo, DCOM presenta varias debilidades para ser considerada una solucin
ideal. La mayora de stas limitaciones vienen dadas precisamente por la naturaleza de
tecnologa propietaria de DCOM. Por un lado, las limitaciones en el nmero de
plataformas en las que esta tecnologa est disponible. Microsoft no ha mostrado
signos de proporcionar servicios como MTS o MSMQ en plataformas distintas de
Windows. Adems, el uso de COM con Java requiere el uso de la mquina virtual de
Microsoft, no soportada en otras plataformas. Por ltimo, estratgicamente, el hecho
de depender de un nico fabricante puede ser tambin un inconveniente adicional.
Adems, no existen especificaciones de DCOM que permitan el desarrollo de
sistemas distribuidos con unas caractersticas de tiempo real (como s sucede con
CORBA-RT) con lo que su uso no resulta adecuado en aquellos sistemas que
presenten tales requisitos.
2.3.3 Java / RMI
La tercera arquitectura distribuida orientada a objetos en liza es Java / RMI (Sun
Microsystems; Grosso W., 2001; Rusty, E., 1997). Como su nombre indica, esta
arquitectura est ntimamente ligada al lenguaje de programacin Java. Esta
arquitectura se integra en la plataforma J2EE y se beneficia de todas las herramientas
que esta plataforma ofrece: servicios de objetos (eventos, seguridad, transacciones,
etc.), modelo de componentes EJBs (Enterprise Java Beans), integracin con la
tecnologa Web, etc. A pesar de que Java est popularizndose cada vez ms, el
hecho de que esta arquitectura quede limitada nicamente a este lenguaje limita en
cierto modo su rango de aplicacin, ya que no siempre es posible emplear dicho
lenguaje. Esta afirmacin es an ms cierta en entornos industriales.
2-50
Al igual que CORBA, RMI (Remote Method Invocation) fue diseada desde el principio
para soportar llamadas a mtodos de objetos remotos. RMI integra directamente un
modelo distribuido orientado a objetos con la mquina virtual Java (JVM, Java Virtual
Machine) desde el kit de desarrollo JDK 1.1 (Java Developer Kit).
Un objeto RMI es un objeto codificado en Java cuyos mtodos son llamados desde
otra mquina virtual Java que puede localizarse dentro del mismo computador o en
una red de ordenadores. Los clientes pueden invocar mtodos de los objetos remotos
RMI como si se tratara de objetos Java locales a la mquina virtual.
En el caso de Java / RMI es la propia mquina virtual de Java quien se encarga de
tareas como la activacin de los objetos o la localizacin de los objetos dentro de una
red.
Las aplicaciones distribuidas basadas en Java / RMI permiten:
Localizacin de los objetos remotos: Las aplicaciones pueden escoger

entre dos mecanismos para obtener las referencias de los objetos remotos:
Una aplicacin puede registrar los objetos remotos que publica a travs del
servicio de nombres que RMI propone: el registro rmi. Adems, la aplicacin
puede utilizar referencias a objetos remotos como parte de su operacin
normal.
Comunicacin con los objetos remotos: RMI gestiona la comunicacin

con los objetos remotos de forma transparente para el programador y desde
su punto de vista se ejecutan como si fuesen llamadas normales a objetos
situados en su propio espacio de memoria.
Serializacin de los objetos: RMI permite enviar objetos entre distintas

mquinas virtuales Java a travs de cierto mecanismo que recibe el nombre de
serializacin y que consiste en convertir un objeto en un flujo de datos para
que el cdigo del objeto est disponible en la mquina virtual destino.
Al igual que sucede en las dems arquitecturas remotas, los clientes RMI interactan
con los objetos remotos a travs de unas interfaces que stos publican. Sin embargo,
2-51
en la arquitectura Java / RMI no es necesario utilizar un lenguaje de definicin de

interfaces propio de la arquitectura, como era el IDL (en CORBA y DCOM). En el
caso de Java / RMI se definen las interfaces en lenguaje Java extendiendo la interfaz
java.rmi.Remote. Una vez definidos estos interfaces se compilan con el compilador de
interfaces de Java / RMI obtenindose los interfaces utilizados en el cliente (Stubs) y
en el servidor (Skeletons). Posteriormente, el cdigo generado a partir de las interfaces
Java / RMI se integra en el cdigo cliente y servidor. Previamente a utilizar los
objetos remotos es necesario aadir las correspondientes entradas en el registro rmi
que hace las veces de servidor de nombres hacia los clientes.
La Figura 2-6 ilustra el funcionamiento de una aplicacin distribuida basada en RMI
que usa el registro para obtener referencias a los objetos remotos. El servidor utiliza
el registro para asociar un nombre con un objeto que pone a disposicin de las
aplicaciones remotas. El cliente busca el objeto remoto por su nombre en el registro
del servidor y una vez que encuentra una referencia llama a los mtodos del objeto
rmi registrado. En aras de independizar el cdigo implementado en los clientes
tambin se muestra cmo se pueden usar servidores Web para descargar el cdigo de
los objetos (en bytecodes) de las correspondientes clases cliente.
RMI
Cliente
registro rmi
RMI
RMI
Servidor
Protocolo HTTP
Protocolo HTTP
Servidor Web
Figura 2-6 Uso del registro para obtener referencias a objetos remotos.
La tendencia de RMI es a converger con CORBA. Esta convergencia est teniendo

lugar fundamentalmente en dos direcciones:
2-52
RMI sobre IIOP: JavaSoft (La empresa propietaria de Java), est

desarrollando una versin de RMI que funciona con el protocolo IIOP, lo
que permite la interoperatibilidad con CORBA. Adems, este enfoque
permite que la arquitectura Java / RMI aproveche algunas de las principales
caractersticas de este protocolo.
RMI / IDL: Por otro lado se est trabajando en permitir a los

programadores Java especificar interfaces CORBA a travs de la semntica de
RMI en lugar del IDL de CORBA.
Servicios Java
Nombres
Al igual que en otras arquitecturas distribuidas resulta conveniente un servicio que
permita obtener referencias a objetos sin tener que utilizarlas explcitamente en el
cdigo. En el caso de Java / RMI, el servicio de Nombres es implementado por el
registro RMI.
Seguridad
Es evidente que una de las preocupaciones de una aplicacin distribuida es la
consecucin de un entorno de ejecucin seguro. As, puede ser necesario el uso de
canales seguros entre los clientes y servidores. RMI proporciona factoras de sockets
de diversos tipos, incluyendo sockets encriptados. A partir del JDK 1.2 se pueden
especificar requisitos para los servicios proporcionados por los sockets del servidor.
Por otra parte, la seguridad tambin debe afectar a las clases descargadas. Para
solucionar este problema se utiliza un gestor de seguridad (RMISecurityManager) que
se encarga de habilitar todas aquellas operaciones que puedan ser sensibles como la
descarga de clases de otros nodos distribuidos, la apertura / escritura de ficheros, la
gestin de las conexiones de red, etc. Como parte de la configuracin de seguridad
tambin resulta necesario configurar correctamente las polticas de seguridad de la
JVM para permitir ejecutar las correspondientes acciones.
2-53
Trfico a travs de cortafuegos

RMI introduce mecanismos que permiten a los clientes comunicarse con los
servidores remotos situados detrs de cortafuegos. Entre otros mecanismos, los
cortafuegos bloquean todo el trfico de red salvo aqul que pasa a travs de
determinados puertos controlados. Dado que la capa de transporte de RMI abre
dinmicamente conexiones a travs de sockets para establecer las comunicaciones
entre clientes y servidores, el trfico generado normalmente resulta bloqueado por la
mayora de cortafuegos. Afortunadamente los diseadores de RMI se anticiparon a
este problema y proporcionaron una solucin en la propia capa de transporte de
RMI. Esta solucin se basa en la encapsulacin del trfico RMI en mensajes HTTP
POST para atravesar los cortafuegos. A grandes rasgos el proceso es el siguiente:
cuando se intenta establecer una conexin a travs de un cortafuegos, el cliente
intenta abrir una conexin con el objeto servidor. Este intento de conexin es
bloqueado por el cortafuegos y entonces, la capa de transporte de RMI vuelve a
intentar la llamada en este caso encapsulada como una peticin HTTP POST. En
realidad, la aplicacin establece una conexin con un objeto proxy que es en realidad
quien encapsula la peticin, que es enviada a travs de Internet (ver Figura 2-7).
Servidor
proxy
Servidor
Web
WWW
Cliente
RMI
Servidor
RMI
Cortafuegos
Cliente
Cortafuegos
Servidor
Figura 2-7 Trfico RMI enmascarado con el protocolo HTTP
Eventos
Java cuenta con un servicio de mensajes: Java Message Service (JMS). Se trata de un
servicio de mensajera que permite que los componentes de una aplicacin basados
en la plataforma Java 2 (J2EE, Java 2 Enterprise Edition) puedan crear, enviar, recibir y
2-54
leer mensajes. Permite el establecimiento de enlaces de comunicacin de forma ligera,

fiable y asncrona en entornos distribuidos acoplados.
Java en entornos industriales
Algunos autores han propuesto arquitecturas que utilizan Java / RMI. As, por
ejemplo, Mart, P. y otros, (1999) proponen el uso de un modelo de planta sobre una
estructura de tipo rbol en la que sus hojas contienen informacin acerca de la planta
bajo control. Estos datos se ofrecen a las aplicaciones remotas en una arquitectura
basada en Java / RMI, de forma que los clientes solicitan informacin acerca de los
datos de proceso. Este enfoque resulta adecuado para ser utilizada con plantas
industriales relativamente sencillas. Sin embargo, las operaciones posibles se limitan a
la lectura y escritura de variables. Los sistemas de control modernos requieren una
funcionalidad ms compleja que incluya otras operaciones de configuracin,
monitorizacin, etc.
Ventajas e inconvenientes de Java / RMI
Java / RMI se beneficia de las interesantes ventajas que Java aporta al mundo de los
sistemas distribuidos. Por ejemplo, el entorno de ejecucin de Java / RMI cuenta con
caractersticas muy interesantes como son la capacidad de enviar objetos (serializacin)
a travs de una red o la perfecta integracin de los objetos remotos en las mquinas
virtuales Java.
El comportamiento de esta arquitectura, y sobre todo, una buena integracin con los
navegadores y servidores Web la convierten en una opcin muy interesante para ser
utilizada en entornos tipo Internet.
Sin embargo, la plataforma Java / RMI exige que todo el desarrollo de los objetos
distribuidos se lleve a cabo en este lenguaje, lo cual no siempre es posible, sobre todo
en entornos industriales. Esto dificulta la integracin de sistemas ya existentes en
esquemas distribuidos. Por otra parte, comparando con otras arquitecturas
distribuidas el rendimiento de esta arquitectura es pobre lo que no la hace idnea en
aplicaciones que requieran un alto rendimiento.
2-55
2.3.4 Integracin de arquitecturas distribuidas en navegadores Web

En las aplicaciones basadas en navegadores Web, los objetos distribuidos pueden ser
utilizados de formas distintas. En algunos casos, el acceso a los objetos distribuidos
estar restringido a la parte servidora. En otros casos, los objetos distribuidos sern
utilizados directamente por las aplicaciones cliente basadas en navegadores. Estos
dos mtodos se ilustran en Figura 2-8 y Figura 2-9 :
El primer caso, mostrado en la Figura 2-8, ilustra una aplicacin ejecutndose sobre
un navegador Web que no interacciona con ningn objeto distribuido. Toda la
interaccin entre el cliente y el servidor tiene lugar a travs del servidor Web va
HTTP. En este caso, el servidor Web es el nico que tiene acceso a los objetos
distribuidos cuando procesa las solicitudes HTTP. Dada la naturaleza de los objetos
distribuidos el servidor Web puede llamar a objetos distribuidos en una red lo que
presentara posibilidades interesantes en el campo del control.
Parte
Cliente
Parte
Servidor
Escenario 1
HTTP
Servidor
Web
Objeto
Distribuido 1
Navegador
Web
Aplicacin
sobre el
navegador
Objeto
Distribuido 2
Figura 2-8 Acceso exclusivo desde el servidor a los objetos distribuidos
Por su parte, el segundo caso, Figura 2-9, ilustra una aplicacin cliente que se ejecuta
sobre un navegador Web que interacciona directamente con los objetos distribuidos.
En este caso el navegador Web primero descarga una aplicacin cliente ejecutable
sobre un navegador (p.e. un applet Java) al navegador. Luego la aplicacin cliente en
ejecucin utiliza directamente los objetos distribuidos.
Cada estrategia tiene sus ventajas e inconvenientes. El primer caso proporciona un
acceso limitado a los objetos distribuidos. As se aumenta la seguridad al ser el
servidor Web el nico punto de entrada desde los clientes. Adems, las aplicaciones
2-56
clientes son ms sencillas dado que no requieren acceso directo a los objetos
distribuidos, resultando ms sencillas de desarrollar y mantener. Sin embargo, este
enfoque est ms limitado en cuanto a posibilidades y prestaciones. Todas las
operaciones se hacen va trfico HTTP con lo que se sobrecarga de forma
importante el servidor Web.
Adems, este primer enfoque requiere que los servidores Web ejecuten pginas
activas (ASP, Active Server Pages, si se utiliza tecnologa de Microsoft, y por tanto
utilizadas con objetos DCOM o JSP Java Server Pages, si se utiliza tecnologa Java,
compatible con las arquitecturas distribuidas Java / RMI y CORBA) que en ltima
instancia realizan la llamada al objeto distribuido sobre el que se desea hacer la
peticin Web.
Por su parte, el segundo enfoque es extremadamente potente. Sin embargo, presenta
ciertos inconvenientes. Se requiere que la aplicacin cliente presente una
infraestructura completa de objetos distribuidos.
Parte
Cliente
Parte
Servidor
Escenario 2
HTTP
Servidor
Web
Navegador
Web
Aplicacin
sobre el
navegador
Objeto
Distribuido 1
Objeto
Distribuido 2
Figura 2-9 Acceso directo desde la aplicacin cliente a los objetos

distribuidos.
En este escenario tambin se pueden utilizar tanto objetos distribuidos CORBA o

Java como DCOM. Sin embargo, parece ms adecuado el uso de objetos CORBA o
Java por los siguientes motivos:
2-57
Respecto al lenguaje de programacin utilizado en la plataforma cliente

Java es la mejor eleccin. Esto es en parte debido a que Java presenta una
excelente integracin con los navegadores Web. De hecho, la mayora de
los navegadores Web traen alguna mquina virtual Java incorporada, o
permiten su instalacin.
La integracin entre CORBA y Java tambin es muy buena. Utilizando la

arquitectura CORBA para las comunicaciones y Java como lenguaje de
programacin en el cliente se consiguen todas las ventajas de utilizar Java
en el cliente y, adems, se cuenta con la flexibilidad que introduce
CORBA (independencia del lenguaje en el servidor, etc).
En el caso de usar objetos DCOM el sistema operativo debe pertenecer a

la familia Windows para soportar DCOM en su totalidad. Sin embargo, si
se utiliza CORBA, o directamente Java, el cdigo se ejecuta directamente
sobre la mquina virtual Java, independizando la ejecucin del sistema
operativo subyacente.
El nodo que soporta la aplicacin cliente debe ser configurado para

soportar el uso de objetos DCOM. Esta configuracin resulta
relativamente farragosa. Por ejemplo, deben registrarse las clases DCOM.
El modelo de seguridad debe ser configurado correctamente tanto en el

servidor como en el cliente. Por su parte, cuando se utiliza CORBA y
Java la seguridad slo viene limitada por el modelo de seguridad de Java.
Este modelo puede ser configurado en el caso de applets fiables.
2.4
ESTNDARES BASADOS EN ARQUITECTURAS DISTRIBUIDAS
En este apartado se presentan, a modo de ejemplo, algunos interesantes estndares

que se han desarrollado para ser utilizados en control de procesos sobre las
arquitecturas distribuidas.
2-58
2.4.1 OPC
OPC (OLE for Process Control, www.opcfoundation.org; Iwanitz, F. y Lange, J., 2002)
pretende sacar partido de la generalizacin de los PCs de sobremesa (debido, una
vez ms, al abaratamiento de sus precios y aumento de prestaciones) en entornos
industriales donde suelen cooperar con los tradicionales PLCs.
OPC juega un papel importante en la integracin, tanto vertical como horizontal, de
soluciones de automatizacin entre componentes distribuidos. Esta tecnologa
introduce interfaces estndares y formatos de datos consistentes que proporcionan
datos del nivel de campo a otros niveles de produccin o incluso a otros nodos en el
mismo nivel de produccin.
La adopcin de estas interfaces por un gran nmero de fabricantes facilita la
construccin de aplicaciones distribuidas en base a componentes OPC. Estos
componentes introducen gran eficiencia y reduccin de costes debido a la
reutilizacin de cdigo binario.
En definitiva, hoy en da OPC es uno de los estndares industriales ms populares
entre usuarios y desarrolladores. As, gran parte de los fabricantes de interfaces HMI
(Human Machine Interface), paquetes SCADA (Supervisory Control and Data Acquisition) y
sistemas DCS (Distributed Control Systems) en el campo de la tecnologa de
automatizacin basada en PC ofrecen con sus productos interfaces OPC. Esto es
igualmente cierto para los fabricantes de dispositivos y tarjetas. La Figura 2-10
muestra un ejemplo en el que se utiliza OPC para intercambiar datos de proceso
entre diferentes tipos de nodos en una red de empresa.
A da de hoy, OPC es una interfaz estndar para acceder a aplicaciones basadas en
sistemas operativos Windows (Windows 9X/ME/NT/2000/XP). De hecho, OPC
se basa en la tecnologa DCOM de Microsoft lo cual, de momento, limita su rango de
aplicacin aunque ltimamente hay grupos interesados en exportar la tecnologa
haciendo uso de los servicios Web.
Gran parte del xito de OPC se debe a que, en la actualidad, no existe otra alternativa
similar. CORBA y Java / RMI son alternativas directas a DCOM pero no existe
2-59
ninguna otra tecnologa basada en ellas que ofrezca interfaces y formatos de datos
estndar que hayan sido adoptados por la industria.
OPC tambin permite la programacin de aplicaciones cliente en entornos de
programacin como Visual Basic, Delphi, etc. bastante asequibles para usuarios no
avanzados. Estas aplicaciones cliente utilizarn los datos ofrecidos por los
componentes OPC. Por su parte, la situacin ms habitual es que estos componentes
sean escritos en C o C++ por programadores expertos buscando el mejor
rendimiento posible.
Figura 2-10 OPC en entornos de computacin heterogneos
Orgenes de OPC
A medida que el nmero de productos y protocolos de comunicacin y sistemas de
buses iba creciendo, los fabricantes de software se enfrentaron al problema de que
tenan que dedicar mayores recursos para desarrollar y mantener la enorme cantidad
de drivers existente.
2-60
En 1995, algunas compaas, incluyendo a la mayora de las grandes compaas del

sector (Fisher-Rosemount, Intellution, Rockwell, Siemens AG, etc....) decidieron
colaborar para conseguir una solucin a este problema y formaron la OPC Task Force.
Tambin formaron parte de este consorcio miembros de Microsoft encargados de
proporcionar soporte tcnico.
La OPC Task Force emprendi la tarea de desarrollar un estndar que permitiese
obtener datos de proceso bajo sistemas operativos Windows, basado en la tecnologa
DCOM de Microsoft. Para Agosto de 1996 ya estaba disponible la primera versin:
OPC Specification Version 1.0. A partir del consorcio anterior se form en Septiembre
de 1996 la OPC Foundation encargada desde entonces de los trabajos de coordinacin
de las especificaciones, elaboracin de nuevos requisitos, marketing, etc.
Especificaciones OPC
Desde entonces se han ido elaborando especificaciones que se centran en
determinados aspectos de las comunicaciones industriales. En la Tabla 2-1 pueden
verse las principales especificaciones as como su estado a fecha de Marzo de 2002.
Estas especificaciones estn disponibles en http://www.opcfoundation.org:
Especificacin
OPC Overview
Descripcin
Versin
Descripcin general de los campos de aplicacin de 1.00
las especificaciones OPC
Common Definicin de conceptos generales relativos al resto 1.00
and de especificaciones
OPC
Definition
Interfaces
OPC Data Access
Specification
OPC Alarms and
Events Specification
OPC Historical Data
Access Specification
OPC
Batch
Specification
Definicin de un interfaz para la lectura y escritura

de datos de proceso
Definicin de un interfaz para la monitorizacin de
eventos
Definicin de un interfaz para acceder a datos
histricos
Definicin de un interfaz para acceder a datos
requeridos para el proceso por lotes. Esta
especificacin extiende la OPC Data Access
Specification
OPC
Security Definicin de un interfaz para la implantacin y uso
de polticas de seguridad
Specification
Integracin de OPC y XML para la construccin de
OPC and XML
aplicaciones Web
OPC Data eXchange Comunicacin en proceso entre distintos servidores
(DX)
OPC
Command Definicin de un interfaz para enviar comandos y
supervisar su ejecucin
Execution Interface
Tabla 2-1 Especificaciones OPC a fecha de Marzo 2002.
2.05
1.02
1.1
2.0
1.0
Draft 0.60
En
construccin
Draft 0.10
2-61
A continuacin se describen las especificaciones ms utilizadas.

Las dos primeras especificaciones ofrecen una visin general de OPC, su mbito,
campos de aplicacin, as como los conceptos bsicos que se utilizarn en el resto de
las especificaciones.
OPC DataAccess
Esta especificacin define la estructura de los servidores de datos de proceso de
OPC. A grandes rasgos estos servidores estn compuestos por objetos de tres
categoras: servidores, grupos e items.
Estos objetos estn organizados de forma jerrquica. As, el objeto servidor acta
como contenedor para objetos del tipo grupo. Por su parte, los objetos de tipo grupo
contienen un grupo de items OPC.
Los grupos OPC proporcionan una forma para que los clientes puedan disponer de
los datos de proceso de forma organizada. Estos datos pueden ser tanto ledos como
escritos. Queda en manos de los clientes especificar la frecuencia de refresco a la que
quieren recibir los datos de los servidores.
Los items OPC representan conexiones a las fuentes de datos originados en el servidor
OPC. Los clientes no pueden acceder directamente a los items OPC sino que deben
hacerlo a travs de los grupos OPC.
OPC Alarm and Event Handling
Esta especificacin define interfaces que proporcionan mecanismos para que los
clientes OPC reciban notificaciones cuando tengan lugar determinados eventos o se
cumplan ciertas condiciones de alarma. Tambin proporciona servicios que permiten
a los clientes OPC obtener los eventos y condiciones soportadas por los servidores
OPC as como obtener su estado en todo momento.
En la especificacin se distingue entre alarmas y eventos. Las alarmas se disparan
cuando se cumplen unas condiciones determinadas. En la nomenclatura de OPC una
2-62
condicin es un estado del servidor de eventos OPC identificado por un nombre, que
resulta de inters a los clientes. Por ejemplo, cuando una variable supera un valor
determinado se puede generar una alarma: HighAlarm.
Por el contrario, los eventos son sucesos significativos para el servidor OPC, el
dispositivo fsico que representa y los clientes OPC asociados. Los eventos pueden
estar asociados, o no, a condiciones especficas. Ejemplos de eventos seran: las
transiciones entre estados de servidor, cambios en la configuracin del sistema,
acciones del operador, o errores de sistema. Los clientes pueden suscribirse a
determinados eventos para que les sean notificados.
OPC Historical Data Access
En entornos industriales la consulta de histricos suele ser una fuente aadida de
informacin. En la actualidad la mayora de los sistemas de almacenamiento de datos
histricos utilizan sus propias interfaces propietarias para la distribucin de los datos
entre los clientes interesados. No existen alternativas para aumentar o usar soluciones
ya existentes.
A la hora de integrar datos en todos los niveles de la pirmide de automatizacin, la
informacin contenida en los histricos puede considerarse como otro tipo de datos.
La especificacin propone varios tipos de servidores de histricos. Los ms
interesantes son:
Servidores simples de datos (Simple Trend Data Servers): Estos servidores

proporcionan poco ms que almacenamiento de datos al natural. Es decir, en
el mismo formato que son obtenidos del servidor de datos OPC.
Servidores para anlisis con compresin de datos (Complex Data

Compression and Analysis Servers): Estos servidores proporcionan compresin
de datos adems del almacenamiento de datos al natural. Son capaces de
proporcionar funciones ms elaboradas enfocadas al anlisis de los datos,
tales como valores promedio, mximos, mnimos, etc. Tambin soportan
actualizaciones de los datos e historia de las actualizaciones.
2-63
Ventajas e inconvenientes de OPC

El principal beneficio de esta tecnologa radica en que los fabricantes de servidores y
clientes OPC no estn limitados por la funcionalidad de sus componentes OPC
(siempre que se adopten las correspondientes definiciones para los interfaces). Por el
contrario, los componentes OPC de diversos fabricantes pueden cooperar en tareas
comunes. No es necesario ningn esfuerzo adicional de programacin para poner en
marcha una aplicacin distribuida. Este esquema de funcionamiento permite incluso
eliminar las dependencias entre los componentes software y hardware, debido al uso
de interfaces abstractas. As, por ejemplo, es posible sustituir dispositivos completos
(cambiando el hardware y el componente software asociado) sin afectar de forma
importante a la aplicacin distribuida.
El uso de OPC tambin proporciona otras ventajas para los diferentes agentes
involucrados en el desarrollo de aplicaciones distribuidas de automatizacin:
Fabricantes de hardware
Los productos pueden ser usados por todos los sistemas compatibles con OPC del
mercado no quedando limitados a un sistema especfico para el que se ha
desarrollado un driver especfico. Adems, debido a la existencia de una interfaz
estandarizada y a la interoperabilidad que introducen estas interfaces no es necesario
familiarizarse con los requisitos especficos de otros sistemas.
El intervalo de desarrollo hasta poner un producto en el mercado (Time to market)
para nuevas generaciones de productos se reduce de forma considerable. Adems,
slo es necesario mantener un nico servidor OPC con lo que se reducen
considerablemente los esfuerzos de mantenimiento.
Fabricantes de software
El producto desarrollado puede usarse con todos los dispositivos y protocolos de
comunicaciones existentes en el mercado para los que OPC est disponible. As, los
fabricantes de software no tienen que desarrollar soluciones especficas. Por el
2-64
contrario, pueden utilizar interfaces estandarizadas no siendo necesario familiarizarse

con especificaciones de protocolos de comunicacin propietarios.
Como resultado, tambin se reducen los tiempos de mantenimiento para los
fabricantes de software al reducirse el nmero de productos mantenidos.
Integradores de sistemas
Se benefician de una mayor flexibilidad en la eleccin de los productos integrados en
las aplicaciones distribuidas.
Por otra parte, tambin en este caso el tiempo necesitado para la integracin y
formacin se reduce considerablemente. Dado que OPC proporciona una interfaz
estndar para todos los productos, no resulta necesario utilizar protocolos
propietarios para cada dispositivo.
Usuarios finales
OPC proporciona mayor flexibilidad (distribucin de componentes, uso de nuevas
tecnologas, eleccin entre productos, etc) durante el diseo de los sistemas al poder
combinar productos de diversos fabricantes.
Por otra parte, la gran variedad de productos disponible en el mercado debera dar
lugar a una notable reduccin de costes con una mayor calidad y facilidad de uso para
los usuarios finales.
Adems, la adopcin de estndares en el sector protege las inversiones en
equipamiento de los usuarios finales evitando que los equipos queden obsoletos y sin
mantenimiento.
Inconvenientes
Respecto a los inconvenientes de OPC, no hay que olvidar que, de momento, a pesar
de que se est trabajando en una especificacin sobre XML, OPC permanece
2-65
ntimamente ligado a DCOM y por tanto comparte la mayora de los inconvenientes

de ste.
As, caben sealar, la dependencia de la plataforma (de momento, OPC slo est
disponible para plataformas Windows), o su comportamiento en sistemas de tiempo
real, donde el comportamiento de DCOM no es el adecuado.
2.4.2 Profinet
En este apartado se presenta Profinet (http://www.profibus.org; Schneider, K.,
2003). Profinet es un ejemplo de cmo las redes de tipo Ethernet pueden ser usadas
como medio fsico para las comunicaciones en el nivel de planta. Profinet introduce
protocolos sobre Ethernet que facilitan la creacin de sistemas de control
distribuidos. Adems, esta tecnologa presenta conceptos innovadores con respecto a
tecnologas anteriormente utilizadas que le auguran un futuro interesante, a pesar de
que en el momento actual todava est en fase de desarrollo.
Componentes Profinet
Profinet proporciona un gran nivel de modularidad permitiendo distribuir la
inteligencia entre los nodos de una red: Los sistemas mecnicos, elctricos y los
programas de control que persiguen una funcionalidad especfica se agrupan en
mdulos autnomos descritos por sus correspondientes interfaces. Como resultado
se obtienen componentes optimizados por separado que pueden ser combinados
para crear un sistema de control distribuido que acte sobre una planta compleja
simplemente conectndolos entre s.
Un aspecto clave de los componentes Profinet radica en las interfaces que los
componentes proporcionan a su vez a otros componentes. A travs de estas
interfaces se permite que otros componentes puedan acceder a aquellas variables que
necesitan para interactuar con los dems componentes. En la fase de diseo de las
aplicaciones, las comunicaciones entre los componentes se definen precisando las
conexiones entre las interfaces de los componentes Profinet.
2-66
Profinet utiliza DCOM para las comunicaciones bsicas entre los componentes.
Como se vio en el anlisis de arquitecturas distribuidas, DCOM es la extensin de la
tecnologa COM para aplicaciones distribuidas. DCOM utiliza los protocolos TCP /
IP. Adems, el hecho de que tanto Profinet como OPC se fundamenten en DCOM
hace que ambas tecnologas puedan colaborar permitiendo una sencilla y potente
integracin de la informacin de proceso con las capas superiores de la pirmide de
automatizacin.
Profinet define un modelo de referencia ejecutable que es implementado en los
dispositivos Profinet. Este modelo fue desarrollado para ser independiente del
sistema operativo, permitiendo la incorporacin de este ncleo ejecutable en una
gran variedad de controladores y sistemas. Por tanto, no resulta necesario el uso de
un sistema operativo basado en plataformas Windows. As, se consigue que PLCs u
otros dispositivos puedan actuar como componentes Profinet.
Protocolos de comunicacin
El uso de Ethernet en sistemas industriales presenta algunos inconvenientes como
son la ausencia de protocolos estandarizados que ofrezcan los servicios que las
aplicaciones de control necesitan. Aqu se encuentra, precisamente, una de las
principales aportaciones de Profinet.
La transmisin de datos entre los componentes es controlada por eventos, es decir,
los datos se envan slo cuando han tenido lugar cambios de forma que se reduce la
transferencia de datos al mnimo y se optimiza la disponibilidad de la red. Uno de los
inconvenientes de Ethernet reside en la imposibilidad de definir un tiempo lmite de
espera (timeout) para que los datos sean entregados. Por ello, en el modelo de
referencia ejecutable que propone Profinet cooperan tres tipos de comunicacin en
funcin del tipo de datos a transmitir:
1. TCP / IP se usa cuando es necesario enviar grandes cantidades de datos (p. e.
descarga de programas)
2-67
2. UDP / IP se usa cuando se transmiten datos de longitud pequea en sistemas

con requisitos de tiempo real acrticos (p.e. la transmisin de datos de
entradas y salidas)
3. Protocolos de comunicacin optimizados, propios de Profinet, que
proporcionan requisitos de tiempo real crtico. Estos requisitos son
negociados entre los dispositivos involucrados antes de establecer la
conexin.
Diseo de aplicaciones con Profinet
En cuanto al diseo de aplicaciones con componentes de Profinet incluye tres fases:
1. Creacin de componentes: Los constructores de los sistemas de
automatizacin crean los componentes como una imagen de los dispositivos
subyacentes. Este proceso implica la programacin de los dispositivos de
igual forma que se haca anteriormente. As, el software creado por los
usuarios se encapsula con las correspondientes herramientas como
componentes Profinet. Automticamente, se crea una descripcin del
componente en forma de un archivo XML.
2. Interconexin de los componentes: Utilizando un editor grfico especfico
(Profinet connection editor) se seleccionan de una biblioteca de componentes los
componentes Profinet disponibles y se interconectan entre s. Las conexiones
reemplazan la programacin de las comunicaciones entre los dispositivos.
3. Descarga de los datos de conexin: Una vez que se han especificado las
conexiones entre los componentes en el editor de conexiones de Profinet, los
datos de conexin y el cdigo as como los datos de configuracin de los
componentes se descargan sobre los dispositivos Profinet. De esta forma
cada dispositivo reconoce al resto de los dispositivos con los que debe
dialogar permitiendo la ejecucin de la aplicacin distribuida.
2-68
Integracin de buses de campo con Profinet

Uno de los problemas a los que Profinet debe dar solucin es la colaboracin entre
los buses de campo y las redes Ethernet. No hay que olvidar que para que un sistema
nuevo tenga xito es muy conveniente que proteja las inversiones previas en
equipamiento por parte de los usuarios finales.
Profinet permite la integracin de buses de campo, Figura 2-11, fundamentalmente
Profibus, de dos formas distintas:
Integracin de buses de campo a travs de proxies: Cada dispositivo es

representado por un componente Profinet. Las comunicaciones con otros
componentes se definen con el editor de conexiones de Profinet. Estos
dispositivos se conectan a un proxy hardware que representa todos los
dispositivos de campo del bus conectados a l. El proxy crea un modelo
entendible por otros dispositivos Profinet de todos los dispositivos
subyacentes.
Integracin de aplicaciones que se ejecutan sobre el bus de campo:

Otra opcin que permite Profinet es la representacin de todo un segmento
de bus de campo por un nico componente Profinet. En este caso, el
componente Profinet se conecta a la red Ethernet y representa la
funcionalidad global del conjunto de dispositivos incluidos.
Figura 2-11 Integracin de buses de campo con Profinet
2.5
2-69
SEGURIDAD EN REDES INTERNET / INTRANET
Hay que tener en cuenta que la informacin interna de una empresa es confidencial
por lo que la seguridad juega un papel fundamental en el acceso remoto a plantas
industriales. En Internet hoy en da existen tcnicas que proporcionan un esquema
relativamente seguro. En este apartado se hace una breve revisin de las mismas. Ms
informacin puede encontrarse en Weaver, A. C., (1999), Jaworski, J. y Perrone P.J.
(2000) o Bobadilla, J. (1999).
Las redes TCP / IP no introducen por defecto mecanismos de seguridad. Por tanto,
para obtener un esquema seguro es necesario aadir dichos mecanismos en los
protocolos del nivel de aplicacin. A continuacin se detallan qu caractersticas
deben satisfacerse para proporcionar un acceso seguro:
Autenticacin: Consiste en determinar la verdadera identidad de los usuarios

implicados.
Privacidad: Se suele conseguir encriptando los datos con diversos algoritmos

de cifrado para impedir que usuarios no autorizados puedan acceder a su
contenido.
Integridad de los datos: Consiste en asegurar que los datos no han sido
modificados durante su envo. Esto suele garantizarse con cdigos calculados
a partir de los mensajes enviados que garantizan la integridad de la
informacin enviada. Estos cdigos reciben el nombre de boletines de
mensajes o message digests.
Autorizacin de usuarios: Antes de que un servidor ejecute la tarea

solicitada se debe asegurar que el cliente est autorizado para hacer semejante
tarea. Esta caracterstica va asociada con la no-repudiacin. Este trmino hace
referencia a la necesidad de que una vez que se ha tomado una accin sobre
el sistema bajo control el usuario remoto no pueda denegar con posterioridad
que l fue quien tom una decisin determinada.
2-70
La autorizacin suele ser el aspecto ms difcil de administrar en un esquema

seguro. Gran parte de su dificultad reside en la criticidad de su naturaleza ya
que un error en la autorizacin de usuarios puede ocasionar que algunos
usuarios lleven a cabo operaciones para las que no estn autorizados
pudiendo ocasionar graves consecuencias.
2.5.1 Cortafuegos
Uno de los mecanismos bsicos, ms extendidos para proporcionar un nivel mnimo
de seguridad son los cortafuegos. Se entiende por cortafuegos aquellos sistemas o
conjunto combinado de sistemas de software especializado que crean una barrera
segura entre dos redes. Los cortafuegos permiten a los administradores de la red
concentrar todo el trfico de entrada a un sistema de control a travs de un punto
de choque que se vigilar con la intencin de evitar el acceso a las redes desde
equipos no autorizados o el uso de servicios no permitidos.
Los controles tpicos que suelen introducir los cortafuegos suelen ser:
Filtrado de paquetes
Filtrado de las direcciones origen y destino
Filtrado del trfico dirigido a unos puertos determinados y a los servicios

asociados.
Tambin suelen permitir mediante la incorporacin de mdulos externos el anlisis

del contenido de los paquetes enviados con ciertos protocolos, posibilitando, por
ejemplo, detectar virus en los mensajes antes de ser almacenados en el servidor de
correo. Los protocolos ms frecuentemente protegidos son los siguientes: HTTP,
FTP, Telnet,... etc.
Los cortafuegos son, por tanto, un elemento habitualmente encontrado en las redes
de tipo Internet y son necesarios para mantener un nivel de seguridad mnimo
independientemente de otras medidas que puedan tomarse.
2-71
Evidentemente, cuando los servidores y las aplicaciones cliente usan arquitecturas

distribuidas orientadas a objetos resulta necesario habilitar trfico a travs de los
cortafuegos del protocolo involucrado (IIOP, RMI,...) Dado que es habitual que los
cortafuegos limiten todo el trfico a su travs a los puertos utilizados por los
protocolos HTTP (pginas Web) y SMTP (correo electrnico) puede ser necesario
encapsular el trfico generado por las aplicaciones distribuidas (protocolos IIOP o
RMI) a travs de HTTP.
2.5.2 Nociones bsicas de criptografa
Los sistemas de cifrado consisten en mtodos para alterar mensajes de forma que
slo personas que conozcan esa alteracin puedan conocer el mensaje de origen. El
mensaje original se denomina texto en claro mientras que una vez encriptado recibe el
nombre de texto cifrado. Para conseguir el paso del mensaje en claro al mensaje
encriptado se usa una clave.
Emisor
Receptor
Texto en claro
Texto en claro
Algoritmo
Cifrado
Texto cifrado
Clave K
Clave K
Mensaje
cifrado
Algoritmo
Descifrado
Texto cifrado
Figura 2-12 Envo de un mensaje cifrado a travs de una red
Supongamos que se desea enviar un mensaje a travs de una red. Para ello se seguir
el esquema de la Figura 2-12. El emisor del mensaje utilizar una clave para encriptar
el mensaje con un algoritmo determinado y se enviar el mensaje al receptor quien lo
descifrar con la clave correspondiente para obtener el mensaje original.
Todos los mecanismos utilizados para introducir seguridad en redes informticas de
tipo Internet se basan en ltima instancia, en algoritmos criptogrficos. A
2-72
continuacin se proporciona una descripcin de los algoritmos criptogrficos ms

habituales.
Algoritmos simtricos
Los algoritmos simtricos son los algoritmos ms clsicos. Estos algoritmos se
caracterizan porque las dos partes implicadas en la comunicacin comparten una
clave secreta nica. La informacin en claro se cifra con la clave secreta por medio de
algn algoritmo de cifrado y se enva a la otra parte, que al recibirla recompone el
mensaje con la clave que ya conoce, obteniendo la informacin en claro.
En trminos computacionales este sistema es rpido y eficaz. Existen diversos
algoritmos muy robustos para realizar este tipo de encriptacin. El grado de
proteccin viene determinado por la longitud de la clave. No obstante, a medida que
aumenta la longitud de las claves tambin aumentan las operaciones de clculo
ralentizando considerablemente los procesos de cifrado y descifrado. Por tanto, es
necesario encontrar un compromiso entre el nivel de seguridad requerido y un
rendimiento aceptable.
Los algoritmos de clave simtrica ms populares son:
DES (Introducido por IBM en 1976) y sus variaciones, p.e. Triple DES, etc.
RC2, RC4, RC5, etc. Se trata de diversos algoritmos propuestos por Ronald
Rivest, una de las figuras clave de la criptografa. Dado que estos algoritmos
son mucho ms rpidos que DES cuentan con gran aceptacin en entornos
Web.
A pesar de la popularidad de estos algoritmos, su mayor inconveniente radica en la

dificultad de obtener un canal seguro con el que intercambiar las claves. Aqu es
donde pueden ayudar los llamados algoritmos asimtricos.
Algoritmos asimtricos (o de clave pblica)
En contraste con la criptografa simtrica, la criptografa asimtrica (o de clave
privada y clave pblica) es relativamente reciente. Diffie y Hellman en 1976 fueron
2-73
los primeros en plantear el concepto de criptografa de clave pblica. En 1978 se

propuso el algoritmo de clave pblica ms famoso, el llamado RSA, en honor a sus
creadores: Rivest, Shamir y Adelman.
En contraste con la criptografa simtrica, que utiliza la misma clave en el emisor y el
receptor, la criptografa de clave pblica se basa en la utilizacin de dos claves, K y K.
La particularidad de este conjunto de algoritmos de cifrado radica en la relacin entre
ambas claves. Ambas claves estn relacionadas por funciones matemticas cuyo valor
directo es fcilmente calculable, pero que cumplen la condicin de que la funcin
matemtica inversa es muy difcil de obtener. En la prctica, dada una clave de
encriptacin K es tcnicamente imposible calcular la clave de desencriptacin K.
De las dos claves utilizadas, una de las claves la guarda el usuario mantenindola en
secreto (clave privada) mientras que la otra se distribuye libremente (clave pblica).
Este tipo de algoritmos permite publicar a un usuario su clave pblica para que otros
usuarios puedan encriptar mensajes con la clave pblica de forma que slo el primer
usuario, que es el nico que conoce la clave privada, pueda descifrarlos. El
funcionamiento tambin puede ser a la inversa.
Estos algoritmos son ms seguros que los algoritmos de clave simtrica. No obstante,
el proceso para encriptar un mensaje con un algoritmo de clave pblica es
computacionalmente mucho ms pesado que la encriptacin con un sistema de clave
simtrica. Por ello, lo habitual es la encriptacin de datos con algn algoritmo de
clave simtrica utilizando un algoritmo de clave pblica para encriptar las claves
simtricas utilizadas.
Seguridad en funcin del tamao de las claves.
Como ya se ha indicado con anterioridad, un parmetro clave en los algoritmos de
cifrado es la longitud de las claves. As, para dar una idea acerca de qu nivel de
seguridad aportan estas tcnicas a continuacin se presentan los tiempos necesarios
para encontrar la clave utilizada en la transmisin de un mensaje (Weaver, A. C.
1999).
2-74
En el caso de criptografa simtrica, y asumiendo que se utiliza hardware

especializado, los tiempos necesarios son:
Longitud de la clave
Tiempo para encontrar la clave
40 bits
0.2 segundos
56 bits (DES)
3.6 horas
64 bits
38 das
80 bits
7,000 aos
112 bits (3-DES)
1013 aos
128 bits
1018 aos
Igualmente en el caso de la criptografa de clave pblica:

Longitud de la clave
Tiempo para encontrar la clave
512 bits
30,000 MIPS-aos
768 bits
200,000,000 MIPS-aos
1,024 bits
1011 MIPS-aos
2,048 bits
1020 MIPS-aos
Se utilizan unidades MIPS (millones de instrucciones por segundo) dado que los
tiempos pueden ser reducidos cuando se utilizan varias CPUs trabajando en paralelo.
Como dato de referencia, en el momento en que se escribi este estudio (Weaver, A.
C. 1999) los PCs estaban en el rango de 50 a 100 MIPS.
De las tablas anteriores se puede concluir que para claves simtricas a partir de 80
bits y pblicas de ms de 786 se obtiene un nivel de seguridad aceptable.
Evidentemente, a medida que aumenta la capacidad de clculo de los ordenadores
tambin resulta conveniente aumentar la longitud de las claves.
Boletines de mensajes
Los boletines de mensajes se utilizan para generar resmenes de mensajes y crear
firmas digitales. Se basan en algoritmos que utilizan una funcin hash que realiza una
computacin tal que al pasarle un mensaje de tamao variable, sta siempre genera
una cadena de longitud fija llamada resumen. La funcin es unidireccional, muy difcil
2-75
o imposible de invertir. Adems, estas funciones generan resmenes muy dispares para
mensajes parecidos.
Cuando alguien enva un mensaje le incorpora un resumen generado por una funcin
de boletines de mensajes, de forma que el receptor pueda verificar que el mensaje no
ha sido alterado al realizar el mismo proceso y comprobando la igualdad del resumen
con el resumen por l obtenido. De esta forma se puede asegurar que los mensajes
enviados no han sido alterados durante su envo.
Los algoritmos ms utilizados son: MD2 (RFC 1319, 1992), MD4 (RFC 1320, 1992)
y MD5 (RFC 1320, 1992), de las que la ms utilizada en Internet es MD5. Otra
funcin bastante utilizada es SHA, adoptada por el gobierno americano.
Firmas digitales
Los boletines de mensajes proporcionan un mecanismo excelente para averiguar si
un mensaje u otro objeto ha sido alterado deliberadamente o accidentalmente. Sin
embargo, deben usarse junto a mecanismos que aseguren que un mensaje ha sido
realmente creado por quien dice serlo. Para ello se utilizan las firmas digitales.
Las firmas digitales suelen usar algoritmos de encriptacin de clave pblica utilizando
la clave privada para la encriptacin de la firma y la clave pblica para el descifrado
de la misma. En otras palabras, una firma digital es un valor (clave pblica) que se
calcula a partir de una secuencia de bytes (clave secreta). La firma digital indica que la
persona que mantiene la clave secreta ha verificado que el contenido del mensaje es
correcto y autntico.
Un ejemplo de algoritmo de firma digital es el DSA (Digital Signature Algorithm).
Certificados y autoridades de certificacin
Las firmas digitales ofrecen un mtodo bastante robusto para autentificar que una
persona o empresa en concreto ha revisado o creado un mensaje u objeto. Sin
embargo, presentan un punto dbil: Es necesario conocer si la clave pblica que
utiliza el firmante es, de hecho, la clave del firmante. Es aqu donde entran los
certificados y las autoridades de certificacin.
2-76
Los certificados digitales son mensajes firmados por una autoridad de certificacin
que certifica el valor de la clave pblica de una entidad. Una autoridad de
certificacin es una entidad en la que se confa para verificar que otras entidades son
quienes dicen ser y que utilizan un determinado algoritmo de encriptacin de clave
pblica. Evidentemente, las empresas que quieren ser certificadas debern adjuntar
documentacin a la autoridad certificadora para demostrar que son quienes dicen ser.
Una de estas autoridades de certificacin de las ms conocidas es Verising, Inc.
Los certificados X.509 de la ISO (International Standard Organization) son un formato
de certificado digital muy popular. Estos certificados contienen, entre otra
informacin, lo siguiente: nombre y clave pblica de la entidad, un intervalo de
fechas en las que el certificado es vlido y la firma digital creada por la autoridad de
certificacin.
2.5.3 Protocolo SSL (Secure Sockets Layer)
SSL (Secure Socket Layer) es un nivel de protocolo de comunicacin creado por
Netscape. La versin actual es la versin 3 que se encuentra en:
http://home.netscape.com/eng/ssl3/index.html
Una de sus caractersticas ms interesantes es que la mayora de los navegadores
actuales (Netscape, Internet Explorer, Opera...) soportan SSL 3.0. Adems, sirve
como base para obtener un nivel de seguridad aceptable en muchas aplicaciones.
SSL se basa en la pila de protocolos TCP / IP. Proporciona servicios seguros sobre
TCP / IP que incluyen confidencialidad, encriptacin de datos, integridad y una
autenticidad y no-repudiacin opcional. Aunque funciona sobre TCP / IP, tambin
puede ser la base de otros protocolos que funcionan sobre TCP / IP como HTTP o
IIOP.
La Figura 2-13 muestra el funcionamiento bsico de SSL que se describe a
continuacin. El cliente enva un mensaje de inicio de conexin al servidor quien
acepta la conexin enviando a su vez una clave pblica certificada por una autoridad
de certificacin. Con el envo de la clave pblica certificada se autentifica a s mismo
2-77
y permite que el cliente pueda utilizar la clave pblica para cifrar con ella una clave
secreta que enva al servidor de forma segura y, por tanto, a partir de ese instante la
comunicacin entre ambos se cifrar con la clave secreta del cliente antes
intercambiada. El servidor puede requerir opcionalmente que el cliente le enve un
certificado para asegurar su identidad.
Cliente
Mensaje de inicio
Servidor
Certificado + Clave Pblica

Clave Secreta Cifrada
Canal Seguro
Figura 2-13 Creacin de un canal seguro con SSL
2.5.4 Seguridad en sistemas distribuidos

Aunque los sistemas distribuidos ofrecen gran flexibilidad y potencia tambin
introducen un gran nmero de problemas de difcil solucin referentes a la seguridad
de los mismos.
En este apartado nos centraremos en los mecanismos de seguridad que utilizan las
dos plataformas distribuidas ms extendidas. As, mientras COM tiende a utilizar los
mecanismos de seguridad proporcionados por el sistema operativo subyacente, en el
caso de CORBA, el ORB proporciona mecanismos de seguridad (a travs del servicio
de seguridad de CORBA) o bien haciendo uso del protocolo SSL sobre el que se
envan las tramas IIOP (CORBA sobre SSL).
Para garantizar la seguridad deben introducirse mecanismos que se extiendan por
todos los componentes de un sistema distribuido. Lo ideal para no dejar lagunas de
seguridad sera independizar al mximo las aplicaciones de los mecanismos de
seguridad de forma que las aplicaciones cliente y servidor puedan desarrollarse sin
tener en cuenta las restricciones de seguridad mientras que el gestor de seguridad
realizase las tareas de control de seguridad en paralelo.
2-78
Mientras que la autentificacin, integridad y privacidad son relativamente fciles de

configurar y gestionar en ambas plataformas distribuidas (COM y CORBA) los
mecanismos de autorizacin son considerablemente ms complejos.
CORBA sobre SSL
Como ya se vio en su momento, el principal protocolo utilizado por los ORB
CORBA es IIOP. Sin embargo, IIOP no incluye mecanismos de seguridad. Esto
hace necesario el uso de unos servicios de seguridad adicionales que pueden
construirse sobre SSL.
Desde el punto de vista de CORBA, el uso de SSL no introduce gran impacto en el
modo de programar los clientes o servidores de una aplicacin distribuida. La razn
es que SSL existe como una capa segura independiente entre IIOP y TCP/IP. Tal y
como se muestra en la Figura 2-14.
Cliente CORBA
Objeto CORBA
ORB
ORB
IIOP
IIOP
SSL
SSL
TCP / IP
TCP / IP
Figura 2-14 Capa SSL en una solucin basada en CORBA sobre SSL
A pesar de que la capa SSL apenas afecta al modo de programacin, s que introduce
una carga adicional importante en cuanto al rendimiento de la aplicacin debido a la
sobrecarga que introducen los mtodos de cifrado.
Los principales beneficios que introduce el uso de clientes CORBA sobre SSL son:
Autentificacin: Con SSL un cliente puede verificar la autentificacin de un

servidor y el servidor puede, opcionalmente, verificar la autentificacin del
cliente. Para ello es necesario que el cliente enve al servidor su propio
certificado.
2-79
Integridad de datos: SSL asegura que los datos no han sido alterados
incluyendo boletines de mensajes.
Privacidad: Una vez que una sesin SSL se ha iniciado, se intercambia otra
clave de forma segura, en este caso, simtrica. Esta clave ser la utilizada para
desencriptar los datos enviados a travs de la sesin que irn debidamente
encriptados.
CORBA sobre SSL proporciona una solucin sencilla y efectiva que facilita cierto
grado de seguridad. No obstante, este esquema no cumple todos los requisitos de
seguridad exigidos a los sistemas distribuidos. Concretamente, SSL no introduce
mecanismos que permitan la autorizacin de los usuarios remotos. En entornos
donde ser requiere mayor seguridad est disponible el servicio de seguridad de
CORBA.
Cortafuegos CORBA
Los cortafuegos previenen el acceso por parte de usuarios no autorizados
protegiendo los puntos de entrada a la red. Sin embargo, los cortafuegos
convencionales no gestionan adecuadamente el trfico generado por las aplicaciones
CORBA. Por ello resulta conveniente un enfoque estndar que controle el trfico
IIOP generado por los objetos CORBA que, permitiendo el acceso a los objetos
CORBA, mejore la seguridad. Estos cortafuegos CORBA permiten el paso del
trfico CORBA, que tambin puede ser CORBA / SSL. En OMG (2004b) se
propone una especificacin que da las pautas para construir este tipo de cortafuegos
CORBA.
Otra solucin proporcionada por algunos ORBs para permitir el trfico CORBA a
travs de cortafuegos es el uso del encapsulamiento de los paquetes IIOP sobre
paquetes HTTP. Estas soluciones se basan en proxies que realizan la conversin de
los paquetes. Un ejemplo de estas soluciones es el Gatekeeper propuesto por el ORB
de Visibroker.
2-80
Servicio de seguridad de CORBA

La especificacin del servicio de seguridad de CORBA (OMG, 2002a) que describe
en detalle cmo gestionar la seguridad en CORBA es bastante compleja. Esta
complejidad es debida a la complejidad intrnseca del tratamiento de la seguridad en
sistemas distribuidos. Adems, el servicio de seguridad debe adaptarse a las
necesidades de los sistemas distribuidos ms complejos lo que complica la
especificacin.
Adems de las dificultades bsicas (autentificacin, integridad y autorizacin) el
servicio de seguridad de CORBA resuelve un gran nmero de dificultades adicionales
relacionadas con la seguridad:
Delegacin: En sistemas de objetos distribuidos es frecuente que un objeto

llame a otro y ste a su vez llame a otro, con lo que se encadenan las llamadas
pudiendo aparecer agujeros de seguridad. El servicio de seguridad de
CORBA se encarga de la delegacin de las peticiones sobre los objetos
CORBA de forma controlada.
Auditora:
Para
monitorizar
la
seguridad
es
conveniente
auditar
determinados eventos como fallos de autentificacin, cambios de privilegios,

etc.
No-repudiacin: En los sistemas cliente / servidor puede ser necesario

evitar que algunos clientes remotos puedan denegar que solicitaron
determinadas operaciones. El servicio de seguridad de CORBA introduce
mecanismos que as lo aseguran.
Interoperabilidad: El servicio de seguridad de CORBA define el protocolo

Secure Inter-ORB Protocol (SECIOP), un protocolo diseado para permitir que
varios ORBs puedan interactuar de forma segura.
Seguridad en DCOM
La introduccin de DCOM en 1996 introdujo algunas modificaciones respecto a la
versin anterior: COM. As, DCOM extiende COM de forma natural con una
2-81
versin mejorada de RPC (denominada Object RPC) como protocolo de transporte

subyacente. Dada esta dependencia de DCOM respecto a RPC los servicios de
seguridad de DCOM estn basados en los servicios de seguridad de DCE RPC y los
mecanismos de seguridad aadidas a la API de COM reflejan los parmetros
necesarios para gestionar la capa de trasporte Object RPC.
Los mecanismos de seguridad de DCOM sobre los sistemas operativos Windows
descansan fundamentalmente sobre los mecanismos de seguridad nativos de dichos
sistemas operativos. A partir de Windows 2000 se proporciona la arquitectura
Kerberos para entornos distribuidos de programacin, junto a la clsica NTLM (NT
Lan Manager). Kerberos asegura un nivel de seguridad aceptable en redes internas.
Respecto a la configuracin, existen utilidades proporcionadas por el sistema
operativo, que permiten la configuracin de dichas arquitecturas de seguridad.
2.5.5 Kerberos
Kerberos es una arquitectura segura desarrollada por el MIT (Massachussets Institute of
Techonolgy) para asegurar su red interna. En la actualidad coexisten dos versiones
principales de Kerberos: Kerberos V4 y Kerberos V5. Desde el punto de vista
tcnico Kerberos V5 es una versin considerablemente ms madura.
Bsicamente, Kerberos proporciona autorizacin en entornos en los que hay
confianza. Kerberos tiene tres objetivos bsicos:
1. Permitir a un usuario la conexin a una red (autenticacin de usuarios)
2. Proporcionar una autenticacin de nodos de la red
3. Proporcionar confidencialidad de datos.
Kerberos se populariz en los aos 1990 siendo estandarizado por la IETF (Internet
Engineering Task Force). Como resultado se propusieron diversos documentos RFC
que describen el protocolo de autenticacin (RFC 1510, 1993) y la interfaz de
programacin de Kerberos (RFC 1964, 1996).
2-82
A pesar de que originariamente los protocolos de Kerberos fueron diseados con

encriptacin simtrica, en los ltimos aos ha habido fuerte demanda para que se
adopte tambin la encriptacin asimtrica.
En sus orgenes Kerberos se dise para Intranets donde se confiaba en una
autoridad central. A medida que aument el nmero de nodos se hizo necesario
aadir un rbol jerrquico de confianza. Es decir, existe una autoridad central que
certifica a otras autoridades secundarias.
Funcionamiento bsico
El protocolo de autenticacin es como sigue (RFC 1510, 1993). Un cliente enva una
peticin a un servidor de autenticacin pidiendo unas credenciales para un servidor
determinado. El servidor de autenticacin devuelve sus credenciales cifradas con la
clave del cliente. Las credenciales consisten en un ticket para el servidor y una clave de
cifrado temporal llamada clave de sesin. Los clientes envan su ticket que contiene la
identidad del cliente y una copia de la clave de la sesin al servidor. A partir de ese
instante el cliente y el servidor comparten la clave de la sesin que se usar para
autentificar al cliente y que podr ser usada opcionalmente para autenticar al servidor.
Ambos nodos podrn utilizar la clave compartida para cifrar cualquier informacin
entre ellos, permitiendo verificar la identidad de los nodos involucrados en una
transaccin, asegurar la integridad de los mensajes intercambiados o preservar la
privacidad de los mensajes. La aplicacin es libre de escoger el nivel de proteccin
deseado utilizando la API propuesta en el RFC 1964, (1996).
Este esquema requiere que haya uno o ms servidores de autenticacin ejecutndose
en computadoras situadas en localizaciones fsicamente seguras. Estos servidores
mantendrn una base de datos de servidores y clientes as como sus claves secretas.
Ventajas y desventajas de Kerberos
A la vista de la descripcin del funcionamiento de Kerberos se puede ver que se trata
de un mecanismo vlido para entornos cerrados. En ltima instancia, los servidores
de autenticacin que mantienen las bases de datos con las contraseas de los nodos
2-83
deben estar en una localizacin fsicamente segura, por lo que este esquema a pesar
de ser vlido en entornos distribuidos cerrados, tipo intranet (Ashley, P. y otros,
2000), no es vlido para entornos tipo Internet.
2.5.6 Mecanismos de autenticacin
La autenticacin es el proceso de validar un usuario asegurando que dicho usuario es
quien dice ser. Existen soluciones que varan desde el tradicional nombre /
contrasea, hasta el uso de objetos como smart cards o la medicin de ciertas
caractersticas biomtricas.
Un sistema puede verificar la identidad a travs de tres tipos de mecanismos:
Informacin conocida exclusivamente por el usuario (What you know):

Contraseas, etc.
Objetos posedos por el usuario (What you have): Smart cards (tarjetas de
acceso similares a las tarjetas de crdito), etc. Estas tarjetas pueden contener
un certificado digital del cliente que se enva al servidor para asegurar la
autenticidad del usuario.
Mediciones biomtricas (What you are): Cualquier medicin de alguna

caracterstica biomtrica como la huella dactilar, el iris, etc.
No todos los sistemas utilizan los tres tipos de mecanismos, sin embargo conviene
que se utilice ms de un mecanismo para reforzar la identidad. As, los objetos
posedos por el usuario, p.e. una tarjeta de acceso, normalmente van acompaados
por algn dato conocido exclusivamente por el usuario (una contrasea) o la
medicin de alguna caracterstica biomtrica. De este modo se previene el uso de
tarjetas robadas o perdidas.
2.6
CONCLUSIONES
En la actualidad Internet se ha convertido en un estndar de facto. Se trata de una

tecnologa muy extendida, madura y fiable. Adems, las tecnologas sobre las que se
2-84
asienta Internet constituyen la base sobre la que muchas empresas asientan sus
propias infraestructuras (intranets). En este captulo se ha hecho un anlisis de las
diferentes tecnologas disponibles para el diseo de aplicaciones distribuidas de
acceso remoto a travs de Internet. Se puede concluir que no existen soluciones
adecuadas para todas las situaciones. Cada tecnologa tiene sus ventajas e
inconvenientes.
As, en aplicaciones sencillas o en dispositivos que cuentan con unos recursos
mnimos el uso de arquitecturas distribuidas no orientadas a objetos como sockets o
SNMP puede proporcionar soluciones interesantes. Sin embargo, a medida que
aumenta la complejidad de las aplicaciones otro tipo de soluciones, por ejemplo las
basadas en arquitecturas distribuidas orientadas a objetos, parecen ms adecuadas.
Por otra parte, dada la generalizacin del protocolo HTTP parece interesante adoptar
soluciones que integren dicho protocolo. Las arquitecturas distribuidas orientadas a
objetos (CORBA, COM+ y Java / RMI) presentan, en general, una buena
integracin con dicho protocolo. Por tanto, para los sistemas complejos, una
solucin basada en estas arquitecturas orientadas a objetos junto al protocolo HTTP
ofrece gran potencia. Cada una de estas tres arquitecturas presenta sus caractersticas.
As, COM+ es la tecnologa ms indicada para ser utilizada en entornos Windows.
Adems, cuenta con la ventaja de ser ampliamente aceptada a nivel industrial e
incluso se utiliza como base para estndares muy extendidos en entornos industriales
como OPC o Profinet. CORBA resulta una buena eleccin sobre todo en entornos
abiertos, multilenguaje y multiplataforma. Esto es debido a que es apoyada por un
gran nmero de fabricantes, lo que convierte la interoperabilidad en un asunto de
gran trascendencia. Adems, se trata de una arquitectura muy madura y que cuenta
con especificaciones para aplicaciones con requisitos especiales como son CORBART o CORBA minimum. Al ser una arquitectura multilenguaje presenta una buena
integracin con Java, lo cual dota a la combinacin de Java y CORBA en una
solucin interesante en el entorno de Internet. Por ltimo, Java / RMI comparte
muchas caractersticas con CORBA. Esta arquitectura tambin ofrece una excelente
integracin en Internet y con los navegadores Web por lo que resulta una opcin
interesante a pesar de que su rendimiento a veces resulta pobre.
2-85
Otra alternativa, aunque no se trate de una tecnologa propiamente orientada a

objetos son los servicios Web. En este caso la integracin con el protocolo HTTP es
excelente. Sin embargo, se trata de una tecnologa relativamente nueva que est en
desarrollo en la actualidad. Adems, carece de algunos de los servicios tpicos de las
arquitecturas distribuidas orientadas a objetos (seguridad, eventos, etc), lo que
complica la construccin de aplicaciones industriales distribuidas.
Por ltimo, es evidente que los sistemas de acceso remoto requieren un nivel mnimo
de seguridad. No hay que olvidar que est involucrada la confidencialidad de la
informacin e incluso puede llegar a afectar a la integridad fsica de las personas. En
este captulo se han analizado algunas de las tcnicas ms habituales utilizadas en
Internet para proporcionar un entorno seguro de comunicacin. Cabe sealar que la
seguridad absoluta no existe. De hecho, probablemente nunca se obtendr una
solucin totalmente segura. Por otro lado, la introduccin de mecanismos de
seguridad sofisticados complica la construccin de los sistemas. Adems, aaden un
coste computacional elevado debido a que en ltima instancia la seguridad se basa en
tcnicas de encriptacin y para construir soluciones ms seguras se encripta mayor
cantidad de informacin con algoritmos ms seguros, lo que introduce mayor
sobrecarga en las aplicaciones. Por ello, antes de construir un sistema de acceso
remoto es necesario realizar un anlisis de riesgos para evaluar los posibles puntos
dbiles y adoptar la solucin ms adecuada en cada caso.
Referencias
Refs 2-1
REFERENCIAS
Aldrich J., Dooley J., Mandelsohn S., Rifkin A. Providing Easier Access to Remote
Objects in Client-Server Systems, Proc. of the Thirty-First Hawaii Internacional Conf. on
System Sciences, 1998, vol. 7, pp 366-375
Ashley, P., Vandenwauver, M., Siebenlist, F. Applying authorization to intranets:
architectures, issuees and APIs, Computer Communications, 23, 2000, pp. 1613-1620
Ariza, T. (2000), Contribuciones a la gestin de dispositivos en sistemas basados en
CORBA, Tesis doctoral, Universidad de Sevilla.
Blanco, P. M., Poli, M. A., Pereira M. R. (2003), OPC and CORBA in
Manufacturing Execution Systems: A Review, Proceedings of the 9th Conference on
Emerging Technologies and Factory Automation ETFA'03, pp. 50-57, Lisboa
Bobadilla, J., (1999), Superutilidades para Webmasters, McGraw-Hill
Box, D. (1998), Essential COM, Addison Wesley
Box, D. (2000), HTTP + XML = SOAP, MSDN Magazine, 15 (3), pp. 67-81.
Coelho, C.N., da Silva, D. C., Padrao, W. C., de vila C., da Mata, J., Fernandes, O.,
(2002), Reingineering embedded systems for the Internet, Proc. of the 15th IFAC
Congress Barcelona.
Diskin D., Chubin S., (1998) Recommendations for Using DCE, DCOM and
CORBA Middleware. http://dii-sw.ncr.disa.mil/coe/topics/atd/recommend/all.
pdf Abril 1998
,J. (1997) Object-based Distributed Systems Draft material for 3rd edition of
Distributed Systems Concepts and Design. DCS, University of London
Gokhale, A., Kumar, B., Sahuguet, A. (2002), Reinventing the Wheel? CORBA vs.
Web Services, http://www2002.org/CDROM/alternate/395
Grosso W., (2001) Java / RMI, OReilly & Associated, Inc.Dollimore
Referencias
Refs 2-2
Guijun W., Ungar L., Klawitter D. A Framework Supporting Component Assembly

for Distributed Systems, Enterprise Distributed Object Computing Workshop, pp 136-146
Guyonnet G., E. Gressier-Soudan, F. Weis (1997) COOL-MMS: a CORBA
approach for ISO-MMS. ECOOP97 Workshop CORBA: Implementation, Use and
Evaluation. Jyvaskyla. Finland.
Henning M. and S. Vinoski (1999) Advanced CORBA Programming with C++,
Addison Wesley Longman, Inc
Huitema, C. (1996) IPV6 The new Internet Protocol, Prentice Hall
ISO / IEC 7498-1 (1994), Open Systems Interconnection -- Basic Reference
Model: The Basic Model, http://www.iso.org
ISO / IEC 9596 (1998), Common Management Information Protocol,
http://www.iso.org
Iwanitz, F., Lange, J. (2002) OPC Fundamentals, Implementation and Application,
Hthig Verlag Heidelberg
Jaworsky J., Perrone P. J. (2000) Java Security Handbook, SAMS Publishing
Jong
de,
Irmen
(2002),
Web
Services
SOAP
and
CORBA,
http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html
Kunes, M., Sauter, T., Fieldbus-Internet connectivity: the SNMP approach, IEEE
Trans. Ind. Electronics, vol. 48, no 6, 2001, pp. 1248-1256
Lwy, J. (2001), COM and .NET: Component Services, OReilly.
Maciel, C. D., Ritter, C., M., TCP / IP networking in process control plants,
Computers in Industrial Engineering, 1998, Vol. 35, Nos 3--4, pp. 611-614
Marn R., P.J. Sanz, (2002) Augmented Reality to Teleoperate a Robot through the
Web Proc. of the 15th IFAC Congress Barcelona.
Refs 2-3
Referencias
Mart, P. Aguado, J.C. Rolando, F. Velasco, M. Colomar, J. Y J.M. Fuertes (1999) A

Java-based framework for distributed supervision and control of industrial
processes Proceedings of the 7th Conference on Emerging Technologies and Factory Automation
ETFA'99, pp. 33-41, Barcelona
Microsoft
Corporation,
DCOM
Technical
Overview,
(1996)
http://msdn.microsoft.com/library
OMG, Object Management Group, (1999) CORBA Components, Julio 1999.
URL: http://www.omg.org/docs/orbos/99-07-01.pdf
OMG, Object Management Group, (2002a) Security Service Specification,
Versin,
1.8,
Marzo
2002.
URL:
http://www.omg.org/technology/documents/formal/real-time_CORBA.htm
OMG, Object Management Group, (2002b) Minimum CORBA Specification,
Versin,
1.0,
Agosto
2002.
URL:
http://www.omg.org/technology/documents/formal/minimum_CORBA.htm
OMG, Object Management Group, (2002c) Real Time-CORBA Specification,
Versin,
1.1,
Agosto
2002.
URL:
http://www.omg.org/technology/documents/formal/real-time_CORBA.htm
OMG, Object Management Group, (2003) The Unified Modeling Language
Specification
Version
1.5,
Versin,
1.5,
Marzo
2003,
URL:
http://www.omg.org/technology/documents/formal/uml.htm
OMG, Object Management Group, (2004a) Common Object Request Broker
Architecture:
Core
Specification,
Marzo
2004,
Versin
3.0.3
URL:
http://www.omg.org/technology/documents/formal/corba_iiop.htm
OMG, Object Management Group, (2004b) CORBA Firewall Transversal
Specification,
Marzo
2004,
Final
http://www.omg.org/docs/ptc/04-03-01.pdf
OPC.URL: http://www.opcfoundation.org/
Adopted
Specification
URL:
Referencias
Refs 2-4
Orfali, R., Harkey, D. (1998) Client / Server programming with Java & CORBA,
2nd Edition, John Wiley & Sons.
Pritchard, J., (1999) COM and CORBA side by side, Addison-Wesley
Raj, G. S., (1998) A detailed comparison of CORBA DCOM and Java/RMI,
http://my.execpc.com/~gopalan/misc/compare.html)
RFC 768, (1980) User Datagram Protocol http://www.ietf.org/rfc/rfc768.txt
RFC 791, (1981) Internet Protocol http://www.ietf.org/rfc/rfc791.txt
RFC
793,
(1981)
Transmission
Control
Protocol
http://www.ietf.org/rfc/rfc793.txt
RFC
821,
(1982)
Simple
Mail
Transfer
Protocol,
SMTP
RFC 822, (1982) Standard For The Format Of ARPA Internet Text Messages
RFC 854, (1983) Telnet Protocol Specification http://www.ietf.org/rfc/rfc854.txt
RFC 959, (1985) File Transfer Protocol (FTP) http://www.ietf.org/rfc/rfc959.txt
RFC 1157, (1990) A Simple Network Management Protocol (SNMP)
RFC 1180, (1991) A TCP / IP Tutorial http://www.ietf.org/rfc/rfc1180.txt
RFC
1319,
(1992)
The
MD2
Message-Digest
Algorithm
MD4
Message-Digest
Algorithm
MD5
Message-Digest
Algorithm
RFC
1320,
(1992)
The
RFC
1321,
(1992)
The
Refs 2-5
Referencias
RFC 1510, (1993) The Kerberos Network Authentication Service (V5)

RFC
1630,
(1994)
Universal
Resource
Identifiers
in
WWW
RFC
1631,
(1994)
The
IP
Network
Address
Translator
(NAT)
RFC
1964,
(1996)
The
Kerberos
Version
GSS-API
Mechanism
RFC 2460, (1998) Internet Protocol, Version 6 (IPv6) Specification,
RFC
2616,
(1999)
Hypertext
Transfer
Protocol
HTTP/1.1,
Rusty E.(1997) Java Network Programming O'Reilly.
Sang-Hoon K., Jaehong P., Young-Geun H., Gibom K., Kyo-Il L. "The Internetbased virtual machining system using CORBA", Integrated Manufacturing Systems, 13/5,
pps 340-344 (2002)
Sanz R., M. Alonso, CORBA for Control Systems, Annual Reviews in Control, No 25,
2001, pp. 169-181
Sanz R., I. Gonzlez, M. Segarra, R. Tagliarini, L. Gomes, G. Hernndez, A.
Zangrilli, (2002) CORBA-based interoperation in substation automation systems
Proc. of the 15th IFAC Congress Barcelona.
Sauter, T., Lobashov, M., Pratl, G. (2002) Lessons learnt from Internet Access to
Fieldbus Gateways, Proc. of the IECON02, Sevilla.
Schmidt, D.C; Kuhns, F., (2000) An Overview of the Real-Time CORBA
Specification IEEE Computer June, pp 56-63.
Referencias
Refs 2-6
Schneeman, R. D. (1999), Implementing a standards-based distributed measurement

and control application on the Internet, http://ieee1451.nist.gov/framework.pdf
Schneider, K., Intelligent field devices in factory automation modular structures into
maunfacturing cells, Proceedings of the 9th Conference on Emerging Technologies and Factory
Automation ETFA'03, pp. 101-104, Lisboa
Seinturier, L. Laurent, A. Dumant, B. Gressier-Soudan, E. Y F. Horn (1999). A
Framework for Real-Time Communication Based Object Oriented Industrial
Messaging Services Proceedings of the 7th Conference on Emerging Technologies and Factory
Automation ETFA'99, Barcelona
Stallings, W., (2000) Comunicaciones y redes de ordenadores, 6 Edicin, PrenticeHall
Stevens, W., R. (1994) TCP / IP Ilustrated, Volume 1. The Protocols, AddisonWesley.
Sturm, J. (2000) Developing XML solutions, Microsoft Press.
Sun Microsystems, Java Remote Method Invocation Distributed Computing for
Java, http://java.sun.com/marketing/collateral/javarmi.html
Vinoski S., CORBA: Integrating Diverse Applications Within Distributed
Heterogeneous Environments IEEE Communications Magazine, 1997, Vol 14, No 2.
URL: http://www.cs.wustl.edu/~schmidt/PDF/vinoski.pdf
Weaver,
A.C.
Privacy
and
Security
on
the
Internet,
http://www.cs.virginia.edu/~acw/cs551-6/Privacy-and-Security-on-the-Internet.doc
W3C Recommendation, (2003) SOAP Version 1.2 Part 0: Primer, 2003,

http://www.w3.org/TR/soap12-part0
W3C
Recommendation,
http://www.w3.org/TR/ws-arch
(2004a)
Web
Services
Architecture,
Referencias
Refs 2-7
W3C Recommendation, (2004b) Extensible Markup Language (XML) 1.0 (Third

Edition), http://www.w3.org/TR/REC-xml
Zimmermann, H. (1980). OSI reference model. The ISO model of architecture for
open systems interconnection, IEEE Transactions on Communications, COM-28
n4, April, pp 425-432.

2 Cap2

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2 Cap2

Загружено:

Авторское право:

Доступные форматы

Metodologa de acceso remoto a plantas industriales

SISTEMAS DISTRIBUIDOS EN ENTORNOS

Sistemas distribuidos en entornos Internet / INTRANET

TCP / IP en entornos industriales

IPv4 vs. IPv6

Arquitecturas distribuidas no orientadas a objetos

Protocolos de gestin de red

Arquitecturas distribuidas orientadas a objetos

COM / DCOM / COM+

Integracin de arquitecturas distribuidas en navegadores Web

Estndares basados en arquitecturas distribuidas

Seguridad en redes Internet / intranet

Nociones bsicas de criptografa

Protocolo SSL (Secure Sockets Layer)

Seguridad en sistemas distribuidos

Captulo 2 Sistemas distribuidos en entornos Internet / Intranet

2. SISTEMAS DISTRIBUIDOS EN ENTORNOS INTERNET /

Internet es una red de ordenadores pblica basada en tecnologa de conmutacin de

Metodologa de acceso remoto a plantas industriales

Red: IP (Internet Protocol, RFC 791, 1981). Gestiona el encaminamiento de los

Transporte: Este nivel proporciona un flujo de datos entre dos, o ms

Aplicacin: En el nivel de aplicacin se gestionan los detalles de aplicaciones

2.1.1 TCP / IP en entornos industriales

Captulo 2 Sistemas distribuidos en entornos Internet / Intranet

transformacin se justifica en gran parte por razones econmicas, as como por su

Metodologa de acceso remoto a plantas industriales

Estos nuevos dispositivos requieren unas prestaciones y un espacio de memoria

Un espacio de direcciones limitado: IP define un campo de direccin de

Captulo 2 Sistemas distribuidos en entornos Internet / Intranet

sin embargo, la estructura de las direcciones IP (en dos niveles: nmero de

Direcciones IP determinadas por la topologa de la red: Las direcciones

Inexistencia de mecanismos de autoconfiguracin: Para que el

Inexistencia de mecanismos intrnsecos de seguridad: El protocolo

Ineficiente gestin de la calidad de servicio en las conexiones: IPv4 no

Metodologa de acceso remoto a plantas industriales

Un espacio de direcciones IP ampliado: IPv6 utiliza direcciones de 128

Introduccin de cabeceras opcionales: IPv6 introduce mecanismos que

Mecanismos para la asignacin de recursos: En lugar del campo tipo de

Captulo 2 Sistemas distribuidos en entornos Internet / Intranet

tratamiento especial. Esto ayuda al tratamiento del trfico especializado

Permite la autoconfiguracin de los ordenadores: Por autoconfiguracin

Capacidad de adaptarse dinmicamente a nuevas topologas de red:

Estas mejoras hacen suponer que, aunque lentamente, su aplicacin se vaya

Sockets tipo datagrama: Proporcionan una interfaz para usar el protocolo

Metodologa de acceso remoto a plantas industriales

Sockets tipo stream: Proporcionan una interfaz al protocolo TCP. Este

Ventajas e inconvenientes de los sockets

Captulo 2 Sistemas distribuidos en entornos Internet / Intranet

Metodologa de acceso remoto a plantas industriales

(http://www.qnx.com) o Linux-RT (http://www.realtimelinuxfoundation.org). As

Figura 2-1 Solicitud de pginas Web usando el protocolo HTTP.

Captulo 2 Sistemas distribuidos en entornos Internet / Intranet

Pginas activas en el cliente: En este modelo el procesamiento del

Pginas activas en el servidor: Procesamiento de los documentos en el

Pginas activas en el cliente y en el servidor: Se trata de un modelo mixto

La principal ventaja de que el procesamiento de las pginas se efecte en el cliente es

Metodologa de acceso remoto a plantas industriales

las alternativas orientadas a objetos para un apartado posterior de este mismo

Lenguajes de script: Los scripts de una pgina Web permiten la ejecucin de

Applets Java: Un applet Java es una aplicacin Java (http://java.sun.com) que

Captulo 2 Sistemas distribuidos en entornos Internet / Intranet

Componentes ActiveX: Otra alternativa similar a los applets Java es el uso de

Pginas Web dinmicas en el servidor