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
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) 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.
That was great to read. Thanks for sharing.
ReplyDeletealso, check Java course in Pune