Distributed System And Its Problems

Published Date: 02 Nov 2017

With the arrival of communication networks and subsequent popularization of information technology, information processing volume increased significantly, which triggered an increase in the development of distributed applications. Various aspects of distributed computing, such as performance, security, and reliability, can easily determine the success or failure of many businesses, cities, or even countries. Computers and networking provide what were thought to be, until recently, unthinkable opportunities, but they also increase our dependency on distributed systems. In order to move the technology further, we might need new ways of thinking about and developing these systems.

Different definitions of distributed system are found in various books and websites. For (Tanenbaum) a distributed system is "A system comprising a set of independent computers seen by users of the system as a single coherent system.", (Coulouris) defines as "A system in which hardware or software components located at networked computers communicate and coordinate their actions by exchanging messages." and (Lamport) defines a distributed system as "A system in which the failure of a computer you did not even know existed, can make our computer unusable."

A distributed system it is then a set of independent processing units which communicate by exchanging and managing synchronization, an application can process in different places on systems with different characteristics, giving the impression to the user that any application is managed by a single system.

DISTRIBUTED SYSTEM AND ITS PROBLEMS

In building distributed systems is given little attention to hostile attacks or ace realities of a world where people make mistakes, there are environmental disturbances, and so on. People who build distributed systems, in large part would work the best of all possible worlds. In the past, my approach would be to build a system of mutually trusting and mutual cooperation of subsystems. Then we encountered some problems with these systems, because today involve too many different cooperating entities for each one to trust all the others. We need architectures that work when there are mutually distrustful components. We need architectures that support cooperation for achieving a common goal but that don’t require subsystems to make strong assumptions about peers. A fundamental problem in distributed systems has been that of reliably distributing information to a collection of processors. This is called the broadcast or the agreement problem. Past work has concerned enforcing strong guarantees (for example, Byzantine Agreement protocols) or enforcing virtually no guarantees (for example, best-effort delivery). Yet, we might be able to implement sufficiently strong guarantees by using gossip or diffusion-protocols that are cheaper than Byzantine Agreement but better behaved than best-effort delivery. We also don’t understand emergent behaviors of networks. We use and study the Internet, but nobody understands how or why the Internet behaves the way it does. So, while we might understand what individual pieces of the Internet do, we have a remarkably poor understanding of what behavior emerges when those pieces are connected, and how we might ensure Internet-wide behavior that will be desirable. So, a revolutionary change is needed. We need to develop qualitatively different approaches.

TECHNOLOGIES

With the evolution of computer networks emerged distributed applications. At the beginning, the processing of applications was done only on the server and the applications were initialized by a client that was connected to it through the network. Later, with the advent of object-oriented programming emerged as a new Middleware CORBA, DCOM components and derivatives of C and Java languages, where the processing has to be distributed among multiple servers (Tanenbaum, 2002).

Today, with the advancement of internet and communication protocols, and new patterns of markup languages like XML, Web services have emerged with the proposal to integrate heterogeneous systems through new technologies. The technology for distributed systems refers to the standardization of elements that are used in programs or applications that make calls remotely activate other applications that reside on other computers and they are in different domains interconnected in a network (Coulouris, 1998). The purpose of distributed systems is to facilitate the achievement of the objectives for a group of users using system resources (hardware and software). Therefore, it is essential that the different types of equipment and systems operating in the environment to communicate in an effective, fast and safe (Coulouris, 1998), (Tanenbaum, 2002).

EXAMPLES OF DISTRIBUTED ARCHITECTURE

An easy example of a distributed architecture for most of the world population, is the internet. The design and construction of mechanisms for Internet communication (Internet protocols) allowed a program running somewhere in the network can send messages to programs elsewhere. It is a set of open services, ie, can be expanded with the addition of new computers and new types of services. On the internet we have a set of independent computers that connect to each other in order to share resources, giving the user the impression that this is all one system.

Internet:

The intranet is also an example of a distributed system. An intranet is composed of several local networks connected by backbones, their size can vary from a single site to multiple sites.

Intranet:

DISTRIBUTED SYSTEMS WITH WEB SERVICES

The Web Service is an emerging technology, about which much has been researched. Researchers define as the way forward in the development of distributed applications, while others have them just an evolution of an old concept. A Web Service is a software application that can be accessed remotely using different XML-based languages. [Pot 2003]

Being modular applications, accessible via a URL, independent of development platforms and enabling interaction between applications without human intervention, Web services present themselves as the solution to the present problems of integration of distributed applications [Lop 2004]. The Web Service is based on the standard rules such as: XML, SOAP, WSDL and UDDI. A web service is similar to the extent that is accessed via a URL. The difference is in the content of what is sent in the request from the client to the server. Web Service clients sends an XML document, formatted in a special way, in accordance with the rules of the SOAP specification. [Cer 2002]

The life cycle of a Web Service includes four distinct states, they are:

Publication – Service registration in the repository of Web Services (UDDI), but is optional.

Find – Research Service in UDDI repository, being optional.

Description – Web service process by which exposes its API.

Invocation – The process by which the client and server interact.

A special feature that draws the most attention from developers is, by virtually any system be able to access Web services from using certain technologies. Web services are platform independent and are found on web servers as components that can be used by other systems, regardless of the programming language. A major motivation for the use of such technology is the Web infrastructure or Distributed Component Architecture. What makes this component of a Web server can be used by multiple clients anywhere on the Internet.

You can deploy Web Services using various architectures. SOAP (Simple Object Access Protocol) is based on a remote invocation of a method and such need to specify the address of the component, the method name and arguments to this method. These data are formatted in XML with certain rules and usually sent over HTTP for this component. Web services based on the REST architecture, based solely on HTTP and message format can be JSON, XML, HTML and others. How is it used only the HTTP only four methods are available: GET, PUT, POST and DELETE. Comparing these two architectures can conclude that REST is lighter because it uses only the HTTP protocol and also some applications may not be able to invoke SOAP. Whenever there is a dependency between invocations it is Stateful Web Services, where the invocations are independent are Stateless Web Services.

DISTRIBUTED TRANSACTIONS AND PROTOCOLS TO COMMIT

The service transaction is provided in client-server models in order to enable data integrity and consistency. The technique of atomic transaction allows the programmer to see your transaction as a sequential program. It is understood then one transaction as a sequence of operations that must be treated as one unit running serially and without interruption, or run concurrently but the same effect as a serial execution. A transaction should normally follow four properties: Atomicity, Consistency, Isolation and Durability. Using transactions in distributed systems will serve to address two problems: Competition (avoid conditions where two or more processes are reading or writing some shared data) and failures (ensure data consistency).

A transaction is said to be distributed when multiple servers are involved in a transaction request by both direct and indirectly via the client server. There are two different ways to build a distributed transaction, the transaction simple and distributed nested transaction. Simple distributed transaction complete each transaction serially before going to the next, while the nested transaction the client requests a transaction to the server which in turn relies on other servers and so on, these can be executed concurrently on different servers and can be confirmed or aborted independently. In distributed transactions is necessary to choose a server transaction coordinator to be the same. Through this coordinating communications are done by the orders and confirmation of a transaction or abortion. The other servers are called participants.

6.1- ATOMIC CONFIRMATION PROTOCOLS

The atomicity of transactions requires that when a distributed transaction ends, either all operations are carried out or all are aborted. A simple way to complete a transaction is atomic so let the coordinator communicates requests for confirmation or abortion for all participants of the transaction. This protocol is called one-phase atomic commit protocol, a protocol is however inefficient because it allows servers abort a transaction, for example in the event of a crash or deadlock.

Already, the protocol of atomic two-phase (two-phase commit protocol) ensures that all participants in the distributed transaction can commit or abort their work, should all participants in the distributed transaction must reach an agreement to confirm the transaction or not. It is the coordinator who informs all participants about the decision and commits or aborts the transaction, the transaction is only committed (committed) if all participants agree and are ready to perform the commit. When a participant is prepared to confirm the transaction, he should lock the relevant data and then confirm or abort the job depending on the response of the coordinator. If the coordinator fall, the data will be blocked until the coordinator is available again. This is the main vulnerability of this protocol. Note that the data remain consistent, but may not be available until the coordinator returns. However if the coordinator fall before a participant is ready, the participant can abort without waiting for his return. This optimization is known as "presumed abort".

CONCLUSION

Distributed systems are increasingly gaining importance in this way, it is necessary to establish a pattern. This article is the result of several research and throughout this article I intend to focus myself on the most important aspects of distributed systems and their implementation. I have met the objectives and have explained in a simple way, which are distributed systems and their problems, illustrated with examples of architecture in the real world, and also the integration of distributed systems with Web Services.