MIDDLEWARE PARA EL INTERNET DE LAS COSAS : UNA ENCUESTA

INTRODUCCIÓN:

- Al permitir el acceso fácil de, y la interacción con, una amplia variedad de

dispositivos físicos o cosas como tales, como electrodomésticos, cámaras de
vigilancia, sensores de control, actuadores, displays, vehículos, máquinas y así
sucesivamente, la IO fomentara desarrollo de aplicaciones en muchos campos
diferentes, tales como la domótica, automatización industrial, ayudas médicas,
cuidado de la salud móvil, la asistencia de ancianos, la gestión inteligente de la
energía y las redes inteligentes, automotores, gestión del tráfico y muchos otros.
- En este contexto un MIDDLEWARE, puede ofrecer servicios comunes para las
aplicaciones para las aplicaciones y facilidad de aplicación desarrollo mediante la
integración de nuevos y de comunicaciones heterogéneas y favoraciendo la
interoperabilidad dentro de las diversas aplicaciones y servicios que se ejecutan
en estos dispositivos.
- Estos enfoques abordan algunos problemas (tales como el descubrimiento,
desconexiones de red, y la comunicación del grupo) que plantea la IO, pero están
limitados en su apoyo a otras como la sensibilidad del contexto y la escabilidad.

ANTECEDENTES:

- La investigación sobre la IO se encuentra todavía en su fase inicial, y un nivel

definición de la IO no esta disponible todavía.
- “ La internet de las Cosas permite a las personas y cosas que se puedan conectar
en cualquier momento en cualquier lugar, en cualquier momento, con cualquier
cosa y cualquier, idealmente usando una ruta red y todo servicio”.

- Las Redes de sensores(SNS), incluyendo redes inalámbricas de sensores

(WSNs) y de sensores inalámbricos y de redes de accionamiento (WSANs), RIFD
comunicaciones M2M y Adquisición de datos (SCADA) son los componentes
esenciales de la IO.

1).- CARÁCTERÍSTICAS DE LA IO INFRAESTRUCTURA:

 Los dispositivios heterogéneos: La naturaleza incrustada y la computación sensor

de muchos dispositivos IO significa que las plataformas de computación de bajo
costo son susceptibles de ser utilizados.
 Con recursos limitados: la informática y sensores embebidos necesitan un factor
de forma pequeño dispositivo, lo que limita su cessing, la memoria y la capacidad
de comunicación.
 La interacción espóntanea: En las aplicaciones de la IO, interacciones repentinos
pueden tener lugar como los objetos que se mueven alrededor, y entrar en el
rango de la comunicación otros objetos, que conduce a la generación espóntanea
de eventos.
 Ultra red a gran escala y el gran número de eventos: En un entorno de la IO, miles
de dispositivos pueden interactuar entre si, incluso en un mismo sitio local, que es
escala mucho mayor que la mayoría de redes convencionales.
 Red dinámica y sin estructura: integrará muchos dispositivos muchos de los
cuales serán los móviles, conectado de forma inalámbrica, y de recursos con-
tensa.
 Sensible al contexto: El contexto es la clave en la IO y sus aplicaciones. Un gran
número de sensores generará grandes cantidades de datos, que no tendrá ningún
valor a menos que se analiza, interpreta.
 Inteligencia: De acuerdo con la visión de Intel IO, los dispositivos o las cosas
inteligentes y sistemas inteligentes de sistemas son los dos elementos clave de la
IO.
 Consciente de la ubicación o información espacial sobre las cosas(objetos) o
sensores en la IO es crítico, ya que la ubicación juega un papel vital en la
informática consciente del contexto.
 Repartido: La propia internet tradicional es una red distribuida globalmente y asi
también es la IO.

2).- CARACTERÍSTICAS DE LAS APLICACIONES DE LA IO:

 Diversas aplicaciones: El IO puede ofrecer sus servicios a un gran número de

aplicaciones en numerosos ámbitos y entornos.
 Tiempo real: Las aplicaciones que utilizan la IO pueden ser ampliamente
clasificados como en tiempo real y no en tiempo real.
 Todo- as-a-Service(XaaS): Un modelo de servicio es muy eficiente, escalable y
fácil de usar.
 Mayor seguridad Ataque de la superficie: Si bien existe un enorme potencial para
la IO en diferentes dominios, también hay preocupación por la seguridad de las
aplicaciones y redes.
 Las fugas de privacidad: El uso de la IO, las aplicaciones pueden recopilar
información acerca de las actividades diarias de las personas. Como la
información reflejando dichas actividades es considerado por muchas personas
como privada, la exposición de esta información podría afectar la privacidad de las
personas.

B. Middleware en la IO y sus requisitos

 En general, un Middleware abstrae las complejidades del sistema o hardware
permitiendo que el desarrollador de aplicaciones pueda enfocar todo su esfuerzo
en la tarea a resolver, sin la distracción de las preocupaciones ortogonales en el
sistema o el hardware de nivel.

1) Requisitos del servicio Middleware: requisitos de servicio Middleware para la

IO se puede categorizar como funcional y no funcional.
- Funcional:
 Detección de recursos: recursos de la IO incluyen dispositivos
heterogéneos de hadware.
 Administración de recursos: Se espera una calidad de servicio aceptable
para todas las aplicaciones.
 Gestión de datos: Los datos son clave en las aplicaciones de la IO.
 Gestión de eventos: Hay potencialmente un número masivo de los eventos
generados en las aplicaciones de la IO, que debe ser manejada como una
parte integral de un MIDDLEWARE mediados de la IO.
 Gestión de código: La implementación de código en un ENTORNO IO.
 Escalabilidad: Un MIDDLEWARE de la IO debe ser escalable para
adaptarse al crecimiento de la red y aplicaciones servicios de la IO.
 En tiempo real o la actualidad: Un MIDDLEWARE debe proporcionar
servicios en tiempo real cuando la corrección de una operación que SUP-
puertos no depende no sólo de su corrección lógico, sino también en el
momento en que se realiza.
 Confiabilidad: Un MIDDLEWARE debe permanecer en funcionamiento
durante la duración de la misión, incluso en presencia de fallos.
 Disponibilidad: Un MIDDLEWARE apoyo aplicaciones de un IO,
especialmente los de misión crítica, debe estar disponible, o aparecen
disponibles en todo momento.
 Seguridad y Privacidad: La seguridad es fundamental para el
funcionamiento de la IO.
 La facilidad de despliegue: Desde un MIDDLEWARE de la IO es
típicamente desplegados por el usuario.
 Popularidad: Un MIDDLEWARE de la IO debe ser apoyado y ampliado
continuamente.
2) Requisitos de arquitectura: Las exigencias arquitectónicas están diseñadas
para apoyar a los desarrolladores de aplicación.
 Abstracción de programación: Proporcionar una API para apliaciones.
 Interoperable: Un MIDDLEWARE debe trabajar con dispositivos
 Basada en los servicios: Una arquitectura de MIDDLEWARE debe ser ofrecer alta
flexibilidad basada en el servicio cuando las nuevas y avanzadas funciones
necesitan ser añadido a un middleware de la IO.
 Adaptado: Un middleware debe ser adaptable para que pueda evolucionar para
encajar en sí en cambios en su entorno o las circunstancias.
  Sensible al contexto: Sensibilidad al contexto es un requisito clave en la
construcción de sistemas adaptativos y también para establecer el valor de los
datos detectados.
 Autónomo: Autónomo significa auto-gobernados. Vicios/ tecnologías/ aplicaciones
de participar activamente en los procesos de la IO.
 Repartido: /dispositivos/ usuarios de un sistema IO a gran escala Aplicaciones-el
intercambio de información y colaboran entre sí

EJEMPLOS DE MIDDLEWARE BASADAS EN EVENTOS

El vapor [76]

Es un servicio de middleware basado en eventos, diseñado para el dominio de la

informática móvil. Utiliza diferentes tipos de eventos para hacer frente a los problemas
relacionados con la dinámica de reconfiguración de la red, la escalabilidad de un sistema
y la entrega en tiempo real de los acontecimientos.

MiSense [ 83]

Es un peso ligero en capas middleware basado en clúster que separa semántica de

aplicación del hardware subyacente, el sistema operativo y la infraestructura de red.

PSWare [ 85]

Es un middleware basado en tiempo real por eventos de WSN, desarrollado para apoyar
eventos compuestos. Proporciona abstracciones de alto nivel, y logra una alta
expresividad y la disponibilidad.

TinyDDS [ 86]

Middleware en- Ables interoperabilidad entre redes inalámbricas de sensores y redes de

acceso. Proporciona lenguaje de programación e interoperabilidad protocolo basado en el
servicio de distribución de datos estándar (DDS).Los TinyDSS marco permite aplicaciones
WSN tengan control sobre el nivel de aplicación y propiedades no funcionales a nivel de
middleware. Simulación y resultados de las evaluaciones empíricas mostraron que
TinyDDS es ligero y tiene poca memoria. Sin embargo, TinyDDS no proporciona una
visión integral de las necesidades de la IO y no aborda los requisitos clave de la IO como
la adaptación. Además, no ofrece un mecanismo de control de topología
PRISMA [ 29]

Es un middleware basado en eventos orientados al recurso para WSN. Al proporcionar un

alto nivel y una interfaz estandarizada para el acceso a datos, PRISMA apoya la
interoperabilidad de las tecnologías de redes heterogéneas. PRISMA es popular entre los
desarrolladores, y alienta a los primeros usuarios

SensorBus [ 87]

Es una madre para redes inalámbricas de sensores. Permite el cambio libre de más de un
mecanismo de comunicación entre los nodos de sensores. Pará responder a la solicitud
de servicio de aplicaciones en varios contextos, SensorBus proporciona servicios de
personalización a través de metadatos. Su arquitectura tiene tres capas, desarrollado para
servicios de aplicaciones, el mensaje y el contexto. La capa de servicios de aplicaciones
proporciona una API que simplifica el desarrollo de aplicaciones. Esta capa también
despliega filtros de aplicaciones para agregar datos interna, lo que reduce los datos de
flujo en la obra NET, lo que lleva a la reducción de consumo de energía en los nodos
sensores. La capa de servicio de mensajes es responsable de proporcionar la
comunicación y coordinación de los componentes distribuidos, abstrayendo el
desarrollador de estas cuestiones

Hydra [ 101]

Es un middleware para servicios y sistemas (IAM) inteligencia ambiental. Está construido

sobre una arquitectura SOA y la arquitectura basada en modelos. Su arquitectura se
compone de una serie de componentes de gestión, incluyendo un gestor de servicios,
gestor de eventos, el administrador de dispositivos, gestor de almacenamiento, gestor de
contexto, y gerente seguridad. Estos componentes se agrupan en aplicaciones y
dispositivos elementos, cada uno de los cuales tienen una capa semántica, capa de
servicio, la capa de red, y capa de seguridad. Hidra proporciona interoperabilidad nivel
sintáctico y semántico usando servicios web semánticos. Además de un número de
elementos funcionales requisitos (por ejemplo, gestión de datos, la gestión de eventos,
gestión de recursos), soporta reconfiguración dinámica fi y auto-configuración con fi. Hidra
'S de recursos, los administradores de dispositivo y la política hacen que sea ligero,
optimizando el consumo de energía en dispositivos con recursos limitados. Componentes
de seguridad distribuida y la confianza social ofrecen una comunicación segura y
confiable
dentro de los dispositivos. Su solución de seguridad y privacidad utiliza zación virtual- y
una implementación de mecanismos basados en WS ES- riched por la resolución
semántica[101]. Sin embargo, su virtualización puede introducir problemas de seguridad
(por ejemplo, ataques de canal lateral). Además, las soluciones de seguridad y de
interoperabilidad semántica basada en ontologías es probable que sean inadecuados en
la IO, ya que, actualmente, no existen estándares para las ontologías de ultra gran escala
de la IO.

Los MUSIC [ 70]

Proporciona una arquitectura basada en componentes auto-adaptativo para apoyar la

construcción de sistemas en entornos ubicuos y SOA, donde pueden ocurrir cambios
dinámicos en proveedores de servicios y de servicios Los consumidores contextos. En
particular, MÚSICA se centra en los cambios en un sitio de proveedor de servicios, para el
intercambio de componentes y servicios que proporcionan la funcionalidad definida por el
marco de componentes.

TinySOA [ 105]

Es un SOM que ofrece un alto nivel de abstracción de la infraestructura para el desarrollo

de WSN aplicaciones. Proporciona una API simple orientada al servicio a través del cual
los desarrolladores de aplicaciones pueden acceder a los recursos de sus aplicaciones
WSN. Maneja WSN dispositivo y nivel de comunicación heterogeneidad, y ofrece una fácil
integración de aplicaciones de Internet con redes inalámbricas de sensores que les
permiten recoger información de los sensores.

SensorsMW [ 108]

Es un SOM flexible adaptable y fl de QoS con fi guración y gestión de redes inalámbricas

de sensores. Se abstrae WSNs como un conjunto de servicios para una perfecta
integración en un sistema de información empresarial. Esto permite una fácil y eficiente de
configuración de las redes inalámbricas de sensores para la recopilación de información
mediante servicios web. Recursos en una WSN son gestionados para cumplir con ciertos
requisitos de calidad de servicio, de acuerdo con los SLA. Es importante destacar, que
ofrece una manera abstracta para acceder a estos recursos para aplicaciones de alto
nivel para reconfigurar y mantener la red durante su vida.

SENSEI [ 109]

Desarrolla una arquitectura para el futuro y el mundo real de Internet incluyendo la IO. Es
una de las primeras propuestas que incluyeron un modelo de contexto, los servicios de
contexto, las tareas de actuación, y la posición con servicio dinámico de ambos servicios
primitivos y avanzadas para el mundo real de Internet. El componente principal de este
middleware es la capa de recursos, que se encuentra entre la capa de capa de aplicación
y servicios de comunicación.

ubiSOAP [ 94]
Es un SOM que proporciona una red sin fisuras de los servicios web. Capa de recursos de
la arquitectura contiene las funciones necesarias, incluyendo la abstracción para
dispositivos PLE sim- (por ejemplo, sensores, actuadores, procesadores o componentes
de software) para facilitar la interacción de aplicaciones y servicios con los recursos. Un
componente de servicios de apoyo permite el descubrimiento y composición dinámica de
los recursos (por ejemplo, servicios).Composición dinámica y la instanciación de nuevos
servicios son facilitados por los modelos semánticamente ricos y descripciones de
sensores, actuadores y elementos de procesamiento.

Servilla [ 95]

Facilita el desarrollo de aplicaciones en redes inalámbricas de sensores heterogéneos.

Utiliza SOC para desacoplar el código de plataforma específico de aplicaciones
independientes de la plataforma. La estructura AP- complicaciones como tareas
independientes de la plataforma que se enlazan dinámicamente a los servicios de
plataforma específica. Servilla 'S arquitectura consiste en una máquina virtual (VM) y un
servicio provisionalmente marco ing (SPF) y se ejecuta en los nodos de sensores
individuales en una WSN. La máquina virtual ejecuta tareas de aplicaciones Mientras que
las descubre SPF-consumo y accede a los servicios, y el proveedor de SPF- anuncia y
ejecuta servicios.

Kasom [ 110]

Es un conocimiento-Aware y orientada a servicios Middleware (Kasom) para redes

embebidas generalizados, especialmente para WSANs. Su arquitectura se compone de
tres subsistemas. Servicios de marco (por ejemplo, seguridad, gestor de tiempo de
ejecución), servicios de comunicación (por ejemplo, el monitor de recursos), y servicios de
gestión del conocimiento (por ejemplo, servicio de reglas composición, recursos de
contexto).

CHOReOS [ 111], [112]

Permite coreografías o composiciones de servicios adaptables, QoS-aware, y

heterogéneos en la IO a gran escala. Se dirige a la escalabilidad, interoperabilidad,
movilidad, y los problemas de adaptabilidad en los enfoques a través de los registros de
servicio escalable como probabilísticos basados en la cosa. CHOReOS se compone de
cuatro componentes: Servicio ejecutables Composición (XSC) para coordinar la
composición de los servicios y las cosas, extensible servicio de acceso (XSA) para
acceder a los servicios y las cosas, extensible Servicio Desven- covery (XSD) para
gestionar protocolos y procesos de descubrimiento de servicios y las cosas, y la nube y
middleware
Grid para gestionar los recursos computacionales e impulsa el despliegue de coreografías
Xively [ 99]

Es un PaaS que proporciona servicios de middleware para crear productos y soluciones

para la IO. basado en la nube pública Xively ofrece a los desarrolladores basados en
estándares de servicios de directorio, datos y servicios de oficina.

CarrIoTs [ 98]

Es un middleware orientada al servicio basado en la nube para la IO, especialmente para

las comunicaciones M2M, y se centra en: el desarrollo de aplicaciones coste M2M eficaz,
escalabilidad y facilidad de uso. La principal ventaja de CarrIoTs es que soporta la
escalabilidad a nivel de red.

Echelon [ 118]

Es una plataforma IIoT con un juego completo de fichas, pilas, módulos, interfaces y
software de gestión de dispositivos en desarrollo y las comunidades P2P. A diferencia de
las plataformas de la IO de consumo, se ocupa de los requisitos básicos para el IIoT.

Esterae [ 125]

Es un middleware basado en VM para nodos sensores con recursos limitados.

MagnetOS [ 132]

Es un sistema operativo distribuido para redes de sensores que abstrae toda la red como
una sola, uni fi ed Java VM, que hace que las aplicaciones escritas para MagnetOS
portátil. El objetivo principal de esta solución es reducir el consumo de energía y
aumentar la longevidad de la red.

Similar a MagnetOS,

Squawk es una pequeña Java VM que soporta múltiples aplicaciones, ofrece punto-tipos
de conexión a punto, y utiliza código optimizado con el fin de reducir el consumo de
memoria. Sensorware es otra solución que implementa un intérprete de guiones con el fin
de proporcionar una forma de redes inalámbricas de sensores basados en secuencias de
comandos móviles programar.

Impala [ 149]
Es una solución middleware para WSNs que permite modularidad aplicación, la
adaptabilidad, y reparabilidad en WSNs. Esta solución middleware era parte del proyecto
Ze-Branet, un sistema de red de sensores móvil para la mejora de la tecnología de
seguimiento a través de los nodos de seguimiento deficiente de energía y técnicas de
comunicación P2P. Impala adopta la programación por aire para la gestión de código y
describe una arquitectura de software más adecuado para mejorar la eficiencia de los
recursos de los nodos de recursos limitados

UbiROAD [ 153]

Es un middleware semántica para entornos viales inteligentes sensibles al contexto. Se

trata de la interoperabilidad entre en el coche y dispositivos heterogéneos borde de la
carretera. La interoperabilidad semántica se logra por dos capas: de interoperabilidad a
nivel de datos y funcional de interoperabilidad a nivel de protocolo y
coordinación.soluciones de middleware

LIMA [ 160]

Es un middleware para MANET desarrollados para hacer frente a las limitaciones de

energía dispositivos móviles. LIMA toma prestado y adapta el modelo de coordinación de
Linda [163], y rompe el espacio de tuplas centralizado en la puerta de entrada en múltiples
espacios de tuplas, cada uno unido de forma permanente a un componente móvil. El
acceso al espacio de tuplas se lleva a cabo utilizando un conjunto extendido de
operaciones espaciales tupla, incluyendo varios constructos diseñados para facilitar las
respuestas en tiempo real flexible y FL a cambios.

TinyLIME [ 161]

Se basa en LIMA mediante la adición de componentes especializados para redes de

sensores. Sin embargo, TinyLIME ofrece un apoyo limitado para la adaptación y no tiene
ningún mecanismo de seguridad construido en. TeenyLIME es una extensión de LIMA y
TinyLIME.

TeenyLIME [ 162]

Es una extensión de LIMA y TinyLIME. Se proporciona un modelo de programación más

general abstracción mediante el despliegue de operaciones proactivas y reactivas. Limita
el número de aplicación- nivel utiliza mediante el control de vecindad de un salto de un
dispositivo. Esto se hace para reducir el consumo de energía y mejorar los datos
sensibles al contexto de recolección.Un inconveniente de CAL, TinyLIME y que despliega
un estilo de comunicación asíncrona y desacoplado tanto en el tiempo y el espacio.

Un espacio tupla es un repositorio de datos que se puede acceder al mismo tiempo.

TS-Mid es otro middleware tupla-espacio para WSNs, que despliega un estilo de

comunicación asíncrona y desacoplado tanto en el tiempo y el espacio.
TS-Mid sigue el mismo enfoque de la recogida de datos en una puerta de enlace. Sin
embargo, TS-Mid mejora la jerarquía de estructura de nodos mediante la creación de
regiones lógicas (o grupos) para los nodos en la proximidad.

A3-TAG, sigue la estructura jerárquica nodo utilizado en TS-Mid, con el fin de hacer frente
a la auto-adaptación y diseminación de nuevas tareas con configuración a través de la
comunicación de grupo. Sin embargo, A3-TAG presenta los mismos inconvenientes: el
nodo líder se convierta en un cuello de botella en el grupo y no
proporciona uniformidad de uso de energía.

Las soluciones de tupla-espacios de middleware presentados aquí (es decir,

LIMA, TinyLIME, TeenyLIME, TS-Mid, A3-TAG) han sido diseñados sólo para redes
inalámbricas de sensores o dispositivos móviles.

En middleware orientado base de datos.

SINA maneja eventos y también puede hacer frente a la movilidad de la consulta

(sumidero) nodo .Permite complicaciones sensores AP para realizar consultas y tareas de
mando, recoger las respuestas y resultados, y monitorear los cambios dentro de las
redes.
PUMA, es otro middleware orientado a la base de datos. En PUMA, hay dos tipos de
datos: los datos almacenados y los datos del sensor
IrisNet, es una plataforma de base de datos orientada, que despliega servicios
heterogéneos en WSNs.
Sensación ,es middleware orientado a la base de datos-desarrollado para aplicaciones de
WSN, y diseñado para proporcionar soporte para diferentes sensores.
KSpot +, es un middleware distribuido centrada en los datos architecture para WSN.

Un middleware aplicación específica.

Una aplicación específica (es decir, la aplicación de guiado) enfoque de middleware

centra en el apoyo de gestión de recursos.

AutoSec y Adaptativo Middleware son algunos ejemplos de este enfoque. AutoSec utiliza
un corredor de servicio dinámico para la gestión de recursos en un sistema distribuido.
Milán es similar a Adaptativo Middleware, aunque Milán explora el concepto de
adaptación proactiva con el fin de responder a las necesidades de aplicación. Milán
permite a las aplicaciones para especificar sus requisitos de calidad de servicio y ajustar
la configuración de la red en tiempo de ejecución.
MidFusion, se basa en los conceptos presentados en Milán y Adaptativo Middleware. El
propósito de esta solución de middleware es evitar el mantenimiento de los conocimientos
acerca de los sensores exactos disponibles.

Aunque los middleware presentados en este documento abordan muchas cuestiones y

requisitos en la IO, todavía hay algunos retos de búsqueda .Es importante destacar que la
mayoría de middleware actuales abordan redes inalámbricas de sensores, mientras que
otras perspectivas (por ejemplo, M2M, RFID y SCADA) rara vez se abordan.

Esta encuesta indica que ha habido avances significativos en hacer frente a muchos
desafíos para el middleware en un entorno IO, con los siguientes desafíos abiertos
restantes.

A. Problemas relacionados con los requisitos funcionales de Recursos infraestructura de

la IO invalida registros de recursos centralizada y enfoques de descubrimiento.

Administración de recursos: de recursos frecuentes conflictos ocurrir en aplicaciones

de IO que comparten recursos.
Gestión de datos: Una gran cantidad de datos en bruto recogió continuamente
necesita ser convertida en conocimiento útil.
La mayoría de los encuestados middleware ofrecen soporte para la agregación de datos,
pero no tienen en cuenta los datos de filtrado.
Gestión de eventos: Un gran número de eventos se generan proactiva y reactiva en la
IO. Debido a esto, se espera que los componentes de middleware puedan convertirse en
cuellos de botella en el sistema. La mayor parte del middleware encuestados no puede
manejar o no han sido probados en contra de este requisito.
Gestión de código: Reprogramación es uno de los principales desafíos no sólo en la IO,
Sino también en el desarrollo de software.

B. Problemas relacionados con los requisitos no funcionales Escalabilidad: Como la

mayoría de middleware existentes son WSNs céntrica, su escalabilidad a nivel de red
también está limitado a redes inalámbricas de sensores.

Tiempo real: Las aplicaciones y servicios se basan en estar directamente conectado con
el mundo físico. La obtención de información en tiempo real sobre el estado del mundo
real sigue siendo una tarea difícil. Algunos enfoques de middleware son, por naturaleza,
no en tiempo real (por ejemplo, bases de datos o tupla en el espacio middleware).
Confiabilidad: La fiabilidad no se trata en la mayoría de las propuestas existentes. Para
lograr fiabilidad middleware, cada componente o servicio de un middleware tiene que ser
perfectamente capaz de sustitución.
Disponibilidad: Maximizando la disponibilidad del sistema y rápida recuperación de los
fracasos son desafíos que no son específicos de la IO, sino a cualquier sistema
distribuido. En el contexto de la IO, la disponibilidad de las cosas y servicios que se
ofrecen es importante.
Seguridad y privacidad: Todas las preocupaciones de seguridad, la privacidad y la
confianza en todas las tecnologías (por ejemplo, Internet tradicional, redes inalámbricas
de sensores, comunicaciones M2M, RFID, SCADA, y la computación en la nube)
utilizados en la IO están claramente presentes en el contexto de la IO. Sin embargo, la
seguridad, la privacidad y la confianza no están completamente resuelto en estas
tecnologías.
La facilidad de despliegue: Implementación, posterior a la implementación, y
capacidad de programación son tareas importantes en el ciclo de vida de middleware
IO. La reducción de la interacción humana en estas etapas y tener la posibilidad de
desplegar de forma remota el software intermedio sin ningún pre-configuración del
dispositivo sigue siendo un reto interesante.
Popularidad: El crecimiento de una comunidad en línea activa en torno a un proyecto de
software es una tarea difícil.

C. Desafíos relacionados con los requisitos arquitectónicos -Programación de abstracción:

La mayoría de middleware ofrecen apoyo abstracción -programación. Sin embargo, los

nuevos lenguajes y herramientas que necesitan ser adoptados tienen una curva de
aprendizaje para los desarrolladores y usuarios. El apoyo a este requisito se puede
mejorar.

Interoperabilidad: interoperabilidad de las redes está bien apoyado por la mayoría

de middleware existentes, pero muchos carecen de sustentación para la interoperabilidad
semántica y sintáctica.
Basada en los servicios: La mayoría de los middleware son a base de servicio.
Adaptado: En una serie de enfoques, la adaptación de toma de decisiones no es
modificable y requiere volver a compilar el sistema o una parte del Sistema.
Sensibilidad al contexto y el comportamiento autónomo: Los diferentes tipos de
middleware se han aprovechado de un cierto nivel de conciencia del contexto.

La mayoría de middleware existentes no son adecuados para sistemas con propiedades

de auto (por ejemplo, la auto-adaptativo) M2M comunicaciones incluyendo. Junto con la
explotación más amplia de contexto, integración y la explotación de la inteligencia y las
propiedades auto en el sistema de middleware de la IO es una rica, área de investigación
abierta.

El middleware es necesario para facilitar el desarrollo de las diversas aplicaciones

y servicios en la IO. Muchas propuestas se han centrado en este problema. Las
propuestas son diversas e implican diferentes enfoques de diseño middleware y
soportan diferentes requisitos. En este trabajo se pone a estas obras en perspectiva y
presenta una visión holística del campo. Al hacer esto, las características principales
de la IO y los requisitos de middleware de la IO se identifican.