All ATG repositories provide a means for representing information in a data store as Java objects. The composite repository lets you use more than one data store as the source for a single repository. The composite repository consolidates all data sources in a single data model, making the data model flexible enough to support the addition of new data sources. Additionally, the composite repository allows all properties in each composite repository item to be queryable. Thus, from the point of view of your ATG application, the composite repository presents a consistent view of your data, regardless of which underlying data store the data may reside in.
The composite repository is a repository that unifies multiple data sources. Its purpose is to make any number of repositories appear in an ATG application as a single repository. The composite repository defines a mapping between item descriptors and properties as they appear to facilities that use the composite repository and item descriptors and properties of the data models that comprise the composite data model. A composite repository is composed of any number of composite item descriptors. Each item descriptor can draw on different data models from different repositories, and map underlying data model attributes in different ways.
Use Example
Suppose you maintain profile data both in an SQL database and an LDAP directory. ATG’s profile repository ships with a user composite item descriptor comprised of just one primary item descriptor and no contributing item descriptors. The primary item descriptor is the user item descriptor. You can add to the composite item descriptor the user item descriptor from the LDAP repository as a contributing item descriptor. If there are any property name collisions between the SQL repository and the LDAP repository, you can resolve them by mapping the properties explicitly to different names in the composite repository configuration. After you’ve done this, your ATG applications can view both LDAP profile information and SQL database profile information as properties of composite items in the composite user item descriptor.
Primary and Contributing Item Descriptors
Each composite item descriptor is composed of any number of contributing item descriptors. One of these contributing item descriptors must be designated as the primary item descriptor. The primary item descriptor’s main purpose is to provide the ID space for the composite item descriptor. The composite item descriptor can incorporate any number of contributing item descriptors, which contribute properties to the composite repository items.
Each contributing item has one or more relationships to the primary item. These relationships are defined in the contributing item descriptor. Each relationship defines a unique ID attribute in the primary item descriptor, as well as a unique ID attribute in the contributing item descriptor. The attribute can be the repository item ID or a unique property. A contributing item is linked to a primary item if the value of its unique ID attribute matches the value of the primary item’s unique ID attribute. If multiple relationships are defined, they are AND’d together.
For example, suppose you have a contributing item descriptor that defines two relationships to the primary item descriptor. One says that a primary item’s firstName property must match the contributing item’s userFirstName property and the other says that the primary item’s lastName property must match the contributing item’s userLastName. These two relationships together mean that a user’s first names and last names must each match for two items to be related. This is useful in situations where no one property uniquely identifies a user. See link-via-property for an example of defining a relationship with two or more properties.
Item Inheritance and Composite Repositories
A composite repository can handle item descriptor inheritance only for its primary item descriptors. For example, suppose you have a user composite item descriptor. Its primary item descriptor is named person and is part of an LDAP repository. The contributing item descriptor is named user and is part of an SQL repository. The user item descriptor has a subtype named broker. The composite items have access to the properties of the person item descriptor and the user item descriptor, but not to properties that exist only in the broker item descriptor.
Transient Properties and Composite Repositories
An LDAP repository does not support transient properties. Therefore, if you want to use transient properties in your composite item descriptor, the transient properties must be derived from an SQL repository or other repository that does support transient properties.
Non-Serializable Items and Composite Repositories
An LDAP repository item is not serializable. Therefore, if you have a property that derives from an LDAP repository item, you should mark the property as not serializable by setting the serialize attribute to false:
<property name="propName" >
...
<attribute name="serialize" value="false"/>
...
</property>
Property Derivation
The properties in a composite item descriptor are determined as follows:
1.If configured to do so, all properties from the primary and contributing item descriptors are combined into the composite item descriptor, with each property retaining its property name and property type.
2.Any properties marked as excluded are removed from the composite item descriptor. See Excluding Properties.
3.All property mappings are performed. This means that a primary or contributing property that is to be mapped gets renamed in the composite item descriptor. See Property Mappings.
4.If there are any two properties in the composite item descriptor that have the same name, an error results. The composite repository requires that all composite property names map explicitly to only one primary or contributing property.
Configuring a Composite Repository
1.Design the composite repository. Pick what item types you want to represent in your composite repository’s composite item descriptors
2,Specify the primary item descriptor. This is where the composite repository item’s repository item IDs come from
3.Specify any contributing item descriptors you need to supplement the primary item descriptor.
4.Resolve any property name collisions between properties in the primary item descriptor and the contributing item descriptors. See Property Mappings.
5.Determine whether you want to use static or dynamic linking for properties whose types are repository items. See Link Methods.
6.Determine what item creation policy you want the composite repository to implement. See Creating Composite and Contributing Items.
7.Determine whether there are any properties in your primary or contributing item descriptors that you want to exclude from the composite item descriptor. See Excluding Properties.
8.Create and configure a CompositeRepository component. See Configuring the Composite Repository Component.
Property Mappings
The composite repository requires that all composite property names map explicitly to only one primary or contributing property. If primary or contributing item descriptors contain one or more properties with the same name, you must exclude one of the properties (see Excluding Properties) or map it to another name.
You can map a property with the mapped-property-name attribute in an item descriptor’s property tag. For example, given two contributing item descriptors, where each has a login property, you can map one of the properties to a different name like this:
<property name="ldapLogin" ... mapped-property-name="login"/>
In this example, the name attribute specifies the property name in the composite item descriptor and the mapped-property-name attribute specifies the name of the property in the primary or contributing item descriptor to which this property maps.
Excluding Properties
Sometimes you may not want to expose absolutely every property from the underlying primary and contributing item descriptors in the composite item descriptor. You can configure the item descriptor to exclude those contributing properties that are not desired. You do this by setting a property tag’s exclude attribute to true:
<property name="password ... exclude="true"/>
Link Methods
The link-method attribute determines what happens when the composite repository needs to get a property value that belongs to a contributing repository item. For example, a process might call:
CompositeItem.getPropertyValue("ldapFirstName");
where ldapFirstName is a property of a contributing repository item in an LDAP repository. The CompositeItem that is being asked for the property needs to look for this contributing item. If it can find it, it retrieves the property value and acts according to the value of the link-method attribute: static or dynamic.
Static link method
If link-method is set to static, the contributing item is stored in a member variable of that composite repository item. The next time a property is requested from that same item, it retrieves it from this variable instead of finding it again from the underlying contributing repository. This saves some computational effort and results in faster property retrieval.
If the value of the property or properties used to link to the underlying contributing item changes, the data in the member variable is stale. This occurs only if a linking property in the underlying data store changes. For example, if you link to a contributing item descriptor using a login property, static linking can result in stale data only if the login property changes in an underlying repository.
Dynamic link method
If link-method attribute is set to dynamic, the composite repository queries the underlying repository for the contributing item every time a property is requested from it. This might result in slower performance, but it also means that data is never out of sync at the repository level.
Methods compared
Dynamic link mode might seem like the most technically correct implementation, because the data model is guaranteed to reflect the latest information. Because dynamic link mode requires a query each time information is needed from a composite item, it can impair performance. Usually, the information that links items rarely changes. Static linking is generally provides correct data model linking.
composite-repository-template
The composite-repository-template tag encloses the whole composite repository definition. The composite-repository-template tag encloses a <header> tag and one or more <item-descriptor> tags:
header (Composite Repository)
item-descriptor (Composite Repository)
Example
<composite-repository-template>
<header>
...
</header>
<item-descriptor name="..." />
...
</item-descriptor>
</composite-repository-template>
header (Composite Repository)
The <header> tag provides information that can help you manage the creation and modification of repository definition files.
For example, the header of your template might look like this:
<header>
<name>Catalog Template</name>
<author>Neal Stephenson</author>
<author>Emily Dickinson</author>
<version>$Id: catalog.xml,v 1.10 2000/12/24 03:34:26 hm Exp $</version>
<description>Template for the store catalog</description>
</header>
item-descriptor (Composite Repository)
The item-descriptor tag defines a composite item descriptor.
<item-descriptor name="compositeUser" default="true"
display-property="fooProperty"
display-name-resource="itemDescriptorUser">
<attribute name="resourceBundle"
value="atg.userprofiling.CompositeProfileTemplateResources"
data-type="string"/>
<primary-item-descriptor.../>
<contributing-item-descriptor.../>
...
</item-descriptor>
1.A primary-item-descriptor tag can enclose one or more property tags.
2.The contributing-item-descriptor has the same attributes as the primary-item-descriptor tag. See primary-item-descriptor and contributing-item-descriptor attributes.
Sample Composite Repository Definition File
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario-manager-configuration
PUBLIC "-//Art Technology Group, Inc.//DTD Scenario Manager//EN"
'http://www.atg.com/dtds/composite-repository/composite-repository_1.0.dtd'>
<!-- composite repository definition -->
<composite-repository-template>
<!-- Header similar to GSA DTD -->
<header>
<!-- name of this document -->
<name>A sample Composite Repository template</name>
<!-- author of this document -->
<author>Graham Mather</author>
<!-- version of this document -->
<version>$Change: 226591 $$DateTime: 2002/01/22 15:50:56 $$Author: gm $
</version>
</header>
<!-- composite item descriptor definition -->
<!-- name: name of the composite item descriptor -->
<!-- default: is this the composite repository's default item descriptor? -->
<!-- display-property: the property used when display items of this type -->
<!-- display-name-resource: resource which defines the display name -->
<item-descriptor name="compositeUser" default="true"
display-property="fooProperty"
display-name-resource="itemDescriptorUser">
<!-- resource bundle from whence this item descriptor's resources come -->
<attribute name="resourceBundle"
value="atg.userprofiling.CompositeProfileTemplateResources"
data-type="string"/>
<!-- icon for items of this type -->
<attribute name="icon" value="userIcon" data-type="string"/>
<!-- "basics" category sort priority -->
<attribute name="categoryBasicsPriority" value="10" data-type="int"/>
<!-- primary view definition -->
<!-- name: the name of the primary view, as it appears internally to the
composite repository. The primary view and all composite views must have
unique internal view names -->
<!-- repository-nucleus-name: the nucleus path of the repository in which
the primary view resides -->
<!-- repository-item-descriptor-name: the name of the view in the given
repository which acts as the primary item descriptor for this composite item
descriptor -->
<!-- all-properties-propagate: if true, composite repository attempts to
make all properties in the primary item descriptor available in the
composite item descriptor. Default is false -->
<!-- all-properties-queryable: if true, all properties in the view are
queryable unless otherwise specified. If false, all properties are not
queryable unless otherwise specified. default is true -->
<primary-item-descriptor name="user"
repository-nucleus-name="/atg/userprofiling/ProfileAdapterRepository"
repository-item-descriptor-name="user"
all-properties-propagate="true"
all-properties-queryable="true">
<!--
Can also contain explicit property mappings and explicit property exclusions
-->
<property mapped-property-name="lastName" exclude="true"/>
<property mapped-property-name="email" exclude="true"/>
</primary-item-descriptor>
<!-- contributing view definition -->
<!-- name: the name of this contributing view, as it appears to the composite
repository -->
<!-- repository-nucleus-name: the nucleus path of the repository in which the
primary view resides -->
<!-- repository-item-descriptor-name: the name of the view in the given
repository which acts as the primary item descriptor for this composite item
descriptor -->
<!-- all-properties-propagate: if true, composite repository attempts to make
all properties in the primary item descriptor available in the composite item
descriptor. Default is false -->
<!-- all-properties-queryable: if true, all properties in the view are
queryable unless otherwise specified. If false, all properties are not
queryable unless otherwise specified. default is true -->
<contributing-item-descriptor name="UserProfile-LDAP"
repository-nucleus-name="/atg/adapter/ldap/LDAPRepository"
repository-item-descriptor-name="user"
all-properties-propagate="true"
all-properties-queryable="true">
<!-- explicit property mapping
sometimes it's advantageous to explicitly map a property in a composite view
to a particular property in either the primary or a contributing view.
For example, perhaps two contributing views have properties with the same
name. This gets around the "no contributing views with same property names"
rule.
-->
<!-- name: name of this composite property -->
<!-- mappedPropertyName: the property to which this property maps -->
<!-- queryable: property queryable flag -->
<!-- required: property required flag-->
<!-- expert: property expert flag -->
<!-- hidden: property hidden flag -->
<!-- readable: property readable flag -->
<!-- writable: property writable flag -->
<!-- category-resource: resource for category name -->
<!-- display-name-resource: resource for display name -->
<property name="ldapFirstName" mapped-property-name="firstName"
queryable="false" required="false" expert="false"
hidden="false" readable="true" writable="true"
category-resource="categoryBasics"
display-name-resource="ldapFirstName">
<!-- bundle for this property's resources -->
<attribute name="resourceBundle"
value="atg.userprofiling.CompositeProfileTemplateResources"
data-type="string"/>
<!-- flag for ui being able to write this property -->
<attribute name="uiwritable" value="true" data-type="boolean"/>
<!-- maximum length for this property -->
<attribute name="maxLength" value="32" data-type="int"/>
<!-- does this property's value have to be unique? -->
<attribute name="unique" value="true" data-type="boolean"/>
<!-- sort priority -->
<attribute name="propertySortPriority" value="10" data-type="int"/>
</property>
<!-- explicit property exclusion
Sometimes users will not want to expose absolutely every property from
the underlying primary and contributing views in the composite view. An
explicit property removal allows the user to make the composite view
contain only those contributing properties that are desired.
-->
<property mapped-property-name="login" exclude="true"/>
<property mapped-property-name="password" exclude="true"/>
<property mapped-property-name="id" exclude="true"/>
<!--
2) a composite view's property names are determined thusly:
a) If all-properties-propagate is true, all properties from the primary and
contributing views are combined into the composite view, retaining their
property names, property types, and any metadata they may have defined.
b) All property exclusions are performed. This means that any properties
to be excluded are removed from the composite view.
c) All property mappings are performed. This means that a primary or
contributing property that is to be mapped gets renamed in the composite
view.
d) If there are any two properties in the composite view that have the same
name, error. The composite repository requires that all composite property
names map explicitly to only one primary or contributing property.
-->
<!-- the primary view link describes how items in the contributing view are
linked to items in the primary view. For each primary-contributing
relationship, the user picks a unique id attribute for the primary and the
contributing view. The attribute can be either the repository id of the
item or a uniquely-valued property of the item (e.g. login). A primary item
is linked to a contributing item if its unique id attribute value matches
the unique id attribute value of the contributing item. There must be at
least one primary view link, but there is primary view link limit. -->
<!-- example: this primary view link defines a relationship where an item in
the primary view is linked to an item in this contributing view if the
contributing item has a repository id which is the same as the primary
item's id.
-->
<!--
<primary-item-descriptor-link>
<link-via-id/>
</primary-item-descriptor-link>
-->
<!-- OR:
This primary view link defines a relationship where a primary view item is
linked to an item in this contributing view if the value of the primary
item's "login" property matches the value of the contributing item's
"userLoginName" property.
-->
<primary-item-descriptor-link>
<link-via-property primary="login" contributing="login"/>
</primary-item-descriptor-link>
<!-- OR:
This primary view link defines a relationship where a primary view item is
linked to an item in this contributing view if the value of the primary
item's "firstName" property matches the value of the contributing item's
"userFirstName" property AND the value of the primary item's "lastName"
property matches the value of the contributing item's "userLastName"
property. This is useful in the case where no one property in the primary
view or the contributing view is uniquely valued. The relationships are
ANDed together
<primary-item-descriptor-link>
<link-via-property primary="firstName" contributing="userFirstName"/>
<link-via-property primary="lastName" contributing="userLastName"/>
</primary-item-descriptor-link>
-->
</contributing-item-descriptor>
</item-descriptor>
No comments:
Post a Comment