Nội dung

Lecture Notes Lecture 8 – DISTRIBUTED SOFTWARE ARCHITECTURE An architecture style (also known as an “architecture pattern”) abstracts the common properties of a family of similar designs. Define a family of systems in terms of a pattern of its structural organization. Components Of A Style The key components of an architecture style are: • Elements/components that perform functions required by a system • Connectors that enable communication, coordination, and cooperation among elements • Constraints that define how elements can be integrated to form the system • Attributes that describe the advantages and disadvantages of the chosen structure Categories of Architectural Styles • • • • • • • Hierarchal Software Architecture – Layered Distributed Software Architecture – Client Server – SOA Data Flow Software Architecture – Pipe n Filter – Batch Sequential Event Based Software Architecture Data Centered Software Architecture – Black board – Shared Repository Interaction-Oriented Software Architectures – Model View Controller Component-Based Software Architecture DISTRIBUTED SOFTWARE ARCHITECTURE A distributed system is a collection of computational and storage devices connected through a communications network. In this type of system, data, software, and users are distributed. The subsystems or components within a distributed system communicate with each other using a number of methods including message passing, remote procedure calls, and remote method invocation. Two important elements of designing a distributed system are: network topology, the way in which entities are organized to form a connected network; and communications mode, the method by which components communicate with each other. Many systems in the real world are naturally distributed. These systems are widely used in large enterprise environments such as a database system that enables data to be accessed remotely, a B2B system with its distributed suppliers and clients, or an SAP system to manage distributed resources. Distributed systems are everywhere. A distributed system can be modeled by the client-server architecture, and this forms the basis for multitier architectures. Alternatives are the broker architecture such as CORBA, and the service-oriented architecture (SOA) such as web services and grid services. Key features of a distributed architecture are its service location transparency and its services reliability and availability. Additionally, there are several technology frameworks to support distributed architectures, including .NET, J2EE, CORBA, .NET web services, AXIS Java web services, and GloBus grid services. Client Server Architectural Style The client-server model is the most commonly distributed system architecture. It is based on two communicating processes, usually running on different processors, and thus decomposes a system into two major subsystems: client and server. The first process, the client, issues a request to the second process, the server. The server process receives the request (serving data from a database, printing a document), carries it out, and sends a reply to the client. A system that follows the client–server pattern is organized as a set of services and associated servers, and clients that access and use the services. The major components of this model are: 1. A set of servers that offer services to other components. Examples of servers include print servers that offer printing services, file servers that offer file management services, and a compile server, which offers programming language compilation services. 2. A set of clients that call on the services offered by servers. There will normally be several instances of a client program executing concurrently on different computers. 3. A network that allows the clients to access these services. Most client–server systems are implemented as distributed systems, connected using Internet protocols. Client–server architectures are usually thought of as distributed systems architectures but the logical model of independent services running on separate servers can be implemented on a single computer. Again, an important benefit is separation and independence. Services and servers can be changed without affecting other parts of the system. Clients may have to know the names of the available servers and the services that they provide. However, servers do not need to know the identity of clients or how many clients are accessing their services. Clients access the services provided by a server through remote procedure calls using a request-reply protocol such as the http protocol used in the WWW. Essentially, a client makes a request to a server and waits until it receives a reply. Two-Tier Client–Server Architectures A two-tier client–server architecture is the simplest form of client–server architecture. The system is implemented as a single logical server plus an indefinite number of clients that use that server. This is illustrated in Figure 18.8, which shows two forms of this architectural model: 1. A thin-client model, where the presentation layer is implemented on the client and all other layers (data management, application processing, and database) are implemented on a server. The client software may be a specially written program on the client to handle presentation. More often, however, a web browser on the client computer is used for presentation of the data. 2. A fat-client model, where some or all of the application processing is carried out on the client. Data management and database functions are implemented on the server. The advantage of the thin-client model is that it is simple to manage the clients. This is a major issue if there are a large number of clients, as it may be difficult and expensive to install new software on all of them. If a web browser is used as the client, there is no need to install any software. The disadvantage of the thin-client approach, however is that it may place a heavy processing load on both the server and the network. The server is responsible for all computation and this may lead to the generation of significant network traffic between the client and the server. Implementing a system using this model may therefore require additional investment in network and server capacity. However, browsers may carry out some local processing by executing scripts (e.g., Javascript) in the web page that is accessed by the browser. Multi-Tier Client–Server Architectures The fundamental problem with a two-tier client–server approach is that the logical layers in the system— presentation, application processing, data management, and database—must be mapped onto two computer systems: the client and the server. This may lead to problems with scalability and performance if the thin-client model is chosen, or problems of system management if the fat-client model is used. To avoid some of these problems, a ‘multi-tier client–server’ architecture can be used. In this architecture, the different layers of the system, namely presentation, data management, application processing, and database, are separate processes that may execute on different processors. The three-tier client–server model can be extended to a multi-tier variant, where additional servers are added to the system. This may involve using a web server for data management and separate servers for application processing and database services. Multi-tier systems may also be used when applications need to access and use data from different databases. In this case, you may need to add an integration server to the system. The integration server collects the distributed data and presents it to the application server as if it were from a single database. As I discuss in the following section, distributed component architectures may be used to implement multitier client–server systems.