Transcript GoXML™ Transform 2.0

ebXML Technical Overview
How all the pieces fit together
Duane Nickull
CTO – XML Global Technologies
Chair – UN/CEFACT eBusiness
Architecture
[email protected]
Agenda:
 Examine some business and
technical needs for ebXML.
 Look at the overall architecture of
ebXML.
Followed by:
 ( Technical Track | Business Track )
2
ebXML Introduction
Understanding Mission and
Architecture
Business Needs
 Link traditional data exchanges (EDI or new XML) to
business applications.
 Lower costs to configure new e-Business relationships.
 Create “Smart” Business Processes.
 Provide a reusable set of core information
components.
 Low cost server and client based solutions.
 Protect investments in existing systems.
4
The need for XML
 It is desirable to transport data
around networks (including the
internet).
 XML is the format of choice for
marking up that data.
 SGML was too complex, HTML not
robust enough.
5
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
6
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>
7
XML is not enough.
 XML is for marking up data.
 XML, by itself, does not solve
interoperability problems yet it is an
important tool for doing so.
 XML does not provide semantics.
 XML does not solve business problems.
 XML Schemas do not provide semantics
or solve business problems.
8
Thoughts
 XML by itself is not the magic
bullet.
 What we really need is a dynamic
cross-walk mechanism for XML
based vocabularies.
9
Thus the need for ebXML
Mission: ebXML enables anyone,
anywhere to do business with
anyone else over the Internet
10
ebXML Technical Architecture
INDUSTRY
Specifications
XML
1
Scenarios
Business Profiles
COMPANY A
Request Industry Process Details
2
ebXML
Registry
Do
wn
3
Qu
lo
ad
eb
er
ya
XM
L
bo
co
ut
Build Local System
Implementation
Register Implementation Details
Register C OMPA NY A Profile
4
CO
mp
o
M
ne
PA
nt
NY
A
s
pr
of
ile
COMPANY B
ebXML compliant
software system
5
Ag
ree
DO
o
ra
nT
d in
g
en t
em
g
an
A rr
SS
E
N
SI
BU
AN
TR
S
ON
I
CT
SA
6
11
Architecture Concepts…
1. Business Processes and associated
Core Components (in XML)
2. A mechanism for registering and
storing them (Registry)
3. A mechanism for declaring a Trading
Partners capabilities and they can
do/support (CPP)
12
Architecture Concepts…
5. A mechanism for describing a Trading
Partners capabilities (CPP).
4. A mechanism for describing a Trading
Partner Agreement (CPA).
6. A standardized messaging service
(ebXML MS)
7. A standardized methodology/process
for modeling the real world business and
translating it into XML.
13
B
U
S
I
N
E
S
S
T
R
A
N
S
A
C
T
I
O
N
S
Business Operational View
Business aspects
of
business transactions
Comply with
Covered by
Viewed
as
BOV
related
standards*
Functional Service View
Information technology
aspects of
business transactions
Comply with
Covered by
FSV
related
standards
* UML Models
14
Modeling ….
BOV
Business Operational View
BDV
Business
Domain
View
BRV
Business
Requirement
View
BTV
Business
Transaction
View
BSV
Business
Service
View
15
And more modelling….
Business Experts
BDV
Designers
Analysts
BRV
BTV
BSV
Facilitors & Modelers
16
And yet more modelling….
Business Process
And Information Models
17
FSV Architecture
CPP
CPP
CPA
Interface
Interface
18
 At the heart of ebXML is a powerful system of
Registries and Distributed Repositories.
 The Registry provides the interfaces.
 Registries contain pointers and meta information
in the Registry Information Model (RIM).
 ebXML v 1.0 Registries have two main interfaces –
ObjectManager() and ObjectQueryManager().
 The methods exposed by the interfaces have set
metadata for expressing queries and returns.
Repository
Synchronization
RIM
Registry API
I/O
19
ebXML Registry Architecture
Managed
Objects
Passed by URI
Reference
Applications
GUI’s
Referenced
By URI
RIM
ObjectManager()
ObjectQuery
Manager()
RSS Messaging
Transport Layer
Registry Side
API
RSS Messaging
ebXML MSH
Transport Layer
Client Side
20
Registry Item Examples
 Registry systems can give you
information about many types of
ebXML and even non-ebXML
documents.
- CPP and CPA templates
- Business Process Documents
- Core Components and CC Aggregates
- DTD’s and Schemas (Assembly documents)
- Programming artifacts
21
XML Elements
 XML elements can reference items
from a Registry.
 Examples:




<LastName>
<NomDeFamille>
<Name>
<姓>
All are the same item!!!
22
Registry Item Examples
 XML elements in business messages
can reference items in a registry.
 Examples:




<LastName UID=“myrep:1236”>
<NomDeFamille UID=“myrep:1236”>
<Name UID=“myrep:1236”>
<姓 UID=“myrep:1236”>
All are the same item!!!
23
 XML Elements in document instances contain
pointers to Repository Item’s.
 Most Registry Items are metadata – not instances
of data.
<?xml version=“1.0”>
<UID>12345</UID>
<?xml version=“1.0”>
<Element> 姓 </Element>
<Also org=“yourOrg”>
LastName
</Also>
< 姓 UID=“FooRep:12345”>
Duane
</ 姓 >
Registry
API
API
Managed
object
Managed
object
Managed
object
24
ebXML Messaging Service
ebXML Applications
Messaging Service Interface
Messaging Service
Authentication, authorization and
repudiation services
Header Processing
Encryption, Digital Signature
Message Packaging Module
Delivery Module
Send/Receive
Transport Mapping and Binding
HTTP
SMTP
IIOP
FTP
…
25
ebXML – CPP and CPA
 Trading Partner Profiles and Agreements.
 Tells you Business Service Interfaces,
bindings etc.
 Provide a list of Business Processes or Web
Services.
 NOT designed to be a legal agreement.
example
26
ebXML Business Process
Specification Schema
BPSS are Runtime and Design Time artifacts.
 Captures particulars of BP in an XML
schema controlled instance.
 References Business Information used in
each step of process.
 Should Identify Assembly Docs at Design
time.
example
27
Core Components:
 A Core Component captures information
about a real world (business) concept.
 A Core Component can be atomic or
aggregate.
 It is ‘Core’ because it occurs in many
different
areas
of
industry/business
information exchange.
28
Core Component Realization
29
ebXML Business information
Collaborat
ion
Protocol
Profile
(CPP)
Supported
Business
Process
1.
.
<<References>>
Bridge to
Legacy Data
1..
<<Constructed From>>
DTD’s
Schemas?
DTD’s
Schemas?
DTD’s
Schemas?
XML Representations
<<Constructed From>>
Business Information Entities
<<Constructed From>>
Core
Comp.
Core
Comp.
Core
Comp.
Core
Comp.
Core
Comp.
Core
Comp.
Core
Comp
30
Methodologies
TOP
DOWN
APPROACH
UMM
Modeling
Core
Components
Payload
Metadata
Final Business
Payload
Payload
Metadata
Information
Components
Legacy
Data
BOTTOM
UP
APPROACH
31
Information Harmonization
UN/CEFACT
Core Components
2005
2004
UBL
EDI
2003
2002
Existing eBusiness Standards
xCBL HL7 OAG OTA SAP RosettaNet XBRL
32
Runtime Stack (first look).
CPP/A
BP Rules
BPEE
BPSS
ebXML MHS
App Server
URL
Port
Security
I/O
O/S
33
ebXML Use Case
Management
CRM
PR / IR
Production
Sales and Marketing
Shipping
Procurement
34
ebXML Business Service Interfaces
Management
CRM
PR / IR
Production
Sales and Marketing
Shipping
OUTSOURCE
Procurement
35
Some Final Thoughts..
 ebXML ideal foundation for Web Services.
 Build an open architecture, not a
“Standard”
 Truly interoperable and Extensible (Global)
 Includes everyone from SME’s to Fortune
1000.
 Facilitates global eBusiness.
Q&A
Duane Nickull
36
Q&A
37