Several technology frameworks support distributed architectures, including .NET, J2EE and CORBA. Middleware is an system layer that supports and simplifies the development and execution of distributed applications, as a buffer between the applications and the network, managing the different components of the distributed system.
Middleware as an intermediator for distributed system.
The basis of a distributed architecture is its transparency, reliability, and availability.
Pros:
Resource sharing − hardware and software.
Openness − Flexibility for hardware and software from different vendors.
Concurrency − Concurrent processing to enhance performance.
Scalability − Increased throughput by adding new resources.
Fault tolerance − continuous operation after a fault has occurred.
Cons-
Complexity − more than centralised systems.
Security − More susceptible to external attack.
Manageability − More effort required for system management. Relates the complexity above.
Unpredictability − Unpredictable responses depending on the system organisation and network load.
1- Client-Server
The client-server architecture is the most common distributed system architecture. Major subsystems:
Client − This is the first process that issues a request to the second process: the server.
Server − The second process. Receives the request, carries it out, and sends a reply to the client.
The application is a set of services provided by servers. The servers need not to know about clients, but the clients must know the identity of servers.
There are two models based on the functionality of the client:
Thin-client model - all the processing and data management by the server. The client only runs the GUI software. Used for legacy systems migrated to client server architectures. Drawback is heavy processing load on both the server and the network.
Thick/Fat-client model - server in charge of the data management. The software on the client implements the application logic and the interactions with the system user. It is best when the capabilities of the client system are known before hand.
Problem is its complexity when compared to the thin client model.
Pros:
1- Separation of responsibilities such as user interface presentation and business logic processing.
2- Reusability of server components and potential for concurrency
3- Design and development of distributed applications made simple.
4- Migraion or integration of existing applications made easy.
5- Effective use of resources when many clients are accessing a high-performance server.
Cons:
1- Lack of heterogeneous infrastructure to deal with the requirement changes.
2- Security compromised
3- Limited server availability and reliability.
4- Fat clients with presentation and business logic together.
2- Multi-Tier
Multi-Tier is a client–server architecture that physically separates the functions of presentation, application processing and data management. This allows developers to change or add a specific layer, instead of reworking the entire application, enabling the creation of flexible and reusable applications.
The three-tier architecture is the most common instance of the multi-tier model, typically composed of a presentation tier, an application tier, and a data storage tier. It may run on another processor.
Presentation Tier - the topmost level of the application such as a webpage or a system GUI (graphical user interface), communicating with other tiers. Interaction with the end-user is the primary goal here.
Application Tier (Business Logic, Logic Tier, or Middle Tier) -manages the application, processes the commands and makes logical decisions, evaluation and calculations, processesing the data between the two surrounding layers.
Data Tier - information stored and retrieved from the database or file system, for processing and presentation to user. It includes the data persistence mechanisms (database servers, file shares, etc.) and provides API (Application Programming Interface) to the application tier which provides methods of managing the stored data.
Pros:
1- Better performance and simpler to manage than a thin-client approach.
2- Enhances the reusability and scalability −extra servers are added as demands increase.
3- multi-threading support, reducing network traffic.
4- maintainability and flexibility
Cons:
More critical server reliability and availability.
3 - Broker Architectural Style
Middleware architecturecoordinates and enables the communication between servers and clients. Object communication through a middleware system called an object request broker (software bus). Client and the server do not interact directly, but by proxy, which communicates with the mediator-broker. A server provides services by registering and publishing their interfaces with the broker and clients can request the services from the broker statically or dynamically by look-up.
Components of Broker Architectural Style:
Broker - responsible for coordinating communication, which include forwarding and dispatching the results and exceptions. It can be either an invocation-oriented service, a document or message - oriented broker to which clients send a message. Its functions range from locating a proper server, transmitting requests to sending responses back to clients and providing APIs for clients to request and servers to respond.
Stub - proxy for the client. Generated at compilation time, it provides additional transparency between them and the client, making a remote object appear like a local one.
Skeleton
Skeleton - starts at the service interface compilation on the server side. It is server's proxy. It encapsulates low-level system-specific networking functions and provides high-level APIs to communicate between the server and the broker, receiving the requests, unpacks them, unmarshals the method arguments, calls the suitable service and also marshals the result before sending it back to the client.
 |
No comments:
Post a Comment