0 federal xml community of practice (xmlcop) meeting washington, dc march 16, 2005 ebxml registry...
TRANSCRIPT
1
Federal XML Community of Practice (xmlCoP) Meeting
Washington, DCMarch 16, 2005
ebXML Registry Version 3.0 Overview
Joseph M. Chiusano
Booz Allen Hamilton
2
What We’ll Cover
ebXML Registry Version 3.0: What’s New
ebXML Registry Brief Overview
Version 3.0: New Features
– HTTP Protocol Binding
– Content Management Services
– Cooperating Registries
– Event Notification
– Security Enhancements
Questions
3
ebXML Registry Version 3.0: What’s New
4
ebXML Registry Version 3.0: What’s New
Feature Description
HTTP Protocol Binding Web Browser client to access to registry using HTTP 1.1 protocol
Simple content retrieval
Registry Managed Version Control Robust version control mechanisms based on the DeltaV/WebDAV protocol
Query Enhancements Iterative query support
Parameterized stored queries
Improved Filter Query syntax
Content Management Services Content validation
Content cataloging
Content-based discovery
Cooperating Registries Support Distributed content/metadata
Federated queries
Replicated content/metadata
Object relocation
Event Notification Publish/subscribe capabilities
NOTE: A star to the left of a feature indicates that it will be covered during this presentation.
5
ebXML Registry Version 3.0: What’s New (cont’d)
Feature Description
Security Enhancements XACML-Based Access Control Model
SAML-Based Federated Identity Management
Compliance with WS-I Basic Security Profile 1.0
OASIS Web Services Security (WSS) Support
Improved Extensibility Easier to define new types of requests and responses
Improved Identifiers Human-Friendly URN-based Identifiers
6
ebXML Registry Brief Overview
7
The ebXML Registry standard is a metadata registry standard that supports the registration, maintenance and discovery of both XML- and non-XML artifacts
An ebXML Registry is an information system that securely manages any content type and the standardized metadata that describes it
The ebXML Registry version 1.0 standards were developed during the OASIS/UNCEFACT Electronic Business XML (ebXML) initiative and approved in May 2001
The OASIS/ebXML Registry Technical Committee Technical Committee continues to develop the ebXML Registry standards
– The ebXML Registry version 2.0 standards are OASIS approved and ISO approved standards (ISO 15000-3 and ISO 15000-4)
Work on ebXML Registry Version 3.0 began in January 2002
– Version 2.5 (OASIS Committee Draft, June 2003) included some Version 3.0 features in their early forms
The ebXML Registry version 3.0 specifications are OASIS Committee Drafts as of 10 February 2005
– They are in OASIS Public Review until 14 March 2005
8
Major ebXML Registry Features at a Glance
Source: “The UN/CEFACT Registry/Repository Architecture” presentation
Federated Architect
ure
Standard Metadata
Event Bus
Secure Architecture
ebXML Registr
y
Manage information artifacts, enforce conformity rules,
cataloguing, custom queries, WCM
Interoperability between autonomous ebXML
registries
DSIG, Role-Based Access Control, Audit Trail
Identifiers, Description,
Classification, Association,
Version Info, etc.
Enable workflow using Content-Based Event Notification
Information Artifacts Registry
Publish/maintain/discover information artifacts
Content Manageme
nt
9
ebXML Registry Version 3.0: Simplified View of Architecture
Source: ebXML Registry Services and Protocols Committee Draft, 10 February 2005
10
The following class diagram represents the ebXML Registry Information Model (ebRIM)
= highlighted during discussionSource: ebXML Registry Information Model
Committee Draft, 10 February 2005
11
Version 3.0: New Features
12
HTTP Protocol Binding
13
The HTTP Binding protocol provides multiple options for accessing RegistryObjects and RepositoryItems via the HTTP 1.1 protocol
Sample “getRegistryObject” request:
GET /http?interface=QueryManager&method=getRegistryObject¶mid=
“{URN_OF_REGISTRY_OBJECT}” HTTP/1.1
Can also retrieve RepositoryItem using “getRepositoryItem” method
“QueryManager” interface “getRegistryObject” method Parameter
14
The HTTP Binding protocol has been presented as a foundational mechanism for interoperability between ebXML Registry and UDDI
UDDI Registry ebXML Registry
Trading Partner #1 Trading Partner #2
(Actual)
(Effective)
WSDL Document
WSDL Document
The ebXML Registry and UDDI HTTP bindings can enable “reach-through” capabilities from one registry type to another:
Source: “UDDI and ebXML Registries: A Three-Tier Vision”, ebXML Forum, September 2003
15
Content Management Services
16
Content Management Services enable improved quality, integrity and discovery of content and metadata within ebXML Registry
Content Validation: Provides the ability to enforce domain-specific validation rules upon submitted content and metadata, in a content-specific manner
– Improves the quality and integrity of registry content and metadata
– Submission requests that contain invalid data are rejected in their entirety by the registry, with a “ValidationException” returned
Content Cataloging: Provides the ability to selectively convert submitted RegistryObjects and RepositoryItems into ebRIM-defined metadata, in a content-specific manner
– Enables content-based discovery within the registry
– Cataloging automatically creates and/or updates RegistryObject metadata such as ExtrinsicObject or Classification instances
– The cataloged metadata enables clients to discover the registry content and metadata using standard query capabilities of the registry
17
Content Validation utilizes one or more Content Validation Services to automatically validate RegistryObjects and RepositoryItems when they are submitted to the registry
This process is shown in the following figure:
Potential use cases include:
– Validation of XML instance documents against their schema upon submission to the registry (e.g. Compliance with DOJ GJXDM or NIEM)
– Enforcement of consistency rules and semantic checks when a business process definition is submitted to the registry (e.g. HL7 business process definition)
18
Content Cataloging utilizes one or more Content Cataloging Services to automatically catalog RegistryObjects and RepositoryItems when they are submitted to the registry
This process is shown in the following figure:
Potential use cases include:
– Find all XML schemas that have a targetNamespace containing “www.epa.gov”
– Find all WSDL documents that have a SOAP binding defined
– Find all Basic Core Components (BCCs) that are part of an Aggregate Core Component (ACC), that is the basis for an Aggregate Business Information Entity (ABIE) whose Geopolitical context equals “European Union”
19
The following is an example of cataloging a WSDL document according to the fact that it has a SOAP binding
<definitions name="StockQuote" xmlns="http://schemas.xmlsoap.org/wsdl/ ….>
<message name="GetTradePriceInput"> <part name="tickerSymbol" element="xsd:string"/>
<part name="time" element="xsd:timeInstant"/> </message>
<message name="GetTradePriceOutput"> <part name="result" type="xsd:float"/> </message>
<portType name="StockQuotePortType"> <operation name="GetTradePrice"> <input message="tns:GetTradePriceInput"/>
<output message="tns:GetTradePriceOutput"/> </operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetTradePrice"> [details removed for example]
</operation> </binding>
<service name="StockQuoteService"> [details removed for example] </service> </definitions>
ClassificationSchemes used:
• ExtrinsicObject – XML Schema– User Manual– WSDL
• WSDL 1.1 Bindings – HTTP– MIME– SOAP over SMTP– SOAP over HTTP
20
Cooperating Registries
21
The Cooperating Registries feature enables multiple ebXML registries to cooperate with each other as part of a “federation”
A registry federation is a group of registries that have voluntarily agreed to form a loosely coupled union
This enables operations such as:
– Cross-registry associations
– Federated queries
– Local caching of data from another registry
– Object relocation
Registry D
Registry E
Registry B
Registry A
Registry C
NOTE: Arrows are conceptual, and are not meant to depict physical connections.
22
Registry federations are based on a peer-to-peer (P2P) model where all participating registries are equal
A federation may be based on common business/domain interests and specialties that the registries might share
– Examples:
Federation of registries for the criminal justice domain
Federation of registries among universities
Replication of RegistryObjects in other registries within a federation can improve access time and fault tolerance through local caching of remote objects
– Involves creation of a “local replica”
Replicas may be kept current using the event notification feature, or through periodic polling
23
A federated query operates on data that belongs to all members of the federation
Example:
“FIND ALL SCHEMAS FOR STANDARD X”
ebXML Registry #2
ebXML Registry #1
ebXML Registry #n
. . . . ebXML Registry #3
Schema #1 Schema #2 Schema #3 Schema #n
24
Event Notification
25
The Event Notification feature enables an ebXML registry to notify its users and/or other registries about “events of interest”
Also known as “publish/subscribe”
Examples of “events of interest” are:
– A RegistryObject that the user submitted has been subscribed to by a registry user
– An XML schema that a registry user has subscribed to has been updated
– A new Web Service has been submitted that relates to a topic in which a registry user has interest
The Event Notification feature uses “content-based” notification, in which interests are expressed in the form of a query over registry content
– This differs from “topic-based” notification, in which interests are tied to topics by which information is categorized
Notifications are triggered in response to “AuditableEvents” that are created within the registry in response to client-initiated requests and changes in the life cycle of a RegistryObject
– Example: Creation or deletion of a RegistryObject
26
Subscription to events is done through preconfigured AdHocQuery “selectors” that denote the subscription criteria
SELECT * FROM Service s, AuditableEvent e, AffectectedObject ao,Classification c1, Classification c2ClassificationNode cn1, ClassificationNode cn2 WHEREe.eventType = 'Created' AND ao.id = s.id AND ao.parent=e.id ANDc1.classifiedObject = s.id AND c1.classificationNode = cn1.id ANDcn1.path = 'Security' ANDc2.classifiedObject = s.id AND c2.classificationNode = cn2.id ANDcn2.path LIKE '%Liberty Alliance%'
Example: Request notification if a security service is submitted to the registry, and it implements the Liberty Alliance specifications:
“Find all services that are Created and classified by ClassificationNode where ClassificationNode’s Path equals “Security”, and classified by ClassificationNode where ClassificationNode’s Code
contains string “Liberty Alliance”
Notification of events can be done through two mechanisms:
– Web Service-Based Notification: Delivery of event notifications through invocation of a specified listener Web Service
– Email-Based Notification: Delivery of event notifications via email to a human user or an email endpoint for a software component or agent
SQL Query
27
Security Enhancements
28
ebXML Registry Version 3.0 supports OASIS XACML 1.0 for its Access Control Information Model
XACML (eXtensible Access Control Markup Language) defines a standard mechanism for expressing access control policies
XACML is based on three main concepts:
– Subject: An entity (human or system) that requests access to a resource (interaction with SAML)
– Resource: A data, service, or system component to which access is requested
– Action: An operation on a resource (such as “read”)
ebXML Registry can function as both an XACML Policy Enforcement Point (PEP) and a Policy Decision Point (PDP)
Access control is on both RegistryObjects and RepositoryItems
Every RegistryObject is associated with exactly one Access Control Policy that governs “who” is authorized to perform “what” action on that RegistryObject
ebXML Registry can also function as an XACML Policy Store
– Manage policies for protecting resources outside the registry
29
ebXML Registry Version 3.0 also supports Federated Identity Management based on OASIS SAML 2.0
SAML (Security Assertion Markup Language) defines a framework for communicating security and identity information between IT systems in a standard manner
– Provides Single Sign-On (SSO) capabilities for user-to-system, system-to-system, and service-to-service communications
SAML expresses security information in the form of assertions about subjects
– An assertion is a declaration of certain facts, such as “John Smith was granted update privileges to database X at time Y”
– A subject is an entity (either human or computer) that has an identity in some security domain
The SAML Protocol defines 2 primary entities:
– Service Provider: An entity that provides services to Principals
– Identity Provider: A type of service provider that creates, maintains, and manages identity information for Principals
An ebXML Registry can function as a SAML Service Provider
– Allows the registry to utilize an Identity Provider to perform client authentication on its behalf
– Avoids duplication of Identity Provider user database within registry
30
Questions?
32
OASIS ebXML Registry Information
OASIS ebXML Registry TC Home Page:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep