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.