Una estrategia para integrarlos a todos (del Internet de las Cosas a la Empresa)

por

Hola de nuevo. En este artículo voy a hablarte sobre algunos de los increíbles cambios que la mayoría de nosotros, y nuestros hijos con seguridad, viviremos en nuestro día a día gracias a la tecnología: ya se trabaja en convertir nuestras ciudades en ciudades inteligentes, o nuestros coches en coches conectados, o en el Internet de las Cosas (Internet of Things o IoT). Estos son algunos de los mayores exponentes de la transformación social que vivimos con el intercambio constante de información y la integración de “todo con todo”.

 

Y yo me pregunto: ¿de qué me sirve tener las cosas de mi casa conectadas si en cuanto salgo a la calle y paseo por mi ciudad o me meto en mi coche se acabó la conectividad?

 

En realidad, todo está muy relacionado. Diría más: todo es lo mismo.

 

Vamos a verlo.

 

 

LOS ECOSISTEMAS DE INFORMACIÓN

 

Te invito a que observemos este asunto desde distintas escalas. Podemos incluir más, pero para manejar un alcance controlado en este artículo hablaremos de tres escalas.

 

Cuando pensamos en el Internet de las Cosas es probable que lo primero que nos venga a la mente sean las casas inteligentes (Smart Homes). Hogares donde los dispositivos, los electrodomésticos y los objetos que nos rodean son capaces de intercambiar información que, debidamente aprovechada y controlada, nos puede hacer la vida mucho más cómoda y aportarnos seguridad, confort y nuevas experiencias.

Esta sería la primera escala: las Smart Homes (hogares inteligentes).

Los Smart Homes son Ecosistemas de Informacion

 

Ahora salgamos de casa. Vamos a conducir un rato. Hoy día no es extraño conectar nuestros teléfonos móviles al coche, por ejemplo, para poder usar el sistema de manos libres para hacer o atender llamadas, o para usar el navegador GPS, o para escuchar nuestra música por el audio del coche. Todo esto está muy bien, y efectivamente, hay conectividad en nuestro coche. Pero, ¿ya está? ¿esto es todo? Sí, de acuerdo, también están los mensajes… pero seamos realistas: si estás conduciendo no puedes leer mensajes en una pantalla, aunque sea la pantalla que tienes en el salpicadero de tu coche.

Bueno, enseguida veremos más posibilidades. Por ahora fijemos aquí la segunda escala. Los conocidos como Connected Cars (coches conectados).

Los Connected Cars son Ecosistemas de Informacion

 

Bien, ya tenemos dos escalas. La tercera es bastante obvia. Cuando salimos de casa, ya sea a pie o en coche, vamos a circular por las calles de nuestra ciudad. Pasaremos por tiendas, restaurantes, farmacias, centros de salud, hospitales, bancos, centros comerciales, edificios de oficinas, edificios públicos como el Ayuntamiento, oficinas de correos, etc. Naturalmente nos gusta encontrar las calles limpias, el mobiliario urbano cuidado y funcionando. Y si puede mostrarnos información útil, mejor que mejor. Los parques en buenas condiciones, la iluminación, etc, etc.

 

Sin duda, las ciudades son auténticos ecosistemas donde conviven muchos negocios y muchos servicios, privados y públicos. Y los ciudadanos cada vez demandamos más información, más interacción y más automatización. Evitar las colas, poder realizar gestiones desde nuestros dispositivos móviles en temas bancarios, sanitarios, servicios públicos municipales…, planear nuestro ocio con información de calidad y actualizada, etc, etc.

Bueno pues esta es nuestra tercera escala: las Smart Cities (Ciudades Inteligentes).

Las Smart Cities son Ecosistemas de Informacion

 

Cada una de estas escalas, o ámbitos si queremos verlos así, están formados por un conjunto de sistemas que interactúan entre sí intercambiando información. Son, por tanto, Ecosistemas de Información. En consecuencia, de lo que estamos hablando en realidad es de tres Ecosistemas de Información: nuestras Smart Homes son un Ecosistema de Información, nuestros Connected Cars son otro Ecosistema de Información y nuestras Smart Cities son otro Ecosistema de Información.

 

Y tal como ocurre con los ecosistemas en la naturaleza, los distintos Ecosistemas de Información interactúan entre sí, como veremos enseguida.

 

CASOS DE USO

Veamos ahora algunos ejemplos más o menos imaginarios, que veremos en un futuro de la mano del Internet de las Cosas (en algunos casos, presente ya), y que nos servirán para ilustrar el resto de esta entrada:

 

Caso 1.

Tu frigorífico te envía dos notificaciones, que recibes en tus dispositivos móviles. En la primera notificación, te informa de que los yogures están a 5 días de su fecha de caducidad. En la segunda notificación, te informa de que la leche y la verdura se agotarán en dos días, y te pide confirmación para enviar el pedido de compra al supermercado habitual. Tras confirmarlo, antes de un minuto recibes otra notificación que te confirma que el pedido llegará a tu domicilio al día siguiente.

 

Caso 2.

Tu coche se aproxima a tu ciudad de destino (puede ser la ciudad donde vives, donde trabajas, o simplemente donde tienes fijado tu destino en ese trayecto). El sistema de a bordo te informa verbalmente que has recibido indicaciones sobre plazas de aparcamiento disponibles, así como de situación del tráfico en las principales vías de acceso a la ciudad. Te pide confirmación para establecer en tu navegador GPS la ruta hacia los aparcamientos disponibles más próximos a tu destino, evitando las zonas de mayor tráfico. O quizás tienes configurado tu vehículo para que tome esa decisión por defecto sin tener que confirmarlo. Esa ruta, por supuesto, se recalcula en tiempo real con cada nueva actualización de datos que el coche recibe de la ciudad. Además, para la obtención de la información de aparcamiento se produce un intercambio de mensajes entre la ciudad y el vehículo parecido a esto:

  • Vehículo: coordenadas de destino (X, Y).
  • Ciudad: las plazas de aparcamiento disponibles, ordenadas por cercanía a la zona de tu destino, están en esta lista: Lista (X, Y). Y la cantidad estimada de vehículos que se dirigen a la misma zona es de Z.

Así, nuestro vehículo estimará un porcentaje de probabilidades de cada zona disponible, en función de la afluencia estimada de vehículos y el tráfico existente en las distintas vías de entrada. Podrá establecer una ruta eficiente, que maximice tus opciones de encontrar una plaza libre de aparcamiento, sin esfuerzo, en el menor tiempo posible.

 

Caso 3.

Antes de acostarte, programas tu hora de despertarte en tu dispositivo móvil. Le asignas una rutina previamente configurada, llamada “día laborable”, que consiste en:

  • encender lentamente las luces de tu dormitorio 30 minutos antes de la hora, hasta llegar a despertarte a la hora elegida,
  • tener en ese momento tu bañera llena con una determinada cantidad de agua a una determinada temperatura,
  • mantener tu café caliente en la cocina,
  • tener la casa climatizada a 23 grados,
  • reproducir tu lista de música favorita,
  • mostrar en tu pantalla de TV tu selección de feeds RSS,
  • encender el climatizador de tu coche 10 minutos antes de irte,
  • cuando sales de tu casa, entra en funcionamiento la rutina “ausente”, que pone en modo de ahorro de energía todos los sistemas de tu casa, excepto tu alarma.

 

Podríamos imaginar prácticamente cualquier caso de uso, pero para este artículo creo que es bastante. Sigamos.

 

LO QUE TIENEN EN COMÚN

Todos estos escenarios, y cualquier otro que se nos pueda ocurrir, comparten muchas características. Identificarlas nos ayudará a ir perfilando la mejor solución estratégica a la implementación de estos casos de uso que parecen tan cerca de la ciencia-ficción.

Necesidades comunes en el IoT

 

Todos los casos de uso están definidos desde la perspectiva del usuario, nunca desde la perspectiva de los sistemas participantes. Los procesos que interesan al usuario determinan los flujos de información que queremos modelar y resolver. En ningún caso el usuario debe adaptarse a ninguna restricción derivada de la tecnología. Si te fijas, en ningún momento hemos mencionado ningún software concreto, ni dispositivo concreto. Se trata de casos independientes de la tecnología.

 

Tampoco hemos mencionado ninguna marca o proveedor de los dispositivos que participan. No hemos indicado la marca del vehículo, ni de las bombillas, ni del sistema de aire acondicionado, ni el fabricante del televisor, ni qué lector RSS usa… nada de nada. Por lo tanto, estamos dando por sentado la necesidad de que cualquier sistema participante, de cualquier proveedor, sea capaz de interpretar su papel en estos flujos de información. La independencia del proveedor parece, por tanto, otra característica a considerar. De no garantizar esta independencia, el usuario tendría pocas opciones para disponer de los dispositivos que más le gusten, cambiarlos cuando quiera, ampliarlos, o eliminarlos del caso. Esto nos lleva directamente a la siguiente característica.

 

Los dispositivos no deben intercambiar información directamente entre sí. Es decir, necesitan un sistema director, un sistema mediador que orqueste los distintos eventos, y se asegure de enviar y recibir los mensajes de cada dispositivo en tiempo y forma. Otra manera de enunciar esta tercera necesidad sería así: cada Ecosistema de Información debe minimizar el acoplamiento todo lo posible. El acoplamiento se refiere a la dependencia entre los distintos sistemas que participan en los procesos. Un sistema mediador, junto con el uso de estándares de interoperabilidad que definen la mensajería a utilizar, permitiría garantizar el menor acoplamiento posible en el Ecosistema de Información, favoreciendo así la independencia del usuario respecto de cada fabricante, como indicábamos en el punto anterior.

 

Por último, mencionaremos también la necesidad de que el usuario disponga de un panel de control, un cuadro de mando donde además de activar o desactivar los parámetros y casos que quiera, pueda configurar nuevos casos, nuevas rutinas, nuevas acciones, para que cada Ecosistema de Información pueda responder a sus necesidades cambiantes.

 

LA ESTRATEGIA A SEGUIR

Al hilo de las características comunes que hemos identificado, vamos a imaginar el boceto de una posible estrategia a seguir, paso a paso. Observa que en ningún momento estamos hablando de tecnología.

Integracion de Sistemas. Una propuesta de estrategia

 

Analizar y modelar los procesos.

Ante cada uno de los casos de uso, o flujos de información que tenemos entre manos, debemos realizar un análisis que nos permita identificar, al menos, lo siguiente:

Actores.

Necesitamos conocer todos los sistemas participantes, incluyendo al usuario cuando corresponda, naturalmente. Se trata de identificar qué sistemas tienen un rol en el caso, bien sea enviando información, recibiéndola, o ambas cosas.

Roles.

Tenemos que saber qué papel juega cada uno de los actores. Quién produce información y quién la consume.

Eventos.

Es necesario identificar qué hechos significativos del proceso determinan el avance del flujo de información. A veces podemos estar ante eventos de tiempo (como cuando se programa la hora de despertarnos), o eventos propios del caso (como cuando el coche recibe la información de la ciudad, o cuando la cantidad de leche del frigorífico es menor que una cantidad configurada, o cuando nos alejamos de nuestra casa).

Mensajes.

¿Cuándo se envía o se recibe información? Habitualmente este envío y recepción de información estará ligado a los eventos. Incluso algunos de estos eventos serán, precisamente, los de envío y recepción de mensajes, porque a menudo es en esos momentos cuando el flujo de información avanza. Es necesario saber cuántos mensajes debe enviar y recibir cada actor, así como identificar qué mensajes participan. En este punto habría que tener en cuenta que a veces, un mismo mensaje, puede ser enviado desde un actor a varios actores.

Con toda esta información, podríamos modelar los procesos para poder verlos gráficamente y así comprenderlos mejor. Podríamos encontrar patrones similares, quizás idénticos, en distintos casos de uso e incluso en distintos Ecosistemas de Información.

 

Analizar los mensajes.

En cada uno de los mensajes identificados ¿qué información debe viajar? ¿qué datos son necesarios? ¿qué datos son interesantes, aunque no sean imprescindibles? ¿de qué datos dispone cada actor para poder desempeñar su papel en el caso y qué información necesitaría recibir? ¿qué actor debería suministrar esa información? ¿es una información específica de un actor o podría ser información general común a todo el Ecosistema de Información?

 

Este último matiz es muy importante, porque a menudo un sistema se autoproclama proveedor de cierta información que, en realidad, pertenece al Ecosistema de Información, y no a ese sistema particular. Cuando esto ocurre, ese sistema introduce acoplamiento (dependencia), de forma que se pierde capacidad de crecer y adaptarse a las necesidades de uso real, y se pierde capacidad de sustituir unos sistemas por otros.

 

Por tanto, es importante identificar muy bien cuál es el verdadero origen de los datos que son necesarios para cada actor, sin tener en cuenta a ningún otro actor: analizando únicamente el caso de uso en el contexto del Ecosistema de Información.

 

Diseñar los mensajes estándar.

La palabra clave aquí es “estándar” y el concepto clave a introducir es Interoperabilidad. En el diseño de los mensajes debemos utilizar un estándar de Interoperabilidad adecuado. Es deseable que cada Ecosistema de Información cuente con su propio estándar de Interoperabilidad. Este estándar, debe tener perfectamente catalogados los posibles eventos que corresponden al funcionamiento real de ese Ecosistema de Información. Con cada evento, debe especificar los mensajes que pueden acompañarlo y la información asociada, la obligatoria y la opcional, llegando a especificar la estructura de los mensajes.

 

Esta parte es de vital importancia. Si un Ecosistema de Información no cuenta con un estándar de Interoperabilidad único y común para todos los actores, entonces la dificultad para implementar los flujos de información se dispara, la probabilidad de error aumenta exponencialmente, y lo más probable es que alguno de los actores imponga sus propios esquemas de mensajería al resto. De nuevo, aparecen la dependencia y el acoplamiento, que comprometen la escalabilidad y la agilidad de todo el Ecosistema de Información.

 

Déjame que insista en la importancia de este tema. Los Ecosistemas de Información son cambiantes porque el mundo es cambiante, y las circunstancias de cada ciudad, cada conductor, cada ciudadano, cambian. Y al cambiar sus circunstancias, cambian sus necesidades. Los Ecosistemas de Información deben ser capaces de adaptarse a esos cambios rápidamente y con el menor impacto posible. Por eso el acoplamiento es un enemigo a batir. Si no se tiene en cuenta este tema desde el primer momento, con frecuencia sale a relucir cuando nos damos cuenta de que no podemos cambiar nada sin un enorme esfuerzo económico y de reingeniería.

 

Diseñar los Servicios.

Conocemos los sistemas participantes, qué sistema envía y qué sistema recibe cada mensaje, en función de qué eventos. Conocemos los patrones que aparecen en los procesos modelados, y sabemos cuáles se repiten en un mismo Ecosistema de Información, o incluso en distintos Ecosistemas de Información.

 

Hemos identificado también eventos externos a cada Ecosistema de Información, normalmente producidos por otros Ecosistemas, que tienen importancia en cada caso de uso.

 

Hemos diseñado los mensajes de manera estándar, homogénea, usando para ello el estándar de Interoperabilidad correspondiente a cada Ecosistema de Información. Tengamos en cuenta aquí que cuando en un caso participa más de un Ecosistema de información, es muy probable que dos estándares de mensajería diferentes tengan que entenderse. Significa que tendremos que ser capaces de “entender” esquemas distintos a los de nuestro Ecosistema de Información, y “traducir” sus datos a nuestros mensajes. Y viceversa.

 

Ahora podemos empezar a diseñar un Catálogo de Servicios. Tengamos en cuenta que para cada uno de los casos que estemos estudiando, puede ser suficiente con un único servicio, o pueden necesitarse varios servicios. Esto dependerá principalmente de la complejidad de cada caso, y de nuestras propias decisiones de diseño.

 

Otro detalle importantísimo a la hora de diseñar los servicios es el concepto de granuralidad. Este concepto se refiere al nivel de atomicidad del servicio, o lo que es lo mismo, su nivel de abstracción. Y todo ello está directamente relacionado con la reusabilidad. No es ningún secreto que, si fomentamos la reutilización del software, cualquier software, estamos ahorrando costes y mejorando la mantenibilidad. En un Ecosistema de Información, la reusabilidad de los servicios es otro factor clave para alcanzar la agilidad y escalabilidad, porque incide directamente en los costes de los proyectos y en la calidad de los sistemas.

 

Un servicio demasiado abstracto, es decir, de baja granuralidad, ofrece una capacidad de reutilización muy alta. Para entender bien estos conceptos pensemos en un ejemplo. Si manejamos el concepto “vehículo”, podemos usarlo para hablar de cualquier traslado: usamos un vehículo para volar, un vehículo para navegar, un vehículo para conducir por la carretera con la familia y otro para hacerlo en solitario o en pareja, otro vehículo para pedalear, otro vehículo para cubrir grandes distancias sobre raíles, y otro vehículo para viajar en grandes grupos. Y en cada uso podemos llegar al detalle que queramos porque el concepto “vehículo” es suficientemente abstracto para usarlo en todos los casos.

 

Sin embargo, un servicio de alta granuralidad, es decir, con un nivel bajo de abstracción, ofrece una capacidad menor de reutilización. Siguiendo con nuestro ejemplo, si manejamos el concepto “bicicleta”, podemos usarlo en un conjunto más reducido y específico de usos: usamos una bicicleta de montaña para ir de excursión, una bicicleta de paseo para ir por la ciudad, una bicicleta de carreras para entrenar y competir, y poco más.

 

Modelo Estático.

Para cada servicio existen los siguientes elementos que debemos identificar:

  • un proveedor del servicio, que envía el mensaje correspondiente,
  • un mensaje estándar, que contiene la información necesaria para el evento,
  • uno o varios consumidores del servicio, que reciben el mensaje,
  • y una determinada lógica de negocio, que corresponde con ciertas validaciones, acceso a datos del Ecosistema, transformaciones o cualquier procesamiento interno que requieran los datos recibidos desde el proveedor, antes de ser enviados a los consumidores.

 

Toda esta información compone el Modelo Estático del servicio, es decir, su definición desde el punto de vista formal, de estructura, y de diseño.

 

Cuando identifiquemos toda esta información es muy importante recordar los requisitos que vimos en el apartado 3. LO QUE TIENEN EN COMÚN: por ejemplo, identificar el proveedor del servicio no es señalar qué sistema concreto provee el servicio, sino el “tipo” de sistema, manteniendo el necesario nivel de abstracción que nos garantice la independencia del fabricante y de la tecnología.

 

Modelo Dinámico.

Para cada servicio deberemos, además, definir su comportamiento, es decir, su Modelo Dinámico.Se trata de definir con detalle la secuencia de comunicación que se producirá entre el proveedor y los consumidores que participan.

 

En el Modelo Dinámico debemos introducir un nuevo actor. En las necesidades que comparten todos los casos en estudio, vimos que una de ellas era la de disponer de un sistema mediador. Este sistema, como su propio nombre indica, actuará como intermediario entre los sistemas participantes. Su uso ayudará a garantizar la independencia de los distintos sistemas entre sí, y del propio usuario respecto a los sistemas implicados. El desacoplamiento es una característica clave que debemos perseguir en nuestra estrategia, para garantizar la sostenibilidad futura del Ecosistema de Información, su escalabilidad y su mantenibilidad. Lo estamos repitiendo varias veces, pero no es casualidad: realmente es muy importante y no es fácil de lograr.

 

Una técnica muy útil para especificar el patrón de comunicación que seguirán los actores, incluyendo el sistema mediador, es usar un Diagrama de Secuencia. Estos diagramas, como quizás sepas, forman parte del estándar UML. Permiten representar gráficamente de forma muy intuitiva qué hace cada actor en cada momento durante el tiempo en que están interactuando.

 

El Modelo Dinámico debe incluir, además, una descripción de la lógica de negocio que debe resolver el servicio. Algunos ejemplos de lógica de negocio son:

Mapeos

Entre el esquema del mensaje de entrada y el esquema del mensaje de salida. Es decir, indicar qué datos del mensaje de entrada debemos asignar a qué campos del mensaje de salida.

Transformaciones

a realizar sobre los datos del mensaje de entrada, para poder construir el mensaje de salida. Por ejemplo, un valor del mensaje de salida que no viene en el mensaje de entrada, pero se obtiene por combinación de varios datos que sí recibimos, o en función de algún valor que recibimos en la entrada.

Accesos a bases de datos

necesarios para tomar determinadas decisiones de enrutamiento, basadas en los datos del mensaje de entrada.

 

Políticas

Aunque lo hemos dejado para el quinto punto, en realidad este paso es previo. Quizás sería más preciso decir que este punto engloba a todos los demás. En cualquier estrategia, la definición y mantenimiento de las normas, las políticas, los procedimientos que deben seguirse por todos los participantes en la implementación de la estrategia, establecen el marco de trabajo sobre el que haremos todo lo demás.

 

Aquí estamos incluyendo, por ejemplo:

Estándar de Interoperabilidad

que establece el modelo de diseño de los mensajes y las particularidades generales a tener en cuenta en la implementación del estándar. Todo estándar se define a un nivel de abstracción alto que permite su aplicación en distintos escenarios. Es ahora, al aplicarlo a un Ecosistema de Información, cuando debemos bajar ese nivel de abstracción y concretar lo que compete a ese Ecosistema de Información, pero sin llegar a un nivel de detalle demasiado bajo. Ese detalle último corresponderá al diseño de cada mensaje, en cada caso de uso.

 

Política de reintentos

una característica de fábrica de los sistemas mediadores, que permite superar de forma automática y transparente cualquier posible problema en las comunicaciones, o en la disponibilidad de un sistema destinatario de un mensaje. Cuando algún caso en concreto requiera una política de reintentos específica, se indicará en el Modelo Dinámico de los servicios afectados.

 

Política de gestión de errores

donde se establece para todos los actores de qué manera deben procesarse los errores propios del flujo de información y la lógica de negocio de cada caso. Por tanto, quedan fuera de su alcance los errores propios de cada sistema participante.

 

Procedimientos

de todo tipo, como por ejemplo de qué manera se registrará y controlará qué sistemas usan qué servicios.

 

Seguridad

donde se detallarán las técnicas de encriptación, reglas de firewall, sistema de tokens, credenciales, etc, que se usarán para garantizar la seguridad en el envío y recepción de los mensajes.

 

¿Y quién define todo esto? Intuitivamente, está claro que tendrá que ser un equipo con cierta autoridad en el Ecosistema de Información. En las TIC es lo que se conoce como Gobernanza, otro elemento absolutamente clave para la implementación de la estrategia.

 

CONCLUSIONES

Al principio de este artículo, te decía que cuando se trata de integrar sistemas, todo es lo mismo. Y es evidente que en el Internet de las Cosas, se trata de integrar sistemas. Ya sea en las Smart Homes, en las Smart Cities o en los Connected Cars, tres Ecosistemas de Información que comparten el trasfondo del Internet de las Cosas, en el fondo todo es lo mismo.

 

Pero como hemos dicho numerosas veces en este blog, toda organización empresarial también es un Ecosistema de Información. Podemos considerarlo un cuarto caso para el propósito de esta entrada. Todo lo dicho hasta aquí, es igualmente aplicable para los casos de uso del Internet de las Cosas, así como para las empresas y organismos públicos.

 

Así que, como primera conclusión, tenemos una estrategia que es aplicable a prácticamente cualquier escenario de integración de sistemas en el que se persigan unos determinados objetivos:

  • Interoperabilidad
  • Escalabilidad
  • Sostenibilidad
  • Independencia de la tecnología
  • Independencia del proveedor/fabricante
  • Mantenibilidad
  • Orientación a procesos
  • Bajo acoplamiento

 

Por otra parte, hemos visto que, mediante la definición de normas, políticas y procedimientos desde los órganos de Gobernanza de cada Ecosistema de Información, se establece el marco de trabajo homogéneo necesario para alcanzar los objetivos que menciono arriba.

 

Y hemos presentado un boceto simplificado de una estrategia de Integración de Sistemas que permitiría alcanzar esos objetivos en cualquiera de los casos de uso que podamos imaginar, para cualquier Ecosistema de Información.

 

La estrategia presentada a muy grandes rasgos en este artículo se llama Orientación a Servicios, o también estrategia SOA, para los amigos.

El sistema mediador se conoce como middleware, y uno de sus componentes principales es el ESB (Enterprise Service Bus).

El análisis de los procesos se realiza mediante técnicas de BPM (Business Process Modeling) usando el estándar BPMN para el modelado de los procesos.

La orquestación de los eventos se realiza bajo un enfoque EDA (Event Driven Architecture), que es un estilo de diseño que promueve el uso de mensajería asíncrona, disparada en tiempo real por los eventos del Ecosistema de Información.

La mensajería se puede diseñar mediante XML y los servicios pueden implementarse mediante servicios web, usando tanto SOAP como REST (ambos estilos presentan ventajas e inconvenientes). Aunque también pueden usarse otras tecnologías, no sólo servicios web, porque los middlewares vienen equipados con numerosos adaptadores para no depender de esta variable.

 

Una estrategia para integrarlos a todos (del Internet de las Cosas a la Empresa)

 

Bueno, pues hasta aquí ha dado este artículo. Espero que te haya resultado interesante. Cualquier comentario que tengas puedes dejarlo aquí abajo. Tus opiniones siempre serán enriquecedoras.

 

Gracias por tu tiempo, y si te ha gustado esta entrada, quizás a tus contactos también les guste, así que no lo dudes y compártela en tus redes.

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This