Dev/omar/design
From Omar Wiki
Contents
|
Overview
This page is the root for all pages related to design documents for freebXML Registry:
- performance - The page on issues related to freebXML Registry performance.
- serverCache - The registry server cache design.
- serverPlugin - The registry server plugin design.
- typeExtensions - The class-level JAXR extension mechanism.
- SetStatusOnObject Protocol and UI - The new SetStatusOnObjects protocol
- Role Based Content Filtering Service
freebXML Registry Architecture
The following figure shows a simplified architecture of freebXML Registry:
[Image:
freebXML Registry Simplified Architecture]
The next few sections explain the architecture from top to bottom and left to right.
Registry Client Layer
Web Browser
A registry client may be a web browser which accessed the registry directly using the HTTP protocol using the registry's HTTP interface. Any registry content or metadata may be accessible via HTTP GET module access control using this method as defined by the HTTP Protocol Binding of ebXML Registry Protocols. This feature is alternatively referred to as "registry HTTP interface".
Web UI
A registry client may be a thin client Web UI that runs within a web container and is accessed via a web browser. The Web UI code running inside a web container uses JAXR API to access the registry.
An example of such a registry client is the freebXML Registry Web UI which is implemented using Java Server Faces (JSF). Note that in case of the freebXML Registry Web UI, the JAXR Provider and the registry server communicate via local calls within the same JVM. This behavior is configurable in OMAR and described under localCall Mode section within section on JAXR Provider.
Java UI
A registry client may be a fat client Java UI that runs on the client machine. Such a client uses JAXR API to access the registry in a manner similar to Web UI.
The freebXML Registry Java UI is an example of such a UI.
Admin Tool
The Admin Tool is a Command Line Interface (CLI) that provides a variety of admin functions. It aslo uses uses JAXR API to access the registry in a manner similar to Java UI.
SOAP Client
Not shown in the figure is a generic SOAP Client that accesses the registry using its SOAP interface directly. Such a client could be implemented in languages other than Java.
Registry Client API Layer
The next layer in the architecture is the registry client API layer.
JAXR API
The JAXR API is a standard Java API for XML registries and is the chosen API for freebXML Registry. The JAXR API provides the standard Java interfaces defined by the JAXR specifications. The JAXR API is provided by Sun's JWSDP download. The JAXR API requires an implementation, referred to as "JAXR Provider", in order to be useful and functional.
Several members of the freebXML Registry team are original authors of the JAXR specification. The spec lead for JAXR API is a member of the freebXML Registry team.
The following figure shows a simplified architecture of JAXR API:
[Image:
JAXR API Simplified Architecture]
JAXR Provider
The freebXML Registry provides its own JAXR Provider which is an advanced implementation of JAXR API.
Ideally JAXR client applications should only depend upon JAXR API. However, in freebXML Registry clients sometimes need to depend upon implementation classes within the JAXR Provider in order to access new features that are planned for next generation of JAXR API (JAXR 2.0).
The freebXML Registry JAXR Provider implements JAXR API methods to communicate with freebXML Registry server using the ebXML Registry 3.0 standard protocol. The JAXR Provider uses JAXB:
- To generate ebXML Registry Protocol request messages to send to the registry server and
- To process ebXML Registry protocol response messages received from the registry server
Several members of the freebXML Registry team are original authors of the ebXML Registry standard. The Editor for ebXML Registry specifications is a member of the freebXML Registry team.
The following figure shows how JAXR a JAXR Provider typically works:
[Image:
JAXR Theory Of Operation]
localCall Mode
The freebXML Registry JAXR Provider supports a special feature called the locallCall mode. When this mode is set to default value of "false", then all communication between JAXR Provider and registry server is via ebXML Registry protocol over SOAP 1.1 with attachments.
When localCall mode is set to "true" as is the case with the Web UI, then an optimization occurs which bypasses the SOAP communication and instead communicates via local method calls directly from JAXR Provider to the QueryManager and LifeCycleManager interfaces defined by the registry server.
freebXML Registry Server
In the figure, the freebXML Registry server sits below the JAXR Provider. The server is typically deployed and runs within a web container such as tomcat or a commercial J2EE server such as Sun Java Enterprise System Application Server.
Registry Vs. Repository
See FAQ entry.
- Repository
- Contains any type of electronic content such as: XML Schema, XML Instance, WSDL, GIF image...
- A content instance in the Repository MUST have an associated metadata instance in the Registry
- Registry
- Contains metadata instances
- Metadata instance describes a content instance or another metadata instance
- Metadata instances enable discovery of content
HTTP Interface
As required by ebXML Registry standard, the freebXML Registry Server exposes an HTTP interface that enables accessing registry content and metadata using HTTP GET via an HTTP URL. For details see the [ebRS] specifications.
Note that the freebXML Registry Server HTTP interface provides a binding only to the QueryManager interface of the registry. This means the HTTP GET access is only supported for queries and specifically not supported for publish functionality.
The HTTP interface implementation within the registry server, uses JAXB to process the ebXML Registry protcol request message and to generate HTTP response containing the [ebRIM] object instances matching the query.
SOAP Interface
As required by ebXML Registry standard, the freebXML Registry Server exposes a SOAP 1.1 with Attachemnets interface to both the QueryManager and LIfeCycleManager interfaces of the registry. For details see the [ebRS] specifications.
The SOAP Interface of the registry server uses SAAJ for processing the SOAP message. It uses JAXB to process the ebXML Registry protcol request message and to generate the the ebXML Registry protcol response message.
QueryManager Interface
The Querymanager interface provides access to browsing and discovery capabilities using the standard AdhocQuery protocol defined by [ebRS].
- Queries may be pre-defined or application specific
- Query syntax may be:
- SQL 92 (preferred query syntax, used pervasively in freebXML Registry)
- XML Filter Query syntax (discouraged, used rarely in freebXML Registry)
- Queries may be ad hoc queries using predicate conjunction, disjunction, negations etc.
- Content based queries may be used in combination with content cataloging feature to discover artifacts based on metadata that was cataloged automatically from content. Examples:
- Find me all images that are color images
- Find me all images that are greater than 10cm x 15cm
- Queries map be parameterized and stored queries within the registry server as metadata of type AdhocQuery
- Web UI and Java UI allow mapping stored parameterized queries to Search Forms where each query param maps to a form field. This technique is used to hide potential query complexity from users.
Unauthenticated clients MAY access the QueryManager interface. However, such clients will only be able to see public content and metadata within the registry.
LifeCycleManager Interface
This interface provides access to publish capabilities using various standard ebXML Registry protocol defined by [ebRS]:
- SubmitObjectsRequest Protocol: Used to publish content and metadata
- UpdateObjectsRequest Protocol: Used to update content and metadata
- ApproveObjectsRequest Protocol: Used to approve content and metadata
- DeprecateObjectsRequest Protocol: Used to deprecate content and metadata
- UndeprecateObjectsRequest Protocol: Used to undo a previous deprecation of content and metadata
- RemoveObjectsRequest Protocol: Used to delete content and metadata
- RelocateObjectsRequest Protocol: Used to relocate content and metadata from one registry to another
Unauthenticated clients cannot access the LifeCycleManager interface as it requires authenticated access.
Authentication
Upon receiving a request the first thing the registry server does is perform authentication to determine the identity of the user that is making the request.
A registry client may authenticate with the registry server as defined by [ebRS, ebRIM]. Authentication is done using X509 digital certificates. A user MUST previously register with the registry server using Java UI or Web UI user registration tool. During registration, the client's public key certificte is made known to the server (and stored within its server keystore). When a user sends a request signed by the corresponding private key, the registry server can determine the identity of the user making the request.
In case of SOAP based communication:
- The JAXR Provider uses XWSS API from JWSDP to perform signing of the outgoing request to the server.
- Upon receiving the request, the server uses XWSS API to verify the digital signature.
- The server signs the response using XWSS API when sending the response back, if configured to do so.
- The JAXR Provider verifies the response using XWSS API, if configured to do so.
In case of Web UI where localCall=true is used there is no SOAP based communication and the JAXR Provider makes direct calls into methods of server QueryManager and LifeCycleManager interfaces. In case of Web UI the communication between browser and web container is done using HTTPS and SSL Mutual Authentication using the user's certificate and the certificate associated with the registry (actually associated with its special user named RegistryOperator).
Authorization
Once the server has authenticated an incoming request, next it performs authorization checks for the request using the authetication credentials determined from the authentication steps.
XACML Access Control Policies
Authorization is done using access control policies that govern the request and take as input:
- Subject Attributes: The attributes about the user bvased on Authentication credentials
- Resource Attributes: The attributes associated with the metadata object being accessed
- Action Attributes: The attributes associated with the action being performed.
Subject Attributes
These include the following Subject Attributes:
- Subject id: The identity of the User
- SubjectRoles: The roles assigned to the user
- SubjectGroups: The groups to whom the user has been assigned (functionally similarto roles)
Resource Attributes
These include almost any attribute defined by [ebRIM] on a RegistryObjects.
Action Attributes
These include almost any attribute defined by [ebRIM] on a Action. Typically this is just an id that identifies an ACTION such as Create, Update, Deprecate, Undeprecate, Delete etc.
Persistence
The abstract Persistence layer is responsible for storing content and metadata to a persistent store and providing CRUD access to it.
SQLPersistenceManager Interface and SQLPersistenceManagerImpl
The SQL PersistenceManager interface provides an abstract interface for using an RDBMS and SQL-92 to provide persistence for the registry server. It has an implementation class SQLPersistenceManagerImpl which provides a concrete implementation over RDBMS sing JDBC 3.0.
The DAO Classes
Not shown in architecture diagram are some 20 classes named XxxDAO where Xxx maps to a class defined by [ebRIM]. These classes provide CRUD support for the corresponding RIM class using an RDBMS and JDBC 3.0
RepositoryManager Interface and RepositoryManagerImpl
The RepositoryManager interface provides an abstract interface for using an RDBMS and SQL-92 to provide persistence for the RepsositoryItems within the registry server. It has an implementation class RepositoryManagerImpl which provides a concrete implementation over RDBMS sing JDBC 3.0. The RepositoryManagerImpl currently uses Hibernate to access the RDBMS. However, this will be changed such that it would use SQLPersistenceManagerImpl and DAO classes to access the RDBMS in future when we remove Hibernate from freebXML Registry.
Relational Database Management System (RDBMS)
This is the relational database that actually stores content and metadata for freebXML Registry while providing ACID transactional charateristics. The registry server's Persistence layer uses JDBC 3.0 to access the RDBMS. Most SQL-92 and JDBC 3.0 compliant RDBMS are supported. The default database for freebXML Registry is Apache Derby. By defaut Derby runs in embedded mode within the same JVM as the registry server. This can be changed via configuration of Derby.
Issue: What is the highest performing Derby mode for registry?
Links
[ebRS, ebRIM]ebXML Registry 3.0 Specifications Bundle (OASIS Approved Standard)
[ebRRWebinar] OASIS ebXML Registry 3.0 Webinar 2005 Slides:
[JAXR] Java API for XML Registries
