Лекция №24Интероперабельность
Важный аспект спецификации интерфейсов — это возможность объединять в единое целое компоненты программной системы, разработанные на разных языках программирования и выполняющиеся в различных средах. Технологии для объединения разнородных модулей программы называют в программной инженерии интероперабельностью или межпроцессным взаимодействием (inter-process communication, IPC).
В крупных программных проектах интероперабельность зачастую необходима:
- Различные модули программы могут разрабатываться (или повторно использоваться) в нескольких средах, например, из соображений производительности или стоимости.
- Компоненты программы могут быть разделены в физическом смысле (то есть они располагаются на разных компьютерах). В этом случае использование готовых сетевых протоколов обмена данными позволяет значительно сократить затраты на разработку и интеграцию.
Теоретически, взаимодействие между компонентами можно организовать при помощи встроенных в операционную систему средств. Например, в стандарте IPC POSIX, поддерживаемом, в частности, в Linux, есть много средств взаимодействия программ: семафоры, разделяемая память, сигналы, каналы и так далее. Этот метод обмена данными требует достаточно низкоуровневогопрограммирования, что затрудняет разработку и может привести к плохо обнаруживаемым ошибкам.
Более современный подход к межпроцессному взаимодействию — использование промежуточного ПО (middleware), которое позволяет обращаться с удаленными компонентами приложения так же, как и с локальными. Два основных вида промежуточного ПО различаются тем, что в процессе взаимодействия выходит на первый план: функции, которые преобразовывают данные, или сама передаваемая информация.
Объектно-ориентированные системы задают интерфейсы объектов, которые реализованы удаленными компонентами. Клиент вызывает эти методы так же, как методы обычных объектов. Преобразование вызовов в сообщения, пересылаемые по сети, и обратное преобразование результата — ответственность посредника доступа к объектам (object request broker, ORB). Многие системы (например, CORBA — common object request broker architecture) позволяют свести взаимодействие с ORB к минимуму, автоматически создавая для связи с посредником специальные вспомогательные объекты (stub и skeleton). Для стандартизации типов данных для интерфейса объекта создается универсальное описание, независимое от языка программирования, на котором написана его реализация.
В системах обмена сообщениями (message-oriented middleware) интерфейс задается для самих пересылаемых данных. В отличие от объектно-ориентированных систем, между отправителем сообщений и их получателем не создается канал связи; вместо этого они взаимодействуют через брокер сообщений. Благодаря этому можно отправлять сообщения нескольким адресатам, которые могут не быть активными на момент отправки. В целом, системы обмена сообщениями более гибкие по сравнению с объектно-ориентированными методами межпроцессного взаимодействия; с другой стороны, работоспособность приложения становится зависимой от единственного компонента — брокера сообщений.
Демонстрация интероперабельности через CORBA на примере целочисленных последовательностей здесь.