Distinguiendo entre SaaS y SOA

Surge una gran confusión al momento de hacer la distinción entre el software como servicio (SaaS) y la arquitectura orientada a servicios (SOA). El Marco de Referencia de Zachman puede ayudar a tratar de dar sentido a la sopa de letras de los Web Services y los servicios públicos que constituyen la base tanto para SOA y SaaS.

Varios profesionales de TI tienden en algún momento, a utilizar erróneamente el término software como servicio (SaaS) y arquitectura orientada a servicios (SOA) de manera intercambiable. A lo mejor, esta práctica defectuosa crea confusión, en el peor de los casos, puede conducir a diseños pobres.  Nuestro objetivo, por lo tanto, es de aclarar el significado de estos dos términos a menudo utilizados y abusados​​.

En pocas palabras, la diferencia entre SaaS y SOA es que el primero es un modelo de entrega de software mientras que el segundo es un modelo para la construcción de software. Una mejor manera de iluminar las diferencias entre estos dos conceptos es el uso del conocido modelo arquitectónico Zachman [1].

En este artículo, examinaremos brevemente los conceptos de SaaS y SOA, seguido de una breve historia de los modelos de arquitectura de software. Utilizamos el modelo Zachman para diferenciar los dos enfoques arquitectónicos para la construcción de software. Dado que el modelo Zachman es bastante intuitivo, el enfoque que tomamos para describir las diferencias entre SaaS y SOA funciona bien incluso con los profesionales que no son de TI.

Definiendo los términos

A veces se conoce como software de suscripción, [2] el modelo de entrega SaaS separa esencialmente la propiedad del software por parte del usuario, el propietario es un vendedor que aloja el software y permite al usuario ejecutarlo bajo demanda a través de alguna forma de arquitectura del lado del cliente a través de Internet o un Intranet. Este nuevo modelo ofrece software como los servicios públicos y los cargos sobre una base por uso, similar a la forma en que cobra una empresa de servicios públicos de electricidad. Tal vez el producto SaaS más célebre es la herramienta para la gestión de Salesforce.com Customerrelationship. Sin embargo, los productos SaaS están disponibles para una amplia gama de funciones de negocios, incluyendo servicio al cliente, gestión de recursos humanos, la funcionalidad de escritorio, correo electrónico, nóminas, aplicaciones financieras, y la cadena de suministro y control de inventario. [3]

En un modelo SOA, los componentes constitutivos del sistema de software son servicios reutilizables. [4] Una colección de servicios que interactúan entre sí a través de interfaces estándares y protocolos de comunicación. SOA promete cambiar radicalmente la forma en que construimos sistemas internos, así como la forma en que los sistemas internos y externos interactúan. Esta estrategia arquitectónica va de la mano con las aplicaciones de software que están cerca de los objetos de negocio que ayudan a crear una capa de abstracción (porque SOA le permite seleccionar “piezas” de software personalizadas que puede alinear estrechamente con su funcionalidad comercial correspondiente). SOA es también un marco coherente para conectar el software adecuado estática y dinámicamente.

Algunos de los principales actores de SOA y sus últimos productos incluyen a: BEA AquaLogic, Sonic SOA Suite 6.1, Oracle Web Services Manager, HP Systinet Registry 6.0, Iona Artix 5.0, Cape Clear 7.5, Microsoft .NET, Sun Java Composite Application Platform Suite, & IBM WebSphere.  En esta lista, se termina con una arquitectura tecnológica, una arquitectura de procesos, la arquitectura de la aplicación, y así sucesivamente. SOA ayuda a reunirlos, aunque no siempre es fácil de moverse en esa dirección teniendo muchas y diversas aplicaciones involucradas.

A pesar de sus diferencias, SaaS y SOA están estrechamente relacionados con los modelos arquitectónicos para los sistemas de información a gran escala. Con SaaS, un proveedor puede ofrecer un sistema de software como un servicio. Usando SOA permite que el servicio publicado pueda ser descubierto y adoptado como un componente de servicio para la construcción de nuevos sistemas de software, que también pueden ser publicados y entregados como nuevos servicios. En otras palabras, los dos modelos se complementan entre sí: ​​SaaS ayuda a ofrecer componentes para que SOA los pueda usar, y SOA ayuda a implementar SaaS de forma  más rápida.

Aunque ambos proporcionan características prometedoras para la industria del software moderno, son sólo modelos de nivel conceptual y requieren una tecnología detallada para apoyarlos. En la actualidad, el mejor habilitador conocido que apoya tanto SaaS y SOA son las tecnologías de aplicaciones programables de servicios Web con descripciones de interfaz estándar que proveen acceso universal a través de protocolos de comunicación estándar. [5] Los servicios web proporcionan un conjunto holístico basado en XML, ad hoc, además la industria de lenguajes Web  y protocolos estándar apoya a las descripciones de servicios web (Web Services Desription Language [WSDL] [6]), publicación y descubrimiento (utilizando UDDI [7]), el transporte (mediante SOAP [8]), y así sucesivamente.

Ni tampoco SaaS requiere la tecnología de servicios Web para SOA, pero es, con mucho, la mejor opción actual para apoyarlos.

En otras palabras, las tecnologías de servicios Web, con toda su pila asociada de normas, permiten y facilitan la adopción de SaaS y SOA. Vale la pena señalar que ni SaaS ni SOA requiere de tecnología de servicios Web, pero es lejos la mejor opción actual para apoyarlos. Ante este hecho, se utilizan los términos de servicios y servicios Web indistintamente en este artículo.

Texto completo (inglés) en: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1140&context=silicon_valley

Referencias

[1] J.A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems J., 1987, vol. 26, no. 3, pp. 276–292.

[2] M. Turner, D. Budgen, and P. Brereton, “Turning Software into a Service,” Computer, vol. 36, no. 10, 2003, pp. 38–44.

[3] M.H. Weier and L. Smith, “Businesses Get Serious about Software as a Service,” Information Week, 16 Apr. 2007, pp. 46–48.

[4] L.-J. Zhang, J. Zhang, and H. Cai, Services Computing, Springer, 2007.

[5] C. Ferris and J. Farrell, “What Are Web Services?” Comm. ACM, vol. 46, no. 6, 2003, p. 31.

[6]. “Web Services Description Language (WSDL) 1.1,” W3C note, E. Christensen et al., eds., 15 Mar. 2001; www.w3.org/TR/wsdl.

[7] Universal Description, Discovery, and Integration (UDDI), version 3, Organization for the Advancement of Structured Information Standards (Oasis), 2004; http://www.uddi.org/pubs/uddi_v3.htm.

[8] SOAP Version 1.2, Part 1: Messaging Framework (second edition), W3C recommendation, M. Gudgin et al., eds., 27 Apr. 2007; http://www.w3.org/TR/soap12-part1/

Anuncios

7 comentarios

Archivado bajo Arquitectura de Software, SaaS, SOA

7 Respuestas a “Distinguiendo entre SaaS y SOA

  1. Aristóteles Cahua Flores

    Que buena aclaración!, lo compartiré, saludos!

  2. Son dos tecnologías parecidas en su concepto base y, sobre todo, muy nuevas. Creo que por eso aparecen las mayoría de las confusiones, pero este post explica perfectamente las diferencias.

  3. SOA es nueva tecnología? Y entonces porque los “microservicios” se dicen que son la alternativa a SOA? Por qué Amazon migró todos plataforma a “mirososervicios”? Todos estos términos son una jungla 🙂

    • jjegonzalezf

      Te agradezco el comentario Fernando. Me obligó a investigar un poco y eso es bueno.

      Creo que la diferencia entre los microservicios y SOA no es tan evidente, quizás por eso se presta a confusión. Me atrevo a decir que los microservicios son una especialización de SOA. Los microservicios en realidad responden a un estilo de arquitectura y diseño de software basado en el principio de responsabilidad única que vienen a romper un poco el esquema de las aplicaciones monolíticas. Y la otra pregunta importante es: ¿Cómo gobiernas los microservicios? SOA no existe si no hay gobierno. En contextos de arquitecturas empresariales, SOA usa un ESB (Enterprise Servie Bus) para rutear el contenido a través del bus de servicio, y los microservicios usan AMQP.

      De todas formas creo que los microservicios ayudan mucho para desarrollar aplicaciones que se vendan como servicio (SaaS), dado que el desarrollo, testing y deploy es mucho más rápido que en contextos SOA.

      Acá hay buenas referencias:

      http://martinfowler.com/articles/microservices.html
      https://www.quora.com/What-is-the-difference-between-SOA-and-microservices

      Saludos cordiales

      • Muy bueno… gracias! En mi empresa se habla de que el ESB es “base” para SOA, la pregunta es si nosotros somos sólo Microsoft y desarrollamos en .NET, requerimos igualmente SOA-ESB o podemos usar tecnología mas básica para orientarnos al servicio? Algo propio de Microsoft? SOA se aplica cuando hay que inerrrelacionar ambiente heterógenos, o no?

  4. Pingback: La Ingeniería detrás de Uber (PARTE I) | Juanjo's Blog

  5. Pingback: La Ingeniería detrás de Uber | EXCELLENCE MANAGEMENT

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s