Desmitificar el middleware
Algunos conceptos sobre esta tecnología de conexión
El middleware, una tecnología de “conexión”, es un elemento crucial en la empresa integrada, pero también es un campo de minas de términos dialectales e imprecisos. La siguiente es una introducción a los conceptos más importantes sobre un software que es capaz de conectar aplicaciones que les permite a su vez el intercambio de datos.
Cualquiera que sienta confusión respecto al concepto de middleware (software intermedio) deberá saber que pertenece a un club amplio de personas, ya que se trata de un término cuyo significado se expande y se contrae con el tiempo. Desafortunadamente, las discusiones sobre middleware comienzan con frecuencia de manera sencilla, pero ascienden en espiral rápidamente para incluir términos como colas asíncronas, monitores de objetos y diversas variantes del acrónimo COM (Component Object Model). Pero, ¿qué es el middleware? Esencialmente, es software que conecta aplicaciones, permitiéndoles intercambiar datos. De este modo, ofrece ventajas clave frente a la conexión fija o hardwiring de aplicaciones, que generalmente requiere añadir codificación a todas las aplicaciones participantes, informándoles de los detalles sobre cómo comunicarse entre sí. Además, el middleware añade un tercer elemento independiente a esa transacción: una función de conversión o traducción.
¿Por qué utilizar el middleware?
Desde un punto de vista comercial, la conectividad entre aplicaciones es hoy una realidad necesaria. Por ejemplo, las aplicaciones de taller, inventario, cuentas por cobrar y planificación avanzada necesitan comunicarse entre sí para que las compañías puedan presentar ofertas exactas a los clientes y para que los ejecutivos puedan adoptar con rapidez sus decisiones. La actividad del e-business en particular requiere una integración mucho mayor, ya que en Internet los clientes desean ver al mismo tiempo varios tipos de información actualizadas al minuto: especificaciones de producto, disponibilidad, fechas de entrega y estados de cuenta. Según la consultora The Standish Group, los centros de llamadas de clientes tienen empleados conectados a múltiples aplicaciones para responder a esos tipos de consultas y esto está bien cuando se les está pagando por hacerlo, pero cuando se comienza a permitir que los clientes accedan ellos mismos a esa información, resulta demasiado complicado. Precisamente es aquí donde entra en acción el middleware, para agrupar todas esas aplicaciones y conectarlas a un front-end Web, ocultando así la complejidad a la vista del cliente.
Desde un punto de vista técnico, el middleware ofrece beneficios, dependiendo del tipo de producto que se elija. En primer lugar, brinda simplicidad. En los entornos de proceso corporativo actuales, muchas aplicaciones tienen que compartir datos. Poner un middleware entre ellos puede significar que cada aplicación sólo necesitará una interfaz (con el middleware) en lugar de una interfaz separada con cada aplicación con la que desea comunicarse. Sin embargo, si se están conectando sólo dos aplicaciones entre sí, podría resultar más complicado introducir middleware que codificar las dos aplicaciones de forma que puedan comunicarse una con otra.
Otra de las ventajas es la persistencia, es decir, el middleware puede capturar datos y retenerlos hasta que hayan sido registrados de manera apropiada por todas las aplicaciones o bases de datos que necesitan la información. Por último, la tercera ventaja son los servicios, ya que si los datos tienen que ser comprobados respecto a integridad, o tienen que ser impresos, reconciliados con datos de otras aplicaciones, fraccionados o reformateados, hay varios tipos de middleware que pueden realizar esas tareas eficientemente. Eso significa que no hay que codificar esos servicios una y otra vez para cada aplicación que los utiliza. Al evolucionar los productos middleware, aumenta la amplitud de los servicios que pueden ofrecer. Los vendedores que comercializan estos potentes productos intentan con frecuencia inhibirse utilizando el término middleware.
¿Por qué es confuso?
Existen tres motivos que explican la confusión que hay acerca del middleware. Uno es que el espacio tecnológico está lleno de términos incomprensibles, porque existe una gran cantidad de detalles técnicos legítimos. En segundo lugar, los vendedores suelen cambiar con regularidad su terminología y los nombres de sus productos y, en tercero, los productos aumentan en funcionalidad, lo que hace más difícil delinear las diversas categorías.
En cuanto a los tipos de middleware, no es raro que las compañías mantengan varios en activo al mismo tiempo, de forma que diferentes tipos de ellos resultan más apropiados para diferentes tareas de integración. Las compañías grandes, que generalmente presentan requerimientos de integración más complejos, tienden a gravitar hacia productos middleware más sofisticados, como EAI (Enterprise Application Integration). Un tipo de middleware son los RPCs y gateways de bases de datos. En realidad, aunque quizás no son verdaderamente middleware, se incluyen aquí por motivos de contexto. Ambos son formas antiguas de manejar la conectividad de las aplicaciones, en particular en entornos de proceso distribuido. RPC o Remote Procedure Call (llamada remota de procedimientos) consiste en una porción de codificación incluida en una aplicación cliente y destinada a invocar un procedimiento en la aplicación del servidor. De acuerdo con la definición actual, las llamadas RPC no son middleware propiamente dicho y, aunque se siguen utilizando, son un método que es sustituido con frecuencia por el moderno middleware, porque requieren que los programadores las reescriban una y otra vez cuando conectan juntas varias aplicaciones. Hay otros enfoques de middleware que resultan con frecuencia más eficientes al aumentar la cantidad de aplicaciones. Por su parte, los gateways o pasarelas de bases de datos encajan mejor en la definición de middleware que los llamados RPC, ya que son un tercer medio que facilita el acceso a los datos. Estos gateways conectan aplicaciones a un tipo específico de plataforma de base de datos.
Otra clase de middleware es el orientado a mensajes o MOM, cuyos principales ejemplos son el MQSeries de IBM o el MSMQ de Microsoft. El middleware MOM (Message-Oriented Middleware) es un antiguo conocido. Se hace cargo de transmitir datos de una aplicación a otra depositando esos datos en un formato de mensaje, de forma parecida al funcionamiento del correo electrónico, así que si se comprende el correo electrónico, se comprende el principio en el que se basa MOM. Lo mismo que sucede con el correo electrónico, una ventaja clave de MOM es que los datos procedentes de una aplicación A van a una cola (algo así como una zona de espera) y pueden ser extraídos más tarde, en caso necesario, por una aplicación B. Esto protege la integridad de los datos si, por ejemplo, sucede que la aplicación B está detenida para ser cargada de nuevo en el momento en que la aplicación A está intentando transmitir información. Bajo este enfoque asíncrono, el servidor de middleware espera a que la aplicación B comience a funcionar de nuevo, y después entrega en la secuencia correcta los datos que están en la cola. MOM se utiliza para intercambios simples de datos en una dirección, cuando se están realizando pocas operaciones con los datos y los tiempos para el intercam
Cualquiera que sienta confusión respecto al concepto de middleware (software intermedio) deberá saber que pertenece a un club amplio de personas, ya que se trata de un término cuyo significado se expande y se contrae con el tiempo. Desafortunadamente, las discusiones sobre middleware comienzan con frecuencia de manera sencilla, pero ascienden en espiral rápidamente para incluir términos como colas asíncronas, monitores de objetos y diversas variantes del acrónimo COM (Component Object Model). Pero, ¿qué es el middleware? Esencialmente, es software que conecta aplicaciones, permitiéndoles intercambiar datos. De este modo, ofrece ventajas clave frente a la conexión fija o hardwiring de aplicaciones, que generalmente requiere añadir codificación a todas las aplicaciones participantes, informándoles de los detalles sobre cómo comunicarse entre sí. Además, el middleware añade un tercer elemento independiente a esa transacción: una función de conversión o traducción.
¿Por qué utilizar el middleware?
Desde un punto de vista comercial, la conectividad entre aplicaciones es hoy una realidad necesaria. Por ejemplo, las aplicaciones de taller, inventario, cuentas por cobrar y planificación avanzada necesitan comunicarse entre sí para que las compañías puedan presentar ofertas exactas a los clientes y para que los ejecutivos puedan adoptar con rapidez sus decisiones. La actividad del e-business en particular requiere una integración mucho mayor, ya que en Internet los clientes desean ver al mismo tiempo varios tipos de información actualizadas al minuto: especificaciones de producto, disponibilidad, fechas de entrega y estados de cuenta. Según la consultora The Standish Group, los centros de llamadas de clientes tienen empleados conectados a múltiples aplicaciones para responder a esos tipos de consultas y esto está bien cuando se les está pagando por hacerlo, pero cuando se comienza a permitir que los clientes accedan ellos mismos a esa información, resulta demasiado complicado. Precisamente es aquí donde entra en acción el middleware, para agrupar todas esas aplicaciones y conectarlas a un front-end Web, ocultando así la complejidad a la vista del cliente.
Desde un punto de vista técnico, el middleware ofrece beneficios, dependiendo del tipo de producto que se elija. En primer lugar, brinda simplicidad. En los entornos de proceso corporativo actuales, muchas aplicaciones tienen que compartir datos. Poner un middleware entre ellos puede significar que cada aplicación sólo necesitará una interfaz (con el middleware) en lugar de una interfaz separada con cada aplicación con la que desea comunicarse. Sin embargo, si se están conectando sólo dos aplicaciones entre sí, podría resultar más complicado introducir middleware que codificar las dos aplicaciones de forma que puedan comunicarse una con otra.
Otra de las ventajas es la persistencia, es decir, el middleware puede capturar datos y retenerlos hasta que hayan sido registrados de manera apropiada por todas las aplicaciones o bases de datos que necesitan la información. Por último, la tercera ventaja son los servicios, ya que si los datos tienen que ser comprobados respecto a integridad, o tienen que ser impresos, reconciliados con datos de otras aplicaciones, fraccionados o reformateados, hay varios tipos de middleware que pueden realizar esas tareas eficientemente. Eso significa que no hay que codificar esos servicios una y otra vez para cada aplicación que los utiliza. Al evolucionar los productos middleware, aumenta la amplitud de los servicios que pueden ofrecer. Los vendedores que comercializan estos potentes productos intentan con frecuencia inhibirse utilizando el término middleware.
¿Por qué es confuso?
Existen tres motivos que explican la confusión que hay acerca del middleware. Uno es que el espacio tecnológico está lleno de términos incomprensibles, porque existe una gran cantidad de detalles técnicos legítimos. En segundo lugar, los vendedores suelen cambiar con regularidad su terminología y los nombres de sus productos y, en tercero, los productos aumentan en funcionalidad, lo que hace más difícil delinear las diversas categorías.
En cuanto a los tipos de middleware, no es raro que las compañías mantengan varios en activo al mismo tiempo, de forma que diferentes tipos de ellos resultan más apropiados para diferentes tareas de integración. Las compañías grandes, que generalmente presentan requerimientos de integración más complejos, tienden a gravitar hacia productos middleware más sofisticados, como EAI (Enterprise Application Integration). Un tipo de middleware son los RPCs y gateways de bases de datos. En realidad, aunque quizás no son verdaderamente middleware, se incluyen aquí por motivos de contexto. Ambos son formas antiguas de manejar la conectividad de las aplicaciones, en particular en entornos de proceso distribuido. RPC o Remote Procedure Call (llamada remota de procedimientos) consiste en una porción de codificación incluida en una aplicación cliente y destinada a invocar un procedimiento en la aplicación del servidor. De acuerdo con la definición actual, las llamadas RPC no son middleware propiamente dicho y, aunque se siguen utilizando, son un método que es sustituido con frecuencia por el moderno middleware, porque requieren que los programadores las reescriban una y otra vez cuando conectan juntas varias aplicaciones. Hay otros enfoques de middleware que resultan con frecuencia más eficientes al aumentar la cantidad de aplicaciones. Por su parte, los gateways o pasarelas de bases de datos encajan mejor en la definición de middleware que los llamados RPC, ya que son un tercer medio que facilita el acceso a los datos. Estos gateways conectan aplicaciones a un tipo específico de plataforma de base de datos.
Otra clase de middleware es el orientado a mensajes o MOM, cuyos principales ejemplos son el MQSeries de IBM o el MSMQ de Microsoft. El middleware MOM (Message-Oriented Middleware) es un antiguo conocido. Se hace cargo de transmitir datos de una aplicación a otra depositando esos datos en un formato de mensaje, de forma parecida al funcionamiento del correo electrónico, así que si se comprende el correo electrónico, se comprende el principio en el que se basa MOM. Lo mismo que sucede con el correo electrónico, una ventaja clave de MOM es que los datos procedentes de una aplicación A van a una cola (algo así como una zona de espera) y pueden ser extraídos más tarde, en caso necesario, por una aplicación B. Esto protege la integridad de los datos si, por ejemplo, sucede que la aplicación B está detenida para ser cargada de nuevo en el momento en que la aplicación A está intentando transmitir información. Bajo este enfoque asíncrono, el servidor de middleware espera a que la aplicación B comience a funcionar de nuevo, y después entrega en la secuencia correcta los datos que están en la cola. MOM se utiliza para intercambios simples de datos en una dirección, cuando se están realizando pocas operaciones con los datos y los tiempos para el intercam
