O9ebxml

ebXML ARQUITECTURA TÉCNICA e-logistics Curso 2009 Eduard Rodés

ÍNDICE OBJETIVOS DEL DISEÑO DE LA ARQUITECTURA VISIÓN GENERAL DEL ebXML METODOLOGÍA DE MODELADO FASES FUNCIONALES DEL ebXML LA INFRAESTRUCTURA ebXML CONFORMIDAD CON ebXML

OBJETIVOS DEL DISEÑO DE LA ARQUITECTURA Tras 25 años de existencia el EDI sólo ha logrado integrarse en la operativa de las grandes empresas en las que los “grandes jugadores” han impuesto sus reglas (automoción, distribución,..) En los últimos años el XML (lenguaje de marca) ha tomado protagonismo en el intercambio de datos en la red por ser más abierto y flexible. El reto para diseñar mensajes que se adapten a los procesos de negocio y la estandarización de este lenguaje son independientes de la sintaxis en la que los mensajes están codificados.

OBJETIVOS DEL DISEÑO La especificación ebXML proporciona un marco en el que las inversiones básicas en los procesos de negocio definidos en EDI pueden aprovecharse en una arquitectura que aprovecha las nuevas capacidades técnicas del XML

VISIÓN GENERAL DEL ebXML La arquitectura pretende proporcionar: Un mecanismo estándar para describir procesos de negocio y sus modelos de información asociados. Un mecanismo para registrar y guardar Procesos de Negocio y MetaModelos de información que permitan ser compartidos y reutilizados. Obtener información de cada participante incluyendo: Los modelos de negocio que soporta Los Interfaces de servicio de negocio que ofrecen como soporte a los procesos de negocio Los mensajes de negocio que se intercambian entre los respectivos interfaces de servicio de negocio La configuración técnica del transporte soportado, seguridad y protocolos de cifrado

VISIÓN GENERAL DEL ebXML Un mecanismo para registrar esta información para que pueda ser encontrada y reutilizada. Un mecanismo para describir la ejecución de un acuerdo mutuo sobre la forma de realizar un negocio, que puede obtenerse de la información proporcionada por cada participante en el punto 3 (Acuerdo de Protocolo de colaboración -CPA) Un marco de servicio estándar de Mensajes que permita la interoperabilidad segura y fiable de los intercambios de mensajes entre “Trading Partners” Un mecanismo para la configuración del servicio de mensajes que vincule los procesos de negocio acordados, conforme a las restricciones definidas en los acuerdos de negocio.

METODOLOGÍA DE MODELADO Visión general La mayoría de de las empresas utilizan sistemas muy diferentes, pero muchas actividades pueden descomponerse en procesos de negocio (BP) que son más genéricos a un tipo específico de negocio. Para realizar el análisis se utiliza la metodología UMM (UN/CEFACT Modeling Methodology) basada en UML ( Unified Modeling Language ). UMM utiliza dos puntos de vista para describir los aspectos relevantes de una transacción de negocio: BOV (Business Operational View): Visión desde la prespectiva operacional. FSV (Funtional Service View): Visión desde la prespectiva funcional.

METODOLOGÍA DE MODELADO BOV Se dirige a La semántica de los datos de negocio en las transacciones y a las informaciones asociadas a los intercambios. La arquitectura para las transacciones de negocio, que incluyen: Los acuerdos operacionales Acuerdos y especificaciones obligaciones mutuas y requerimientos Para obtener este resultado se utilizan herramientas que permiten obtener el Conocimiento para la Colaboración en el Negocio (Business Collaboration Knowledge) y que se encuentran en la “Core Library” y en la “Business Library”

METODOLOGÍA DE MODELADO Core Library Contiene datos y definición de procesos, incluyendo relaciones y referencias cruzadas, que pueden estar vinculadas a un esquema de clasificación de la industria. Es el puente entre el lenguaje específico del negocio o de la industria y el conocimiento expresado por los modelos en un contexto más general y un lenguaje más natural. Business Library Contiene modelos de actividades y secuencias que describen procesos de negocio. Se utilizará como referencia en el proceso de análisis y creación de las estructuras operativas.

METODOLOGÍA DE MODELADO El conocimiento para la colaboración de Negocio se obtiene de la Core Library. En la primera fase se definen las estructuras de negocio que describen el problema utilizando diagramas de situación (Use Case Diagrams) y Descripciones. Primero se verifica si existen entradas útiles en un Registro compatible ebXML. Si no se encuentran se creará una nueva entrada y se incorporará a un Registro compatible ebXML. En la segunda fase (análisis) se crearán los esquemas de actividades y diagramas de secuencias que describan los procesos de negocio. Los diagramas de Clases incorporarán los paquetes de información asociados (documentos de negocio).

METODOLOGÍA DE MODELADO La última fase para la estandarización es la de diseño, que se puede lograr aplicando principios de orientación a objetos basados en UMM. En ebXML la interoperabilidad se logra aplicando Objetos de Información de Negocio a lo largo de todos los modelos de clases. Los Procesos de Negocio se crean aplicando UMM que utiliza un conjunto común de Objetos de Información de Negocio y Core Components.

METODOLOGÍA DE MODELADO El Servicio de Registro se utiliza para almacenar Procesos de Negocio y Modelos de Información, que son la representación basada en XML de estos modelos, Core Components y Perfiles de Protocolos de Colaboración. Se deben guardar en una forma que permita su localización hasta el nivel de los datos elementales utilizando una metodología consistente.

FASES FUNCIONALES Fase de Implementación En esta fase se analizan los procedimientos para aplicar la infraestructura de ebXML. El operador que quiera involucrarse en una transacción ebXML deberá primero obtener copias de las especificaciones ebXML. Las estudiará y obtendrá a continuación la “Core Library” y la “Business Library”. También podrá interesarle obtener otros Procesos de Negocio del interlocutor almacenados en su Perfil de Negocio para su análisis y revisión. Alternativamente el operador podrá implementar ebXML utilizando aplicaciones de terceros o podrá someter sus propios Procesos de Negocio a un Servicio de Registro.

FASES FUNCIONALES Fase de Implementación Diseño y proceso de registro Implementación y registro de perfil Opcionalmente negociar acuerdos Realizar negocios bajo ebXML Proceso de negocio y modelo de información Registro/ Repositorio Perfil del interlocutor A Perfil del interlocutor B Acuerdo de intercambio Documentos de negocio Industria

FASES FUNCIONALES Fase de localización y reutilización Cubre todos los aspectos de localización de los recursos ebXML relacionados. El operador que tenga implementado una Interface de Servicio de Negocio puede iniciar el proceso de localización y reutilización. Una posibilidad para localizar recursos es solicitar el Perfil del Protocolo de Colaboración (CPP) de otro operador. En esta fase los operadores deberán entender el significado de la información de negocio que requiera otro operador.

FASES FUNCIONALES Fase de puesta en marcha Cubre la ejecución de un escenario con las transacciones ebXML asociadas En esta fase se intercambian mensajes entre los operadores utilizando el Servicio de Mensajes ebXML

INFRAESTRUCTURA ebXML Información del operador (CPP y CPA) Para poder realizar transacciones los operadores deben poder publicar los Procesos de Negocio que soportan y la tecnología que utilizan, de forma que se pueda conocer su capacidad para intercambiar información. Esto se logra mediante el “Collaboration Protocol Profile” (CPP) y un acuerdo especial de negocio denominado “Collaboration Protocol Agreement” (CPA). CPP Describe las capacidades específicas que un operador soporta y sus requerimientos de interface que se deben cumplir para poder realizar intercambios con otro operador. Suelen ser informaciones del tipo: información de contacto, clasificación industrial, procesos de negocio soportados, requerimientos../..

INFRAESTRUCTURA ebXML ../..del servicio de mensajes, etc. También puede incluir aspectos de seguridad y detalles de implementación. Todos los operadores deberán incluir su CPP en un Registro de Servicio compatible ebXML y facilitar mecanismos de localización. Las definiciones del CPP no deben ser ambiguas, pero pueden incluir diferentes opciones (ej. HTTP o SMTP para el transporte). CPA Recoge los acuerdos de los operadores concretos respecto a el cómo se interseccionan sus CPP para realizar las transacciones. Describe: (1) el Servicio de Mensajes y (2) los requerimientos de los procesos de Negocio acordados por dos o más interlocutores, pudiéndose ../..

INFRAESTRUCTURA ebXML ../.. Indicar los que se pueden soportar en forma genérica, indicando los que en el momentos se desean soportar.

INFRAESTRUCTURA ebXML La Colaboración de Negocio es el soporte que se solicitarán los operadores que quieran establecer relaciones. Se facilitará mediante la publicación y publicitando en directorios o Registros de ebXML. La especificación de las CPA-CPP incluyen un anexo no normativo para la concreción de la composición de la CPA y los procesos de negociación.

INFRAESTRUCTURA ebXML Interface del CPP en los Procesos de Negocio Un CPP debe referencia uno o mas Procesos de Negocio soportados por un operador que tenga un CPP definido. Debe referenciar los diferentes roles que interlocutor puede asumir en un Proceso de Negocio (por ejemplo vendedor y comprador en un proceso de compra-venta). El CPP debe poderse guardar y recuperar de un Registro ebXML. El CPP puede también describir detalles vinculantes utilizados para construir las cabeceras de mensajes ebXML.

INFRAESTRUCTURA ebXML Interface del CPA El CPA regula el Interfase utilizado por un operador para ceñir el Interfase de Servicio de Negocio a un conjunto de parámetros acordados por todos los interlocutores que ejecuten el acuerdo. El CPA tiene interfaces con los CPP en los que se concretan las capacidades de los CPP respecto a lo que los interlocutores harán (CPA) El CPA debe referenciarse a procesos de negocio específicos y a los requerimientos de interacción necesarios para ejecutar estos Procesos de Negocio. El CPA puede guardarse en un Registro y debería poderse recuperar

INFRAESTRUCTURA ebXML Modelado de procesos de negocio Los Procesos de Negocio y los Metamodelos de Información conforman un mecanismo que permite a los interlocutores definir los elementos necesarios para realizar transacciones en un entorno de negocio específico, utilizando una metodología consistente. Un proceso de negocio describe de forma detallada como los interlocutores asumen diferentes funciones, relaciones y responsabilidades para facilitar la interacción con otros interlocutores con los que tengan que colaborar. La interacción entre las diferentes funciones de cada interlocutor se realiza mediante la representación de un conjunto de transacciones de negocio. Cada transacción de negocio se expresa como un intercambio electrónico de documentos.

INFRAESTRUCTURA ebXML Estos documentos pueden estar compuestos por Objetos de Información de Negocio reutilizables. A un nivel inferior estos Procesos de Negocio pueden estar compuestos por Core Processes reutilizables. Los Objetos de Información de Negocio pueden también estar compuestos por Core Components reutilizables. Los Procesos de Negocio y los Metamodelos de Información en ebXML soportan puntos de vista sobre los requerimientos, análisis y diseño que proporcionen un conjunto de elementos semánticos (vocabulario) para cada punto de vista y que forman la base de la especificación de las estructuras necesarias que se requieran para facilitar los Procesos de Negocio y la integración de la información y la interoperabilidad.

INFRAESTRUCTURA ebXML Hay una visión adicional del Metamodelo que es el Specification Schema, que soporta la especificación directa del conjunto de elementos requeridos para configurar un sistema ejecutable de un conjunto de transacciones ebXML. El SS forma un subset semántico y está disponible en formato UML y como DTD.

INFRAESTRUCTURA ebXML Una especificación completa de un Proceso de Negocio consiste en un Proceso de Negocio y un Metamodelo de Información especificado en relación a un SS y en una identificación de los modelos deseados. Esta información servirá como imput inicial para la elaboración del CPP y el CPA.

Funcionalidad Formal La funcionalidad de un proceso de negocio debe poder ser entendida tanto por personas como por las aplicaciones. Deben poderse guardar y recuperar en un Registro compatible ebXML. Se deben poder expresar en sintaxis XML para que las aplicaciones las puedan interpretar. Interfaces CPP y CPA: El CPP de un interlocutor define su capacidad funcional y técnica para soportar uno o varios procesos de negocio y uno o varios roles en cada proceso. La CPA define las condiciones bajo las cuales dos interlocutores realizaran transacciones. INFRAESTRUCTURA ebXML

La interface entre el Proceso de Negocio, su Metamodelo de Información y el CPA es la parte del documento del proceso de negocio que puede ser expresado como un documento XML. Core Components: el proceso de negocio debe referenciar los CC directa o indirectamente utilizando documentos XML que estén referenciados a los modelos de información y negocios adecuados y/o a los documentos de negocio (posiblemente DTDs o Esquemas) Mensajería ebXML: un proceso de negocio debe ser capaz de ser transportado de un servicio de Registro a otro por medio de un mensaje ebXML. Y también debe ser capaz de ser transportado desde un Registro a una aplicación de usuario mediante un mensaje ebXML. INFRAESTRUCTURA ebXML

Sistema de Registro: un proceso de negocio que deba utilizarse en una infraestructura ebXML debe ser recuperable a través de una consulta a un Registro, y por lo tanto cada Proceso de Negocio debe contener un identificador único. Detalles de implementación no normativos La composición exacta de los Objetos de Información de Negocio o de los Documentos de Negocio se guía por un conjunto de elementos de contexto que se derivan del Proceso de Negocio INFRAESTRUCTURA ebXML

Los procesos de Negocio y los Metamodelos de Información pueden generarse según la recomendación UMM o en cualquier otra forma siempre que cumplan con ebXML. Funcionalidad de los Core Components y de la Core Library Los Core Components recogen la información sobre conceptos de negocio del mundo real y de las relaciones que se establecen alrededor de este concepto, otros Objetos de Información de Negocio y una descripción contextual que describe como un Core o una Entidad de Información Agregada puede usarse en un escenario particular de eBusiness con ebXML. INFRAESTRUCTURA ebXML

Un componente Core puede ser un elemento individual de información de negocio o una familia agregada de Objetos de Información de negocio que se agrupan de forma conjunta en una Entidad de Información Agregada. Funcionalidad Formal: los componentes Core deben facilitar, como mínimo, las siguientes funcionalidades: Deben poder ser guardados y recuperados utilizando mecanismos de Registro ebXML. Deben contener y mantener un conjunto mínimo de información que satisfaga las necesidades del eBusiness. Se tienen que poder expresar en sintaxis XML INFRAESTRUCTURA ebXML

Tienen que ser capaces de contener: Otro Componente Core en combinación con uno o más elementos de Objetos de Información de negocios. Otro Componente Core en combinación con cero o más elementos de Objetos de Información de negocios. Un Componente Core tiene que poderse identificar de forma unívoca. Interfaces Un componente Core debe poder ser referenciado directa o indirectamente desde una instancia de un Documento de Negocio. El Proceso de Negocio puede especificar uno o varios Componentes Core según se requiera o información opcional como parte de una instancia de un Documento de Negocio. INFRAESTRUCTURA ebXML

Un CC debe interfasear con un mecanismo de Registro que permita guardarlo y recuperarlo. Un CC puede interfasear con un elemento XML desde otro vocabulario XML por el hecho de que sea referenciado bilateral o unilateralmente como una equivalencia semántica. Detalles de implementación no normativos Un CC puede contener atributos o ser parte de otro CC siempre y cuando se especifique el contexto preciso o la combinación de contextos en los que se usa. El proceso de agregación de CC para un contexto de negocio específico debe incluir medios para identificar la colocación de un CC en otro CC. También puede ser una combinación de contextos estructurales que faciliten la reutilización de CC o Entidades de ../.. INFRAESTRUCTURA ebXML

Información Agregada. Este se denomina como Contexto de negocio INFRAESTRUCTURA ebXML

El contexto puede también ser definido utilizando Procesos de Negocio y Metamodelos de Información, que definen las instancias de los Objetos de Información de Negocio en los que ocurren los CC. Los elementos de Objetos de Información de Negocio o los CC dentro de un CC genérico pueden ser obligatorios u opcionales. Un CC en un contexto específico o en una combinación de contextos puede alterar la cardinalidad Obligatorio/opcional. Funcionalidad del Registro El Registro debe permitir guardar elementos en syntaxis que utilicen conjuntos de caracteres multi-byte. Cada elemento del Registro, en todos los niveles de granularidad en que los defina la Entidad que le somete, tiene que ser identificable de forma univoca. INFRAESTRUCTURA ebXML

El Registro debe devolver cero o un encuentro como respuesta de una consulta de un identificador único. Si hubiera más de una respuesta debería dar un mensaje de error a la Autoridad de Registro. Un Elemento de Registro debe estructurarse de forma que suministre información asociada que lo identifique, su nombre, su descripción, su estatus administrativo y de acceso, su persistencia u mutabilidad, su clasificación conforme a los esquemas de clasificación predefinidos, declarar su tipo de fichero e identificar la organización que lo ha incorporado y la organización responsable.. La Interface del Registro sirve como aplicación para acceder al Registro. Deben existir de forma integrada interfases humanas (como un browser). INFRAESTRUCTURA ebXML

La Interface del Registro debe ser independiente del protocolo de Red que se utilice. Los procesos soportados por el Registro pueden incluir: Un CPA especial entre el Registro y sus clientes Un conjunto de funcionalidades relativas al Registro Un conjunto de Mensajes de Negocio a intercambiar con los clientes como parte de un Proceso de Negocio específico. Unos interfaces para soportar los mensajes y los mecanismos de consulta y respuesta. Un CPA especial para regular las interacciones entre registros ebXML compatibles. Un conjunto de procesos para interacciones entre Registros INFRAESTRUCTURA ebXML

Un conjunto de mensajes de error y condiciones con acciones correctoras. Para facilitar el proceso de localización podrán utilizarse herramientas de selección para construir las consultas. Los servicios de Registro existen para crear, modificar y borrar elementos de registro y sus metadatos. Se pueden utilizar protocolos de seguridad para ofrecer la autentificación y protección del repositorio cuando sea accedido por el Registro. A todos los items del Registro se les deben asignar UIDs (Unique Identifiers). Estas claves UID son requisito para todos los contenidos ebXML INFRAESTRUCTURA ebXML

O9ebxml

Más contenido relacionado

Similar a O9ebxml (20)

Más de Ergoclicks (13)

Último (20)

O9ebxml