Составители:
Рубрика:
кие лицензии требуют, чтобы программы, использующие эти
компоненты, сами распространялись в виде открытых исходни-
ков. Этот печальный факт существенно ограничивает примени-
мость открытых компонентов.
2.3.1.3. Технологии 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, который осуществляет упа-
ковку сообщения и затем передает его информационной магистрали
(в терминах CORBA информационная магистраль называется ORB –
Object Request Broker). Информационная магистраль передает сообщение
Структура программных компонентов
75
а затем могут быть использованы другими программистами в других про-
ектах. Исходный код библиотек может быть закрыт, то есть они могут рас-
пространяться в откомпилированном виде, защищая тем самым интересы
разработчиков. Однако организация компонентного программирования
на базе библиотек подпрограмм обладает следующими недостатками:
• Двоичный код библиотеки жестко привязан к аппаратной плат-
форме, так как содержит инструкции конкретного процессора. Это
уменьшает переносимость программы, использующей библиотеку.
• Как правило, библиотека рассчитана на использование кон-
кретного компоновщика и может поддерживать ограниченное
количество языков программирования, компиляторы которых
генерируют объектные файлы в нужном формате и используют
нужные соглашения о вызове подпрограмм.
• Библиотеки подпрограмм плохо подходят для объектно-ориен-
тированных языков, так как не содержат никакой информации
о типах. Например, если вы разработаете библиотеку классов на
C++, вам придется распространять вместе с ней заголовочные
файлы, содержащие объявления классов.
Динамические библиотеки некоторым образом облегчают компо-
нентное программирование. Они поддерживаются операционной систе-
мой, и поэтому разработчики компиляторов вынуждены следовать требо-
ваниям, налагаемым операционной системой. То есть динамические биб-
лиотеки не зависят от причуд компиляторов и компоновщиков и могут ис-
пользоваться для большего диапазона языков программирования. Однако
в остальном они не лучше, чем обычные библиотеки подпрограмм.
2.3.1.2. Открытые исходные тексты
Еще один интересный путь создания компонентных программ приду-
мали в мире открытых исходников, в котором компоненты распространя-
ются в виде исходных текстов. Тем самым вроде бы решается часть проблем.
По крайней мере, можно попытаться переносить эти компоненты с плат-
формы на платформу (перекомпилируя исходники и исправляя возникаю-
щие ошибки). Кроме того, исходные тексты в отличие от двоичных файлов
содержат информацию о типах, что позволяет использовать объектно-ори-
ентированные возможности. Но и здесь нас подстерегают неприятности:
• Если компоненты написаны на разных языках, то соединить их
вместе не так-то просто. Отсюда проистекает тяга фанатов от-
крытых исходников к превращению своих программ в набор ма-
леньких утилит, написанных на C и соединенных посредством
корявых и трудночитаемых скриптов.
• Открытые компоненты почти всегда имеют так называемые «за-
разные» лицензии (например, GNU Public License – GPL). Та-
74
CIL и системное программирование в Microsoft .NET
74 CIL и системное программирование в Microsoft .NET Структура программных компонентов 75
а затем могут быть использованы другими программистами в других про- кие лицензии требуют, чтобы программы, использующие эти
ектах. Исходный код библиотек может быть закрыт, то есть они могут рас- компоненты, сами распространялись в виде открытых исходни-
пространяться в откомпилированном виде, защищая тем самым интересы ков. Этот печальный факт существенно ограничивает примени-
разработчиков. Однако организация компонентного программирования мость открытых компонентов.
на базе библиотек подпрограмм обладает следующими недостатками:
• Двоичный код библиотеки жестко привязан к аппаратной плат- 2.3.1.3. Технологии COM и CORBA
форме, так как содержит инструкции конкретного процессора. Это Особого внимания заслуживают технологии COM (Component Object
уменьшает переносимость программы, использующей библиотеку. Model) и CORBA (Common Object Request Broker Architecture). Технология
• Как правило, библиотека рассчитана на использование кон- COM, разработанная корпорацией Microsoft, поддерживает все три вида
кретного компоновщика и может поддерживать ограниченное взаимодействия компонентов, а именно: взаимодействие внутри адресно-
количество языков программирования, компиляторы которых го пространства процесса, межпроцессное взаимодействие и взаимодейст-
генерируют объектные файлы в нужном формате и используют вие по сети. Технология CORBA ориентирована исключительно на взаи-
нужные соглашения о вызове подпрограмм. модействие компонентов по сети.
• Библиотеки подпрограмм плохо подходят для объектно-ориен- Первое, с чем сталкивается программист при использовании COM или
тированных языков, так как не содержат никакой информации CORBA, это необходимость описывать метаданные на языке IDL (Interface
о типах. Например, если вы разработаете библиотеку классов на Definition Language). В COM и CORBA используются несколько разные ва-
C++, вам придется распространять вместе с ней заголовочные рианты языка IDL, но для нас сейчас это несущественно. Подобное неудоб-
файлы, содержащие объявления классов. ство объясняется тем, что эти технологии не подразумевают специальной
Динамические библиотеки некоторым образом облегчают компо- поддержки в компиляторах языков программирования. Например, мы мо-
нентное программирование. Они поддерживаются операционной систе- жем написать COM-объект на языке C++, но ничего не знающий о COM
мой, и поэтому разработчики компиляторов вынуждены следовать требо- компилятор C++, естественно, не сгенерирует никаких метаданных! Вот
ваниям, налагаемым операционной системой. То есть динамические биб- поэтому метаданные нужно отдельно описывать на языке IDL.
лиотеки не зависят от причуд компиляторов и компоновщиков и могут ис- Технологии COM и CORBA определяют двоичный стандарт для пере-
пользоваться для большего диапазона языков программирования. Однако дачи данных между компонентами. Так как компоненты могут быть напи-
в остальном они не лучше, чем обычные библиотеки подпрограмм. саны на разных языках и, соответственно, внутреннее представление дан-
ных в них может существенно различаться, то компонент, осуществляю-
2.3.1.2. Открытые исходные тексты щий передачу, вынужден выполнять преобразование передаваемых дан-
Еще один интересный путь создания компонентных программ приду- ных в стандартное представление (маршалинг), а компоненту, принимаю-
мали в мире открытых исходников, в котором компоненты распространя- щему данные, приходится выполнять преобразование данных из стан-
ются в виде исходных текстов. Тем самым вроде бы решается часть проблем. дартного представления к своему внутреннему представлению (демарша-
По крайней мере, можно попытаться переносить эти компоненты с плат- линг). При межпроцессном взаимодействии и взаимодействии по сети за-
формы на платформу (перекомпилируя исходники и исправляя возникаю- траты на преобразование данных не играют существенной роли, но при
щие ошибки). Кроме того, исходные тексты в отличие от двоичных файлов взаимодействии внутри адресного пространства одного процесса они мо-
содержат информацию о типах, что позволяет использовать объектно-ори- гут сильно сказаться на производительности программы.
ентированные возможности. Но и здесь нас подстерегают неприятности: На рис. 2.11 изображена схема взаимодействия двух объектов при ис-
• Если компоненты написаны на разных языках, то соединить их пользовании технологии COM или CORBA. Объекты Client и Server нахо-
вместе не так-то просто. Отсюда проистекает тяга фанатов от- дятся в разных компонентах, поэтому объект Client не может непосредст-
крытых исходников к превращению своих программ в набор ма- венно передать сообщение объекту Server. Вместо этого он обращается к
леньких утилит, написанных на C и соединенных посредством специальному объекту-заглушке ClientStub, который осуществляет упа-
корявых и трудночитаемых скриптов. ковку сообщения и затем передает его информационной магистрали
• Открытые компоненты почти всегда имеют так называемые «за- (в терминах CORBA информационная магистраль называется ORB –
разные» лицензии (например, GNU Public License – GPL). Та- Object Request Broker). Информационная магистраль передает сообщение
Страницы
- « первая
- ‹ предыдущая
- …
- 42
- 43
- 44
- 45
- 46
- …
- следующая ›
- последняя »
