СПОСОБ ПОСТРОЕНИЯ СИСТЕМЫ СООБЩЕНИЙ МНОГОУРОВНЕВОЙ НЕСИММЕТРИЧНОЙ ТРАНСПОРТНОЙ СИСТЕМЫ Российский патент 2013 года по МПК G06F9/04 

Изобретение относится к системам автоматизации, основанным на использовании вычислительных машин.

Современные возможности меняют наши представления об организации рабочего процесса. Персональный компьютер, ставший за последние десятилетия неотъемлемым атрибутом офиса и средством выполнения большинства офисных задач, перестает успевать за растущими потребностями пользователей. Реальным инструментом пользователя оказывается программное обеспечение, которое лишь привязано к ПК, делая его промежуточным звеном корпоративной информационной системы. В результате активное развитие получают облачные вычисления (cloud computing), когда пользователи имеют доступ к собственным данным, но не управляют и не задумываются об инфраструктуре, операционной системе и собственно программном обеспечении, с которым они работают.

Вместе с тем, с ростом масштабов организаций использование в ИТ-инфраструктуре пользовательских ПК вызывает ряд сложностей:

- большие операционные издержки на поддержку компьютерного парка;

- сложность, связанная с управлением настольными ПК;

- обеспечение пользователям безопасного и надежного доступа к ПО и приложениям, необходимым для работы;

- техническое сопровождение пользователей;

- установка и обновление лицензий на ПО и техническое обслуживание;

- резервное копирование и т.д.

Уйти от этих сложностей и сократить издержки, связанные с их решением, возможно благодаря применению технологии виртуализации рабочих мест сотрудников на базе инфраструктуры виртуальных ПК. Такая система позволяет отделить пользовательское ПО от аппаратной части - персонального компьютера и осуществлять доступ к клиентским приложениям через терминальные устройства.

Одним из условий, характеризующих АСУ СП как области применения разрабатываемого изделия, является необходимость взаимодействия с различными системами и подсистемами на всех уровнях иерархии. Причем в ходе применения по назначению в результате реконфигурации системы состав взаимодействующих систем, подсистем и объектов может оперативно изменяться. Следует учесть, что взаимодействующие системы, подсистемы и объекты могут быть построены в различных инструментальных средах на различных программно-аппаратных платформах и функционировать в различных операционных системах.

Проблема объединения комплексов в единое целое или в сеть (например, в глобальную), легко интегрируемую из множества подсетей, может рассматриваться либо как создание всеобъемлющего комплекса, либо как интеграция комплексов на основе объединения «доверенных» узлов без потери управляющего воздействия каждого из участников. Проблема реконфигурации комплекса под состояние среды (решаемые задачи) или в целях функционального восстановления после поражающих воздействий также может рассматриваться как интеграция доверенных узлов без потери управляющего воздействия.

Построение подобных сетей предполагает уже не просто организацию поддержки сетевого транспорта, а решение задачи следующего этапа - слияние программных комплексов или масштабирование - построение нового программного комплекса за счет включения дополнительных компонентов, наделенных определенным функционалом, либо за счет свободно переносимых в программно-аппаратном пространстве, неограниченно расширяемых через повторяющиеся структуры программных комплексов.

Основой для проведения такого процесса является виртуализация программного комплекса. Комплекс, обладающий свойством виртуализации, подобен гармошке: он может быть собран в пределах одной ПЭВМ или растянут на множество машин. В том случае, если каждый узел комплекса сможет воспроизводить по определенному алгоритму из процессов свои крупные функциональные единицы или функциональные блоки (это можно делать и централизованно), решается проблема автоматической конфигурации.

Совокупность функциональных блоков создает более крупную единицу, с одной стороны, обладающую совокупным функционалом и не теряющую главного свойства своих составных частей - виртуализации. Такой крупной единицей может являться, например, функционал автоматизированного рабочего места, функционал группы, комплекса.

Предлагаемая технология развивает компонентную модель программирования и основывается на архитектуре, построенной на независимых программных сущностях - процессах, которые представляют собой эволюционное развитие модулей.

Процессы обладают следующими основными характеристиками:

- независимостью;

- самодостаточностью;

- способностью к сетевому взаимодействию.

1. Независимость процессов. Под этим подразумевается, во-первых, программная независимость, т.е. возможность раздельной компиляции процессов и последующее их динамическое связывание; во-вторых, информационная независимость, т.е. способность процесса скрывать свои внутренние данные и представлять их только через свою интерфейсную часть, и, в-третьих, способность процессов работать автономно (отсутствие сбоев процесса при динамической загрузке или завершении работы других процессов).

2. Принцип самодостаточности определяет функциональную законченность процесса, т.е. его способность выполнять четко определенные и логически взаимосвязанные функции, определенные в рамках одной задачи (подзадачи) информационной системы.

3. Сетевое взаимодействие. Поскольку процессы являются частями большой и распределенной системы, способность процессов взаимодействовать через сеть должна являться одной из их основных характеристик. Посредством ее решается вопрос независимости процессов от их размещения, т.е. их свободная переносимость (виртуализация).

Основные положения построения программного комплекса на основе процессной архитектуры:

1. Программный комплекс представляет собой совокупность взаимодействующих между собой изолированных программ (процессов).

2. На сетевом уровне программы взаимодействуют по протоколу ТСР/IР.

3. Общение между программами организуется посредством команд.

4. Доставка команды осуществляется по адресу, прописанному в адресной части команды.

5. В процессе своего продвижения в команде формируется адрес возврата. Таким образом, получатель команды может формировать ответ отправителю команды.

6. Часть программ (процессов), несущих ответственность за доставку команд, называются диспетчерами. Остальные программы - процессы.

7. Процессы могут быть подключены только к диспетчерам. Диспетчеры подключаются также только к диспетчерам.

8. Среди диспетчеров выделяется Центральный диспетчер. На него замыкаются все диспетчеры системы.

9. Центральные диспетчеры также могут подключаться друг к другу. Таким образом, можно наращивать комплекс бесконечно.

10. Центральный диспетчер, не имеющий подключения к другому Центральному диспетчеру, является вершиной комплекса. Каждый комплекс имеет только одну вершину.

11. Функция диспетчеров - в продвижении команды между собой и, в конце концов, передачи ее процессу.

12. При адресации используются имена диспетчеров и процессов. Каждый процесс и диспетчер имеет собственное имя.

13. Свое имя процесс или диспетчер сообщает при подключении к другому диспетчеру. Этот процесс называется регистрацией.

14. Процесс строится на основе Типового процесса.

15. Типовой процесс осуществляет всю работу по подключению, регистрации, приему и передаче команд к диспетчерам. Открытой у него является интерфейсная часть, позволяющая использовать функции приема/передачи команд.

16. В состав Типового процесса входит буфер команд и командный интерпретатор.

17. Пользовательский процесс расширяет Типовой процесс и пользуется его интерфейсом.

Возрастающие требования вызывают необходимость в процессах, которые должны эксплуатироваться с высшей степенью экономичности, надежности и безопасности. Поэтому известно, уже с момента проектирования необходимо всемерно автоматизировать производственные процессы посредством потока информации с использованием вычислительной машины.

Применяемые для этого системы уже известны из способа построения системы доступа к сетям передачи данных, в частности к IP-сетям, включающего создание системы по сотовому принципу и организацию абонентам базовой станции (соты) беспроводного доступа к сетевым ресурсам через групповой концентратор, при этом данные от группового концентратора передают абонентам через несколько направленных базовых передатчиков, прием сигналов со стороны абонентов ведут абонентскими индивидуальными или микрогрупповыми (кластерными) приемниками, передачу сигналов от абонентов ведут индивидуальными или кластерными абонентскими передатчиками, а прием сигналов от абонентов осуществляют базовыми групповыми приемниками с зонами покрытия, которые определяют исходя из условия нахождения базового группового приемника в зоне прямой видимости соответствующих абонентских передатчиков, и данные от базовых приемников направляют на групповой концентратор, для передачи данных между базовой станцией и абонентами используют электромагнитное излучение оптического диапазона, в качестве базовых передатчиков используют передающие оптические устройства в количестве, соответствующем количеству абонентских приемников, с которыми и устанавливают их оптическое соединение, при этом используют одну и ту же оптическую несущую для передачи данных от всех абонентских передатчиков внутри группы, патент РФ 2196387.

Для осуществления известного способа требуются специальные пути передачи, что значительно сужает функциональные возможности выстраиваемой системы.

Технический результат предлагаемого способа заключается в том, чтобы создать автоматизированную систему с территориально независимыми автоматизированными рабочими местами при неограниченном расширении системы через свои повторяющиеся структуры с построением иерархической транспортной системы.

Этот технический результат достигается тем, что в способе построения системы сообщений многоуровневой несимметричной транспортной системы виртуальным рабочим местам придают возможность динамически конфигурироваться на любом числе узлов локальной сети, объединяющей вычислительные машины комплекса технических средств автоматизированной системы, образуя пространственно независимую информационную решетку, образованную повторяющимися структурами, при этом для обеспечения сетевого взаимодействия программных процессов системы имеются исполняемые модули, образующие транспортную систему в виде информационной решетки, а исполняемые модули располагают в узлах этой решетки, причем звенья решетки создают повторяющиеся структуры, все процессы автономны и разделены на зоны, в каждой из которых все процессы замыкают на процесс-диспетчер, являющийся системным элементом, выполняющим только служебные функции, при этом каждый процесс-диспетчер имеет клиентскую часть для обработки команд, поступивших сверху транспортной системы, и серверную часть для обработки команд, поступивших снизу, обе части диспетчера определяют в адресе получателя его имя для дальнейшей пересылки команды.

Изобретение поясняется чертежами, на которых изображено:

фиг.1, 2 - схема объединения двух транспортных систем (ТС);

фиг.3 - комбинация запуска транспортной системы на промежуточных вариантах количества компьютеров;

фиг.4 - схема подключения процессов к диспетчеру.

фиг.5 - схема адресации процессов в транспортной системе комплекса.

Фиг.6 - схема маршрута от отправителя к получателю.

Осуществление изобретения.

Виртуализация рабочих мест.

Рабочее место - это аппаратно-программный комплекс, решающий задачи одного должностного лица АС.

Независимость рабочих мест от их территориального расположения определяется как свободная миграция программного обеспечения внутри комплекса технических средств АС. При этом возможен вариант, когда все рабочие места собраны в пределах одной рабочей станции (минимальный вариант). Идеальный вариант - одна рабочая станция - один АРМ. В случае избытка технических средств рабочие места могут занимать несколько рабочих станций.

В основе технического решения лежит реализация существенной независимости программных модулей (процессов) и открытости их интерфейсов.

Кроме того, взаимодействие этих модулей (процессов) опирается на специальную платформу исполняемых модулей, образующих транспортную систему. Эти модули могут образовывать произвольные конфигурации, размещаясь на произвольных узлах сети передачи данных.

Изоморфное масштабирование.

Суть построенной на данной технологии АС в создании информационной решетки, в узлах которой располагаются элементы транспортной системы. Несколько звеньев этой решетки создают повторяющие структуры, которые могут быть размножены неопределенное число раз. Т.е. комплекс АС может расширяться (или уменьшаться) за счет дублированных информационных структур.

Дублирование информационных структур может производить сам комплекс, или в качестве таковых могут быть использованы структуры аналогичных комплексов, вступивших во взаимодействие с данным. Под аналогичным комплексом подразумеваем комплекс, собранный по представленной технологии.

В принципе, расширение рассматриваемой АС возможно не только за счет аналогичных информационных структур, главное, чтобы в качестве строительных элементов архитектуры использовались «строительные материалы» данной технологии.

Отсюда вытекает еще одно свойство - взаимодействие АС за счет слияния архитектур, выполненных на данной технологи.

Одно из применений такого рода АС заключается в следующем. Представим существование некой территориальной ограниченной АС с хорошей производительностью (базовой АС) и нескольких мобильных АС с крайне низкими техническими ресурсами. Если все рассматриваемые АС реализованы с применением данной технологии, то эти мобильные АС время от времени могут вступать во взаимодействие с базовой АС и при этом использовать ее потенциал для проведения своих расчетов и корректировки своих заданий, т.е. на какой-то момент всегда существует расширенная АС (базовая + одна или несколько мобильных), которая является целостной и может решать задачи, доступные для такой архитектуры.

Принципы построения автоматизированной системы на основе независимых программных компонентов, реализованных отдельными исполняемыми модулями - процессами.

Идея такой архитектуры заключается в максимальной независимости процессов, то есть в их способности загружаться и функционировать автономно. В таком случае любой компьютер сети может стать средой выполнения процесса, а самому процессу становится безразлично место его физической загрузки.

Каждый процесс обрабатывает поступающую к нему информацию и отдает ее другим процессам. Возникает своего рода конвейер, на котором процессы выполняют свои операции, а на выходе мы получаем уже готовый результат.

Принцип независимости (автономности) процессов позволяет решать вопрос группировки динамически, то есть во время функционирования АС, не прерывая ее работы. Более того, этот же принцип позволяет проводить реконфигурацию всей системы также без ее перезагрузки.

Общее пространство процессов разделяется на отдельные зоны. Эти зоны, так же как и процессы, могут физически располагаться в пределах АС в произвольном порядке, но с условием не пересечения друг другом. Все процессы одной зоны замыкаются на специальный процесс - диспетчер, который выполняет только служебные функции, то есть является системным элементом АС. Процессы и диспетчеры увязываются в единую структуру благодаря типовому процессу. Он определяет основу других процессов и диспетчеров системы, то есть другие процессы и диспетчеры являются наследниками класса «типовой процесс». Задача типового процесса заключается, во-первых, в установке связи с диспетчерами и, во-вторых, в приеме и передаче информационных сообщений. Класс наследника использует уже готовые реализации перечисленных выше свойств типового процесса и предоставляет разработчику вызовы функций этих реализации.

Архитектура иерархической системы сетевого взаимодействия программных компонентов системы.

Для обеспечения сетевого взаимодействия в комплексе задействованы специальные процессы - диспетчеры, совокупность которых образует единую среду функционирования комплекса, в которую погружены остальные процессы. Множество процессов, подключенных к одному диспетчеру, образуют АРМ.

Транспортная система комплекса выполняет две основные задачи:

- обеспечивает сетевое взаимодействие процессов;

- компонует АРМы комплекса.

Транспортная система (ТС) строится иерархически. Каждый клиент имеет над собой только одного диспетчера, который выступает для него в качестве сервера, предоставляющего транспортные услуги. Однако любой диспетчер может выступать в качестве клиента по отношению к вышестоящему диспетчеру, и в этом качестве для вышестоящего он ничем существенным не отличается от рядового прикладного процесса. Поскольку в качестве клиента любой диспетчер может иметь одного и только одного хозяина-сервера, транспортная система является иерархической системой с единственной вершиной. Иначе говоря, в системе всегда существует один и только один диспетчер, не являющийся ничьим клиентом.

Из вышеизложенного следует, что транспортная система в общем случае является многоуровневой и несимметричной, с неограниченным числом уровней. Ближайшие аналоги ТС - файловая система Linux и файловая система логического диска MS Windows. Диспетчер является аналогом каталога (папки) файловой системы, клиент - аналогом файла. Однако есть и одно принципиальное отличие - ТС не имеет фиксированной вершины (аналога корневой папки), поскольку ТС динамически наращиваема как вниз от вершины (подобно файловой), так и вверх. То есть вершина всегда есть и в любой момент единственна, но она, в отличие от корневой папки ("\" в MS Windows или "/" в Linux), в любой момент может уступить свой статус другой (однако внешней по отношению к той ТС, которую вершила теряющая свой статус вершина). Ситуация смены вершины произойдет в случае, когда вершинный (центральный) сервер некоторой автономно работавшей ТС подсоединится к какому-либо из диспетчеров другой ТС. При этом две частные ТС сольются в одну, а центральный диспетчер второй ТС станет общей вершиной объединенной ТС.

Схема объединения двух ТС представлена на фиг.1 и 2.

Проиллюстрированная выше гибкость построения ТС достигается, прежде всего, за счет того, что в ней на любом уровне функционирует единый с точки зрения программного кода модуль диспетчера. По существу здесь исчезают понятия типа «главный диспетчер», «центральный диспетчер». Ранг диспетчера может быть изменен оперативно, посредством либо его собственного подключения к другому серверу, либо при подключении к нему в качестве клиента иного диспетчера.

Для прикладных программистов, разрабатывающих процессы, встраиваемые в систему, диспетчер является отдельным независимым программным модулем, внутренняя начинка которого им недоступна. Способ общения с диспетчером не зависит от среды разработки прикладного процесса, в том числе от операционной системы и от языка программирования, и определяется лишь его интерфейсом.

Транспортная система представляет собой систему исполняемых модулей, загружаемых перед стартом АС. Это достаточно независимое и самодостаточное образование. Для ТС безразлична функциональная реализация АС. Исполняемые модули ТС могут быть загружены как на одном компьютере сети, так и на нескольких, из расчета один диспетчер - один компьютер. Возможна комбинация запуска ТС на промежуточных вариантах количества компьютеров (фиг.3).

Подразумевается, что каждый АРМ разворачивается на отдельном компьютере. Это вполне логично, если учесть, что управляет АРМ оператор, которому затруднительно разделять, например, такое оборудование, как клавиатура с другим таким же пользователем. Однако ряд процессов может выполнять только служебные функции, без какого-либо вмешательства оператора. В таком случае диспетчер и подсоединенные к нему процессы могут мигрировать по компьютерам АС - место их размещения не принципиально. Фактически возможна комбинация, в которой диспетчер и часть подключенных к нему процессов находятся на одном компьютере, а другая часть - на другом (фиг.4). Такой вариант возможен и для процессов в составе АРМ.

На данном рисунке отображена миграция процессов, образующих АРМ_3, в пределах автоматизированной системы, на другие компьютеры, поддерживающие работу АРМ_1 и АРМ_2.

Как уже указывалось выше, компонентами транспортной системы (ТС) являются: диспетчеры, образующие основу информационного взаимодействия системы, и процессы - пользователи системы.

Взаимодействие компонентов в ТС осуществляется посредством команд. Все команды имеют единую внутреннюю структуру, в которой четко выделяются системный (транспортный) и прикладной уровни. В настоящее время структура команды предусматривает шесть полей. Первые два составляют адресную часть: адрес получателя команды, указываемый отправителем, и адрес самого отправителя, который формируется автоматически и должен обеспечить обратное прохождение ответа на команды-запросы, посланные в любую точку ТС. Возможность автоматического формирования обратного адреса обеспечивается путем введения понятия «регистрационного имени», которое по умолчанию совпадает с именем программного модуля, но, при необходимости, может быть изменено, однако только при запуске модуля. Типовой процесс должен закрывать возможность изменения регистрационного имени после присоединения клиента к системе. Третье поле - индекс команды, он используется для тех команд, чей формат требует посылки ответной команды от получателя. Четвертое поле - код транспортной операции. На прикладном слое возможно использование лишь строго фиксированного числа операций ТС, а именно: SAY - отправка сообщения, не требующего ответа, ASK - команда, требующая ответа (запрос), REP - ответная команда на ASK, ERR - ошибка в запросе (пользовательский процесс может посылать сообщение об ошибке лишь в синтаксисе двух ниже описываемых полей, этот код аналогичен возбуждению исключительной ситуации в программном коде и должен сигнализировать разработчику прикладного процесса о недоотлаженности его программного кода, ошибки конечного пользователя доводятся до его рабочего места через посылку обычных сообщений (ответов)). На системном уровне ТС используются также другие команды, недоступные на прикладном уровне (прежде всего REG - команда регистрации процесса у диспетчера, а также BYE - требование сервера к клиенту отсоединиться, KILL - требование сервера к клиенту завершить работу; в дальнейшем возможно появление иных команд). Все эти команды должен обрабатывать типовой процесс. Как уже сказано ранее, на прикладном уровне поле кода транспортной операции должно быть недоступно для заполнения при посылке команды (это достигается предоставлением своего стандартного метода отсылки команды классом типового процесса на каждый тип операции). Однако для получаемых команд обработчику входящих сообщений прикладного уровня код транспортной операции доступен для анализа. Пятое поле - код команды прикладного уровня. Это поле ТС не анализирует, оно отдано на откуп прикладному уровню. Шестое - поле операндов (собственно сообщения). Оно представляет собой строку, содержащую разделенные пробелами ключевые параметры, каждый из которых имеет формат: код операнда, знак равенства (пробелы вокруг знака равенства недопустимы), значение: Операнд1=3начение1 Операнд2=3начение2. Типовой процесс должен предоставлять сервисные функции для обработки строки операндов, но в содержимое их не вмешивается. Специально обрабатывается особый ключевой параметр, имеющий пустой код операнда (т.е. операнд начинается сразу со знака равенства, за которым идет значение). Значением такого операнда является весь «хвост» строки от знака равенства (в таком случае правило о кавычках и пробелах можно не соблюдать).

На фиг.5 приведена схема адресации процессов в транспортной системе комплекса. Имена диспетчеров обозначены как D1, D2. Имена процессов - P1, P2, Р3. Имена центральных диспетчеров - CD1, CD2.

В соответствии с приведенной схемой получаем простую систему адресации, основанную на иерархии имен диспетчеров, что отображается в адресной части команды. Фактически, адрес представляет собой цепочку имен диспетчеров и имя процесса - отправителя команды. На фиг.6 представлены разные варианты адресации команд, зависящих от местоположения получателя команды:

- отправитель и получатель подключены к одному диспетчеру;

- отправитель и получатель подключены к разным диспетчерам одного центрального диспетчера;

- отправитель и получатель подключены к разным диспетчерам разных центральных диспетчеров.

Адрес получателя (АП) задается на прикладном уровне. Обработка его (маршрутизация команды) осуществляется диспетчерами ТС. Алгоритм обработки не зависит от уровня иерархии, на котором работает диспетчер. Формат АП: [[[Дисп1.]Дисп2.]ДиспN.]ПроцессПолучатель. Этот формат похож на формат задания пути в файловых системах, только в качестве разделителя имен диспетчеров (играющих роль папок в ФС) используется символ точки. Перечень имен диспетчеров перед именем процесса-получателя задает путь к этому процессу от точки перегиба на маршруте от отправителя к получателю. В частном случае им может быть и обычный диспетчер для специальных команд, запрашивающих данные, имеющиеся у него.

Так, для посылки сообщения от самого левого на схеме (фиг.6) процесса Р1 к своему соседу процессу Р2 может быть задан как АП в виде Д1.Р2, так и просто в виде Р2.

Алгоритм обработки АП диспетчером таков. Команда может поступить в диспетчер как сверху, так и снизу. Команда, поступившая в диспетчер сверху, анализируется клиентской частью диспетчера. В АП она обязательно должна содержать и его имя. Если это не так - он вернет назад сообщение об ошибке. Если его имя является последним в цепочке имен АП, то это команда непосредственно ему, и он ее интерпретирует сам. Если за его собственным именем есть иное, то это имя он ищет в списке имен зарегистрированных у него клиентов (игнорируя все имена, следующие в цепочке АП за ним). При нахождении клиента с таким именем он пересылает команду ему (т.е. вниз), иначе он должен вернуть отправителю (наверх) сообщение «адресат не найден». Сообщение «адресат не найден» возвращается прикладному процессу-отправителю только при посылке последним команды с кодом транспортной операции ASK.

Команда, поступившая в диспетчер снизу, анализируется серверной частью диспетчера. В АП она не обязательно содержит его имя. Однако, если его имя стоит первым в цепочке имен АП, то на маршруте команды данный диспетчер находится в точке перегиба (либо это команда, адресованная непосредственно ему, но тогда его имя - единственное в АП). Если его имени нет там, то он проверяет первое в цепочке имя на совпадение с именами зарегистрированных у него клиентов. Если совпадение найдено, команда пересылается этому клиенту (вниз, т.е. перегиб: снизу пришло - вниз ушло). Аналогичным образом анализируется и второе имя в цепочке АП в случае, когда первое имя - имя самого диспетчера. Если же цепочка не начинается с имени самого диспетчера, а второе имя не найдено в списке клиентов, то диспетчер предполагает, что команда предназначена для прохождения наверх, и он ищет первое имя в своем списке вышестоящих серверов (если таковой список есть, т.е. если данный диспетчер сам не является вершиной ТС). Если такое имя найдено, команда отправляется первому из вышестоящих серверов, и тот повторит процедуру анализа АП. В противном случае он должен вернуть отправителю (вниз) сообщение «адресат не найден»).

Иначе говоря, при прохождении команды снизу вверх всегда ищется точка перегиба, от которой она меняет направление движения. Именно поэтому АП, заполняемый отправителем, должен содержать адрес «от точки перегиба». Это однозначно гарантирует доставку транспортной системой команды до адресата.

Для гарантирования однозначности адресации в процессе регистрации на сервере проверяется на уникальность регистрационное имя присоединившегося клиента не только в списке его (серверных) клиентов, но и в списке вышестоящих (по отношению к серверу) диспетчеров.

В АП в любом звене цепочки адресов, кроме самого первого, вместо конкретного имени может быть указан специальный символ «*» (звездочка), означающий широковещательное сообщение. Например, единственный символ «*» означает рассылку команды всем процессам, расположенным на том же уровне, что и посылающий (однако оно не пойдет на более низкие уровни, т.е., если процесс Р1 (фиг.6) пошлет такое сообщение, то оно дойдет до процесса Р2, но адрес Д1.Д2, получив такое, своим клиентам переправлять его не будет. АП, указанный в виде Д.*.Р2, доставит команду от процесса Р1 к Д.Д1.Р2 и Д.Д2.Р2. и т.п.

Адрес отправителя, как уже говорилось, проставляется автоматически. Типовой процесс помещает в АО регистрационное имя процесса. Каждый диспетчер при прохождении через него команды наверх добавляет в начало АО свое имя, и так продолжается до точки перегиба.

Изобретение относится к системам автоматизации, основанным на использовании вычислительных машин. Техническим результатом является территориальная независимость АРМ при неограниченном расширении системы через свои повторяющие структуры с построением иерархической транспортной системы за счет свободной миграции программного обеспечения внутри комплекса технических средств АС. Виртуальным рабочим местам придают возможность динамически конфигурироваться на любом числе узлов локальной сети, образуя пространственно независимую информационную решетку, образованную повторяющимися структурами, для обеспечения сетевого взаимодействия программных процессов системы имеются исполняемые модули, образующие транспортную систему в виде информационной решетки, а исполняемые модули располагают в узлах этой решетки, причем звенья решетки создают повторяющиеся структуры, все процессы автономны и разделены на зоны, в каждой из которых все процессы замыкают на процесс-диспетчер, выполняющий только служебные функции, при этом каждый процесс-диспетчер имеет клиентскую часть для обработки команд, поступивших сверху транспортной системы, и серверную часть для обработки команд, поступивших снизу, обе части диспетчера определяют в адресе получателя его имя для дальнейшей пересылки команды. 6 ил.

Способ построения системы сообщений многоуровневой несимметричной транспортной системы, в котором независимость виртуальных рабочих мест от их территориального расположения достигают свободной миграцией программного обеспечения внутри комплекса технических средств автоматизированной системы (АС), для чего виртуальным рабочим местам придают возможность динамически конфигурироваться на любом числе узлов локальной сети, объединяющей вычислительные машины комплекса технических средств автоматизированной системы, образуя пространственно независимую информационную решетку, образованную повторяющимися структурами, при этом для обеспечения сетевого взаимодействия программных процессов системы имеются исполняемые модули, образующие транспортную систему в виде информационной решетки, а исполняемые модули располагают в узлах этой решетки, причем звенья решетки создают повторяющиеся структуры, все процессы автономны и разделены на зоны, в каждой из которых все процессы замыкают на процесс-диспетчер, являющийся системным элементом, выполняющим только служебные функции, при этом каждый процесс-диспетчер имеет клиентскую часть для обработки команд, поступивших сверху транспортной системы, и серверную часть для обработки команд, поступивших снизу, обе части диспетчера определяют в адресе получателя его имя для дальнейшей пересылки команды.