Evolución de los Sistemas Operativos

Sinceramente no entiendo (o quizás es muy temprano y ese es el problema) cuál es la necesidad imperiosa de salir en defensa de productos millonarios de Google, simplemente porque alguien (en este caso yo) los pone en vereda… Esa necesidad de abrazar al gigante cual Jack, para ver si le podes sacar alguno de los huevos de oro…

En fin, quizás soy muy inocente, o, como dije antes, quizás es muy temprano. Pero retomemos con la evolución de los sistemas operativos, de la cual pueden pasar por la primera parte aquí.

Sistemas Distribuidos con Objetos

A medida que fue aumentando la complejidad de las soluciones distribuidas fue necesario incorporar conceptos, metodologías y buenas practicas en la construcción de software y llevarlas al entorno distribuido.

El concepto de objeto en el sentido clásico de la Programacion Orientada a Objetos y que tiene sus raíces principales en el lenguaje Smalltalk, se mantiene a nivel de diseño de aplicaciones pero cambia algunas características cuando se lo lleva a un entorno distribuido.

Un objeto distribuido es un objeto (componente funcional con estado interno, comportamiento, heredable y encapsulado), que por estar en un entorno distribuido también debe ser:

Transaccional: los cambios de estado que produce se deben ejecutar completamente o no ejecutarse.
Seguro: debe evitar vulnerabilidades que corrompa el estado del sistema.
Lockeable: debe fijar un cerramiento que garantice su ejecución correcta ante accesos concurrentes.
Persistente: su estado interno debe conservarse mas alla de su ciclo de vida.

Esta definición de objeto distribuido nos conduce a la necesidad de contar con una infraestructura que facilite la comunicación entre este tipo de componentes, logrando a su vez que logren esta comunicación a través de distintas plataformas de ejecución, sistemas operativos y lenguajes de programación.

Así surge el estándar CORBA (Common Object Request Broker Architecture), definido por la OMG (Object Management Group no Oh My God!!) y que surge de la iniciativa de un consorcio de empresas interesadas en establecer una arquitectura interoperable sobre la base del paradigma orientado a objetos. CORBA se constituye asi en un ejemplo de sistema distribuido basado en objetos.

Entre los elementos distintivos del estándar y que se puede decir que sentaron las bases para lo que se conoce actualmente como web services, encontramos:

Un lenguaje de especificación de interface, IDL Interface Definition Language, que define los limites de las componentes o sea las interfaces contractuales con los potenciales clientes.
Un bus de objetos u ORB (Object Request Broker) que comunican objetos independientes de su locación. El cliente se despreocupa de los mecanismos de comunicación con los que se activan o almacenan los objetos servidores.

Provee un vasto conjunto de servicios de middleware distribuido y tiene claramente un mecanismo de comunicación mucho mas complicado que los clásicos RPC y MOM.

Integración de Aplicaciones

Mas allá de los esfuerzos por construir estándares para mejorar la interoperatividad y de la existencia de plataformas Web mucho mas accesibles al programador y al usuario, el desarrollo de aplicaciones distribuidas a gran escala, seguía adoleciendo de problemas de integración.

La idea de construcción de aplicaciones integradas permitió que las organizaciones desarrollen software que resuelva cada parte de su negocio y se integre con aplicaciones que gestionen la parte administrativa de dicho negocio. En este sentido la idea de integración de aplicaciones comienza a cobrar un sentido muy relevante.

En este contexto surgen los sistemas ERP (Enterprise Resource Planning) que proveen variada funcionalidad integrada por un único repositorio de datos.

No se tardo demasiado en intentar agregar valor a los desarrollos de las organizaciones aportando sistemas de CRM (Customer Relationship Management) o sistemas de DataWareHouse que requieren algún tipo de integración con los sistemas de índole operativa o propia del negocio.

Esta integración se enfoca principalmente en la integración vía el modelo de datos. Este tipo de integración ha sufrido una evolución e incluye diversas variantes que se describen a continuación.

Integración Punto a Punto

Se basa en integración uno a uno sustentada generalmente por un middleware asincrónico basado en colas de mensajes. Si bien es un esquema de alta disponibilidad, dada por el mecanismo de comunicación, es rígido y difícil de adaptar a los cambios, ademas de resultar muy costoso de gestionar, monitorear y extender. Es una arquitectura accidental, completamente sincrónica, de grano grueso y poco escalable.

Integración por Adaptadores

La interacción se realiza por un hub donde se conecta cada elemento a integrar previa construcción del adaptador correspondiente para poder enchufarse. Cada uno de los elementos esta desconectado y no requiere utilizar el mismo lenguaje ya que existen adaptadores para establecer la comunicación.

La complejidad esta en la construcción del adaptador.

Mediador de Mensajes

Este mecanismo de integración representa una evolución del modelo anterior hacia una generalización del hub permitiendo extraer la lógica de la integración fuera de las aplicaciones. Se define declarativamente la forma de comunicación de las aplicaciones y se traslada al mediador o broker la lógica necesaria para producir las transformaciones que generen salidas validas para el otro extremo.

Utiliza colas para garantizar la distribución de los mensajes, que se manejan con un esquema de publicador/suscriptor. Esto asegura que el trafico que se genera sea solamente el requerido.