Л.Е. Карпов - Системы программирования (1119429), страница 31
Текст из файла (страница 31)
Массивы отображаются в определения массивов Си++.Операции отображаются в виртуальные методы Си++, имеющие то же имя, что иоперации.Современные версии спецификации CORBA допускают и обратныеотображения: например, в стандарте CORBA 3 прямо предусмотрено проведениеотображения записи интерфейсов на языке Java в записи интерфейсов на IDL. Обратноеотображение позволяет программистам на языке Java создавать объекты, доступные издругих приложений, написанных (возможно) на других языках программирования.Имеются в виду объекты, имеющие объектную ссылку CORBA и доступ кмежброкерному протоколу IIOP (Internet Inter-ORB Protocol). Конечно, такаявозможность подразумевает введение некоторых ограничений на использование языкаJava (в частности, нельзя использовать параметры inout и out, все выходы в IDLприсутствуют в возвращаемом значении).
Обработка программы на языке Javaобратным компилятором позволяет получить эквивалентный интерфейс, написанныйна IDL, имея который, мо жно построить (на языке Java или другом языкепрограммирования) программу клиента CORBA, имеющую доступ к нужному объекту.Чтобы иметь техническую возможность взаимодействовать с некоторымсервером, все, что требуется знать программисту, это IDL-интерфейс этого сервера.Конечно, разработчик должен быть осведомлен о семантике интерфейсов методов идругих ограничениях (например, о специфическом порядке, в котором следуетвызывать методы для достижения той или иной цели). Эти аспекты не формализованы,их предполагается описывать другими средствами, например, в виде комментариев,вставляемых в IDL-спецификации, или в составе сопроводительной документации.Описанный механизм спецификации CORBA, призванный обеспечиватьспособность к взаимодействию, требует, чтобы клиент был статически привязан кинтерфейсу: компилятор IDL статически генерирует переходник, специфический дляконкретного сервисного интерфейса.
Однако модель удаленного обращения к методудопускает динамическое обнаружение новых объектов и построение обращений к нимв процессе работы, даже если для данного клиента не был создан никакой переходник.Эта возможность базируется на двух компонентах: репозитории интерфейсов иинтерфейсе динамического обращения. Репозиторий интерфейсов хранит определениявсех объектов, известных брокеру ORB. Приложения могут использовать репозиторийдля поиска, редактирования или удаления IDL-интерфейсов. Один брокер может иметьнесколько репозиториев, и несколько брокеров могут иметь доступ к одномурепозиторию. Единственное требование, поставленное в спецификации CORBA,заключается в том, что каждый брокер должен иметь хотя бы один репозиторий.111Возможность динамического построения обращений к методам на основединамически обнаруженных интерфейсов решает только часть проблемыдинамического обращения к службе.
Он предполагает, что клиенты ужеидентифицировали нужную им службу. Для того чтобы это стало возможным, вспецификации CORBA ссылки на сервисные объекты выдаются только службойименования и справочной службой. Отношения между этими двумя службаминапоминают отношения между алфавитными и тематическими каталогами илителефонными справочниками. Служба именования позволяет извлекать ссылки наобъекты, отталкиваясь от их имени, а справочная служба дает возможность клиентамискать службы, основываясь на их свойствах. Службы в свою очередь вносят сведенияо своих свойствах в справочник, при этом разные службы имеют разные свойства,описывающие их нефункциональные характеристики.
Используя справочную службу,клиенты могут искать не только объекты, реализующие тот или иной интерфейс, нотакже объекты, свойства которых имеют заданные значения (например, книги по Си).Спецификация CORBA позволяет пользователям систем, построенных на ееоснове, организовывать свои программы в виде служб, предоставляющих услугидругим программам, то есть таким же службам или более традиционно построеннымпрограммам пользователей. Однако обычно (по аналогии с библиотеками стандартныхпрограмм) вместе с базовой системой (самим брокером CORBA) могутраспространяться программы служб, спецификации которых также стандартизованы.Некоторые из этих служб являются обязательными и распространяются всегда, другиеслужбы, несмотря на стандартность интерфейса, имеют более ограниченноеприменение и распространяются по отдельным соглашениям с пользователями.5.4.
Серверы приложений и сетевые службыКак и описанные ранее технологии построения распределенных систем COM иDCOM, стандарт CORBA не ставит целью зафиксировать какое-либо представление отом, какими должны быть системы программирования для распределенных систем.
Вто же время эти стандарты направлены на решение задач, являющихся одновременно изадачами систем программирования – обеспечение поддержки программных продуктовна протяжении их жизненного цикла. Поддержка, которую подобные стандарты исистемы оказывают прикладным программам, очень важна, причем по мере развитияпредставлений о распределенных системах она становится все более необходимой. Ещеболее такая поддержка необходима в тех случаях, когда строящаяся распределеннаясистемапредназначаетсядляинтеграциипрограммныхкомпонентов,взаимодействующих друг с другом посредством глобальных сетей и, прежде всего,глобальных сетей общего доступа, например, посредством сети Интернет.В последнее время системная поддержка распределенных программ,взаимодействующих в Интернете, приняла форму, которая называется серверомприложений, а само взаимодействие в этой сети стало осуществляться посредствомиспользования сетевых служб.
Наиболее широко распространены серверы приложенийJ2EE фирмы Sun Microsystems, .NET фирмы Microsoft, WebSphere компании IBM,WebLogic фир мы BEA Systems, OAS фир мы Oracle Corp oationrи многие другие,функционально близкие друг другу.Все ранее описанные виды системных платформ базируются чаще всего насинхронных методах обращений, когда клиентское приложение обращается к методу,предлагаемому (возможно, динамически определяемым) поставщиком службы. Толькокогда поставщик службы заканчивает выполнение своей работы, он выдает ответ112клиенту. Однако в последнее время все большее распространение приобретаютподходы, поддерживающие более динамичные асинхронные формы взаимодействия, атакже системы распределенного программного обеспечения, взаимодействующие наоснове обмена сообщениями. При асинхронном взаимодействии клиент,запрашивающий услугу у сервера, после выдачи запроса продолжает свою работу в тоймере, в которой это возможно, не тратя время на ожидание результата.
При этом в силеостается использование принципов объектно-ориентированного программирования, накоторых основываются и современные серверы приложений и сетевые службы.Серверы приложений представляют собой крупные библиотеки компонентов,содержащих средства поддержки, как на этапе программирования (проектированияинтерфейсов), так и на этапе выполнения. Сетевые службы используются серверамиприложений в качестве окон во внешний мир, именно через них наиболее удобноосуществлять взаимодействие в глобальной сети.
В то же время сетевые службы самипо себе пригодны для использования и в более локальных системах, с их помощьюмогут даже взаимодействовать отдельные независимые компоненты серверовприложений. Для описания услуг, предоставляемых сетевыми службами, как и в другихраспределенных системах, используется специальный язык описания интерфейсовWSDL (Web Service Definition Language), компилятор с которого включается в составсистемы программирования.WSDL поставщикаслужбыгенератор WSDLкомпилятор WSDL(клиентская сторона)компилятор WSDL(серверная сторона)запрашивающий службупоставщик службыприкладной объект(клиент)прикладной объект(поставщик службы)переходникскелетонпромежуточныйслой, основанныйна асинхронныхвзаимодействияхсообщенияпромежуточныйслой, основанныйна асинхронныхвзаимодействияхСовременные системы программирования для сетевых служб содержатодновременно и специальные средства генерации описания интерфейсов по исходнымтекстам на более традиционных языках программирования, например, по текстам наязыке Java.
В остальном схема формирования сетевой службы напоминает аналогичные113схемы формирования серверной и клиентской частей в системах, основанных намоделях удаленного вызова процедур и удаленного обращения к методам.По-существу, при взаимодействии сетевых служб и происходит обращениеодной службы (выступающей в данном случае в роли клиента) к удаленной процедуре,реализованной внутри другой службы, являющейся в этот момент сервером. Однакосетевые службы выглядят гораздо более симметричными, чем клиенты и серверы вболее традиционных распределенных системах. Одни и те же службы могутпопеременно выступать в обеих ролях – быть и клиентами и серверами. Более того,возможно и такое взаимодействие сетевых служб, когда они одновременно являютсяклиентами одних служб и серверами запросов других служб.Сетевые службы имеют и другое важнейшее отличие от традиционных средстввзаимодействия: для них удалось стандартизовать не только интерфейсы, как дляпроцедур и методов классов, но и протоколы взаимодействия.
В обычных системахпоследовательность вызова процедур или обращений к методам классов формальноникак не регламентирована. Только из неформальных описаний семантики процедур иметодов, а также из примеров, обычно включаемых разработчиками в документацию,при программировании приложений удается добиться правильной последовательностивызовов. Для сетевых служб протоколы их функционирования в информационной сетиописываются на специально для этого разработанном языке описания протоколов.Таких языков в настоящее время существует несколько, наиболее перспективным внастоящее время можно считать язык выполнения бизнес-процессов BPEL.Однако полезность серверов приложений не ограничивается только ихспособностью проводить взаимодействие в глобальной сети посредством хорошостандартизованных сетевых служб.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
