В информатике , передача сообщений является методом для вызова поведения (т.е. запуска программы) на компьютере. Вызывающая программа отправляет сообщение процессу (который может быть субъектом или объектом ) и полагается на этот процесс и его поддерживающую инфраструктуру, чтобы затем выбрать и запустить некоторый соответствующий код. Передача сообщений отличается от обычного программирования, в котором процесс, подпрограмма или функция вызываются напрямую по имени. Передача сообщений является ключом к некоторым моделям параллелизма и объектно-ориентированного программирования .
Передача сообщений повсеместно используется в современном компьютерном программном обеспечении. [ необходима цитата ] Он используется как способ для объектов, составляющих программу, работать друг с другом и как средство взаимодействия объектов и систем, работающих на разных компьютерах (например, в Интернете). Передача сообщений может быть реализована с помощью различных механизмов, включая каналы .
Обзор [ править ]
Передача сообщений - это метод вызова поведения (т. Е. Запуска программы) на компьютере. В отличие от традиционной техники вызова программы по имени, при передаче сообщений используется объектная модель, чтобы отличать общую функцию от конкретных реализаций. Вызывающая программа отправляет сообщение и полагается на объект, чтобы выбрать и выполнить соответствующий код. Обоснование использования промежуточного уровня по существу делится на две категории: инкапсуляция и распространение.
Инкапсуляция - это идея о том, что программные объекты должны иметь возможность вызывать службы для других объектов, не зная и не заботясь о том, как эти службы реализованы. Инкапсуляция может уменьшить объем логики кодирования и сделать системы более удобными в обслуживании. Например, вместо того, чтобы иметь операторы IF-THEN, которые определяют, какую подпрограмму или функцию вызывать, разработчик может просто отправить сообщение объекту, и объект выберет соответствующий код в зависимости от своего типа.
Один из первых примеров того, как это можно использовать, был в области компьютерной графики. Манипулирование графическими объектами связано с различными сложностями. Например, простое использование правильной формулы для вычисления площади замкнутой формы будет зависеть от того, является ли форма треугольником, прямоугольником, эллипсом или кругом. В традиционном компьютерном программировании это привело бы к длинным операторам IF-THEN, которые проверяют, какой объект имеет форма, и вызывают соответствующий код. Объектно-ориентированный способ справиться с этим - определить класс, вызываемый Shapeс подклассами, такими как Rectangleи Ellipse(которые, в свою очередь, имеют подклассы Squareи Circle), а затем просто отправить сообщение любому, кто Shapeпросит вычислить его площадь. КаждыйShapeЗатем объект вызовет метод подкласса с формулой, подходящей для этого типа объекта. [1]
Распределенная передача сообщений предоставляет разработчикам уровень архитектуры, который предоставляет общие службы для создания систем, состоящих из подсистем, которые работают на разных компьютерах в разных местах и в разное время. Когда распределенный объект отправляет сообщение, уровень обмена сообщениями может позаботиться о таких проблемах, как:
- Поиск процесса с использованием разных операционных систем и языков программирования в разных местах происхождения сообщения.
- Сохранение сообщения в очереди, если соответствующий объект для обработки сообщения в данный момент не запущен, а затем вызов сообщения, когда объект доступен. Кроме того, при необходимости, сохранение результата до тех пор, пока отправляющий объект не будет готов его принять.
- Контроль различных транзакционных требований для распределенных транзакций, например, ACID- тестирование данных. [2]
Синхронная и асинхронная передача сообщений [ править ]
 | Этот раздел в значительной степени или полностью основан на одном источнике . ( февраль 2015 г. ) |
Синхронная передача сообщений [ править ]
Синхронная передача сообщений происходит между объектами, которые выполняются одновременно. Он используется в объектно-ориентированных языках программирования, таких как Java и Smalltalk.
Синхронный обмен сообщениями аналогичен синхронному вызову функции; точно так же, как вызывающая функция ожидает завершения функции, отправляющий процесс ожидает завершения процесса получения. Это может сделать синхронную связь невозможной для некоторых приложений. Например, большие распределенные системы могут работать недостаточно хорошо, чтобы их можно было использовать. Таким большим распределенным системам может потребоваться работа, пока некоторые из их подсистем не работают на обслуживание и т.
Представьте себе загруженный бизнес-офис со 100 настольными компьютерами, которые отправляют друг другу электронные письма, используя исключительно синхронную передачу сообщений. Выключение компьютера одним работником может привести к зависанию остальных 99 компьютеров до тех пор, пока работник снова не включит свой компьютер для обработки одного электронного письма.
Асинхронная передача сообщений [ править ]
При асинхронной передаче сообщения принимающий объект может быть отключен или занят, когда запрашивающий объект отправляет сообщение. Продолжая аналогию с вызовом функции, это похоже на вызов функции, который возвращается немедленно, не дожидаясь завершения вызываемой функции. Сообщения отправляются в очередь, где они хранятся до тех пор, пока их не запросит принимающий процесс. Принимающий процесс обрабатывает свои сообщения и отправляет результаты в очередь для получения исходным процессом (или некоторым назначенным следующим процессом). [3]
Асинхронный обмен сообщениями требует дополнительных возможностей для хранения и повторной передачи данных для систем, которые не могут работать одновременно и обычно обрабатываются программным обеспечением промежуточного уровня (часто называемым промежуточным программным обеспечением ); распространенным типом является промежуточное ПО, ориентированное на сообщения (MOM).
Буфер, необходимый для асинхронной связи, может вызвать проблемы, когда он заполнен. Необходимо принять решение, заблокировать ли отправителя или отказаться от будущих сообщений. Заблокированный отправитель может привести к тупиковой ситуации . Если сообщения отброшены, связь перестает быть надежной.
Гибриды [ править ]
Синхронная связь может быть построена поверх асинхронной связи с помощью синхронизатора . Например, α-Synchronizer работает, гарантируя, что отправитель всегда ждет сообщения подтверждения от получателя. Отправитель отправляет следующее сообщение только после получения подтверждения. С другой стороны, асинхронная связь также может быть построена на основе синхронной связи. Например, современные микроядра обычно предоставляют только примитив синхронного обмена сообщениями [ необходима цитата ], а асинхронный обмен сообщениями может быть реализован поверх с помощью вспомогательных потоков .
Распределенные объекты [ править ]
Системы передачи сообщений используют распределенные или локальные объекты. В случае распределенных объектов отправитель и получатель могут находиться на разных компьютерах, работать с разными операционными системами, использовать разные языки программирования и т. Д. В этом случае уровень шины заботится о деталях преобразования данных из одной системы в другую, отправки и получения данных через сеть и т. д. Протокол удаленного вызова процедур (RPC) в Unix был ранним примером этого. Обратите внимание, что для этого типа передачи сообщений не требуется, чтобы отправитель или получатель использовали объектно-ориентированное программирование. Системы процедурного языка можно обернуть и рассматривать как крупнозернистые объекты, способные отправлять и получать сообщения. [4]
Примеры систем, поддерживающих распределенные объекты: Emerald , ONC RPC , CORBA , Java RMI , DCOM , SOAP , .NET Remoting , CTOS , QNX Neutrino RTOS , OpenBinder и D-Bus . Системы с распределенными объектами были названы системами с «ничего не разделяемым», потому что абстракция передачи сообщений скрывает основные изменения состояния, которые могут использоваться при реализации отправки сообщений.
В этом разделе не процитировать любые источники . ( Февраль 2015 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
 | Этот раздел требует внимания специалиста по информатике . Конкретная проблема: Разделы смешивают между локальной и распределенной передачей сообщений, например. чтобы подразумевать, что локальная передача сообщений не может выполняться с передачей по ссылке и должна включать целые объекты, что на самом деле только частично верно для распределенных систем. ( Апрель 2015 г. ) |
Распределенная или асинхронная передача сообщений имеет дополнительные накладные расходы по сравнению с вызовом процедуры. При передаче сообщений аргументы должны быть скопированы в новое сообщение. Некоторые аргументы могут содержать мегабайты данных, все из которых должны быть скопированы и переданы принимающему объекту.
Вызов традиционных процедур отличается от передачи сообщений с точки зрения использования памяти, времени передачи и местоположения. Аргументы передаются приемнику обычно регистрами общего назначения, не требующими дополнительного хранения и времени передачи, или в списке параметров, содержащем адреса аргументов (несколько битов). Передача адресов невозможна для распределенных систем, поскольку системы используют отдельные адресные пространства.
Веб- браузеры и веб-серверы являются примерами процессов, которые обмениваются данными посредством передачи сообщений. URL - адрес является примером ссылки ресурса , не подвергая процесс внутренних органов .
Подпрограммы вызова или метод вызова не будет выхода , пока вызывается вычисление не прекращается. Асинхронная передача сообщений, напротив, может привести к тому, что ответ будет поступать через значительное время после отправки сообщения запроса.
Как правило, обработчик сообщений обрабатывает сообщения от нескольких отправителей. Это означает, что его состояние может измениться по причинам, не связанным с поведением отдельного отправителя или клиентского процесса. Это контрастирует с типичным поведением объекта, для которого вызываются методы: ожидается, что последний будет оставаться в том же состоянии между вызовами методов. Другими словами, обработчик сообщений ведет себя аналогично изменчивому объекту .
Математические модели [ править ]
Известными математическими моделями передачи сообщений являются модель актера и вычисление числа Пи . [5] [6] С математической точки зрения сообщение - это единственное средство передачи управления объекту. Если объект отвечает на сообщение, у него есть метод для этого сообщения.
Алан Кей утверждал, что передача сообщений более важна, чем объекты в ООП, и что сами объекты часто переоцениваются. Модель программирования живых распределенных объектов построена на этом наблюдении; он использует концепцию распределенного потока данных для характеристики поведения сложной распределенной системы в терминах шаблонов сообщений с использованием высокоуровневых спецификаций функционального стиля. [7]
Примеры [ править ]
- Реализация актерской модели
- Аморфные вычисления
- Связь последовательных процессов
- Программирование на основе потоков
- МЫЛО
См. Также [ править ]
- Активное сообщение
- Распределенных вычислений
- Цикл событий
- Шаблон обмена сообщениями
- Передача сообщений в компьютерных кластерах
- Интерфейс передачи сообщений
- Языки программирования, которые включают передачу сообщений как центральную функцию:
- AppleScript
- Erlang
- Эликсир
- HyperCard / LiveCode
- Идти
- Цель-C
- Ржавчина [8]
- Scala
- Болтовня
- Себя
- Параллельный ML
Ссылки [ править ]
- ^ Голдберг, Адель; Дэвид Робсон (1989). Smalltalk-80 Язык . Эддисон Уэсли. С. 5–16. ISBN 0-201-13688-0.
- ^ Орфали, Роберт (1996). Основное руководство по выживанию клиент / сервер . Нью-Йорк: Wiley Computer Publishing. С. 1–22 . ISBN 0-471-15325-7.
- ^ Орфали, Роберт (1996). Основное руководство по выживанию клиент / сервер . Нью-Йорк: Wiley Computer Publishing. С. 95–133 . ISBN 0-471-15325-7.
- ^ Орфали, Роберт (1996). Основное руководство по выживанию клиент / сервер . Нью-Йорк: Wiley Computer Publishing. С. 375–397 . ISBN 0-471-15325-7.
- ↑ Милнер, Робин (январь 1993 г.). «Элементы взаимодействия: лекция о премии Тьюринга» . Коммуникации ACM . 36 (1): 78–89. DOI : 10.1145 / 151233.151240 .
- ^ Карл Хьюитт; Питер Бишоп; Ричард Штайгер (1973). «Универсальный модульный актерский формализм для искусственного интеллекта». IJCAI. Цитировать журнал требует
|journal=( помощь ) - ^ Кей, Алан. «прототипы против классов: Re: Sun's HotSpot» . lists.squeakfoundation.org . Проверено 2 января 2014 года .
- ^ «Использование передачи сообщений для передачи данных между потоками - язык программирования Rust» . doc.rust-lang.org .
Дальнейшее чтение [ править ]
- Ramachandran, U .; М. Соломон; М. Вернон (1987). «Аппаратная поддержка межпроцессного взаимодействия» . Материалы 14-го ежегодного международного симпозиума по компьютерной архитектуре . ACM Press.
- Далли, Уильям. «Желейная машина» . Проверено 7 июня 2013 года .
- McQuillan, John M .; Дэвид К. Уолден (1975). «Некоторые соображения для высокопроизводительной системы межпроцессного взаимодействия на основе сообщений» . Материалы семинара 1975 года ACM SIGCOMM / SIGOPS по межпроцессным коммуникациям . ACM Press.
- Симидзу, Тошиюки; Такеши Хори; Хироаки Исихата (1992). «Поддержка передачи сообщений с малой задержкой для AP1000» . Материалы 19-го ежегодного международного симпозиума по компьютерной архитектуре . ACM Press.
Внешние ссылки [ править ]
- Пакетная история передачи сообщений
