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.

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.
- Document publishing
- Manages requests to publish documents, including the option to
render them into PDF or HTML format. When a request is made to transform
content to an alternative format, the content services submit format
translation requests to a rendition engine.
- 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.