1.6 Treaty Relationships

If an organization's overall architecture could be described as a single fortress, we wouldn't need the software fortress model. We could use simple three-tier (or N- tier ) diagrams to explain our architecture. The reason we need the software fortress model is that enterprises are not mono-lithic. They have many software fortresses. It is the relationship between these different fortresses that we are trying to model and understand.

When one or more fortresses work together to accomplish a higher-level activity, we say that the fortresses are allies of each other. They coordinate their work through treaty relationships.

The fact that the cooperating fortresses are allies doesn't mean that they trust each other. They still communicate using drawbridges , and those communications are still closely monitored by guards . Other than the specific relationship defined by the treaty, the fortresses still consider each other hostile entities.

There are two types of treaties : simple and complex. A simple treaty can be implemented directly between two fortresses, with one fortress making requests to the other through an approved drawbridge channel. A common example is the treaty between a presen tation and a business application fortress, allowing, say, Web clients to process banking transactions.

A complex treaty requires a treaty management fortress. A treaty management fortress may be required for any number of reasons. It may be required because many fortresses are involved in the treaty. For example, a customer order may require several business application fortresses to work together (one authorizing credit cards, another updating inventory, yet another processing the shipment). A treaty management fortress may be required because of incompatibilities in the ally drawbridges, such as one using Microsoft's MSMQ and the other using J2EE's RMI/IIOP.

Figure 1.4 pictorially differentiates between simple and complex treaties.

Figure 1.4. Simple versus Complex Treaties