Distributed network architecture. Distributed Systems Overview

Today, almost all large software systems are distributed. A distributed system is a system in which information processing is not concentrated on one computer, but is distributed among several computers. When designing distributed systems, which has much in common with the design of any other software, a number of specific features should still be taken into account. Some of these were already mentioned in the introduction to Chapter 10 when discussing client/server architecture, and they are discussed in more detail here.

Since distributed systems have become widespread these days, software developers must be familiar with their design considerations. Until recently, all large systems were basically centralized, running on one main computer (mainframe) with terminals connected to it. The terminals were practically not involved in information processing - all calculations were performed on the main machine. The developers of such systems did not have to think about the problems of distributed computing.

All modern software systems can be divided into three large classes.

1. Application software systems designed to run on only one personal computer or workstation. These include word processors, spreadsheets, graphics systems, etc.

2. Embedded systems designed to run on a single processor or an integrated group of processors. These include control systems for household devices, various devices, etc.

3. Distributed systems in which software runs on a loosely integrated group of parallel processors connected through a network. These include ATM systems owned by a bank, publishing systems, shared software systems, etc.

Currently, there are clear boundaries between the listed classes of software systems, which will become increasingly blurred in the future. Over time, as high-speed wireless networks become widely available, it will be possible to dynamically integrate devices with embedded software systems, such as electronic organizers with more general systems.

Six main characteristics of distributed systems are identified.

1. Sharing resources. Distributed systems allow the sharing of hardware and software resources, such as hard drives, printers, files, compilers, etc., connected through a network. Obviously, resource sharing is also possible in multi-user systems, but in this case the central computer must be responsible for provisioning and managing resources.

2. Openness. This is an opportunity to expand the system by adding new resources. Distributed systems are open systems to which hardware and software from different manufacturers are connected.

3. Parallelism. In distributed systems, multiple processes can be running simultaneously on different computers on the network. These processes may (but do not have to) interact with each other during their execution.

4. Scalability. In principle, all distributed systems are scalable: in order for the system to meet new requirements, it can be expanded by adding new computing resources. But in practice, expansion may be limited to a network connecting individual computers in the system. If you connect many new machines, the network bandwidth may not be sufficient.

5. Fault tolerance. The presence of multiple computers and the possibility of duplicating information means that distributed systems are resistant to certain hardware and software errors. Most distributed systems can usually maintain at least partial functionality in the event of an error. A complete system failure occurs only in the event of network errors.

6. Transparency. This property means that users are provided with completely transparent access to resources and at the same time information about the distribution of resources in the system is hidden from them. However, in many cases, specific knowledge about the organization of the system helps the user make better use of resources.

Of course, distributed systems have a number of disadvantages.

Complexity. Distributed systems are more complex than centralized ones. It is much more difficult to understand and evaluate the properties of distributed systems in general, and to test these systems. For example, here system performance does not depend on the speed of one processor, but on the network bandwidth and the speed of different processors. By moving resources from one part of the system to another, the performance of the system can be radically affected.

Safety. Typically, a system can be accessed from several different machines, and messages on the network can be viewed or intercepted. Therefore, it is much more difficult to maintain security in a distributed system.

Controllability. The system may consist of different types of computers on which different versions of operating systems may be installed. Errors on one machine can spread to other machines with unpredictable consequences. Therefore, much more effort is required to manage and maintain the system.

Unpredictability. As all Web users know, the response of distributed systems to certain events is unpredictable and depends on the full system load, its organization and network load. Since all of these parameters are subject to constant change, the time it takes to complete a user request may vary significantly at any given time.

When discussing the advantages and disadvantages of distributed systems, a number of critical design issues for such systems are identified (Table 9.1).

Table 9.1. Distributed System Design Issues

Design problem	Description
Resource Identification	Resources in a distributed system are located on different computers, so the resource naming system should be designed so that users can easily open and reference the resources they need. An example is the Uniform Resource Locator (URL) system, which defines the addresses of Web pages. Without an easily understandable and universal identification system, most resources will be inaccessible to users of the system
Communications	The universal functionality of the Internet and the efficient implementation of TCP/IP protocols on the Internet for most distributed systems serve as an example of the most efficient way to organize communication between computers. However, where special requirements are imposed on performance, reliability, etc., alternative methods of system communications can be used
Quality of system service	The quality of service offered by a system reflects its performance, availability and reliability. The quality of service is influenced by a number of factors: distribution of system processes, resource distribution, system and network hardware and system adaptation capabilities
Software architecture	Software architecture describes the distribution of system functions across system components, as well as the distribution of these components across processors. If high quality system service is to be maintained, choosing the right architecture is critical

The task of distributed system designers is to design software or hardware to provide all the necessary characteristics of a distributed system. And this requires knowing the advantages and disadvantages of various distributed system architectures. There are two related types of distributed system architectures.

1. Client/server architecture. In this model, the system can be represented as a set of services provided by servers to clients. In such systems, servers and clients differ significantly from each other.

2. Architecture of distributed objects. In this case, there is no difference between servers and clients and the system can be represented as a set of interacting objects, the location of which does not matter much. There is no difference between the service provider and their users.

In a distributed system, different system components may be implemented in different programming languages ​​and run on different types of processors. Data models, information representation, and communication protocols are not all necessarily the same in a distributed system. Therefore, distributed systems require software that can manage these different types of parts and guarantee interaction and data exchange between them. Middleware belongs precisely to this class of software. It is located, as it were, in the middle between different parts of the distributed components of the system.

Distributed systems are typically developed using an object-oriented approach. These systems are created from loosely integrated parts, each of which can directly interact with both the user and other parts of the system. These parts should react to independent events whenever possible. Software objects built on the basis of such principles are natural components of distributed systems. If you are not yet familiar with the concept of objects.

based on the reconfigurable multi-pipeline computing environment L-Net

One of the current problems in the field of control systems is the development of software for distributed fault-tolerant control systems. The solutions that exist in this area today are proprietary and, as a result, expensive and not always effective.

These solutions do not provide for the efficient use of backup database resources, both technical and software, which negatively affects both the fault tolerance and scalability of such solutions. If the network architecture is violated, there is no possibility of dynamic reconfiguration of both information processing processes and the transmission of data flows (both control and information). The use of specific microcontrollers and the use of DCS/SCADA complicates the development and support of systems and the expansion of their functionality.

Architecture of a distributed control system

The generalized typical architecture of a distributed control system (DCS) includes three hierarchically related levels: operator level, control level and input/output level (see Fig. 1).

The main task of the operator level is to provide a human-machine interface (HMI) to configure and control the functioning of the entire system. The control level is responsible for receiving and processing data from sensors, transmitting data to the operator level and developing control actions on actuators. The input-output level represents sensors and actuators directly connected to the control object.

The task of the software, within the framework of the generalized DCS architecture, is to ensure the functioning of the operator level and its connection with the system control level. Consequently, the fundamental level when designing software and solving issues of its interaction with hardware is the operator level. The software must make the most efficient use of the system's available hardware resources while being as independent as possible from the internal hardware architecture.

Hardware provides computing resources, memory, and communication media between nodes in the system. When designing the general architecture of a system, specific I/O level nodes that will be connected to it in a specific implementation are not considered; therefore, the general architecture considers the operator level and the control level. The hardware must be widespread, meet modern standards, and have all the properties and capabilities necessary to implement the architecture.

Requirements for DCS

The requirements for the DCS relate not only to the system as a whole, but also to its hardware and software components separately, since specific approaches to meeting these requirements for these components may differ fundamentally. The DCS must first and foremost be fault-tolerant. The simplest method of increasing fault tolerance is redundancy (duplication) of functional units or their combination. The second important property is scalability. Scalability is based on the implementation of special algorithms in software and the hardware ability to replace and add new nodes or their components. At the same time, the system must remain simple for its operation, development of new units or modules and modification of its architecture.

Overview of DCS architectures

To conduct a review of DCS architectures, we selected Siemens SIMATIC PCS 7 DCS as one of the most popular on the market and RTS S3 as a DCS implemented on the basis of the QNX RTOS.

Siemens SIMATIC PCS 7

The system architecture has all the properties of a generalized DCS architecture. Operator stations are computers based on x86 processor architecture with Windows OS and the Siemens WinCC package, which provides HMI. There are servers with databases. Operator stations, engineering stations and servers are connected by a local network based on Ethernet. The operator layer is associated with the management layer of a redundant Industrial Ethernet network. At the control level there are programmable logic controllers (PLCs) with the possibility of redundancy due to duplication of functionality. It is possible to connect to external systems and networks and organize remote access to the system.

RTS S3

This architecture similarly consists of levels of a generalized DCS structure. Operator stations are based on the same hardware platform as the SIMATIC DCS, but can be controlled by either Windows or Linux OS. Engineering stations are combined with operator stations. The system provides a unified application development environment. The Ethernet network connects the nodes within the operator layer and the operator layer itself to the control layer using the TCP/IP protocol stack. At the control level there are industrial computers running the QNX OS with their own database and the possibility of redundancy by duplicating the functionality of the node.

Disadvantages of the described systems

In the systems described above, different hardware and software platforms are used for the operator level and the control level. Within the operator level, only one processor architecture can be used, and a special engineering station is required to configure and develop the control level. These DCSs offer, as a way to increase fault tolerance, only hardware redundancy with duplication of the functionality of the redundant node, which is an irrational use of redundant hardware.

Characteristics and functional features of the L-Net system

When developing the L-Net system, the task was to create a control system that would have the following characteristics:

• Dynamic reconfiguration with full restoration of functionality with minimal losses in the event of a host failure or network topology disruption.
• Effective distribution of tasks among available efficient network nodes.
• Duplication of communication channels between nodes with dynamic reconfiguration of data flows.
• Ease of operation and scaling of the system.
• Portability and operability of the system on any hardware platform intended for building control systems and embedded systems.

To build a system with the characteristics described above, you need an operating system designed primarily for creating control systems and embedded systems. An analysis of existing operating systems showed that the most suitable operating system is QNX 6 (Neutrino), which has very effective resource distribution and networking capabilities. Extensive networking capabilities are provided by the Qnet network protocol. It solves the problem of reliability and dynamic load balancing of communication channels, but it does not solve the problem of fault tolerance of the system as a whole. As a result, an innovative control system was developed based on a distributed, reconfigurable, multi-pipeline computing environment. The developed system has a peer-to-peer architecture that includes three logical blocks: an input-output block, a general-purpose switch block and a reconfigurable computing environment (RCE) block (see Fig. 2).

The main advantages of this architecture are:

• Peer type
• Decentralization
• Scalability
• Spatial distribution

Functional features of this architecture:

• Pipeline processing
• Hardware redundancy
• Load distribution
• On-the-fly reconfiguration

At the first level of the architecture there is an input/output (I/O) block, which includes: input/output nodes, an input/output node switch, an input/output interface, sensors and actuators. The block is responsible for the basic mechanisms for generating control actions based on data from local sensors and data received from other levels of the control system. Assigned tasks are distributed among healthy I/O nodes based on their current relative performance or manually by an operator. Sensors and actuators are connected via a bus to all I/O nodes in the block, which allows any node to poll any sensor or act on any actuator. The I/O node switch provides communication between all I/O nodes to exchange data between them and other levels of the system architecture to receive control and information data. With appropriate hardware capabilities, nodes communicate directly with each other and with nodes and switches at other levels of the system, which reduces response time in the network. Direct communication between nodes and a certain workload of nodes in the current mode of operation of the I/O block makes it possible to organize in the block pipeline calculations necessary for the operation of this block without resorting to external computing power of the control system (RCS), which makes it possible to effectively use free resources provided for redundancy nodes of the I/O block at the time of failure.

The block of general purpose switches, located at the second level of the architecture, organizes communication lines between I/O blocks and RCS and external systems. Each switch can interconnect different links and switches in the entire control system. The number of communication lines is determined by the hardware capabilities of the nodes and switches included in the blocks. Since the Qnet network allows dynamic distribution of data transfer flows, scaling of this block is carried out by simply connecting new devices and does not require configuration, and if one of the switches fails, data transfer between nodes will not be interrupted if another switch provides similar communication between the nodes or they directly related. In this case, it is necessary to take care of sufficient network bandwidth necessary to back up a failed switch.

The reconfigurable computer network (RCN) block, located at the third level of the architecture, provides a high-computing power management system for solving complex problems of information processing, decision-making, recognition, etc. The block is responsible for initializing the entire control system: checking the operability of switches and nodes, network integrity, constructing network graphs of the entire system, setting the starting parameters for the operation of I/O blocks. The nodes of this block provide archiving of both their own data and data from I/O blocks. Each node of this block can play the role of an operator’s machine, designed to monitor the operation of the system and make adjustments to the operating programs of both this node and all nodes of the system, performing reconfiguration upon request.

Load distribution

One of the main tasks of the L-Net system is to distribute the computing load on network nodes. The solution to this problem is based on the construction of computational pipelines. To build a computational pipeline, a task graph is first constructed - a scheme for exchanging data flows from source to recipient. Sensors act as a source, and actuators act as a receiver. The computational pipeline itself is a mapping of the task graph (see Fig. 3) onto the computer network graph (see Fig. 4), taking into account the task requirements for the computing resources of the system and its current state.

The solution is to use a service that provides the recipient with comprehensive information about the current hardware, its state and available data sources, working with network and task graphs. As a result, performance increases due to the pipelineization of calculations and the rational use of all computing resources available to the system is organized.

fault tolerance

The main problem with the functioning of such a system is the complete disruption of the computing pipelines if any node of this pipeline fails or if data transfer between them is disrupted. The basic means of the Qnet protocol achieve the restoration of connections between nodes when they are partially disrupted due to the backup lines provided by the architecture. The L-Net system solves the problem of restoring functionality in the event of a complete failure of the host of a computing system by dynamically reconfiguring the computing pipeline, i.e. using working resources to replace a bad block. The system provides three recovery (reconfiguration) scenarios, differing in response time to the fact of failure, recovery time and used hardware resources: upon failure, with passive readiness, with active readiness.

• Reconfiguration upon failure– after detecting a failure, a search is made for available hardware and its inclusion in the task graph.
• Reconfiguration with passive availability– redundant hardware is determined in advance, a process is launched that ensures the implementation of the top of the task graph on the node, connections are established, but the process does not process the data unless the main node fails.
• Reconfiguration with active availability– the vertex of the task graph is implemented on several nodes, which perform data processing in parallel and transmit the result.

As a result, the system is provided with flexible readiness for failures both at the software and hardware levels, the ability to change the configuration of nodes without stopping work and losing performance, while being independent of the implementation of the network, computing pipeline and node.

Conclusion

The developed L-Net system, unlike existing analogues, involves the use of a wide range of hardware characteristics of DCS nodes with their full software compatibility. When nodes operate under the same operating system (QNX Neutrino), it is possible to build them on various processor architectures (x86, ARM, MIPS, etc.) with a variety of sets of interfaces and peripheral devices. The implementation of nodes is possible in the form of desktop, industrial PCs, wearable PCs and single-board computers. All components of the software complex of the developed DCS can be launched on any of its nodes with the QNX OS, while it remains possible to use nodes with another operating system. This approach allows each node to be used to solve problems at both the operator level and the management level. Consequently, there is a flexible system of interaction between peer nodes without a rigid hierarchy of levels inherent in the generalized DCS architecture and systems using this architecture as a base. Peer-to-peer network simplifies the processes of deployment, operation, scaling and debugging of the system.

To realize the computing potential of redundant hardware in the developed system, dynamic configuration and reconfiguration algorithms based on the Qnet network protocol and L-Net network software are proposed. The dynamic configuration algorithm is based on distributing the computing load across all nodes by pipelining and parallelizing tasks and dynamically balancing the load on data transmission channels between nodes. The system reconfiguration algorithm assumes the presence of three scenarios for restoring operability in the event of a failure, depending on the available hardware, priorities and tasks assigned to the system: upon failure, with passive readiness (allocation of resources) and with active readiness (use of resources). Dynamic configuration and reconfiguration algorithms improve performance and reliability by leveraging existing hardware reserves in the system.

An important advantage of the system is the maximum transparency of both hardware and software technologies used in it, which makes it possible to significantly simplify the technical support of the system and the development of new modules for it.

Conclusion

The developed architectural solutions make it possible to improve such indicators of distributed control systems as reliability, performance, cost, scalability and simplicity due to the possibility of using a wide range of hardware, implementing dynamic configuration algorithms and rational use of system resources.

1. http://kazanets.narod.ru/DCSIntro.htm.
2. http://kazanets.narod.ru/PCS7Overview.htm.
3. http://www.rts.ua/rus/news/678/0/409.
4. Zyl S. QNX Momentics: basics of application. – St. Petersburg: BHV-Petersburg, 2005.
5. Krten R. Introduction to QNX Neutrino. A guide to real-time application development. – St. Petersburg: BHV-Petersburg, 2011.

Keywords: distributed control system, information support of control systems, distributed reconfigurable systems.

Architecture of a distributed control system based on reconfigurable multi-pipeline computing environment L-Net

Sergey Yu. Potomskiy, Assistant Professor of National Research University "Higher School of Economics".

Nikita A. Poloyko, Fifth-year student of National Research University "Higher School of Economics". Study assistant. Programmer. Field of training: “Control and informatics in the technical systems.”

Abstract. The article is devoted to a distributed control system based on reconfigurable multi-pipeline computing environment. The architecture of the system is given. Also, the basic characteristics and functional properties of the system are given too. The article presents a rationale for the choice of the operating system. The basic advantages of the system in comparison with existing similar developments are shown in the article.

Keywords: distributed control system, systems software support, distributed reconfigurable.

In contact with

Distributed automated information systems have now become an everyday reality. Numerous corporate automated information systems use distributed databases. Methods for data distribution and distributed data management, architectural approaches that ensure system scalability, implementing the principles of multi-tier client-server architecture, as well as middle-layer architecture, have been developed.

Mobile architectures are beginning to be put into practice. This applies to both database systems and Web applications.

An approach to building distributed systems is being revived, based on a peer-to-peer architecture (Peer-to-Peer), in which, unlike the client-server architecture dominant in distributed systems today, the roles of the interacting parties in the network are not fixed. They are assigned depending on the situation in the network and the load on its nodes.

Due to the intensive development of communication technologies, mobile AIS is actively developing. Hardware and software for their creation have been developed. Thanks to this, mobile database systems began to develop. Many scientific teams conduct research into the specific features of such systems and create various prototypes of them. Java technologies have become an important tool for mobile software development.

A standard for the Wireless Application Protocol (WAP) has been created, which is already supported by some cell phone models. Based on WAP and XML, the W3C consortium developed a markup language for wireless communications, WML (Wireless Markup Language).

In AIS developments, more attention has been paid to metadata. Here steps are being taken in two directions - standardizing the presentation of metadata and ensuring their support in the system.

AIS uses a variety of methods and means of presenting metadata (various types of metadata repositories). The lack of unification in this area significantly complicates the solution of problems of application mobility, reuse and integration of information resources and information technologies, as well as AIS reengineering.

To overcome these difficulties, metadata standards focused on various information technologies are being actively developed. In this area, a number of international, national and industrial standards already exist that define the presentation of metadata and the exchange of metadata in AIS. Some of them have already acquired the status of de facto standards. We will limit ourselves here to mentioning only the most significant of them.

Probably the first de facto standard in this category was the CODASYL data description language for network structure databases. More recent standards include: the SQL query language standard for relational databases, which contains the definition of the so-called information schema - a set of representations of relational database schemas; a component of the ODMG object database standard that describes object schema repository interfaces; international standard IRDS (Information Resource Dictionary Systems), which describes systems for creating and maintaining directories of organizational information resources.

Next, we should mention the CWM (Common Warehouse Metamodel) standard developed by the OMG consortium for representing data warehouse metadata, based on the OIM (Open Information Model) standard previously created for broader purposes by the MDC (Meta Data Coalition) consortium.

The new XML technology platform for the Web also includes standards for representing metadata. Metadata support is one of the most important innovations of the Web, radically changing the technology for managing its information resources. While database technologies initially required support for metadata, the first generation Web did not support metadata.

Web metadata standards are a subset of the XML language used to describe the logical structure of some type of XML document. This description is called DTD (Document Type Definition). In addition, the XML platform includes the XML Schema standard, which offers more advanced capabilities for describing XML documents. The RDF (Resource Definition Framework) standard defines a simple knowledge representation language for describing the content of XML documents. Finally, the developing OWL (Ontology Web Language) standard defines a formal ontology description language intended for the semantic Web.

The UML (Unified Modeling Language) language standard, which provides a metadata representation of CASE tools for visual object analysis and design, was developed by the OMG consortium. This language is supported in many CASE software products. The OMG consortium also created the XMI (XML Metadata Interchange) standard for exchanging metadata between CASE tools using the UML language.

Also worth mentioning here is the Dublin Core (DC) standard - a set of metadata elements for describing the content of documents of various natures. This standard quickly gained popularity and found, in particular, wide application in the Web environment (see Section 3.3).

Work on developing existing and creating new standards for presenting metadata for AIS continues. More detailed information about the standards in question can be found in the encyclopedia.

According to the famous expert in the field of computer science E. Tanenbaum, there is no generally accepted and at the same time strict definition of a distributed system. Some wits argue that distributed is such computing system, in which a malfunction of a computer that users previously didn't even know existed causes all their work to stop. A significant part of distributed computing systems, unfortunately, satisfy this definition, but formally it only applies to systems with a unique point of vulnerability ( single point of failure).

Often, when defining a distributed system, the division of its functions between several computers is of paramount importance. With this approach, any computing system, where data processing is divided between two or more computers. Based on the definition of E. Tanenbaum, a somewhat more narrowly distributed system can be defined as a set of independent computers connected by communication channels, which from the point of view of the user of some software look like a single whole.

This approach to defining a distributed system has its drawbacks. For example, everything used in such a distributed system software could work on one single computer, however, from the point of view of the above definition, such a system will no longer be distributed. Therefore, the concept of a distributed system should probably be based on an analysis of the software that forms such a system.

As a basis for describing the interaction of two entities, we consider the general model of client-server interaction, in which one of the parties (client) initiates data exchange by sending a request to the other party (server). The server processes the request and, if necessary, sends a response to the client (Fig. 1.1).

Rice. 1.1.

Interaction within the client-server model can be either synchronous, when the client waits for the server to complete processing of its request, or asynchronous, in which the client sends a request to the server and continues its execution without waiting for a response from the server. The client and server model can be used as a basis for describing various interactions. For this course, the interaction of the component parts of the software that forms a distributed system is important.

Rice. 1.2.

Let's consider a typical application, which, in accordance with modern concepts, can be divided into the following logical levels (Fig. 1.2): user interface(IP), application logic (AL) and data access (DA), working with a database (DB). The user of the system interacts with it through the user interface, the database stores data describing the application domain, and the application logic level implements all algorithms related to subject area.

Since in practice different users of a system are usually interested in accessing the same data, the simplest way to distribute the functions of such a system across several computers would be to separate the logical levels of the application between one server part of the application, responsible for accessing data, and client parts located on several computers. implementing the user interface. Application logic can be assigned to the server, clients, or divided between them (Figure 1.3).

Rice. 1.3.

The architecture of applications built on this principle is called client-server or two-tier. In practice, such systems are often not classified as distributed, but formally they can be considered the simplest representatives of distributed systems.

A development of the client-server architecture is a three-tier architecture, in which the user interface, application logic and data access are separated into independent components of the system that can run on independent computers (Fig. 1.4).

Rice. 1.4.

The user's request in such systems is sequentially processed by the client part of the system, the application logic server and the database server. However, usually a distributed system is understood as a system with a more complex architecture than a three-tier one.

(Site material http://se.math.spbu.ru)

Introduction.

Today, almost all large software systems are distributed. Distributed system- a system in which information processing is not concentrated on one computer, but is distributed among several computers. When designing distributed systems, which has much in common with software design in general, some specific features should still be taken into account.

There are six main characteristics of distributed systems.

1. Sharing resources. Distributed systems allow the sharing of both hardware (hard drives, printers) and software (files, compilers) resources.
2. Openness.This is the ability to expand the system by adding new resources.
3. Parallelism.In distributed systems, multiple processes can run simultaneously on different computers on the network. These processes can interact while they are running.
4. Scalability . Under scalability the possibility of adding new properties and methods is understood.
5. Fault tolerance. The presence of several computers allows duplication of information and resistance to some hardware and software errors. Distributed systems can support partial functionality in the event of an error. A complete system failure occurs only in the event of network errors.
6. Transparency.Users are given full access to resources in the system, while at the same time information about the distribution of resources throughout the system is hidden from them.

Distributed systems also have a number of disadvantages.

1. Complexity. It is much more difficult to understand and evaluate the properties of distributed systems in general, they are more difficult to design, test and maintain. Also, system performance depends on the speed of the network, not individual processors. Redistributing resources can significantly change the speed of the system.
2. Safety. Typically, a system can be accessed from several different machines, and messages on the network can be viewed and intercepted. Therefore, it is much more difficult to maintain security in a distributed system.
3. Controllability. The system may consist of different types of computers on which different versions of operating systems can be installed. Errors on one machine can spread in unpredictable ways to other machines.
4. Unpredictability . The response of distributed systems to some events is unpredictable and depends on the full system load, its organization and network load. Since these parameters may constantly change, the response time to a request may differ significantly from time to time.

From these shortcomings, it can be seen that when designing distributed systems, a number of problems arise that developers need to take into account.

1. Resource Identification . Resources in distributed systems are located on different computers, so the resource naming system should be designed so that users can easily open and reference the resources they need. An example is the URL (Uniform Resource Locator) system, which defines the names of Web pages.
2. Communication. The universal functionality of the Internet and the efficient implementation of TCP/IP protocols on the Internet for most distributed systems serve as an example of the most efficient way to organize communication between computers. However, in some cases where special performance or reliability is required, specialized tools may be used.
3. Quality of system service . This parameter reflects performance, availability, and reliability. The quality of service is influenced by a number of factors: distribution of processes, resources, hardware and system adaptation capabilities.
4. Software architecture . Software architecture describes the distribution of system functions across system components, as well as the distribution of these components across processors. If high quality system service is to be maintained, choosing the right architecture is critical.

The task of distributed system designers is to design software and hardware to provide all the necessary characteristics of a distributed system. And this requires knowing the advantages and disadvantages of various distributed system architectures. There are three types of distributed system architectures.

1. Client/server architecture . In this model, the system can be represented as a set of services provided by servers to clients. In such systems, servers and clients differ significantly from each other.
2. Three-tier architecture . In this model, the server provides services to clients not directly, but through a business logic server.

The first two models have already been mentioned more than once; let’s take a closer look at the third.

1. Distributed Object Architecture . In this case, there is no difference between servers and clients and the system can be represented as a set of interacting objects, the location of which does not matter much. There is no difference between the service provider and their users.

This architecture is widely used nowadays and is also called web services architectures. A web service is an application accessible via the Internet and providing some services, the form of which does not depend on the provider (since the universal data format is used - XML) and the operating platform. There are currently three different technologies that support the concept of distributed object systems. These are EJB, CORBA and DCOM technologies.

First, a few words about what XML is in general. XML is a universal data format that is used to provide Web services. Web services are based on open standards and protocols: SOAP, UDDI and WSDL.

1. SOAP ( Simple Object Access Protocol), developed by the W3C consortium, defines the format of requests to Web services. Messages between a Web service and its user are packaged in so-called SOAP envelopes (sometimes also called XML envelopes). The message itself can contain either a request to perform some action, or a response - the result of performing this action.
2. WSDL (Web Service Description Language).The Web service interface is described in WSDL documents (and WSDL is a subset of XML). Before deploying a service, the developer writes its description in WSDL, specifies the Web service address, supported protocols, a list of allowed operations, request and response formats.
3. UDDI (Universal Description, Discovery and Integration) - protocol for searching Web services on the Internet ( http://www.uddi.org/). It is a business registry in which Web service providers register services and developers find the necessary services to include in their applications.

From the report it may seem that Web services are the best and no alternative solution, and the only question is the choice of development tools. However, it is not. An alternative to Web services exists; it is the Semantic Web, the need for which was spoken about by WWW creator Tim Berners-Lee five years ago.

If the task of Web services is to facilitate communication between applications, then the semantic Web is designed to solve a much more complex problem - using metadata mechanisms to increase the effectiveness of the value of information that can be found on the Web. This can be done by abandoning the document-oriented approach in favor of an object-oriented one.

Bibliography

1. SommervilleI. Software engineering.
2. Dranica A. Java vs. NET. - "Computerra", #516.
3. Internet resources.