Deployment Planning Guide > Load Balancing and Resilient Processing Planning >

About Resilient Processing

Resilient processing, also called distributed services, distributes server requests to multiple instances of batch-mode server components. The server requests for these components are typically message-based, so any instance of the component can process the request. If one instance of a component fails, another can perform the task, thus providing resiliency. Multiple instances of the components can run on the same Siebel Server or on several Siebel Servers.

Load balancing is about distributing workload. Resilient processing is about providing redundancy. Resiliency also provides round-robin distribution of workload to multiple instances of server components.

Resilient processing makes more efficient use of hardware resources than server clustering. In addition, resilient processing does not require third-party clustering software. Where possible, resilient processing should be used instead of server clustering.

If server clustering is used, resilient processing is not required, as the cluster will provide a resilient environment. Resilient processing is not available for all server components. It cannot be used for server components that must run on only one server. An example is Siebel Remote. In these cases, the only high availability option is server clustering.

Resilient processing is the preferred method for providing high availability for the following server components:

• Communications Manager
• CORBA Object Manager
• eDocument Server
• Pricer
• Field Service
• File System Manager
• Interactive Assignment
• Server Request Broker
• Server Request Processor
• Siebel Marketing
• Workflow Process Manager

Resilient processing uses two server components:

• Server Request Processor. This component handles asynchronous server requests. See About Server Request Processor.
• Server Request Broker. This component handles synchronous server requests. See About Server Request Broker.