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