Evolución de Tecnología Hacia SOA

Evolución de tecnología hacia SOA En los orígenes de Internet, las primeras computadoras en implementar sus protocolos fueron aquellas de la universidad de Berkeley. Pronto se hizo necesario crear un medio sencillo y eficaz para escribir programas capaces de intercomunicarse entre sí. Esta necesidad dio origen a la primera especificación e implementación de socket. Un Socket permite que computadoras distintas puedan intercambiar cualquier flujo de datos, de manera fiable y ordenada. Para que dos programas puedan comunicarse entre sí es necesario que se cumplan ciertos requisitos: * Que un programa sea capaz de localizar al otro. * Que ambos programas sean capaces de intercambiarse cualquier secuencia de octetos, es decir, datos relevantes a su finalidad. Para ello son necesarios los tres recursos que originan el concepto de socket: * Un protocolo de comunicaciones, que permite el intercambio de octetos. * Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora. * Un número de puerto, que identifica a un programa dentro de una computadora. Los sockets permiten implementar una arquitectura cliente-servidor. La comunicación ha de ser iniciada por uno de los programas que se denomina programa cliente. El segundo programa espera a que otro inicie la comunicación, por este motivo se denomina programa servidor. La arquitectura cliente-servidor se divide en dos partes, la parte del servidor y la parte de un conjunto de clientes. Normalmente el servidor es una máquina bastante potente que actúa de depósito de datos y funciona como un sistema gestor de base de datos (SGBD). Ambas partes deben estar conectadas entre sí mediante una red. Una representación gráfica de este tipo de arquitectura sería la siguiente.

A parte de estos existen más aplicaciones software para el correcto funcionamiento de esta arquitectura pero ya están condicionados por el tipo de sistema operativo instalado, el tipo de red en la que se encuentra, etc. Una de las primeras soluciones a esta problemática fueron los sockets, que precisamente tienen la capacidad de comunicar dos procesos, ya sea mediante datagramas o flujos de datos (streams). Sin embargo, los sockets requieren que las aplicaciones implanten sus propios protocolos para codificar y decodificar los mensajes que intercambian, lo que introduce una problemática diferente a la naturaleza del problema a resolver y aumenta la posibilidad de errores durante la ejecución. La evolución del SOA continua con una forma de procesar la información utilizando distintas maquinas llamado computación distribuida. Es una red de computadores donde los recursos informáticos son compartidos con todas las otras computadoras en el sistema. La potencia de procesamiento, la memoria y el almacenamiento de datos, son recursos de la comunidad donde los usuarios autorizados pueden entrar y realizar ciertas tareas. Una red distribuida puede ser tan simple como una colección de equipos similares funcionando con el mismo sistema operativo, o tan complejo como una red interconectada a sistemas, formada por cualquier plataforma informática que te puedas imaginar. Con esta tecnología, diferentes computadoras dentro de una red comparten uno o más recursos. En uno de estos sistemas considerado ideal, todos los recursos son compartidos, convirtiendo una red de computadoras en un potente supercomputador. Con el interfaz adecuado, acceder a uno de estos sistemas no es muy diferente de que acceder a los recursos de una máquina local. Toda computadora autorizada tendrá acceso a una potencia de procesamiento enorme, y una gran capacidad de almacenamiento. Estos sistemas trabajan con el principio de los recursos combinados. Se comparte toda la carga a través de múltiples computadoras para completar tareas de forma más eficiente y rápida. Los sistemas de computación distribuida enlazan los recursos de red todos juntos, de una forma tal, que permite a una sola computadora heredar la potencia del resto de computadoras en el sistema.

Dentro del ámbito del cómputo distribuido se incorpora fuertemente la tecnología orientada a objetos, debido a que en el paradigma basado en objetos el estado de un programa ya se encuentra distribuido de manera lógica en diferentes objetos, lo que hace a la distribución física de estos objetos en diferentes procesos o computadoras una extensión natural. El middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Funciona como una capa de abstracción de software distribuida, que se sitúa entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). El middleware nos abstrae de la complejidad y heterogeneidad de las redes de comunicaciones subyacentes, así como de los sistemas operativos y lenguajes de programación, proporcionando una API para la fácil programación y manejo de aplicaciones distribuidas. Dependiendo del problema a resolver y de las funciones necesarias, serán útiles diferentes tipo de servicios de middleware. Algunos ejemplos que utilizan la tecnología middleware son: RPC, RMI, CORBA y Monitor de transacciones. La primera alternativa que surgió al empleo de los sockets (y que se implementa en base a ellos), son las llamadas a procedimientos remotos (RPC) donde la comunicación entre los elementos que componen el sistema distribuido, se realiza mediante la invocación de funciones que se encuentran en espacios de direcciones diferentes. El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de computadora ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC. Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente. Como es de esperar, en los lenguajes cuyo paradigma de programación no es el procedimental, sino el orientado a objetos, se requiere ya no invocar procedimientos remotos, sino a métodos de objetos remotos. La invocación remota de métodos de Java es un modelo de objetos distribuidos, diseñado específicamente para el lenguaje Java, por lo que mantiene la semántica del modelo de objetos locales de Java, facilitando de esta manera la implantación y el uso de objetos distribuidos. En el modelo de

objetos distribuidos de Java, un objeto remoto es aquel cuyos métodos pueden ser invocados por objetos que se encuentran en una máquina virtual (MV) diferente. Los objetos de este tipo se describen por una o más interfaces remotas que contienen la definición de los métodos del objeto que es posible invocar remotamente. La invocación remota de un método (RMI) es la acción de invocar un método de una interfaz remota de un objeto remoto. La invocación de un método de un objeto remoto tiene exactamente la misma sintaxis de invocación que la de un objeto local. Un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos es CORBA (Common Object Request Broker Architecture, arquitectura común de intermediarios en peticiones a objetos). En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información. CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java y Python. Hay también implementaciones para Perl y TCL. CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware. Un monitor de transacciones es un conjunto de uno o más componentes (no necesariamente en el sentido de componentes de objetos) que brindan el soporte para el diseño, desarrollo, configuración y operación de confiables aplicaciones de transacciones distribuidas. Esto significa que de alguna manera se debe garantizar las propiedades ACID para las aplicaciones, y también incluye la puesta en marcha de los procesos servidores, la canalización de los mensajes de solicitud/respuesta y algún tipo de supervisión y equilibrio de cargas.

Un monitor de transacciones puede ser concebido como una estructura pre-construida que ayuda desarrollar y administrar una aplicación cliente/servidor, y su principal función es garantizar las propiedades ACID, mientras que al mismo tiempo debe colaborar para mantener un alto rendimiento. En términos generales, podemos decir que SOA es una arquitectura para computación distribuida que trata al software como servicios disponibles a través de la red. SOA no es completamente nuevo, CORBA es un ejemplo de orientación a servicios. Algunos aspectos de la arquitectura orientada a servicios se han utilizado durante bastante tiempo. Por ejemplo, las empresas utilizan la tecnología de intercambio de mensajes durante décadas para integrar aplicaciones. SOA es una arquitectura de sistemas distribuidos caracterizada por las siguientes propiedades: 

Visión lógica: El servicio es una visión abstracta y lógica de los programas, base de datos, procesos de negocio, entre otros, definido en términos de lo que hace, normalmente ejecutando una operación de negocio.



Orientación al mensaje: el servicio es formalmente definido en términos de los mensajes intercambiados entre los proveedores y los consumidores. La estructura interna y la implementación son ajenas a propósito. Usando SOA, un usuario no puede y no necesitaría saber los detalles de implementación de un servicio.



Orientación a la descripción: Un servicio es descrito por meta-datos procesables por maquinas. Solo los detalles expuestos al público que son importantes para utilizar el servicio deben ser descritos. La semántica del servicio debe ser documentada, directa o indirectamente, por su descripción.



Granularidad: los servicios tienden a utilizar un numero reducido de operaciones con un a complejidad relativamente grande en las operaciones llevadas a cabo.



Orientación a la red: se pueden utilizar los servicios a través de una red, pero no es obligatorio.



Neutralidad de la plataforma: los mensajes se envían en un formato normalizado independiente de la plataforma a través de las interfaces. XML es el formato mas obvio que atiende a es a restricción.