Передача сообщений в компьютерных науках

Введение

Техника запуска программы на компьютере без непосредственного вызова – это концепция в информатике.

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

Обзор

Передача сообщений — это техника вызова поведения (т.е. запуска программы) на компьютере. В отличие от традиционного подхода, при котором программа вызывается по имени, передача сообщений использует объектную модель для отделения общей функции от конкретных реализаций. Вызывающая программа отправляет сообщение и полагается на объект для выбора и выполнения соответствующего кода. Обоснования использования промежуточного слоя по сути сводятся к двум категориям: инкапсуляция и распределённость. Инкапсуляция — это идея о том, что программные объекты должны иметь возможность запрашивать сервисы у других объектов, не зная и не заботясь о том, как эти сервисы реализованы. Инкапсуляция может уменьшить объём логики кодирования и повысить удобство сопровождения систем. Например, вместо использования операторов IF THEN, определяющих, какую подпрограмму или функцию вызывать, разработчик может просто отправить сообщение объекту, который выберет соответствующий код на основе своего типа. Одним из первых примеров использования этого подхода стала область компьютерной графики. Манипулирование графическими объектами сопряжено с различными сложностями. Например, правильная формула для вычисления площади замкнутой фигуры будет зависеть от того, является ли фигура треугольником, прямоугольником, эллипсом или окружностью. В традиционном программировании это привело бы к длинным операторам IF THEN, проверяющим тип фигуры и вызывающим соответствующий код. Объектно-ориентированный подход заключается в определении класса Shape с подклассами, такими как Rectangle и Ellipse (которые, в свою очередь, имеют подклассы Square и Circle), а затем просто в отправке сообщения любому объекту Shape с просьбой вычислить его площадь. Каждый объект Shape затем вызовет метод подкласса с формулой, подходящей для данного типа объекта. Распределённая передача сообщений предоставляет разработчикам слой архитектуры, обеспечивающий общие сервисы для создания систем, состоящих из подсистем, работающих на разнородных компьютерах в разных местах и в разное время. Когда распределённый объект отправляет сообщение, слой передачи сообщений может решать такие задачи, как: Поиск процесса, использующего различные операционные системы и языки программирования, в разных местах, откуда исходит сообщение. Сохранение сообщения в очереди, если соответствующий объект для обработки сообщения в данный момент не работает, и последующий вызов сообщения, когда объект станет доступен. Также, при необходимости, хранение результата до тех пор, пока отправляющий объект не будет готов его получить. Контроль различных транзакционных требований для распределённых транзакций, например, атомарность, согласованность, изолированность, долговечность (ACID) и проверка данных.

Message passing is a technique for invoking behavior (i. e., running a program) on a computer. In contrast to the traditional technique of calling a program by name, message passing uses an object model to distinguish the general function from the specific implementations. The invoking program sends a message and relies on the object to select and execute the appropriate code. The justifications for using an intermediate layer essentially falls into two categories: encapsulation and distribution. Encapsulation is the idea that software objects should be able to invoke services on other objects without knowing or caring about how those services are implemented. Encapsulation can reduce the amount of coding logic and make systems more maintainable. E. g., rather than having IF THEN statements that determine which subroutine or function to call a developer can just send a message to the object and the object will select the appropriate code based on its type. One of the first examples of how this can be used was in the domain of computer graphics. There are various complexities involved in manipulating graphic objects. For example, simply using the right formula to compute the area of an enclosed shape will vary depending on if the shape is a triangle, rectangle, ellipse, or circle. In traditional computer programming this would result in long IF THEN statements testing what sort of object the shape was and calling the appropriate code. The object oriented way to handle this is to define a class called Shape with subclasses such as Rectangle and Ellipse (which in turn have subclasses Square and Circle) and then to simply send a message to any Shape asking it to compute its area. Each Shape object will then invoke the subclass's method with the formula appropriate for that kind of object. Distributed message passing provides developers with a layer of the architecture that provides common services to build systems made up of sub systems that run on disparate computers in different locations and at different times. When a distributed object is sending a message, the messaging layer can take care of issues such as:
Finding the process using different operating systems and programming languages, at different locations from where the message originated. Saving the message on a queue if the appropriate object to handle the message is not currently running and then invoking the message when the object is available. Also, storing the result if needed until the sending object is ready to receive it. Controlling various transactional requirements for distributed transactions, e. g. atomicity, consistency, isolation, durability (ACID) testing the data.

Синхронная передача сообщений

Синхронная передача сообщений происходит между объектами, работающими одновременно. Она используется в объектно-ориентированных языках программирования, таких как Java и Smalltalk. Синхронная передача сообщений аналогична синхронному вызову функции: как вызывающая функция ожидает завершения вызванной функции, так и отправляющий процесс ожидает завершения принимающего процесса. Это может сделать синхронную коммуникацию неприменимой для некоторых приложений. Например, большие распределенные системы могут работать недостаточно эффективно, чтобы быть полезными. Таким образом, таким крупным распределенным системам может потребоваться функционировать, даже когда некоторые из их подсистем находятся на техническом обслуживании и т.д. Представьте себе оживленный офис со 100 настольными компьютерами, которые обмениваются электронными письмами исключительно посредством синхронной передачи сообщений. Выключение компьютера одним сотрудником может привести к зависанию остальных 99 компьютеров до тех пор, пока сотрудник не включит свой компьютер обратно для обработки одного электронного письма.

Асинхронная передача сообщений

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

Гибриды

Синхронная связь может быть построена на основе асинхронной связи с использованием синхронизатора. Например, синхронизатор α работает, обеспечивая ожидание отправителем подтверждения от получателя. Отправитель отправляет следующее сообщение только после получения этого подтверждения. С другой стороны, асинхронная связь также может быть построена на основе синхронной связи. Например, современные микроядра обычно предоставляют только базовый механизм синхронной передачи сообщений, а асинхронная передача сообщений может быть реализована поверх него с помощью вспомогательных потоков.

Распределенные объекты

Системы передачи сообщений используют распределенные или локальные объекты. При использовании распределенных объектов отправитель и получатель могут находиться на разных компьютерах, работать под разными операционными системами, использовать разные языки программирования и т. д. В этом случае шинный уровень обеспечивает преобразование данных из одной системы в другую, отправку и прием данных по сети и т. п. Протокол Remote Procedure Call (RPC) в Unix был одним из первых примеров этого. При таком типе передачи сообщений не требуется, чтобы отправитель или получатель использовали объектно-ориентированное программирование. Системы, основанные на процедурных языках, могут быть инкапсулированы и рассматриваться как объекты с крупной гранулярностью, способные отправлять и принимать сообщения. Примерами систем, поддерживающих распределенные объекты, являются: Emerald, ONC RPC, CORBA, Java RMI, DCOM, SOAP, NET Remoting, CTOS, QNX Neutrino RTOS, OpenBinder и D Bus. Распределенные объектные системы часто называют системами с "отсутствием общих ресурсов", поскольку абстракция передачи сообщений скрывает изменения состояния, которые могут использоваться при реализации отправки сообщений. Распределенная или асинхронная передача сообщений имеет дополнительные накладные расходы по сравнению с вызовом процедуры. При передаче сообщений аргументы должны быть скопированы в новое сообщение. Некоторые аргументы могут содержать мегабайты данных, все из которых необходимо скопировать и передать принимающему объекту. Традиционные вызовы процедур отличаются от передачи сообщений с точки зрения использования памяти, времени передачи и локальности. Аргументы обычно передаются получателю через регистры общего назначения, не требуя дополнительного хранения или времени передачи, либо в списке параметров, содержащем адреса аргументов (несколько бит). Передача адресов невозможна для распределенных систем, поскольку они используют отдельные адресные пространства. Веб-браузеры и веб-серверы являются примерами процессов, взаимодействующих посредством передачи сообщений. URL — это пример ссылки на ресурс без раскрытия внутренней структуры процесса. Вызов подпрограммы или метод не завершится, пока вызванное вычисление не будет завершено. Асинхронная передача сообщений, напротив, может привести к тому, что ответ будет получен значительно позже, чем было отправлено сообщение запроса. Обработчик сообщений, как правило, обрабатывает сообщения от нескольких отправителей. Это означает, что его состояние может изменяться по причинам, не связанным с поведением конкретного отправителя или клиентского процесса. Это отличается от типичного поведения объекта, методы которого вызываются: последний, как ожидается, сохранит свое состояние между вызовами методов. Иными словами, обработчик сообщений ведет себя аналогично нестабильному (volatile) объекту.

Message passing systems use either distributed or local objects. With distributed objects the sender and receiver may be on different computers, running different operating systems, using different programming languages, etc. In this case the bus layer takes care of details about converting data from one system to another, sending and receiving data across the network, etc. The Remote Procedure Call (RPC) protocol in Unix was an early example of this. With this type of message passing it is not a requirement that sender nor receiver use object oriented programming. Procedural language systems can be wrapped and treated as large grained objects capable of sending and receiving messages. Examples of systems that support distributed objects are: Emerald, ONC RPC, CORBA, Java RMI, DCOM, SOAP, NET Remoting, CTOS, QNX Neutrino RTOS, OpenBinder and D Bus. Distributed object systems have been called "shared nothing" systems because the message passing abstraction hides underlying state changes that may be used in the implementation of sending messages. Distributed, or asynchronous, message passing has additional overhead compared to calling a procedure. In message passing, arguments must be copied to the new message. Some arguments can contain megabytes of data, all of which must be copied and transmitted to the receiving object. Traditional procedure calls differ from message passing in terms of memory usage, transfer time and locality. Arguments are passed to the receiver typically by general purpose registers requiring no additional storage nor transfer time, or in a parameter list containing the arguments' addresses (a few bits). Address passing is not possible for distributed systems since the systems use separate address spaces. Web browsers and web servers are examples of processes that communicate by message passing. A URL is an example of referencing a resource without exposing process internals. A subroutine call or method invocation will not exit until the invoked computation has terminated. Asynchronous message passing, by contrast, can result in a response arriving a significant time after the request message was sent. A message handler will, in general, process messages from more than one sender. This means its state can change for reasons unrelated to the behavior of a single sender or client process. This is in contrast to the typical behavior of an object upon which methods are being invoked: the latter is expected to remain in the same state between method invocations. In other words, the message handler behaves analogously to a volatile object.

Математические модели

Известными математическими моделями передачи сообщений являются модель акторов и π-исчисление. В математических терминах, сообщение – это единственный способ передачи управления объекту. Если объект реагирует на сообщение, у него есть метод для обработки этого сообщения. Алан Кей утверждал, что передача сообщений важнее, чем объекты в объектно-ориентированном программировании, и что сами объекты часто бывают переоценены. Модель программирования живых распределенных объектов опирается на это наблюдение; она использует концепцию распределенного потока данных для описания поведения сложной распределенной системы в терминах паттернов обмена сообщениями, используя спецификации функционального стиля высокого уровня.