Server Architecture

Author: Eike Stepper

A CDO server hosts one or more repositories. Each repository combines model and history services with a store and a protocol boundary; applications normally configure, observe, and customize the repository rather than either boundary. The managed container supplies the factories and named elements that assemble those parts.

The diagram shows the architectural separation. It is deliberately not a deployment topology:

A typical request starts when a client connector reaches a server acceptor and creates a server session. The session opens a server view or transaction on a repository. A read then uses the revision manager and store; a query is dispatched to a registered query handler; a commit passes through supported validation/interception and conflict handling before the store persists its change set. The resulting commit information and notifications update interested clients. The protocol carries these requests and responses, but its individual indications are not a stable application extension seam.

Repository managers divide responsibilities: the package registry supplies model metadata; the branch manager resolves branches and points; the revision manager loads current or historical object data; the commit-info manager exposes commit metadata; the session manager tracks connected clients; the locking manager coordinates explicit repository locks; and, when enabled, the unit manager handles bounded model subtrees. Repository handlers and protectors intercept supported operations; they do not replace the store or repository factory.

This guide uses normal API and intentional extension SPI. In particular, internal repository, session, commit-manager, protocol-indication, and store classes are implementation details and are not server application extension points.

1  Repository Core

A running repository owns the package registry, branch manager, revision manager, commit-info manager, session manager, and locking manager; it can also expose a unit manager and commit handlers according to its configuration. These services expose state that applications can observe; repository handlers and protectors are the supported ways to influence work. A server application should retain manager objects only while the repository is active and should not retain closed session or view instances as live contexts. Continue with startup and shutdown, the managed-container lifecycle, and repository creation. For live server contexts and observation, see Repository Services and Events; for supported interception, see Repository Handlers and Commit Processing. Security/query extensions and synchronization/transfer are covered in Security, Queries, and Specialized Extensions and Advanced Server Integration.

2  Store Boundary

IStore is the persistence boundary for revisions, commit data, and large objects. Its capabilities determine whether a repository can offer facilities such as auditing and branching. Choose and configure an existing store at the repository boundary; a custom store and IStoreAccessor implementation are expert persistence SPI work, not normal server application programming.

3  Protocol and Transport Boundary

ISessionProtocol separates the CDO repository from wire communication. CDO's supplied server integration uses Net4j acceptors and connectors: an acceptor receives client connections and an connector carries the resulting protocol traffic. Server applications commonly configure an acceptor through the container, but do not implement protocol indications.

4  Container and Lifecycle

The managed container locates factories and creates or retains named server elements. In an OSGi server, bundle registration supplies much of that wiring. Standalone and embedded applications prepare and populate a container explicitly. In both cases, activation and deactivation define component lifetime.

See Also:

• CDO Server Application and Startup
• The Managed Container