Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Distributed Configuration 1. T.C Software + T.C. Hardware = One OS in a multiprocessor system (DOS) Communication: shared memory 2. T.C. Software + L.C. Hardware = Homogeneous OS in network (DOS) Communication: message passing 3. L.C. Software + L.C. Hardware = Heterogeneous OS in network (NOS) Communication: file sharing, network commands 1(DOS) 2(DOS) 3(NOS) Transparency very high high low Multi OS no no yes OS Copies 1 >1 >1 Communication shared memory messages files Resource Management global, central global, distributed, local Scalability no reasonable yes Openness no no yes NOS & DOS Communications in NOS & DOS NOS->DOS transparency • • • L.C. Software + L.C. Hardware + Middleware: NOS->DOS : near really distributed system + complexity reduction Middlewares • • 1. distributed file systems file level transparency (remote file using) • • 2. RPC process level transparency (remote procedure call) • • 3. distributed objects object level transparency (remote object call) • • 4. distributed documents (web) document level transparency (remote document call) Communiction in middlewares like ORB T.C. software + L.C. hardware -> T.C software + T.C harware why? communication by shared data (control mechanisms: semaphores , monitors) is easier communication by message (control mechanisms : algorithms: reliable group communication) Solution: virtual memory (DSM) Distrubution Architectures Multiprocessor architectures Senso r p rocessor Senso r con trol p rocess Traffic flo w p rocessor Disp lay p rocess Traffic ligh t con trol p rocessor Ligh t con trol p rocess Traffic ligh ts Traffic flowsensors and cameras • Op erato r con soles A multiprocessor traffic control system characteristics • Simplest distributed system model. • System composed of multiple processes which may execute on different processors. • Architectural model of many large real-time systems. • Distribution of process to processor may be pre-ordered or may be under the control of a dispatcher. Client-server architectures c3 c2 c4 c12 c11 s4 s1 c1 Server p rocess c10 c5 s2 c6 c7 Client p rocess s3 c9 c8 Computers in a C/S network c1 CC1 c2 CC2 c3, c4 CC3 Netwo rk s1 , s2 s3 , s4 SC2 Server comp uter SC1 c5, c6, c7 c8, c9 CC4 CC5 c10 , c11 , c12 CC6 Client comp uter characteristics -The application is modelled as a set of services that are provided by servers and a set of clients that use these services. -Clients know of servers but servers need not know of clients. -Clients and servers are logical processes Film and picture library Logical design of C/S characteristics Presentation layer presenting the results of a computation to system users and with collecting user inputs. Application processing layer providing functionality e.g., in a banking system, banking functions such as open account, close account, etc. Data management layer managing the system databases. Thin and fat clients characteristics Thin:Used when legacy systems are migrated to client server architectures. The legacy system acts as a server with a graphical interface implemented on a client. Fat:suitable for new C/S systems where the capabilities of the client system are known in advance. More complex than a thin client model. Fat C/S AT M AT M Account serv er Telep rocessing m on it o r AT M AT M Cust o mer acco unt dat abase New Approach (using mobile code: applet, activex Fat + Thin: A 3-tier C/S architecture characteristics -each of the application architecture layers may execute on a separate processor. -better performance than a thin-client approach and is simpler to manage than a fat-client approach. -A more scalable architecture - as demands increase, extra servers can be added. An internet banking system Client Client HTT P interaction SQL query Account serv ice p rov isio n Client Client Database server Web server SQL Custo mer acco unt database Use of C/S architectures Architecture Applications thin -Legacy system applications where separating application processing and data management is impractical. -Computationally-intensive applications such as compilers with little or no data management. -Data-intensive applications (browsing and querying) with little or no application processing. fat -Applications where application processing is provided by off-the-shelf software (e.g. Microsoft Excel) on the client. -Applications where computationally-intensive processing of data (e.g. data visualisation) is required. Three-tier -Large scale applications with hundreds or thousands of clients -Applications where both the data and the application are volatile. -Applications where data from multiple sources are integrated. Distributed object architectures o1 o2 o3 o4 S (o 1) S (o 2) S (o 3) S (o 4) Object request brok er o5 o6 S (o 5) S (o 6) characterictics No distinction between clients and servers. Each distributable entity is an object that provides services to other objects and receives services from other objects. Object communication: a middleware:ORB. More complex to design than C/S systems. Advantages allows to delay design decisions: where and how services should be provided. a very open system architecture: new resources to be added to it. The system is flexible and scaleable. reconfigure the system dynamically with objects migrating across the network as required. A data mining system Dat abase 1 In t egrat or 1 Dat abase 2 Rep ort gen. Visualiser In t egrat or 2 Dat abase 3 Disp lay new types of relationship to be mined by adding new integrator objects.