Coulouris definió los sistemas distribuidos como “sistemas en los que los componentes de hardware y/o software existentes en una red informática se comunican y coordinan sus acciones mediante el intercambio de mensajes”.
Este concepto se ha popularizado en los últimos años debido a varios factores. El primer factor que impulsó el desarrollo de los sistemas distribuidos fue la aparición de las redes de área local de alta velocidad. Otro factor importante fue el avance tecnológico en el desempeño de las computadoras personales y el desarrollo de software para soportar aplicaciones distribuidas. Los sistemas distribuidos están ligados al concepto de Web e Internet. Con la evolución de la Web, y la aparición de nuevos espacios, interacciones, necesidades y aplicaciones, aparece el concepto de Web 2.0. Este término fue acuñado por Tim O'Reilly en 2004 para referirse a una segunda generación en la historia de la Web basada en comunidades de usuarios y una gama especial de servicios, como redes sociales, blogs, wikis o folksonomías, que fomentan la colaboración y la rapidez. intercambio de información entre usuarios.
Las primeras arquitecturas que pueden considerarse orientadas a servicios (SOA) se basaban en CORBA (Common Object Request Broker Architecture), que actuaba como una capa de abstracción para interconectar los diferentes elementos de la arquitectura y construir servicios. Otras tecnologías anteriores fueron DCOM (Modelo de objetos de componentes distribuidos) o RPC (Protocolo de procedimiento remoto). Con la necesidad de diseñar e implementar eficientemente sistemas distribuidos en la Web, surgen varios retos, algunos enfocados al propio desarrollo (rendimiento, experiencia de usuario, etc.) y otros complementarios, basados en la reutilización y compatibilidad de servicios. De estas necesidades surgen los Servicios Web, que brindan mecanismos estandarizados para interconectar diferentes usuarios con servidores de información.
ARQUITECTURAS ORIENTADAS A SERVICIOS
Según SOA (Service Oriented Architecture) son arquitecturas de software que definen el uso de servicios para dar soporte a los requerimientos del negocio, cuyo objetivo es lograr el menor acoplamiento posible entre agentes de software. Un servicio es una unidad de trabajo realizada por un proveedor de servicios para lograr un resultado final deseado por un consumidor de servicios. Tanto el proveedor de servicios como el consumidor de servicios son roles que desempeñan los agentes de software, no los propietarios del software. En un sentido general, una arquitectura orientada a servicios es una solución de software destinada a permitir que una empresa organice y haga uso de varios procesos. Con SOA, las aplicaciones de software ya no son bloques masivos de funciones y procesos. En cambio, estas aplicaciones se componen de servicios modulares ensamblados. Recuerda que un servicio es una simple función de software (como cancelar un CD). Cualquier sistema puede ejecutarlo bajo demanda, independientemente del sistema operativo, la plataforma, el lenguaje de programación o la ubicación geográfica.
Lo revolucionario de SOA no es el concepto en sí mismo, que existe desde hace mucho tiempo, sino el hecho de que se puede implementar en la WWW (World Wide Web). De la misma manera que las páginas web se cargan en cualquier plataforma, los servicios web funcionan de manera similar, independientemente de la plataforma, ya que se crean utilizando
normas universales.
La idea de SOA surge directamente de la programación orientada a objetos, lo que sugiere una relación entre los datos y su procesamiento. Por lo tanto, definen formalmente los servicios a través de interfaces que son independientes de la plataforma y el lenguaje de programación subyacentes. Estas interfaces ocultan las peculiaridades de su implementación, lo que las hace independientes del desarrollador y lenguaje de programación. A través de estas arquitecturas es posible diseñar e implementar sistemas altamente escalables que reflejen la lógica del negocio y al mismo tiempo faciliten la interacción entre diferentes sistemas propios o de terceros. La razón por la que queremos que alguien más haga el trabajo por nosotros es porque son expertos. Usar un servicio suele ser más económico y efectivo que hacerlo usted mismo. Así que la mayoría de nosotros entendemos que no podemos ser expertos en todo. La misma regla se puede aplicar a la construcción de sistemas de software.
Las interfaces son muy importantes, si no están bien definidas o no funcionan, el sistema no funciona. La integración de más interfaces es costosa y también aumenta el potencial de errores en las aplicaciones distribuidas. Las interfaces remotas son la parte más lenta de la mayoría de las aplicaciones distribuidas. Con todo esto, en lugar de construir nuevas interfaces para cada aplicación, tiene más sentido reutilizar interfaces genéricas para todas las aplicaciones.
Entonces, dado que solo tenemos algunas interfaces genéricas disponibles, debemos incluir semánticas específicas de la aplicación en los mensajes. Podemos enviar cualquier tipo de mensaje a través de nuestras interfaces, pero hay algunas reglas a seguir para decir que una arquitectura está orientada a servicios.
– En primer lugar, los mensajes deben ser descriptivos, no instructivos, ya que el proveedor del servicio es el responsable de solucionar el problema. Por ejemplo, sería similar a la situación de ir a un restaurante y decirle al camarero qué te gustaría beber y tus preferencias, pero no debemos explicarle al cocinero cómo preparar tus platos, paso a paso.
- En segundo lugar, los proveedores de servicios no podrán comprender su solicitud si sus mensajes no están escritos en un formato, estructura y vocabulario comprensibles para todos los involucrados. Por lo tanto, limitar el vocabulario y la estructura de los mensajes es una
necesarios para una comunicación eficaz. Cuanto más estrecho sea el mensaje, más fácil de entender.
- En tercer lugar, la posibilidad de prórrogas es de vital importancia. El mundo es un lugar en constante cambio, al igual que el entorno en el que vive el software. Estos cambios requieren cambios correspondientes en el software del sistema, los consumidores de servicios, proveedores y los mensajes que intercambian. Si los mensajes no son extensibles, los consumidores y proveedores están bloqueados a una versión específica del servicio. La restricción y la extensibilidad están profundamente relacionadas, necesita ambas, y aumentar una significa reducir la otra. Lo ideal es lograr un correcto equilibrio.
– Cuarto, una SOA debe tener un mecanismo que permita al consumidor descubrir un proveedor de servicios en el contexto de un servicio buscado por el consumidor. El mecanismo debe ser flexible y no un registro centralizado.
- Quinto, Servicio sin estado: Cada mensaje que un consumidor envía a un proveedor debe contener toda la información necesaria para que el proveedor lo procese. Esta restricción hace que un proveedor de servicios sea más escalable, ya que el proveedor no necesita almacenar información de estado entre solicitudes. Esto se puede llamar un "servicio de producción en masa" ya que cada solicitud se puede manejar de forma genérica. Esta restricción también brinda más visibilidad, ya que cualquier software de monitoreo puede inspeccionar de forma independiente una solicitud y extraer su intención. Esto también permite una fácil recuperación de fallas parciales ya que no hay estados intermedios, lo que hace que el servicio sea más confiable.
- Sexto, solicitudes idempotentes (sin cambios): las solicitudes duplicadas recibidas por un agente de software tienen el mismo efecto que una sola solicitud. Este requisito permite a los proveedores y consumidores aumentar la confiabilidad general de la servicio, simplemente repitiendo la solicitud si hubiera algún fallo.
Entonces podemos decir que SOA no es una herramienta, sino un conjunto de estándares para construir nuevas aplicaciones, más dinámicas y menos dependientes. SOA facilita el acceso a la información y la lógica empresarial a través de múltiples servicios de manera sistemática y también puede orquestar múltiples servicios remotos para componer uno solo. La mayoría de las definiciones identifican el uso de Servicios Web, que veremos en el próximo capítulo, en la implementación de una arquitectura orientada a servicios. Sin embargo, se puede implementar utilizando cualquier otra tecnología basada en servicios.