The ebxml technical architecture presented by duane nickull cto xml global technologies may 2001
Download
1 / 54

The ebXML Technical Architecture Presented by: Duane Nickull CTO, XML Global Technologies May 2001 - PowerPoint PPT Presentation

The ebXML Technical Architecture Presented by: Duane Nickull CTO, XML Global Technologies May 2001 Before we begin… Caveats – ebXML is a work in progress and the work you see today could be subject to change. Presenter – Duane Nickull

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

The ebXML Technical Architecture Presented by: Duane Nickull CTO, XML Global Technologies May 2001

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The ebXML Technical Architecture

Presented by:

Duane Nickull

CTO, XML Global Technologies

May 2001


Before we begin…

  • Caveats –

  • ebXML is a work in progress and the work you see today could be subject to change.


Presenter – Duane Nickull

  • Co-lead/Chief Editor - ebXML Technical Architecture, ebXML Steering Committee

  • Founder and CTO of XML Global Technologies (www.xmlglobal.com)

  • Co-engineered / invented

    • GoXML – First Context based XML Search Engine.

    • First XML e-Commerce Pro (launched Mar 1999).

  • Working with OAG, OASIS, UDDI, HRXML, WSDL

  • Built a reference implementation of ebXML

  • Technical Editor / Director of XSLT.com

    duane@xmlglobal.com


Initial Thoughts:

  • Examine some business technical needs

  • Look at the overall architecture of ebXML.

  • Show working example of XML Global ebXML marketplace

  • Discuss implementing ebXML today

    Followed by:

  • ebXML Proof of Concept Demonstration


Business Technical Needs

  • Link traditional data exchanges (EDI or new XML) to business applications.

  • Create business processes based on smart documents.

  • Provide means for trading partners to quickly and easily locate re-usable components.

  • Provide means for trading partners to customize methods to their own internal systems.

  • Low cost server and client based solutions.


The need for XML

  • It is desirable to transport data around networks (including the internet).

  • Ideally, that data should be self describing.

  • SGML was too complex, HTML not robust enough.


What is Self Describing???

ST*323*712990413

V1*7039610*NEW ZEALAND QUEEN*D*104N*SCAC***L

LS*0100

R4*D*D*JAX*JACKSONVILLE FL****

V9*EAD**920819**JACKSONVILLE FL***A26

R4*D*D*ORF*NORFOLK, VA**NORFOLK INTL TERMIN**

V9*EAD**920817**NORFOLK, VA***A26

R4*L*K*MEB*MELBOURNE, AUST****

V9*EDD**920712**MELBOURNE, AUST***A40

R4*L*K*SYD*SYDNEY, AUST****

V9*EDD**920715**SYDNEY, AUST***A40

R4*L*K*WLG*WELLINGTON, NEW ZEALAND****

V9*EDD**920721**WELLINGTON, NEW ZEA***A40

LE*0100

SE*25*712990413

This is not

self describing

data!


XML is Self Describing

<?xml version=“1.0”?><Data> <Item ID=“112”> <Name>Rod</Name> <Price>12.00</Price> <Units>1</Units> </Item> <Item ID=“114”> <Name>Reel</Name> <Price>15.00</Price> <Units>1</Units> </Item> <Item ID=“120”> <Name>Bait</Name> <Price>24.00</Price> <Units>3</Units> </Item> </Data>


XML issues…

  • XML is a markup language

  • XML, by itself, does not solve interoperability problems yet it is an important tool for doing so.

  • Using XML alone, does not provide semantics

  • XML is a not programming language

  • XML is not a fixed element language

  • XML is not difficult to understand

  • XML will not replace HTML

  • XML does not solve business problems

  • XML Schemas do not provide semantics or solve business problems.

    • What we really need is a dynamic cross-walk mechanism for XML based vocabularies.


¢

¢

¢

¢

¢

¢

¢

¢

Thus the need for ebXML

  • Through the “Electronic Business XML” (ebXML) Initiative OASIS and UN/CEFACT want to lower the barrier of entry to electronic business in order to facilitate trade, particularly with respect to small- and medium-sized enterprises (SMEs) and developing nations.


The ebXML Technical Architecture


Business Operational View

Comply with

Business aspects

of

business transactions

BOV

related

standards*

Covered by

Viewed

as

Functional Service View

Information technology

aspects of

business transactions

Comply with

FSV

related

standards

Covered by

Ebxml Architecture design

B

U

S

I

N

E

S

S

T

R

A

N

S

A

C

T

I

O

N

S

* UML Models


Business Operational View


Business Operational View (BOV)

The BOV addresses the semantics of:

1) The semantics of business data in transactions and associated data interchanges

2) The architecture for business transactions, including:

i) operational conventions;

ii) agreements;

iii) mutual obligations and requirements.

These specifically apply to the business needs of ebXML Trading Partners.


FSV Architecture

CPA

Interface

Interface


Functional Service View (FSV)

The FSV addresses the supporting services meeting the mechanistic needs of ebXML. It focuses on the Information Technology aspects of:

i) functional capabilities;

ii) service interfaces;

iii) protocols.


TA Philosophy

Architect ebXML in Layers

Start with the high level use cases

The first layer has to recognize the Repository Items that constitute Core Components (ie address, tel).

The second Layer has to recognize the Business Process (BPM)

Third Layer is discovery of what partners require (CPP – Collaborative Process Protocol)

Use existing work – the wheel is already round!!!!

Write test code (informally) to test concepts!!!


ebXML High Level use case


Concepts

The conceptual overview has therefore introduced the following concepts and architectural components:

1. A standard mechanism for describing a business process and its associated information model (BPSS)

2. A mechanism for registering and storing a business process and information model so that it can be shared/reused (Registry)

3. Discovery of information (from the CPP) about each participant including:

·What business processes they support.

·What service interfaces they offer in support of the business process.

·What business messages are to be exchanged between their respective service interfaces.

·Technical configuration of the supported transport, security and encoding protocols


Concepts (continued)

4. A mechanism for registering the aforementioned information so that it may be discovered and retrieved (Registry Client or Interface)

5. A mechanism for describing a Trading Partner Agreement (CPA) which can be derived from the information about each participant from their CPP.

6. A standardized messaging service which enables interoperable, secure and reliable exchange of messages between two parties (ebXML TRP)

7. Mechanism for configuration of the respective messaging services to engage in the agreed upon business process in accordance with the constraints defined in the CPA.


ebXML Architecture

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

The Registry is really the interface to the documents.

Registries contain pointers and meta information about many different items - Core Components, DTD, Trading Partner Profiles and Business Process documents.

It is important that we can reference items (CC) from Business Process Layer down to the most atomic Element Level.

Repository

Synchronization

Registry

I / O

API


Repository Item Examples

  • Registry systems can give you information about many types of ebXML documents

    - CPP and CPA templates

    - Business Process Documents

    - Core Components and CC Aggregates

    - DTD’s and Schemas (Assembly documents)


Registry Item Examples

  • XML elements in business messages can reference items callable from a Registry.

  • Examples:

    • <nameofperson>

    • <nomdelapersonne>

    • <name>

    • <TheThingICallYou>

      All are the same item!!!


Registry Item Examples

  • XML elements in business messages can reference items in a registry.

  • Examples:

    • <nameofperson UUID=“myrep:1236”>

    • <nomdelapersonne UUID=“myrep:1236”>

    • <name UUID=“myrep:1236”>

    • <TheThingICallYou UUID=“myrep:1236”>

      All are the same item!!!


XML Elements in document instances contain pointers to RI’s

Registry Items are metadata – not instances of data

<?xml version=“1.0”>

<GUID>12345</GUID>

<Element>name</Element>

<EQ org=“yourOrg”>

PersonName

</EQ>

Repository

Item

<?xml version=“1.0”>

<name GUID=“FooRep:12345”>

Duane

</name>

Document

Instance

Registry

API

API

Managed

object

Managed

object

Managed

object


Registries – deployment

  • Both centralized and decentralized RegRep models shall be acceptable within the ebXML infrastructure. The ebXML registry architecture supports distribution.

  • No single point of failure


User

User

User

User

User

User

Registry (API)

Repository

Centralized System


Decentralized Repository / Distributed Registry

Repository

Items

Registry

(subscribes to decentralized Repository Items

Repository

Items

User

sync

User

Repository

Items

Registry (API)

Repository

Items

User

Searching and indexing only

User

Repository

Items

User

Repository

Items

User


ebXML – CPP and CPA

  • Tells you who, interfaces, tModels etc.

  • Provide a list of interfaces expressed as Business Processes (and binding’s)

  • Each Process has a Globally Unique Identifier (called UUID in UDDI, GUID in ebXML)

  • Similar efforts – IBM TPAML, UDDI, eCo.

CPP Preview


ebXML Business Process

BP describe document choreography and overall process interfaces.

  • Identify which business data needs to be present to ensure requirements of a party is being met.

  • Examples can be “Deliver a service” or “Purchase a product”

  • Identify DTD’s by GUID

BPM Preview


Core Components:

  • A Core Component captures information about a real world (business) concept.

  • A Core Component can be either an individual piece of business information (atomic data element), or a natural 'go-together' family of business information pieces (aggregate data element).

  • It is ‘Core’ because it occurs in many different areas of industry/business information exchange.

CC Preview


ebXML CC and XML Vocabularies

  • Vocabularies (eg. xCBL 2.0, Ariba cXML) contain elements that may be semantically identical to some of the common core components. Examples can be an <address> element on a xCBL invoice and the <partyAddress> on a Visa XML Invoice.

  • Core Components MAY have contextual behaviour at run time

    • i.e. PurchaseOrder.sendParty(name) != PurchaseOrder.buyerParty(name)


ebXML Phases

Phases of implementing and running ebXML..


RequestSpecification()

ReceiveSpecification()

RequestLexicon()

ReceiveLexicon()

RequestBusinessObjectLibrary()

ReceiveBusinessObjectLibrary()

RequestSomeOnesBusinessProcessInformationModel()

ReceiveBusinessSomeOnesBusinessProcessInformationModel()

SendOwnBusinessProcessInformationModel()

ReceiveAcknowledgementForOwnBusinessProcessInformationModelAcceptance()

SendOwnTradingPartnerProfile ()

ReceiveAcknowledgementForOwnTradingPartnerProfile ()

Implementation Phase

ebXML Specification

ebXML

Registry

Business Process and Information Models

Request / Send

Lexicon

(Core Component)

Content

Receive

ebXML

Business

Service Interface

(application)

Business Object Library


Some examples of possible access service methods

RequestSomeOnesTradingPartnerProfile()

ReceiveSomeOnesTradingPartnerProfile ()

RequestSomeOnesNew/UpdatedBusinessProcessInformationModel()

ReceiveBusinessSomeOnesNew/UpdatedBusinessProcessInformationModel()

SendTradingPartnerAgreement()

ReceiveAcknowledgementForTradingPartnerAgreement()

RequestLexiconUpdate()

ReceiveLexiconUpdate()

RequestBusinessObjectLibraryUpdate()

ReceiveBusinessObjectLibraryUpdate()

Discovery Phase

Business Process and Information Models

ebXML Registry

Lexicon

(Core Component)

Content

Business Object Library

Request

Receive Update

ebXML

Business

Service Interface

(application)

TPP

Registry

List of Scenarios

Query

Retrieve (abstract)

Messaging Constraints

Send

ebXML

Service Interface

(application)

Security Constraints


ebXML Run Time Phase

ebXML

Business

Service Interface

(application)

ebXML

Business

Service Interface

(application)

Send

Retrieve

SendBusinessMessage()

ReceiveBusinessMessageAcknowledgement()

ReceiveBusinessMessage()

SendBusinessMessageAcknowledgement()

GenerateErrorMessage()

ReceiveErrorMessage()

Some examples of possible transport methods


Business Profile Document (XML)

Indexes XML instances based on rules and meta data in index.xml

Business Process Document (XML)

DTD’s / Schemas

GUI

Reg

Business Profile Registry

Trading Partner “A”

Big Co.

Business

Process

Registry

Trading Partner “B”

Big Co.

DTD /

Schema

Registry

Registry

Abstract Layers.

Core

Component Library

Registry

Core Component

Library


Special Considerations for SME’s

  • SME’s will not likely have the expertise to start modeling business processes in UML.

  • Address complexity issues – part of the reason why EDI failed to scale/

  • SME’s need a cost effective solution – plug and play type components.

  • ebXML is designed to allow lightweight packages and scaled integration.

  • DEMO – ALPHA (online)


How ebXML SME’s interact

  • SME’s will likely use packages from ASP’s which will present simple web forms for them to fill out. These will include many stock business processes, identifiable by a GUID (UUID).

  • An SME may also identify and use BPM’s (Business Processes) and DTD’s / Schemas used by its partners.

Trading Partner

(ebXML Compliant)

GUI Tool

Trading Partner

Profile

Repository

system

API

Human Interface

SECURITY LAYER

Registry


Collaboration

Protocol

Profile (CPP)

Supported

Business

Process

1..

<<References>>

1..

<<Constructed From>>

DTD’s

Schemas?

DTD’s

Schemas?

DTD’s

Schemas?

<<Constructed From>>

Common Business Objects

<<Constructed From>>

Core

Comp.

Core

Comp.

Core

Comp.

Core

Comp.

Core

Comp.

Core

Comp.

Core

Comp

ebXML Business information

Decomposition to the most atomic level is the winning strategy for ebXML. It allows for automated semantic recognition of business information by using Registry services.


Business Message References

Examples:

eCo.xml

UDDI

Partner Discovery Layer

Examples:

ebXML BP

Syntax

Business Process Layer

Business

Messages

Business Info Layer

Contain

Examples:

xCBL, cXML

Visa Inv.

References to:

Human Search

Interface

Registry

Repository

Items

Business

Application

Interface

API

Human Actors


Building an ebXML Marketplace

  • Caveat – do not claim you have an ebXML compliant marketplace until the spec is done and conformancy tests are available.

  • Start with slow transition.

  • Adopting ebXML is not really complex but needs to be well though out.

  • Some specific tools are needed.


ebXML Marketplace Architecture

  • Registry/Repository is used as a central mechanism for Registration and subsequent discovery of XML meta data.

  • XML Global uses XML Search Engine tightly coupled with Native XML Database.

  • Facilitates ebXML TRP as messaging.


ebXML Marketplace Architecture

  • Tools on front end allow companies to Register their CPP’s.

Register

CPP


Building an ebXML Markeplace

  • Once a Skeleton CPP is built, the user may add one or more Business Processes


CPP

Registry

XML Global ebXML Marketplace

  • Users’ CPP is now complete with BP’s and other participants can query the Registry using published API.

ebXML Users


Registry

XML Global ebXML Marketplace

  • Another User can now retrieve and examine the CPP if they are wanting to do business with the first user.

CPP


Building an ebXML Marketplace

  • As long as they know some basic information, they can compose a CPA and propose it to the first organization.

Self(CPP)

other(CPP)

CPA

Propose()

TRP_Packaging

Verify()


Building an ebXML Marketplace

  • The recipient can then examine the CPA and check it. If it is acceptable, they may wish to sign it. A business Agreement is now in place.

ReceiveProposedCPA()

Validate()

Recognize BP()

Accept() | Reject() | CounterPropose()


Proprietary

Data

Format

ebXML Marketplace

  • Once a CPA and BP have been recognized (by GUID or by query), business information can be transformed using a declarative transformation tool.

Data Exchange

ebXML

Compliant XML Syntax

Backend

System


Data Transformation is key

DEMO .NET Transformation http://demo.xmlglobal.com


Putting all the pieces together

Repository

Repository

Manual

Search

TP #1

TP #2

EbXML

Application

Repository

Registry

QUERIES

INTERCHANGE

Local Cache

ebXML App.

Human Search

Interface

Business modeling

INDEX

Business

Interface

Human

Interface

API

QUERIES

XML

Cache

API

Repository

SECURITY LAYER

Registry

synchronizes

Interface

xCBL

Syntax Validation

UDDI

Biztalk

Schemas


Some Final Thoughts..

  • ebXML to build an open architecture, not a “Standard”

  • Truly interoperable and Extensible (Global)

  • Includes everyone from SME’s to Fortune 1000

  • XML Global has begun implementing this year (2001)

Thank you!

Duane Nickull


Copyright Notice / Credits

You may use this presentation freely for your purposes!

  • Copyright is owned by the Author however, you are hereby granted the right to reuse, distribute, translate and show this presentation, free of any royalty in the spirit of open sharing of information.

  • There are no restrictions other than modification of this copyright notice or credits which must remain intact.

  • Contact Duane Nickull, duane@xmlglobal.com


ad
  • Login