Программное обеспечение промежуточного слоя

Первые реализации RPC были в основном одноплатформенными. Как правило, это были Unix-системы (Sun ONC, Apollo NCS, DCE), ориентированные на язык С и сетевые протоколы TCP/UDP. Первые реализации также были процедурно-ориентированные (не объектно-ориентированные). Последующие этапы развития RPC представляют собой попытки преодолеть указанные недостатки.

Так упоминавшаяся ранее объектно-ориентированная (точнее компонентно-ориентированная) технология СОМ была расширена до DCOM (Distributed COM). DCOM предоставляет возможность коммуникации распределенных компонент через сеть, но ограничивается только Windows-платформами.

Подобное компонентное решение RMI (Remote Method Invocation) и его расширение EJB (Enterprise Java Beans) разработано для платформы Java. Существенное преимущество по сравнению с DCOM (ориентированной только на Windows) заключается в том, что платформа Java может быть развернута поверх большинства современных ОС. Однако взаимодействующие компоненты должны быть реализованы по технологии Java, что является нежелательным ограничением.

Еще одним конкурирующим продуктом является спецификация CORBA (Common Object Request Broker Architecture – общая архитектура объектных запросов), разрабатывавшаяся консорциумом OMG (Object Management Group – рабочая группа по разработке объектно-ориентированных технологий и стандартов – группа представляющая интересы нескольких сотен известных компьютерных фирм). Данная спецификация представляет собой попытку разработать полностью унифицированный компонентно-ориентированный механизм взаимодействия программ в гетерогенной среде. На технологию полагались большие надежды, вкладывались значительные инвестиции, привлекались ведущие специалисты. Однако по ряду причин, в первую очередь организационных [16], CORBA не получила предполагавшегося распространения. Основные претензии предъявляются к ее чрезмерной сложности и не предрасположенности для всемирной сети Интернет (в частности, не обеспечивающей достаточного уровня безопасности).

Рассмотренное программное обеспечение, обеспечивающее взаимодействие программ в гетерогенной среде, располагающееся поверх ОС и под прикладными программами, получило название промежуточного слоя (middleware). Примеры промежуточного слоя (DCOM, RMI, CORBA) имеют много общего не только в постановке задачи, но и в способах ее решения. Эти решения представляют непосредственный интерес в смысле заимствования опыта решения сложных задач.

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

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

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

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

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

В-шестых, взаимодействие с удаленным объектом (компонентом) реализуется с помощью локального посредника (брокера, заместителя, proxy, агента, заглушки). Такое решение соответствует шаблону «Заместитель», хорошо зарекомендовавшему себя в подобных задачах.

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

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

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

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