Your SlideShare is downloading. ×
O9ebxml
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

O9ebxml

336

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
336
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ebXML ARQUITECTURA TÉCNICA e-logistics Curso 2009 Eduard Rodés
  • 2. Í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
  • 3. 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.
  • 4. 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
  • 5. 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
  • 6. 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.
  • 7.  
  • 8. 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.
  • 9. 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”
  • 10. 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.
  • 11.  
  • 12. 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).
  • 13. 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.
  • 14. METODOLOGÍA DE MODELADO
    • FSV
  • 15.  
  • 16. 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.
  • 17. 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.
  • 18. 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
  • 19.  
  • 20. 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.
  • 21.  
  • 22. 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
  • 23. 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../..
  • 24. 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 ../..
  • 25. INFRAESTRUCTURA ebXML
      • ../.. Indicar los que se pueden soportar en forma genérica, indicando los que en el momentos se desean soportar.
  • 26. 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.
  • 27. 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.
  • 28. 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
  • 29. 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.
  • 30. 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.
  • 31. 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.
  • 32. 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.
  • 33.  
  • 34.
      • 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
  • 35.
      • 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
  • 36.
      • 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
  • 37.  
  • 38.
      • 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
  • 39.
      • 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
  • 40.
        • 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
  • 41.
      • 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
  • 42.
      • Información Agregada. Este se denomina como Contexto de negocio
    INFRAESTRUCTURA ebXML
  • 43.
      • 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
  • 44.
      • 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
  • 45.
      • 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
  • 46.
        • 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

×