Формат метаданных. Взаимодействие программных компонентов

Взаимодействие программных компонентов

В настоящее время большой популярностью пользуется компонентный подход к разработке программного обеспечения. Этот подход характеризуется тем, что создаваемый программный продукт состоит из взаимодействующих компонентов. При этом различные компоненты могут независимо разрабатываться разными группами программистов, и при создании каждого компонента может применяться наиболее подходящий язык программирования. В качестве примера можно привести Microsoft Visual Studio .NET и Microsoft Office.

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

Отсутствие удовлетворительной технологии взаимодействия компонентов приводит к следующим негативным явлениям:

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

В компонентной системе можно выделить три вида взаимодействия компонентов:

1. взаимодействие внутри адресного пространства одного процесса;
2. межпроцессное взаимодействие, при котором компоненты работают в разных процессах;
3. взаимодействие в сети, когда компоненты запущены на разных компьютерах.

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

Обзор компонентных технологий

Существует множество способов и технологий организации компонентного программирования. Давайте проведем беглый обзор достижений в этой области.

Библиотеки подпрограмм

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

• Двоичный код библиотеки жестко привязан к аппаратной платформе, так как содержит инструкции конкретного процессора. Это уменьшает переносимость программы, использующей библиотеку.
• Как правило, библиотека рассчитана на использование конкретного компоновщика и может поддерживать ограниченное количество языков программирования, компиляторы которых генерируют объектные файлы в нужном формате и используют нужные соглашения о вызове подпрограмм.
• Библиотеки подпрограмм плохо подходят для объектно-ориентированных языков, так как не содержат никакой информации о типах. Например, если вы разработаете библиотеку классов на C++, вам придется распространять вместе с ней заголовочные файлы, содержащие объявления классов.

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

Открытые исходные тексты

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

• Если компоненты написаны на разных языках, то соединить их вместе не так-то просто. Отсюда проистекает тяга фанатов открытых исходников к превращению своих программ в набор маленьких утилит, написанных на C и соединенных посредством корявых и трудночитаемых скриптов.
• Открытые компоненты почти всегда имеют так называемые "заразные" лицензии (например, GNU Public License - GPL). Такие лицензии требуют, чтобы программы, использующие эти компоненты, сами распространялись в виде открытых исходников. Этот печальный факт существенно ограничивает применимость открытых компонентов.

Технологии COM и CORBA

Особого внимания заслуживают технологии COM (Component Object Model) и CORBA (Common Object Request Broker Architecture). Технология COM, разработанная корпорацией Microsoft, поддерживает все три вида взаимодействия компонентов, а именно: взаимодействие внутри адресного пространства процесса, межпроцессное взаимодействие и взаимодействие по сети. Технология CORBA ориентирована исключительно на взаимодействие компонентов по сети.

Первое, с чем сталкивается программист при использовании COM или CORBA, это необходимость описывать метаданные на языке IDL (Interface Definition Language). В COM и CORBA используются несколько разные варианты языка IDL, но для нас сейчас это несущественно. Подобное неудобство объясняется тем, что эти технологии не подразумевают специальной поддержки в компиляторах языков программирования. Например, мы можем написать COM-объект на языке C++, но ничего не знающий о COM компилятор C++, естественно, не сгенерирует никаких метаданных! Вот поэтому метаданные нужно отдельно описывать на языке IDL.

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

На рис. 2.11 изображена схема взаимодействия двух объектов при использовании технологии COM или CORBA. Объекты Client и Server находятся в разных компонентах, поэтому объект Client не может непосредственно передать сообщение объекту Server. Вместо этого он обращается к специальному объекту-заглушке ClientStub, который осуществляет упаковку сообщения и затем передает его информационной магистрали

Рис. 2.11. Взаимодействия двух объектов через COM или CORBA

(в терминах CORBA информационная магистраль называется ORB - Object Request Broker). Информационная магистраль передает сообщение серверному объекту-заглушке ServerStub, который распаковывает сообщение и вызывает соответствующий метод объекта Server. Результат, возвращаемый методом объекта Server, совершает обратный путь к объекту Client аналогичным образом. Данный пример показывает, что использование технологий COM и CORBA связано с большими трудностями. Ситуация, пожалуй, облегчается лишь тем, что объекты-заглушки могут быть сгенерированы автоматически на основе описания объекта Server на языке IDL (для этого существуют специальные компиляторы).

Хотя технологии COM и CORBA продолжают активно применяться, есть все основания утверждать, что в самом ближайшем будущем они будут вытеснены более эффективными и удобными технологиями (например, .NET).