320 likes | 325 Views
This presentation provides an overview of the new features and updates in ebXML Registry Version 3.0, including HTTP Protocol Binding, Content Management Services, Cooperating Registries, Event Notification, and Security Enhancements.
E N D
ebXML Registry Version 3.0 Overview Joseph M. Chiusano Booz Allen Hamilton Federal XML Community of Practice (xmlCoP) Meeting Washington, DC March 16, 2005
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
NOTE: A star to the left of a feature indicates that it will be covered during this presentation. ebXML Registry Version 3.0: What’s New
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 CommitteeTechnical 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
Publish/maintain/discover information artifacts Manage information artifacts, enforce conformity rules, cataloguing, custom queries, WCM Interoperability between autonomous ebXML registries Information Artifacts Registry Content Management Federated Architecture ebXML Registry Secure Architecture Standard Metadata Identifiers, Description, Classification, Association, Version Info, etc. DSIG, Role-Based Access Control, Audit Trail Event Bus Enable workflow using Content-Based Event Notification Major ebXML Registry Features at a Glance Source: “The UN/CEFACT Registry/Repository Architecture” presentation
ebXML Registry Version 3.0: Simplified View of Architecture Source: ebXML Registry Services and Protocols Committee Draft, 10 February 2005
= highlighted during discussion The following class diagram represents the ebXML Registry Information Model (ebRIM) Source: ebXML Registry Information Model Committee Draft, 10 February 2005
“QueryManager” interface “getRegistryObject” method 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 Parameter
Trading Partner #2 Trading Partner #1 (Effective) UDDI Registry (Actual) ebXML Registry WSDL Document WSDL Document The HTTP Binding protocol has been presented as a foundational mechanism for interoperability between ebXML Registry and UDDI • 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
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
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)
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”
The following is an example of cataloging a WSDL document according to the fact that it has a SOAP binding • ClassificationSchemes used: • ExtrinsicObject • XML Schema • User Manual • WSDL • WSDL 1.1 Bindings • HTTP • MIME • SOAP over SMTP • SOAP over HTTP <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>
Registry D Registry E Registry B Registry A Registry C NOTE: Arrows are conceptual, and are not meant to depict physical connections. 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 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
“FIND ALL SCHEMAS FOR STANDARD X” Schema #1 Schema #2 Schema #3 Schema #n ebXML Registry #2 ebXML Registry #3 ebXML Registry #n ebXML Registry #1 . . . . A federated query operates on data that belongs to all members of the federation • Example:
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
Subscription to events is done through preconfigured AdHocQuery “selectors” that denote the subscription criteria • 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 SELECT * FROM Service s, AuditableEvent e, AffectectedObject ao, Classification c1, Classification c2 ClassificationNode cn1, ClassificationNode cn2 WHERE e.eventType = 'Created' AND ao.id = s.id AND ao.parent=e.id AND c1.classifiedObject = s.id AND c1.classificationNode = cn1.id AND cn1.path = 'Security' AND c2.classifiedObject = s.id AND c2.classificationNode = cn2.id AND cn2.path LIKE '%Liberty Alliance%' SQL Query
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
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
Contact Information • Joseph M. Chiusano • Booz Allen Hamilton • McLean, VA • (703) 902-6923 • chiusano_joseph@bah.com
OASIS ebXML Registry Information • OASIS ebXML Registry TC Home Page: • http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep