Supervisi´on remota de procesos industriales a trav´es de...

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

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

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.


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


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


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.


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


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

isa.uniovi.es/~pgarcia/mithril

isa.uniovi.es/~pgarcia/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.


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


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


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.


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


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

http://www.jxta.org/project/www/license.html

http://www.jxta.org/project/www/license.html


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’>


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’


to=’vibra-signal.equipo2.isa.uniovi.es’id=’items2’>

<query xmlns=’http://jabber.org/protocol/disco#items’/></iq>

La respuesta podrıa ser:


<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>


<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’


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>


</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.

http://www.jabber.org/software/libraries.php

http://www.jabber.org/software/libraries.php


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


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.

www.w3c.org

www.w3c.org

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.

http://jakarta.apache.org

http://jakarta.apache.org

h


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>

http://www.oasis-open.org

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"?>

 <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>

<xsd:schema targetNamespace="http://namespaces.snowboard-info.com"xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<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:element name="GetEndorsingBoarderResponse">

<xsd:complexType><xsd:all><xsd:element name="endorsingBoarder" type="string"/>

</xsd:all></xsd:complexType></xsd:element>

<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 name="GetEndorsingBoarderRequest"><wsdl:part name="body" element="esxsd:GetEndorsingBoarder"/>

</wsdl:message>

<wsdl:message name="GetEndorsingBoarderResponse"><wsdl:part name="body" element="esxsd:GetEndorsingBoarderResponse"/>

</wsdl:message>

<wsdl:portType name="GetEndorsingBoarderPortType">

<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 name="EndorsementSearchSoapBinding"

type="es:GetEndorsingBoarderPortType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

5.4. IMPLEMENTACION DE LOS MODULOS DE PROCESAMIENTO DE DATOS49

<wsdl:operation name="GetEndorsingBoarder">

<soap:operation soapAction="http://www.snowboard-info.com/EndorsementSearch"/>

<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 name="EndorsementSearchService"><wsdl:documentation>snowboarding-info.com Endorsement Service</wsdl:documentation>

<wsdl:port name="GetEndorsingBoarderPort"

binding="es:EndorsementSearchSoapBinding">

<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


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


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


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.

http://ganglia.sourceforge.net

http://ganglia.sourceforge.net

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


<?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

http://www.w3.org/TR/xslt

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.


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.


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


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.

Supervisi´on remota de procesos industriales a trav´es de...

Documents

Transcript of Supervisi´on remota de procesos industriales a trav´es de...