Content Platform Engine content services

The Content Platform Engine content services are responsible for adding and deleting content and retrieving objects and content from an object store. In addition to servicing requests from enterprise content management (ECM) applications, the content services host various background tasks that maintain all the resources that are associated with each object store.

The following diagram provides a detailed view of the content services that are provided by Content Platform Engine.

Diagram of the Content Platform Engine content services architecture
The following services and components are included in Content Platform Engine content services:
Security
Provides a fine-grained security model for authorizing access to objects and content; interacts with directory service products to authenticate users and retrieve user and group account information.
Search
Provides support for both ad hoc search and stored search. Searches can be performed against system properties (such as the object creator or the date created), customer-defined properties (such as Account Number or Customer Name), or document content. Property searches can be combined with text searches. Users can simultaneously search multiple object stores.
Event framework
Enables configuration of actions in response to specific activities that occur on objects that are stored in an object store. For example, when a new document is created, you can configure an event to launch a workflow that is used to further process the document.
Event auditing
Enables monitoring of the activity on the FileNet P8 system. Actions that occur on objects cause an automatic logging of an audit entry for later analysis.
Content-related services
Provides the capability to store and retrieve content securely from different types of storage devices, and provides all the functionality necessary to manage this content. A document or annotation consists of both properties and content. Properties are stored in the object store database. The content (for instance, a Word or PDF document) can be stored in the object store database as well (referred to as database storage), or you can choose instead to store content on a network file server (a file storage area) or on an external storage device (a fixed storage area).
File storage
Manages one or more file stores, allowing document content to be stored on a network file server.
Fixed content providers
Manages one or more Image Services and third-party storage devices for managing content in those repositories.
Federated content systems
Manages fixed storage areas that are configured to access external repositories that are part of a federated content management system.
Full-text indexing
Manages interactions with IBM® Content Search Services. You can enable full-text indexing for one or more document classes and annotation classes, allowing full text searches to be performed against their contents, as well as their properties.
Content cache
If content caching is enabled, stores copies of recently created or accessed content in a local network file share so that subsequent retrievals are more efficient. Content caches are primarily used in geographically distributed environments, where access to remote content storage resources might be over a slow network link.
API transport protocols
Provide two transport mechanisms that applications can use to access the Content Platform Engine server.
EJB Transport
The EJB transport is an Enterprise JavaBeans (EJB) transport that runs in the Java™ Platform, Enterprise Edition (Java EE) EJB container of the application server that hosts the Content Engine Service. Access through this EJB is referred to as the Content Engine EJB Transport. The EJB transport can be accessed only through the Content Engine Java API. All access to the content services ultimately flows through the EJB transport (the Content Engine web service is itself a client of the EJB transport).
Web Services
The web services transport can be accessed directly by web service-based applications. You can configure clients of the Content Engine Java API to use the Content Engine web service. Clients of the Content Engine Microsoft .NET framework-based API and COM Compatibility API must use the Content Engine web service.

The web services enable access to content and process capabilities over the web. The Content Engine Service hosts two web services: Content Engine Web Services (CEWS) and Process Engine Web Services (PEWS). Hosting these two web services together allows them to share common resources and a common environment.

The CEWS and PEWS protocols provide developers with a complete set of interfaces that supports custom application development in a web environment. These two interfaces share many similarities, including:
  • Both are compliant with WS-I (Web Services-Interoperability) Basic Profile.
  • Both implement the same standard WS-Security authentication profiles. The Username Profile allows clients to provide their user name and password credentials to authenticate with the web server through the customer enterprise directory service (such as Microsoft Active Directory or Novell eDirectory). The Kerberos Profile allows .NET framework-based web service applications that are running in a Windows Integrated Authentication environment with Active Directory to authenticate by using their Windows domain credentials.
  • Both allow you to develop applications and FileNet P8 extensions by using Visual Studio .NET and Rational® Application Developer.
  • Both implement a service-oriented architecture, and are designed for stateless operation. That is, each request to the web server is independent of any other, with no client-specific state held by the server after the request is completed. This architecture facilitates scalability and high availability by allowing client requests to be load-balanced across multiple hosts.

CEWS is a low-level protocol that exposes the full Content Platform Engine feature set. All authoring and administrative functionality is available in addition to the basic document management features. Advanced batching capability is available, allowing arbitrarily complex sets of data to be retrieved in a single round trip to the server, and arbitrarily complex sets of updates to be performed in a single round trip. These capabilities combine to allow powerful and highly efficient applications to be built.

PEWS is a high-level protocol that is based upon the Process Engine Java API. It presents an interface that looks familiar to Process Engine Java API developers. PEWS is focused on workflow runtime functionality, allowing for rapid development of step processors and applications that launch or monitor workflows. It does not provide process authoring or administration capabilities. PEWS is designed to work in tandem with Process Orchestration capabilities.

.NET API
Provides a .NET framework-based Common Language Runtime (CLR)-compliant API for accessing the full capability of Content Platform Engine. The API accepts user name and password credentials for authentication. The .NET framework-based API works only with the WSI Listener.
Java API
An interface-based API that provides access to the full capabilities of Content Platform Engine. The API can be configured to run across either the Enterprise JavaBeans (EJB) or Web Services Interoperability (WSI) protocols. When the API runs across the EJB listener, the API uses the full capability of the Java EE framework to propagate security and transaction context. The API also uses a JAAS context, if available.