Revisión de los estándares ebxml, RossetaNet y BizTalk para aplicaciones de comercio electrónico

Transcripción

1 Revisión de los estándares ebxml, RossetaNet y BizTalk para aplicaciones de comercio electrónico Laura Grande Pérez Universidad de Salamanca, Salamanca, España lauragrande@gmail.com Abstract. Thanks to the nowadays universal use of Web and to the impact produced by the Information and Communications Technologies (ICTs), an innumerable amount of information exchange schemes has been developed, among them, XML. Based on this language, new standards have appeared trying to approach enterprises problems when facing a new reality, the electronic commerce (e-commerce) or a step beyond, the electronic business (e-business). This paper reviews three of these standards ebxml, RossetaNet and Biztalk, that are trying to introduce their e-commerce or e-business solutions into great, medium and small business, not only defining a common vocabulary (ontology) but also a scheme of dialogue between companies and a safer transfer protocol to use. Resumen. A partir de la explosión Web y el impacto producido por las Tecnologías de la Información y Comunicación (TICs), se ha desarrollado una innumerable cantidad de esquemas de intercambio de información, entre ellos XML. Basados en este lenguaje, aparecen nuevos estándares que abordan la problemática de las empresas a la hora de enfrentarse a una nueva realidad, el comercio electrónico o un paso más allá, el negocio electrónico. En este artículo se presenta una revisión de tres de estos estándares ebxml, RossetaNet y Biztalk, que buscan imponerse a la hora de implantar soluciones en grandes, medianas y pequeñas empresas, no sólo definiendo un mensaje sino el esquema de diálogo entre empresas y su transporte seguro a través de la red. 1. INTRODUCCIÓN El impacto producido por las Tecnologías de la Información y de la Comunicación (TICs) y el ritmo vertiginoso con que, hoy en día, se producen los cambios políticos, económicos, de mercado, de producción, etc., supone para las empresas un nuevo escenario de presencia, actuación y negocio, en el que deben posicionarse adecuadamente con objeto de asegurar la supervivencia, la competitividad y la representativi-

2 dad deseadas. El uso del correo electrónico, Internet y la tecnología web, la integración de bases de datos, gestores de documentos, programas de gestión de almacén (ERP), de gestión de clientes (CRM) etc., empiezan a ser frecuentes en la realidad empresarial. No obstante, en la mayoría de los casos, aún nos encontramos en el primer peldaño de la comúnmente reconocida Escalera Digital. Fig. 1. Escalera Digital El acceso al escalón de Negocio Electrónico (e-business), que representa una oportunidad para la creación de iniciativas empresariales, y permite a las empresas ya existentes ser más eficientes y flexibles en sus operaciones, no es fácil. Existen condicionantes a nivel estratégico, económico, organizativo y operativo que impiden que las empresas lleguen con éxito a este nivel. A la relación electrónica compra-ventapago entre vendedor-comprador-banco, se añaden, por ejemplo, la integración con las aplicaciones corporativas, la posibilidad de que un cliente pueda conocer el estado de su pedido, la automatización, la adaptación, la cooperación, la concurrencia, etc. El alcance del éxito en cada uno de los grados de madurez de la escalera tecnológica, pasa por encontrar la manera de modelar los conceptos y relaciones que se pueden establecer entre los diferentes componentes de una empresa. En los últimos años, el Intercambio Electrónico de Datos (EDI, Electronic Data Interchange), ha tenido un relativo éxito en la estandarización de intercambio de mensajes entre aplicaciones aunque ha resultado imposible hacer un estándar válido para todos los sectores empresariales. EDI permite mejorar las herramientas disponibles para implementar una solución y ayudar a avanzar en este sentido, pero la solución en sí es un problema conceptual inherente al trabajo con estructuras de información. En la actualidad el problema se intenta abordar a través del uso de la Tecnología Semántica y los Servicios Web. Como primera aproximación a la tecnología semántica, en 1998, aparece XML, un lenguaje de marcas extensible que empieza a ser utilizado como formato de representación de los datos y que define una sintaxis genérica para unos datos semiestructurados. Al ser XML un metalenguaje, se pueden crear a partir de él nuevos lenguajes específicos para un dominio de aplicación concreto. Esto significa que el desarrollo y la integración de aplicaciones es mucho más simple y rápido. La combinación de XML con los servicios web (protocolos remotos basados en datos codificados en este metalenguaje o cualquier sublenguaje derivado, y protocolos de transporte estándar en Internet) puede ser la artífice de la solución al intercambio de información

3 entre sistemas heterogéneos. tanto técnica como organizativamente. Las limitaciones de infraestructura de los servicios web se superan dotándoles de las descripciones semánticas. Aplicando esta idea han surgido nuevas iniciativas que combinan la tecnología semántica y los servicios web y que permiten modelar el universo del negocio electrónico. En este artículo, nos centraremos en tres de estas propuestas, basadas en el estándar XML, ebxml, RossetaNet y BizTalk, que intentan, más allá de la definición de un simple vocabulario, plasmar un marco de actuación e intercambio de información para el comercio y el negocio electrónico. En las siguientes secciones se destacarán los aspectos más importantes, ventajas e inconvenientes de cada una de estas propuestas. A continuación se expondrán las conclusiones y las líneas de trabajo que pueden surgir a partir de la elaboración de este trabajo. 2. ebxml Las transacciones entre empresas consisten en un complejo conjunto de interacciones entre vendedores, compradores y la información que existe sobre un producto o servicio. Cada empresa sigue un protocolo de actuación distinto para el intercambio de información que surge en este proceso, por eso, intentar modelar qué información se intercambia y cómo se estructura de una manera lo más genérica posible, es una tarea cuanto menos ardua. Técnicamente, especificar la información a intercambiar, su estructura y los procesos que controlan este intercambio significa generar una DTD (Document Type Definition) o un esquema XML (XML Schema). Una vez realizada esta labor han de resolverse cuestiones como, por ejemplo, definir qué tipos de protocolos se deben utilizar para transportar la información (HTTP, CORBA, SOAP,...), cómo se puede desarrollar un sistema seguro o cómo representar los procesos de negocio. En 1999 se inició el proyecto Electronic Business XML (ebxml) con el ambicioso objetivo de crear un mercado global electrónico único. Una iniciativa patrocinada por el United Nations Centre for Trading Facilitation en Electronic Business (UN/CEFACT, y la Organization for the Advancement of Structured Information Standards (OASIS, aportando el UN/CEFACT su experiencia sobre procesos de estandarización y OASIS el knowhow sobre XML. Según sus propios autores La visión de ebxml es la creación de un mercado electrónico global en el que puedan contactar empresas de cualquier tamaño y localización geográfica para llevar a cabo negocios mediante el intercambio de mensajes XML 1, 2.1. Transacciones sobre ebxml Supongamos que la empresa A decide introducirse en el comercio electrónico y para ello, va a utilizar la arquitectura ebxml 1

4 Fig. 2. Escenario en el cual la empresa A desea participar en un entorno evxml 1. El primer paso es consultar el registro (ebxml registry), que es el contenedor de modelos de procesos, vocabularios y perfiles reutilizables. En él, la empresa A, examinará las especificaciones y ejemplos de casos de uso. 2. La compañía A comprará el software necesario o adaptará sus sistemas existentes, añadiendo los módulos correspondientes para la exportación / importación de información conforme a ebxml. 3. Después enviará al registro la información relativa a su perfil de negocio, es decir, incorporará la descripción de las capacidades y restricciones que afectan a una empresa así como su ámbito de actuación. Como un tipo de descripción clave hay que destacar la publicación de los servicios que ofrece una empresa, en los términos de ebxml, el Collaboration Protocol Profile (CPP) en forma de esquemas XML o DTD. 4. La empresa B averigua a través del registro el perfil de la empresa A. 5. B identifica situaciones de negocio comunes con A, sabiendo que ambas son conformes a ebxml. 6. La compañía B se pone en contacto con A y se propone un acuerdo sobre los procesos de negocio, documentos, mensajes y tipo de seguridad a introducir en sus transacciones. Ambas llegan a un acuerdo, Collaboration Protocol Agreement (CPA). 7. Las dos empresa forman parte del comercio electrónico ebxml Para intercambiar información A y B utilizarán el ebxml Messaging Service como servicio que les resuelve la problemática de transporte de la información entre ellas. El tipo de mensajes que ambas empresas han de intercambiarse viene definido por el Collaboration Protocol Agreement (CPA) que 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. Condición para que esta negociación se pueda

5 realizar de forma efectiva, es la existencia del ebxml Registry, un repositorio en el cual se pueden depositar cualquier tipo de información ebxml para ser accesible a los posibles interesados. El registry contiene, por ejemplo, descripciones de documentos como una factura en forma de DTDs o esquemas XML. En el CPP se encuentra la descripción del perfil de actividad de una empresa y la especificación del proceso de venta. Contiene la información de qué mensajes intercambiar, su secuencia de intercambio y los formatos especificados con esquemas XML. Es importante hacer resaltar el hecho que no necesita especificar sus propias definiciones, sino que puede utilizar las existentes siempre que le valgan. De hecho, la reutilización de éstas es muy deseable con el fin de simplificar la participación y hacerla más asequible para empresas medianas y pequeñas que no pueden invertir en esfuerzos como los requeridos para la definición de estos documentos. Las empresas deben asegurarse de que sus CPP son compatibles, es decir, asegurar que entienden lo mismo por conceptos. En el caso más simple las dos CPP serán compatibles, si ambas empresas han decidido utilizar descripciones estándar en vez de definir las suyas propias. Este caso puede ser relativamente probable, si no será muy difícil que a priori haya una compatibilidad Arquitectura ebxml se compone de cinco especificaciones distintas, cada una de ellas desarrollada de manera independiente. Messaging. Este servicio de mensajería se responsabiliza del transportes, enrutado y empaquetamiento de los datos de negocio en un formato estándar, si bien ebxml no define ningún formato concreto. Los mensajes ebxml usan una versión mejorada de SOAP 2 que permite incluir ficheros adjuntos con contenido binario (usando empaquetado MIME). Este servicio también abarca las cuestiones relativas a la seguridad, los llamados Security Services, que incluyen la generación y verificación de firmas digitales, la autenticidad y autorización relativa a un mensaje, etc. Además existe soporte para garantizar la fiabilidad del intercambio de los mensajes y el tratamiento de errores. Business Processes. Definidos los documentos de negocio, podemos especificar los procesos que los manejan, es decir, capturar de manera sistemática el flujo de datos en el intercambio de información. Para ello, se utiliza la metodología UMM (UN/CEFACT Modeling Methodology) que a su vez se apoya UML 3 (Unified Modeling Language) como lenguaje de modelado y la plasma luego en XML. Así se refleja el conocimiento en un formato estándar, bajando hasta el nivel de detalle necesario y de manera independiente de la implementación técnica. Aquellos procesos de negocio muy comunes, correspondientes a empresas del mismo sector, pueden ser definidos por una organización (o consorcio), ayudando de esta manera a la interoperabilidad. <!DOCTYPE ProcessSpecification SYSTEM "ebxmlprocessspecificationv1.01.dtd"> <ProcessSpecification name="simple" version="1.1" uuid="[ ]">

6 <!-- Business Documents --> <BusinessDocument name="catalog Request"/> <BusinessDocument name="catalog"/> <BusinessDocument name="purchase Order"/> <BusinessDocument name="po Acknowledgement"/> <! > <Package name="ordering"> <!-- First the overall MultiParty Collaboration --> <MultiPartyCollaboration name="dropship"> <BusinessPartnerRole name="customer"> <Performs initiatingrole="requestor"/> <Performs initiatingrole="buyer"/> <Transition frombusinessstate="catalog Request" tobusinessstate="create Order"/> </BusinessPartnerRole> <BusinessPartnerRole name="retailer"> <Performs respondingrole="provider"/> <Performs respondingrole="seller"/> <Performs initiatingrole="creditor"/> <Performs initiatingrole="buyer"/> <Performs initiatingrole="payee"/> <Performs respondingrole="payor"/> <! > </MultiPartyCollaboration> <!-- Now the Binary Collaborations --> <BinaryCollaboration name="request Catalog"> <InitiatingRole name="requestor"/> <RespondingRole name="provider"/> <BusinessTransactionActivity name="catalog Request" businesstransaction="catalog Request" fromauthorizedrole="requestor" toauthorizedrole="provider"/> </BinaryCollaboration> <BinaryCollaboration name="firm Order" timetoperform="p2d"> <Documentation>timeToPerform = Period: 2 days from start of transaction</documentation> <InitiatingRole name="buyer"/> <RespondingRole name="seller"/> <BusinessTransactionActivity name="create Order" businesstransaction="create Order" fromauthorizedrole="buyer" toauthorizedrole="seller"/> </BinaryCollaboration> <! > <!-- Here are all the Business Transactions needed --> <BusinessTransaction name="catalog Request">

7 <RequestingBusinessActivity name=""> <DocumentEnvelope ispositiveresponse="true" businessdocument="catalog Request"/> </RequestingBusinessActivity> <RespondingBusinessActivity name=""> <DocumentEnvelope ispositiveresponse="true" businessdocument="catalog"/> </RespondingBusinessActivity></BusinessTransaction> <BusinessTransaction name="create Order"> <RequestingBusinessActivity name="" isnonrepudiationrequired="true" timetoacknowledgereceipt="p2d" timetoacknowledgeacceptance="p3d"> <DocumentEnvelope ispositiveresponse="true" businessdocument="purchase Order"/> Fig. 3. Ejemplo reducido de un documento de especificación de procesos. (Fuente: En el ejemplo se expone una parte de la especificación de proceso relacionada con respecto a un catálogo de productos y pedido. Al principio se referencian los documentos de negocio implicados, (Catalog Request, Catalog, Purchase Order,...). Lo siguiente es la descripción de los participantes del proceso, el cliente (Customer) asume aquí dos papeles: solicitando de información (Requestor) y como comprador (Buyer), otros participantes son el vendedor, el proveedor de los productos y un proveedor para un crédito. Las transacciones especificadas son la petición de catálogo y la creación del pedido, otras transacciones no mostradas en el extracto del código del ejemplo son la confirmación de envío de la mercancía, confirmación del pago, etc. Trading Partner Profiles and Agreements. Otra característica importante de ebxml es la representación, de manera sistemática, de las capacidades de una empresa para hacer los negocios electrónicamente; CPP (Collaboration Protocol Profile). Los CPPs proporcionan a las compañías un formato XML común para listar las industrias, los procesos de negocio, los mensajes, y las tecnologías de intercambio de datos que pueden usar. Las empresas, usando sus CPP, llegan a acuerdos que son reflejados en un CPA (Collaboration Protocol Agreement). Para reflejar cuestiones no técnicas o de tipo legal pueden usar un TPA (Trading Partner Agreement). Registries and Respositories. En los repositorios se almacenan los registros ebxml, que contienen los CPPs. Estas funciones son claves para las compañías que usan ebxml, y que pretenden expandirse a nuevos campos o que buscan nuevos compañeros de negocio.

8 Request Industry Domain Business Process Detail Constraints Response Details Content Action Status Transport Layer Access Syntax in XML Classification & Ownership ebxml conformant XML object Collections & Versioning Interface Information Model Remote ebxml Registry Registry Services Associated References Registration of Domain Registry Service Interface Registry Access Index XML Content Referencing Other Registry Service Interface(s): UDDI, CORBA Compatibility Wrappers Repository Content Fig. 4. Arquitectura de los registros Core Components. Permiten identificar de manera única los diferentes términos que utilizan las empresas para relacionarse. La unificación pretende abarcar tanto a empresas que pertenezcan a diferentes ámbitos como a las que estén, dentro del mismo ámbito, pero en un nivel distinto. Si algún tipo de documento no corresponde a las necesidades, pueden modificarse los tipos existentes o crear nuevos tipos válidos. Estos componentes básicos (Core Components) pueden tener diferente nivel de complejidad. Los más básicos son comparables con el concepto informático de tipo de datos, por ejemplo un componente nombre que debe ser una cadena de caracteres alfanuméricos, éste será a su vez componente de estructuras más complejas como una dirección o una cuenta bancaria. Los componentes disponen de información de contexto: dónde se engloban y con qué papel, de esta manera se pueden agregar para crear objetos de información de mayor complejidad. La idea es maximizar la reutilización de elementos predefinidos y llegar así a un compromiso óptimo entre las necesidades de personalización que requiere una relación comercial entre dos empresas y el esfuerzo requerido para definirla. Resulta más sencillo estandarizar tipos de documentos de mayor nivel si sus componentes básicos se encuentran estandarizados. 3. RossetaNet RosettaNet es una organización creada en 1998 para el desarrollo de estándares. Entre sus objetivos, se encuentra crear un lenguaje común para la gestión de procesos de comercio electrónico que han denominado RossetaNet. Al igual que ebxml, es un framework, una infraestructura de base que acelera la construcción de un sistema y aporta las normativas necesarias para garantizar la compatibilidad entre sus participantes. Una transacción electrónica plantea, a grandes rasgos, dos tipos de problemáticas: la relacionada con la información en sí, es decir, qué información contiene y de qué manera se estructura, y la problemática relacionada con el intercambio de esta información entre los sistemas que realizan las transacciones. RosettaNet se centra sobre

9 todo en la mecánica de intercambio de información, independiente de las diferencias de detalle entre las empresas concretas. Trata de generalizar sin tener en cuenta el detalle estructural de la información, el proceso de pedir una oferta, recibir una propuesta, aceptar la oferta y enviar un pedido, etc Arquitectura RossetaNet Este framework, consta fundamentalmente de los elementos siguientes: Business Dictionary, Technical Dictionary 4 : RosettaNet distingue entre un diccionario de negocio y un diccionario técnico, la diferencia está en el conjunto de términos abarcados; el primero contiene aquellos relacionados con las transacciones en sí (define, por ejemplo, el concepto de cuenta bancaria) y el segundo sirve para la descripción de los productos y servicios objeto de las transacciones. Sería el equivalente a los core components de ebxml. <?xml version="1.0" encoding="utf-8"?> <! RosettaNet Business Dictionary: BusinessDataEntities BusinessDataEntities.xml (31-Oct :12:43 PM) This document has been prepared by RosettaNet ( --> <!DOCTYPE RNBD SYSTEM "rnbd.dtd"> <RNBD> <BusinessDataEntities> <Name>AcceptanceAcknowledgement</Name> <Definition>Business information returned to a requesting party to acknowledge the business acceptance of a request.</definition> </BusinessDataEntities> <BusinessDataEntities> <Name>AcceptanceAcknowledgementException</Name> <Definition>Negative acknowledgement of acceptance due to business rule processing errors.</definition> </BusinessDataEntities> <BusinessDataEntities> <Name>AcceptanceAcknowledgment</Name> <Definition>Business information returned to a requesting party to acknowledge the business acceptance of a request.</definition> </BusinessDataEntities> <...> Fig. 5. Fragmento del diccionario de negocio de RossetaNet 4 y%5boid%5b6edb5fe87f69d411bd e33dd8%5d%5d

10 Partner Interface Processes (PIPs): define los procesos de negocio entre empresas. Se dividen en 8 cluster o grupos que representan los procesos de negocio. Cada cluster se divide en segmentos que son una descripción en detalle de los procesos identificados por los clusters. A su vez, los segmentos se subdividen en PIPs (Partner Interface Proceses) que describen las acciones entre socios comerciales a nivel de detalle. Los PIPs son diálogos especializados entre sistemas basados en XML. Cada PIP incluye un documento de negocio con su vocabulario y un proceso de negocio en el que se especifica la forma de intercambio de mensajes. Cluster 0: Aporta funcionalidades administrativas sobre las PIPs disponibles. Cluster 1 (Socios, Productos y Servicios): Se centra en el mantenimiento de los datos de los socios comerciales, sus servicios y un servicio de suscripción a la información de producto, de manera que una empresa se puede suscribir a información sobre los productos a los que la otra le autoriza Cluster 2 (Información de producto): Permite la distribución de información de productos incluyendo información de marketing, técnica, etc. En definitiva trasladar los catálogos de productos de un proveedor a un cliente. Además incluye todas las funcionalidades para mantener la información sincronizada ante cambios en los productos Cluster 3 (Gestión de pedidos): Este cluster se centra en la problemática relacionada con la gestión de pedidos, incluye la generación de un pedido o cesta de la compra, la configuración de los productos, los envíos y devoluciones, transporte, estado del pedido y los aspectos económicos de las transacciones. Cluster 4 (Gestión de almacenes): Las funcionalidades de este cluster se dividen entre funciones para la gestión del almacén en si como la reposición de mercancía y funciones de optimización en las cuales los compradores aportan datos como previsiones de compras que ayudan a optimizar la gestión del stock. Cluster 5 (Información de Marketing): Aquí se gestiona la información relevante para el marketing como ofertas especiales, información de ventas, etc. Cluster 6 (Servicio y soporte): En esta categoría entra la descripción de los servicios posventa como los servicios relacionados con la garantía, soporte técnico o contratación de determinados servicios Cluster 7 (Fabricación): Este cluster pretende recoger los procesos que permiten crear un entorno de producción virtual en el cual se pueden intercambiar diseños, configuraciones, información de requisitos de calidad, etc. El estándar también se preocupa de estados de error como mensajes perdidos, excepciones, etc. Incluso entran casuísticas relativamente refinadas como la desviación de un comprador a otro vendedor si el primero no es capaz de suministrar la cantidad de mercancía solicitada. RossetaNet Implementation Framework (RNIF): es la especificación de transporte, enrutado y empaquetamiento de mensaje de los mensajes PIP. Equivale al servicio de mensajería de ebxml.

11 Fig. 6. Elementos del framework RossetaNet. RosettaNet organiza los procesos de negocio en ocho grandes grupos (Clusters) que subdivide a su vez en unidades (Segmentos) con sus respectivas PIPs. El Implementation Framework (RNIF) da soporte a los PIPs con servicios como el empaquetado y agrupamiento de mensajes de mensajes, encaminamiento, etc Transacciones con RossetaNet. A modo de ejemplo, veamos como se produciría la gestión de pedidos con RossetaNet. Nos centramos en el Cluster 3. El proceso es el siguiente: el comprador envía un mensaje al vendedor indicando la cantidad del producto a adquirir, el vendedor tiene que confirmar la recepción del mensaje. El (los) producto(s) a comprar se define(n) según la información del Cluster 1, las condiciones marco para la transacción han sido negociadas previamente. Esto incluye, por ejemplo, que tanto vendedor como comprador se hayan identificado en el sistema y haya un contrato entre ambos. El comprador debe estar, además, autorizado a la compra del producto. El cluster 3 se divide en los siguientes segmentos: Segmento 3A (Ofertas y pedidos): Permite a los interlocutores intercambiar información de disponibilidad, ofertas, pedidos, estado de pedidos y permite enviar pedidos y cestas de la compra a otros participantes. Segmento 3B (Transporte y distribución): Maneja la información relacionada con el envío y la entrega de la mercancía con posibilidades de realizar modificaciones y tratar excepciones y reclamaciones. Segmento 3C (Devoluciones y finanzas): Todo lo relacionado con la devolución de productos y temas económicos: facturación, créditos, etc. Segmento 3D (Configuración de productos): Apoya la configuración de productos en la gestión de pedidos. Si desglosamos el segmento 3A encontramos, PIP 3A1 (Petición de oferta): describe el intercambio de mensajes para hacer una petición de oferta a un proveedor. La oferta petición tiene básicamente la estructura de un pedido, es decir, varios productos y sus cantidades. Además se puede incluir la configuración de productos o precios previamente negociados. PIP 3A2 (Petición de precios y disponibilidad): describe el intercambio de mensajes para la petición de precios y disponibilidad de los productos. PIP 3A3 (Petición de transferencia de cesta de la compra): describe el intercambio de mensajes para transferir el contenido de una cesta de la compra y confirmar su recepción. PIP 3A4 (Pedidos): describe los mensajes implicados para emitir pedidos, confirmarlos, cancelarlos y modificarlos.

12 PIP 3A5 (Consultar estado de pedido): Aparte de permitir la consulta del estado de pedido emitidos, este PIP también permite su cancelación y modificación. PIP 3A6 (Distribuir estados de pedido): Establece un proceso mediante el cual los vendedores pueden distribuir de forma periódica los estados de sus pedidos pendientes... Una vez creados los mensajes que se define en cada segmento, RNIF da soporte a los PIPs encargándose de empaquetar, encriptar, encaminar y transmitir dichos mensajes. 4. BizTalk BizTalk es en realidad una propuesta de Microsoft para la automatización de B2B y procesos de negocios. Es un marco de trabajo basado en XML y otros estándares de Internet que especifica los procedimientos de intercambio y procesamiento de documentos empresariales estandarizados a través del Web. BizTalk proporciona los recursos siguientes: BizTalk Framework: describe el formato de los mensajes que circulan entre las empresas y la manera de procesarlos. Usa XML para proporcionar un lenguaje común que permita intercambiar la información empresarial. BizTalk.org 5 :es una iniciativa del sector iniciada por Microsoft que constituye la estructura de los usuarios de BizTalk y que crea, mantiene y promociona BizTalk Framework, además de proporcionar una biblioteca de esquemas de documentos Biz- Talk para los documentos empresariales estándar, una comunidad de grupos de noticias y una red de recursos dedicada a promocionar BizTalk como una solución empresarial. Microsoft BizTalk Server: en diferentes versiones, es un servidor de mensajería para procesar mensajes BizTalk e interactuar con sistemas empresariales internos. Proporciona utilidades de envío y recepción de mensajes BizTalk, asignación de los datos incluidos en los mensajes BizTalk a formatos internos, intercambio de datos entre sistemas internos y administración de las transacciones de una manera segura y confiable Transacciones con BizTalk El modelo BizTalk tiene tres niveles: el nivel de aplicaciones, el de servidores BFC (BizTalk Framework Compliant) y el de transporte. Las aplicaciones se comunican entre sí enviando documentos empresariales mediante los servidores compatibles con BizTalk Framework o BFC. Los servidores se envían mensajes BizTalk entre sí a través de varios protocolos de transporte, como HTTP, SMTP, FTP, Microsoft Message Queue (MSMQ) y DCOM. 5

13 Fig. 7. Modelo BizTalk Los servidores BFC intercambian los mensajes BizTalk, éstos contienen documentos BizTalk y éstos, a su vez, contienen documentos empresariales. Un documento empresarial, en términos de BizTalk, es cualquier documento XML bien formado que contiene información del proceso de negocio. Es posible agrupar uno o más documentos empresariales para crear un documento BizTalk. Los documentos BizTalk, también incluyen información que describe qué documentos se incluyen, dónde se envían y cómo se van a procesar. Se puede combinar con cualquier adjunto necesario en una estructura MIME para enviarlo como un mensaje BizTalk. A continuación, los mensajes BizTalk se envían mediante HTTP, SMTP, MSMQ o cualquier otro protocolo de transporte a través de Internet (o, en realidad, a través de cualquier red interna) Framework permite a las aplicaciones enviar documentos empresariales o documentos BizTalk a un servidor BFC; los servidores BFC tienen que ser capaces de encapsular un documento empresarial en un documento si es necesario. El servidor BFC empaqueta a continuación el documento en un mensaje BizTalk y lo envía al servidor BFC de destino para su procesamiento. En el destino, el mensaje se confirma y procesa en el momento en que el servidor BFC de destino interactúa con cualquier otro sistema que necesite y, si es necesario, devuelve otro mensaje al servidor BFC original Arquitectura Técnica de BizTalk Server Para permitir a los usuarios crear procesos de negocio, BizTalk ofrece un modo de especificar e implementar la lógica del proceso y un mecanismo de comunicación entre aplicaciones. Proporciona herramientas de modelo empresarial y administrativas que le permiten modelar transacciones empresariales, crear modelos para los documentos empresariales y definir traducciones de datos que muevan datos empresariales dentro y fuera de las aplicaciones de línea de negocio.

14 Orchestrations Business Rules Engine Inbound <XML Message> Outbound Receive Adapter Receive Pipeline <XML Message> Send Pipeline Send Adapter <XML Message> Incoming Message Subscriptions MessageBox <XML Message> Outgoing Message Message Path Fig. 8. Componentes de BizkTalk Server Dentro de BizTalk se incluyen los siguientes componentes Diseñador de aplicaciones BizTalk: Proporciona las herramientas de análisis empresarial con las que modelar los procesos de una transacción mediante diagramas de flujo sencillos. El desarrollador puede usar esta herramienta para modelar los servicios de aplicaciones necesarios para ejecutar los pasos de un proceso empresarial y enlazar dichos servicios con los pasos correspondientes. Una vez modelado el proceso y enlazados a éste los servicios de aplicación, esta herramienta compila el dibujo en una programación XLANG (una descripción basada en XML del proceso que se puede ejecutar con el motor del programador XLANG). El motor del programador controla la programación y ejecución de las programaciones XLANG, en las que los documentos BizTalk se intercambian, traducen y procesan. Editor BizTalk y Asignador BizTalk: Se encargan de dar formato y traducir los datos. El Editor permite especificar el formato de un documento empresarial, basado en el esquema XML existente o en un diseño. El Asignador permite crear una asignación de la traducción de datos que correlacione los registros y campos de un documento empresarial con los registros y campos de otro, de manera que se puedan transferir de uno a otro. Ambos se basan en la tecnología del esquema XML y están optimizados para BizTalk Framework y SOAP, pero adoptan diversos formatos de datos incluidos ANSI X12, EDIFACT, archivos sin formato, DTD y esquemas de datos XML. Administración de servidores BizTalk: se trata de un complemento de Microsoft Management Console (MMC) que permite administrar servidores BizTalk y grupos de servidores. Escritorio de administración BizTalk: Permite administrar, crear y configurar el intercambio de elementos que constituyen un proceso de intercambio de datos empresariales. Canales: Definen las reglas para procesar un documento empresarial determinado. Las propiedades de los canales incluyen el origen del documento, su destino, el tipo de documento procesado, la asignación utilizada (si se requiere traducción del esquema), el formato de salida, la configuración de seguridad y otros aspectos. Puertos: Definen un destino para un documento empresarial una vez que éste ha sido procesado por un canal. Un destino puede ser la organización con la que tiene la relación empresarial o una aplicación interna. Puede crear varios canales para un solo puerto de mensajería.

15 Organizaciones: se refieren tanto a su empresa como a aquellas con las que intercambia datos empresariales: sus socios comerciales. Definiciones de documentos: describen el tipo de documentos que trata un determinado canal mediante una referencia a la especificación de un documento. La especificación del documento describe su estructura, tipo y versión. Sobres: encapsulan los datos empresariales para su transporte; proporcionan la información que necesita BizTalk para iniciar un intercambio de documento, ya sea interno o externo. Listas de distribución: enumeran un conjunto de puertos a los que se enviará un documento dado mediante procesamiento. Cada puerto representa a una organización diferente. Seguimiento de documentos BizTalk: Permite realizar un seguimiento de los documentos empresariales por las diferentes etapas del proceso definido en las programaciones XLANG y al pasar a BizTalk Server. SDK de BizTalk Server: El Kit de desarrollo de software proporciona a los desarrolladores acceso mediante programación a los componentes y servicios de BizTalk, lo que le permite desarrollar soluciones personalizadas. 5. Conclusiones ebxml, RossetaNet o BizTalk son sólo tres soluciones posibles para el comercio electrónico, pero no hay que perder de vista que existen muchas más. La relativa facilidad con la que se cuenta para desarrollar nuevas plataformas o sublenguajes XML, ha hecho que proliferen. La empresa debe buscar una solución que integre la cadena de suministro con clientes o proveedores y que además se integre con las herramientas de las que disponga (ERP, CRM, SCM, etc.). El objetivo fundamental debería ser que las empresa tendieran a una integración tecnológica que permita extraer el mayor partido a las comunicaciones automatizadas, no únicamente vender por Internet. Este objetivo es que hace rentable el tiempo y el dinero invertido en integrar un estándar o herramienta del tipo de las que se han descrito en el artículo. Es difícil calibrar en este momento cual será a medio o largo plazo el posicionamiento de cada uno de estos estándares, todas las propuestas resultan, en líneas generales, muy parecidas, todas ellas definen, básicamente, un vocabulario para el intercambio de mensajes entre empresas basado en XML, el formato de dichos mensajes, basado en el mismo estándar y la forma de transporte en condiciones seguras. En las búsquedas de información, se observa que ebxml se perfila como la propuesta más madura, no obstante, empiezan a ser compatibles entre ellos, por ejemplo, la última versión de BizTalk es compatible con ebxml. Por otra parte, el mercado del software ya ofrece productos llave en mano que reducen el coste y el tiempo de implantación aunque con peligro de incompatibilidades. Rozando este punto se encuentra BizTalk, el estándar de Microsoft que sólo es compatible con los productos de dicha compañía Otro punto crítico de estos estándares es el objetivo de hacer que el comercio o negocio electrónico sea asequible para pequeñas y medianas empresas, un objetivo difícil a pesar de que el problema de los costes de comunicaciones tiende a desaparecer. La empresa debe hacer el esfuerzo de realizar un trabajo a medida para su caso, con el

16 coste adicional y esfuerzo humano y temporal que supone. Los estándares analizados ofrecen versiones o soluciones para este tipo de empresas, pero ninguna parece lo suficientemente efectiva y razonablemente económica como para que las PYMES adopten este tipo de soluciones. Teniendo en cuenta que el tejido empresarial español está compuesto en un 99% por empresas de este tamaño, queda un gran escollo que los fabricantes de software y estándares deben intentar resolver si desean que el índice de penetración de las empresas en el comercio o, mejor aún, en el negocio electrónico aumente. Respecto a las líneas de trabajo que lleva asociada la web semántica y la integración de los servicios web para el comercio electrónico, podemos decir que, poco a poco, van surgiendo lenguajes con mayor poder semántico como DAML o OWL sobre los que empiezan a describirse ontologías para la integración de comercio electrónico que pueden utilizarse para el desarrollo de nuevos servicios. Cuando estos lenguajes estén más maduros, es de prever que surjan nuevos estándares que faciliten la tarea semántica de integración entre empresas y aplicaciones. Por otro lado, es conveniente seguir trabajando en la seguridad en el transporte de información y en las soluciones abiertas, de fácil uso y que puedan suponer una implantación más asequible para las PYMES, que es el mayor inconveniente de los estándares hasta ahora estudiados. 6. Referencias [ebxml, 2006] Sitio oficial [RossetaNet, 2006] Sitio oficial [BizTalk, 2006] Sitio oficial BURAGA, S., CIOCA, M. Semantic Web-based E-business Applications". [2005] LABEIN. BEDI e-business Negocio Electrónico en el ámbito de laspymes Internacionalizadas de Bizkaia. [17 Junio 2004] PAOLUCCI, M., SYCARA, K., NISHIMURA, T., SRINIVASAN, N. Towards a Semantic Web e-commerce. [2003] EBERHART, A. Semantic Web meets e-commerce Alemania, [2002] AEAC (Asociación española de comercio electrónico) ebxml. Una visión general. [Febrero 2002] AEAC (Asociación española de comercio electrónico) RossetaNet. Una visión general. [Febrero 2002] LOZANO TELLO, A. Ontologías en la web semántica, I Jornadas de Ingeniería Web [2001] IRANI, R. An Introduction to ebxmlcollaborative Electronic Business is here to stay Tutorial, [2001] FLETT, A., BROWN, M., Enterprise-standard ontology environments for intelligent e-business Asuman DOGAC, Exploiting Semantic of Web Services through ebxml Registries. D. FENSEL, C. BUSSLER, Y. DING, V. KARTSEVA, M. KLEIN, M. KOROTKIY, B. OMELAYENKO, AND R. SIEBES. Semantic Web application areas