ODRS

The ODRs will route the incoming HTTP requests in an "application scoped" fashion to any target server capable of servicing the request.

Presently, the generated plug-in routing file contains only the ODRs that are up and running at the time of generation.

Though technically possible, do not create topologies where ODRs route traffic across multiple WebSphere Application Server cells.

As shown in the Real life scenario section, it is a best practice in an enterprise-wide environment to create a separate cell for the ODRs.

In any production system, we recommend you have at least two ODRs so that there will not be a single point of failure.

This server enables the client to access JMX notifications generated by the application servers, node agents, and ODRs within the cell.

Beyond that, the number of ODRs needed will be determined by the amount of load you expect the network to experience.

The next question is: Should application and administrative traffic share ODRs?

On principles of operational independence of data centers, HTTP plug-ins should not be routing to foreign ODRs.

Another reason for routing to foreign ODRs might be session affinity.

The technique requires CGBS configuration if the ODRs and clusters (application deployment targets) are located in different core groups.

Know that at least two ODRs will be needed for high availability, as shown in Figure 2.

This can be achieved by making foreign ODRs secondary targets in the HTTP plug-in.

A second major decision is to decide what caching options you will enable on the ODRs.

Bridge all of the core groups containing the clusters and the core group containing the ODRs.

This pattern consists of one or more on demand routers (ODRs), one or more application servers, and one deployment manager.

If this is the case, then having dedicated ODRs for administrative traffic is the solution.