Standard ebXML

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
ebXMLelecció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 negocioperfiles 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
1
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
2
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
Entidad
funcional
Función de Función de
AF
Aplicación aplicación
Funciones
Middleware
Funciones
Baseware
Tecnologías de
Implantación
Componente EJB
CPP (ebXML Registry <−>
Empresa A)
Protocolo de
aplicación
AP
Programación de
Aplicaciones
API
Control de Servicio SCF
Gestión
MnF
Protocolo
Middleware
MP
Programación
Básica
BPI
Almacenamiento y
SPF
procesado
CPA ( Empresa A <−>
Empresa B), XML
Java API para
CPP/CPA(JSR−157), JAXR
(JSR 93),Servlet API
MSH(abstract service interface)
MSH(messaging service layer y
mapping to various transport
protocols),MIB,Agente SNMP
ebMS (SOAP 1.1),HTTP, FTP,
SMTP,MIME package
Llamadas al sistema,XTI
Java API:JDBC, JAXM
(JSR−67)−JAXP,JAXB
JVM
Sun Solaris
(ebXML Registry)
Interfaz
HCIF
Hombre−Máquina
Protocolos
NF
Baseware
Microsoft Windows 9x/NT
UDP,TCP 802.2(LLC)
IP 802.3 MAC
10 BASE T
3
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
4
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
5
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
Protocolo robusto y fiable
Control empaquetado
Estructura del mensaje
Envelope validatión
Firma digital
Encriptación soportada en mensaje
Encriptación soportada en payload
Control de aplicación back−end
SOAP
TCP/IP
Basado en XML
XML+DTD Schema
Control limitado vía UDDI
NO SOPORTADO
NO
Con transmisión SSL
NO
ebMs
TCP/IP SMTP
XML.MIME+attachments
XML+business templates
Total validación con CPA
Soportado por certificados XML
SI
SI
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.
6
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
7
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
8
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
9