Distributed Systems




Difference between distributed systems and distributed computing

Distributed systems and distributed computing are looks like same. But they slightly different from each other. So let’s talk about them.
In Distributed- computing there are multiple computing units connected to achieve a common task. When considering a single unit, larger computing power enables lot of tasks to be perform. And also searches can be coordinated for efficiency, Successes usually give the finder credit. Distributed computing projects include hunting large prime number, and analysing DNA codes.
A Distributed system includes a collection of autonomous computers, connected through a network and distribution middleware, which enables computers to coordinate their activities and to share the resources of the system, so that users perceive the system as a single, integrated computing facility.
So hope you can now understand the differences.

Standalone system VS Distributed system

Computer based system can be divided into two types according to the distributions of the component. They are,
1.      Standalone systems.
2.      Distributed systems.
So here is the comparison of these two systems.





Standalone system has several advantages and disadvantages.
 
Advantages:
·         Damage controlling
·         More convenient.
·         Doesn’t affect other computer users
Disadvantages:
·         Users are restricted to a single computer.
·         Same software can’t be installed simultaneously.
·         Harder to monitor.

Now let’s move into Distributed system.

 Advantages:
·         Easy to understand redundancy and resiliency.
·         Performances faster than single computer.
·         Easily scalable and parallelism
Disadvantages:
·         Development cost is high.
·         When there is a bug, It’s really challenging to fix it.
·         Increase processing overhead.

Intranet, internet, www, Email, Telecommunication networks, sensor networks are few examples for distributed systems.


Elements of distributed systems


·         Processing components.
·         Data networks for components to communicate.
·         Data source and data
·         The configuration of above elements


Services can be gained from distributed systems
·         Mail services: SMTP, POP3, IMAP
·         File transferring and sharing (FTP)
·         Remote logging (telnet)
·         Games and multimedia: RTP, SIP, H.26x
·         Web (HTTP), through WWW
Browser- based clients and Non browser-based clients
·         If the client component need a browser to communicate, it called browser based client
E.g.: Yahoo mail, Gmail, WebOffice, Google Apps, Microsoft Office Live, WebEx etc.
·         Non-browser based client -the client component don’t need a browser to communicate.
E.g. Facebook, apps, Embelded systems (smart tv)
Types of web- based systems
·         Web applications
§  This is a software program, runs in an internet browser or through a web page.
§  Web application allows for user interaction and can be designed for a variety of uses.
§  Web application must have support for integration with already existing system or external content and services.
§  The development process should be flexible.
§  Must be bug free
·         Rich Internet Applications(RIAs)
§  Faster than web applications.
§  User experience is very high.
§  Can use wider range of controls that allow greater efficiency.
§  Incorporate additional technologies like real-time streaming, high performance, client-side VMs and reduce latency and improve responsiveness.
§  Offline use.
·         Web services and client apps
Different architectures for distributed systems
1.      Client-server (two -tire) architecture

A two-tier architecture is a software architecture in which a presentation layer or interface runs on a client, and a data layer or data structure gets stored on a server. Separating these two components into different locations represents a two-tier architecture, as opposed to a single-tier architecture. Other kinds of multi-tier architectures add additional layers in distributed software design.
Usually (not always) the client sends a request asking the server for some services and the server responds with the resources.
2.      3-tier architecture

A three-tier architecture is a client-server architecture in which the functional process logic, data access, computer data storage and user interface are developed and maintained as independent modules on separate platforms. Three-tier architecture is a software design pattern and a well-established software architecture.
3.      n-tier architecture

N-tier architecture is a client-server architecture concept in software engineering where the presentation, processing and data management functions are both logically and physically separated. These functions are each running on a separate machine or separate clusters so that each is able to provide the services at top capacity since there is no resource sharing. This separation makes managing each separately easier since doing work on one does not affect the others, isolating any problems that might occur.
N-tier architecture is also known as multi-tier architecture.

Micro –  services architecture VS monolithic architecture


First talk about characteristics of micro services.

1) Multiple Components
Software built as microservices can, by definition, be broken down into multiple component services.  Why?  So that each of these services can be deployed, tweaked, and then redeployed independently without compromising the integrity of an application.  As a result, you might only need to change one or more distinct services instead of having to redeploy entire applications.  But this approach does have its downsides, including expensive remote calls (instead of in-process calls), coarser-grained remote APIs, and increased complexity when redistributing responsibilities between components.

2) Built for Business
The microservices style is usually organized around business capabilities and priorities.  Unlike a traditional monolithic development approach—where different teams each have a specific focus on, say, UIs, databases, technology layers, or server-side logic—microservice architecture utilizes cross-functional teams.  The responsibilities of each team are to make specific products based on one or more individual services communicating via message bus.
3) Simple Routing
Microservices act somewhat like the classical UNIX system: they receive requests, process them, and generate a response accordingly.  This is opposite to how many other products such as ESBs (Enterprise Service Buses) work, where high-tech systems for message routing, choreography, and applying business rules are utilized.  You could say that microservices have smart endpoints that process info and apply logic, and dumb pipes through which the info flows.
4) Decentralized
Since microservices involve a variety of technologies and platforms, old-school methods of centralized governance aren’t optimal.  Decentralized governance is favored by the microservices community because its developers strive to produce useful tools that can then be used by others to solve the same problems.  Just like decentralized governance, microservice architecture also favors decentralized data management.  Monolithic systems use a single logical database across different applications.  In a microservice application, each service usually manages its unique database.
5) Failure Resistant
Like a well-rounded child, microservices are designed to cope with failure.  Since several unique and diverse services are communicating together, it’s quite possible that a service could fail, for one reason or another (e.g., when the supplier isn’t available).  In these instances, the client should allow its neighboring services to function while it bows out in as graceful a manner as possible. Monitering microservices can help prevent the risk of a failure. For obvious reasons, this requirement adds more complexity to microservices as compared to monolithic systems architecture.
6) Evolutionary
Microservices architecture is an evolutionary design and, again, is ideal for evolutionary systems where you can’t fully anticipate the types of devices that may one day be accessing your application. Many applications start based on monolithic architecture, but as several unforeseen requirements surfaced, can be slowly revamped to microservices that interact over an older monolithic architecture through APIs 
Now move into monolithic architecture.

·         Composed all in one piece.
·         Designed to self-contained.
·         Typically have better throughput than modular approaches.
·         Modules are relatively independence.
·         Simple to test
·         Simple to deploy

MVC Styles

Mainly there are 3 components in MVC.
1)      Model
It specifies the logical structure of data in a software application and the high-level class associated with it. It is the domain-specific representation of the data which describes the working of an application. When a model changes its state, domain notifies its associated views, so they can refresh.
2)      View
View component is used for all the UI logic of the application and these are the components that display the application’s user interface (UI). It renders the model into a form suitable for interaction. Multiple views can exist for a single model for different purposes.
3)      Controller

Controllers act as an interface between Model and View components. It processes all the business logic and incoming requests, manipulate data using the Model component, and interact with the Views to render the final output. It receives input and initiates a response by making calls on model objects.
  
Now let’s talk about advantages and disadvantages of MVC.

Advantages
1) Faster development process: MVC supports rapid and parallel development. With MVC, one programmer can work on the view while other can work on the controller to create business logic of the web application. The application developed using MVC can be three times faster than application developed using other development patterns.
2) Ability to provide multiple views: In the MVC Model, you can create multiple views for a model. Code duplication is very limited in MVC because it separates data and business logic from the display.
3) Support for asynchronous technique: MVC also supports asynchronous technique, which helps developers to develop an application that loads very fast.
4) Modification does not affect the entire model: Modification does not affect the entire model because model part does not depend on the views part. Therefore, any changes in the Model will not affect the entire architecture.
5) MVC model returns the data without formatting: MVC pattern returns data without applying any formatting so the same components can be used and called for use with any interface.
6) SEO friendly Development platform: Using this platform, it is very easy to develop SEO-friendly URLs to generate more visits from a specific application
Disadvantages

          1) Increased complexity
2) Inefficiency of data access in view
3) Difficulty of using MVC with modern user interface.
4) Need multiple programmers
5) Knowledge on multiple technologies is required.
6) Developer have knowledge of client side code and html code
Communication techniques/ technologies in distributed systems

  • Functional oriented communication(https://techdifferences.com/difference-between-rpc-and-rmi.html)
·         RPC, RMI
                                         Let’s find out what are differences between RPC and RMI


·         COBRA(stsackoverflow)
CORBA uses IDL (Interface Definition Language) to separate interface from implementation. RMI just uses Java interfaces.
Because CORBA is not tied to a particular language, the data types do not always map exactly to the types used by your programming language (e.g. a long in IDL is an int in Java).
RMI programs can download new classes from remote JVMs. CORBA doesn't have this code sharing mechanism.
  •   Message oriented communication
·         SOAP
  •  Resource oriented communication
·         REST

JSON VS XML

First let’s talk about differences between JSON and XML

Here are 2 examples for JASON and XML.



Now let’s talk about similarities among them.
  • Both are simple and open.
  • Both supports Unicode. So internationalization is supported by JSON and XML both.
  • Both represents self-describing data.
  • Both are interoperable or language-independent.


Hope you learnt something from this article..See you in another article..


References



Comments

Popular posts from this blog

How to run multiple Transformations from one Job in Pentaho

Data Analytics