Role of Registries in Service Oriented

1

• Role of Registries in Service Oriented
• Architecture
• Jan 15, 2004 San Diego

Duane Nickull Senior Standards Strategist, Adobe
Systems, Inc.
2
Introduction Duane Nickull

• Senior Standards Strategist, Adobe Systems Inc.
• Team Lead (2001-2003) United Nations/CEFACT
  eBusiness Architecture Group.
• Chair (2002-2003) UN eBusiness Working Group.
• Former Co-lead/Chief Editor - ebXML Technical
  Architecture v 1.0
• Worked on W3C Web Services Architecture, LE -
  XTract TM architecture various Government
  Security/Justice initiatives.
• Co-inventor of GoXML Search Contextual XML
  Search engine
• UN/CEFACT OASIS Joint Coordination Committee
  Special Technical Liaison W3C.
• International SME Registry/Repository

3
Integration Problem area

• Limited justice system integration (National)
• Limited international sharing of intelligence
  information.
• Information sharing is hindered at many levels
  (Zachman Network, Motivation, Function, People
  and Data)
• Einstein quoteintegration?
• Service Oriented Architecture (SOA) is an
  infrastructure to facilitate interoperability.
  Use 1.. Data models.

4
Service Oriented Architecture Overview

• Modern Service Oriented Architectures (SOAs) use
  registry systems (W3C Web Services Architecture,
  ebXML et al).

5
SOA Layer Decomposition
SLA
Supported Business Process
1..
ltltReferencesgtgt
XML Data Dictionaries
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
context
6
What is a Registry/Repository?

• A Registry is an infrastructure component that
  enables the registration and discovery of
  services, ontology's or other artifacts.
• Neutral third party that facilitates
  interactions.
• A shared resource, often in the form of a
  web-based service.
• Can aid in solving many integration problems.

Repository
Registry
Synchronization
RIM
I / O
API
7
Relationship of Registry standards
8
Registry can provide registration
Intent/Policy
A G E N C y

• AND MUCH MORE
• Customer Services
• Process Automation Services
• Business Management Processes
• Digital Asset Services
• Business Analytical Services
• Back Office Services
• Support Services

Service choreography
Data Model
Service interface
Registry
Physical network
9
Justice Registry Prototype use caseA Government
of Canada pilot justice initiative.
9/25
10
Goals and Wish List.

• Develop a library of re-useable data elements
  (similar to DoJ XML Justice Dictionary)
• Share the Data Elements from a registry/repository
  .
• Develop a methodology for process modelers to use
  the data elements to build transactions within
  their exchanges (Similar to JIEM).
• Maintain and manage the library over time
  (Registry centric methodology).
• Integrate with the international community (long
  term).
• JIT privilege-based integration (long term).

11
Justice Data Dictionary goals
Harmonization!
2003
2002
2001
2000
Existing Standards
RCMP
XML
Courts
Corrections
Justice
ON
NPB
Customs
12
CPSIN IJI Logical Data Model
13
CPSIN Data Model
Case
Process
Disposition
Activity
Event
Charge
responsible agency
place of trial
suspect
Object Role
exhibit
defendant
weapon
Organization
Property
Person
Location
Object
Object Affiliation
owns
has
found at
CPSIN Canadian Public Safety Information Network
14
Registry expresses CPSIN Data Models

• A Data Element has an Attribute.
• What Agency asserts that information?
• What Date was that information gathered?
• How are instances of that information classified?
• What amount of trust do I place on that
  information (Registry Audit Trail)?
• What additional information MUST be associated
  with the assertion? Events MUST have an Agency
  who asserts them.
• Context can be asserted via Registry.
• Roles and permission based access.
• Complete Data Dictionary Management, versioning,
  event notifications, user defined ontology's and
  more.
• Complexity of todays data models REQUIRE
  Registry to manage them.

15
CPSIN IJI Data Elements (examples)

• Being
• Being identifier
• Event
• Event type
• Event date
• Event identification code
• Agency
• Agency identifier
• Agency case number
• Etc

16
Building Transactions with Data Elements
17
Information Sharing Use Case 1
Canadian Law Enforcement Web Service Interface
Law Enforcement Registry
US Law Enforcement
All transactions assembled from Data dictionary
in Registry.
18
Event Notification - Use Case 2
Canadian Law Enforcement
Canadian Registry
US Law Enforcement
19
Registry eForms Architecture

• Registry enablement of Dynamic User interfaces
  and workflow.

20
Why Registry driven eForms?

• ROI is very high.
• Logical extension next step to Data Dictionary.
• eForms are common user interfaces to SOAs.
• Users familiar with many types of eForms (HTML,
  PDF etc) built on XML data models.
• Abstracts View from Model and Control (MVC
  Philosophy).
• Good data capture with integrity checks.
• Justice/Law Enforcement depends on integrity of
  data captured. eForms facilitates.

21
Registry driven eForms consumers of XML data
dictionaries.

• Life Management of eForms requires no further
  integration at client/user.
• Changes published in to XML data model in
  Registry are reflected instantly to 1,000s of
  forms/presentations. Real time system.
• Instance data is data type consistent with
  applications. XML Data models use W3C Schema Data
  types.
• Registry access control policy for instance data
  drives workflow based on model.
• Flexible classification schemes and context
  mechanisms promote management of data models.

22
eForms Architecture
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/XML Data Model Registryand Repository
Allows designers to quickly publish new eForms
based on XML Data Models. Permissions based
system tight security.
eForms Design Tool uses XML Data Elements
23
Registry Driven eForms Sequence
Schema, DTD Registry UID Definitions
requests form template
Build Form
Registry
Receive eForms data
Query for form structure
GUI
Registry
Process() Archive()
Info Server
Other Agencies
Nth Tier (UnKnown Users)
24
Conclusions

• Registry Driven SOAs, developed for eBusiness,
  work well for data integration.
• Registry is the heart of modern SOAs.
• Registry agnostic to Objects. Any Object
  allowed. Supports new bread of Smart software.
• Advanced, semantic content management helps
  facilitate complete integration.
• Flexible, scalable taxonomy and ontology
  management.
• Multi-layered security model compliant with many
  requirements.

25
Justices unique challenges

• Archive format Registry Archive format
  integrity and audit trail.
• Security Registry queries (USAF)
• Legislative
• Multi-lingual support (GoC EN FR)
• Discussions?

26
Q A
References CPSIN IJI - Canadian
Government ed.buchinski_at_tbs-sct.gc.ca (613)
957-2497 Registry Products - Duane Nickull
dnickull_at_adobe.com [phone]

27
Supplemental Slides

• Data Harmonization

28
Data Model Harmonization

• Harmonizing the Data model is a logical step.
• Old models were driven by bottom up approach
  (take a common intersection of what all agencies
  have)
• New models are driven by top-down approach (What
  do the stakeholders need to mine from the
  instance data)
• Separating presentation of documents from
  structure and logic important (Think MVC)
• Supported by Registry!

29
Examples of old data models

• A relic of legacy data capture techniques.
• Does not scale for aggregation models
• Modern use cases for instance data never
  envisioned

30
Aggregation/Reconciliation Issues

• How to rely on information that
  contradicts/conflicts?
• Different masks
• Different code sets
• Assertion integrity
• Dates of events
• Data capture techniques
• Agency audit trails
• More

31
New Smart Justice Object Model