Siebel architecture high level overview

Siebel has many components and the one which is extensively used is ecommunications_enu.
The following is a good view of the general architecture of Siebel 

Source:http://download.oracle.com/docs/cd/B40099_02/books/DeplmtPlan/DeplmtPlan_ArchOverview15.html#wp1010252

The basic architecture of Siebel consists of a collection of web servers clustered together and a network load balancer distributes web requests to each of these

These web servers are then connected to a cluster of application object managers (AOM). Object managers are the ones which process requests and are connected to the database with or without connection pooling.

These object managers have a wide range of parameters which can be changed after connecting to the server manager (Server manager is a utility to performs various administrative activities on the Siebel server). Some examples of the parameters are max (MaxSharedDbConns) and min (MinSharedDbConns) database connections. The min connection parameter tells the object manager about the number of connections that should be constantly maintained so that the new user does not has to wait to get a new database connection and hence this parameter helps performance. The max connection parameter is to insulate the database from a huge flow of user sessions (Too many sessions can challenge the physical memory available to the database server and can cause database server crash) and hence helps system stability.

When a user logs in to the Siebel application, a session is created for him on one of the web server and his request is sent to the object manager.

The object manager generates a new log for this newly created session. The log can be found in the log directory of the object manager. For example ‘eCommunicationsObjMgr_enu_1380_1447037798.log’. 

 The following is a typical head of such a log file

The 1^st entry in this log tells us about the process under which the requests of the newly logged in user are running (In the above case the request is running under 16416 process id, highlighted in blue). So basically, an object manager will have a few processes running on the host machine and each process will have multiple threads running under it. Each of these threads is to cater to 1 user request.