Common Intermediate Language и системное программирование в Microsoft.Net. Макаров А.В - 44 стр.

UptoLike

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