ebXML. Parte 2: Funcionamiento en un Sistema Completo.

En el número anterior, dimos un contexto general sobre lo que es ebXML y sus principales componentes. En esta ocasión, mostramos con mayor detalle el funcionamiento de ebXML en un sistema, así como su relación con RosettaNet y Web Services.

La orientación de la arquitectura técnica de ebXML se enfoca en proveer una estructura para que las organizaciones puedan colaborar en la integración de sus procesos externos. Típicamente el primer paso de este proceso consiste en que una organización defina y publique sus procesos de negocio en un repositorio donde otras organizaciones puedan descubrirlos. Una vez que otra organización los descubre, basándose en ellos y en su propia definición de procesos, inicia una secuencia de negociación mediante la cual se establecen acuerdos de colaboración, y apegándose a los términos y condiciones de estos acuerdos, los socios de negocios crean y configuran sus interfaces electrónicas de servicios, con lo cual se habilitan para iniciar transacciones y ejecutar así los procesos acordados. Los procesos definidos en la primera fase de este escenario y que a su vez han sido acordados con otros socios de negocios deben administrarse y verificar que satisfacen los acuerdos. Conforme los participantes en la comunidad de negocios electrónicos aumentan, se evalúan los procesos existentes con el propósito de mejorarlos y se definen nuevos procesos con el fin de ajustarse a las necesidades del mercado. La secuencia descrita en el escenario anterior, necesaria para el establecimiento de una comunidad con procesos externos compartidos e integrados entre sí, puede perfectamente llevarse a cabo mediante la implementación de las especificaciones que forman la estructura ebXML. En este artículo se muestra la correspondencia entre los pasos del proceso descrito y cada una de las especificaciones ebXML.

Definición de Procesos de Negocio

Determinar qué procesos son necesarios para ser tomados en cuenta en una estrategia de comercio electrónico, además de la descripción de cada una de las actividades y elementos que los forman, es una tarea que puede ser realizada con mayor facilidad si se emplea una metodología orientada a capturar el conocimiento de una organización en prácticas de comercio electrónico. UMM fue desarrollada con ese propósito, además de que ebXML la recomienda debido a que en las especificaciones BPSS y CPP/A existe una correspondencia con esta metodología.

Exhibición de las Capacidades, Servicios y Procesos

El modelado de procesos, necesario para describir y definir las capacidades de colaboración de un socio de negocios, es normalmente independiente de la tecnología. Sin embargo, para poder exhibir dichas capacidades en un repositorio público de tal forma que puedan ser encontradas por socios potenciales, es necesario exponerlas en un formato estándar entendible electrónicamente y capaz de ser procesado e interpretado por una máquina. ebXML define dos esquemas XML para este propósito: CPP y BPSS. El documento principal que describe las capacidades de un socio de negocios es el CPP, dichas capacidades están definidas en términos de roles que desarrolla, empaquetado de los mensajes, protocolos de transporte que es capaz de desarrollar, mecanismos de seguridad y procesos que ejecuta. La definición de los procesos se especifica en otro documento, en el CPP sólo se incluyen referencias a él. Aunque ebXML provee la especificación BPSS para la definición de procesos de negocios, no limita a que en el CPP se incluyan referencias a documentos formados con esquemas diferentes, que pueden ser XLANG, WSFL o PIP (Rosetta Net).

En cuanto a la definición de contenido de los mensajes que intervienen en las colaboraciones, ebXML no especifica ninguna recomendación, dejando esta responsabilidad a otros organismos, los cuales pueden emitir formatos más apegados al giro de los negocios involucrados. Actualmente existen asociaciones que han definido contenido de mensajes para intercambio electrónico, como lo son: EDIFACT, ANSI, XEDI, Automotive Industry Action Group (AIAG), BOLERO.NET, OAG y otros.

Para almacenar el CPP y el documento que describe los procesos (que puede ser definido mediante el BPSS) en un repositorio, se utilizan los servicios de la interfaz Life Cicle Management (LM), provista por el registro. Para tener acceso a esta interfaz es necesario ser un usuario registrado en dicho repositorio. Un registro/repositorio normalmente es desarrollado por comunidades de empresas que se asocian con el fin de integrar sus procesos de negocios, sin embargo también existen empresas que proveen servicios de hospedaje en sus repositorios además de herramientas de software para transferencia electrónica de mensajes, modelado de procesos, transformación entre formatos XML etc.

Establecimiento de Acuerdos con Socios

Para encontrar socios de negocios potenciales, las empresas acceden a los servicios que ofrece el registro/repositorio a través de la interfaz Query Management. Para acceder a esta interfaz, no es necesario ser un usuario registrado del repositorio. Una vez que se descubre un posible socio en el registro, se puede transferir el CPP encontrado al servidor propio, con el cual se forma un CPA. Este CPA se envía al socio en cuestión para iniciar un proceso de negociación. Una vez que ambos socios están de acuerdo en el CPA, deben almacenar copias idénticas de este en sus servidores y con ellas configurar sus aplicaciones e interfaces con el fin de llevar a cabo los procesos acordados.

El CPA viene a ser un subconjunto de un CPP o puede ser la intersección entre los dos CPP’s a partir de los cuales se construye (el CPP propio y el CPP obtenido del repositorio) y define la forma en la que dos socios de negocios interactúan en la realización de las colaboraciones que han acordado, la interacción también puede llevarse a cabo a través de intermediarios, para lo cual debe existir un CPA entre cada parte y el intermediario (adicionalmente al CPA entre ambas partes).

Al igual que el CPP, el CPA contiene referencias a la especificación de procesos (definida en BPSS, XLANG, WSFL o PIP de Rosetta Net), la que define una o más conversaciones entre las partes involucradas. La conversación representa una unidad simple de negocios definida por una colaboración binaria. Una conversación consiste de una o más transacciones de negocios, cada transacción es un mensaje de petición emitida por una de las partes que participan en la colaboración, y cero o un mensaje de respuesta emitido por la otra parte. Además la especificación de procesos define el orden en el cual las transacciones deben efectuarse (coreografía).

El CPA puede implementarse en un servidor B2B en el sitio de cada socio, donde deben residir sus especificaciones de procesos. Debe incluir además de los servicios que provee, una bitácora de auditoría. La información estática puede ser almacenada en una BD local, para generar los datos contenidos en las transacciones necesarias para satisfacer el CPA.

Intercambio de Información

Como se mencionó en el artículo anterior, ebXML especifica SWA como método de empaquetado para el transporte de mensajes, el propósito inicial de esta especificación, es que quienes estén usando EDI puedan realizar la transición a ebXML sin complicaciones. Como beneficio adicional permite que el contenido útil del mensaje sea definido de forma libre y de acuerdo a las necesidades de las partes que intervienen en determinada colaboración. El cuerpo del mensaje SOAP contiene un listado de todos los documentos adjuntos al mensaje, el formato de cada documento puede ser XML, pdf, imágenes etc., siempre y cuando el formato se haya especificado en el CPA al cual el mensaje SOAP hace referencia. El destinatario del mensaje puede usar este listado para verificar si todos los documentos adjuntos se recibieron. Además, en el encabezado del mensaje SOAP se define un identificador de conversacion (ConversationId) para indicar la parte del proceso que se ejecuta una vez terminada exitosamente la transacción.

Administración de Procesos

Los pasos anteriores son los necesarios para completar un proceso de integración de procesos de negocios interempresarial. Como puede observarse, sólo dos especificaciones de la estructura de ebXML son necesarias para que dos partes puedan integrar sus aplicaciones en un esquema de colaboración: el CPA y ebMS. El CPA es el acuerdo que convierte a las partes en socios, cuyo fin común es la integración de sus aplicaciones. La especificación de mensajes (ebMS) es el medio a través del cual llevan a cabo sus transacciones.

Conforme la comunidad de negocios va creciendo, la dificultad para administrar los procesos de colaboración entre socios se incrementa. Suponiendo que se tienen 5 socios y con cada socio se ejecutan 3 procesos y cada proceso tiene 4 actividades, en total deben administrarse 60 actividades. Considerando que cada proceso puede tardar desde unas horas hasta varios días en completarse, monitorear el estado de cada proceso conlleva algunas complicaciones.

Considerando el problema de administración de procesos ejecutables, surge una tecnología para ayudar a las empresas a administrar sus procesos a fin de optimizarlos y adaptar el comportamiento de las empresas a los cambios que normalmente son necesarios. Estos sistemas se conocen como Business Process Management Systems (BPMS) —ver SG Año 1 No. 4—, y aunque ebXML no recomienda un modelo particular de implemantación, este tipo de sistemas deben ser considerados al planear proyectos que involucran procesos ejecutables.

Relación de ebXML con RosettaNet

El consorcio RosettaNet (www.rosettanet.org) inició en Junio de 1998 auspiciado por la industria electrónica. El objetivo de la iniciativa es administrar de forma eficiente el canal de suministro a través del Internet. RosettaNet es un consorcio pionero en la definición de estándares basados en XML para integración B2B, y constituye la fuente de inspiración para ebXML. El modelo de esta especificación se divide en tres areas:

1. Intercambio de mensajes. RosettaNet Implementation Framework (RNIF)

2. Definición de procesos. Partner Interface Processes (PIPs).

3. Conjuntos de datos usados en giros específicos de la industria, tales como códigos de productos, códigos de industrias, etc.

RNIF v2.0 es una especificación muy parecida a la de ebMS, lo cual le permitió al consorcio RosettaNet alinearse completamente con ebXML en la versión 3 de RNIF.

En cuanto a la definición de procesos, RosettaNet ha desarrollado un catálogo bastante amplio. Cada proceso (PIP) está formado por diálogos especializados sistema a sistema en XML. Cada especificación de PIP incluye un documento de negocios con su correspondiente vocabulario y un proceso con la coreografía de los mensajes. Los PIPs están agrupados en siete áreas:

1. Captura de información, mantenimiento y distribución para el desarrollo de CPP y suscripciones a información de productos.
2. Distribución y actualizaciones periódicas de especificaciones técnicas.
3. Precios, tiempos de entrega, recepción y administración de órdenes.
4. Administración de inventario.
5. Campañas de información y mercadotecnia.
6. Asistencia técnica posterior a la venta.
7. Intercambios de diseño, configuración, procesos e información relacionada con manufactura.

Estas especificaciones de procesos son útiles para que las empresas que requieran integrar sus aplicaciones en un ambiente B2B escojan de entre este catálogo los procesos que mejor se ajusten a sus necesidades para definir sus CPPs. A partir del 2003 RosettaNet emplea la especificación de BPSS para definir todo su catálogo de procesos.

Relación de ebXML con Web Services

Existen muchas semejanzas que provocan confusión entre ebXML y Web Services. De hecho muchas empresas que ofrecen soluciones B2B e implementan en ellas especificaciones ebXML las anuncian como Web Services, colaborando con ello a aumentar la confusión.

Las principales semejanzas entre ambas tecnologías son:
• Usan el mecanismo de petición/respuesta sobre protocolos de transporte sin conexión permanente (HTTP, SMTP).
• Ambas usan SOAP como métodos de empaquetamiento de mensajes.
• El método para descubrir a las otras partes con quienes realizar transacciones es a través de un registro público (UDDI, registro/repositorio).
• ebXML especifica que la interfaz de un registro/repositorio pueda exponerse mediante servicios, lo cual provoca que las reglas de interacción con el registro se establezcan en un documento WSDL que puede ser descubierto mediante un UDDI.

Sin embargo, en los detalles de estas que parecieran ser semejanzas, existen profundas diferencias:
• El método de empaquetamiento de ebXML adiciona a SOAP extensiones que permiten la seguridad y confiabilidad de los mensajes usados en las transferencias, además de que es posible intercambiar documentos en cualquier formato convenido, no necesariamente XML.
• UDDI no provee almacenamiento de documentos, sólo provee referencias (links) a documentos WSDL, mientras que la separación entre registro y repositorio establecida por ebXML permite el almacenamiento de cualquier tipo de documentos. Este esquema puede ser usado para que una organización respalde todo el conocimiento adquirido, sus metadatos, la descripción de sus procesos etc., en un repositorio interno.
• La unidad atómica de Web Services es un servicio (transacción), mientras que en ebXML es una colaboración (proceso o conversación). Una colaboración está formada por una o varias transacciones que se realizan siguiendo una secuencia prestablecida, por lo cual es posible definir colaboraciones partiendo de servicios. Para agrupar servicios dentro de colaboraciones y definir el flujo de los mismos, se han establecido las especificaciones XLANG y WSFL propuestas por Microsoft e IBM respectivamente. Aunque estas empresas están entre los principales promotores de la tecnología de Web Services, no han podido establecer una especificación común para el flujo de los servicios que componen las colaboraciones, por lo cual sus respectivos productos y soluciones de integración B2B resultan ser incompatibles.

Aunque en el esquema de Web Services sea posible establecer colaboraciones partiendo de servicios, el hecho de que la unidad atómica de esta tecnología sea el servicio, compromete mucho la confiabilidad de las colaboraciones, más aún tratándose de que el protocolo de transporte HTTP no es orientado a conexión. Además de que el tiempo necesario para que una colaboración sea ejecutada puede tomar varios días.

Conclusión

En estos artículos hemos visto a grandes rasgos de lo que se trata ebXML. Es una tecnología bastante prometedora, que posiblemente ayude a evitar que las transacciones de negocio por Internet se conviertan en una torre de Babel. Los invitamos a que conozcan más sobre ebXML y analicen si su adopción puede traer beneficios a su empresa o industria.

Referencias
• www.ebxml.org