Monday, 23 April 2012

What is a dispatcher

First you need to understand How a Web application works

1) Client(Web browser) and server interact through Http and Html.
2) Browser understands HTML and can display it on the screen
3) Web browser makes a Http request and gets Http response
3) So it either makes a Get or Post request. Get request is visible in browser
4) In Case of Static web pages. Get request directly tells us the location of the page
5) In case of Dynamic content web server forward request to Web application or CGI common gateway interface
6) In CGI performance can be a issue due to one process per request
7) For enabling Dynamic content we have Java classes called servlets which can accept Http request and Give Http response
8) A servlet will have Get method inside it which tells it what to do based on the request

Routing in IBM Cognos BI

Routing? Why?
IBM Cognos BI is based on a Service Oriented Architecture (SOA). This implies the product consists of a set of independent services which communicate via SOAP over a network. There are many different services which all implement different features of the product. Each service can only serve a certain type of request. This is one of the routing challenges in an SOA, to route a request to a service which can serve this type of request.
Another aspect of the routing challenges in an SOA is load balancing and/or fail-over. There can be multiple instances of the same type of service in an overall system. If there are multiple instances, then either load balancing (each instances get's assigned a configurable percentage of the requests of that type) or fail-over (requests for a certain type of service get re-routed to an active instance because another one failed) can happen.

The Dispatcher

IBM Cognos BI addresses both routing challenges by a software component called the Dispatcher. The Dispatcher, technically, is a Java Servlet which implies it handles HTML input and generates HTML output. In the case of IBM Cognos BI, the input and output payload is actually using the Simple Object Access Protocol (SOAP) which again, technically, is XML payload transported over the HTTP protocol.
Each Dispatcher hosts a set of services which are determined by the system components installed in this instance of IBM Cognos BI. The services get registered to the Dispatcher and it's the Dispatcher which controls them. At the same time the Dispatcher “knows” which service instances it hosts and hence which types of requests it can serve locally.
When a Dispatcher is started up, it will register itself with the active Content Manager (CM). It will report the services it hosts and will obtain information about the system from CM. Through this process, each Dispatcher gathers information about all other Dispatchers in the system and the services they host.
While a simple single server environment may be sufficient for testing, production systems usually consist of several installed instances, sometimes called nodes, each running a Dispatcher with it's own set of services registered. With multiple nodes, load-balancing and fail-over become possible. The IBM Cognos BI architecture implements this by a logical bus which exists between the Dispatchers on each node. On this logical bus requests get passed/routed between Dispatchers in a system and eventually to a specific service instance registered with one of the Dispatchers. This process will acknowledge load balancing and service availability as will be explained during the course of this document.
Clients send requests destined for a certain service to a Dispatcher to get them served. The Dispatchers of a system will ensure the request is routed to an available instance of the requested service which will handle the request and relay back the result to the client.
Entry Point Considerations
Because the Dispatcher is a Java Servlet, it must be deployed to a Servlet Container/Java Application Server which typically is located in the Application Tier of a classical 3-tier architecture. It's considered a potential risk to expose the Application Tier to external (e.g. from an uncontrolled or less controlled environment) clients for direct access, thus as a best practice, some other component in the web tier like a web server is used to handle the communication with the external clients. Only dedicated controlled and secured communication paths between Web Tier servers and Application Tier servers are allowed.


Entry Point Considerations

Because the Dispatcher is a Java Servlet, it must be deployed to a Servlet Container/Java Application Server which typically is located in the Application Tier of a classical 3-tier architecture. It's considered a potential risk to expose the Application Tier to external (e.g. from an uncontrolled or less controlled environment) clients for direct access, thus as a best practice, some other component in the web tier like a web server is used to handle the communication with the external clients. Only dedicated controlled and secured communication paths between Web Tier servers and Application Tier servers are allowed.
The IBM Cognos BI architecture supports this approach by supplying the IBM Cognos BI Gateway which exists in 6 different implementations (CGI, MOD, MOD2, MOD2_2, ISAPI) and an additional Servlet implementation. Typical installations use Gateway(s) to act as the entry point to the IBM Cognos BI system. The Gateway component, though, does nothing to the request but relay it to the first available Dispatcher in it's configured list of Dispatchers, it can be perceived as a proxy. The Servlet Gateway is a special implementation of a Gateway in such that it has to be deployed to a Java Application server or Servlet Container, typically located in the Application Tier. It is used for setups where other software is used to proxy requests from the Web Tier to the Application Tier. One example are Application Server Plug-Ins deployed to web servers for this particular purpose like they exist for IBM WebSphere or JBOSS.
The Gateway does not route, it's using a static connection to the first available Dispatcher in its configuration, which only changes if the first configured Dispatcher is not reachable. Only in this case the Gateway will try to forward the request to the second Dispatcher in its configured list of Dispatchers and so forth. That being said, routing only starts whenever a given request hits an IBM Cognos BI Dispatcher for the very first time. The Dispatcher which initially receives a client request is called the FRONT Dispatcher for this request. This becomes important for several specific request flows involved with authentication (refer Appendix A).
Technically though, it doesn't make a difference what the entry point is: a Dispatcher or a Gateway. This is remarkable because it implies that one can use application server features like web server plug-ins which proxy requests received in the web tier to the application tier in the same manner as the IBM Cognos BI Gateway does.

For the rest of the document no differentiation between Dispatcher or Gateway is made, whenever required it will reference to an entry point to simplify things.

The dispatcher starts all IBM Cognos 8 services configured and enabled on a computer, and routes requests. The dispatcher is a multithreaded application that uses one or more threads per request. Configuration changes are routinely communicated to all running dispatchers. The dispatcher includes IBM Cognos Application Firewall to provide security for IBM Cognos 8. For more information,

Each Dispatcher hosts a set of services which are determined by the system components installed in this instance of IBM Cognos BI. The services are registered to the Dispatcher and its the Dispatcher which controls them. At the same time the Dispatcher “knows” which service instances it hosts and hence which types of requests it can serve locally.

 The dispatcher is the entry point for IBM Cognos 8 service requests sent by a Web server gateway or other software. The dispatcher handles the routing requests and balances the load of user requests to the various IBM Cognos 8 services.

You can have more than one dispatcher in your IBM Cognos 8 environment. In such distributed installations one dispatcher is configured for every instance of the Content Manager or Application Tier Components that are installed and configured in your environment.

After you install and configure IBM Cognos 8, one dispatcher is available on each computer by default. Each dispatcher has a set of associated services, listed in the following table.


http://www.ibm.com/developerworks/data/library/cognos/infrastructure/cognos_specific/page510.html

Both routing challenges are addressed by a software component called the Dispatcher. The Dispatcher, technically, is a servlet which handles HTML input and generates HTML output. In the case of IBM Cognos BI, the input and output payload will actually be SOAP (XML via HTTP).


An application programming interface (API) is a source code-based specification intended to be used as an interface by software components to communicate with each other


A Servlet is a Java class in Java EE that conforms to the Java Servlet API, a protocol by which a Java class may respond to requests


Because the Dispatcher is a servlet, it must be deployed to a Servlet Container/Java Application Server, which implies it is located in the Application tier of a classical 3-tier architecture. It's is considered a potential risk to expose the application tier to end users, so usually as a best practice, some other component in the web tier like a web server is used to handle the communication with the external clients.


In the IBM Cognos BI architecture, this is done by the IBM Cognos BI Gateway which exists in 6 different implementations (CGI, MOD, MOD2, MOD2_2, ISAPI) and an additional servlet implementation. Typical installations use single or multiple Gateways to act as the entry point to the IBM Cognos BI system. The Gateway component, though, does nothing to the request but relay it to the first available Dispatcher in it's configured list of dispatchers. The Gateway does not route, it's a static link which only changes if the configured Dispatcher is not reachable. Only in this case the Gateway will try to forward the request to the second dispatcher in its list and so forth. That being said, routing only starts whenever a request reaches a dispatcher for the first time. The Dispatcher which first receives a request is called the FRONT Dispatcher. This is important for several specific request flows involved with authentication (refer Appendix A).

Technically though, it doesn't make a difference what the entry point is: a Dispatcher or a Gateway. This is remarkable because it implies that one can use application server features like web server plug-ins which proxy requests received in the web tier to the application tier in the same manner as the IBM Cognos BI Gateway does


How application server interacts with web server

http://www.theserverside.com/feature/Understanding-How-the-Application-Servers-Web-Container-Works

When a client makes a request for a JSP or a Servlet, the request initially goes to the Web server. The Web server reads the special XML file the application server provides, and realizes that the request that came in should be sent to the application server for processing.

The special XML file also provides the IP address/port combination of listening application servers. The Web server, using the http protocol, then sends the request to the Application server JVM listening on the appropriate port.

The JVM listening on the appropriate port represents our application server, and the port the JVM listens on can be configured through that JVM’s Web container.

The Web server handles the incoming request, and matches that request to the application server set up to handle the given Servlet or JSP.

1 comment: