7.2 Large-scale connectors

In the previous section, we introduced the idea of connectors, using a Bean-scale example to illustrate the principle; the connectors transmitted simple events and property-values. But we can also use the same idea where the components are large applications running their own databases and interoperating over the internet. Recall that the big advantage of connectors over point-to-point interfaces was that we try to design a small number of protocols common to the whole network of components, so that they can easily be rearranged. In our small examples, that meant that we could pull components out of a bag and make many end-products; for large systems, it means that you can more easily rearrange the components as the business changes. This is a common problem being faced by many large and not-so-large companies.

For example, our hotel system might have a web server in Amsterdam, a central reservations system in Edinburgh, a credit card gateway in New Zealand, and local room allocation systems in each hotel world-wide. We would like to define a common connector, a common 'language' in which they all talk to one another, so that future reconfigurations need not involve writing many new adapters. Typical events in our hotels connector protocol will be customers arriving and leaving, paying bills; properties will include availability of rooms. The component kit architecture for such a network will have to specify:

 

Figure 47 Incompatible business processes.

This point about business rules is sometimes forgotten at the modelling stage. But it is very important: if one component of the system thinks a customer can have two rooms whereas another thinks each customer just has one, there will be confusion when they try to interoperate. And it is not just a question of static invariants: the sequences in which things should happen matters too. For example, imagine a company that comprises two divisions in different states as a result of a merger. In Great Britain the business demands payment before delivery is made, whilst in Eire payment is demanded after delivery is made. The different business régimes can be illustrated by the two state transition models in Figure 47. Problems will arise if these systems pass orders to each other to fulfil, because when a British customer orders a widget from the Dublin branch, they pass the request to the British system in the ordered state. That system assumes payment has been made and delivers - so that lucky John Bull never pays a penny. Obversely, poor Paddy Riley, who orders from the London branch, is asked to pay twice.