The hub model

The hub is the model that has traditionally been used with CICS® dynamic transaction routing.

A routing program running in a TOR routes transactions between several AORs. Usually, the AORs (unless they are AOR/TORs) do no dynamic routing. Figure 1 shows a hub routing model.
Figure 1. Dynamic routing using a hub routing model. One routing region (the TOR) selects between several target regions.
A terminal-owning region (TOR) is connected to four application-owning regions (AORs). A dynamic routing program runs in the TOR and balances transaction requests across the AORs. The TOR is both the requesting region and the routing region. Each of the AORs is a possible target region.
The hub model applies to the routing of:
  • Transactions started from terminals.
  • Transactions started by terminal-related START commands.
  • Program-link requests received from outside CICS. (The receiving region acts as a hub or TOR because it routes the requests among a set of back-end server regions.)
  • Bridge 3270 requests.
  • CICS-to-CICS DPL requests.

The hub model is a hierarchical system; routing is controlled by one region (the TOR). Normally a routing program runs only in the TOR.

Advantage of the hub model

It is a relatively simple model to implement. For example, compared to the distributed model, there are few inter-region connections to maintain.

Disadvantages of the hub model

  • If you use only one “hub” to route transactions and program-link requests across your AORs, the “hub” TOR is a single point-of-failure.
  • If you use more than one “hub” to route transactions and program-link requests across the same set of AORs, you may have problems with distributed data. For example, if the routing program keeps a count of routed transactions for load-balancing purposes, each “hub”-TOR will need access to this data.