Middleware to Build Distributed Applications The point of middleware is to make life easier for the distributed systems implementer,

but how? In this chapter we try to answer this question. The chapter has three parts. In the first, we look at distributed processing from the point of view of the business. This part is trying to answer the question, what is middleware for? The second part discusses tiers. The path from end user to database typically involves several, distinct logical layers, each with a different function. These are tiers. Note that they are logical tiers, which may be implemented in varying numbers of physical systems; one tier does not necessarily mean one physical system. The question is, what tiers should there be? The final part is about distributed architecture. This part is trying to answer the question, how do we assemble the tiered components into a large-scale structure? 6.1. What is middleware for? From a user's perspective, there are four large groups of distributed processing technology: 1. Transaction technology, or more generally, technology that is part of the implementation of business processes and business services 2. Information retrieval technology, or more generally, technology for supporting management oversight and analysis of business performance 3. Collaborative technology, like e-mail, for helping people work together 4. Internal IT distributed services such as software distribution or remote systems operations 6.2. Tiers When people first started writing online programs, they quickly recognized that such programs had three tiers: a presentation tier to do with formatting and controlling the user interface, a logic tier that decides what to do with the input data, and a database tier that controls access to the data. In a distributed architecture, it is common for these tiers to be run on different physical machines. Furthermore, it was recognized that if the local branch office had a server, which talked to a departmental server, which talked to an enterprise wide server, additional tiers would be defined. So was born the notion of n-tier architectures. In this section we discuss the degree to which these tiers really should be split and why. 6.2.1. The presentation tier Originally online access was through terminals. Later there were workstations. As a variant on the theme, there were branch office networks with small LANs in each branch and a WAN connection to the central system. Processing in the branch was split between the branch server and the branch workstations. Now of course there is the Internet. 6.3. Architectural choices Categories such as transactional, information retrieval, and so forth don't lead us to different distributed architectures. Rather, the architecture must be capable of working with all of them.

There are three common distributed architecture patterns in use: