MIDDLEWARE HISTORIA El origen de la palabra Middleware se remonta al ao 1968, en donde la palabra es usada durante la 1968 NATO Software Engineering

Conference, siendo una idea de cmo conectar el nuevo software con sistemas ms antiguos. Durante las dcadas previas a los 90s, fue solamente descrito como un software para la gestin de conexin en redes, para cuando las tecnologas en redes alcanzaron una penetracin y visibilidad suficiente el software middleware' haba evolucionado en un conjunto de paradigmas y servicios. De esta forma se estaba ofreciendo una manera ms fcil, robusta y controlable para construir aplicaciones distribuidas. DEFINICIONES Middleware es un software de computadora que conecta componentes de software o aplicaciones para que puedan intercambiar datos entre stas. Es utilizado a menudo para soportar aplicaciones distribuidas. Esto incluye servidores web, servidores de aplicaciones, sistemas de gestin de contenido y herramientas similares. Middleware es especialmente esencial para tecnologas como XML, SOAP, servicios web y arquitecturas orientada a servicios. Middleware es una incorporacin relativamente reciente en la computacin. Obtuvo popularidad en los 80 como una solucin al problema de cmo conectar nuevas aplicaciones con viejos sistemas. De todas maneras el trmino ha sido usado desde 1968. Tambin facilitaba el procesamiento distribuido: conexin de mltiples aplicaciones para crear una aplicacin ms grande, generalmente sobre una red. El Middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogneas. CARACTERSTICAS DEL MIDDLEWARE Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos propietarios. Permite la interconectividad de los Sistemas de Informacin del Organismo. Proporciona mayor control del negocio al poder contar con informacin procedente de distintas plataformas sobre el mismo soporte. Facilita el desarrollo de sistemas complejos con diferentes tecnologas y arquitecturas. Ser confiable y disponible

Organizacin de una aplicacin distribuida en funcin al Middleware

Correo Electrnico. Provee servicios no relacionados con el negocio que residen sobre la red permitiendo interconectar usuarios. Productos de Groupware, como por ejemplo Lotus Notes. Web Browser, Web gateways. Sql Gateways. Paquetes de Electronic Data Interchange (EDI). Paquetes de Remote procedure Call (RPC). Servidores de Objetos distribuidos, como por ejemplo CORBA.

STUB Y SKELETON Esta capa es la que escucha los mtodos llamados remotamente hechos por el cliente y re direcciona estas llamadas a los servicios del RMI en el servidor, esta capa consiste de un stub y del skeleton. Para invocar a los mtodos de los objetos remotos, el request (pedido) en el lado del cliente empieza en el stub. El stub es proxy del cliente que representa el objeto remoto. Este es referenciado por el programa como si fuera cualquier otro mtodo local que est corriendo. El stub comunica el mtodo al objeto remoto a travs del skeleton que es implementado en el servidor. El skeleton es el proxy del lado del servidor que continua la comunicacin con el stub: Lee los parmetros para el mtodo llamado. Hace una llamada al servicio remoto. Acepta el valor que retorna Escribe el valor retornado de regreso al stub.

Lenguaje de definicin de interfaz El lenguaje de definicin de interfaz o IDL (Interface Definition Language), es un lenguaje que se utiliza para definir las interfaces entre los componentes de una aplicacin y es el elemento que soporta la interoperabilidad de la tecnologa. El IDL slo puede definir interfaces, no implementaciones. Al especificar las interfaces entre

objetos en CORBA, IDL es el encargado de asegurar la independencia del lenguaje de programacin utilizado. Para que esto sea posible, es necesario asegurar que los datos son correctamente intercambiados entre dos lenguajes distintos, para lo cual IDL define los tipos de datos de una forma independiente del lenguaje con las correspondencias necesarias. Por ejemplo, un tipo long en C++ de 32 bits puede corresponderse con un int de Java. OMG ha definido bastantes correspondencias con lenguajes de programacin populares, como: C, C++, COBOL, Java, Smalltalk o Ada. Tendremos principalmente dos tipos diferentes de IDL en CORBA: Stub IDL: es la interfaz esttica a los servicios declarados en las interfaces IDL, para el cliente todas las llamadas parecen locales. Actuar como proxy del objeto remoto, realizando la invocacin de mtodos remotos, incluyendo la serializacin, la recepcin de respuestas y la deserializacin. El cliente puede tener tantos stubs como interfaces IDL existan. Es generado a partir del IDL en el lenguaje de programacin del cliente (C, C++ Java, Smalltalk, Ada, ) por un compilador IDL. Skeleton IDL: es el representante esttico del cliente en el servidor. Para el servidor todas las llamadas parecen locales. Es generado a partir del IDL por un compilador IDL y realiza la deserializacin de las invocaciones del cliente. Primitivas de funcin utilizadas en el Middleware Tipos de Middleware Software intermedio general Servicios generales que requieren todos los clientes y servidores, por ejemplo: software para las comunicaciones usando el TCP/IP, software parte del sistema operativo que, por ejemplo, almacena los archivos distribuidos, software de autenticacin, el software intermedio de mensajes de clientes a servidores y viceversa.

Software intermedio de servicios. Software asociado a un servicio en particular, por ejemplo: software que permite a dos BD conectarse a una red cliente/servidor (ODBC: Conectividad abierta de BD), software de objetos distribuidos, por ejemplo la tecnologa CORBA permite que objetos distribuidos creados en distintos lenguajes coexistan en una misma red (intercambien mensajes), software intermedio para software de grupo, software intermedio asociado a productos de seguridad especficas (Conexiones Seguras: Sockets), etc.

Tuplas distribuidas (DT) Las bases de datos relacionales distribuidas ofrecen la abstraccin de tuplas distribuidas, y son el tipo de middleware ms empleado actualmente. Su SQL (Structured Query Language), permite que los programadores manipulen conjuntos de tuplas en un lenguaje natural con una semntica intuitiva y fundamentos matemticos rigurosos basados en la teora de conjuntos y el clculo de predicados

Llamada Procedure Remoto (RPC) El cliente realiza una llamada a procedimientos que estn corriendo en mquinas remotas. Pueden ser sncronos o asncronos.

Middleware orientado a mensaje (MOM) Se pueden dividir en dos tipos, espera y publicacin/suscripcin. El paso de espera se puede dividir en mensaje y espera. El paso de mensaje inicia con que la aplicacin enva un mensaje a uno o ms clientes, con el MOM del cliente. El servidor MOM, recoge las peticiones de la cola (Message Broker) en un orden o sistema de espera predeterminado. Los actos del servidor MOM son como un router y usualmente no interactan con estas. El MOM de publicacin y suscripcin acta de manera ligeramente diferente, es ms orientado a eventos. Si un cliente quiere participar por primera vez, se une al bus de informacin. Dependiendo de su funcin, si es como publicador, suscriptor y ambas, este registra un evento. El publicador enva una noticia de un evento al bus de memoria. El servidor MOM enva un anuncio al subscriptor registrado cuando la informacin est disponible

.Middleware de objetos distribuidos (DOM) Es un tipo de infraestructura que permite el acceso remoto a los objetos remotos transparente. Se basa en la llamada a procedimiento remoto (RPC) mecanismo. Algunos sistemas de DOM tambin permiten a los objetos en diferentes plataformas de interactuar, por ejemplo, CORBA. Otros ejemplos de sistemas de DOM son de Microsoft Modelo de objetos componentes distribuido (DCOM) y Enterprise JavaBeans ( EJB ) de Sun Microsystems (ahora Oracle Corporation ).

Monitores de procesamiento transaccional (TP Monitors) Es un programa que monitoriza una transaccin a medida que pasa de una etapa en un proceso a otro. El propsito del supervisor de TP es asegurarse de que la transaccin procesa por completo o, si se produce un error, a tomar las medidas adecuadas.

Supervisores de TP son especialmente importantes en tres niveles arquitecturas que utilizan el equilibrio de carga porque la operacin puede ser enviado a cualquiera de varios servidores. De hecho, muchos supervisores de TP manejan todas las operaciones de balanceo de carga, envo de transacciones a diferentes servidores en funcin de su disponibilidad Tecnologa de acceso a base de datos (DBAT) Estos servicios permiten ejecutar consultas o distintas actualizaciones tanto a archivos planos como de Bases de Datos, ubicados en uno o ms servidores, asegurando la integridad de los datos y la disponibilidad de la aplicacin. Adems, existen varias APIs que permiten la conectividad con Bases de Datos. Por ejemplo, para aplicaciones Web, los estndares de facto son MicrosoftODBC y JDBC. Framework orientado a componentes (COF) Un componente es programa que realiza una funcin especfica, diseada para operar e interactuar fcilmente con otros componentes y aplicaciones. El middleware en este caso en una configuracin de componentes. Los puntos fuertes de este middleware es que es configurable y reconfigurable. La reconfiguracin se puede realizar en tiempo de ejecucin, lo que ofrece una gran flexibilidad para satisfacer las necesidades de un gran nmero de aplicaciones. Servicio de Directorio (DS) Estos servicios proveen un eficiente y potente mtodo de ubicar y administrar recursos en una red. Por ejemplo, podemos mencionar: LDAP. En resumen, los servicios de un Middleware proveen: Ubicacin transparente de un extremo a otro de la red permitiendo interaccin con otra/s aplicacin/es o servicio/s. Independencia de los servicios de la red. Confiabilidad y disponibilidad. Escalabilidad sin perder funcionalidad. Servidores de Aplicacin (AS) A pesar de que no son una tecnologa de integracin por s mismas, son una parte importante como contenedores de lgica. Comparativa entre tipos de Middleware

Aplicaciones

Los servicios de middleware proporcionan un conjunto ms funcional de la API s para permitir una aplicacin a:

Localizar claramente a travs de la red, proporcionando as una interaccin con otro servicio o aplicacin Los datos filtrados para que sean utilizables en un ambiente pblico a travs de anonymizationprocess para la proteccin de la privacidad(por ejemplo) Ser independiente del servicio de red Ser fiable y siempre disponible Aadir los atributos complementarios como semntica en comparacin con el sistema operativo y servicios de red.

Otros de inters en el tema