Universidad de Oviedo
Departamento de Ingenierıa Electrica, Electronica,
de Computadores y Sistemas
Trabajo de Investigacion
Supervision remota de procesos industriales atraves de Internet.
Alberto Pintado Sanchez
Septiembre 2004
2
Universidad de Oviedo
Departamento de Ingenierıa Electrica, Electronica,
de Computadores y Sistemas
Trabajo de Investigacion
SUPERVISION REMOTA DE PROCESOSINDUSTRIALES A TRAVES DE INTERNET.
Autor: Alberto Pintado Sanchez
Director: Ignacio Dıaz Blanco
Gijon, Septiembre de 2004
4
TRABAJO DE INVESTIGACION. 5
Resumen
EN este trabajo, se propone un esquema para la monitorizacion remota deprocesos industriales a traves de Internet.
La utilizacion de Internet como medio de comunicaciones supone un tremen-do avance en este area ya que nos permite deslocalizar los puestos de controlque anteriormente se encontraban situados en la planta industrial.
El interfaz elegido para la interaccion con nuestro sistema es la WWW(WorldWide Web). La utilizacion del lenguaje HTML para la presentacion de los datosresultantes de la monitorizacion proporciona una gran flexibilidad debido a quegran parte de los dispositivos que poseen conexion a Internet tienen instaladoun navegador web.
Otra de las ventajas de la utilizacion de la WWW como interfaz de nuestrosistema es que nos encontramos ante una tecnologıa completamente consolidaday utilizada por millones de usuarios. Ademas contamos con la existencia denumerosas herramientas tanto libres como comerciales que pueden ser utilizadasen el desarrollo e implementacion del sistema.
Esta nueva vision de la monitorizacion de procesos permite realizar unaestrategia global para la supervision de los procesos industriales que influira demanera claramente positiva en la eficiencia y seguridad de los mismos.
6
TRABAJO DE INVESTIGACION. 7
Indice general
1. Introduccion 131.1. Descripcion del sistema . . . . . . . . . . . . . . . . . . . . . . . 14
2. Capa Fısica 152.1. Seguridad en la capa fısica . . . . . . . . . . . . . . . . . . . . . . 15
3. Capa de monitorizacion 173.1. Seguridad en la capa de monitorizacion . . . . . . . . . . . . . . 18
4. Capa de transporte 194.1. ¿Que es Middleware? . . . . . . . . . . . . . . . . . . . . . . . . . 194.2. Tipos de middleware . . . . . . . . . . . . . . . . . . . . . . . . . 194.3. Clasificacion del Middleware . . . . . . . . . . . . . . . . . . . . . 204.4. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.1. IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4.2. Arquitectura de organizacion de objetos . . . . . . . . . . 20
4.4.2.1. Objetos de aplicacion . . . . . . . . . . . . . . . 214.4.2.2. ORB . . . . . . . . . . . . . . . . . . . . . . . . 214.4.2.3. CORBA Facilities . . . . . . . . . . . . . . . . . 224.4.2.4. CORBA Services . . . . . . . . . . . . . . . . . . 224.4.2.5. Ventajas de CORBA . . . . . . . . . . . . . . . 224.4.2.6. Desventajas de CORBA . . . . . . . . . . . . . . 23
4.5. JAVA-RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.5.1. Arquitectura RMI . . . . . . . . . . . . . . . . . . . . . . 23
4.5.1.1. Componentes sustitutos o stubs . . . . . . . . . 244.5.1.2. Esqueleto . . . . . . . . . . . . . . . . . . . . . . 244.5.1.3. Capa de referencias remotas . . . . . . . . . . . 244.5.1.4. Capa de Transferencia . . . . . . . . . . . . . . . 244.5.1.5. Ejemplo de interface Java-RMI . . . . . . . . . . 24
4.5.2. Ventajas RMI . . . . . . . . . . . . . . . . . . . . . . . . . 244.5.3. Desventajas de RMI . . . . . . . . . . . . . . . . . . . . . 25
4.6. DCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8 INDICE GENERAL
4.6.1. Arquitectura COM . . . . . . . . . . . . . . . . . . . . . . 254.6.1.1. Interface COM . . . . . . . . . . . . . . . . . . . 254.6.1.2. Clase COM . . . . . . . . . . . . . . . . . . . . . 264.6.1.3. Objetos COM . . . . . . . . . . . . . . . . . . . 264.6.1.4. Servidor COM . . . . . . . . . . . . . . . . . . . 26
4.6.2. Ejemplo de un interface COM . . . . . . . . . . . . . . . . 274.6.2.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . 274.6.2.2. Inconvenientes . . . . . . . . . . . . . . . . . . . 27
4.7. Plataforma .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.8. JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.8.1. Objetivos de JXTA . . . . . . . . . . . . . . . . . . . . . . 284.8.1.1. Interoperabilidad . . . . . . . . . . . . . . . . . . 284.8.1.2. Independencia de la plataforma . . . . . . . . . 284.8.1.3. Ubicuidad . . . . . . . . . . . . . . . . . . . . . 28
4.9. Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.9.1. Ventajas de Jabber . . . . . . . . . . . . . . . . . . . . . . 294.9.2. Desventajas Jabber . . . . . . . . . . . . . . . . . . . . . . 294.9.3. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . 30
4.9.3.1. Servidores . . . . . . . . . . . . . . . . . . . . . 304.9.3.2. Clientes . . . . . . . . . . . . . . . . . . . . . . . 304.9.3.3. Gateway . . . . . . . . . . . . . . . . . . . . . . 30
4.9.4. Esquema de direccionamiento . . . . . . . . . . . . . . . . 304.9.4.1. Identificador de dominio . . . . . . . . . . . . . . 314.9.4.2. Identificador de nodo . . . . . . . . . . . . . . . 314.9.4.3. Identificador de recurso . . . . . . . . . . . . . . 31
4.9.5. Seguridad en Jabber (SASL) . . . . . . . . . . . . . . . . 314.9.5.1. Ejemplo SASL . . . . . . . . . . . . . . . . . . . 31
4.9.6. Protocolo IQ (Input/Query) . . . . . . . . . . . . . . . . . 324.9.7. Servicio de busqueda . . . . . . . . . . . . . . . . . . . . . 334.9.8. Envıo de datos . . . . . . . . . . . . . . . . . . . . . . . . 344.9.9. Servicio de transmision de ficheros . . . . . . . . . . . . . 354.9.10. Servicio de transmision de ficheros . . . . . . . . . . . . . 374.9.11. Servicio de localizacion geografica . . . . . . . . . . . . . 374.9.12. Servicio de RPC(Remote Procedure Calls) . . . . . . . . . 374.9.13. Utilizacion de Jabber como Middleware . . . . . . . . . . 384.9.14. Requisitos de la capa de transporte . . . . . . . . . . . . . 38
4.10. Alternativa Seleccionada (Jabber) . . . . . . . . . . . . . . . . . 384.10.1. Estandares abiertos de Internet . . . . . . . . . . . . . . . 394.10.2. Software Libre para Jabber . . . . . . . . . . . . . . . . . 394.10.3. Facilidad de aprendizaje . . . . . . . . . . . . . . . . . . . 394.10.4. Independencia del lenguaje de programacion . . . . . . . 394.10.5. Protocolos extensibles . . . . . . . . . . . . . . . . . . . . 39
5. Capa de aplicacion 415.1. Modulos de procesamiento de datos . . . . . . . . . . . . . . . . . 41
5.1.1. Modulo de procesamiento y almacenamiento de datos Mithril 425.1.2. Modulo de procesamiento de datos . . . . . . . . . . . . . 42
5.2. Modulo de almacenamiento persistente de datos . . . . . . . . . . 425.2.1. Volcado de datos a fichero . . . . . . . . . . . . . . . . . . 435.2.2. Volcado de datos en cinta . . . . . . . . . . . . . . . . . . 43
INDICE GENERAL 9
5.2.3. Utilizacion de un S.G.B.D. . . . . . . . . . . . . . . . . . 435.2.4. Alternativa seleccionada . . . . . . . . . . . . . . . . . . . 43
5.3. Modulo de interface con otros sistemas . . . . . . . . . . . . . . . 445.3.1. Ventajas de los servicios web . . . . . . . . . . . . . . . . 445.3.2. Inconvenientes de los servicios web . . . . . . . . . . . . . 455.3.3. Modo de funcionamiento . . . . . . . . . . . . . . . . . . . 455.3.4. Protocolos utilizados por los servicios web . . . . . . . . . 45
5.3.4.1. WSDL (Web Services Definition Language) . . . 455.3.4.2. SOAP (Simple Object Access Protocol) . . . . . 455.3.4.3. UDDI (Universal Description, Discovery and In-
tegration) . . . . . . . . . . . . . . . . . . . . . 465.3.5. Ejemplos de servicios web . . . . . . . . . . . . . . . . . . 46
5.4. Implementacion de los modulos de procesamiento de datos . . . . 495.5. Seguridad en la capa de aplicacion . . . . . . . . . . . . . . . . . 50
5.5.1. Seguridad en XML . . . . . . . . . . . . . . . . . . . . . . 505.5.1.1. XML DSig . . . . . . . . . . . . . . . . . . . . . 505.5.1.2. XML Enc . . . . . . . . . . . . . . . . . . . . . . 505.5.1.3. SAML . . . . . . . . . . . . . . . . . . . . . . . . 505.5.1.4. XACML . . . . . . . . . . . . . . . . . . . . . . 515.5.1.5. XrML . . . . . . . . . . . . . . . . . . . . . . . . 515.5.1.6. XML Key Management Specification . . . . . . 51
5.5.2. Seguridad en Servicios Web . . . . . . . . . . . . . . . . . 515.5.2.1. WS-Security . . . . . . . . . . . . . . . . . . . . 51
6. Capa de presentacion 536.1. Interfaz web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2. Mejoras a HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.2.1. Interfaz basico . . . . . . . . . . . . . . . . . . . . . . . . 546.2.2. Interfaz Avanzado . . . . . . . . . . . . . . . . . . . . . . 54
6.3. Estructura de la capa de presentacion . . . . . . . . . . . . . . . 546.3.1. XSL (eXtensible Stylesheet Language . . . . . . . . . . . 55
6.3.1.1. XSLT . . . . . . . . . . . . . . . . . . . . . . . . 556.3.1.2. Aplicacion de tecnicas XSL al sistema . . . . . . 56
6.4. Interfaz web para servicios web . . . . . . . . . . . . . . . . . . . 566.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7. Vision General del sistema 597.1. Flujo de datos del sistema . . . . . . . . . . . . . . . . . . . . . . 597.2. Interaccion del usuario con el sistema . . . . . . . . . . . . . . . . 60
7.2.1. Peticion de datos a traves del interfaz web . . . . . . . . . 607.2.2. Peticion de datos a traves de servicios web . . . . . . . . 60
8. Conclusion 61
9. Futuras lıneas de trabajo 63
10 INDICE GENERAL
TRABAJO DE INVESTIGACION. 11
Indice de figuras
1.1. Esquema de las capas del sistema . . . . . . . . . . . . . . . . . . 14
2.1. Sensores acoplados a un motor electrico . . . . . . . . . . . . . . 16
3.1. Tarjeta de adquisicion de datos conectada a un PC . . . . . . . . 17
4.1. Esquema de la arquitectura de organizacion de objetos CORBA . 214.2. Diagrama JAVA-RMI . . . . . . . . . . . . . . . . . . . . . . . . 234.3. Esquema de comunicaciones DCOM entre objetos COM en difer-
entes maquinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4. Protocolo Input/Query . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Esquema de un mensaje SOAP . . . . . . . . . . . . . . . . . . . 46
6.1. Esquema de aplicacion web . . . . . . . . . . . . . . . . . . . . . 55
12 INDICE DE FIGURAS
TRABAJO DE INVESTIGACION. 13
CAPITULO 1
Introduccion
HOY en dıa Internet se encuentra practicamente en todos los aspectos dela vida cotidiana, podemos conectarnos a Internet desde nuestras propias
casas e incluso se ha convertido en muchos casos en una herramienta fundamen-tal dentro del entorno de trabajo.
A lo largo de estos ultimos anos el crecimiento de Internet y la WWW hasido exponencial. Actualmente, existe una gran variedad de servicios a travesde Internet como pueden ser los bancos electronicos, las librerıas, reserva debilletes, administracion publica, etc.
Aunque existen campos que han evolucionado de una manera espectacularcon la aparicion de Internet, en otros como la monitorizacion de sistemas nose han abierto grandes lıneas de investigacion para la utilizacion de Internetcomo medio de comunicaciones. Existen ciertos estudios en el campo de la mon-itorizacion remota como [?], [?], [?], [?], [?] pero distan mucho del crecimientoespectacular de otras ramas. Esta tecnologıa aporta una enorme flexibilidad yaque permite independencia en la localizacion del sistema a monitorizar y deloperador.
Debido al vacıo existente dentro de este campo, este trabajo de investigaciontratara de desarrollar un sistema que sirva como comienzo para futuras investi-gaciones en este area.
En este trabajo, se realizara un estudio de viabilidad para el diseno de unsistema de monitorizacion remota. Dentro de este estudio se emplearan las masnovedosas tecnicas conocidas por el autor para desarrollar un sistema eficiente ybasado en estandares abiertos. Otro de los criterios que seguiremos en el estudiosera la implementacion de un sistema distribuido, en el cual cada uno de loselementos sea independiente del resto permitiendo el alta y baja dinamica denodos en el sistema.
14 CAPITULO 1. INTRODUCCION
1.1. Descripcion del sistema
EL sistema de monitorizacion remota se presenta como una arquitectura mul-tinivel dentro de la cual podemos diferenciar las siguientes capas:
Capa Fısica (Sensores)
Capa de Monitorizacion
Capa de Transporte (Middleware)
Capa de Aplicacion
Capa de Presentacion
MITHRILMITRHIL
MIDDLEWARE
INTERFACE BUILDER
APLICACIÓNWEB SERVICIOS
WEB
WS-GUI
HTML
FLASH JAVA
SENSORES
MODULO DE ADQUISICION
Figura 1.1: Esquema de las capas del sistema
Debido a que como comentaremos despues las dos primeras capas se encuen-tran totalmente englobadas dentro del proyecto Mithril del Area de Ingenierıade Sistemas y Automatica de la Universidad de Oviedo, este trabajo de investi-gacion se centrara en las tres capas superiores.
TRABAJO DE INVESTIGACION. 15
CAPITULO 2
Capa Fısica
La capa fısica se encuentra en la parte inferior de nuestro sistema y esta for-mada por el conjunto de dispositivos fısicos utilizados para la recoleccion dedatos y por sus conexiones con la tarjeta de adquisicion de datos del PC. Elconjunto de elementos de medida incluye los sensores utilizados para convertirlas magnitudes fısicas en senales procesables por la tarjeta de adquisicion dedatos.
2.1. Seguridad en la capa fısica
En esta capa es fundamental poseer de una buena seguridad fısica basadaen el control de acceso a las instalaciones donde se encuentran nuestros dispos-itivos de medida. Tambien es extremadamente importante la seguridad laboralde los operarios que controlen nuestro sistema por lo que deberemos senalarconvenientemente y conforme a la legislacion vigente todos y cada uno de lospuntos peligrosos de nuestro sistema.
16 CAPITULO 2. CAPA FISICA
Figura 2.1: Sensores acoplados a un motor electrico
TRABAJO DE INVESTIGACION. 17
CAPITULO 3
Capa de monitorizacion
Esta capa se encuentra implementada dentro del proyecto Mithril(isa.uniovi.es/~pgarcia/mithril) del Area de Ingenierıa de Sistema y Automatica de laUniversidad de Oviedo.
Figura 3.1: Tarjeta de adquisicion de datos conectada a un PC
Este proyecto pretende construir un sistema de captura y monitorizacionde datos modular y adaptable a las necesidades de un cliente concreto. Mithril
18 CAPITULO 3. CAPA DE MONITORIZACION
controla la recoleccion y preparacion de datos provenientes de los sensores atraves de las tarjetas de adquisicion de datos instaladas en los PC’s.
3.1. Seguridad en la capa de monitorizacion
En la capa de monitorizacion implementaremos la seguridad a traves dela seguridad fısica de nuestros equipos ası como de la seguridad dentro de lospropios ordenadores donde se encuentra instalado el software de adquisicion dedatos mediante un sistema de contrasenas lo suficientemente robusto.
TRABAJO DE INVESTIGACION. 19
CAPITULO 4
Capa de transporte
La capa de transporte es la encargada de aportar las funcionalidades nece-sarias a las capas superiores para la transmision de datos entre los diferenteselementos de la red. Este tipo de software tambien es conocido bajo el nombrede middleware. El middleware funciona como una especie de “pegamento” entrelos diferentes elementos en la integracion de sistemas. Como veremos a contin-uacion, existen numerosas tecnologıas de objetos distribuidos cada una de ellascon sus ventajas e inconvenientes.
4.1. ¿Que es Middleware?
Middleware es una capa situada entre las aplicaciones y la red. Este softwareproporciona servicios como identificacion, autorizacion, directorios y seguridad.
Middleware es un software de conectividad que permite la interaccion deprocesos situados en una o mas maquinas a traves de una red. A lo largo delos anos el middleware se ha encontrado presente en diversas formas como lossistemas CICS O MQ Series de IBM, CORBA, COM o J2EE y ultimamente enlos Servicios Web. El middleware permite la integracion de sistemas heredadoscon las ultimas tecnologıas proporcionando ası un mecanismo para el cambiopaulatino de las estructuras de tecnologıas de la informacion.
4.2. Tipos de middleware
Existen diferentes tipos de middleware:
Monitores de transaccion de procesos
RPC (Remote Procedure Calls)
Middleware Orientado a Mensajes (MOM)
Object Request Brokers (ORB)
20 CAPITULO 4. CAPA DE TRANSPORTE
Los servicios de sistemas distribuidos incluyen los RPC, MOM y ORB.
4.3. Clasificacion del Middleware
Segun [?] se puede realizar la siguiente clasificacion del middleware:
RPC contra Mensajerıa Asıncrona
Especıficos de un lenguaje contra independientes del lenguaje
Propietarios contra basados en estandares
Incrustados contra empresariales
4.4. CORBA
CORBA (Common Object Request Broker Architecture) es una arquitecturaabierta no propietaria dependiente del OMG (Object Management Group) desti-nada a la integracion de aplicaciones informaticas sobre practicamente cualquiersistema operativo y lenguaje de programacion.
4.4.1. IDL
La finalidad del IDL(Interface Definition Language) es la definicion de losinterfaces distribuidos. Estos interfaces proporcionan los nombres con los cualesse va a poder acceder a los objetos remotos, los parametros de entrada y saliday las posibles excepciones que pueda lanzar el metodo
El siguiente ejemplo describe un objeto CORBA cuyas operaciones son la raızcuadrada y la potencia, la raız cuadrada recibe como parametro un numero realy devuelve otro numero real y la potencia recibe como parametros de entradala base y el exponente y devuelve el resultado en otro real.
module Calculadora{interface Funciones {
float raizCuadrada (in float numero);float potencia (in float base, in float exponente);
}}
4.4.2. Arquitectura de organizacion de objetos
Objetos de Aplicacion
ORB Agente de Peticion de Objetos
CORBA Facilities
CORBA Services
4.4. CORBA 21
Objetos de
Aplicación
CORBAFacilitiesVerticales
CORBAFacilities
Horizontales
ORB
CORBA Services
Figura 4.1: Esquema de la arquitectura de organizacion de objetos CORBA
4.4.2.1. Objetos de aplicacion
Los objetos de aplicacion son los objetos que implementan las interfaces IDLdefinidas por el programador.
4.4.2.2. ORB
Los requisitos para que un ORB cumpla con la especificacion CORBA sonlos siguientes:
modelo de objetos CORBA
arquitectura CORBA
sintaxis y semantica para el IDL del OMG
A su vez, el ORB debe contener los siguientes componentes basicos:
Interfaz de invocacion dinamica Permite emitir una peticion sin tener stub
Interfaz de esqueleto dinamico Igual que el anterior pero en el lado servidor
Stubs y esqueleto IDL Los stubs y esqueletos sirven como nexo entre elcliente y el servidor. Son generados a partir del interfaz IDL.
Nucleo ORB Proporciona los metodos necesarios para el transporte de peti-ciones desde los clientes hacia la implementaciones de los objetos
22 CAPITULO 4. CAPA DE TRANSPORTE
Interfaz ORB Ofrece varias funciones como conversion de referencias de ob-jetos a texto, etc.
Adaptador de objetos La principal funcion de los adaptadores de objeto esservir de interfaz entre la implementacion de un objeto y su ORB ası comopermitir la activacion transparente de los mismos. En la actualidad seencuentran definidos dos tipos de adaptadores de objetos el BOA (BasicObject Adapter) y el POA (Portable Object Adapter)
4.4.2.3. CORBA Facilities
Las CORBA Facilities definen un conjunto de servicios de alto nivel orienta-dos a las aplicaciones de usuario final como pueden ser: administracion de datos,interfaces de usuario final, etc.
Dentro de las CORBA Facilities existen dos categorıas:
CORBA Facilities Horizontales El OMG ha definido como las siguientesCORBA Facilities horizontales:
Interface de usuario
Administracion de informacion
Administracion de sistemas
Administracion de tareas
CORBA Facilities Verticales Las CORBA Facilities Verticales definen in-terfaces IDL estandar para sectores de mercado concretos como pueden ser:telecomunicaciones, medicina, etc.
4.4.2.4. CORBA Services
Los CORBA Services definen un conjunto de servicios de bajo nivel utilizadospor las aplicaciones distribuidas y que permiten comunicarse entre sı de unaforma estandar.
Entre los CORBA Services podemos encontrar:
Servicios de Nombres
Servicios de Eventos
Servicios de Notificacion
Servicios de Seguridad
4.4.2.5. Ventajas de CORBA
Independiente del lenguaje
Independiente de la plataforma
Eficiente
Variedad de implementaciones tanto comerciales como libres
4.5. JAVA-RMI 23
ClienteRMI
ServidorRMI
ComponentesSustitutos Esqueleto
Capa de Referencias
remotas
Capa de Referencias
remotas
Capa de Transferencia
Capa de Transferencia
Conexión Virtual
Conexión a la red
Figura 4.2: Diagrama JAVA-RMI
4.4.2.6. Desventajas de CORBA
Complejidad inherente a la programacion CORBA
Tamano de los ejecutables
Protocolos de transmision binarios
4.5. JAVA-RMI
RMI (Remote Method Invokation) es una API del lenguaje de programacionJava para llamadas a procedimientos remotos. Este API permite la creacion deaplicaciones distribuidas a traves de llamadas a objetos Java remotos.
4.5.1. Arquitectura RMI
La arquitectura RMI se estructura en tres capas:
Componentes sustitutos (stubs)/esqueleto
Referencias remotas
Transporte
24 CAPITULO 4. CAPA DE TRANSPORTE
4.5.1.1. Componentes sustitutos o stubs
Los componentes sustitutos o stubs funcionan como representantes o proxiesdel objeto remoto en el lado del cliente local. El cliente invoca a un metodoen el stub que se encarga de realizar la llamada al metodo del objeto remoto ydevolver el resultado de la operacion.
4.5.1.2. Esqueleto
El esqueleto es el elemento que interacciona con la capa de referencias remo-tas del servidor. El esqueleto recibe las peticiones de llamadas a procedimientosremotos desde la capa de referencias remotas del cliente. Otra de las atribucionesdel esqueleto es realizar el unmarshalling de los argumentos, de la misma formarecibe los valores devueltos por el objeto remoto y realiza el marshalling antesde devolverlos al cliente que previamente realizo la llamada.
4.5.1.3. Capa de referencias remotas
La capa de referencias remotas proporciona un protocolo independiente dereferencias independiente de stubs y esqueletos.
4.5.1.4. Capa de Transferencia
La capa de transferencia se encarga de crear y establecer la comunicacionentre el cliente y el servidor. Se encuentra compuesta por cuatro elementos:
Punto final de la referencia del espacio de direccion
Canal
Conexion
Abstraccion del transporte
4.5.1.5. Ejemplo de interface Java-RMI
import java.rmi.*
public interface Calculadora extends java.rmi.Remote {// Calcula la raiz cuadrada de un numeropublic float raizCuadrada ( float numero )
throws RemoteException;
// Calcula la potencia de un numeropublic float potencia ( float base, float exponente)
throws RemoteException;};
4.5.2. Ventajas RMI
Orientado a Objetos
Eficiencia en el transporte de grandes cantidades de datos
4.6. DCOM 25
Patrones de diseno
Seguridad
Facilidad de uso y de implementacion
Multiplataforma
Recolector de basura distribuido
Conexion con sistemas legados
Bajo coste
4.5.3. Desventajas de RMI
Protocolo binario que no permite su paso a traves de los firewalls
Dependiente del lenguaje de programacion (Java)
Amenazas de seguridad a traves de la ejecucion de codigo remoto
4.6. DCOM
DCOM (Distributed COM) es una tecnologıa de objetos distribuidos propi-etaria de Microsoft. Se encuentra basada en la anterior tecnologıa COM (Com-ponent Object Model) utilizada para permitir la interoperacion de aplicacionesen sistemas Windows. Actualmente ha sido sustituida por la plataforma Mi-crosoft .NET.
DCOM se diseno para trabajar sobre diferentes protocolos de red incluyendolos protocolos utilizados en Internet como HTTP.
4.6.1. Arquitectura COM
La arquitectura COM se encuentra compuesta por los siguientes elementos:
Interface COM
Clase COM
Objeto COM
Servidor COM
Cliente COM
4.6.1.1. Interface COM
El interface COM se utiliza para publicar los metodos utilizados para accedera un objeto COM. Es equivalente a una clase abstracta.
26 CAPITULO 4. CAPA DE TRANSPORTE
Cliente COMRun-time
COMRun-time Cliente
MediosSeguridad
DCERPC
MediosSeguridad
DCERPC
PilaProtocolos
Protocolode RedDCOM
PilaProtocolos
Figura 4.3: Esquema de comunicaciones DCOM entre objetos COM en diferentesmaquinas
4.6.1.2. Clase COM
Una Clase COM representa la implementacion de uno o mas interfacesCOM. Encapsula el comportamiento asociado a los metodos y accede a laspropiedades identificadas en el interface de acceso COM. Las Clases COM seencuentran implementadas dentro de un Servidor COM.
4.6.1.3. Objetos COM
Los Objetos COM son instancias de Clases COM dentro de un servidorCOM. Un Objeto COM es accedido por un cliente COM a traves de un Interface.
4.6.1.4. Servidor COM
Un servidor COM proporciona las implementaciones de los interfaces a uncliente COM. Como hemos comentado en el apartado anterior un Objeto COMes una instancia de una clase COM contenida dentro de un servidor. Los Servi-dores COM tienen dos tipos de funcionamiento:
Independiente Implementados en ejecutables independientes
Dentro de otro proceso Normalmente implementados en DLL’s o en objetosActiveX
4.7. PLATAFORMA .NET 27
4.6.2. Ejemplo de un interface COM
interface DECLSPEC_UUID("{3F2504E0-4F89-11D3-9A0C-0305E82C3301}")ICalculadora:
public IUnknown{
virtual HRESULT raizCuadrada(float numero/*[in]*/,float *result/*[out]*/) = 0;
virtual HRESULT potencia(float base/*[in]*/,float exponente/*[in]*/,float *result/*[out]*/) = 0;
}
4.6.2.1. Ventajas
Ampliamente utilizado
Forma sencilla de interaccion entre programas en plataformas Windows
4.6.2.2. Inconvenientes
Actualmente ha sido reemplazado por la plataforma .NET
Escaso soporte en plataformas no Windows
Binarios no portables
Problemas de seguridad pueden tener acceso a la API de windows
Actualmente no tiene soporte para procesamiento en tiempo real
4.7. Plataforma .NET
.NET es un proyecto de Microsoft para la creacion de una plataforma dedesarrollo de software basada en RAD(Rapid Application Development), inde-pendencia de la plataforma y transparente a la red.
.NET se encuentra basado en una maquina virtual (CLI) y una librerıa declases estandar de la misma forma que la plataforma J2EE de Sun Microsystems.El codigo utilizado por la maquina virtual (MSIL) puede ser generado a partirde una gran cantidad de lenguajes de programacion entre los que se incluyenC++,C#,Visual Basic, ASP .NET o Fortran.
Existen numerosas similitudes entre la plataformas J2EE y .NET. Una delas principales similitudes es la ejecucion de sus propios bytecodes intermediospor medio de una maquina virtual.
A pesar de las caracterısticas comunes entre ambas existen diferencias sus-tanciales como la portabilidad entre diferentes sistemas operativos. J2EE seencuentra disponible para una gran cantidad de sistemas operativos y platafor-mas hardware mientras que .NET solo se encuentra disponible para plataformasWindows. Aunque Microsoft solo haya desarrollado .NET para su propio sistemaoperativo existen proyectos que proporcionan implementaciones de .NET para
28 CAPITULO 4. CAPA DE TRANSPORTE
otros sistemas. Los proyectos de migracion de .NET mas importantes son: Monoy Rotor.
4.8. JXTA
JXTA es un conjunto de protocolos disenados para proporcionar comunica-ciones P2P (peer to peer entre los dispositivos conectados a una red.
El proyecto JXTA arranco como un proyecto de investigacion en Sun Mi-crosystems con la finalidad de crear un direccionamiento del espacio P2P.
4.8.1. Objetivos de JXTA
Interoperabilidad
Independencia de la plataforma
Ubicuidad
4.8.1.1. Interoperabilidad
La mayor parte de las redes P2P actuales se encuentran disenadas con unproposito especıfico como mensajerıa instantanea, comparticion de ficheros, etc.De la misma manera cada uno de los desarrolladores de estas plataformas siguesus propios criterios a la hora de realizar su diseno e implementacion. Comoresultado de esta falta de unicidad en los criterios surge la incompatibilidadentre las distintas redes P2P. En este punto es donde aparece JXTA como unaplataforma de desarrollo comun para aplicaciones P2P que permita la interop-erabilidad entre las diferentes redes.
4.8.1.2. Independencia de la plataforma
Habitualmente los sistemas de intercambio de informacion a traves de P2Putilizan API’s vinculadas a un determinado sistema operativo o a un lenguajede programacion concreto. De esta forma, la migracion de dichos sistemas deintercambio a otros sistemas operativos implica una nueva codificacion.
El hecho de que los actuales sistemas P2P se encuentren tan ligados a una de-terminada plataforma disminuye de manera significativa la cantidad de clientespotenciales de las redes. Por esta razon el objetivo de JXTA es crear unaplataforma de intercambio P2P independiente tanto del lenguaje de progra-macion utilizado por el programador como del sistema operativo utilizado.
4.8.1.3. Ubicuidad
JXTA se diseno con la finalidad de poder ser implementado para cualquiertipo de dispositivo digital.
Gran parte de los sistemas P2P actuales se encuentran orientados a unaplataforma en concreto, normalmente hacia Microsoft Windows. Esto sin dudaalguna es planteamiento incorrecto debido a que no debemos restringir la uti-lizacion de nuestras redes a una arquitectura y sistema operativo en concreto,mas aun si tenemos en cuenta que el gran la gran proliferacion de este tipo de
4.9. JABBER 29
sistemas tendra lugar tanto en el entorno empresarial como en el de sistemasconsumibles de uso domestico.
JXTA proporciona un conjunto de protocolos para la creacion de aplicacionesdistribuidas utilizando un entorno P2P.
Otra de las ventajas del proyecto JXTA es que se su codigo se encuentraliberado bajo la licencia Apache Software License. Este tipo de licencia permitela modificacion y distribucion tanto del codigo fuente como de los binarios. Sepuede consultar el texto ıntegro de la licencia en la pagina : http://www.jxta.org/project/www/license.html
4.9. Jabber
Jabber es un conjunto de protocolos y tecnologıas XML que permiten elintercambio de mensajes, presencia, y otra informacion estructurada entre dosentidades practicamente en tiempo real. La primera aplicacion de Jabber es lamensajerıa instantanea de la misma forma que otros programas como Messengero ICQ. Recientemente, Jabber se ha convertido en un estandar del IETF.
Jabber se compone principalmente de dos protocolos: XMPP Core y XMPPIM. El primero es utilizado para el intercambio estructurado de informacion y elsegundo es una extension del primero para funciones de mensajerıa instantaneay funciones de presencia. Ademas de los dos protocolos principales, existe otroconjunto de protocolos denominados JEP (Jabber Enhancement Protocols) queaportan nuevas funcionalidades.
4.9.1. Ventajas de Jabber
Abierto
Estandar del IETF
Probado
Descentralizado
Seguro
Extensible
Flexible
Extendido
Gran cantidad de subprotocolos definidos para aplicaciones concretas
Codigo fuente abierto
4.9.2. Desventajas Jabber
Transferencia de informacion en modo texto lo que se traduce en unamenor eficiencia en la transmision de datos
Recomendable tener instalado nuestro propio servidor Jabber lo cual im-plicara costes de instalacion y mantenimiento
30 CAPITULO 4. CAPA DE TRANSPORTE
4.9.3. Arquitectura del sistema
El protocolo XMPP utiliza cuatro elementos fundamentales dentro de suarquitectura:
Servidores
Clientes
Gateways
Red
4.9.3.1. Servidores
Un servidor actua como una capa de abstraccion inteligente para las comu-nicaciones XMPP. Los cometidos principales de los servidores en Jabber son:
Gestionar conexiones hacia otras entidades o sesiones pertenecientes aotras entidades, en la forma de XML Streams desde o hacia clientes au-torizados, servidores u otras entidades
Enrutamiento de las stanzas XML entre las diferentes entidades sobre lasXML streams
4.9.3.2. Clientes
Los clientes en la mayor parte de las ocasiones se conectan a los servidoresa traves de una conexion TCP
4.9.3.3. Gateway
Es un servicio especial en el lado servidor cuya principal funcion es la detraducir el protocolo XMPP a otro sistema de mensajerıa instantanea.
4.9.4. Esquema de direccionamiento
Definiremos como entidad cualquier extremo de una red que pueda comuni-carse utilizando el protocolo XMPP. Todas las entidades se pueden direccionarde una forma unica compatible con el RFC 2396.
La direccion de una entidad Jabber se denomina JID. La notacion utilizadapara una JID expresada en ABNF es la siguiente:
jid = [ node "@" ] domain [ "/" resource ]domain = fqdn / address-literalfqdn = (sub-domain 1*("." sub-domain))sub-domain = ([IDNA] conformant domain label)address-literal = IPv4address / IPv6address
4.9. JABBER 31
4.9.4.1. Identificador de dominio
El identificador de dominio es el identificador principal de y el unico elementorequerido en un JID. Normalmente representa el gateway o el servidor principalal cual se conectan otras entidades para el enrutamiento XML y para la gestionde datos.
La entidad referenciada por un identificador de dominio no tiene que sernecesariamente un servidor, puede ser un servicio que se encuentra direccionadocomo un subdominio de un servidor que extiende la funcionalidad del servidor.
4.9.4.2. Identificador de nodo
El identificador de nodo es una cadena opcional situada antes del nombrede dominio y separada por una arroba (’@’), normalmente identifica la entidadque se comunica con el servidor o gateway.
4.9.4.3. Identificador de recurso
El identificador de recurso es una cadena opcional situada tras el identifi-cador de dominio y separada de este por el caracter ’/’. Normalmente representauna sesion especıfica o un objeto que pertenece a la entidad asociada con el iden-tificador de nodo.
4.9.5. Seguridad en Jabber (SASL)
XMPP incluye un metodo para la autentificacion de streams a traves deSASL(Simple Authentication and Security Layer). SASL proporciona un metodogeneralizado para el soporte de autentificacion para los protocolos orientados aconexion.
4.9.5.1. Ejemplo SASL
El cliente inicia un stream al servidor
<stream:streamxmlns=’jabber:client’xmlns:stream=’http://etherx.jabber.org/streams’to=’example.com’version=’1.0’>
El servidor responde al cliente
<stream:streamxmlns=’jabber:client’xmlns:stream=’http://etherx.jabber.org/streams’id=’c2s_234’from=’example.com’version=’1.0’>
32 CAPITULO 4. CAPA DE TRANSPORTE
IQ-get
IQ-res
Entidad 1 Entidad 2
IQ-set
IQ-res
Figura 4.4: Protocolo Input/Query
El servidor envıa los tipos de autentificacion disponibles al cliente
<stream:features><mechanisms xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism>
</mechanisms></stream:features>
El cliente selecciona el metodo de autentificacion
<auth xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’mechanism=’DIGEST-MD5’/>
4.9.6. Protocolo IQ (Input/Query)
Aunque el protocolo Jabber tiene una naturaleza asıncrona, tambien disponede una modelo peticion/respuesta que tiende a ser sıncrono aunque no garantizaque la respuesta suceda inmediatamente a la peticion. Este modelo peticionrespuesta recibe el nombre de Input/Query IQ abreviado.
El protocolo IQ proporciona muchas de las caracterısticas basicas de men-sajerıa instantanea de Jabber.
<iq type=’get’ from=’[email protected]/home’to=’[email protected]/Beetle’ id=’ver1’>
4.9. JABBER 33
<query xmlns=’jabber:iq:version’/></iq>
<iq type=’result’ to=’[email protected]/home’from=’[email protected]/Beetle’ id=’ver1’><query xmlns=’jabber:iq:version’><name>Jabber Instant Messenger</name><version>1.7.0.14</version><os>95 4.10</os>
</query></iq>
4.9.7. Servicio de busqueda
En nuestro caso particular, es necesario poseer un mecanismo de busqueda deservicios dentro de la red. Supongamos que deseamos saber que tipos de senalesestan siendo capturadas por un determinado equipo y que caracterısticas tienenestas senales.
Jabber posee un servicio de busqueda (JEP-0030 Service Discovery) para labusqueda de servicios en los diferentes nodos del sistema.
Supongamos que queremos averiguar que senales tiene mapeadas un equipo.En primer lugar debemos pedir todos los elementos que tiene mapeados.
<iq type=’get’from=’[email protected]/signals’to=’[email protected]’id=’items1’>
<query xmlns=’http://jabber.org/protocol/disco#items’/></iq>
Supongamos la siguiente respuesta:
<iq type=’result’from=’equipo2.isa.uniovi.es’to=’[email protected]/signals’id=’items1’>
<query xmlns=’http://jabber.org/protocol/disco#items’><item jid=’vibra-signal.equipo2.isa.uniovi.es’
name=’Vibraciones’/><item jid=’current-signal.equipo2.isa.uniovi.es’
name=’Corrientes’/></query>
</iq>
Vemos que dentro de equipo2.isa.uniovi.es tenemos mapeados dos tiposde senales : vibracion y corrientes. Una vez que hemos visto que tenemos senalesde vibracion podemos querer saber cuantas senales de vibracion tiene mapeadasese equipo. Para realizar esta consulta utilizaremos el siguiente mensaje:
<iq type=’get’from=’[email protected]/signals’
34 CAPITULO 4. CAPA DE TRANSPORTE
to=’vibra-signal.equipo2.isa.uniovi.es’id=’items2’>
<query xmlns=’http://jabber.org/protocol/disco#items’/></iq>
La respuesta podrıa ser:
<iq type=’result’from=’equipo2.isa.uniovi.es’to=’[email protected]/signals’id=’items2’>
<query xmlns=’http://jabber.org/protocol/disco#items’><item jid=’vibra-signal.equipo2.isa.uniovi.es’
node=’acelerometro1’name=’Senial del acelerometro 1’/>
<item jid=’vibra-signal.equipo2.isa.uniovi.es’node=’acelerometro2’name=’Senial del acelerometro 2’/>
<item jid=’vibra-signal.equipo2.isa.uniovi.es’node=’acelerometro3’name=’Senial del acelerometro 3’/>
</query></iq>
<iq type=’get’from=’[email protected]/signals’to=’vibra-signal.equipo2.isa.uniovi.es’id=’items3’>
<query xmlns=’http://jabber.org/protocol/disco#items’ node=’acelerometro1’/></iq>
<iq type=’result’from=’equipo2.isa.uniovi.es’to=’[email protected]/signals’id=’items3’>
<query xmlns=’http://jabber.org/protocol/disco#items node=’acelerometro1’><item jid=’vibra-signal.equipo2.isa.uniovi.es’
node=’acelerometro1/sensibilidad’name=’Sensibilidad voltios/g’/>
<item jid=’vibra-signal.equipo2.isa.uniovi.es’node=’acelerometro1/resfrec’name=’Respuesta en frecuencia’/>
<item jid=’vibra-signal.equipo2.isa.uniovi.es’node=’acelerometro1/limmax’name=’Limite maximo de medida’/>
</query></iq>
4.9.8. Envıo de datos
El envıo de datos entre los elementos debe ser eficiente, ya que nuestro sis-tema va a utilizarlo de forma masiva. Jabber dispone de un protocolo(JEP-0095)
4.9. JABBER 35
para la transmision de streams que puede servirnos para nuestro proposito. Acontinuacion, se muestran una peticion de iniciacion de streams y la aceptacionde la propuesta anterior.
<iq type=’set’ id=’offer1’ to=’[email protected]/resource’><si xmlns=’http://jabber.org/protocol/si’
id=’a0’mime-type=’binary/octet-stream’profile=’http://jabber.org/protocol/si/profile/file-transfer’>
<file xmlns=’http://jabber.org/protocol/si/profile/file-transfer’><info>This is info</info><flag/>
</file><feature xmlns=’http://jabber.org/protocol/feature-neg’><x xmlns=’jabber:x:data’ type=’form’><field var=’stream-method’ type=’list-single’><option><value>http://jabber.org/protocol/bytestreams</value></option><option><value>jabber:iq:oob</value></option><option><value>http://jabber.org/protocol/ibb</value></option>
</field></x>
</feature></si>
</iq>
<iq type=’result’ to=’[email protected]/resource’ id=’offer1’><si xmlns=’http://jabber.org/protocol/si’><feature xmlns=’http://jabber.org/protocol/feature-neg’><x xmlns=’jabber:x:data’ type=’submit’><field var=’stream-method’><value>http://jabber.org/protocol/bytestreams</value>
</field></x>
</feature></si>
</iq>
4.9.9. Servicio de transmision de ficheros
Nuestro sistema tambien necesitara un servicio de transmision de ficheros.Jabber dispone de un protocolo para la transmision de ficheros, que se encuentradescrito en el JEP-0096. JEP-0096 nacio para mejorar la transmision de ficherosdescrita en el antiguo protocolo Out-of-Band Data que contaba con problemascomo la falta de fiabilidad.
<iq type=’set’ id=’offer1’ to=’[email protected]/resource’><si xmlns=’http://jabber.org/protocol/si’
id=’a0’mime-type=’text/plain’profile=’http://jabber.org/protocol/si/profile/file-transfer’>
<file xmlns=’http://jabber.org/protocol/si/profile/file-transfer’
36 CAPITULO 4. CAPA DE TRANSPORTE
name=’test.txt’size=’1022’hash=’552da749930852c69ae5d2141d3766b1’date=’1969-07-21T02:56:15Z’/>
<feature xmlns=’http://jabber.org/protocol/feature-neg’><x xmlns=’jabber:x:data’ type=’form’><field var=’stream-method’ type=’list-single’><option><value>http://jabber.org/protocol/bytestreams</value></option><option><value>http://jabber.org/protocol/ibb</value></option>
</field></x>
</feature></si>
</iq>
<iq type=’result’ to=’[email protected]/resource’ id=’offer1’><si xmlns=’http://jabber.org/protocol/si’><file xmlns=’http://jabber.org/protocol/si/profile/file-transfer’><range offset=’252’ length=’179’/>
</file><feature xmlns=’http://jabber.org/protocol/feature-neg’><x xmlns=’jabber:x:data’ type=’submit’><field var=’stream-method’><value>http://jabber.org/protocol/bytestreams</value>
</field></x>
</feature></si>
</iq>
En primer lugar, se necesita saber si el protocolo se encuentra soportado porlas dos partes:
<iq type=’get’to=’equipo2.isa.uniovi.es’from=’[email protected]/signals’id=’info1’>
<query xmlns=’http://jabber.org/protocol/disco#info’/></iq>
<iq type=’result’to=’[email protected]/signals’from=’equipo2.isa.uniovi.es’id=’info1’>
<query xmlns=’http://jabber.org/protocol/disco#info’>...<feature var=’http://jabber.org/protocol/si’/><feature var=’http://jabber.org/protocol/si/profile/file-transfer’/>...
</query></iq>
4.9. JABBER 37
4.9.10. Servicio de transmision de ficheros
El servicio de transmision de ficheros descrito JEP-0096 mejora la trans-mision de ficheros descrita en protocolo Out-of-Band Data. El protocolo uti-lizado con anterioridad contaba con varios problemas como eran la falta defiabilidad, la transmision de ficheros
4.9.11. Servicio de localizacion geografica
El servicio de localizacion geografica descrito en el JEP-0080 de Jabber so-porta la transmision de datos relativos a la localizacion geografica de cada unode los clientes en una red Jabber. La incorporacion de este servicio a nuestrosistema permitira conocer la posicion geografica de cada uno de los elementosindustriales monitorizados lo cual puede ser muy util para su mantenimiento encaso de detectarse anomalıas en su funcionamiento.
Peticion de localizacion geografica
<iq type=’get’id=’loc_1’from=’[email protected]/balcony’to=’[email protected]/garden’>
<geoloc xmlns=’http://jabber.org/protocol/geoloc’/></iq>
Respuesta de localizacion geografica
<iq type=’result’id=’loc_1’to=’[email protected]/balcony’from=’[email protected]/garden’>
<geoloc xmlns=’http://jabber.org/protocol/geoloc’><description>Verona</description><lat>45.45</lat><lon>11.00</lon>
</geoloc></iq>
4.9.12. Servicio de RPC(Remote Procedure Calls)
Existen varias formas de transporte de XML-RPC utilizando Jabber, una deellas es Jabber-RPC. Jabber-RPC (JEP-0009) transporta las peticiones XML-RPC dentro de la carga util del query.
<iq type=’set’ to=’[email protected]/jrpc-server’ id=’1’><query xmlns=’jabber:iq:rpc’><methodCall><methodName>examples.getStateName</methodName><params><param><value><i4>6</i4></value>
38 CAPITULO 4. CAPA DE TRANSPORTE
</param></params>
</methodCall></query>
</iq>
<iq type=’result’ to=’[email protected]/jrpc-client’from=’[email protected]/jrpc-server’ id=’1’>
<query xmlns=’jabber:iq:rpc’><methodResponse><params><param><value><string>Colorado</string></value>
</param></params>
</methodResponse></query>
</iq>
4.9.13. Utilizacion de Jabber como Middleware
En nuestro proyecto utilizaremos como middleware el protocolo de comuni-caciones Jabber ya que nos permite implementar de una forma rapida y sencillala capa de comunicaciones entre los diferentes elementos de nuestro sistema.
Existe en la actualidad un proyecto denominado JAM (Jabber As Middle-ware) que promueve la utilizacion del protocolo Jabber en entornos A2A (Ap-plication To Application)
4.9.14. Requisitos de la capa de transporte
Una vez se han comentado las diferentes alternativas para la implementacionde la capa de transporte, comentaremos los requisitos del sistema para posteri-ormente seleccionar una tecnologıa.
En el diseno de la capa de transporte de nuestro sistema se han definido unconjunto de parametros entre los que se encuentran :
Proporcionar un mecanismo de intercambio de datos entre la capa demonitorizacion y la capa de aplicacion
Utilizacion de una tecnologıa orientada a objetos distribuida
Facilidad de implementacion
Tecnologıa basada de estandares abiertos
Escalabilidad
4.10. Alternativa Seleccionada (Jabber)
Finalmente tras evaluar todas las opciones expuestas con anterioridad se hadecidido utilizar Jabber en la implementacion de la capa de transporte. Lasrazones para esta eleccion han sido las siguientes:
4.10. ALTERNATIVA SELECCIONADA (JABBER) 39
Basado en estandares abiertos de Internet
Existencia de software libre para la programacion
Facilidad de aprendizaje
Independencia del lenguaje de programacion
Protocolos extensibles
4.10.1. Estandares abiertos de Internet
Los siguientes protocolos de Jabber han sido aceptados como estandar delIETF (Internet Engineering Task Force)
draft-ietf-xmpp-core-24
draft-ietf-xmpp-im-22
draft-ietf-xmpp-cpim-05
4.10.2. Software Libre para Jabber
Al encontrarse basado en un conjunto de protocolos abiertos existen nu-merosas aplicaciones y utilidades para Jabber con diferentes tipos de licenciaslibres como LPGL, GPL, Apache, JOSL, BSD, etc.
4.10.3. Facilidad de aprendizaje
Jabber esta descrito en XML, lo cual implica que todos sus protocolos decomunicaciones estan descritos en texto plano. Esto facilita en gran manera lacomprension tanto de los protocolos como de los flujos de datos.
4.10.4. Independencia del lenguaje de programacion
Como hemos comentado en el apartado anterior Jabber se encuentra de-scrito en XML lo cual nos permite la creacion de mensajes Jabber simplementegenerando cadenas de texto. Por lo tanto, podremos generar mensajes Jab-ber practicamente desde cualquier lenguaje de programacion. Obviamente estaaproximacion no es la mas correcta ya no nos permitirıa validar el codigo XMLgenerado y la generacion de los mensajes serıa bastante laboriosa.
Para evitar el proceso de generacion directa de mensajes Jabber existe unconjunto de librerıas tanto comerciales como libres que permiten la generacion demensajes Jabber desde una gran cantidad de lenguajes de programacion http://www.jabber.org/software/libraries.php como C++, C#, PHP, Python,Ruby, Java, Delphi, Tcl, Perl, Flash, etc.
4.10.5. Protocolos extensibles
Al ser un conjunto de estandares abiertos, los protocolos Jabber se encuen-tran en continua evolucion. De la misma forma, paulatinamente van apare-ciendo nuevos subprotocolos para satisfacer necesidades en algunos marcos deaplicacion especıficos.
40 CAPITULO 4. CAPA DE TRANSPORTE
TRABAJO DE INVESTIGACION. 41
CAPITULO 5
Capa de aplicacion
La capa de aplicacion engloba el conjunto de operaciones de tratamiento yalmacenamiento de los datos obtenidos en la monitorizacion ası como la conec-tividad con otros sistemas.
Los objetivos de la capa de aplicacion son los siguientes:
Tratamiento matematico y preparacion de datos
Interface de conexion con otros sistemas
Implementacion de tecnicas de almacenamiento de datos
Gran parte de las funcionalidades de la capa de aplicacion se encuentranenglobadas dentro del proyecto Mithril, otras se implementaran como modulosde nuestro sistema de monitorizacion.
Los modulos con los que contara la capa de aplicacion son los siguientes:
Modulos de procesamiento de datos
Modulo de almacenamiento persistente de datos
Modulo de interface con otros sistemas
Modulo de enlace de la capa de aplicacion con la capa de presentacion
5.1. Modulos de procesamiento de datos
En un sistema de monitorizacion es fundamental la existencia de un modulode procesamiento de datos ya que la informacion recolectada a traves de lossensores no suelen ser util sin haber sido procesados con anterioridad.
Si por ejemplo, nuestro sistema de monitorizacion alimenta otro sistema deestimacion basado en redes neuronales sera necesario realizar una preparacionde datos. En esta preparacion de datos se utilizaran tecnicas de filtrado como
42 CAPITULO 5. CAPA DE APLICACION
pueden ser la eliminacion de datos que se encuentren desviados un porcentajedeterminado tanto por encima como por debajo de la media. Una vez se harealizado el filtrado de datos serıa necesaria la normalizacion de los mismospara lo cual se deben de realizar previamente calculos estadısticos tales comomedias, desviaciones tıpicas, etc.
Con el objeto de aportar las funcionalidades anteriormente comentadas sedispondra de dos modulos, uno existente dentro del Mithril y otro independienteimplementado sobre un servidor de aplicaciones al mismo nivel que los demasmodulos que comentaremos con posterioridad.
5.1.1. Modulo de procesamiento y almacenamiento de datosMithril
Mithril ademas de proporcionar el sistema de captura de datos, contiene unconjunto de funciones para el procesamiento y almacenamiento de los mismos.Entre las funciones de procesamiento se encuentran transformadas de Fourier,tratamiento estadıstico de datos, datamining, etc. Mithril posee ademas soportepara el almacenamiento de informacion multiples Sistemas de Gestion de Basesde Datos.
5.1.2. Modulo de procesamiento de datos
Aunque se posea de un sistema de procesamiento de datos en Mithril puedeser interesante la existencia de un modulo independiente de operaciones matematicaspara el tratamiento de datos. Bien por no sobrecargar los PC que contienen elsistema de captura o por extender las funcionalidades del modulo de proce-samiento de Mithril.
5.2. Modulo de almacenamiento persistente dedatos
Otra de las caracterısticas fundamentales de un sistema de monitorizaciones el almacenamiento persistente de datos. No cabe duda que la monitorizacionon-line es muy importante pero pueden darse ocasiones en las cuales sea nece-saria una comparativa de datos para determinar la evolucion del sistema a lolargo del tiempo. Para ello, es necesario disponer de un modulo que de man-era independiente nos permita una primera instancia almacenar los datos paraposteriormente poder recuperarlos de manera eficiente.
Dentro los sistemas de almacenamiento persistente podemos encontrar dostipos fundamentales de aproximaciones :
Volcado de datos a fichero
Volcado de datos en cinta
Utilizacion de un S.G.B.D.
5.2. MODULO DE ALMACENAMIENTO PERSISTENTE DE DATOS 43
5.2.1. Volcado de datos a fichero
El volcado de datos a fichero se ha venido utilizando a lo largo de los anoscomo uno de los principales recursos de almacenamiento de datos. Normalmenteeste volcado viene a ser secuencial, por lo que si no disponemos de un conjunto deındices para acceder directamente a los datos deberemos realizar una busquedasecuencial dentro de dicho fichero para recuperar un determinado conjunto deinformacion. Este recorrido secuencial influira negativamente en el rendimientodel sistema.
5.2.2. Volcado de datos en cinta
Los sistemas de almacenamiento en cinta son uno de los metodos tradi-cionales para la realizacion de copias de seguridad en sistemas informaticosactualmente se encuentran un poco en desuso pero siguen siendo validas parael almacenamiento de grandes cantidades de informacion.
Los sistemas de almacenamiento de datos en cinta tiene un gran inconve-niente a la hora de la recuperacion de datos ya que unicamente nos permitenrealizar la recuperacion de manera secuencial con el consiguiente coste temporal.Aunque las cintas posean una gran capacidad, en algun momento si nuestro sis-tema de captura funciona de manera continuada la cinta terminara por llenarselo cual nos generara una situacion problematica. Por otra parte, proporcionangran cantidad de almacenamiento a precios economicos por lo que pueden serutilizados como un sistema de almacenamiento secundario o de respaldo.
5.2.3. Utilizacion de un S.G.B.D.
Los Sistemas de Gestion de Bases de Datos se encuentran implantados en casitodos los entornos con soluciones que van desde Microsoft Access para entornosdomesticos o de pequena empresa hasta sistemas como Oracle o DB2 de IBMorientados a la gran empresa.
Los sistemas de gestion de bases de datos proporcionan un conjunto de car-acterısticas que aventaja mucho a la utilizacion de simples ficheros de texto.
Una de los problemas con los que nos podemos encontrar a la hora de lautilizacion de un S.G.B.D. en un sistema de adquisicion de datos es la frecuenciade muestreo. Si la cantidad de datos generada por el subsistema de captura esmuy elevada podemos tener problemas a la hora de la insercion de la informacionen base de datos. En este caso, serıa conveniente realizar un preprocesado dedatos donde se eliminen todos aquellos datos que no sean relevantes.
INCLUIR EL ARTICULO DEL IECONPara un sistema de monitorizacion remota la frecuencia de muestreo tampoco
necesita ser excesivamente alta ya que la capacidad de percepcion de datos deloperador no lograra saturar el sistema de gestion de bases de datos.
5.2.4. Alternativa seleccionada
La alternativa mas recomendable es la utilizacion de un sistema de gestionde bases de datos. Las razones fundamentales son :
Facilidad en la recuperacion de datos
44 CAPITULO 5. CAPA DE APLICACION
Robustez
Gran variedad de S.G.B.D. tanto de software libre como propietario
Como hemos comentado anteriormente, los S.G.B.D. en casos extremos po-drıan no ser capaces de realizar las inserciones de los datos proporcionados porel sistema de captura.
5.3. Modulo de interface con otros sistemas
En numerosas ocasiones, la salida proporcionada por un sistema de moni-torizacion puede utilizarse como entrada de otros sistemas. Para realizar estaintegracion es necesario, que nuestro sistema proporcione un interfaz.
En la actualidad la integracion de sistemas (EAI Enterprise ApplicationIntegration) se suele realizar traves de sistemas propietarios aunque tal y como seexpresa en [?] y en [?] los servicios web representan cada vez mas una alternativareal.
Los servicios web representan una gran ventaja con respecto a los sistemaspropietarios debido a que se encuentran basado en estandares del W3C www.w3c.org, pueden implementarse utilizando software libre y tienen una curva deaprendizaje poco pronunciada.
MEJORAR LA REDACCION Y EXPANDIR EL CONTENIDO CON LOSARTICULOS DEL IEEE
Los servicios web se encuentran fuertemente ligados a las siguientes tec-nologıas:
WSDL (Web Services Definition Language)
UDDI (Universal Description, Description and Integration)
SOAP (Simple Object Application Protocol)
XML (eXtensible Markup Language)
Protocolo de transporte (HTTP,SMTP,TCP/IP)
5.3.1. Ventajas de los servicios web
Los servicios web proporcionan interoperabilidad entre diferentes aplica-ciones software corriendo en distintas plataformas
Los servicios web soportan estandares y protocolos abiertos. Los protocolosy los formatos de datos se encuentran basados en texto donde es factible,facilitando la tarea de los desarrolladores y la comprension de su modo defuncionamiento
Los servicios web sobre HTTP pueden funcionar a traves de muchas me-didas de seguridad de los cortafuegos sin necesidad de modificar las reglasde filtrado.
5.3. MODULO DE INTERFACE CON OTROS SISTEMAS 45
5.3.2. Inconvenientes de los servicios web
Los estandares de servicios web para algunas caracterısticas como seguri-dad y transacciones no existen o se encuentran en el comienzo de su fase dedesarrollo en comparacion con otros protocolos abiertos de computaciondistribuida como CORBA.
Los servicios web tienen un bajo rendimiento comparados con otras aprox-imaciones de computacion distribuida como RMI, CORBA o DCOM. Estorepresenta una solucion de compromiso cuando se eligen protocolos basa-dos en texto. XML no se diseno pensando en ser conciso en su codificacionni en su eficiencia al analizarse.
Utilizando como protocolo de transporte HTTP, los servicios web puedenevitar las medidas de seguridad existentes en los cortafuegos cuya misiones la de bloquear o auditar las comunicaciones entre programas en amboslados del cortafuegos.
5.3.3. Modo de funcionamiento
Los servicios web se utilizan a traves de un servidor de aplicaciones. Unservidor de aplicaciones es una computadora instalada dentro de una red quesirve como soporte para la ejecucion de ciertas aplicaciones software. Un ejemplotıpico de servidor aplicaciones puede ser el servidor Jakarta http://jakarta.apache.org
5.3.4. Protocolos utilizados por los servicios web
5.3.4.1. WSDL (Web Services Definition Language)
Es un formato XML para la descripcion de servicios web. Las operacionessoportadas y los mensajes se describen de forma abstracta y despues se espe-cializan para un protocolo de red y un formato de mensaje.
5.3.4.2. SOAP (Simple Object Access Protocol)
Es un protocolo basado en XML para el intercambio de mensajes entre apli-caciones software. SOAP puede utilizar como protocolo de transporte cualquierade los protocolos utilizados comunmente en Internet pero en la mayor parte delas aplicaciones se utiliza sobre HTTP.
Estructura de un mensaje SOAP Un mensaje SOAP se divide en dospartes:
http://www.w3.org/TR/soap12-part0/
Cabecera (Head)
Cuerpo (Body)
La cabecera contiene meta-informacion relativa al enrutamiento, seguridady transacciones. El cuerpo sin embargo contiene el grueso de la informacion atransmitir.
46 CAPITULO 5. CAPA DE APLICACION
CABECERA SOAP
CUERPO SOAP
ENVOLTURA SOAP
Figura 5.1: Esquema de un mensaje SOAP
5.3.4.3. UDDI (Universal Description, Discovery and Integration)
Es un registro independiente basado en XML de servicios web a nivel mundi-al. UDDI se encuentra patrocinado por OASIS http://www.oasis-open.org.
El registro UDDI contiene tres componentes :
Paginas Blancas
Paginas Amarillas
Paginas Verdes
UDDI es uno de los estandares principales relacionados con los servicios web,ha sido disenado para ser accedido a traves de SOAP y proporcionar acceso alos documentos WSDL que describen los formatos de mensaje necesarios parainteractuar con los servicios web que se encuentran en el registro.
5.3.5. Ejemplos de servicios web
El siguiente ejemplo expuesto en [?] muestra el conjunto de peticion, re-spuesta y definicion de un servicio web relativo a tablas de snowboard.
<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Header><m:Trans xmlns:m="http://www.w3schools.com/transaction/" SOAP-ENV:mustUnderstand="1">234</m:Trans>
5.3. MODULO DE INTERFACE CON OTROS SISTEMAS 47
</SOAP-ENV:Header><SOAP-ENV:Body><m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com"><manufacturer>K2</manufacturer><model>Fatbob</model>
</m:GetEndorsingBoarder></SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com"><endorsingBoarder>Chris Englesmann</endorsingBoarder>
</m:GetEndorsingBoarderResponse></SOAP-ENV:Body>
</SOAP-ENV:Envelope>
WSDL description
<?xml version="1.0"?>
<!-- root element wsdl:definitions defines set of related services--> <wsdl:definitions name="EndorsementSearch"targetNamespace="http://namespaces.snowboard-info.com"xmlns:es="http://www.snowboard-info.com/EndorsementSearch.wsdl"xmlns:esxsd="http://schemas.snowboard-info.com/EndorsementSearch.xsd"xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<!-- wsdl:types encapsulates schema definitions of communication types; here using xsd --><wsdl:types>
<!-- all type declarations are in a chunk of xsd --><xsd:schema targetNamespace="http://namespaces.snowboard-info.com"xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<!-- xsd definition: GetEndorsingBoarder [manufacturer string, model string] --><xsd:element name="GetEndorsingBoarder">
<xsd:complexType><xsd:sequence><xsd:element name="manufacturer" type="string"/>
<xsd:element name="model" type="string"/></xsd:sequence>
</xsd:complexType></xsd:element>
<!-- xsd definition: GetEndorsingBoarderResponse [... endorsingBoarder string ...] --><xsd:element name="GetEndorsingBoarderResponse">
48 CAPITULO 5. CAPA DE APLICACION
<xsd:complexType><xsd:all><xsd:element name="endorsingBoarder" type="string"/>
</xsd:all></xsd:complexType></xsd:element>
<!-- xsd definition: GetEndorsingBoarderFault [... errorMessage string ...] --><xsd:element name="GetEndorsingBoarderFault">
<xsd:complexType><xsd:all><xsd:element name="errorMessage" type="string"/>
</xsd:all></xsd:complexType></xsd:element>
</xsd:schema></wsdl:types>
<!-- wsdl:message elements describe potential transactions -->
<!-- request GetEndorsingBoarderRequest is of type GetEndorsingBoarder --><wsdl:message name="GetEndorsingBoarderRequest"><wsdl:part name="body" element="esxsd:GetEndorsingBoarder"/>
</wsdl:message>
<!-- response GetEndorsingBoarderResponse is of type GetEndorsingBoarderResponse --><wsdl:message name="GetEndorsingBoarderResponse"><wsdl:part name="body" element="esxsd:GetEndorsingBoarderResponse"/>
</wsdl:message>
<!-- wsdl:portType describes messages in an operation --><wsdl:portType name="GetEndorsingBoarderPortType">
<!-- the value of wsdl:operation eludes me --><wsdl:operation name="GetEndorsingBoarder"><wsdl:input message="es:GetEndorsingBoarderRequest"/><wsdl:output message="es:GetEndorsingBoarderResponse"/><wsdl:fault message="es:GetEndorsingBoarderFault"/>
</wsdl:operation></wsdl:portType>
<!-- wsdl:binding states a serialization protocol for this service --><wsdl:binding name="EndorsementSearchSoapBinding"
type="es:GetEndorsingBoarderPortType">
<!-- leverage off soap:binding document style @@@(no wsdl:foo pointing at the soap binding) --><soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
5.4. IMPLEMENTACION DE LOS MODULOS DE PROCESAMIENTO DE DATOS49
<!-- semi-opaque container of network transport details classed by soap:binding above @@@ --><wsdl:operation name="GetEndorsingBoarder">
<!-- again bind to SOAP? @@@ --><soap:operation soapAction="http://www.snowboard-info.com/EndorsementSearch"/>
<!-- furthur specify that the messages in the wsdl:operation "GetEndorsingBoarder" use SOAP? @@@ --><wsdl:input><soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/></wsdl:input><wsdl:output><soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/></wsdl:output><wsdl:fault><soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/></wsdl:fault>
</wsdl:operation></wsdl:binding>
<!-- wsdl:service names a new service "EndorsementSearchService" --><wsdl:service name="EndorsementSearchService"><wsdl:documentation>snowboarding-info.com Endorsement Service</wsdl:documentation>
<!-- connect it to the binding "EndorsementSearchSoapBinding" above --><wsdl:port name="GetEndorsingBoarderPort"
binding="es:EndorsementSearchSoapBinding">
<!-- give the binding an network address --><soap:address location="http://www.snowboard-info.com/EndorsementSearch"/>
</wsdl:port></wsdl:service>
</wsdl:definitions>
Una de las ventajas que proporciona WSDL es que permite la generaciondinamica de servidores de servicios web a partir de su definicion. Existen nu-merosas implementaciones para gran cantidada de lenguajes de programaciony de sistemas operativos. Una de ellas es el paquete PEAR::SOAP programadoen PHP y disponible en [?].
5.4. Implementacion de los modulos de proce-samiento de datos
Los modulos de procesamiento de datos, como hemos comentado anterior-mente, extienden o anaden funcionalidades existentes al sistema Mithril.
Una de las alternativas mas interesantes serıa implementar estos modulos
50 CAPITULO 5. CAPA DE APLICACION
dentro de un servidor de aplicaciones que contuviese tambien la capa de pre-sentacion.
Este enfoque nos proporciona varias ventajas:
Permite la ejecucion de los modulos de la capa de aplicacion y de la capade presentacion dentro de un mismo entorno
Facilidad de implementacion de los diferentes modulos (servicios web,procesamiento de datos, etc.)
Sencillez en la instalacion de los diferentes modulos
5.5. Seguridad en la capa de aplicacion
En esta seccion comentaremos los diferentes protocolos existentes para la im-plementacion de la seguridad en la capa de aplicacion. Nos centraremos basica-mente en la implementacion de la seguridad en las comunicaciones ya que rep-resentan el punto mas debil.
5.5.1. Seguridad en XML
Como hemos comentado anteriormente, los servicios web se encuentran basa-dos en el lenguaje de marcado XML, por lo que parece logico realizar una revisionde los diferentes protocolos existentes para la implementacion de la seguridaden el formato XML.
5.5.1.1. XML DSig
Las firmas digitales proporcionan una prueba de integridad de los datos a lavez que nos proporcionan una garantıa de no repudio ya que los datos han sidofirmados con la clave privada del creador.
XML DSig se diferencia de otros protocolos de cifrado de mensajes debido aque permite realizar la firma digital de partes de un documento XML en vez deobligar a firmar digitalmente el documento completo. Otra de las caracterısticasdiferenciales es que permite que dos documentos que difieran ligeramente en sucontenido, por ejemplo que contengan diferentes espacios en blanco generen elmismo resumen y puedan ser ası autentificados.
5.5.1.2. XML Enc
La especificacion XML Encryption Syntax and Processing define un vocab-ulario y unas reglas de procesamiento para proteger la confidencialidad de doc-umentos XML parcial o totalmente y tambien de datos no XML. La salida delproceso de la encriptacion es un documento XML bien formado por lo que puedeser procesado con posterioridad.
5.5.1.3. SAML
SAML es un protocolo para el intercambio de informacion de autentificaciony autorizacion. Las peticiones, respuestas y sentencias (aserciones) se encuen-tran codificadas en XML , SAML tambien utiliza los espacios de nombres XML.Normalmente las estructuras SAML se encuentran embebidas en codigo XML.
5.5. SEGURIDAD EN LA CAPA DE APLICACION 51
SAML asegura la interoperabilidad entre diferentes sistemas de seguridadproporcionando un marco para la transaccion segura de comercio electronicoentre empresas.
5.5.1.4. XACML
XACML es un lenguaje para polıticas de control de acceso basadas en XML.XACML expresa y comunica las reglas y polıticas que un mecanismo de controlde acceso usa para determinar el acceso a un conjunto de sujetos o atributos.
XACML proporciona un control de granularidad fina sobre actividades basadasen diversos criterios entre los que se encuentran :
Atributos del usuarios que requiere acceso
El protocolo sobre el cual se ha hecho la peticion
El mecanismo de autenticacion
5.5.1.5. XrML
Es una especificacion XML destinada a la especificacion y gestion de derechosy condiciones asociadas a todos los tipos de recursos incluyendo servicios ycontenidos digitales. XrML en su version 2.0 es completamente compatible conespacios de nombres XML utilizando Schemas XML.
5.5.1.6. XML Key Management Specification
XKMS proporciona un conjunto de protocolos para la distribucion y registrode claves publicas susceptibles de ser utilizadas junto con protocolos como XMLDSig y XML Enc. La sintaxis de los mensajes de XKMS se encuentra basadaen SOAP y WSDL.
XKMS comprende dos subprotocolos :
XML Key Information Service Specification
XML Key Registration Service Specification
5.5.2. Seguridad en Servicios Web
Una vez que hemos realizado una revision a la implementacion de la se-guridad en el formato XML en el cual se basan los servicios web expondremosel protocolo WS-SEC para la implementacion de la segurodad en los propiosservicios web.
5.5.2.1. WS-Security
WS-Security describe las mejoras a aplicar al protocolo SOAP para la integri-dad, autentificacion y confidencialidad. WS-Security ademas incluye un mecan-ismo para la asociacion de tokens de seguridad al mensaje.
WS-Security proporciona tres mecanismos:
propagacion de tokens de seguridad
52 CAPITULO 5. CAPA DE APLICACION
integridad del mensaje
confidencialidad del mensaje
Requerimientos
Multiples tokens de seguridad para autenticacion o autorizacion
Multiples dominios de confianza
Multiples tecnologıas de encriptacion
Seguridad de mensaje punto a punto y unicamente seguridad a nivel detransporte
TRABAJO DE INVESTIGACION. 53
CAPITULO 6
Capa de presentacion
La capa de presentacion proporciona el interfaz para que el usuario interactuecon el sistema de monitorizacion y de este modo lleve a cabo la supervision delproceso industrial. Tal y como hemos comentado en el capıtulo de introduccionse intentara crear un interfaz similar al del proyecto Ganglia http://ganglia.sourceforge.net. Es interesante recordar este ejemplo, ya que tanto nuestroproyecto como Ganglia se encuentran orientados a la monitorizacion remota.
6.1. Interfaz web
La monitorizacion via web es una forma muy interesante desde el punto devista operativo ya que, como comentaremos a continuacion, aporta numerosasventajas frente a otras formas de monitorizacion aunque tambien nos aportaotra serie de retos e inconvenientes.
6.1.1. Ventajas
No es necesario instalar software en el cliente
Puede ser accesible desde cualquier punto con acceso a Internet
Permite la posibilidad de conexion de multiples dispositivos con diversasarquitecturas de una manera transparente
Sencillo de manejar
Supongamos un caso en el cual se desean monitorizar un conjunto de mo-tores dispersos a lo largo de una nave industrial, serıa muy util poder utilizaruna PDA con conexion a Internet para poder monitorizar en cada momento elfuncionamiento de cada uno de ellos al tiempo que pueden estar siendo moni-torizados desde el centro de control.
54 CAPITULO 6. CAPA DE PRESENTACION
Si en vez de utilizar la web para la monitorizacion utilizasemos un cliente encada maquina deberıamos desarrollar diferentes aplicaciones para cada uno delos dispositivos con los consiguientes costes de desarrollo asociados.
6.1.2. Inconvenientes
Falta de interactividad, las paginas no pueden ser refrescadas desde elservidor unicamente a traves de peticiones del cliente
Pobreza de elementos de representacion
6.2. Mejoras a HTML
Uno de los principales problemas del interfaz web es la falta de expresividaddel lenguaje HTML. Inicialmente HTML no fue concebido para la generacion decontenidos dinamicos ni para la creacion de complicados interfaces. A lo largode los anos, se han realizado extensiones del protocolo HTML y han aparecidonuevos lenguajes afines(CSS, Javascript) que mejoran las capacidades inicialesde HTML.
A pesar de todo esto, HTML y sus extensiones limitan bastante el disenode interfaces, por lo que nuestro sistema incorporara tecnologıas de objetosembebidos en el HTML tales como Flash o applets Java.
La incorporacion de estos elementos externos y de algunas caracterısticasavanzadas de HTML puede provocar incompatibilidades con los navegadoresinstalados en algunos dispositivos. Debido a este problema, se crearan dos ver-siones del interfaz:
Basica
Avanzada
6.2.1. Interfaz basico
El interfaz basico esta orientado a aquellos clientes que posean un limita-do ancho de banda en su conexion o dispositivos que no soporten otras tec-nologıas en sus navegadores a parte de HTML. Se encontrara construido conun subconjunto de HTML que permita su visualizacion en un variado conjuntonavegadores disponibles para un amplio conjunto de dispositivos.
6.2.2. Interfaz Avanzado
El interfaz avanzado intentara paliar la falta de expresividad del lengua-je HTML utilizando elementos externos como applets Java o Flash. Esto nospermitira anadir efectos graficos y un conjunto de atractivas funcionalidadesvisuales a la hora de crear los interfaces de usuario.
6.3. Estructura de la capa de presentacion
La estructura de la presentacion de datos en el servidor web estarıa basadaen un modelo de capas.
6.3. ESTRUCTURA DE LA CAPA DE PRESENTACION 55
HTML WML
JavaApplets FlashCapa de
presentación
XSLT
PHP
MOD-PHP
Servidor Web Apache
PlantillasXSL
Datos
Figura 6.1: Esquema de aplicacion web
Por un lado tendrıamos una capa comunicaciones donde se recibirıan losdatos a representar, un conjunto de plantillas de representacion de datos, unmotor de plantillas y el interfaz de presentacion.
El conjunto de datos a representar se encuentra en XML por lo que necesi-tamos un motor de transformacion XSLT y una plantilla XSL de presentacionpara cada uno de los formatos.
6.3.1. XSL (eXtensible Stylesheet Language
Es un lenguaje utilizado para expresar hojas de estilo para documentos XML.El lenguaje XSL se compone de dos partes:
XSLT
XSL-FO
6.3.1.1. XSLT
XSLT es una de las principales tecnologıas de XSL. XSLT proviene de XSL-Transformations y permite la transformacion de documentos XML a otros for-matos como por ejemplo HTML, PDF, LATEX, etc. La especificacion de XSLT
56 CAPITULO 6. CAPA DE PRESENTACION
<?xml version="1.0"?> <xsl:stylesheet version="1.0"xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/"><html><body><h1><xsl:value-of select="sensor/nombre"/>
</h1><h2><ul><li><xsl:value-of select="sensor/unidades"/></li><li><xsl:value-of select="sensor/resfrec"/></li><li><xsl:value-of select="sensor/limmax"/></li>
</ul></h2>
</body></html>
</xsl:template></xsl:stylesheet>
Tabla 6.1: Codigo XSL de ejemplo
se puede encontrar en http://www.w3.org/TR/xslt. Esta tecnologıa permitecombinar los datos contenidos en un fichero XML no que contiene ninguna ref-erencia a su formato de representacion con unas reglas de presentacion paraobtener el documento final en el formato requerido.
Actualmente, se encuentran disponibles un gran numero implementacionesXSLT. Existen implementaciones tanto para los navegadores Internet Explorercomo para Mozilla.
6.3.1.2. Aplicacion de tecnicas XSL al sistema
Si tenemos en cuenta que nuestros datos se encuentran representados enXML, a traves de la utilizacion de XSLT podremos representar la informacionen diferentes formatos ası como generar interfaces web personalizables de unaforma transparente.
6.4. Interfaz web para servicios web
Los servicios web proporcionan un conjunto de funcionalidades para las apli-caciones externas a nuestro sistema, pero no proporcionan un interfaz para in-teractuar con un cliente de manera directa a traves de un navegador. Aunqueparezca redundante ya que existe un interfaz web para el sistema, la creacionde un interfaz para los servicios web puede ser interesante si las funcionalidadesproporcionadas no son exactamente las mismas que las del interfaz web delsistema.
La generacion dinamica de interfaces para servicios web se trata de una man-era detallada en [?]. Ante la falta de un estandar para el acceso a servicios web
6.5. SEGURIDAD 57
desde un navegador, este artıculo presenta una arquitectura para la generaciondinamica de interfaces utilizando XSLT, plantillas XSL y los datos en formatoXML.
6.5. Seguridad
En principio puede resultar arriesgado que los datos obtenidos en las capturasviajen a traves de Internet, pero como se explica en el capıtulo correspondientea la seguridad del sistema los datos viajaran encriptados utilizando diferentesprotocolos implementados en capas inferiores.
58 CAPITULO 6. CAPA DE PRESENTACION
TRABAJO DE INVESTIGACION. 59
CAPITULO 7
Vision General del sistema
En los capıtulos anteriores hemos comentado la estructura del sistema medi-ante la explicacion de cada una de las partes que lo componen. A continuaciondescribiremos como todos estos modulos interactuan entre sı para formar elsistema completo.
7.1. Flujo de datos del sistema
El flujo de datos del sistema comienza, naturalemnte, en la capa fısica dondelos sensores miden las magnitudes fısicas dentro de los equipos y las transfor-man en senales electricas. Estas senales electricas son recibidas en la tarjeta deadquisicion de datos cuyo convertidor analogico/digital convierte estas magni-tudes electricas en un flujo de datos binarios procesables por un PC. El accesoa este flujo de datos binarios se realiza a traves de un driver, en nuestro casouna DLL implementada en ISA (Area de Ingenierıa de Sistemas y Automaticade la Universidad de Oviedo), que posteriormente envıa dichos datos a una apli-cacion. En nuestro caso, esta aplicacion es Mithril. Una vez los datos llegan aMithril normalmente sufren un procesamiento basado en la aplicacion de unconjunto de operaciones matematicas sobre los datos. Una vez se hja realizadoesta etapa de procesamiento el flujo de datos puede seguir dos direcciones: uti-lizar las capacidades de monitorizacıon de Mithril o dirigirse hacia el sistema demonitorizacion remota. En este trabajo nos centraremos en la segunda opcionla transmision de los datos al sistema de monitorizacion remota.
La transmision del flujo de datos al sistema de monitorizacion remota serealiza a traves del modulo de comunicaciones de Mithril. Este modulo de co-municaciones se basa en la utilizacion de un cliente Jabber que se conecta auna red de mensajerıa Jabber integrada por el resto de Mithril, por uno o masservidores Jabber y por los diferentes modulos residentes en los servidores deaplicaciones. El modulo de comunicaciones debe tener informacion relativa alenrutado de cada una las senales capturadas etc. El flujo de datos normalmentese encaminara a traves de la red Jabber hacia el modulo de procesamiento de
60 CAPITULO 7. VISION GENERAL DEL SISTEMA
datos que una vez haya realizado las operaciones correspondientes se encam-inara hacia los modulos de interfaces con otros sistemas o hacia la capa depresentacion. En el primer caso, los datos habran sido solicitados a traves deuna peticion al servicio web correspondiente y en el segundo caso los datos semostraran a traves de una pagina web generada dinamicamente en el servidorde aplicaciones.
7.2. Interaccion del usuario con el sistema
La interaccion del usuario con el sistema se puede llevar a cabo a traves dedos metodos:
Interfaz web de la aplicacion
Peticion de datos a traves de un servicio web
7.2.1. Peticion de datos a traves del interfaz web
La capa de aplicacion genera un conjunto de paginas web que conforman elinterfaz web del sistema. Este interfaz web permite la visualizacion de datos.
7.2.2. Peticion de datos a traves de servicios web
Nuestro sistema contendra un archiv .wsdl en un lugar accesible donde seespecificaran tanto los servicios disponibles con la especificacion de los paramet-ros de entrada y salida para cada uno de ellos. A traves de este fichero .wsdlel cliente puede reconocer los servicios disponibles y realizar las peticiones dedatos a nuestro sistema.
TRABAJO DE INVESTIGACION. 61
CAPITULO 8
Conclusion
A lo largo de este trabajo de investigacion, se ha realizado un estudio parala creacion de un sistema de monitorizacion remota. Este sistema utiliza comobase el proyecto Mithril desarrollado en el Area de Ingenierıa de Sistemas yAutomatica de la Universidad de Oviedo.
A lo largo del estrudio se han mostrado y evaluado un conjunto de tecnologıasindividuales que solucionan problemas concretos que planteados por el sistema.La seleccion de las tecnologıas recomendadas para la implementacion del sistemase ha basado en estandares abiertos situados en vanguardia tecnologica tal ycomo se ha determinado en la introduccion.
Finalmente podemos concluir que, realizando las tareas de integracion per-tinentes entre las diferentes tecnologıas utilizadas en cada una de las capas, esfactible el diseno e implementacion del sistema de monitorizacion remota.
62 CAPITULO 8. CONCLUSION
TRABAJO DE INVESTIGACION. 63
CAPITULO 9
Futuras lıneas de trabajo
En este trabajo se ha planteado tanto una estructura de capas como un con-junto de tecnologıas a aplicar en cada una de ellas. Todo esto puede servirnoscomo referencia a la hora de realizar un analisis y diseno exhaustivo que de-semboque en las implementacion definitiva del sistema. Principalmente, puedenplantearse dos futuras lıneas de trabajo. La primera debera centrarse en la in-tegracion de las diferentes tecnologıas para formar un sistema consolidado. Lasegunda lınea de trabajo debera centrarse en la gestion dinamica de elementosdentro del sistema que permita la tolerancia a fallos.
Top Related