Ceptor Dispatcher is a Reverse Proxy Server, which is typically deployed in a DMZ zone.

It is capable of running in a servlet container of your choice, or it can run in the Web Server provided by Ceptor as part of the distribution.

It has similar functionality as the Ceptor Gateway, but is based upon older technology and uses blocking IO for its communication - this means that it is unable to support WebSockets, and it takes up a running thread also while waiting for requests from backends.
That being said, it is extremely stable, and has proven its worth for the last 15+ years in highly secure and performance-critical systems.

But, newer deployments should use Ceptor Gateway instead of the Dispatcher, since it contains more functionality, and is easier to configure. Also, new features will be added to the gateway, but in general not to the dispatcher.

What does the Dispatcher do

The Dispatchers job, is basically to forward requests to web application servers. It also assigns session id’s to browsers, and performs load-balancing by assigning servers to users. The dispatcher also makes sure that clients reach the same server for every request they perform, so session state information can be kept in memory on the application server, instead of sharing it via databases.

 In short, the dispatcher sits in the DMZ zone between firewalls, and forwards requests to an application web server.

If the dispatcher gets a request from a browser without a sessionid cookie, it will contact the session creation servlet, and ask it to create a new session. It then puts that session id in a cookie, and sends it to the browser, so the browser can send the sessionid to the server in the next request.

The reason why the dispatcher does not use an Agent to contact the SessionController, is that it only needs to be able to create new sessions. With an Agent, it could also retrieve session information from the Server, such as userid and password. Since the dispatcher is usually deployed in the DMZ zone, which is considered insecure, it is more secure if the computer running the dispatcher does not have full access to the SessionController server. That way, if the dispatcher computer is hacked, the only thing a hacker can do, is to create new sessions, not spy on existing ones.

The dispatcher itself is a servlet that runs on top of a web server and a servletengine, such as WebLogic or Tomcat with Apache. The servlet is configured to forward certain URLs to the web application server, such as /servlet/* or /include/* or /jsp/* while other URLs are processed locally, such as static html pages and images.

The dispatcher is also able to filter access to specific URLs based on the authorizations of a particular the user. This means that certain URLs can be made available to e.g. administrators only, and all non-known URLs can be blocked providing additional security.

In order to retrieve information from the dispatcher servlet, a few special URLs exists: If an url that is passed to the dispatcher servlet ends with “.statistics”, “.errorstatistics” or “.urlstatistics”, it is not forwarded to the application web server, but the dispatcher instead generates an answer.

If the url ends with “.statistics” the dispatcher returns a page where the application web servers and their status (up/down) is listed. This can be used to quickly determine if the dispatcher can reach all its defined web servers.

An URL ending with “.errorstatistics” returns a page listing the last 100 errors that have occurred in the dispatcher while processing requests. This can give valuable information about the current state of the system.

If the URL ends with “.urlstatistics”, the last 1000 URLs that have passed through the dispatcher are listed, along with information about the size of the reply, and the time in milliseconds it took the application web server to reply.

The URLs ending with “.errorstatistics” and “.urlstatistics” are password protected, so not everyone can see the list of URLs and errors that occurred, but the “.statistics” page is not password protected, since it only shows a list of logical server names (not tied to the DNS name) and their current status (up/down). This .statistics page can also be used by a load balancer to determine if it should forward requests to this dispatcher or not, since if all application web servers are marked down, because of e.g. network problems, there is no reason to send request to it.