Introduction To Distributed systems

Distributed Computing System

Distributed computing is a computing concept that, in its most general sense, refers to multiple computer systems working on a single problem. In distributed computing, a single problem is divided into many parts, and each part is solved by different computers. As long as the computers are networked, they can communicate with each other to solve the problem. If done properly, the computers perform like a single entity.

The ultimate goal of distributed computing is to maximize performance by connecting users and IT resources in a cost-effective, transparent and reliable manner. It also ensures fault tolerance and enables resource accessibility in the event that one of the components fails.

Distributed System

A distributed system is a network that consists of autonomous computers that are connected using a distribution middleware. They help in sharing different resources and capabilities to provide users with a single and integrated coherent network.

The key features of a distributed system are:

• Components in the system are concurrent. A distributed system allows resource sharing, including software by systems connected to the network at the same time.
• There can be multiple components, but they will generally be autonomous in nature.
• A global clock is not required in a distributed system. The systems can be spread across different geographies.
• Compared to other network models, there is greater fault tolerance in a distributed model.
• Price/performance ratio is much better.

The key goals of a distributed system include:

• Transparency: Achieving the image of a single system image without concealing the details of the location, access, migration, concurrency, failure, relocation, persistence and resources to the users
• Openness: Making the network easier to configure and modify
• Reliability: Compared to a single system, a distributed system should be highly capable of being secure, consistent and have a high capability of masking errors.
• Performance: Compared to other models, distributed models are expected to give a much-wanted boost to performance.
• Scalability: Distributed systems should be scalable with respect to geography, administration or size.

Challenges for distributed systems include:

• Security is a big challenge in a distributed environment, especially when using public networks.
• Fault tolerance could be tough when the distributed model is built based on unreliable components.
• Coordination and resource sharing can be difficult if proper protocols or policies are not in place.
• Process knowledge should be put in place for the administrators and users of the distributed model.

Computer-based systems can be mainly divided into 2 types, according to the distribution of the components

    1.  Standalone systems (or commonly referred to as desktop applications) 

    2.  Distributed systems.

Standalone system	Distributed system
All the components are executed within a single device	The components are distributed and executed in multiple devices
Do not need a network	Need a network
Usually, one or tightly coupled set of technologies are used to develop (JAVA, .NET)	Multiple and loosely coupled set of technologies are used to develop (HTML +CSS + JS + PHP)

1. Standalone  systems 

A standalone computer is exactly what its name implies: a computer that stands on its own. Any tasks or data associated with that computer stay inside it and are not accessible from anywhere else. Any peripherals, such as printers, must be directly connected to it in order to work.

Network

A standalone's counterpart is the network. Basically, a network is a group of separate computers connected together. A peer-to-peer network is the simplest form because it simply hooks computers together in a circular fashion. Other methods, such as client/server, are controlled by a central area called a hub.

Standalone Advantages

One advantage of a standalone computer is damage control. For example, if something goes wrong, only the standalone will be affected. Simplicity is another advantage because it takes a lot less expertise to manage one computer than it does to set up or troubleshoot several. Standalone computers can also be more convenient. For example, printing on a network may require you to walk some distance from the computer to the printer. Inversely, any peripherals on a standalone have to be in arm's reach. Finally, a standalone does not affect other computer users. With a network, one user may waste space by watching movies or listening to music. In turn, everyone else using the network may see slower computer performance.

Standalone Disadvantages

Standalone computers have drawbacks. First of all, users are restricted to a single computer. On a network, users can access their files from any connected computer. Second, the same software cannot be installed simultaneously. While a network allows everything to be changed at once, a standalone requires that any new programs must be set up one-by-one, which is much more time-consuming. Third, it is much cheaper to connect every computer to one printer than to buy a printer for each standalone computer. Finally, standalone are harder to monitor. On a network, certain software can be used to simultaneously view each user's activity.

    2. Distributed Systems 

A distributed system is a collection of independent computers that appear to the users of the system as a single coherent system.

Examples

• The world wide web – information, resource sharing
• Clusters, Network of workstations  Distributed manufacturing system (e.g., automated assembly line)
• The network of branch office computers - Information system to handle automatic processing of orders
• A network of embedded systems
• New Cell processor (PlayStation 3)

Advantages

• Economics
• Speed 
• Inherent distribution
• Reliability
• Incremental growth

Disadvantages

• Software
• Network
• More components to fail
• Security

Elements of distributed systems

• Processing components
• Data networks for components to communicate - Including the components who are dedicated for processing the communication, called connectors 
• Data stores (databases) and Data
• The configuration of the above elements

There are different types of services, which can be gained from distributed systems

• Mail service (SMTP, POP3, IMAP)
• File transferring and sharing (FTP)
• Remote logging (telnet)
• Games and multimedia (RTP, SIP,H.26x)
• Web (HTTP) - The service of the web gained through the internet is called the WWW

Browser-based(web application) and Non-Browser-based(client/server application) clients of distributed systems

An application that runs on the client side and accesses the remote server for information is called a client/server application whereas an application that runs entirely on a web browser is known as a web application. The client-server always makes requests to the remote server to get some information. The user interaction with the server is always through a user interface or application on the client side. The user interaction in a web application is through a web browser. A client-server application can be platform specific as well as cross-platform depending on the programming language used. A web application is a platform independent because they require only a web browser. The cross-platform language makes an application look native to the platform or the operation system of the client.

The client/server application is always installed on the client’s computer, unlike a web application. Web applications can run on the browsers directly and hence do not require any installation. A client-server application uses a two-tier architecture whereas a web application uses a multi-tier architecture which consists of; user client, middle tier, and application server. A web application uses a single-user system, unlike a client-server application which uses two users: client and server.

A web application is hosted in a browser-controlled environment, or it is often programmed in a language that supports the browser. JavaScript is the most widely used browser-supported language. In client/server applications, the server machine is a host that runs single or multiple-server programs sharing their resources with clients. A client always requests from server information or content without sharing any of its resources.

In a client/server application, it is difficult to test scripting errors whereas in web applications it is easy to test scripting errors. Specific types of clients used in a client/server model are web browsers, email clients, and online chat clients. The types of servers used are web servers, FTP servers, application servers, database servers, name servers, file servers, mail servers, terminal, and print servers.

In a client/server model, the server often gets overloaded as the number of simultaneous client requests increases. In a web application, this problem is ruled out as a compatible web browser is all that is needed to get the web application working. Some of the examples of web applications include Yahoo mail, Gmail, WebOffice, Google Apps, Microsoft Office Live, WebEx, etc.

• A client/server application uses a two-tier architecture whereas a web application uses multi-tier architecture.
• In a client/server application, the user interaction with the server is mainly through a user interface whereas in a web application the user interaction is through a compatible web browser.
• A client/server application lacks robustness because if a server fails, the requests cannot be completed whereas a web application exhibits robustness.
• A client/server application requires installation on the client’s machine whereas a web application can run directly from a compatible web browser.
• In a client/server model, the server may become overloaded with the increasing client requests which result in low performance whereas multiple users can use a web application at the same time and also deliver superior performance.

Types of Web-based Systems

• Web sites
• Web applications
• Web services and client apps
• Rich Internet Applications (RIAs)/Rich Web-based Applications (RiWAs)

Web sites

A website is a collection of publicly accessible, interlinked Web pages that share a single domain name. Websites can be created and maintained by an individual, group, business or organization to serve a variety of purposes. Together, all publicly accessible websites constitute the World Wide Web.

A website is also known as a web presence.

Web application

A web application is a computer program that utilizes web browsers and web technology to perform tasks over the Internet.

Web services and client apps

A web service is any piece of software that makes itself available over the internet and uses a standardized XML messaging system. XML is used to encode all communications to a web service. For example, a client invokes a web service by sending an XML message, then waits for a corresponding XML response. As all communication is in XML, web services are not tied to any one operating system or programming language—Java can talk with Perl; Windows applications can talk with Unix applications.

Rich Internet Application

is web applications that have the features and functionality of traditional desktop applications. 

RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e., maintaining the state of the program, the data etc) back on the application server.

RIAs typically: 

• run in a web browser, or do not require software installation. 
• run locally in a secure environment called a sandbox

Architectural Models 

• Client-server model 
• Peer-to-peer 

Client/Server Systems

In client-server systems, the client requests a resource and the server provides that resource. A server may serve multiple clients at the same time while a client is in contact with only one server. Both the client and server usually communicate via a computer network and so they are a part of distributed systems.

Peer to Peer Systems

The peer to peer systems contains nodes that are equal participants in data sharing. All the tasks are equally divided between all the nodes. The nodes interact with each other as required as share resources. This is done with the help of a network.

Monolithic vs. Microservices Architecture

When developing a server-side application you can start it with a modular hexagonal or layered architecture which consists of different types of components:

• Presentation — responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIs).
• Business logic — the application’s business logic.
• Database access — data access objects responsible for access the database.
• Application integration — integration with other services (e.g. via messaging or REST API).

Despite having a logically modular architecture, the application is packaged and deployed as a monolith. Benefits of Monolithic Architecture

• Simple to develop.
• Simple to test. For example you can implement end-to-end testing by simply launching the application and testing the UI with Selenium.
• Simple to deploy. You just have to copy the packaged application to a server.
• Simple to scale horizontally by running multiple copies behind a load balancer.

In the early stages of the project it works well and basically most of the big and successful applications which exist today were started as a monolith.

Drawbacks of Monolithic Architecture

• This simple approach has a limitation in size and complexity.
• Application is too large and complex to fully understand and made changes fast and correctly.
• The size of the application can slow down the start-up time.
• You must redeploy the entire application on each update.
• Impact of a change is usually not very well understood which leads to do extensive manual testing.
• Continuous deployment is difficult.
• Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements.
• Another problem with monolithic applications is reliability. Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.
• Monolithic applications has a barrier to adopting new technologies. Since changes in frameworks or languages will affect an entire application it is extremely expensive in both time and cost.

Microservices Architecture

The idea is to split your application into a set of smaller, interconnected services instead of building a single monolithic application. Each microservice is a small application that has its own hexagonal architecture consisting of business logic along with various adapters. Some microservices would expose a REST, RPC or message-based API and most services consume APIs provided by other services. Other microservices might implement a web UI.

The Microservice architecture pattern significantly impacts the relationship between the application and the database. Instead of sharing a single database schema with other services, each service has its own database schema. On the one hand, this approach is at odds with the idea of an enterprise-wide data model. Also, it often results in duplication of some data. However, having a database schema per service is essential if you want to benefit from microservices, because it ensures loose coupling. Each of the services has its own database. Moreover, a service can use a type of database that is best suited to its needs, the so-called polyglot persistence architecture.

Some APIs are also exposed to the mobile, desktop, web apps. The apps don’t, however, have direct access to the back-end services. Instead, communication is mediated by an intermediary known as an API Gateway. The API Gateway is responsible for tasks such as load balancing, caching, access control, API metering, and monitoring.

The Microservice architecture pattern corresponds to the Y-axis scaling of the Scale Cube model of scalability.

Benefits of Microservices Architecture

• It tackles the problem of complexity by decomposing application into a set of manageable services which are much faster to develop, and much easier to understand and maintain.
• It enables each service to be developed independently by a team that is focused on that service.
• It reduces barrier of adopting new technologies since the developers are free to choose whatever technologies make sense for their service and not bounded to the choices made at the start of the project.
• Microservice architecture enables each microservice to be deployed independently. As a result, it makes continuous deployment possible for complex applications.
• Microservice architecture enables each service to be scaled independently.

Drawbacks of Microservices Architecture

• Microservices architecture adding a complexity to the project just by the fact that a microservices application is a distributed system. You need to choose and implement an inter-process communication mechanism based on either messaging or RPC and write code to handle partial failure and take into account other fallacies of distributed computing.
• Microservices has the partitioned database architecture. Business transactions that update multiple business entities in a microservices-based application need to update multiple databases owned by different services. Using distributed transactions is usually not an option and you end up having to use an eventual consistency based approach, which is more challenging for developers.
• Testing a microservices application is also much more complex then in case of monolithic web application. For a similar test for a service you would need to launch that service and any services that it depends upon (or at least configure stubs for those services).
• It is more difficult to implement changes that span multiple services. In a monolithic application you could simply change the corresponding modules, integrate the changes, and deploy them in one go. In a Microservice architecture you need to carefully plan and coordinate the rollout of changes to each of the services.
• Deploying a microservices-based application is also more complex. A monolithic application is simply deployed on a set of identical servers behind a load balancer. In contrast, a microservice application typically consists of a large number of services. Each service will have multiple runtime instances. And each instance need to be configured, deployed, scaled, and monitored. In addition, you will also need to implement a service discovery mechanism. Manual approaches to operations cannot scale to this level of complexity and successful deployment a microservices application requires a high level of automation.

 Model-View-Controller (MVC) 

Model

The Model handles the state of the application. The state is what your application is about. If your application is a forum, your Model might contain Class::DBI objects representing threads, users and postings. The Model does not know anything about HTML, or web servers or anything like that. It just supplies ways to query the state, and ways to change that state.

View

The View is the representation of the user interface. Usually there are many (possibly nested) Views in a single application. A view can query the model, but it is not supposed to change the state. In web based MVC systems, a view can be implemented using a template that renders an HTML page. In our hypothetical forum application, the Views would be the templates for rendering a full thread, the login page, the posting page etc.

Controller

User actions on the View are send to the Controller. In a web environment, this is usually done by having the Controller handle the incoming HTTP requests.

The Controller receives user requests, and translates them into actions that the Model should take. Then it selects the appropriate View to handle the response.

It is possible to have more than one Controller, but most web application frameworks I’ve used assume you only have one.

What’s so useful about it

Separation of requests and pages

Since the Controller is in charge of handling the requests and selecting an appropriate page (View), there is no immediate coupling between the request made by the user and the resulting page.

This turns out to be very useful if the page-flow in the application is complex, but even for simple applications the Controller is a good place to handle common actions - authentication and session management can be handled in the Controller, for instance.

Views are dumb

Since all code that does anything except building a nice page for the user is outside the View objects, changing the layout does not involve touching the logic of the application. Since the part of the application that changes the most during and after development is the layout, this means much less chance of adding bugs.

Shielding of the Model implementation

Since all actions on the application state are handled by the Model, it is possible to change the Model’s implementation without touching the user interface, as long as the Model’s public API doesn’t change. (but see L<Coupling between View and Model|Coupling between View and Model>).

Problems and limitations

What goes where

Sometimes is just hard to figure out where a specific piece of the application is supposed to go. Especially dividing the Model from the Controller can be hard. As a rule of thumb, the Controller should be as minimal as possible - it is only responsible for translating HTTP requests into Model actions and selecting the right View - the Model should provide all the behavior it can without handling the HTTP requests or output formatting details.

Coupling between View and Model

One problem with having the View and Controller querying the Model is that changing the Model’s public API means you also have to adapt the Controller and Views that act on it (L<Note 2|Note 2>). Adapting the Controller is usually not too much work, but changing a large number of Views will be annoying.

The Model Model View Controller pattern tries to minimize the impact of these changes by using two Models: a Domain Model and an Application Model - the View only queries the Application Model, and the Application model can query the Domain Model. The Application Model usually partly generated by the GUI design tools. I haven’t used this pattern at all, so I don’t know how useful it is for web applications

Lots of objects

Creating an MVC application can result in more classes and objects than a “page-based” system. That means more design up front. On the other hand, a well designed MVC system will be easier to adapt and expand, because the code will be separated better.

Example: a HTTP request.

Figure 1. A sequence diagram of a single request/response pair

Notice that the Controller does not handle the communication between the View and the Model: the Views make direct requests to the Model.

Communication techniques/technologies

• Functional oriented communication - RPC/RMI, CORBA
• Message Oriented communication - SOAP
• Resource oriented communication - REST

Definition of RPC

Remote Procedure Call (RPC) is a programming language feature devised for the distributed computing and based on semantics of local procedure calls. It is the most common forms of remote service and was designed as a way to abstract the procedure call mechanism to use between systems connected through a network. It is similar to IPC mechanism where the operating system allows the processes to manage shared data and deal with an environment where different processes are executing on separate systems and necessarily require message-based communication.

Let’s understand how RPC is implemented through the given steps:

·         The client process calls the client stub with parameters, and its execution is suspended until the call is completed.

·         The parameters are then translated into machine-independent form by marshalling through client stub. Then the message is prepared which contain the representation of the parameters.

·         To find the identity of the site the client stub intercommunicate with name server at which remote procedure exists.

·         Using blocking protocol the client stub sends the message to the site where remote procedure call exists. This step halt the client stub until it gets a reply.

·         The server site receives the message sent from the client side and converts it into machine specific format.

·         Now server stub executes a call on the server procedure along with the parameters, and the server stub is discontinued till the procedure gets completed.

·         The server procedure returns the generated results to the server stub, and the results get converted into machine-independent format at server stub and create a message containing the results.

·         The result message is sent to the client stub which is converted back into machine specific format suitable for the client stub.

·         At last client, stub returns the results to the client process.

Definition of RMI

Remote Method Invocation (RMI) is similar to RPC but is language specific and a feature of java. A thread is permitted to call the method on a remote object. To maintain the transparency on the client and server side, it implements remote object using stubs and skeletons. The stub resides with the client and for the remote object it behaves as a proxy.

When a client calls a remote method, the stub for the remote method is called. The client stub is accountable for creating and sending the parcel containing the name of a method and the marshalled parameters, and the skeleton is responsible for receiving the parcel.The skeleton unmarshals parameters and invokes the desired method on the server. The skeleton marshals the given value (or exceptions) with the parcel and sends it to client stub. The stub reassembles the return parcel and sends it to the client.

In Java, the parameters are passed to methods and returned in the form of reference. This could be troublesome for RMI service since not all objects are possibly remote methods. So, it must determine which could be passed as reference and which could not.

Java uses process named as serialisation where the objects are passed as value. The remote object is localised by pass by value. It can also pass an object by reference through passing a remote reference to the object along with the URL of the stub class. Pass by reference restricts a stub for the remote object.

CORBA

CORBA stands for Common Object Request Broker Architecture. What is common about CORBA is that it integrates ideas from several of the original proposers. CORBA did not just follow the lead of a single large corporation, and it is very deliberately vendor neutral. The CORBA architecture specifies a software component, a broker, that mediates and directs requests to objects that are distributed across a network (or several networks), which might have been written in a different language from that of the requestor, and which might be (and in fact, usually are) running on a completely different hardware architecture from that of the requestor.

You can begin to get an idea of the tremendous advantages of CORBA from the preceding paragraph. CORBA enables your application to tie together components from various sources. Also, and unlike a typical client/server application, a CORBA application is not inherently synchronous. It is not necessarily typical that a CORBA requestor (a client) invokes a method on a server component and waits for a result. Using asynchronous method invocations, event interfaces and callbacks from server object to the client ORB, you can construct elaborate applications that link together many interacting objects and that access one or many data sources and other resources under transactional control. CORBA enables you to go beyond the bounds of the traditional client/server application in many imaginative ways.

CORBA Features

CORBA achieves its flexibility in several ways:

• It specifies an interface description language (IDL) that allows you to specify the interfaces to objects. IDL object interfaces describe, among other things:
• The data that the object makes public.
• The operations that the object can respond to, including the complete signature of the operation. CORBA operations map to Java methods, and the IDL operation parameter types map to Java datatypes.
• Exceptions that the object can throw. IDL exceptions also map to Java exceptions, and the mapping is very direct.

CORBA provides bindings for many languages, including both non-object languages such as COBOL and C, and object-oriented languages such as Smalltalk and Java.

• All CORBA implementations provide an object request broker (ORB), that handles the routing of object requests in a way that is largely transparent to the application developer. For example, requests (method invocations) on remote objects that appear in the client code look just like local method invocations. The remote call functionality, including marshalling of parameter and return data, is performed for the programmer by the ORB.
• CORBA specifies a network protocol, the Internet Inter-ORB Protocol (IIOP), that provides for transmission of ORB requests and data over a widely-available transport protocol: TCP/IP, the Internet standard.
• A set of fully-specified services eases the burden of application development by making it unnecessary for the developer to constantly reinvent the wheel. Among these services are:
• Naming. One or more services that let you resolve names that are bound to CORBA server objects.
• Transactions. Services that let you manage transaction control of data resources in a flexible and portable way.
• Events.

Reference list

https://www.techopedia.com/definition/7/distributed-computing-system

https://www.techopedia.com/definition/18909/distributed-system

https://www.techwalla.com/articles/advantages-disadvantages-of-standalone-computers

http://www.differencebetween.net/technology/software-technology/difference-between-client-server-application-and-web-application/

https://www.techopedia.com/definition/5411/website
https://www.maxcdn.com/one/visual-glossary/web-application/
https://www.tutorialspoint.com/webservices/what_are_web_services.htm
https://www.slideshare.net/SebaYoussef/rich-internet-applications-8711592?from_action=save
https://www.tutorialspoint.com/Distributed-Systems
https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59
https://zeekat.nl/articles/mvc-for-the-web.html
https://techdifferences.com/difference-between-rpc-and-rmi.html
https://docs.oracle.com/cd/A81042_01/DOC/java.816/a81356/corba.htm