Having obtained the connection object as described in Section 4.1.1, “Creating a Connection”, you can access three repositories: content repository, workflow repository and user repository. A repository encapsulates functionality that pertains to one category of domain objects. All repositories implement the common superinterface CapRepository.
A repository offers methods for the following tasks:
Lookup existing objects.
Modify existing objects.
Create new objects.
Inspect objects.
Inspect types.
Provide access to services.
Add and remove listeners that are informed about all events in the repository.
Get information about the connected server and about the local machine.
Obtain a reference to the associated connection.
In the previous list, objects are identifiable persistent objects. The content repository is concerned with documents and folders. The workflow repository is concerned with processes and task. The user repository is concerned with users and groups. Depending on the stateful objects that have to be processed, you choose the appropriate repository.
The term services referred to objects that exist once per connection and that can be obtained through the repositories. In some sense, services are small repositories whose functionality is very limited. They might perform any of the tasks listed above by accessing objects and types or handling listeners, but their methods concern only one specific aspect of the repository, for example, only content publication or only the computation of rights to workflow objects.
In fact, the methods provided by such services might have just as well been provided by their repository, but at the expense of clarity. By grouping methods in service objects, you can get a quick overview of the system, while getting closely accustomed to the relevant services, only.
A typical method that is reachable directly on the repository level is
ContentRepository.getRoot(), which returns an object representing the root
folder. It is not appropriate for an individual object and it is not easily grouped with other
methods to form a service. A typical method on the service level is
PublicationService.approvePlace(Content). It matches nicely with other
publisher-related methods and there is no need why it would absolutely have to be placed in
the object-level class
Content.
After all, many applications do not care about publication at all, so that it is preferred to
make it a little less visible.
In Figure 4.1, “Class Diagram: Repositories and Services” you can see an UML class diagram of the connection and all repositories and services that are reachable through the session.
See Chapter 5, The Content Repository, Chapter 6, The Workflow Repository, and Chapter 7, The User Repository for detailed discussions of the individual repositories. The services are also described in the chapter that is devoted to their repository.
 |  |  |
 |