ESA y Web Services en SAP Netweaver: Introducción

I. Web Services: Una primera mirada

Web Services es hoy uno de los conceptos que más atención concentra en la industria del software. Desde los proveedores líderes, hasta los emprendimientos más emergentes, todos lo incluyen en su agenda.  Los Web Services, probablemente, nos traen la promesa de establecer un nuevo modelo de programación, que suceda al paradigma cliente-servidor, donde, por fin, se reconcilien la idea de interoperabilidad con la flexibilidad para generar cambios en las aplicaciones.

Nos proponemos en esta serie de tips, clarificar el concepto de Web Services, para luego desarrollar las posibilidades que brinda SAP con su arquitectura orientada a servicios. Más allá de su definición formal y características técnicas, que desarrollaremos en este primer artículo, es importante entender cómo y porqué llegamos a este paradigma.

El contexto

Los procesos de negocio están compuestos por múltiples funciones aplicativas. Los escenarios de negocio cada vez más competitivos y complejos, han gestado la demanda de funcionalidad cada vez más elaborada, y una oferta de soluciones cada vez más especializada, alimentada por el suceso de las aplicaciones tipo ERP. Sin embargo, la realidad muestra que no es posible implementar toda esta funcionalidad utilizando una única tecnología. Una infraestructura moderna de software debería permitir integrar funciones desarrolladas interna o externamente, por múltiples proveedores y plataformas en un único proceso completo y efectivo.

Hasta hoy, la integración de software se apoyaba principalmente en la definición manual de interfaces, formato de mensajes, y la concordancia explícita entre los “socios” de negocio involucrados. Este enfoque, además de laborioso, genera enormes trabas en la flexibilidad de las interfaces obtenidas y su capacidad de adaptarse a los cambios.

La propuesta de los Web Services

El término Web Service define a la vez una entidad de software y un modelo de programación , que, basado en estándares abiertos y universalmente aceptados, permite combinar funcionalidad implementada en las más variadas plataformas.

En blanco y negro, un Web Service es una entidad ejecutable de software, totalmente encapsulada y “autosuficiente”, que puede ser detectada e invocada a través de una red para cumplir con un propósito determinado. El “consumidor” de un Web Service desconoce la complejidad interior de la misma, desconoce la plataforma y el lenguaje en el que está escrita, pero sí conoce el efecto concreto de su ejecución. La invocación del Web Service se realiza a través de protocolos de mensaje absolutamente estandarizados, y, por supuesto, los Web Services son reusables.

Los Web Services proveen un mecanismo para que las aplicaciones hablen unas con otras prescindiendo de la plataforma de cada una de ellas, y sin estar controladas por ningún proveedor. Una compañía podría, por ejemplo, diseñar un Web Service que permita verificar el historial crediticio de un cliente. Este Web Service podría estar disponible para ser “consumido” por cualquier aplicación interna o externa, sin importar si la misma corre en Linux, Windows, JAVA o ABAP.

Más de lo mismo?

Un primer análisis a la definición abstracta de Web Services parece NO encerrar nada demasiado nuevo. En cierta forma, parece que estuviéramos hablando de viejos conceptos: aplicaciones descompuestas, componentes reusables, complejidad encapsulada como caja negra, independencia de plataforma, interoperabilidad entre entornos heterogéneos, etc. De hecho, como mencionáramos anteriormente, no son éstas preocupaciones nuevas para los desarrolladores. La industria del software ha estado trabajando todos estos años sobre nuevos paradigmas para resolver las limitaciones del modelo procedural, aislado y propietario, de la década del 80. Innumerables tecnologías han ido surgiendo y permitiendo algunos progresos en este sentido.

Los lenguajes del ’90 trajeron API’s, funciones y librerías reusables. El desarrollo de las soluciones tipo ERP nos permitió tener software integrado, “out-of-the-box”, con mucha riqueza funcional. Luego, el paradigma cliente servidor nos trajo aplicaciones estratificadas en capas y distribuidas para aprovechar las mejores aptitudes de cada plataforma. Java y el modelo de objetos nos trajo la noción de portabilidad, componentización y abstracción. Paralelamente, Internet nos trajo el irreversible camino hacia la interfaz de usuario estandarizada, y la universalidad de las comunicaciones. También surgieron protocolos para implementar conectividad entre aplicaciones: RFC, CORBA/DCOM y otras soluciones propietarias. Sin embargo, ninguna de estas tecnologías por sí solas pudo sortear todos los obstáculos.

Porqué Web Services es diferente

Los Web Services son, en cierta forma, la evolución natural y predecible de este proceso. La principal diferencia con sus predecesores es que, por primera vez, y gracias a los estándares de la Web, existe una oportunidad concreta de aceptación y universalidad de estándares.

• La definición de Web Services es independiente de los lenguajes y las plataformas de desarrollo. Todos los principales “vendors” de aplicaciones soportan Web Services. Detrás de los Web Services hay varios comités de estandarización.
• Las definiciones de Web Services están expresadas en sintaxis XML, lo que hace sencillo desarrollar y ofrecer las herramientas para definir servicios basados en XML.
• Web Services, como su nombre lo sugiere, se ejecutan fácilmente sobre Internet, permitiendo escenarios absolutamente distribuidos.
• Casi cualquier lenguaje permite desarrollar Web Services, incluyendo JAVA, ABAP, C.

Para entender este proceso, resulta útil compararlo con la evolución que se diera los últimos años con las interfaces de usuario.

Desde que existe la Web, el mundo ha podido acceder a información y aplicaciones desde cualquier lado usando Web Browsers. La Web utiliza estándares para formatear y transmitir información desde y hacia el browser, basado en protocolos HTML y HTTP respectivamente. La amplia aceptación de estos estándar ha llevado a un crecimiento espectacular y ha reemplazado mayoritariamente los accesos propietarios.

La misma transformación que ocurrió en las interfaces de usuario a partir de la creación de los estándares HTTP y HTML es ahora posible masivamente para el intercambio entre aplicaciones. Los métodos propietarios para conectar e integrar aplicaciones serán reemplazados por métodos estándar basados en Web Services.

Enterprise Services y SAP Enterprise Services Architecture

Cualquier servicio, simple o complejo, implementado con las consignas de un Web Service puede ser considerado como tal. (Por ejemplo, eliminar un registro del sistema de órdenes). Sin embargo, preferimos la designación de Enterprise Services para definir a aquellos Web Services que, por su alcance y complejidad, conforman una solución completa a una necesidad de negocio. Por ejemplo, un Enterprise Service podría ser “cancelar el pedido de un cliente”. Este Enterprise Service seguramente involucrará la participación de muchos otros Web Services que verifican datos, eliminan registros de una o varias tablas, envían mensajes de aviso, impactan sobre el sistema finaciero, etc. etc.

ESA (Enterprise Services Architecture) es el “blueprint” de SAP para ayudar a los desarrolladores a adoptar e implementar un modelo de programación basado en Enterprise Services. Materializado a través de las herramientas y soluciones de SAP Netweaver, representa la nueva visión de SAP, alrededor de la cual apoyará toda su oferta de productos actual y futura.

II. WebServices : La definición Formal

La definición formal de un WS hecha por el World Wide Web Consortium es:

“Un web service es un software aplicativo identificado por un URI (*), cuya interfaz y vínculos pueden ser identificados, descriptos y descubiertos por artefactos XML y soporta interacción directa con otros software aplicativos utilizando mensajes basados en XML a través de protocolos basados en Internet.”

• Desde un punto de vista práctico, los XML web services son una categoría de componentes de software que proveen funcionalidad a través de Internet. Las características normalmente presentes en WS son:
• La interacción con los WS se produce utilizando protocolos estándar de Internet. Esto incluye los más conocidos como TCP/IP, HTTP; XML así como los nuevos estándar como Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) y Universal Discovery, Description and Integration (UDDI).
• Un WS no suele ser una aplicación completa sino que frecuentemente es un componente funcional que forma parte de una solución más amplia. De aquí se desprende que los WS están orientados inicialmente hacia la interacción entre programas.
• Los WS exponen su funcionalidad a través de interfaces bien definidas. Las mismas proveen a los programadores de detalles suficientes para utilizar la funcionalidad ofrecida por el WS. El lenguaje utilizado para esta descripción es WSDL.
• Los WS son publicados en un registro, que puede ser publico o privado dependiendo de la naturaleza del WS. El proceso de registrar y buscar un WS está definido por los estándar UDDI.

Estándares y Protocolos

Aunque los WS son una nueva tecnología, hacen uso de muchos estándares y protocolos ampliamente difundidos.

Publicación y búsqueda

UDDI (Universal Description, Discovery and Integration) es una iniciativa para producir un registro de WS. Básicamente, UDDI ofrece una guía de compañías que puede ser buscada por nombre, industria donde opera y región donde se ofrece el servicio. De esta forma, el programador conoce la existencia, propósito y ubicación del servicio.

Ejemplos de registros UDDI públicos:

Cada uno de estos registros contiene la misma información y son actualizados de manera consistente.

Las compañías pueden además establecer registros UDDI privados para listar los servicios disponibles dentro de su red privada.

Definición

Una vez que el WS ha sido descubierto necesitamos entender qué interacciones soporta. El Web Service Description Language (WSDL) es el estándar para definir WS. WSDL es un formato XML que contiene información sobre cada mensaje que puede ser enviado al servicio y la clase de respuesta retornada. WSDL provee la base para un contrato que indica al cliente como se comportará el WS.

Messaging

Una vez que hemos accedido a la definición del WS podemos enviar mensajes al servicio para acceder a su funcionalidad. Simple Object Access Protocol (SOAP) ha sido adoptado como el mecanismo para enviar mensajes entre clientes y WS. SOAP se basa en XML y no está ligado a ningún lenguaje ni plataforma.

Ejemplos de Web Services

El tipo más común de WS provee acceso programado a la información, por ejemplo, control de stock, tasas de tipo de cambio, horarios de arribo de vuelos y traducción de idiomas. Esta información puede ya estar a disposición de las personas electrónicamente a través de páginas web, documentos o sistemas propietarios. Sin embargo, en estos formularios la información puede ser complicada de manipular desde la programación. Con WS la información viene publicada utilizando interfaces bien definidas y se accede por medio de protocolos estándar y representaciones de datos. Cualquier dispositivo o programa, sin importar la plataforma o lenguaje de programación, puede comunicarse con el WS a través de la red para acceder a la información. Las aplicaciones de tal servicio son inagotables, cualquier escenario de provisión de información es un ambiente ideal para apoyar la entrega en el modelo de WS.

Además de brindar información al cliente, un WS puede con la misma facilidad actuar como un repositorio de información. Esta capacidad permite que muchas aplicaciones de diversas plataformas compartan y manipulen la misma información. Servicios como agenda y almacenamiento de archivos son buenos ejemplos donde los WS pueden aportar valor. Estos servicios permitirían a las personas acceso a su información independientemente de su ubicación o plataforma utilizada.

Las características mencionadas abren muchas posibilidades para aplicaciones y WS intermediarios. Por ejemplo, si las compañías de transporte dispusieran información sobre los horarios de sus colectivos, trenes y vuelos utilizando WS, una aplicación o WS intermediario podría utilizar dicha información para planificar la ruta óptima entre dos lugares.

Otro ámbito excelente para la aplicación del modelo de WS es para integrar sistemas anteriores dentro de modernas soluciones IT. La utilización de WS para construir una capa de abstracción entre los clientes y los sistemas anteriores conlleva numerosos beneficios. Las nuevas plataformas del cliente obtienen acceso a los sistemas anteriores y el WS puede coordinar las actividades a través de múltiples sistemas a medida que procesa los requerimientos del cliente.

Ventajas de los Web Services

Como se desprende de los ejemplos anteriores, el modelo de WS provee interesantes posibilidades. Sin embargo, estas capacidades pueden ser realizadas usando otros modelos aplicativos. Las verdaderas ventajas de los WS no reside tanto en lo que hacen sino en cómo lo logran.

El principal beneficio es la integración. El costo de proyectos en los que se trata de integrar aplicaciones, sistemas y tecnología diversas es muy alto. Los WS ofrecen un estándar ampliamente consensuado que representa la herramienta de integración perfecta, logrando interoperabilidad real así como bajando ostensiblemente los costos.

• Basados en estándares
• Tecnología no propietaria
• Simplicidad
• Independencia de lenguaje y plataforma.
• Abstracción funcional
• Herramientas de búsqueda
• Tiempo de desarrollo reducido

Escenarios no recomendados para aplicar Web Services

El modelo de WS es una herramienta que provee un mecanismo para entregar funcionalidad a los usuarios. Los WS no son la respuesta indicada en todas las situaciones. Estas son situaciones en las cuales los WS pueden resultar inapropiados:

• Sistemas Cerrados: En ocasiones el ámbito del problema es tal que el cliente al que apuntamos está unívocamente definido. La solución puede ser diseñada para un grupo de personas o puede ser aplicable solo a usuarios de cierta plataforma. En estas situaciones, los beneficios de los WS pueden no ser necesarios.
• Performance Crítica: Los WS proveen flexibilidad al costo de la performance. Los documentos XML pueden ser lentos de crear y procesar. En sistemas donde la performance es un factor crítico de éxito debería evaluarse si el costo extra de la utilización de WS es realmente útil.
• Confiabilidad: Para proveer el soporte mas amplio posible, los WS se apoyan en los protocolos e infraestructura de Internet. Si la solución a desarrollar brindará servicios críticos a los usuarios, debería considerarse la confiabilidad general de Internet y la de los proveedores externos de WS.
• Limitaciones Técnicas: Los WS no se desempeñan tan bien como otras tecnologías en áreas como el soporte transaccional y la seguridad. Si estos son factores críticos debería considerarse la posibilidad de aplicar otra solución.

III. SAP y el soporte de Web Services

SAP brinda la posibilidad de extender las soluciones empresariales por medio de web services JAVA o ABAP. En caso de implementar procesos que involucran diversos socios comerciales y sistemas heterogéneos puede ser beneficioso optar por desarrollos en JAVA. En cambio, para soluciones centradas en la selección de información, podemos considerar el entorno nativo.

El marco de desarrollo consiste de:

• Entorno de desarrollo de la personalidad ABAP
• Entorno de desarrollo de la personalidad J2EE
• Herramientas que soportan registración UDDI
• Entorno de ejecución distribuido SOAP (ABAP / J2EE)

Copyright Teknoda S.A.

• Anterior
• Siguiente