Adobe Systems XML Registry Workshop - PowerPoint PPT Presentation

Loading...

PPT – Adobe Systems XML Registry Workshop PowerPoint presentation | free to view - id: a319e-YzFkZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Adobe Systems XML Registry Workshop

Description:

Agenda - Day 1. 9:00 9:30 Introduction, Agenda and statement of objectives: ... also explored to discuss how semantic discovery may be possible using XML syntax ... – PowerPoint PPT presentation

Number of Views:180
Avg rating:3.0/5.0
Slides: 144
Provided by: dua83
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Adobe Systems XML Registry Workshop


1
Adobe Systems XML Registry Workshop
Name Duane Nickull Title Senior Standards
Strategist
2
Presenter Duane Nickull
  • Senior Standards Strategist, Adobe Systems Inc.
  • Former Team Lead UN/CEFACT eBusiness
    Architecture Group (UEB Architecture)
  • Former Co-lead/Chief Editor - ebXML Technical
    Architecture v 1.0
  • Former W3C Web Services Architecture Group
    member.
  • UN/CEFACT OASIS Joint Coordination Committee
    Special Technical Liaison W3C.
  • dnickull_at_adobe.com

3
News Release (relevant)
  • Adobe Extends Commitment to XML Standards with
    Acquisition of Yellow Dragon Software
  • Acquired Technology Assets Enable Native ebXML
    Support in Adobe's Intelligent Document Platform
    and Streamline Collaboration Across the Extended
    Enterprise
  • http//biz.yahoo.com/bw/031110/105289_1.html

4
Agenda - Day 1
900 930 Introduction, Agenda and statement of
objectives - Introduce ourselves and state
specific objectives from this course to the
instructor. - Any concerns they have or
specific questions may be addressed at this time.
- Course outline. 930 1100 Part 1 An
Introspective Analysis of Service Oriented
Architectures - A brief history of how Service
Oriented Architectures evolved. - ebXML,
UN/CEFACTs eBusiness Architecture and Web
Services Architectures as three reference models.
- Show how Registries are positioned within
these architectures.
5
Agenda - Day 1
  • 1100 1120 Break
  • 1120 1230 Part 2 An Introspective Analysis
    of Service Oriented Architectures
  • - A continuation of the earlier session with
    more specific delving into Registry Systems. Each
    SOA places different demands of the Registry
    facility and those functional requirements are
    examined in details.
  • 1230 QA
  • 1240 1340 lunch break
  • 1340 1500 Registry Functionality and
    Architecture - Explore the major facilities of
    a Registry/Repository System
  • - Show how a Registry functions.
  • - Examine relationship of registries to
    repositories
  • - Tightly bound vs. loosely coupled models
  • - Registry Interfaces for humans and
    applications.
  • - Registry architecture (server-client models,
    API, security)

6
Agenda - Day 1
  • 1500 1520 Break
  • 1520 1645 The Business Use case for Registry
    Adoption
  • Factors that make registry systems favored for
    adoption within specific enterprise
    architectures.
  • - List of some registry use cases.
  • - Factors that drive their adoption.
  • - Specific registry adoption strategies and the
    benefits that may be realized.
  • 1645 1700 Q A

7
Agenda - Day 2
  • 900 1045 ebXML Registry a specific look at
    the ebXML Registry Model
  • - A specific look at ebXML Registry
  • - Identify the major specifications that
    constrain an ebXML Registry, capabilities and
    deployment models.
  • - Discuss a few reference implementations.
  • - Overview of Registry Services Specification
    (RSS)
  • - Overview of Registry Information Model (RIM)
  • 1045- 1105 Break
  • 1105 1200 UDDI Registry
  • - A specific look at the UDDI Registry
    Specifications - Overview of what a UDDI
    Registry does.- How UDDI differs from an ebXML
    Registry.
  • 1200 QA
  • 1210 1300 Lunch Break

8
Agenda - Day 2
  • 1300 1500 ISO 11179 model for metadata
    Registries - International Standards
    Organizations (ISO) 11179 specification for
    metadata registries. - The work of ISO and its
    relationship ebXML and UDDI. - Ontology efforts
    are also explored to discuss how semantic
    discovery may be possible using XML syntax and
    Registries. - Meta facilities management covered
    include classification structures and schemes,
    associations and relationships between different
    Registries. - Automatic semantic discovery and
    dynamic configuration of system interfaces based
    on discovery of registry artifacts.
  • 1500 1645 Setting up a Registry System -
    Live demonstration of setting up a
    Registry/repository environment.
  • - Configuration of Registry. - Granting
    privileges to the Registry Authority (RA)-
    Creating the top-level classification scheme
  • - Adding the first artifacts to the Registry.
  • 1465 1700 Q A

9
Agenda - Day 3
  • 900 Recap of Day One and two any unanswered
    questions, comments etc.
  • 915 1045 Programmatic Registry clients -
    Examples of programmatic access to the
    Registry.- Acquiring and configuring the
    libraries.
  • - Write a simple REST client that can perform
    simple registry tasks from a line command. -
    Java based client will demonstrate many of the
    registry features including sending proper
    credentials to access the Registry content.
  • 1045- 1105 Break
  • 1105 1245 Mastering the Registry environment
    - Continuation of the morning session.-
    Registry Client Functionality- Training the
    attendees of usage of registry facilities.
  • - Registry authoritys roles and
    responsibilities, user accounts and
    administration, preventing unauthorized access,
    protecting registry content, locking content from
    use, administration of classification schemes

10
Agenda - Day 3
  • 1245 1300 QA
  • 1300 1400 Interactive Lunch break
  • 1400 1515 Registry Federation,
    De-centralization and future work. Work that is
    on-going within the applicable Registry standards
    bodies and upcoming features for new registry
    work. A brief discussion about the political
    landscape with software vendors and who is
    backing different Registry initiatives.
  • 1515 1535 - Break
  • 1535 1645 Deployment strategies for IT
    workers W- Once a Registry system has been
    decided on for deployment, work begins to make
    other departments aware of the Registry and help
    them begin using it. Carefully planning the
    Registry implementation by collecting
    requirements and calculating registry usage will
    benefit all and ensure a successful
    implementation. The pre-deployment planning and
    post deployment training will be highlited by
    showing actual functionality
  • 1645 1700 Final Q A

11
Round table
  • Introductions.
  • What do you expect to get out of this class?
  • Specific registry projects?
  • Company / Department / Sign in sheet.
  • Any concerns they have or specific questions may
    be addressed at this time.
  • Any questions on the schedule.
  • Additional topics? (time permitting)

12
An Introspective Analysis of Service Oriented
Architectures
0930
  • Understanding the technological and cultural
    factors driving their adoption

13
First - Business factors for Services
Cultural Shift
SOA eBusiness Processes over WWW
System Integration
Business to Customer
Internet Based Delivery
WANs
Local Networks
Protocols / Standards

Computers
14
Competitive Marketplace
1954 2004
Source BancBoston Robertson Stevens
15
Business Interaction Models
HTML
B to C
Disintermediation
EDI
B to B
Collaboration
XML
Infomediary
Malls
16
The Shift to N-Tier
N-Tier
2-Tier
Internet/ Enterprise
1-Tier
Client/Server
Distributed Production Web Aware/Web
Scale eCommerce
Monolithic/Automation
Corporate Applications (Often departmental)
Mainframe Apps Mini-Computer Apps
17
Second Technical Services
  • A program often resides on one system.
  • Old style -gt Spaghetti code no structure, no
    classes procedural and linear execution.
  • GWBasic, early Cobol, Pascal, Fortran
  • Object-Oriented programming is the early roots of
    Service Oriented Architecture.
  • Classes ecapsulate logic and data.
  • They can call each other as services - Accessor
    and Mutator or get() and set().

18
A simple program (object-oriented)
  • public class HelloOttawa
  • public static void main(String args)
  • System.out.println("Hello Ottawa!")

Calls a method() of the class
Imports another class
Import HelloOttawa public class
HowAreYouOttawa public static void
main(String args)
HelloOttawa() System.out.println("How are
you!")
19
The basis for Service Oriented
This class offers a service
  • public class HelloOttawa
  • public static void main(String args)
  • System.out.println("Hello Ottawa!")

Import HelloOttawa public class
HowAreYouOttawa public static void
main(String args)
HelloOttawa() System.out.println("How are
you!")
This class uses the service
20
Service Oriented Architecture expanded
  • What if the two classes are not on the same
    machine?
  • How can one class find another?
  • How can a class send its information to the
    other class?
  • Do the two classes have to be on the same
    network?
  • Distributed Computing!!!!

21
A new class() multiplies two numbers
  • public class Multiply
  • public static void main(String args)
  • if (args.length ! 2)
  • System.out.println( "Usage java "
    Multiply.class.getName() " ltinteger agt ltinteger
    bgt")
  • System.exit(-1)
  • try
  • int a Integer.parseInt(args0)
  • int b Integer.parseInt(args1)
  • int result a b
  • System.out.println(a " times " b "
    " result)
  •  
  • catch (Exception e)
  • System.err.println("Error encountered "
  • e.getMessage())
  • System.exit(-1)

22
Calling a service (RPC)
  • Remote Procedure Call (RPC)
  • Calling a functional piece of logic that resides
    elsewhere.

Multiply (5.45, 1.63)
ConvertCurrency(5.45, USD, CAD)
Multiply() class
ConvertCurrency() class
Result comes back
23
Service Oriented components
  • A transport mechanism is required that can
  • Take a payload in a machine readable manner.
  • Route it to the Service
  • Provide sufficient information to allow the
    service to return an answer.

24
XML-RPC transport for RPC
  • XML-Remote Procedure Call
  • Precursor to SOAP
  • Very lightweight
  • Usually used within a Local Area Network (LAN)
  • Used for non-critical applications (messages may
    get lost, timeouts, no ack required).
  • More was needed.

25
Why XML?
  • If we want to use the multiply class, we need to
    provide parameters (arguments) to the service
    along with the type of service call.
  • Example multiple (4,5)
  • XML provides a way to do this that is not
    dependant on programming language, operating
    system or code styles.
  • Possible to have a CurrencyConversion() class
    running on Linux in ANSI C calling the
    Multiply() class running in Java on Windows. XML
    is the go-between. Standardized encodings.

26
Data Serialization Problem
Int array4 -9, 0, -2, 1
27
Caveats
The receiving machine must have the same view
of the data as the sending app. If the
receiving machine sees it as a set of unsigned
integers, the logical view changes..
Unsigned integers
Array Size
Index_0 value
Index_1 value
Index_2 value
Index_3 value
4
247
0
254
1
28
More
  • Now add in
  • - multibyte integers characters
  • - bit ordering uncertainties
  • Message serialization should not depend on
    language, compiler or platform characteristics.

29
Real World Problems
  • ASSET/DATA/MERGE
  • NAMEFliegel
  • DATE 01.01.01
  • ASSET/CONTENT
  • FILEsystem//fliegel.jpg

ST323712990413 V17039610D104NSCACL LS010
0 R4DDJAXJACKSONVILLE FL V9EAD920819
JACKSONVILLE FLA26
XML
Field delimiters, grouping delimiters, what
constitutes containment, white space handling,
end of line handling, recoverable error when
parsing, data validation, data typing/masks,
enumerated types..
30
A quick look at XML.
lt?xml version1.0 encodingUTF-8?gt
ltelement1gt
ltelement2gt lt/element2gt

content
lt/element1gt
ltelement1 attributeThis is the largest
container/gt
content
31
Benefits of XML and related standards
  • Lower costs and reduced errors.
  • Global standard wide usage.
  • Consistent data conduct.
  • Increase speed of deployment.
  • Free Parsers in most languages.
  • Allows flexibility in future
  • Provide investment protection.

Key Champion awareness and recognition of the
value of standards. The first step is knowledge.
32
XML Solution to array problem
  • lt?xml version1.0 encodingUTF-8?gt
  • ltarray size4gt
  • ltinteger value-9/gt
  • ltinteger value 0/gt
  • ltinteger value-2/gt
  • ltinteger value 1/gt
  • lt/arraygt

33
XML Solution to Multiply() problem
  • ltparametersgt
  • ltservicegtMultiplylt/servicegt
  • ltinteger value5/gt
  • ltinteger value 4/gt
  • lt/parametersgt

ltanswergt ltinteger value20/gt lt/answergt
Service publisher
Service User
34
Remote Service -gt Web Service
  • Call services over http.
  • Use XML for marking up parameters and returns.
  • Can use Simple Object Access Protocol (SOAP) or
    ebXML Messaging (or others).
  • Web Services services accessed via the Web.
  • Synchronous and Asynchronous
  • Loosely coupled systems have evolved.

35
How do I find/describe services?
?
?
?
?
?
?
US
?
?
36
Web Service Description Language
  • WSDL provides a simple description of the service
    offered.
  • WSDL is missing many things semantics, trading
    partners agreements, constraints on who can use
    the service, etc.
  • WSDL is a very simple, partial solution to a big
    problem and does not tackle all issues.
  • Still works in many cases.

37
Business Service Interface (BSI)
  • UN/CEFACT term (Abstract Architectural).
  • For Business applications, there are standards
    that can be used to describe Service endpoints.
  • ebXML uses CPPs.
  • CPPs point at payloads (with semantics)
  • CPPs points at Business Processes (and
    collaborations)
  • More on WSDL, CPP later.

38
Service descriptions
CPP BPSS
WSDL
?
WSDL
?
Eco.xml
?
?
Eco.xml
?
CPP BPSS
?
How do I discover them?
?
?
CPP
WSDL
39
Registry/Repository
CPP BPSS
WSDL
?
WSDL
?
Eco.xml
?
?
Eco.xml
?
CPP BPSS
?
REGISTRY
?
?
CPP
WSDL
40
Service Oriented Architecture
  • Need to define an Architecture to show these
    interactions.
  • 3 main SOA examples to look at
  • ebXML OASIS UN/CEFACT
  • Web Services Architecture Group (WSAG) W3C
  • UN/CEFACT eBusiness Architecture United Nations
    CEFACT TMG group.
  • Coming up after break!

41
The ebXML SOA Architecture
1105
  • Reliance on Registry systems.

42
Company or Government Use Cases
  • A company can have a service much like a code
    method().
  • Companies can offer business services for those
    who wish to purchase services, validate
    credentials etc.
  • Government users may wish to associate an owner
    with a vehicle license plate, a registered owner
    with a firearm or validate permit information.
  • A process may be associated with roles and
    information.

43
ebXML Service Oriented Architecture
44
Architecture Concepts
  • Business Processes and associated Core Components
    (in XML).
  • A mechanism for registering and storing them
    (Registry)
  • A mechanism for declaring a Trading Partners
    capabilities and they can do/support (CPP)
  • A way to convey semantics and agree on meanings
    of Business Payloads (Core Components, BIEs)

45
Architecture Concepts
  • A mechanism for describing a Trading Partner
    Agreement (CPA).
  • A standardized messaging service (ebXML MS)
  • A standardized methodology/process for modeling
    the real world business and translating it into
    XML.

46
ebXML uses EDI Reference Model
B U S I N E S S T R A N S A C T I O N S
UML Models
47
ebXML FSV implementation
48
ebXML Registry / Repository
  • The Registry is the heart of ebXML.
  • Powerful system of Registries and distributed
    Repositories.
  • Loosely coupled.
  • Registries contain pointers and meta infromation
    (Metadata)
  • The Registry Services exposed by the interfaces
    have set methods().
  • The Registry is the heart of ebXML.
  • Powerful system of Registries and Distributed
    Repositories.
  • Loosely coupled.
  • Registries contain pointers and meta information.
    Meta information constrained by Registry
    Information Model (RIM)
  • The Registry Services exposed by the interfaces
    have set metadata for expressing queries and
    returns.

Repository
Registry
Synchronization
I / O
RIM
API
49
ebXML Registry Item Examples
  • Registry systems can give you information about
    many types of ebXML and even non-ebXML documents.
  • - CPP and CPA
  • - Business Process Documents
  • - Core Components and CC Aggregates
  • DTDs and Schemas (Assembly documents)
  • Other non-xml or non-ebxml artifacts.

50
ebXML Business information
Collaboration Protocol Profile (CPP)
Supported Business Process
1..
ltltReferencesgtgt
Bridge to Legacy Data
1..
ltltConstructed Fromgtgt
DTDs Schemas?
DTDs Schemas?
DTDs Schemas?
ltltConstructed Fromgtgt
XML Representations
Business Information Entities
ltltConstructed Fromgtgt
Core Comp.
Core Comp.
Core Comp.
Core Comp.
Core Comp.
Core Comp.
Core Comp
51
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.
  • Think ISO 11179 Data Elements!

52
Core Components driven by UMM
53
Core Components BIEs are
54
Business Process
  • Choreography of a bilateral (or more?)
    engagement.
  • Must maintain state at both ends.
  • Constraints imposed on forward progress in
    process.
  • Examples - gt real world vs. virtual.
  • Points at Payloads to be used at modeling time
    (Design Phase) and at Runtime Phase.
  • Work on going.
  • BPEL (Business Process Execution Language).

55
Web Services Architecture
  • Developed from RPC, XM-RPC, WSDL and associated
    standards.

56
Quick Introduction to Web Services
  • Web Services usually refers to a group of loosely
    coupled components like WSDL, SOAP, WSCI etc.
  • Has risen from the ground up (technically driven)
  • Derived from XML-RPC
  • Same basic principles as ebXML.

57
I want to offer a service
1. This application offers functionality that
others can use
2. I make it available via a SOAP interface
usually in a servlet container
3. I describe the servicein a Web Services
Description Language (WSDL) instance doc (XML
format)
4. I register that service in a UDDI or ebXML
Registry so others can locate and use it.
58
Web Service simple model
59
Web Service expanded model
60
WSAG principles
  • An interoperability architecture.
  • Not intended for individual Web services
  • Not dependant on WSDL, SOAP, ebXML MS or any
    other technology.
  • to provide a global perspective on the networked
    service architecture.
  • Other specifications, such as SOAP 1.2 and WSDL
    give detailed recommendations for specific
    requirements

61
WSAG relationships
62
WSAG major goals
  • Interoperability between Web services,
  • Integration with the World Wide Web,
  • Reliability of Web services,
  • Security of Web services,
  • Scalability and extensibility of Web services,
    and
  • Manageability of Web services.

63
WSAG major non-goals
  • To prescribe a specific programming model or
    programming technology
  • To constrain the internal architecture and
    implementation of specific Web services
  • To demonstrate how Web services are constructed
  • To be specific about how messages or other
    descriptions are formatted (ebXML, AS1?)
  • To determine specific technologies for messaging,
    discovery, choreography etc.

64
Web Services major components
65
The UN/CEFACT Architecture
  • Building on top of ebXML and Web Services.

66
Key Architecture Principles
  • Platform independence.
  • Event driven and Service Oriented Architecture.
  • Facilitation of multiple concurrent and/or
    different implementations.
  • Component based architecture allowing eBusiness
    components to be added, deleted or modified.
  • Allows proprietary protocol support, including
    custom extensions for industry standards. This
    refers to, but is not constrained by, electronic
    message payloads.
  • Custom workflow, information and syntax
    definitions are allowed in support of unique
    business rules and requirements, as may be
    defined by users.
  • Incremental phased implementation.

67
(No Transcript)
68
Business Service Interface
  • All details of a service interface.
  • Can be adapted for non-business.
  • Most BSI information will likely be registered in
    a Registry.

69
Runtime Stack uses BSI artifacts.
70
State Management
71
The UN/CEFACT Modeling Methodology
  • Why and when we need UMM

72
The UMM Meta-model
73
UMM - expanded
74
What can UMM give us?
  • Data in payloads, transport details in message
    envelope and verbs in BP artifacts.
  • Higher probability of interoperability between
    vocabularies.
  • Alignment of semantics.
  • Smart, re-useable processes.
  • A complete view of choreography and state.
  • A statement of intent.

75
What UMM means for a Registry
  • All UML relationships must be capable of being
    expressed in RIM (registry information Model).
  • UML diagrams stored in Registry (note What type
    of file?)
  • XMI can be used within Registry.
  • UML artifacts related to XML, EDI or other
    expressions of the SAME thing.

76
SOAs are
  • Event driven.
  • Platform neutral.
  • Service oriented.
  • Registry centric.
  • Payload agnostic.
  • Infrastructures.

77
Q A SOAs Break

78
Registry Functionality in Architecture
1300 1430
  • Functional Requirements

79
Goals of this Module
  • Explore the major facilities of a
    Registry/Repository System
  • Show how a Registry functions.
  • Examine relationship of registries to
    repositories
  • Tightly bound vs. loosely coupled models
  • Registry Interfaces for humans and applications.
  • Registry architecture (server-client models, API,
    security)

80
What is a Registry?
  • An XML registry is an infrastructure that enables
    the registration and discovery of services,
    ontology's or other artifacts for information
    sharing.
  • It is a neutral third party that facilitates
    dynamic and loosely coupled interactions.
  • A registry is available to organizations as a
    shared resource, often in the form of a web-based
    service.

81
Relationship of Registry standards
82
Content Management System (CMS)
  • Can manage any artifact throughout its entire
    lifecycle.
  • Does a better job for WS discovery than UDDI.
  • Allows sharing re-use.
  • Facilitates either Metadata OR instances.

83
Registry Architecture Examples
84
Registry Facilities
85
Registry Facilities (cont.)
86
Registry Facilities (cont.)
87
Discovery via a Registry
88
Client Server model
  • Life Cycle Management interface provides a
    collection of methods for managing objects within
    the Registry.
  • Query Management Interface that controls the
    discovery and retrieval of information from the
    Registry.
  • RC Registry Client
  • (Optional) Administrative Management manage
    users, accounts, etc beyond RIM.

89
Registry Architecture
Managed Objects
RIM
API
RSS Messaging
RSS Messaging
Registry Side
Client Side
90
XML Elements
  • XML elements can reference items from a Registry.
  • Examples
  • ltLastNamegt
  • ltNomDeFamillegt
  • ltNamegt
  • lt?gt
  • All are the same item!!!

91
Registry Item Examples
  • XML elements in business messages can reference
    items in a registry.
  • Examples
  • ltLastName UIDmyrep1236gt
  • ltNomDeFamille UIDmyrep1236gt
  • ltName UIDmyrep1236gt
  • lt? UIDmyrep1236gt
  • All are the same item!!!

92
Registry Usage for Metadata Look-up
  • XML Elements in document instances contain
    pointers to Repository Items.
  • Most Registry Items are metadata not instances
    of data.

lt?xml version1.0gt lt ? UIDFooRep12345gt Duane
lt/ ? gt
Document Instance
Registry
API
API
Managed object
Managed object
Managed object
93
Registry Actors
94
Registry Actor Relationships
95
UN/CEFACT Implementation Phase
96
UN/CEFACT Discovery Phase
97
Relationship of Registries-Repositories
  • One Registry can access several repositories.
  • De-centralized model means content does not have
    to reside on same server as Registry.
  • One Registry can use programmatic access or HTTP
    interface to point at content on another Registry.

98
Relationship of Registries-Repositories
Registry Client
Registry Server
RIM
Registry Client
Repository
Repository
Repository
99
Relationship of Registries-Repositories
Registry Client
Registry Server
RIM
Repository
Repository
Repository
100
Registry usage summary
  • Registries are agents for discovery
  • Repositories hold content
  • Relationship can be more than 11
  • Offer interfaces for actors
  • Permission based privileges
  • Agnostic to content
  • Audit trails and more..
  • Fundamental building blocks of a SOA!

101
Business Use Case for Registry
130 245
  • Functional Requirements

102
In Search of the Silver Bullet
  • Flexible Integration Tools
  • XML Syntax
  • Metadata Interchange (semantics?)
  • Internet Marketplaces
  • Standards (EDI, XML)
  • Published Interfaces in a Registry (ebXML or
    UDDI)
  • Low cost for coming online.

103
More Partners More Complexity
I ( n (n-1)) ( r (r-1))
I Integration work R number of systems N
number of applications
104
Registry-Centric Concept of Operations
SHIFT
SHIFT
Ad Hoc
105
Challenges of e-business today
  • XML initiatives underway for specific industries
  • attempts at verbatim translation of EDI to XML
  • Consensus required on common requirements
  • No core infrastructure means
  • Incompatibility
  • Reinvention the norm
  • Segregated pockets of communication

106
More than B2B
  • Use cases shared with non-eBusiness users.
  • Registries facilitate sharing of information
    across multiple domains.
  • eGovernment starting to rely on Registry (US,
    Korea, Australia, Hong Kong (2001-2)
  • Austria, Spain (2004).
  • CDC initiative for information sharing of disease
    outbreaks (Registry centric).
  • Security/Intelligence initiatives.

107
ebXML Registry Vision
  • A semantic registry is the key foundation block
    upon which global electronic business exchanges
    will be built.

K. Fessenden
108
Traditional EDI
Each arrow is a project
109
XML
More than 400 initiatives
110
Business Service Interface (BSI)
Profile
Profile
Profile
Profile
Profile
Profile
Profile
Profile
Need to Register a BSI to automate business
Connection across industry boundaries
111
BSI Approach Business Centric
Each participant needs to specify their own
Who, What, Why and How?
Standards parlance
Business Terms
Organisation(s) Industry / Service Business
process Context factors Transaction
interchanges Information details Messaging details
CPPA, WSDL, eCo BPSS, BPEL, WSCI etc. Metadata
Content Assembly XML content structure Semantics
Registry ebMS, CPA, WS-RM
112
Profile Registration Maintenance
Organisation Business process Information Technolo
gy
Own Capabilities and Requirements to trading
partners
Registry
Profile
113
Registry for Metadata Interchange
  • Allows tools to make use of semantic crosswalk
    mechanisms (easier integration of new and
    existing systems).
  • Easy to re-integrate if someone changes their
    BSI. (add one element?)
  • Exchanges can take a first step of checking to
    see if the BSI has changed.
  • Dynamic configuration possible in some cases.
  • Maintenance of existing relationships/interfaces
    more likely as primary use case.

114
Information Sharing Use Case
Canadian Law Enforcement Web Service
LE WS Registry
US Law Enforcement
115
Registry Supports Data Models
  • A Person has a XXXX Attribute.
  • Who asserts that information?
  • What Date was that information gathered (weight)?
  • What amount of trust do I place on that
    information?
  • What additional information MUST be associated
    with the assertion.

116
CPSIN Data Model
117
Standards Example Deployment
One View to User Organizations
Request Federation Make Associations Synch User
Groups Local content control
Federation Server
OAG Registry
Content Classification
STAR Registry
OAG
BOD's
STAR
Assemblies
STAR
BPS
OAG staff approve
Data
Dictionary
Data
Dictionary
Element Definitions
STAR staff
Transaction Assembly
Element Definitions
Transaction Assembly
118
Use Case Registry Driven eForms
119
E forms layers - Implementation
RequestForm() Validate() ConvertToXML() SendFormIn
fo()
Client Layer
End users
Registry
ValidateForm() UseFormInfo() Archive() ProcessForm
()
2nd Tier (Server) Layer
Government users
3rd Tier (Other Agency) Layer
ReceiveData() QueryRegistry() Archive() ProcessDat
a()
?? USERS
ReceiveData() QueryRegistry() Archive() ProcessDat
a()
Nth Tier (UnKnown Users) Layer
120
Implementation Sequence
Schema, DTD Registry UID Definitions
End User requests form
Build Form
Registry
Receive eForms data
Query for form structure
GUI
Process() Archive()
Info Server
Other Agencies
Nth Tier (UnKnown Users)
121
Receiving Unknown Data
  • When an application receives Data from an eForm
    that it does not understand, the UID can be
    resolved to dynamically write transformation or
    viewing templates.

Proprietary Data Format marked with UIDs
Data Transformation
Received data
Compliant XML Syntax XSL or CSS
Resolve UIDs From Registry
Registry
122
Eforms data and ROI
RequestForm() Validate() ConvertToXML() SendormInf
o()
No ROI / Small ROI
Client Layer
End users
ValidateForm() UseFormInfo() Archive() ProcessForm
()
2nd Tier (Server) Layer
Moderate ROI
Government users
3rd Tier (Other Agency) Layer
ReceiveData() QueryRegistry() Archive() ProcessDat
a()
Large ROI
?? USERS
Nth Tier (UnKnown Users) Layer
ReceiveData() QueryRegistry() Archive() ProcessDat
a()
123
The Many to Many Challenge
Trading Partners
Divisions of the Corporation
124
Goal Single face Solution
Trading Partners
entity
Single Interface
125
eForms workflow support.
  • A primary goal of many architectures.

126
eForms Publishing Processing
127
ROI for adoption of Registry driven eForms
  • Life Management of eForms requires no further
    integration at client.
  • Changes published in Registry are reflected
    instantly to 1,000s of forms.
  • Instance data is data type consistent with
    applications.
  • Registry Access control policy for instance data
    drives workflow.
  • Flexible classification schemes and context
    mechanisms promote reuse of metadata.

128
Assembly Mechanism
  • A Registry Use Case - Binding Data together

129
What is assembly
  • Meta-data to bind multiple objects together.
  • In UML, is often proprietary.
  • In ebXML, will likely be XML based.
  • Context specific assembly of Metadata.
  • Like a schema to create a schema (meta-metadata).
  • Supported by Registry/Repository.
  • Blueprint for creating a .xsd schema.
  • Work in progress within OASIS (CAM, UBL) and
    UN/CEFACT (CCTS).

130
Content Assembly
Courtesy of OASIS CAM
131
Assembly Scenario
Registry
XML Serializations
Content Assembly Document
Context
Assembly Utility
XML Schema
eForms, PDF, HTML etc.
Instance Data
132
Sample Assembly template
lt? xml version"1.0" ?gt ltAssemblyGuide
outputSyntax"W3CSchema"
ContentRegistry"http//ebxml.my-house.ca8080"gt
ltDataElement root"true" name"Being" gt
ltDataElement name"BeingTypeIdentifier"
useDataElement"0021-BeingTypeIdentfier.xm
l" /gt ltDataElement name"GenderIdentifier"
useDataElement"0014-GenderIdentifi
er.xml" /gt ltDataElement name"BeingBirthYear"
useDataElement"0020-BeingBirthY
ear.xml" /gt ltDataElement name"BeingBirthMonth
" useDataElement"0018-BeingBirt
hMonth.xml" /gt ltDataElement
name"BeingBirthDay"
useDataElement"0017-BeingBirthDay.xml"
/gt lt/DataElementgt lt/AssemblyGuidegt
133
Assembly explained
UML
XML
134
Registry supported Assembly
  • CAM guide will be fed into CAM application.
  • CAM application will make several round trips to
    the registry to get() the metadata fragments it
    needs to complete an Aggregation.
  • Will use Context as classification to retrieve
    correct registry Object (Data Element)
  • Most likely in XML.
  • CAM application will produce a context specific
    schema.

135
eForms Assembly
eForms Server
  • Receives data
  • Receives eForm template
  • Populates template
  • with data
  • Generates form
  • Signs form
  • Extracts content andmetadata
  • Archives statements

End user - eForms Presentation
Archiving Registryand Repository
Template Registryand Repository
eForms Design Tool (uses Assembly-type Documents)
Allows designers to quickly publish new eForms
136
Basic Architectural needs for eForms.
  • A Metadata Registry generally compliant with
    ISO/IEC 11179 (UDDI is not an option but can be
    used to find registry).
  • Registry uses a web service interface.
  • eForms application that can utilize a network
    connection to query a Registry.
  • eForms Design tool to build form metadata.
  • Data modeling experience.
  • eForms rendering tool
  • Secure reliable messaging system

137
Context
  • Context an essential element of defining
    semantics.

138
Context demonstrated.
  • 0 (What is this round shape?)
  • 4 5 0
  • 0ne m0re f0r the r0ad.
  • T0tal 0.36. (one concept two contexts)
  • Real world example for data
  • Monetary amount becomes
  • Invoice Total (in context of settlement, role of
    invoicer) or
  • PO total (in context of procurement, role of
    purchaser)

139
Context defines meaning
  • Stock what does it mean?
  • I called my broker to buy stock.
  • Making soup? Start with a good stock.
  • The rancher has lots of livestock.
  • Examples
  • YEAR (Core Component) becomes
  • BEING.BIRTH.YEAR (Business Information Entity)

140
Context Categories
  • Geo-political
  • Industry
  • Product
  • Official constraints
  • Business Process Role
  • Supporting Role
  • Systems Capabilities

141
Sample XML Context Declaration
lt?xml version"1.0" encoding"UTF-8"
?gt ltContextAssertion homeRegistry"http//ebxml.my
-house.ca8080"
value"urnuuid4a593056-3509-0766-2e7b-4e15403042
3f" gt lt!--Category ( Geopolitical
OfficialConstraint
ProcessRole SupportingRole
ProductClassification
IndustryClasification
SystemCapability )--gt
ltDeclaration category"Geopolitical"
qualifier"ISO-3166-2"
agencyURL"http//www.iso.org"
value"CA-ON" /gt ltDeclaration
category"IndustryClassification"
qualifier"NAICS-2002"
agencyURL"http//www.naics.org"
value"9221" commonName"Justice,
Public Order, and Safety Activities" /gt
ltDeclaration category"SystemCapability"
qualifier"ServiceOutputSyntax"
value"xml_schema_xsd" /gt lt/ContextAssertiongt
142
Registry support for Context
  • ebXML Registry Specification shows how RIM can be
    used to facilitate contextual classifications of
    Registry content.
  • Not yet supported in UDDI
  • ISO 11179 fully supports context as necessity for
    accurate data element classifications. Model
    ported to ebXML RIM 1.0.
  • Context Declarations can be submitted as content
    to Registry as Registry Objects of type type
    def (user defined).

143
Q A
  • Q A for day one.
  • Look forward to Day 2.
About PowerShow.com