A Rationale-based Model for Architecture Design Reasoning

7.1. The EFT system
Therefore, in assessing whether MCP could process all payment transactions, there is
a need to check if the bank is still legitimately logged on to the EFT system when the
transaction is received. AR22 provides two alternative solutions. If there is a dedicated
MCP server for each connection, as documented in the QLR in the AR, the server process
can keep the login state in memory, hence perform much better because the login state is
already kept. Alternatively, if MCP is generic, then every payment that is processed by
it would need to be checked for bank login state. This is achieved either via the database
or via a central authorisation server. This is documented in AAR. An individual MCP
instance which is responsible for a dedicated bank connection gives a better performance
for checking the message security, thus we choose this design.
As a result of the decision, the MCP design needs to employ a state machine. Messages
passing through it would set its state according to the events such as the successful login
of a bank. Top End has to be configured to support the start-up of multiple MCPs, one
for each connection. The message header would need a data element, in particular the
connection session identifier, to identify a connection.
7.1.6 Centralised control
The requirements R5 2 0 and R5 2 1 specify that the EFT system has to broadcast the
settlement window timetable and the shutdown notification to member banks. These
requirements would mean that special messages need to be sent through MCPs to all
those banks that are on-line at the time.
There were two relevant issues in considering the architecture design. Firstly, what
mechanism should be used to notify the banks and secondly which banks should be notified.
Figure 7.9 shows the motivational reasons and the design reasoning of this design.
AR23 was a decision to use a centralised server to carry out the messages distribution.
There was no alternative option in this decision because there is only one viable mechanism,
i.e. a single process to coordinate its execution. A user would use an user interface C9 0 1
to order a message distribution such as system shutdown. The order would be sent to the
Control Server (C8 0 0 ) to execute. The Control Server would determine which banks
are currently logged into the EFT system and then distribute the message to the banks.
When designing the control server, a parallel issue was to determine how to detect bank
login states. The decision in AR24 was to make use of Session tables which logged the
states of current bank connections (I2 0 4 and I2 0 5 ).
It is common that a number of indirectly related decisions may exist in parallel in
an architecture design. The decisions arising from the issues usually have common mo-
118