SOA

En Facultad nos enseñan que para comprender una realidad compleja se debe dividirla y de esta manera analizar cada componente y comprenderlo para luego analizar la totalidad de la realidad. Utilizaremos este método para definir la Arquitectura orientada a Servicio. Primero analicemos el término servicio.

Servicio tradicionalmente se ha utilizado para describir una función de negocio autocontenida, con una interfaz bien definida y estable, que recibe requerimientos de sus clientes. El servicio no depende del contexto de sus clientes y puede ser consumido por varios sistemas sin ser modificado. Los servicios son instalados (o desplegados) una única vez, esto lo diferencia de los componentes que deben ser incluidos dentro del contexto de cada aplicación que requiera de su uso y permanecen disponibles, sin consumir recursos hasta que son invocados.

Propiedades de un servicio:

· Interfaz bien definida

· Autocontenido

· No depende del contexto de sus clientes

· No requiere ser desplegado con cada cliente

Luego de definir servicio nos especificaremos arquitectura. Una definición reconocida es la de Clements: La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones.

Una vez aclarada la definición de servicio y arquitectura, podemos avanzar sobre la de SOA. Se podría definir como un estilo arquitectónico que propone modelar la empresa como una colección de servicios expuestos en la red. Nos propone ver a la empresa no como sistemas aislados si no como un todo.

La principal utilidad de los servicios web es que promueven la interoperabilidad entre diferentes plataformas, sistemas y lenguajes. Con servicios web, por ejemplo, sería posible integrar una aplicación Windows desarrollada con Microsoft .NET con una aplicación desarrollada en J2EE desplegada en un servidor de aplicaciones bajo un sistema Linux.

Alrededor de los Web services, que dominan el campo de un estilo SOA más amplio que podría incluir otras opciones, se han generado las controversias que usualmente acompañan a toda idea exitosa. Al principio hasta resultaba difícil encontrar una definición aceptable y consensuada que no fuera una fórmula optimista de mercadotecnia. El grupo de tareas de W3C, por ejemplo, demoró un año y medio en ofrecer la primera definición canónica apta para consumo arquitectónico, que no viene mal reproducir aquí:

Un Web service es un sistema de software diseñado para soportar interacción máquina-a-máquina sobre una red. Posee una interfaz descripta en un formato procesable por máquina (específicamente WSDL). Otros sistemas interactúan con el Web service de una manera prescripta por su descripción utilizando mensajes SOAP, típicamente transportados usando HTTP con una serialización en XML en conjunción con otros estándares relacionados a la Web

Un servicio es una entidad de software que encapsula funcionalidad de negocios y proporciona dicha funcionalidad a otras entidades a través de interfaces públicas bien definidas.

Los componentes del estilo (o sea los servicios) están débilmente acoplados. El servicio puede recibir requerimientos de cualquier origen. La funcionalidad del servicio se puede ampliar o modificar sin rendir cuentas a quienes lo requieran. Los servicios son las unidades de implementación, diseño e implementación.

Como todos los otros estilos, las SOA poseen ventajas y desventajas. Como se trata de una tecnología que está en su pico de expansión, virtudes y defectos están variando mientras esto se escribe.

SOA no es un concepto concreto para un área de la empresa, si no que dependiendo del punto de vista que se emplea. Ya que un ejecutivo de negocio lo puede ver como un conjunto de servicios de negocio, un arquitecto de software lo vera como un estilo arquitectónico y el desarrollador un conjunto de estándares, herramientas y tecnologías concretas que permiten llevar a cabo sus tareas.