4: Software. Properties of software devices in telecommunications networks

Annotation: This lecture deals with the software of stations operating in a telecommunications network [31]

The main features of this software are inherent in many systems that use software today and are not unique. Just list them in order to understand the problems to be solved.

Software stations operating in a telecommunications network, has the following characteristic properties.

1. "Big software". Its main features:
   • it is created by a large team of specialists (over 100 people);
   • has a large volume (more than 100,000 lines of program text);
   • updated and supplemented throughout the entire "life cycle" of the system.
2. Software system operating in real time.

It means that:

• the task (for example, establishing a connection) must be solved within a certain time (the period of “aging” of the results of the program, sometimes in milliseconds), after which its solution becomes meaningless;
• the solution of the problem takes place in a situation that may change during the time of its solution (release and blocking of paths, failure of resources and erroneous or malicious actions of users).

In addition, such programs are characterized by an industrial approach, the main features of which are:

1. Mass character of the product and its long service life during operation in non-professional (in terms of programming) environment.
2. Alienability and resistance to the future.

   These concepts imply the possibility of installing, adding, correcting and replacing components and software as a whole without involving its creators;
3. Ease of maintenance.

   This task implies the availability of tools to monitor the actions of the software and the environment. It also concerns the creation of a friendly interface.

We repeat that these properties are characteristic not only for telecommunication tasks, but also belong to systems using "industrial software".

Programming systems

The task of this section does not include consideration or even more criticism of various programming systems. As one of the creators of the theoretical approach to programming, E. Dijkstra [25] noted: "The Tower of Babel of Languages ​​grows, and each subsequent one claims to be its crown." The task of this section also does not include the evaluation of various software solutions. Today one thing is clear that "there is no better than the language you know."

The approach proposed in this section was created for the development of domestic program-controlled telecommunications systems. It is displayed in books and many articles (for example, [9, 13, 44, 45]). This approach was developed in the 1970s, and now it can be classified as an object-oriented programming system.

Without claiming to review systems belonging to the object-oriented class, we give the basic definitions of the object-oriented approach. Note that later he will meet more than once in this course, for example, when considering issues of operation and management of communication networks [29, 52].

After reviewing the general issues, we will move on to the domestic method.

Object oriented approach

The basis of this approach is the following concepts.

1. An object that represents the device or information about it to be processed in the program.
2. Attribute. Each object is described by a list of attributes, which, on the one hand, define all the characteristics of the object, on the other - indicate the parameters that can be used by the external environment. The relationship object-attribute is similar to the relation function-parameter in mathematics. This sometimes allows you to write an object as a function.
3. Message (method.) Requests for the operation of an object are called messages or methods. Objects can support more than one method. Methods consist of two parts: the description (signature) and the implementation (implementation). The description consists of the name of the method, the names and types of the parameters (including the return value) and exceptions.
4. The object interface is a part of an object designed to interact with the external environment. A collection of interfaces determines the behavior of an object. The object interface consists of the object name and a set of methods.
5. Often, the concept of a class is associated with the Internet interface. The class has an internal part that defines the structural quality, and an external part that contains the grouping of all objects of the class and the constructor for each class.
6. The object's behavior is a contract, a description of the object's behavior when managing its program, which is offered to the consumer. The contract consists of a description and the necessary preconditions (preconditions), invariants (invariants) and post-conditions (post-conditions). Invariants - preconditions - conditions, the correctness of which must be ensured before calling the method. Postconditions - conditions, the validity of which is checked after calling the method and confirms the correctness of the execution of the contract.

CORBA architecture for distributed computing systems

For building software, its development and operation, many applications use the Common Object Request Broker Architecture (CORBA) - Common Architecture with sending requests to an object through an intermediary. Basic information about this architecture can be found in [18, 29, 52, 68]. Often it is classified as a system for working with distributed computing resources. Its properties largely correspond to the requirements for the development and operation of software stations in telecommunications networks listed at the beginning of this section.

A portion of the CORBA architecture that is required for further consideration is shown in Fig. 4.1.

According to modern classification, this architecture belongs to the client-server architecture class. As can be seen in fig. 4.1, there are two types of network devices:

• clients (in the object-oriented approach, these are objects);
• servers (serving network nodes).

Work is carried out by the server at the request of the client for the service.

The main feature of the CORBA architecture is the availability of the ORB (Object Request Broker) software bus. The ORB is "responsible" for distributing client requests to the appropriate servers, and is also a transport medium for interacting during the execution of a task. The details of this interaction are hidden from the user and exist as part of the implementation of the "software bus".

The following elements of interaction are usually hidden [18].

• The location of the object. The client does not know where the target object is located - in a separate process in another computer on the network or in a different process on the same computer on the network.
• The implementation of the object. The client does not know how the object is implemented, which programming language or scripting language is used to implement it, which operating system or which hardware is working in the object.
• The condition of the object. When sending a request to a target object, the client does not need to know whether the object is activated (that is, if the corresponding process is running) and is ready to accept the request. If necessary, before sending a service request to the object, the ORB component invisibly for the client starts the process on the object.
• The mechanism of communication with the object. The client does not know the mechanism (for example, protocol, shared memory, local method call, etc.).

These ORB features enable application developers to concentrate on applications and not worry about the problems of distributed system programming of the lower level.

This approach simplifies modernization, search for failures and deviations from normal operation and other actions during the operation of the station.

Consider another method that corresponds to the stated properties of the object-oriented approach and distributed programming systems. It was used to create domestic switching systems.

This approach is reflected in many articles and books. For initial study can be recommended [7, 12, 13, 40, 44, 45].

Fig. 4.1. Fragment of CORBA architecture