Messaging

Messaging transfiere paquetes de datos de forma confiable, frecuente, inmediata y asíncronamente, usando formatos de datos personalizados.

La desincronización es importante porque se pueden enviar datos sin estar listos para recibirlos aún. El desacoplamiento de los formatos de datos hace que múltiples sistemas puedan recibir mensajes.

Sistemas de Mensajería

Podemos encontrar los siguientes componentes:

Message Channel: Es una conexión particular dentro de un sistema de mensajería que permite a las aplicaciones transmitir información de manera predeterminada y predecible. Un conjunto de canales bien diseñados forman un Message Bus que actúa como un API para un grupo entero de aplicaciones. Una aplicación escribe información al canal y la otra lee información de ese canal particular. Existen diferentes canales de mensajería para los diferentes tipos de información que las aplicaciones quieran transmitir. Para anular las diferencias entre diferentes tipos de datos existen DataTypes Channels, y para mensajes inválidos se utiliza Invalid Message Channel. Existen dos tipos de Message Channels:

• Point-to-Point Channels
• Publish-Subscribe Channels

Message: Es una pieza de datos transmitida como byte-stream a través de una canal que consiste de dos partes básicas:

• Header: información usada por el sistema de mensajería que describe el datos siendo transmitido, su origen, su destino, etc.
• Body: el dato siendo transmitido, generalmente ignorado por el sistema de mensajería y simplemente transmitido como es.

Cualquier dato transmitido dentro de un sistema de mensajería puede ser convertido dentro de uno o más mensajes enviados a través de canales de mensajería.

Tipos de mensaje:

Command Message: invoca un procedimiento en otra aplicación

Document Message: pasa una serie de datos a otra aplicación

Event Message: notificar a una aplicación el cambio en otra

Pipes and Filters: Divide una tarea de procesamiento más grande en una secuencia de pasos independientes más pequeños (filtros) que son conectados por canales (pipes). Estas tareas pueden ser desencriptar mensajes, utilizar un mecanismo de autenticación o eliminar mensajes duplicados. También se pueden procesar en paralelo. Son muy utilizados para tareas de prueba y comparar resultados. 

Message Router: Se conectan a múltiples canales de salida (Message Channels). Consumen un mensaje de un Message Channel y república a un diferente Message Channel dependiendo de una serie de condiciones. Si cambia el tipo de mensaje, nuevos componentes de procesamiento son agregados, o cambian las reglas de enrutamiento, solo se debe cambiar el Message Router.

Message Translator:Traduce un formato de dato entre filtros o aplicaciones, ayudando a desacoplar los formatos de datos entre aplicaciones.

Message Endpoint (especialización de Channel Adapter): Una aplicación puede contener un conjunto de código que conecta y une el dominio de mensajería. Conectando una aplicación a un canal de mensajería usando un Message Endpoint, se utiliza un cliente del sistema de mensajería para que la aplicación pueda enviar o recibir mensajes. Esto hace que para la aplicación sea transparente el conocimiento sobre formatos de datos, canales de mensajería o cualquier otro detalle de comunicación, es decir, se encapsula el sistema de mensajería y personaliza el API de mensajería para una aplicación específica o una tarea. Si el sistema de mensajería cambia, solo basta con cambiar el Message Point. Una aplicación puede tener más de un Message Point debido a que un Message Point es específico a un canal.

RESTfull

REST define un set de principios arquitectónicos por los cuales se diseñan servicios web haciendo foco en los recursos del sistema, incluyendo cómo se accede al estado de dichos recursos y cómo se transfieren por HTTP hacia clientes escritos en diversos lenguajes. REST emergió en los últimos años como el modelo predominante para el diseño de servicios. De hecho, REST logró un impacto tan grande en la web que prácticamente logró desplazar a SOAP y las interfaces basadas en WSDL por tener un estilo bastante más simple de usar.

Los 4 principios de REST

Una implementación concreta de un servicio web REST sigue cuatro principios de diseño fundamentales:

1.    Utiliza los métodos HTTP de manera explícita:

Una de las características claves de los servicios web REST es el uso explícito de los métodos HTTP, siguiendo el protocolo definido por RFC 2616. Por ejemplo, HTTP GET se define como un método productor de datos, cuyo uso está pensado para que las aplicaciones cliente obtengan recursos, busquen datos de un servidor web, o ejecuten una consulta esperando que el servidor web la realice y devuelva un conjunto de recursos.

REST hace que los desarrolladores usen los métodos HTTP explícitamente de manera que resulte consistente con la definición del protocolo. Este principio de diseño básico establece una asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP. De acuerdo a esta asociación:

·         se usa POST para crear un recurso en el servidor

·         se usa GET para obtener un recurso

·         se usa PUT para cambiar el estado de un recurso o actualizarlo

·         se usa DELETE para eliminar un recurso

2.    No mantiene estado:

Los servicios web REST necesitan escalar para poder satisfacer una demanda en constante crecimiento. Se usan clústeres de servidores con balanceadores de carga y alta disponibilidad, proxies, y gateways de manera de conformar una topología servicial, que permita transferir peticiones de un equipo a otro para disminuir el tiempo total de respuesta de una invocación al servicio web. El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de servicios web REST envíen peticiones completas e independientes; es decir, se deben enviar peticiones que incluyan todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan redireccionar y gestionar la carga sin mantener el estado localmente entre las peticiones.

Una petición completa e independiente hace que el servidor no tenga que recuperar ninguna información de contexto o estado al procesar la petición. Una aplicación o cliente de servicio web REST debe incluir dentro del encabezado y del cuerpo HTTP de la petición todos los parámetros, contexto y datos que necesita el servidor para generar la respuesta. De esta manera, el no mantener estado mejora el rendimiento de los servicios web y simplifica el diseño e implementación de los componentes del servidor, ya que la ausencia de estado en el servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.

3.    Expone URL´s con forma de directorios:

Desde el punto de vista del cliente de la aplicación que accede a un recurso, la URI determina qué tan intuitivo va a ser el web service REST, y si el servicio va a ser utilizado tal como fue pensado al momento de diseñarlo. La tercera característica de los servicios web REST es justamente sobre las URL’s.

Las URI de los servicios web REST deben ser intuitivas, hasta el punto de que sea fácil adivinarlas. Pensemos en las URI como una interfaz auto-documentada que necesita de muy poca o ninguna explicación o referencia para que un desarrollador pueda comprender a lo que apunta, y a los recursos derivados relacionados.

Una forma de lograr este nivel de usabilidad es definir URL’s con una estructura al estilo de los directorios. Este tipo de URL’s es jerárquica, con una única ruta raíz, y va abriendo ramas a través de las sub rutas para exponer las áreas principales del servicio. De acuerdo a esta definición, una URI no es solamente una cadena de caracteres delimitada por barras, sino más bien un árbol con subordinados y padres organizados como nodos. Por ejemplo, en un servicio de hilos de discusiones que tiene temas varios, se podría definir una estructura de URL’s como esta:

http://www.miservicio.org/discusion/temas/{tema}

Algunas guías generales más al momento de crear URL’s para un servicio web REST:

·         ocultar la tecnología usada en el servidor que aparecería como extensión de archivos (.jsp, .php, .asp), de manera de poder portar la solución a otra tecnología sin cambiar las URI.

·         mantener todo en minúsculas.

·         sustituir los espacios con guiones o guiones bajos (uno u otro).

·         evitar el uso de strings de consulta.

·         en vez de usar un 404 Not Found si la petición es una URI parcial, devolver una página o un recurso predeterminado como respuesta.

4.    Transfiere XML, JSON o Ambos :

La representación de un recurso en general refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. La representación del recurso son simples "fotos" en el tiempo. Esto podría ser una representación de un registro de la base de datos que consiste en la asociación entre columnas y tags XML, donde los valores de los elementos en el XML contienen los valores de las filas. O, si el sistema tiene un modelo de datos, la representación de un recurso es una fotografía de los atributos de una de las cosas en el modelo de datos del sistema. Estas son las cosas que serviciamos con servicios web REST.

La última restricción al momento de diseñar un servicio web REST tiene que ver con el formato de los datos que la aplicación y el servicio intercambian en las peticiones/respuestas. Acá es donde realmente vale la pena mantener las cosas simples, legibles por humanos, y conectadas.

Por último, es bueno construir los servicios de manera que usen el atributo HTTP Accept del encabezado, en donde el valor de este campo es un tipo MIME. De esta manera, los clientes pueden pedir por un contenido en particular que mejor pueden analizar. Algunos de los tipos MIME más usados para los servicios web REST son:

• MIME-TYPE                          Content/Type
• JSON                                     Application/Json
• XML                                       Application/Xml
• XHTML                                  Application/Xhtm + Xml

Esto permite que el servicio sea utilizado por distintos clientes escritos en diferentes lenguajes, corriendo en diversas plataformas y dispositivos. El uso de los tipos MIME y del encabezado HTTP Accepto es un mecanismo conocido como negociación de contenido, el cual le permite a los clientes elegir qué formato de datos puedan leer, y minimiza el acoplamiento de datos entre el servicio y las aplicaciones que lo consumen.

Universal Description, Discovery and Integration

UDDI Un registro global de servicios Web 

UDDI es un registro público diseñado para almacenar de forma estructurada información sobre empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir información de una empresa y de sus servicios. Se puede utilizar sistemas taxonómicos estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización. Lo más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como infraestructura para una colección de software basado en servicios Web.

• ¿Por qué UDDI? ¿Por qué resulta necesario un registro de este tipo? Teniendo en cuenta que existe una colección de software de miles (quizás millones) de servicios Web, se nos plantean varias cuestiones difíciles:
• ¿Cómo se descubren los servicios Web?
• ¿Cómo se categoriza la información de forma coherente?
• ¿Cómo repercute esto en la localización?
• ¿Cómo afecta a las tecnologías de propietario? ¿Cómo se puede garantizar la interoperabilidad del mecanismo de descubrimiento?
• ¿Cómo se puede interactuar en tiempo de ejecución con este mecanismo de descubrimiento cuando mi aplicación depende de un servicio Web?

La iniciativa UDDI surgió como respuesta a estas preguntas. Varias empresas, incluidas Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas trescientas más (para obtener un listado completo, consulte UDDI: Community [en inglés]), unieron sus esfuerzos para desarrollar una especificación basada en estándares abiertos y tecnologías no propietarias que permitiera resolver los retos anteriores. El resultado, cuya versión beta se lanzó en diciembre de 2000 y estaba en producción en mayo de 2001, fue un registro empresarial global alojado por varios nodos de operadores en el que los usuarios podían realizar búsquedas y publicaciones sin coste alguno. 

A partir de la creación de esta infraestructura para servicios Web, los datos sobre estos servicios se pueden encontrar de forma sistemática y confiable en una capacidad universal totalmente independiente de proveedores. Se pueden llevar a cabo búsquedas categóricas precisas utilizando sistemas de identificación y taxonómicos extensibles. La integración de UDDI en tiempo de ejecución se puede incorporar a las aplicaciones. Como resultado, se fomenta el desarrollo de un entorno de software de servicios Web. 

¿Cómo funciona UDDI? 

La información de UDDI se aloja en nodos de operador, empresas que se han comprometido a ejecutar un nodo público conforme a la especificación que rige el consorcio UDDI.org. En la actualidad existen dos nodos públicos que se ajustan a la versión 1 de la especificación UDDI: Microsoft aloja uno e IBM el otro. Hewlett Packard se ha comprometido a alojar un nodo bajo la versión 2 de la especificación. Los operadores del host deben replicar datos entre ellos a través de un canal seguro, para conseguir la redundancia de la información en el registro UDDI. Se pueden publicar los datos en un nodo y descubrirlos en otro tras la réplica. Actualmente, la réplica se produce cada 24 horas. En el futuro, este intervalo entre réplicas se reducirá, ya que habrá más aplicaciones que dependan de los datos de UDDI. 

Resulta importante observar que no existen requisitos de propietario respecto al modo en que el operador del host implementa su nodo. El nodo sólo se debe ajustar a la especificación UDDI. El nodo de Microsoft (http://uddi.microsoft.com/default.aspx [en inglés]), por ejemplo, se ha escrito por completo en C# y se ejecuta en producción en tiempo de ejecución en lenguaje común .NET Beta 2. El código de base se beneficia claramente de la compatibilidad nativa con SOAP y de la serialización que ofrecen las clases de sistema .NET. En el lado del servidor, el nodo del operador Microsoft utiliza Microsoft® SQL Server 2000 como almacén de datos. Creo que basta con mencionar que IBM utiliza tecnologías diferentes para ejecutar su nodo, ¿verdad?. No obstante, los dos nodos se comportan exactamente igual, ya que se ajustan al mismo conjunto de llamadas a API XML basadas en SOAP. Las herramientas de los clientes pueden interoperar con ambos nodos sin problemas. Por eso, el nodo público UDDI constituye un claro ejemplo de que el modelo de servicios Web XML funciona en entornos heterogéneos. 

El próximo paso para comprender la iniciativa UDDI consiste en ver qué datos se almacenan en UDDI y cómo se estructuran. UDDI es relativamente ligero; se ha diseñado como registro, no como depósito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario a recursos, mientras que un depósito sólo almacena información. El registro Microsoft® Windows® puede servir de ejemplo: contiene las configuraciones y parámetros básicos pero, en última instancia, su función es la de dirigir la aplicación a un recurso o binario. Buscar un componente COM basándonos en su Id. de programa nos conducirá a un Id. de clase, que a su vez nos dirigirá a la ubicación del binario. 

UDDI se comporta de forma similar: como el registro de Windows, se basa en identificadores únicos globales (GUID) para garantizar la capacidad de búsquedas y determinar la ubicación de recursos. En última instancia, las consultas a UDDI conducen a una interfaz (un archivo .WSDL, .XSD, .DTD, etc.) o a una implementación (como un archivo .ASMX o .ASP) ubicadas en otro servidor. Por tanto, UDDI puede responder a este tipo de preguntas:

• "¿Qué interfaces de servicios Web basadas en WSDL se han publicado y establecido para un sector determinado?"
• "¿Qué empresas han escrito una implementación basada en una de estas interfaces?"
• "¿Qué servicios Web, categorizados de algún modo, se ofrecen actualmente?"
• "¿Qué servicios Web ofrece una empresa determinada?"
• "¿Con quién se debe poner en contacto el usuario para utilizar los servicios Web de una empresa?"
• "¿Cuáles son los detalles de implementación de un servicio Web concreto?"

Ejemplo de aplicación

¿Cómo se utiliza Servicios UDDI dentro de una organización?
UDDI facilita el descubrimiento de servicios Web y otros recursos de programación dentro de una organización. Los dos escenarios más comunes para Servicios UDDI dentro de una organización son la reutilización de código y la configuración dinámica de aplicaciones:

• Reutilización de código. En tiempo de diseño, los desarrolladores pueden buscar en UDDI los servicios Web o recursos de programación para reutilizarlos en aplicaciones nuevas. Servicios UDDI expone toda la información necesaria para invocar un servicio, facilitando la labor de integrar ese servicio dentro de una aplicación.
• Configuración dinámica de aplicaciones. En tiempo de ejecución, una aplicación consulta a Servicios UDDi para descubrir la información actualizada de enlace al servicio que necesita, para conectarse después  directamente a ese servicio. Un ejemplo de esto puede ser una aplicación de operaciones en bolsa,  que consulta a Servicios UDDI a primera hora de la mañana para obtener la información de configuración  de los distintos servicios que forman parte de la aplicación, como un panel de cotizaciones ("ticker"), actualizaciones de servicio para clientes o servicios de compraventa.

 Compatibilidad con la especificación UDDI y otras tecnologías

• ¿La implementación de Microsoft es compatible con las herramientas de cliente de otros fabricantes?
  • Sí. Servicios UDDI de Windows Server 2003 es totalmente compatible con la versión 1.0 de UDDI y con las especificaciones de API de programación 2.0 (disponibles en el Sitio Web de UDDI.org), así que todas las herramientas compatibles con la versión 1.0 o con la especificación de la versión 2 se pueden utilizar para acceder a Servicios UDDI.¿Quién define el estándar UDDI?

• OASIS es el organismo responsable de la creación y administración de las especificaciones UDDI. Las especificaciones y los estándares subsiguientes se traspasaron desde UDDI.org a OASIS en julio de 2002. Microsoft era uno de los fundadores de UDDI.org y participa activamente en el proceso posterior de generación de estándares en OASIS. Si desea más información sobre OASIS, UDDI.org y otras informaciones de carácter general sobre UDDI, puede visitar el Sitio Web de UDDI.org.

WSDL y UDDI 

WSDL se ha convertido en una pieza clave de la pila de protocolos de los servicios Web. Por eso, es importante saber cómo colaboran UDDI y WSDL y por qué la idea de interfaces frente implementaciones forma parte de cada protocolo. WSDL y UDDI se diseñaron para diferenciar claramente los metadatos abstractos y las implementaciones concretas. Para entender cómo funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta división. 

Por ejemplo, WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis y semántica que necesita un servicio Web) son siempre abstractos, mientras que los puertos (las direcciones de red en las que se invoca al servicio Web) son siempre concretos. No es necesario que un archivo WSDL incluya información sobre el puerto. Un archivo WSDL puede contener simplemente información abstracta de interfaz, sin facilitar datos de implementación concretos, y ser válido. De este modo, los archivos WSDL se separan de las implementaciones. 

Una de las consecuencias más interesantes de esto es que pueden existir varias implementaciones de una única interfaz WSDL. Este diseño permite que sistemas dispares escriban implementaciones de la misma interfaz, para garantizar así la comunicación entre ellos. Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del software de cliente crea el código auxiliar/proxy a partir de esa interfaz, dicho software se podrá comunicar con las tres implementaciones con el mismo código de base, cambiando simplemente el punto de acceso. 

UDDI establece una distinción similar entre la abstracción y la implementación con el concepto de tModels. La estructura tModel, abreviatura de "Technology Model" (modelo de tecnología), representa huellas digitales técnicas, interfaces y tipos abstractos de metadatos. El resultado de los tModels son las plantillas de enlace, que son la implementación concreta de uno o más tModels. Dentro de una plantilla de enlace se registra el punto de acceso de una implementación particular de un tModel. Del mismo modo que el esquema de WSDL permite separar la interfaz y la implementación, UDDI ofrece un mecanismo que permite publicar por separado los tModels de las plantillas de enlace que hacen referencia a ellos. Por ejemplo, un grupo industrial o de estándares publica la interfaz canónica para un sector particular y, a continuación, varias empresas escriben implementaciones de esta interfaz. Obviamente, cada una de estas implementaciones haría referencia al mismo tModel. Los archivos WSDL constituyen un ejemplo perfecto de tModel de UDDI.

SOA

Qué es SOA

La Arquitectura SOA establece un marco de diseño para la integración de aplicaciones independientes de manera que desde la red pueda accederse a sus funcionalidades, las cuales se ofrecen como servicios.

La forma más habitual de implementarla es mediante Servicios Web, una tecnología basada en estándares e independiente de la plataforma, con la que SOA puede descomponer aplicaciones monolíticas en un conjunto de servicios e implementar esta funcionalidad en forma modular.

 ¿Qué es un servicio exactamente? Un servicio es una funcionalidad concreta que puede ser descubierta en la red y que describe tanto lo que puede hacer como el modo de interactuar con ella.

Desde la perspectiva de la empresa, un servicio realiza una tarea concreta: puede corresponder a un proceso de negocio tan sencillo como introducir o extraer un dato como “Código del Cliente”. Pero también los servicios pueden acoplarse dentro de una aplicación completa que proporcione servicios de alto nivel, con un grado de complejidad muy superior –por ejemplo, “introducir datos de un pedido”-, un proceso que, desde que comienza hasta que termina, puede involucrar varias aplicaciones de negocio.

 La estrategia de orientación a servicios permite la creación de servicios y aplicaciones compuestas que pueden existir con independencia de las tecnologías subyacentes. En lugar de exigir que todos los datos y lógica de negocio residan en un mismo ordenador, el modelo de servicios facilita el acceso y consumo de los recursos de IT a través de la red. Puesto que los servicios están diseñados para ser independientes, autónomos y para interconectarse adecuadamente, pueden combinarse y recombinarse con suma facilidad en aplicaciones complejas que respondan a las necesidades de cada momento en el seno de una organización. Las aplicaciones compuestas (también llamadas “dinámicas”) son lo que permite a las empresas mejorar y automatizar sus procesos manuales, disponer de una visión consistente de sus clientes y socios comerciales y orquestar sus procesos de negocio para que cumplan con las regulaciones legales y políticas internas. El resultado final es que las organizaciones que adoptan la orientación a servicios pueden crear y reutilizar servicios y aplicaciones y adaptarlos ante los cambios evolutivos que se producen dentro y fuera de ellas, y con ello adquirir la agilidad necesaria para ganar ventaja competitiva.

Servicios Web

La adopción de una solución de diseño basada en SOA no exige implantar servicios Web. No obstante, como ya comentamos anteriormente, los servicios Web son la forma más habitual de implementar SOA. Los servicios Web son aplicaciones que utilizan estándares para el transporte, codificación y protocolo de intercambio de información. Los servicios Web permiten la intercomunicación entre sistemas de cualquier plataforma y se utilizan en una gran variedad de escenarios de integración, tanto dentro de las organizaciones como con partners de negocios. 

Los servicios Web se basan en un conjunto de estándares de comunicación, como son XML para la representación de datos, SOAP (Simple Object Access Protocol) para el intercambio de datos y el lenguaje WSDL (Web Services Description Language) para describir las funcionalidades de un servicio Web. Existen más especificaciones, a las que se denomina genéricamente como la arquitectura WS-*, que definen distintas funcionalidades para el descubrimiento de servicios Web, gestión de eventos, archivos adjuntos, seguridad, gestión y fiabilidad en el intercambio de mensajes y transacciones. Microsoft anunció por vez primera su modelo de servicios Web en septiembre de 1999, y a partir de ese momento se inició una corriente innovadora que ha transformado profundamente el panorama de la arquitectura de aplicaciones. Desde la aparición de la versión 1.0 de .NET Framework, las inversiones de Microsoft en herramientas y su alto nivel de  compromiso con los servicios Web dentro de la plataforma Windows han contribuido al fuerte desarrollo actual de la Orientación a Servicios.

Poco después Microsoft comenzó a colaborar con IBM para desarrollar la organización Web Services Interoperability Organization (WS-I), institución que promueve la interoperabilidad entre plataformas, sistemas operativos y lenguajes de programación. Actualmente en WS-I hay más de 150 miembros, y ha creado servicios Web que resuelven distintas áreas críticas en aspectos como la interoperabilidad, seguridad y fiabilidad de la mensajería.

Qué es SaaS

Otro concepto muy ligado a SOA es la noción de “Software como Servicio” (Saas, “Software as a Service”). En pocas palabras, SasS puede definirse como “software que se pone en explotación en la modalidad de servicio gestionado y que al cual se accede a través de Internet”.

 El concepto de SaaS suele asociarse con los proveedores de servicios de aplicación (ASPs) de los años 90, que ofrecían aplicaciones “empaquetadas” a los usuarios corporativos a través de Internet. Estos primeros intentos de poner en marcha soluciones de Software a través de Internet tenían más en común con las aplicaciones corporativas tradicionales (las que se instalan y utilizan dentro de la red interna de las empresas) que con las actuales aplicaciones SaaS en muchos aspectos, tales como el modelo de licencia y la arquitectura. Puesto que esas aplicaciones se crearon en principio como aplicaciones para un solo destinatario, su capacidad para compartir datos y procesos con otras aplicaciones estaba muy limitada y tendían a ser escasamente atractivas en comparación con sus equivalentes de instalación en local.

 Hoy día las aplicaciones SaaS pretenden aprovechar las ventajas de la centralización a partir de una arquitectura de instancia única con múltiples usuarios y ofrecer una experiencia con funcionalidades avanzadas que compitan con ventaja frente a las aplicaciones instaladas localmente. Una aplicación SaaS normalmente la ofrece un proveedor de forma directa o un intermediario (llamado “agregador”) que empaqueta ofertas SaaS de distintos proveedores y las ofrece como una plataforma unificada de e-aplicaciones o una suite de servicios de aplicación.

 A diferencia del modelo de licencias habitual del software que se instala en las empresas, el acceso a las aplicaciones SaaS se suele basar en un modelo de suscripción, donde los clientes pagan una tarifa por adelantado para utilizarlas. Las estructuras de precios varían de unas aplicaciones a otras: algunos proveedores aplican una tarifa plana con acceso ilimitado a diversas funcionalidades de las aplicaciones, y otros aplican tramos tarifarios que dependen del nivel de utilización. SaaS además se posiciona como uno de los pilares del desarrollo de la orientación a servicios. A los efectos de este documento, nos vamos a referir de forma genera a SOA, incluyendo en este concepto tanto los servicios implantados en local como los alojados en Internet. Consideramos que SaaS es un componente fundamental en cualquier estrategia SOA de un cliente.

Beneficios de SOA

Los beneficios de SOA para una organización se plasman a dos niveles distintos: al del usuario corporativo y a nivel de la organización de IT.

 Desde el punto de vista de la empresa, SOA permite el desarrollo de una nueva generación de aplicaciones dinámicas que resuelven una gran cantidad de problemas de alto nivel, fundamentales para el crecimiento y la competitividad. Las soluciones SOA permiten entre otras cosas:

 • Mejorar la toma de decisiones. Al integrar el acceso a los servicios e información de

negocio dentro de un conjunto de aplicaciones dinámicas compuestas, los directivos

disponen de más información y de mejor calidad (más exacta y actualizada). Las personas,

procesos y sistemas que abarcan múltiples departamentos pueden introducirse de forma más

directa en una panorámica unificada, lo que permite conocer mejor los balances de costes y

beneficios que se producen en las operaciones de negocio que se realizan a diario. Y al

disponer de mejor información en un tiempo menor, las organizaciones pueden reaccionar de

manera más ágil y rápida cuando surgen problemas o cambios.

• Mejorar la productividad de los empleados. Un acceso óptimo a los sistemas y la

información y la posibilidad de mejorar los procesos permiten a las empresas aumentar la

productividad individual de los empleados. Estos pueden dedicar sus energías a los procesos

importantes, los que generan valor añadido y a actividades de colaboración,

semiestructuradas, en vez de aceptar las limitaciones y restricciones impuestas por los

sistemas de IT rígidos y monolíticos. Más aún: puesto que los usuarios pueden acceder a la

información en los formatos y modalidades de presentación (web, cliente avanzado,

dispositivo móvil), que necesitan, su productividad se multiplica en una gran cantidad de

escenarios de uso, habituales o nuevos.

• Potenciar las relaciones con clientes y proveedores. Las ventajas de SOA trascienden las

fronteras de la organización. Los beneficios que ofrece SOA trascienden los límites de la

propia organización. Los procesos de fusión y compra de empresas se hacen más rentables

al ser más sencilla la integración de sistemas y aplicaciones diferentes. La integración con

partners comerciales y la optimización de los procesos de la cadena de suministro son, bajo

esta perspectiva, objetivos perfectamente asequibles. Con SOA se puede conseguir mejorar

la capacidad de respuesta a los clientes, habilitando por ejemplo portales unificados de

servicios. Si los clientes y proveedores externos pueden disponer de acceso a aplicaciones y

servicios de negocio dinámicos, no solamente se permite una colaboración avanzada, sino

que se aumenta la satisfacción de clientes y proveedores. SOA permite flexibilizar los

procesos críticos de compras y gestión de pedidos –habilitando modalidades como la

subcontratación de ciertas actividades internas- superando las restricciones impuestas por

las arquitecturas de IT subyacentes, y con ello consiguiendo un mejor alineamiento de los

procesos con la estrategia corporativa.

SOA contribuye también a documentar el modelo de negocio de la empresa y a utilizar el modelo de negocio documentado para integrar en él y dar respuesta a las dinámicas de cambio que se produzcan y optimizarlo de acuerdo con ellas.

• Aplicaciones más productivas y flexibles. La estrategia de orientación a servicios permite

a IT conseguir una mayor productividad de los recursos de IT existentes –como pueden ser

las aplicaciones y sistemas ya instalados e incluso los más antiguos- y obtener mayor valor

de ellos de cara a la organización sin necesidad de aplicar soluciones de integración

desarrolladas ex profeso para este fin. La orientación a servicios permite además el

desarrollo de una nueva generación de aplicaciones compuestas que ofrecen capacidades

avanzadas y multifuncionales para la organización con independencia de las plataformas y

lenguajes de programación que soportan los procesos de base. Más aún: puesto que los

servicios son entidades independientes de la infraestructura subyacente, una de sus

características más importantes es su flexibilidad a la hora del diseño de cualquier solución.

• Desarrollo de aplicaciones más rápido y económico. El diseño de servicios basado en

estándares facilita la creación de un repositorio de servicios reutilizables que se pueden

combinar en servicios de mayor nivel y aplicaciones compuestas en respuesta a nuevas

necesidades de la empresa. Con ello se reduce el coste del desarrollo de soluciones y de los

ciclos de prueba, se eliminan redundancias y se consigue su puesta en valor en menos

tiempo. Y el uso de un entorno y un modelo de desarrollo unificados simplifica y

homogeneíza la creación de aplicaciones, desde su diseño y prueba hasta su puesta en

marcha y mantenimiento.

• Aplicaciones más seguras y manejables. Las soluciones orientadas a servicios

proporcionan una infraestructura común (y una documentación común también) para

desarrollar servicios seguros, predecibles y gestionables. Conforme van evolucionando las

necesidades de negocio, SOA facilita la posibilidad de añadir nuevos servicios y

funcionalidades para gestionar los procesos de negocio críticos. Se accede a los servicios y

no a las aplicaciones, y gracias a ello la arquitectura orientada a servicios optimiza las

inversiones realizadas en IT potenciando la capacidad de introducir nuevas capacidades y

mejoras. Y además, puesto que se utilizan mecanismos de autenticación y autorización

robustos en todos los servicios –y puesto que los servicios existen de forma independiente

unos de otros y no se interfieren entre ellos- la estrategia de SOA permite dotarse de un nivel

de seguridad superior.