Metodologías para el Desarrollo de Servicios en la Web

Coulouris definió los sistemas distribuidos como “sistemas en los que los componentes hardware y/o software existentes en una red de computadoras, se comunican y coordinan sus acciones mediante el intercambio de mensajes”.

Este concepto se ha popularizado durante los últimos años, debido a varios factores. El primer factor que impulsó el desarrollo de sistemas distribuidos fue la aparición de redes locales de alta velocidad. Otro factor importante ha sido el avance tecnológico en las prestaciones de los ordenadores personales y el desarrollo de software para soportar aplicaciones distribuidas. Los sistemas distribuidos se ligan con el concepto de Web e Internet. Con la evolución de la Web, y la aparición de nuevas áreas, interacciones, necesidades y aplicaciones, surge 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 las redes sociales, los blogs, los wikis o las folcsonomías, que fomentan la colaboración y el intercambio ágil de información entre los usuarios.

Las primeras arquitecturas que pueden considerarse orientadas a servicio (SOA) se basaban en CORBA (Common Object Request Broker Architecture), que actuaba como una capa de abstracción para interconectar los distintos elementos de la arquitectura y construir los servicios. Otras tecnologías anteriores fueron DCOM (Distributed Component Object Model) o RPC (Remote Procedure Protocol). Con la necesidad de diseñar e implementar sistemas distribuidos en la Web de forma eficiente, surgen diversos desafíos, algunos centrados en el propio desarrollo (rendimiento, experiencia de usuario, etc.) y otros complementarios, basados en la reusabilidad y compatibilidad de los servicios. Sobre estas necesidades aparecen los Servicios Web, proporcionando mecanismos estándar para interconectar a los distintos usuarios con los servidores de información.

ARQUITECTURAS ORIENTADA A SERVICIOS

Según  SOA (Service‐Oriented Architecture) son arquitecturas de software que definen el uso de servicios como soporte a los requisitos del negocio, cuyo objetivo es alcanzar el mínimo acoplamiento posible entre agentes software. Un servicio es una unidad de trabajo realizada por un proveedor de servicios para alcanzar un resultado final deseado por un consumidor del servicio. Tanto el proveedor como el consumidor del servicio son roles realizados por agentes software en lugar de sus propietarios. En un sentido general, una arquitectura orientada a servicios es una solución software que pretende permitir a la empresa organizar y hacer uso de múltiples procesos. Con SOA, las aplicaciones software ya no son enormes bloques de funciones y procesos. En cambios, estas aplicaciones se componen de servicios modulares ensamblados. Recordemos que un servicio es una función software simple (como por ejemplo, cancelar la reproducción de un CD). Puede ser ejecutada bajo demanda por cualquier sistema, sin tener en cuenta el sistema operativo, plataforma, lenguaje de programación o posición geográfica.

Lo que es revolucionario acerca de SOA no es el concepto en sí mismo, el cual ha estado presente desde hace tiempo, sino el hecho de que se puede implementar a través de la WWW (World Wide Web). De la misma forma que las páginas web se cargan en cualquier plataforma, los servicios web trabajan de forma similar, sin tener en cuenta la plataforma, ya que se construyen utilizando
estándares universales.

ImageLa idea de SOA parte directamente de la programación orientada a objetos, la cual sugiere una relación entre los datos y su procesamiento. Así, definen los servicios formalmente a través de interfaces independientes de la plataforma subyacente y del lenguaje de programación. Estas interfaces ocultan las particularidades de su implementación, lo que las hace independientes del desarrollador y del lenguaje de programación. A través de estas arquitecturas se consiguen diseñar e implementar sistemas altamente escalables que reflejan la lógica de negocio y a la vez facilitan la interacción entre distintos sistemas propietarios o de terceros. La razón por la cual queremos que alguien haga el trabajo por nosotros es porque es experto. Utilizar un servicio es generalmente más barato y efectivo que hacerlo por nosotros mismos. Así, la mayoría de nosotros comprendemos que no podemos ser expertos en todo. La misma regla se puede aplicar a la construcción de sistemas software.

Las interfaces son tremendamente importantes, si éstas no han sido bien definidas o no funcionan, el sistema no funciona. Integrar más interfaces es caro, y además incrementa la posibilidad de errores en 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 unas genéricas para todas las aplicaciones.

Así, ya que sólo disponemos de unas pocas interfaces genéricas disponibles, debemos incluir dentro de los mensajes semántica específica sobre las aplicaciones. Podemos enviar cualquier tipo de mensaje sobre nuestras interfaces, pero hay unas pocas reglas a seguir para poder decir que una arquitectura es orientada a servicio. 

‐ Primero, los mensajes deben ser descriptivos, más que instructivos, porque el proveedor del servicio es responsable de resolver el problema. Por ejemplo, sería similar a la situación de ir a un restaurante y decir al camarero lo que te gustaría tomar y tus preferencias, pero no deberíamos explicar al cocinero cómo cocinar tus platos, paso por paso. 

‐ Segundo, los proveedores de servicio no serán capaces de entender tu petición si tus mensajes no están escritos en un formato, estructura y vocabulario comprensible por todos los involucrados. Así, limitar el vocabulario y la estructura de los mensajes es una
necesidad para lograr una comunicación eficiente. Cuanto más restringido sea el mensaje, más sencillo es entenderlo.

‐ Tercero, la posibilidad de extensiones es de vital importancia. El mundo es un sitio cambiante en todo momento, y de forma similar es el entorno en el que vive el software. Estos cambios demandan cambios correspondientes en el sistema software, consumidores de servicios, proveedores, y los mensajes que intercambian. Si los mensajes no son extensibles, los consumidores y proveedores estarán bloqueados en una versión concreta del servicio. Restricción y extensibilidad están profundamente relacionadas, se necesitan ambas, e incrementar una supone una reducción de la otra. Lo ideal es lograr un correcto balance.

‐ Cuarto, una SOA debe poseer un mecanismo que permita al consumidor descubrir un proveedor de servicios bajo el contexto de un servicio buscado por el consumidor. El mecanismo debe ser flexible, y no debería ser un registro centralizado.

‐ Quinto, Servicio stateless (sin estados): Cada mensaje que envía un consumidor a un proveedor debe contener toda la información necesaria para que el proveedor la procese. Esta restricción hace más escalable a un proveedor de servicio puesto que el proveedor no tiene que almacenar información de estado entre peticiones. Esto se puede denominar “servicio de producción en masa” ya que cada petición puede ser tratada de manera genérica. Esta restricción además provee de más visibilidad, ya que cualquier software de monitorización puede inspeccionar una petición independiente y extraer su intención. Esto permite además la recuperación de forma sencilla de fallos parciales, puesto que no hay estados intermedios, haciendo el servicio más fiable.

‐ Sexto, Peticiones idempotentes (que no realizan ningún cambio): Las peticiones duplicadas recibidas por un agente software tienen el mismo efecto que una petición única. Este requisito permite que los proveedores y consumidores incrementen la fiabilidad total del servicio, simplemente repitiendo la petición si ha habido algún fallo.

Podemos decir entonces, que SOA no es una herramienta, sino un conjunto de patrones de construcción de nuevas aplicaciones más dinámicas y menos dependientes. SOA facilita el acceso a la lógica de negocios y la información entre diversos servicios de una manera sistemática, pudiendo además orquestar diversos servicios remotos para componer uno único. La mayoría de las definiciones identifican la utilización de Servicios Web, los cuales veremos en el siguiente  capítulo, en la implementación de una arquitectura orientada a servicios. No obstante, se puede implementar utilizando cualquier otra tecnología basada en servicios.

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s