This document covers the following topics:
The CentraSite registry supports the JAXR information model. Physically, the registry resides in a single XML database that can be accessed using XQuery, UDDI or JAXR-based client APIs.
A JAXR-based registry is built around a generic, but extensible object called a RegistryObject. The RegistryObject class defines a minimal set of metadata and provides methods that enable an object to be classified and associated with other objects in the registry.
Although the metadata that RegistryObject specifies is very minimal (Name, Description and Key), it can be dynamically extended to incorporate additional metadata. By extending the RegistryObject, one can model and catalog virtually any type of artifact in an SOA environment.
The object types that make up the CentraSite registry are all extensions of the basic JAXR RegistryObject class.
In general, CentraSite's information model consists of system-related objects, which support the administration and management of the registry, and assets, which represent the artifacts in your SOA.
System-related objects include objects such as organizations, users, groups, roles, taxonomies, policies and lifecycle models. These type of objects do not appear in the catalog, however they play a key role in managing its content.
The organization object in particular plays a major role within the registry. Under the registry's information model, any object that is not an organization must be associated with an organization object.
CentraSite is installed with one predefined organization. When the administrator of this organization creates users (which are represented by user objects in the registry), CentraSite automatically associates those user objects with the administrator's organization. Similarly, when those users subsequently create objects in the registry, CentraSite associates those objects with the user's organization.
When users work with CentraSite, they see only the registry objects that belong to their organization. Because organizations restrict users to the portion of the registry that "belongs" to their organization, they provide a way to, in effect, partition CentraSite into multiple, logical registries.
Note:
When necessary, it is possible to share objects between
organizations. Using permissions, one can give a group of users in another
organization permission to access a specific data object. Additionally, there
are certain types of objects (such as Policies) that can be made globally
available to all organizations. In both cases, however, the organization in
which the objects were originally created maintains "ownership" of the shared
objects.
For a complete description of each of the system-related object types in the CentraSite information model, see the document Object Type Management.
Assets refer to registry objects that represent the artifacts in your SOA. As installed, the CentraSite registry supports four asset types (Services, XML schemas, BPEL processes and Application Servers). Because these asset types are based on the JAXR extensible RegistryObject, you can customize the amount and type of metadata that CentraSite maintains for each type. You can also create additional asset types as necessary. For a complete description of the installed asset types and information about defining additional asset types, see the document Object Type Management.
In JAXR, relationships are modeled using Association objects. Internally, CentraSite uses these objects extensively to establish relationships between many system-related objects in the registry. For example, Associations are used to relate an organization to its set of registry objects. CentraSite automatically generates and maintains these types of underlying associations when you create or modify system-related objects using CentraSite GUIs or APIs.
Besides the implicit relationships that CentraSite maintains for system-related objects, CentraSite also allows you to explicitly establish relationships between registry objects through the use of relationship attributes. A relationship attribute is part of an object's metadata.
An object can have many relationship attributes reflecting the many types of relationships it has with other objects. For example, a Web service asset might include a relationship attribute called "Uses", which relates the service to its constituent artifacts (i.e., assets that it uses or otherwise depends upon). The same asset might also include a relationship attribute called "Used By" which relates the service to its dependents.
Relationship attributes can be predefined or ad hoc. Predefined relationship attributes are ones that are part of an asset's type definition. When a relationship attribute is predefined, the attribute is present in all assets of that type. Ad hoc relationships are ones you can create as necessary for an individual instance of an asset.
For more information about defining relationship attributes, see the document Object Type Management.
