Abstract. En este documento trazamos el standard profile de ebXML comparándolo con la tecnología Web Service de W3C. Hemos supuesto que el lector está familiarizado con Web Service del W3C y el standard ebXML. No obstante, para definir el escenario típico de actuación trazamos un proceso típico de negociación en ebXML.

Introducción

Situación de partida: Dos organizaciones precisan realizar negocios y deciden implementar el standard ebXML.

El proceso de negocio e-Business entre dos empresas que desean realizar transacciones comerciales mediante comercio electrónico basado en el standard ebXML es como describimos a continuación. Para intercambiar información ambas utilizarán el “ebXML Messaging Service” como servicio que les resuelve la problemática de transporte de la información entre ellas.

Fase de implementación

Como sabemos, en el ebXML Repository encontramos una colección de procesos y escenarios de negocio adecuados para transacciones entre empresas de un determinado sector de la industria así como perfiles específicos ofertados por las empresas implicadas. En esta fase nuestra empresa decide incorporarse al sistema ebXML y requiere darse a conocer. Para ello inicialmente pedimos al registro las especificaciones ebXML y las aprendemos.

Una vez conocemos las especificaciones, implementamos nuestro perfil de negocio ebXML CPP (Collaboration Protocol profile).

Finalmente solo nos queda publicar nuestro perfil CPP para que seamos “visibles” en el mundo ebXML y estemos en disposición de ser descubiertos por otras empresas interesadas en nuestro negocio. El CPP describe las características soportadas en el proceso, los requisitos obligatorios así como información técnica ebXML—elección de algoritmos de encriptación, certificados de encriptación y elección del protocolo de transporte-[1]-.

Fase de búsqueda del perfil de negocio del futuro socio y negociación del pliego de condiciones de la transacción

En esta fase nuestra empresa solicita al registro información del futuro socio de negocio—perfiles y escenarios--. Con esta información estamos en buena disposición para entender las capacidades y requisitos de negocio de la empresa socio tales como el tipo de proceso de negocio en el que está interesado, los mensajes que deben ser intercambiados, los mecanismos de transporte, la seguridad e integridad del proceso, etc.

En el mundo real se negocia el pliego de condiciones entre las partes y ebXML no es una excepción. Así, el siguiente paso que debemos acometer es el ponernos de acuerdo con nuestro socio. Para ello, enviamos un contrato al socio denominado en ebXML CPA (Collaborative Partner Agreement). El CPA debe reflejar los perfiles CPP de ambas empresas.

A partir de aquí, negociamos con nuestro socio adaptando el CPA a nuestros procesos e intereses hasta que llegamos a un contrato definitivo para poder empezar la transacción entre las partes. El CPA contiene la información para configurar correctamente el software que utiliza cada una de las partes para el intercambio electrónico de la información[1]. En esta fase es muy aconsejable que el personal clave de negociación de ambas compañías se conozcan en persona para intercambiar impresiones antes de empezar la relación eBusiness.

Fase de transacción

Ahora ya podemos efectuar transacciones con nuestro socio. El CPA se ha acordado en la fase anterior y las transacciones se efectuarán de un modo predefinido donde ambas empresas han jugado un rol participativo en el diseño del intercambio de información útil de negocio. Las transacciones consisten en mensajes ebXML que son enviados sobre el servicio de mensajería denominado ebMS(ebXML Messaging Service) que el standard nos ofrece.

Escenario típico e implementación

Teniendo claro el proceso de transacción podemos ya establecer un escenario típico.

Los actores implicados son las dos empresas que van a establecer relaciones comerciales y el registro ebXML (ebXML Registry/Repository). Estos actores están conectados mediante una infraestructura con elementos intermedios de interconexión, de seguridad como firewall y redes.

Para la implementación del servicio ebXML de entre las opciones que nos ofrece el mercado hemos elegido la plataforma J2EE de Sun Microsystems

La Plataforma J2EE abarca las áreas clave en el desarrollo de e-business:

• Desarrollo de la conectividad con el cliente (client-tier) -applets, aplicaciones, business partners, web browsers,etc.—donde se utiliza el servicio web

• Implementación del servicio web incluyendo la lógica workflow, la lógica de transformación de datos, la lógica de negocio y la de acceso a los datos. Esta funcionalidad que existe detrás de web service es la que realiza el trabajo en nombre de los clientes.

• Proporciona solución a la conexión al back-end del sistema , el cual incluye una o más bases de datos, información existente en la empresa, business partners que publican sus propios servicios web, y un contexto de almacenamiento compartido para utilizar información a través de diferentes sistemas.

El entorno J2EE para web service tiene la siguiente estructura:

La conectividad del cliente ebXML: el tipo de cliente es Business Partner. Cuando un socio de negocio hace una petición a un web service, el recipiente del tipo de documento XML es un Java servlet. El servlet ,objeto java basado en petición/respuesta, está gestionado por el entorno del container y puede contestar usando cualquier protocolo (HTTP,FTP,POP,etc.)

En la plataforma J2EE el componente EJB invoca los web service de los socios utilizando los APIs JAX.* que Java proporciona[3]:

Usa el Java API para registros XML (JAXR) para buscar los CPPs publicados en el ebXML Registry

Usa el Java API para mensajes XML (JAXM) para enviar SOAP o mensajes ebXML al servicio web externo.

Usa el Java API parsing para XML (JAXP) y el Java API binding para transformar datos Java en formato adecuado XML

En la siguiente figura se muestra el uso de los APIs JAX.* al invocar un business web service

III. Trazado del Standard Profile según el modelo GII de ITU en ebXML

Una vez definido y explicado el escenario típico de funcionamiento en ebXML podemos trazar el del standard profile según el modelo GII

Hemos de hacer algunas consideraciones previas :

No hemos trazado el standard profile de los elementos intermedios y englobamos en uno el de los tres actores: las empresas y el registro.

Los standard profile de las empresas son el mismo y tenemos que distinguir las situaciones de intercambio con el ebXML Registry donde el protocolo de aplicación es el CPP y la situación de negociación entre empresas donde el protocolo es el CPA.

El registro tendrá como protocolo de aplicación el CPP y no tendrá HCIF..

ebXML (Empresa A/B &EbXML Registry)
Nivel funcional	Entidad		Tecnologías de Implantación
Función de Aplicación	Función de aplicación	AF	Componente EJB
		Protocolo de aplicación	AP	CPP (ebXML Registry <-> Empresa A) CPA ( Empresa A <-> Empresa B), XML
		Programación de Aplicaciones	API	Java API para CPP/CPA(JSR-157), JAXR (JSR 93),Servlet API
	Funciones Middleware	Control de Servicio	SCF	MSH(abstract service interface)
		Gestión	MnF	MSH(messaging service layer y mapping to various transport protocols),MIB,Agente SNMP
		Protocolo Middleware	MP	ebMS (SOAP 1.1),HTTP, FTP, SMTP,MIME package
		Programación Básica	BPI	Llamadas al sistema,XTI Java API:JDBC, JAXM (JSR-67)-JAXP,JAXB
	Funciones Baseware	Almacenamiento y procesado	SPF	JVM Sun Solaris (ebXML Registry)
		Interfaz Hombre-Máquina	HCIF	Microsoft Windows 9x/NT
		Protocolos Baseware	NF	UDP,TCP 802.2(LLC) IP 802.3 MAC 10 BASE T ARP

Funciones Baseware

Network Function(NF): Aquí incluimos aquellas funciones de transporte y control entre entidades en localizaciones separadas en la GII

Interfaz Hombre-Máquina(HCIF): En la fase de implementación y negociación precisamos de interfaz donde pedir los modelos de negocio del sector y del partner de interés y reflejar el feedback entre las empresas(proceso asíncrono).

Almacenamiento y procesado (SPF): En las entidades lógicas que ejecutan componentes middleware y de aplicación y almacenan información tenemos la JVM .y una Sun Solaris. En el estándar, como hemos visto, define el ebXML Registry donde se almacenan los BPSS y CPP. Lo incluimos entre paréntesis por ser un actor propio del escenario típico.

Funciones middleware

Protocolo Middleware(MP): El standard define el ebXML Message Service. El ebMS proporciona el camino standard de comunicación para intercambiar información del proceso de negocio entre empresas. El servicio proporciona funciones de seguridad que incluyen identificación, autenticación,autorización, privacidad, mensajes firmados, no repudio y loggin.

El mensaje está compuesto de dos estructuras de información: una cabecera que se utiliza para routing y entrega de los mensajes, una parte de payload usada para la comunicación entre las empresas. El servicio proporciona un camino de intercambio de información B2B en el payload de una forma fiable y segura..

La parte payload puede no ser un documento XML(por ejemplo, una información para una transacción EDI). La información del Payload puede ser una concatenación de documentos de negocio XML o de otro tipo de formato((imágenes binarias, información de negocio, etc) Con ebMS enrutamos el payload correctamente al interior de la aplicación. Así , el mensaje tiene un protocolo envoltorio de comunicación exterior(outer-communication protocol) el cual es específico para el protocolo de transporte y un protocolo envoltorio independiente para el mensaje. El mensaje ya envuelto es empaquetado con MIME(Context type:multipart).

El servicio consiste en tres partes lógicas

El abstract service interface: que incluye la funcionalidad para enviar y recibir, notificar y preguntar.

La messanging service layer controla las reglas de funcionamiento del negocio usando el CPA. Incluye seguridad y funciones para asegurar la fiabilidad del mensaje. Cualquier violación de las reglas del CPA provoca un error en el sistema de intercambio.

El mapping to various transport protocols incluye SMTP,HTTP y FTP. El servicio de mensaje define formatos para todos los mensajes a través de componentes distribuidos, incluyendo el registro y las aplicaciones de usuario. No pone restricciones acerca del contenido del payload Soporta notificaciones de ida , de petición/respuesta y ambas pueden ser síncronas o asíncronas. También soporta secuencias de payloads en los casos donde existe multiplicidad de mensajes intercambiados.

MSH

Para enviar y recibir mensajes ebXML es necesario el manejador MSH (ebXML Message Handler). Las principales funcionalidades del MSH son el envío de mensajes, asegurar su integridad, seguridad(a varios niveles--tanto a nivel de mensaje como de transporte--). El mensajeado (envío y recepción) está basado en SOAP con accesorios o funciones de mejora(SOAP with attachment) sobre cualquier protocolo de transporte(SMTP, HTTP ,FTP),persistencia( para monitorizar y auditar ), etc. Cualquier MSH es capaz de proporcionar el protocolo de transporte deseado, capacitar seguridad, aplicar los algoritmos de encriptación acordados, etc. Como ya comentamos en la primera parte del documento, una vez se ha llegado a un acuerdo al final del CPA , ambas partes obtienen una copia del CPA. El CPA se instala entonces en el MSH. En el caso de realizar varias negociaciones el MSH gestiona el mensaje con el CPA correspondiente a cada negocio.

Gestión(MnF): Aquí incluimos la gestión de los protocolos de transporte y el MSH con las partes lógicas del servicio messaging service layer y mapping to various transport protocols.

Control del servicio(SCF):Nuevamente incluimos aquí el MSH aunque en este caso le asociamos la parte lógica de abstract service interface que proporciona el control de la interacción en ebMS.

Programación básica: (BPI) Como JAXM actúa sobre SOAP: las interfaces lógicas entre las funciones middleware y las baseware son las siguientes :XTI, llamadas al sistema, y los siguientes APIs de Java:

JAXM(JSR 67):Messaging

JAXP(Para procesado XML -JSR05)

JAXB((Java API for XML databinding,JSR 31)

Función de aplicación

Función de aplicación(AF): Como hemos comentado en la implementación de ebXML, en J2EE la función de aplicación está modelada por un objeto componente EJB el cual recibe las peticiones vía servlet , consulta el registro , envía la información al servicio middleware ebMS y dirige el parseado.

Protocolo de aplicación: El protocolo de aplicación depende de si la comunicación es entre empresa y registro o entre empresa y empresa. En el primer caso es el CPP y en el segundo el CPP.. También incluimos XML como protocolo básico en aplicaciones Web service.

Programación de aplicaciones (API): Aquí Java[2] nos ofrece su API específico para servlets , para obtener información y gestionar los CPPs en el Registry JAXR( JSR 93) y el Java API para implementar ebXML (JSR 157).

IV. Web Service de W3C vs ebXML de OASIS

En este punto ya estamos en disposición de realizar una comparativa basada en el standard profile trazado del escenario típico ebXML con el de Web Service de W3C

Para cada función del modelo GII vamos a destacar las diferencias más significativas.

Función de aplicación

En la función de aplicación destacamos 2 aspectos :

Los 2 modos de usar XML: en Web service W3C para ordenar los argumentos en una llamada a procedimiento remoto(RPC) y usar XML para crear proceso de negocio. Lo que tenemos claro es que un B2B document no es una RPC( los procesos de negocio requieren una comunicación asíncrona antes que la síncrona y requiere funcionalidades obligadas de encriptación, no repudio, firma digital,etc.)

El protocolo en W3C es XML. XML no es efectivo para empaquetar datos binarios( documentos XML y posee codificación especial para empaquetar código binario). Para documentos B2B es óptimo MIME ya que empaqueta cualquier formato de datos (ebXML empaqueta con MIME). En ebXML con los protocolos CPP/CPA logramos ajustar cada relación e-Business en un proceso óptimo de transacción entre las socios .

Estos aspectos nos indican que Web service W3C no es adecuado para transacciones B2B. El origen de ebXML es el B2B. Extraemos de esta forma las relaciones :

Web Service- Departamento empresarial- Intranet

ebXML- Socio B2B Extranet

Funciones middleware

En las funciones middleware la principal diferencia es el protocolo middleware

En Web Service de W3C es SOAP y en ebXML es ebMS.

SOAP vs. ebMS

Simply Object Access Protocol (SOAP), el equivalente del RPC (Remote procedure Call) basado en Web utilizado en comunicaciones servidor a servidor, utiliza XML para el control sintáctico y formato del mensaje a través de Internet. La seguridad viene proporcionada por mecanismos shttp, firewall y filtrado por IP. En el protocolo se asume un solo servidor SOAP el cual no incluye ninguna extensión para soportar mecanismos sintácticos derivados de XML que proporcionen modelos de negocio como es el caso de ebXML. .Como ya conocemos ebMS hemos destacamos sus características principales comparándolas con las de SOAP mediante la siguiente tabla

.

capacidad	SOAP	ebMs
Protocolo robusto y fiable	TCP/IP	TCP/IP SMTP
Control empaquetado	Basado en XML	XML.MIME+attachments
Estructura del mensaje	XML+DTD Schema	XML+business templates
Envelope validatión	Control limitado vía UDDI	Total validación con CPA
Firma digital	NO SOPORTADO	Soportado por certificados XML
Encriptación soportada en mensaje	NO	SI
Encriptación soportada en payload	Con transmisión SSL	SI
Control de aplicación back-end	NO	XML mapping+ACK

Observando la tabla nos afianzamos en la opinión de no utilizar web service en B2B y las relación anteriormente expuesta se refuerza.

Respecto a BPI tenemos que destacar que la diferencia entre JAXM y JAX/RPC(aunque en el standard aparecen en funciones distintas en J2EE están en la misma capa de programación) es análoga a la diferencia entre MOM (message oriented middleware) y RPCs. JAMX esta equipado a través de aplicaciones tipo MOM mientras que JAX/RPC está diseñado específicamente para RPC.

Funciones baseware

En las funciones de red observamos la orientación Intranet de Web Service de W3C y la extranet de ebXML. Como explicamos en el standard, aparece interfaz HCIF debido al proceso asíncrono de la negociación .

Finalmente destacamos las diferencias en el almacenamiento. Web service utiliza registro UDDI mientras que ebXML utiliza un registry/repository. La diferencia entre un registro y un repositorio es la siguiente:

Un registro almacena meta-datos acerca de objetos del repository y las operaciones que puede efectuar son del tipo(submit, manage,search,etc..),

Un repository:contiene CONTENIDO(objetos), CPA/CPP, BPSS y no tiene equivalente en UDDI(los tmodels son referencias los documentos WSDL pueden estar almacenados en cualquier lugar). Observamos así la distinta finalidad de UDDI y ebXML: ebXML está orientado a tener contenido de gestión que fue diseñado, almacenado y gestionado por una red de parámetros de comercio electrónicos establecidos por las necesidades sectoriales industriales estableciendo sus BPSS. UDDI fue diseñado para gestionar metadatos asociados a un servicio web.

V. Conclusiones

Como conclusión extraemos que la relación que observamos en la comparativa se ha afianzado en todas las funciones del standard profile. Para implementar una colaboración B2B debemos de utilizar el standard ebXML En transacciones la flexibilidad, seguridad, fiabilidad, confiabilidad, integridad en las relaciones son una base para llegar a un acuerdo y el estándar ebXML nos ofrece ese marco cosa que Web service de W3C no. La gran potencialidad estriba en la abstracción y la seguridad que ofrece. La abstracción de datos(BPSS) en el aspecto le da una exclusividad a medida a la negociación y la seguridad porque proporciona el manto adecuado para que ambas partes del negocio puedan sentarse a negociar. En cuanto a la implementación , en Sun Microsystems han hecho una apuesta muy fuerte por ebXML ofreciendo a los desarrolladores los APIs necesarios. De hecho muchas iniciativas de ebXML están utilizando Java.

En este contexto todo parece indicar que se va imponer como standard global.

VI. Referencias

[1] Eric Chiu. EbXML Simplified-A guide to the new standard for Global E-Commerce.John Wiley&Sons,Inc.2002

[2] Sang Shin,“ebXML What is ebXML? Why ebXML?”,Sun microsystems (http://www.javapassion.com/webservices/ebXML4.pdf, visitado 30/6/2004)

[3] (http://www.cascadetg.com/downloads/XMLJava.pdf, visitado 25/6/2004)

Cada empresa debe adaptar su perfil de negocio a un lenguaje entendible para el resto de las empresas. Esa semántica entendible la extrae de las especificaciones que el ebXML Registry/Repository le proporciona

Denominamos socio de negocio al cliente o proveedor con quien efectuamos la transacción

Firewall

Red Privada A

Red Privada B

Firewall

Red de Telecomunicación

Firewall

Empresa A

(ebXML implementado)

Empresa B

(ebXML implementado)

ebXML

Registry/Repository

Servlets

JSP

EJBs

Business Partner

Applets, aplicaciones

Web browser

Context

Repository

Bases de datos

Sistemas ERP

ebXML

registry

Conectores

firewall

CLIENT TIER

BACK-END SYSTEMS

WEB SERVICE CONTAINER

ebXML

ebXML

JAXM

EJB

(Session Bean)

Servlets

JAXP,JAXB

JAXR

Business Partner

ebXML

registry

Petición cliente

2.Localiza el servicio y su descripción CPP

7.Transformación XML

3.Resultado de la petición ebXML

6.Respuesta recibida

1.Registro de CPP en el Repository

4.XML/HTTP/.

5.XML/HTTP

firewall

CONTAINER

CONTAINER