Evolución de la arquitectura: arquitectura orientada a los servicios vs. servicios Web

La arquitectura orientada al servicio (SOA) no es lo mismo que los servicios Web: esto último es una forma concreta de lograr algunos beneficios de SOA, y especifica una colección de tecnologías utilizando protocolos como el protocolo de acceso a objetos sencillos (SOAP), y lenguajes como XML. Los servicios Web se invocan por Internet por medio de protocolos industriales estándar, incluyendo SOAP; lenguaje extensible de marcas (XML); protocolo de transferencia de hipertexto (HTTP), lenguaje de descripción de los servicios Web (WSDL), descripción, descubrimiento e integración universales (UDDI). Esto se define a través de organizaciones públicas de estándares como el World Wide Web Consortium (W3C). Por ejemplo, SOAP es una tecnología de mensajes basada en XML estandarizada por el W3C, que especifica todas las reglas necesarias para localizar servicios Web, las integra en aplicaciones, y se pueden comunicar entre ellas. UDDI es un registro público, ofrecido de forma gratuita, donde se puede publicar y preguntar acerca de los servicios Web.

Tercera parte de la serie Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios

Para mayor información, consulte Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios y Evolución de la arquitectura: desde la arquitectura basada en la Web hasta la arquitectura orientada al servicio.

SOA puede definirse y explicarse en parte por los servicios Web, que de acuerdo con Microsoft son “módulos de software que se auto-describen, semánticamente encapsulan la funcionalidad discreta, envueltos y accesibles por medio de protocolos de comunicación estándar de Internet como XML y SOAP. Los servicios Web están revolucionando cómo las aplicaciones se comunican con otras aplicaciones (o, de forma más amplia, cómo las computadoras se comunican con otras computadoras) al proporcionar un formato universal de datos que permita que los datos se adapten o transformen fácilmente. Con base en XML, el lenguaje universal del intercambio de datos por Internet, los servicios Web pueden comunicarse a través de plataformas y sistemas operativos, sin importar el lenguaje de programación en el que están escritas las aplicaciones. Aunque cada servicio Web es una unidad discreta de código que maneja un conjunto limitado de tareas, y aunque los servicios Web siguen siendo independientes uno del otro, pueden libremente enlazarse a un grupo colaborativo que lleve a cabo una tarea en particular.

Pero, a diferencia de los servicios Web, SOA es un amplio concepto que opera de forma independiente a cualquier tecnología específica, e incluso si uno utiliza los servicios Web y acercamientos orientados a objetos (OO), uno puede no logar necesariamente el estado holístico de unión libre, autónoma, y componentes reutilizables que son esenciales para una SOA verdadera. Sin embargo, los servicios Web también hacen posible que los desarrolladores elijan entre construir (proporcionar) todas las piezas de sus aplicaciones o consumir (utilizar) servicios Web creados por otros. Esto significa que una compañía no tiene que suministrar cada pieza para una solución completa. La habilidad de exponer (anunciar y ofrecer) sus propios servicios Web crea nuevos ingresos para cualquier compañía, ya sea un vendedor independiente de software (ISV), un revendedor o incluso una empresa usuaria.

Servicios Web orientados a los negocios

Una definición orientada a los negocios de los servicios Web sería un acercamiento que les ayuda a los negocios a conectarse con sus clientes, socios y empleados. En otras palabras, le permite al negocio extender los servicios existentes a nuevos clientes, ayudarle a que trabaje de forma más eficiente con sus socios y proveedores y desbloqueo de información para que pueda fluir hacia cualquier empleado que lo necesite.

Las prácticas de gestión comercial eficientes describen la duración del control como una masa crítica sobre la cual un solo administrador o equipo de administración no puede manejar a la gente o las instalaciones de forma eficiente. Esta es la razón por la que las instalaciones de fabricación que se hacen muy grandes por lo general se dividen en unidades más pequeñas, y por la que las grandes corporaciones por lo general tienden a tener múltiples unidades comerciales de distribución y fabricación que operan de forma independiente. Estas empresas no sólo necesitan manejarse de forma efectiva, sino que también necesitan colaborar e interoperar entre ellas.

La colaboración y la interoperabilidad son críticas cuando residen múltiples unidades comerciales en una corporación grande, o cuando existe un requerimiento de integrar el sistema en un sistema dispar del proveedor o del cliente cuando una extensión interempresarial (B2B) o negocio-cliente (B2C) es parte del modelo comercial. Estas conexiones se pueden hacer fácilmente al utilizar los servicios Web que, una vez más, le permiten a las aplicaciones compartir información a través de Internet, sin importar el sistema operativo o el software que utilice la aplicación. Al permitirles a las aplicaciones compartir datos en las distintas plataformas hardware y sistemas operativos, los servicios Web proporcionan muchos más beneficios, incluyendo un menor tiempo de desarrollo y costos menores para nuevos proyectos. También les entregan a los usuarios experiencias integradas más personales a través de nuevos dispositivos inteligentes, incluyendo las computadoras personales (PCs).

Un buen ejemplo es un sistema de inventario independiente, que, si no se conecta a nada más, no es tan valioso como podría serlo. En otras palabras, el sistema puede ser capaz de rastrear inventario, pero no puede hacer mucho más, y los usuarios pueden tener que ingresar la información del inventario dos veces, una en su sistema de contabilidad y otra en su sistema de gestión de las relaciones con los clientes (CRM). El sistema del inventario puede ser incapaz de darles las órdenes automáticamente a los proveedores, y los beneficios de tal sistema de inventario “autista” son disminuir los altos gastos operacionales. Sin embargo, si uno conecta tal sistema de inventario a un sistema de contabilidad, ya sea que uno venda o compre algo, las implicaciones para el inventario y el flujo de caja se puede rastrear en un sólo paso. Además, al conectarlo a un sistema de gestión de almacén (WMS), a un sistema de pedido del cliente, a sistemas de pedidos al proveedor y a la compañía de embarque, de pronto el sistema de gestión de inventario vale mucho más, ya que los usuarios pueden realizar una gestión ininterrumpida de su negocio al mismo tiempo que lidian con cada transacción sólo una vez, en lugar de una vez para cada sistema al que afecta. Esto representa menos trabajo y una menor oportunidad de error.

Previo al desarrollo de los servicios Web y los servicios de aplicación, para enlazar sistemas dispares se requería una gran cantidad de programación y varios pasos manuales para que ocurriera la interacción. Y cuando ocurría, se sacrificaba la velocidad del sistema. Por otro lado, las plataformas modernas le deben permitir a todas las compañías automatizar de una manera más fácil los procesos hechos de forma manual, y por lo tanto reduce los costos de mano de obra, y facilita la exactitud al eliminar el error humano. Por ejemplo, debe ser posible que las órdenes que se coloquen en el sitio Web de la compañía se procesen de forma automática virtualmente en tiempo real, con el precio adecuado asignado de acuerdo al estatus del cliente. Se pueden crear las cuentas antes de que se procese la orden, mientras que las órdenes se pueden imprimir automáticamente y los artículos se pueden sacar automáticamente del inventario en tiempo real, todo esto sin la intervención humana.

La implementación de una aplicación en tal plataforma basada en servicios Web puede incluso cambiar la carga de la transacción del sistema de comercio electrónico de ventanilla hasta el sistema de planificación de los recursos de la empresa (ERP) de la oficina de gestión. Por ejemplo, se puede enviar un correo electrónico agradeciéndole al comprador por la compra desde la oficina de gestión justo después de que se consuma la transacción XML en el sistema ERP. De esta forma, la información enviada puede ser más informativa, incluyendo datos como la producción esperada en los plazos estimados y las fechas de entrega, que es realmente pertinente en un ambiente de fabricación B2B. Lo que es importante es que la retroalimentación recibida en un ambiente de comercio electrónico B2B se pude mejorar a través de la habilidad de extender de igual forma la información al sistema ERP de la oficina de gestión. El resultado debe ser una experiencia más rica del cliente, a su vez resulta en clientes más felices y en un mayor ingreso a largo plazo.

El ambiente SOA

Existen varias aplicaciones similares donde las soluciones basadas en los servicios Web puedan reemplazar las tareas manuales propensas a errores y de larga duración para acelerar el cumplimiento de la orden. Pero para aprovechar esto, los vendedores de aplicaciones empresariales necesitan volver a educar a los usuarios para ver las cosas desde otra perspectiva. A principios de los años 80 y los días de la unidad de programas, los arquitectos de sistemas gastaron una gran cantidad de tiempo con clientes que desarrollaban especificaciones de sistema antes de escribir el sistema personalizado y adaptado. A los usuarios se les recomendaba ver las cosas desde una perspectiva externa en cuanto a la funcionalidad e interna en cuanto a la tecnología, para impulsar la tecnología al límite (de lo que se podría hacer en dicho momento). Los usuarios se acostumbraron a demandar la funcionalidad y a obtenerla, incluso a un precio muy alto. Para mitigar esto, los servidores de aplicación se han convertido en el middleware para la empresa ya que proporcionan cada vez más ganchos al legado de aplicaciones. En un ambiente SOA, un servidor de aplicación hospeda los servicios de aplicación y también juega el papel de una tecnología fundamental. Los monitores de procesamiento de transacción (TPMs) y los monitores de transacción de objetos (OTMs) son ejemplos de productos nativos del servidor de aplicación.

Antes de que Sun Microsystems fuera pionero del concepto del servidor de aplicación a finales de los años 90 (aunque algunos pueden argumentar que Microsoft Transaction Server [MTS] es previo al trabajo del servidor de aplicación de Sun), el software todavía se trataba como líneas inexplicables de códigos monolíticos, legados de aplicaciones confusos o en el mejor de los casos objetos vagamente reconocibles. La unidad de programa y las primeras aplicaciones cliente/servidor también tenían control completo sobre esto, incluyendo la interfase de usuario (UI), lógica de procesos, lógica de integración, lógica de aplicación y base de datos. La llegada de los servicios de aplicación comenzaron a cambiar esto al proporcionar un sutil pero profundo cambio en cómo se debería diseñar (y percibir) el software. Por primera vez, los desarrolladores comenzaron a pensar en código e términos de funciones y servicios como la gestión de transacciones, el balance de carga y la seguridad. Ya que tales servicios son comunes a todos los sistemas, sin importar la plataforma, los desarrolladores de software comenzaron a perseguir seriamente la idea de que los componentes identificables de funcionalidad se pueden volver a utilizar y compartir en múltiples sistemas diferentes.

La intención es dirigir la conciencia del mercado cada vez mayor de los siguientes hechos:

1. 1. Casi todos los cambios comerciales, y que el software debe cambiar con el negocio (consulte What's Wrong With Application Software? Business Changes, Software Must Change with the Business).
2. Incluso las pequeñas empresas realmente son únicas, unitalla, y por lo tanto, el software es un requisito para varias empresas, incluso para las más pequeñas (consulte, What's Wrong With Application Software? Businesses Really Are Unique—One Size Can Never Fit All).
3. El alto costo de desarrollo, el soporte y las mejoras en términos de dinero, tiempo y calidad limitan la forma en que el software instalado puede cubrir las demandas del negocio (consulte, What's Wrong with Application Software? It's the Economics).

Sin embargo, se necesitan muchos esfuerzos, conocimiento del dominio industrial, y recursos (con frecuencia estimado en cientos de “años laborales”) para divisar y construir un sistema empresarial desde cero. Al decidir como escribirlo, cada vendedor de software hace un gran y caro compromiso con la base tecnológica que tiene que seleccionar al comienzo del proyecto (por ejemplo, el lenguaje de programación, la plataforma del sistema operativo, y la tecnología de acceso a los datos). Con frecuencia, el lenguaje seleccionado y la tecnología de acceso de los datos están bien integradas y posteriormente no se pueden separar fácilmente.

Si no se toma en cuenta a los defensores de la fuente abierta y a los pioneros y a los fanáticos de IBM System i (antes AS/400 —consulte Análisis situacional de la plataforma del servidor: IBM A/S400), ha existido por mucho tiempo una demarcación entre los sistemas empresariales basados en Unix para las grandes empresas y los sistemas basados en Microsoft Windows para la parte inferior del mercado. Con la llegada de los servidores de aplicación, y las incursiones de los vendedores y los usuarios en los servicios Web y el habilitamiento SOA, esta oposición se ha transformado en los servidores de aplicación basados en Java 2 Enterprise Edition (J2EE) contra Microsoft .NET (consulte, Understand J2EE and .NET Environments Before You Choose).

Aunque se ha dicho mucho acerca de la investigación en el campo de J2EE (consulte, Oracle Further Orchestrates Its SOA Forays, SAP NetWeaver para múltiples propósitos, y Contribución para el rejuvenecimiento del legado de sistemas en el campo de la planificación de los recursos empresariales), busque artículos extra que también analicen las relaciones exteriores de los vendedores empresariales centrados en Microsoft.

Si es suficiente con aclarar el caso más básico, y posiblemente el más predominante, éste sería una simple compatibilidad con .NET en el mercado En concreto, esto significa que el legado de software simplemente opera en los servidores .NET (Microsoft Windows). Aunque tales productos centrados en Microsoft pueden operar en los últimos sistemas operativos de Microsoft y las plataformas de bases de datos, los beneficios antes mencionados de servicios Web no son tan fáciles de lograr.

Conclusión y recomendaciones

Cuando aparece una nueva tecnología, es muy común que un proveedor de aplicaciones empresariales rodee su antiguo software central de contabilidad o ERP con una "cubierta" de una tecnología más nueva, donde la meta es opacar de forma efectiva la antigua tecnología, dándole el último "look" gráfico. La meta también es proporcionar una forma más sencilla de accesar a la lógica comercial central y a los datos desde otros sistemas o dispositivos más modernos o desde Internet. Varios sistemas de contabilidad y ERP de la oficina de gestión en el mercado hoy en día se escribieron en, y todavía tienen, centros escritos no en la unidad de programas o tecnologías antiguas no equivalentes. Las estrategias empleadas para envolver los productos antiguos incluye la incorporación del Windows contemporáneo interfases de usuario gráficas (GUIs), con frecuencia llamadas “limpiador de pantalla” o UIs basadas en navegadores Web, que proporcionan nuevos niveles de servicios Web para rejuvenecer sus antiguos productos al accesar los viejos componentes de lógica comercial y bases de datos.

Mientras que el “antiguo” software cubra las necesidades comerciales, la nueva tecnología no es la conductora del cambio, que hace que se construyan productos de reemplazo en un nuevo marco de trabajo con una estrategia más riesgosa. Algunos de los productos ahora están en su enésima generación, que le ha proporcionado a los vendedores la oportunidad de optimizar su código y resolver varios problemas de seguridad y conflicto. La funcionalidad del producto todavía importa mucho, y aunque es importante para que los proveedores de aplicaciones empresariales puedan implementar la última ciencia computacional y dar el "salto cualitativo", no existe una correlación garantizada entre ser el primero en comercializar y tener éxito en el mercado. Varios vendedores también han sentido el disgusto de las bases de clientes que estaban lejos de estar listos para dar un salto tecnológico significativo. Por lo tanto, al tener una gran base de clientes todavía con productos antiguos en operación que soportan tecnologías posiblemente obsoletas, incluso si los vendedores más grandes han tenido que detenerse y pensar en las estrategias para descontinuar su último lanzamiento de producto.

Como conclusión, esta siempre es la razón comercial que debe conducir cualquier decisión técnica. Cada negocio debe enfocarse en optimizar los procesos y competencias centrales como reducir los costos, mejorar la satisfacción del cliente, lograr entregas más rápidas, etc. Luego se debe realizar algún ejercicio tedioso para determinar los habilitadores tecnológicos. Para la gran mayoría de las empresas, su futuro portafolio de activos IT seguirá mostrando una mezcla de legados de aplicaciones hechos en casa y empaquetados, y no una reescritura total del SOA.

Con esto termina la serie Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios