Составители:
Рубрика:
кие лицензии требуют, чтобы программы, использующие эти
компоненты, сами распространялись в виде открытых исходни-
ков. Этот печальный факт существенно ограничивает примени-
мость открытых компонентов.
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
- …
- следующая ›
- последняя »