280 likes | 415 Vues
This overview delves into distributed architecture, focusing on client/server, multi-tier, and broker models. Distributed systems comprise components connected through networks, emphasizing the importance of topology and communication modes. The client/server model, a prevalent architecture, separates responsibilities between client and server processes. The multi-tier model enhances scalability and reusability by introducing middle layers. Additionally, the broker architecture facilitates communication and service discovery. Each model presents unique advantages and challenges, notably in security, reliability, and extensibility.
E N D
Objective • Introduce Distributed Arch. • Client/Server • Multi-tier • Broker • Service Oriented • Discuss Pros and Cons
Introduction • Distributed System • Computers connected through network • Components are distributed • Two important issues: • Topology: the way components connected • Mode: the way they communicate with each other • Many models available • Each has pros and cons
Client/Server • The most commonly distributed system architecture • It has two communicating processes • Running on different processors • So, it is decomposed into two major subsystems: • Client • Server • Server process receives the request, carries it out, and sends a reply to the client
Client/Server • Two tier: client and server Back-end tier focuses on business logic and database management Front-end tier focuses on the user interaction
Client/Server Summary • Advantages: • Responsibility separation such as user interface presentation and business logic processing • Reusability of server components • Disadvantages: • Lack of heterogeneous infrastructure to deal with the requirement changes • Security complications • Server availability and reliability • Testability and scalability
Multi-tier • At least 3 tiers • Front-end tier - User interface presentation tier • Middle-end tier - Business logic tier • Manages business logic and execution • Back-end tier - DB management tier • Handles database
Multi-tier • Advantages of multi-tier over two-tier architecture. • Enhanced reusability and scalability by adding the middle tier • Middle layer is easy to change • Have portable and nonproprietary design and implementation • Middle layer can provide multi-threading support • Reduces traffic on the network • Cons • Difficulty in testing due to lack of testing tools • Adding multiple servers in the system makes the server reliability and availability even more critical
The Broker architectural pattern • Transparently distribute aspects of the software system to different nodes • An object can call methods of another object without knowing that this object is remotely located. • CORBA is a well-known open standard that allows you to build this kind of architecture.
Broker Style • Typical middleware arch. from mid 1990’s • Key Idea: • Service provider register services through broker • Clients discover services through broker • Clients submit requests to broker • Broker massages requests from clients and relay results from service provider • Typical examples: • CORBA, RPC, and RMI
Broker Architecture • Sub-components include • Broker – provide service registration • Stub (client-side proxy) – provide “stub” version of remote services, responsible for massaging messages • Skeleton (server-side proxy) – encapsulates lower network details, dispatch requests to local service objects • Bridges (optional) – for interaction with brokers • Network – for interaction with brokers
Broker Architecture • Broker • It coordinates communications, passing on request and returning replies • It stores all servers’ • registration information, their functionalities and location information • It provides APIs for clients to request, servers to respond, registering or unregistering server components, transferring messages, and locating servers.
Broker Architecture • Stub (Client-side proxy) • Mediates between the client and the broker and providing additional transparency between them. • To the client, a remote object appears like a local one. • The proxy hides inter-process communication at protocol level, marshals the parameter values, and unmarshals results from the server. • The stud is generated at compilation time and deployed at client side to be used as a proxy for client
Broker Architecture • Skeleton (server-side proxy) • It is also generated by service interface compilation and deployed at server side • Encapsulates low-level system specific networking functions like client proxy and provides high level APIs to mediate between the server and the broker • It receives and unpacks the requests, unmarshals the arguments, and calls the appropriate service. • When receives the result back from the server, it also marshals results before sending it back to the client.
Broker Architecture • Bridges • Optional component • Hide implementation details when two brokers interoperates • Can translate requests and parameters from one format to another
Broker Architecture • Network • Connects components using designated protocol standards such as • TCP/IP • OIIP • SOAP • The request carries data in a message document or method invocation format.
Broker Architecture • Example – Broker Model Service 1 2 1 Request Broker 1 3 Service 2 5 Response 4 Service 3 Broker 2
Broker Architecture • Connected Broker with client-server proxy Client Proxy Broker 1 Server Proxy Bridges Server Proxy Broker 2 Client Proxy Broker 3 Client Proxy Server Proxy
Summary – Broker Style • Advantages • Server component implementation and location transparency, • Changeability and extensibility, • Feasibility of run time changes of server components (add or remove server components) • Disadvantages: • Inefficiency due to the overhead of proxies • Low fault tolerance • Difficulty testing
Broker Example – CORBA • CORBA – Common Object Request Broker Architecture
Static Remote Invocation in CORBA • Steps to make things work • service published using IDL (Interface Definition Language) • service implemented by extending Servant class and registered by extending Service class • client implemented by locating name service and invoke service
Dynamic CORBA Invocation • Dynamic? • The invoker does not have to know all details of service provider, e.g., parameter format • Information is disclosed by broker at run time • Relies on 3 components • CORBA Interface Repository (IFR) • Dynamic Invocation Interface (DII) • Dynamic Skeleton Interface (DSI)
Message Broker Architecture • Message: formatted information e.g., XML