1 2 System types Distributed systems • Personal systems that are designed to • Virtually all large computer-based run on a personal computer or systems are now distributed systems workstation • Information processing is distributed • Distributed systems where the over several computers rather than system software runs on a loosely confined to a single machine integrated group of cooperating • Distributed software engineering is processors linked by a network now very important Distributed system 3 4 Distributed system disadvantages characteristics • Resource sharing • Complexity • Concurrency • Security • Scalability • Manageability • Fault tolerance • Unpredictability • Transparency 1
Distributed Systems Issues in distributed system 5 Architectures design • Architectural design for software that executes on more than one processor 7 8 Topics covered Distributed systems architectures • Multiprocessor architectures • Multiprocessor architectures – System composed of multiple processes that • Client-server architectures may execute on different processors • Distributed object architectures • Client-server architectures – Distributed services which are called on by • CORBA clients. Servers that provide services are treated differently from clients that use services • Distributed object architectures – No distinction between clients and servers. Any object on the system may provide and use services from other objects 2
9 10 Multiprocessor architectures A multiprocessor traffic control system • Simplest distributed system model • System composed of multiple processes which may execute on different processors Traffic flow Traffic light control Sensor processor processor processor • Architectural model of many large real- Light time systems Sensor Display control control process process process • Distribution of process to processor may be pre-ordered or may be under the control of a dispatcher Traffic lights Traffic flow sensors Operator consoles and cameras 11 12 Client-server architectures A client-server system • The application is modelled as a set of services that are provided by servers and a c3 set of clients that use these services c2 c4 c12 c11 • Clients know of servers but servers need Server process c1 s1 s4 not know of clients c10 • Clients and servers are logical processes c5 Client process • The mapping of processors to processes is s2 s3 c9 not necessarily 1 : 1 c6 c8 c7 3
13 14 Computers in a C/S network Thin and fat clients • Thin-client model – In a thin-client model, all of the application c1 c2 processing and data management is carried out c3, c4 CC1 CC2 CC3 on the server. The client is simply responsible for running the presentation software. Network Server s3, s4 s1, s2 • Fat-client model computer SC1 SC2 – In this model, the server is only responsible for data management. The software on the client implements the application logic and the Client computer c5, c6, c7 interactions with the system user. c8, c9 c10, c11, c12 CC4 CC5 CC6 15 16 Thin and fat clients Thin client model • Used when legacy systems are migrated to client server Presentation Server architectures. Thin-client Data management Client model – The legacy system acts as a server in its Application processing own right with a graphical interface implemented on a client Presentation Application processing Server • A major disadvantage is that it places Fat-client Client model Data a heavy processing load on both the management server and the network 4
17 18 Fat client model A client-server ATM system • More processing is delegated to the client as the application processing is locally executed ATM • Most suitable for new C/S systems where the capabilities of the client system are ATM Account server known in advance Tele- Customer • More complex than a thin client model processing account especially for management. New versions of monitor database ATM the application have to be installed on all clients ATM 19 20 Layered application architecture Application layers • Presentation layer – Concerned with presenting the results of a Presentation layer computation to system users and with collecting user inputs • Application processing layer – Concerned with providing application specific Application processing functionality e.g., in a banking system, banking layer functions such as open account, close account, etc. • Data management layer Data management – Concerned with managing the system databases layer 5
21 22 Three-tier architectures A 3-tier C/S architecture • In a three-tier architecture, each of the application architecture layers may execute on a separate processor • Allows for better performance than a thin- Presentation Server Server client approach and is simpler to manage Client Data Application than a fat-client approach management processing • A more scalable architecture - as demands increase, extra servers can be added 23 24 An internet banking system Use of C/S architectures Client HTTP interaction Web server Database server SQL query Customer Client Account service SQL account provision database Client Client 6
25 26 Distributed object architectures Distributed object architecture • There is no distinction in a distributed object architectures between clients and o1 o2 o3 o4 servers S (o1) S (o2) S (o3) S (o4) • Each distributable entity is an object that provides services to other objects and receives services from other objects Software bus • Object communication is through a middleware system called an object o5 o6 request broker (software bus) S (o6) • However, more complex to design than C/S S (o5) systems Advantages of distributed object Uses of distributed object 27 28 architecture architecture • As a logical model that allows you to • It allows the system designer to delay structure and organize the system. In this decisions on where and how services should case, you think about how to provide be provided application functionality solely in terms of • It is a very flexible and scaleable system services and combinations of services architecture that allows new resources to • As a flexible approach to the be added to it as required implementation of client-server systems. • It is possible to reconfigure the system The logical model of the system is a client- server model but both clients and servers dynamically with objects migrating across are realized as distributed objects the network as required communicating through a software bus 7
29 30 Middleware CORBA • Software that manages and supports • Common Object Request Broker the different components of a Architecture (CORBA) is an international standard for an Object Request Broker - distributed system. In essence, it sits middleware to manage communications in the middle of the system between distributed objects • Middleware is usually off-the-shelf • Several implementation of CORBA are available rather than specially written • Distributed Component Object Model software (DCOM) is an alternative approach by Microsoft to object request brokers • CORBA has been defined by the Object Management Group (OMG) 31 32 Application structure CORBA application structure • Application objects Application Horizontal Domain • Standard objects, defined by the OMG, objects CORBA facilities facilities for a specific domain e.g. insurance • Fundamental CORBA services such as directories and security management Object request broker • Horizontal (i.e. cutting across applications) facilities such as user interface facilities CORBA services 8
33 34 CORBA standards CORBA objects • CORBA objects are comparable, in • An object model for application objects principle, to objects in C++ and Java – A CORBA object is an encapsulation of state • They MUST have a separate interface with a well-defined, language-neutral interface definition that is expressed using a defined in an IDL (interface definition language) common language (IDL) similar to C++ • An object request broker that manages • There is a mapping from this IDL to programming languages (C++, Java, etc.) requests for object services • Therefore, objects written in different • A set of general object services of use to languages can communicate with each other many distributed applications 35 36 Object request broker (ORB) ORB-based object communications • The ORB handles object communications. It knows of all objects in the system and o1 o2 their interfaces • Using an ORB, the calling object binds an S (o1) S (o2) IDL stub that defines the interface of the called object • Calling this stub results in calls to the ORB IDL IDL which then calls the required object stub skeleton through a published IDL skeleton (links the interface to the service implementation) Object Request Broker 9
Recommend
More recommend