The ATG Repository API (atg.repository.*) is the foundation of persistent object storage, user profiling, and content targeting in ATG products. A repository is a data access layer that defines a generic representation of a data store. Application developers access data using this generic representation by using only interfaces such as Repository and RepositoryItem. Repositories access the underlying data storage device through a connector, which translates the request into whatever calls are needed to access that particular data store. Connectors for relational databases and LDAP directories are provided out-of-the-box. Connectors use an open, published interface, so additional custom connectors can be added if necessary.
Developers use repositories to create, query, modify, and remove repository items. A repositoryitem is like a JavaBean, but its properties are determined dynamically at runtime. From the developer’s perspective, the available properties in a particular repository item depend on the type of item they are working with. One item might represent the user profile (name, address, phone number), while another may represent the meta-data associated with a news article (author, keywords, synopsis).
The purpose of the Repository interface system is to provide a unified perspective for data access. For example, developers can use targeting rules with the same syntax to find people or content.
Applications that use only the Repository interfaces to access data can interface to any number of back-end data stores solely through configuration. Developers do not need to write a single interface or Java class to add a new persistent data type to an application
Each repository connects to a single data store, but multiple repositories can coexist within ATG products, with various applications and subsystems using different repositories or sharing the same repository. Because of this approach, applications that use only the Repository API to access data can interface to any number of back-end data stores solely through configuration. For example, the security system can be directed to maintain its list of usernames and passwords in a SQL database by pointing the security system at a SQL repository. Later, the security system can be changed to use an LDAP directory by reconfiguring it to point to an LDAP repository. Which repositories you use depends on the data access needs of your application, including the possible requirement to access data in a legacy data store.
The ATG platform includes the following models for repositories:
SQL Repositories, which use ATG’s Generic SQL Adapter (GSA) connector to perform a mapping between ATG and data stored in a SQL database. You can use a SQL repository to access content, user profiles, application security information, and more.
SQL Profile Repository, included in the ATG Personalization module, which uses the Generic SQL Adapter connector to perform a mapping for user data contained in a SQL database. See the ATG Personalization Programming Guide.
LDAP Repository, which uses the ATG LDAP connector to access user data in an LDAP directory. See the LDAP Repositories chapter.
Composite Repository, which provides a means for using more than one data store as the source for a single repository. See the Composite Repositories chapter.
Versioned Repositories, an extension of the SQL Repository used in ATG Content Administration. See the ATG Content Administration Programming Guide.
When you store content in a repository, in addition to the meta-information about a document, you need access to the physical piece of content that is the document and path information that tells you where the document is stored. To handle this problem, we have developed the content-specific repository extensions located in the atg.repository.content package, which is described in the ATG API Reference and in the SQL Content Repositories chapter in this ATG Repository Guide.
