Internal architecture

The following diagram and descriptions provide a high-level overview of the internal architecture of Content Engine. Content Engine is built on the Java™ 2 Enterprise Edition (J2EE) platform and runs within a J2EE-compliant application server.

An overview of the internal Content Engine architecture

 

Java API. The Java Application Programming Interface (API) is an interfaced-based API that provides access to the full capabilities of Content Engine. The Java API can be configured to run across either the Enterprise Java Beans (EJB) or Web Services Interoperability (WSI) protocols. When running across the EJB listener, the Java API leverages the full capability of the J2EE framework to propagate security and transaction context. The Java API also leverages a Java Authentication and Authorization Service (JAAS) context, if available.

.NET API. The .NET API provides a Microsoft .NET Common Language Runtime (CLR) compliant API for accessing the full capability of Content Engine. The API accepts user name and password credentials for authentication. The .NET API works only with the WSI Listener.

WSI Listener. The WSI listener leverages the Systinet toolkit to provide a pure web services based interface to the Content Engine server. Both the .NET and Java APIs can operate across WSI.

EJB Listener. The EJB listener provides an EJB interface to Content Engine and provides both local and remote interfaces. The local interface is used by J2EE components bundled with the Content Engine EAR file (which is the Content Engine application file deployed to the application server). The remote interface is used by a remote Java API. The EJB listener is not a public interface and is leveraged by the Java API. The EJB listener also leverages the application server provided protocols for communicating between server nodes and providing automatic propagation of security and transaction context.

Request Broker. All server requests flow through the request broker regardless of where the call originated. The request broker provides a central source code location for setting up a server call, propagating client information like locale or time zone, finding the appropriate server code to call, and providing error logging. This component also handles reentrant calls for "loop back" behavior inside of the server to maintain transaction, security, and call context information. When the server call is set up, the LDAP store is queried to determine the user and group associations for the given principal for use during authorization requests.

System Retrievers. System retrievers handle requests from the client, such as GetObject, ExecuteSearch, and GetSearchMetaData. There is a hierarchy of retrievers which mirrors the class hierarchy and these retrievers are responsible for retrieving various objects from the repository and returning them to the client.

System Persisters. System persisters handle ExecuteChange requests from the client. There is a hierarchy of persisters which mirrors the class hierarchy. These persisters are responsible for adding, updating, and deleting various objects to the repository.

Database Persist Layer. The database persist layer provides an interface between the system retrievers and system persisters and the various RDBMS vendors and their corresponding Java Database Connectivity (JDBC) drivers.

Synchronous Events. Synchronous events are called from the system persisters based on relevant subscriptions for those events on a given object. Synchronous events are events that are handled in a synchronous fashion (for example, events that are handled as they occur).

Background Tasks. Various background tasks can be queued up and handled in an asynchronous fashion. These include the queue item handler (asynchronous events, XML classification, and security propagation), the cache update task, storage related tasks, the Images Services (IS) pull daemon, and the Content Based Retrieval (CBR) handler. In addition, there is an automatic classification framework which handles the various classification related events such as XML classification, and an asynchronous event framework for handling customer scripted asynchronous events (asynchronous events are queued for later processing.)

Metadata Cache. The metadata cache holds information about the classes and properties of an object store. The cache is used to determine if classes exist during retrieval and persistence, and to determine which properties exist for those classes. It is also used to retrieve other attributes of classes and properties.

GCD. The Global Configuration Data (GCD) stores hierarchical configuration data related to the P8 domain. There is only one GCD for every P8 domain. Data stored in the GCD includes the domain configuration (sites, virtual servers, and server instances), marking sets, object store definitions, add-ons, fixed content devices and any other data that must be shared between all object store services in a P8 domain. The GCD is stored in a database.

Content Storage. Content storage provides for the storage of document and annotation content elements in either the object store database, or in a separate repository from the object store database. One benefit to storing content elements outside of the object store database is increased storage manageability.

The content elements are stored in storage areas. The supported storage areas are: the object store database, a shared file storage system, and a fixed content device (such as an EMC Centera, IBM DR550, NetApp SnapLock, or other device).