EbXML TM Technical Architecture Overview

(c)2000 ebXML TM - Editor: Duane Nickull ([email protected])

EbXML TM Technical Architecture Overview

www.ebxml.orgEditor: Duane Nickull

Constributors: All ebXML Committees, participantsV 0.3


Part One

What is ebXML?


ebXML™

“Creating a Single Global

Electronic Market™”

A United Nations – CEFACT / Oasis sponsored initiative


ebXML Mission . . .

To provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties.


ebXML Architecture

Providing a view for integration of business processes among ad-hoc or established independent business partners by electronic means.

Reducing the need for collaborative business partners to have individual and expensive prior agreement on how to integrate business processes.

Providing a high-level business-centric view of distributed e-business processes.

Supporting and representing business processes independent of the technical solution.

Providing and supporting a library of common, standard intra-business processes

Allowing for both business processes and enabling technologies to evolve independently while retaining long-term investments in both.

Integrating with new and legacy systems throughout the enterprise Leveraging existing technologies and standards


Business Process(Meta) Model

MessageBusiness ContentTechnical Content

Host

ServicesInterface

TechnologyMapping

CommonTechnical

Architecture

CommonTechnical

ArchitectureSecurity

Transport

Syntax & schemata

Holds

Sends &Receives

Uses

Structures

Enables

Populates

Supports

ComponentLibrary

CommonComponents

Defines

Providesmetadata for

Providescontent for

Holds

ProvidesAccessTo

Services

Process

Schemata

Codes, Elements

Network Economy

DistributedRepository RegistryRegistry


ebXML Architecture

• At the heart of ebXML is a powerful system of Registries and Repositories

• A Repository is a storage tank for Meta data such as Mapping Templates, business rules, “smart” document DTD’s, dictionaries, libraries and other core components for electronic business

RepositoryRegistryRegistry


ebXML Core Components

Core components are elements of the component library that are common to multiple business domains.

Core Components are Business Objects horizontal to many organizations. Examples can be an address on an invoice, a telephone number or a legal requirement to reply with confirmation of receipt of a purchase order.


Part Two - ebXML Mapping / Rendering

A review of ebXML Mapping / Rendering Architecture


ebXML Templates

Repository

Mapping Templates

Provide semantic information for “smart” business documents.

Ideally utilize a “declarative” approach to transformations. Small footprint.

ebXML Mapping / Renderiing Templates are expressed in valid XML syntax only.

They are authored and owned by standards bodies, businesses or organizations who wish to interoperate within the ebXML Architecture.


ebXML Registries & Repositories• A Registry is an interface to allow “Process Owners” to submit or

update their mapping templates.

• A Registry has two interfaces – one for applications (API) and one for Humans (Manual HTTP)

• A Security protocol is use to offer authentication, protection and non-repudiation benefits.

• Once the XML syntax has been validated, the Mapping Template is placed into the Repository.

RepositoryRegistry

API Human Interface

SECURITY LAYER

Syntax Validation


EbXML Repository Search Requirements

• Once the Mapping Templates are stored in a Repository, a search and retrieval mechanism must be employed.

• The XML Repository Search engine must provide:

– A Web Search interface for humans to manually locate data

– An API for applications to rapidly access stored data

– A caching mechanism


EbXML Repository Search Requirements• A mechanism will be deployed to meet the Search and Retrieval needs

for an ebXML Repository.• It must spider the Repository and creates a searchable index of the

XML-syntax data.• A cache is created • A machine API to the Cache is used

RepositoryRegistry

API Human Interface

SECURITY LAYER

Syntax Validation

XML indexmechanism

XMLCache

XMLCache

Spiders the Repository

XQI API Human SearchInterface


How ebXML Trading Partners Interact• A Trading Partner creates a Mapping Template The

Mapping Template Editor then sends a copy of the

Template to the Registry.

Trading Partner(ebXML Compliant)

ebXML Application

ebXML Application

Registry

API Human Interface

SECURITY LAYER

GUI Editing Tool


How ebXML Trading Partners Interact

• The trading Partner can now send a business transaction to another ebXML capable trading partner.

• The transaction sent to the second partner can be classified in three distinct categories - Meta Information, Technical Information and Business Information.

Trading Partner #1(ebXML Compliant)


Business Interchange


ebXML Transactional Architecture

• The Business transaction will be expressed in syntax that conforms to XML (current version is 1.0). The Business Information will be neutral but may need to use entity references to comply with the XML syntax requirements.



Business Interchange


ebXML Architecture• The first part of the message will be the Processing

instructions expressed in the document type declaration• A multibyte character set will be used to help facilitate

diverse language characters

<?xml version=“1.0” encoding=“UTF-8”?>

[note: This entire section will be elaborated on by Messaging Group]


ebXML Architecture• The message will use a root tag of <ebxml> to identify it

as an ebXML compliant transaction.

<?xml version=“1.0” encoding=“UTF-8”?><ebXML>

</ebxml>



ebXML Architecture

• The next component is the routing information (a technical component). Each message must have enough information in this section to uniquely identify each party and be able to address each party on the Internet.

<?xml version=“1.0” encoding=“UTF-8”?><ebXML> <routing verion=“1.0”> <from>Trading Partner 1</from> <to>Trading Partner 2</to> </routing>

</ebxml>



ebXML Architecture• The next component is the Meta data component for identifying the

business process, the version of that process, the owner of the process and where another application can retrieve a mapping template to apply to the business data component.

<?xml version=“1.0” encoding=“UTF-8”?><ebXML> <routing></routing> <process type=“Purchase_Order” version=“1.17” owner=“FOOBAR_EDI” location=www.foorepository.com/maps/>

</ebxml>


http://www.foorepository.com/maps


ebXML Message Architecture

… <process type=“Purchase_Order” version=“1.17” owner=“FOOBAR_EDI” location=“foorepository.com/maps”/>…

The <process> element is a mechanism to provide information that will allow a unique Mapping Template to be retrieved and applied to the business content of the message.





ebXML Message Meta Architecture

• The “type” attribute:– Is used to uniquely identify the process type in

conjunction with the “owner” and “version” attributes.

– Any combination of characters can be used as long as they are legal in XML syntax.

– Can be used with other attributes to locate a specific Mapping Template in a Repository




• The “version” attribute:– Is used to identify a specific version of a process

unique to each process “owner”

– Not to be confused with the “version” attribute of the <routing> element which is used to maintain state within a transaction

– Standard conventions of major.minor should be applied (ie version=“1.17”)




• The “owner” attribute:– Is used to identify a the organization who “owns” the

process being identified.

– Any combination of characters can be used as long as they are legal in XML syntax

– A shared Registry/Repository will be used to provide unique identification and assign “Owner” names.




• The “location” attribute:– Is used to retrieve Mapping Templates or UML

modelling of the process.

– Ideally will utilize http to point to this information



ebXML Architecture• When Trading Partner #2 receives the incoming message, it gets handed to the ebXML

application by the server interface that receives it.• The ebXML application then checks it’s own cache to see if the process Mapping

Template is available in the correct version.

RepositoryRegistry

XMLCache

XMLCache

XQI APIHuman Search

Interface

Index

TP #1 TP #2 EbXML Application

Local Cache


ebXML Architecture• If the process is available, the transaction can be acted upon.• If it is not found, the ebXML Application must then check the

repository cache via the API• If a Template is found, the transaction can now be acted upon.

RepositoryRegistry

XMLCache

XMLCache

XQI APIHuman Search

Interface

Index

TP #2 EbXML Application

Local Cache


ebXML Architecture• A third stage “Manual” search can be employed to locate a

similar Mapping Template. For example, v 1.17 may not be available however, 1.17 is. The Template Editor can now be used to manually create the template by TP #2

RepositoryRegistry

XMLCache

XMLCache

XQI APIHuman Search

Interface

Index

TP #2 EbXML Application

Local Cache

ManualSearch


ebXML Architecture• A Search logic is employed by the application to determine Mapping

Templates abstracts. If a MT to map X12 to cbXML is available and an MT to map cbXML to HL7 is available, this now allows a Trading Partners to map from X12 to HL7 even though no MT actually claims to do this.

X12

cbXML

HL7

TP #1 TP #2

X12 to cbXML

X12 to HL7 does not exist

cbXM

L to H

L7ABSTRACT TRANSLATION


InterfaceXml.org

eCoBiztalk

Repository

XMLCache

XMLCache

XQI APIHuman Search

Interface

INDEX

TP #1 TP #2 EbXML Application

Local Cache

INTERCHANGE

ManualSearch

ebXML App.

TEMPLATE EDITOR GUI

Registry

APIHuman Interface

SECURITY LAYER

Syntax Validation

Adding all the Components Together


Some Final Thoughts..

• Build an open architecture, not a “Standard”• Truly Inter-operable and Extensible

Thank you!Editor: Duane Nickull

EbXML TM Technical Architecture Overview

Documents

Transcript of EbXML TM Technical Architecture Overview