Лекция 20. Интероперабельность

Важный аспект спецификации интерфейсов — это возможность объединять в единое целое компоненты программной системы, разработанные на разных языках программирования и выполняющиеся в различных средах. Технологии для объединения разнородных модулей программы называют в программной инженерии интероперабельностью или межпроцессным взаимодействием (inter-process communication, IPC).

В крупных программных проектах интероперабельность зачастую необходима:

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

Презентация: Лекция 20.

Демонстрация интероперабельности через CORBA на примере целочисленных последовательностей здесь.

Теоретически, взаимодействие между компонентами можно организовать при помощи встроенных в операционную систему средств. Например, в стандарте IPC POSIX, поддерживаемом, в частности, в Linux, есть много средств взаимодействия программ: семафоры, разделяемая память, сигналы, каналы и так далее. Этот метод обмена данными требует достаточно низкоуровневого программирования, что затрудняет разработку и может привести к плохо обнаруживаемым ошибкам.

Более современный подход к межпроцессному взаимодействию — использование промежуточного ПО (middleware), которое позволяет обращаться с удаленными компонентами приложения так же, как и с локальными. Два основных вида промежуточного ПО различаются тем, что в процессе взаимодействия выходит на первый план: функции, которые преобразовывают данные, или сама передаваемая информация.

Объектно-ориентированные системы задают интерфейсы объектов, которые реализованы удаленными компонентами. Клиент вызывает эти методы так же, как методы обычных объектов. Преобразование вызовов в сообщения, пересылаемые по сети, и обратное преобразование результата — ответственность посредника доступа к объектам (object request broker, ORB). Многие системы (например, CORBA — common object request broker architecture) позволяют свести взаимодействие с ORB к минимуму, автоматически создавая для связи с посредником специальные вспомогательные объекты (stub и skeleton). Для стандартизации типов данных для интерфейса объекта создается универсальное описание, независимое от языка программирования, на котором написана его реализация.

В системах обмена сообщениями (message-oriented middleware) интерфейс задается для самих пересылаемых данных. В отличие от объектно-ориентированных систем, между отправителем сообщений и их получателем не создается канал связи; вместо этого они взаимодействуют через брокер сообщений. Благодаря этому можно отправлять сообщения нескольким адресатам, которые могут не быть активными на момент отправки. В целом, системы обмена сообщениями более гибкие по сравнению с объектно-ориентированными методами межпроцессного взаимодействия; с другой стороны, работоспособность приложения становится зависимой от единственного компонента — брокера сообщений.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *