Распределенные приложения и многоуровневая архитектура

Распределенные приложения и
многоуровневая архитектура
Электронная коммерция и электронный
бизнес
Все возрастающая конкуренция и новые возможности, предоставляемые сервисами e-commerce
(электронная коммерция) и e-business (электронный бизнес), заставляют компании, работающие по
традиционным технологиям переходить на использование названных бизнес-технологий.
Электронная коммерция
Термин electronic commerce или e-commerce (электронная коммерция) используется для обозначения
систем купли-продажи товаров и услуг с помощью Интернет, в частности World Wide Web
(всемирной Web-сети).
Для обозначения торговли "напрямую" через сеть Интернет употребляется также термин e-tailing
(электронная розничная торговля).
Системы e-commerce решают следующие основные задачи:


Web-представительство в Интернет различных товаров и услуг;
электронный обмен данными (Electronic Data Interchange), т. е. поддержка стандартов
безбумажных информационных технологий;
 обеспечение связи с заказчиками: системы типа "бизнес — потребитель" (business-tocustomer, B2C);
 обмен данными для поддержания деловых контактов с партнерами: системы типа "бизнесбизнес" (business-to-business, B2B);
 поддержка эффективного менеджмента: системы типа "бизнес-администрация” (business-toadministration, B2A);
 обеспечение связи заказчиков с администрацией предприятия: системы типа
«потребитель — администрация» (customer-to-administration, C2A),
 поддержка электронной почты, факс-модемной связи и других медиа-средств для
обеспечения заказчиков информацией в удобной форме;
 осуществление прямых покупок и продаж через Интернет;
 обеспечение защиты информации.
E-commerce является одной из ключевых технологий нового тысячелетия, позволяющей
менеджерам, не выходя из своего офиса, развивать производство, продвигать свою продукцию на
рынке и взаимодействовать с заказчиками.
Существуют две основные модели e-commerce: линейная и нелинейная.
Линейная модель поддерживает доступ конечного пользователя к информационным ресурсам
производителя или поставщика, реализуя отношение 1:1 ("один-к-одному").
Нелинейная модель, получившая название c-commerce — collaborative commerce (совместная
коммерция) отражает взаимодействие предприятия с партнерами по бизнесу, включает
многочисленные связи с поставщиками, подрядчиками и субподрядчиками. Предприятия,
связанные комплексом связей, получили название "коллаборативных сообществ". Нелинейная
модель c-commerce поддерживает взаимоотношения m:n ("многие-ко-многим").
Электронный бизнес
На основе Интернет-технологий e-business (электронный бизнес) осуществляет преобразование
традиционных форм ведения бизнеса в более эффективные формы.
Electronic business или e-business (электронный бизнес) — термин, появившийся несколько позже и
часто используемый как синоним e-commerce, все же обозначает более широкое понятие любого рода
бизнеса в Интернет. Это могут быть не только операции купли-продажи. E-business включает также
сервисное обслуживание заказчиков (e-service), взаимодействие с деловыми партнерами,
предоставление специальной информации, различные инвестиционные и банковские услуги, системы
бронирования билетов и т. д.
E-business является следующей ступенью структурного развития Интернет-ориентированных
приложений после e-commerce.
E-business — это комплексная интеграция бизнес-процессов, корпоративных приложений и
организационных структур, необходимых для создания высокодоходной и эффективной модели
бизнеса.
Переход от традиционных форм ведения бизнеса к системам
e-business
Большое число современных изданий посвящено исследованию возможности систем электронной
коммерции и электронного бизнеса для управления предприятием. Специалистами рассматриваются
возможные способы перехода от традиционных схем управления предприятием к менеджменту,
широко использующему интеграцию с архитектурой e-commerce и e-business.
Электронный бизнес полностью изменил формы конкурентной борьбы, существенно повысил
скорость реакции на те или иные события и изменил саму природу конкуренции на рынке
товаров и услуг. Теперь уже конкуренция связана не так с конкуренцией капиталов, как с
конкуренцией товарных знаков, т. е., фактически, информационных технологий.
Можно так образно описать сложившуюся ситуацию: "Повсеместно менеджеры ощущают: их
компании стоят на перепутье e-commerce дорог, и этих дорог очень много. Но какая из них ведет к
успеху? К каким направлениям им стоит прикладывать усилия? Какие бизнес-модели, стратегии
менеджмента или тактика сделают их бизнес успешным? Каковы характеристики следующего
поколения бизнес-приложений? Какие провайдеры будут лидировать в предоставлении этих услуг и к
кому обращаться за помощью?"
Современный бизнес невозможен без знания основ электронного бизнеса. Компании, отставшие в
этом направлении, очень дорого расплачиваются за свою нерасторопность.
На рис. 1 представлена общая структура организации традиционного предприятия.
Рис. 1. Организация традиционного бизнеса
Для перехода от такой классической организации деятельности предприятия к структуре,
ориентированной на применение Интернет-технологий, необходимо реализовать следующие
целенаправленные действия:



произвести полный анализ текущего состояния предприятия, организации
производственного
процесса,
инфраструктуры,
информационного
пространства
предприятия, эффективности бизнеса;
пересмотреть подход к бизнесу. Перейти от проблемы эффективной реализации готовых
товаров и услуг к инверсной задаче определения товаров или услуг, максимально
удовлетворяющих потребности потенциальных заказчиков;
определить ключевое направление производства, с тем чтобы найти свое место на рынке
товаров и услуг. Целью производства должны быть высококачественные товары,
удовлетворяющие требованиям заказчика и с приемлемой ценой.
Рис. 2. Организация электронного бизнеса
Из схемы на рис. 2 видно, что наиболее важной частью является организация информационного
обеспечения и непосредственной связи с заказчиками. Для принятия правильного и
своевременного решения менеджеру необходимо иметь точную и актуальную информацию.
При организации деятельности предприятия в соответствии с идеями электронной коммерции и
электронного бизнеса преследуются три основные цели, обеспечивающие путь к успеху:


улучшение обслуживания клиентов;

возможность модернизации продукции.
совершенствование организационных мероприятий для снижения себестоимости
продукции (в скобках отметим, что эта продукция должна быть качественной и
иметь разумную цену);
Коротко поясним, что под этим подразумевается в системах электронного бизнеса.
Улучшение обслуживания клиентов
По сравнению с прошлым, современный бизнес в большей степени ориентирован на
повышение качества продукции и имеет целью более качественное обслуживание клиентов. В
будущем же предполагается переход на полное самообслуживание, совершенствование
маркетинга и расширение взаимосвязей, поддерживаемых электронными средствами.
Открытость
Кроме того, имеется тенденция к большей открытости фирм и корпораций. Производителю
становится выгодным не скрывать свои планы от партнеров и заказчиков, а, наоборот, все больше
посвящать их в тенденции развития предприятия. Близкое знакомство с заказчиками и тесные
контакты с партнерами дают неоспоримые преимущества предприятию.
Готовность к изменениям
Предприятие должно быть готово к возможным изменениям рынка, например, быстро
реагировать на изменения цен на аналогичные товары у конкурентов. Оперативно адаптироваться
к любым изменениям и даже предвидеть эти изменения можно, только имея хорошую
информационную поддержку.
Информационная поддержка
Для любой фирмы жизненно важно организовать получение актуальной информации
необходимого типа вовремя и в нужном месте. Вид информации и формы ее обработки и
хранения могут варьироваться в зависимости от специфики и профиля предприятия.
Использование контактов с пользователем
Для лучшего понимания нужд заказчика целесообразно отслеживать, анализировать и сохранять
сведения о том, когда произошел контакт с заказчика с Вашей компанией, какими средствами
клиент при этом воспользовался , что было предметом данного взаимодействия и каков его
результат. Подобный анализ полезен для определения возможностей предприятия по
улучшению обслуживания заказчиков.
Выработка перспективной корпоративной концепции
обслуживания заказчиков
Корпоративная концепция преследует самую главную цель: как, опираясь на системы
электронного бизнеса, наиболее полно удовлетворить потребности клиентов, сделать их
обслуживание технологичным, комфортным и удобным, как для предприятия, так и для заказчиков.
При этом, данная программа должна по возможности учитывать как краткосрочную, так и
отдаленную перспективу и тенденции рынка.
Совершенствование организационных мероприятий
Основная цель организационных мероприятий — снижение себестоимости продукции и
принятие решений, направленных на получение наиболее эффективного результата при общей
ориентации на удовлетворение потребностей заказчика.
Электронный бизнес предоставляет возможность сделать контакты с поставщиками более
надежными и эффективными. Отношения партнерства устанавливаются гораздо легче, если
поставщикам открывается доступ к информации о необходимых для бизнеса товарах, материалах,
услугах, планах выпуска продукции или продаж, процессе проектирования и реализации.
Партнеры, таким образом, могут оперативно реагировать на ваши запросы и в более короткие
сроки осуществлять необходимые поставки.
Перечислим основные моменты, определяющие эффективность организационных мероприятий.
Эффективное управление активами
Задачей менеджмента является обеспечение приобретения необходимых ресурсов по минимальной
цене, их доставки в необходимые сроки и с минимальными затратами, поддержка эффективного
способа хранения, перемещения и распределения.
Эффективное взаимодействие с поставщиками
Управление, организацией взаимодействий предприятия с поставщиками нацелено на интеграцию
предприятия с поставщиками на основе единого информационного пространства. Это позволяет
существенно ускорить все процессы, протекающие между предприятием и поставщиками.
Управление информацией о продажах
Для эффективной реализации продукции требуется детальная информация о рынке сбыта
аналогичной продукции: что именно, где и по какой цене продается. Эти сведения помогают
определить разумную цену на продукцию предприятия и регионы, предпочтительные для ее
сбыта.
Вычислительные методы и системы
Электронный бизнес должен опираться на отработанные вычислительные методики,
позволяющие численно оценивать все производственные и коммерческие процессы. Эти модули
предназначены для непрерывного поиска уменьшения затрат и повышения качества продукции и
обслуживания.
Исследование спроса на продукцию
Один из принципов менеджмента — "Разнообразие убивает эффективность". Важным моментом
является определение наиболее перспективных видов продукции, с тем чтобы предприятие могло
сфокусировать усилия на самых перспективных направлениях. Зато уж те товары или услуги,
которые выбраны как предмет деятельности фирмы, должны наиболее полно удовлетворять
потребительскому, спросу и требованиям каждого конкретного заказчика.
Возможность модернизации продукции
Непрерывное усовершенствование продукции необходимо как для повышения ее качества, так и
для того, чтобы превзойти конкурентов и завоевать признание на рынке. Рынок не статичен, он
динамично развивается, поэтому постоянная модернизация продукции призвана обеспечить
лидерство предприятия в избранной области.
Рассмотрим основные принципы, на которых основывается менеджмент предприятий, нацеленных
на постоянную модернизацию продукции.
Ориентация на риски
Руководство предприятия, стремящегося захватить и удержать лидерство на рынке с помощью
усовершенствования своей продукции, должно анализировать и четко представлять риски,
связанные с модернизаций. Любое новшество предполагает риск, поэтому должен применяться
особый стиль менеджмента, опирающийся на исследование рисков и путей их преодоления.
Расширение
Ориентация предприятия на постоянную модернизацию продукции требует приобретения новых
материалов и комплектующих. Кроме того, требуется расширение предприятия, связанное с
необходимостью в персонале, способном разрабатывать новые материалы и образцы, вести
исследовательскую работу, развивать и усовершенствовать корпоративное программное
обеспечение. Возможно также слияние с другими компаниями-партнерами с целью образования
более мощной структуры.
Обучение заказчиков
Для того чтобы эффективно продавать постоянно модернизируемую продукцию и не упустить
первенства, следует лидировать и в сфере обучения заказчиков, преодолевая естественный
консерватизм. В простой и удобной форме заказчику надо показать преимущества
модернизированной продук ЦИИ И НАУЧИТЬ пользоваться ею. В этом плане незаменимыми
оказываются всевозможные демонстрационные и обучающие системы.
Поощрение модернизации
Менеджеры, проводящие последовательную модернизацию продукции, должны использовать
гибкую систему премирования успехов, полученных в этом направлении.
Основные отличия между традиционным и электронным бизнесом
Подытоживая все вышесказанное, отметим основные отличия между традиционным бизнесом и ebusiness (таблица 1):
Таблица 1. Сравнение традиционного и электронного бизнеса
Признак
Традиционный бизнес
Электронный бизнес
Основная направленность
Ориентация на продукцию
Ориентация на заказчика
Поддерживающие системы
Жесткие функциональноориентированные системы
Гибкие интегрированные
сервисные системы
Концепция успеха на рынке
Уменьшение стоимости продукции
Связи с заказчиками
Принцип деятельности
Проблемно-ориентированная на
конечный результат
Ориентированная на решение
Обзор основных направлений архитектуры
программных систем
Мы рассмотрели практические задачи, которые необходимо реализовать при переходе от
традиционного менеджмента к менеджменту Интернет-ориентированному.
После моделирования программной системы, а зачастую и параллельно с моделированием,
начинается этап разработки ее архитектуры.
В настоящее время существует множество вариантов архитектуры программных приложений.
Тем не менее, можно выделить ключевые направления и главные идеи, на основе которых
строится все многообразие архитектурных решений.
Рассмотрим основные направления архитектуры программных систем в хронологической
последовательности.
Автономные приложения
Однопользовательское приложение устанавливается и эксплуатируется на одном компьютере.
Автономные приложения (Stand-alone application) не потеряли значения и в наши дни. Если для
решения задачи достаточно ресурсов одного персонального компьютера и в процессе работы не
требуется взаимодействие с другими пользователями, вполне естественно реализовать
приложение как однопользовательское.
Однопользовательские системы имеют одноуровневую архитектуру. Приложение и данные
полностью размещаются на одном компьютере. Задачи, связанные с поддержанием
эффективного функционирования предприятия, требуют предоставления одновременного доступа
многим пользователям к актуальной информации, быстрой обработки и пересылки данных.
Развитием и некоторым усовершенствованием однопользовательских систем являются рабочие
станции, схематично представленные на рис. 3. В данном варианте компьютеры связаны друг с
другом в кольцо.
Рис. 3. Рабочие станции
Приложения, установленные на каждой рабочей станции, тем не менее, являются
однопользовательскими, т. е. они устанавливаются отдельно на каждом рабочем месте и
вызываются автономно каждым пользователем такой кольцевой сети. Преимуществом данного
варианта является только возможность взаимодействия и обмена данными между рабочими
местами. Однако все программное обеспечение и используемые данные дублируются. Любые
изменения в используемых программных продуктах, например их модернизация, требуют
соответствующих изменений на каждом рабочем месте. Вариант, представленный на рис. 8.3,
называют кольцевой сетью. Таким образом, использование рабочих станций, функционирующих
в кольцевой сети, хоть и является шагом вперед по сравнению с автономной работой за
персональным компьютером, не позволяет решить задачи уровня предприятия.
Перечислим недостатки рассмотренной архитектуры:
- работа таких программных комплексов подвержена частым сбоям;
- обмен информацией происходит медленно, удаленный доступ затруднен;
- возможны потери важной информации;
- затруднена организация удаленного доступа;
- модернизация системы очень трудоемка;
- защита информации от несанкционированного доступа организована слабо;
- администрирование кольцевой сети трудоемко и неэффективно.
Многопользовательские системы. Архитектура
Host/Terminal
Необходимость организации совместного доступа к программному обеспечению и совместного
использования информации привела к созданию более сложных систем, к которым
одновременно может обращаться произвольное число пользователей.
Многопользовательское приложение (Multi-user application) — это приложение,
предназначенное для коллективного использования.
Существуют различные варианты реализации такого рода программных систем.
Одним из базовых вариантов является архитектура Host/Terminal (Хост/Терминал).
Архитектура Host/Terminal представляет собой полностью централизованную систему, в которой
все ресурсы и вычисления сосредоточены на центральном компьютере, клиенты же имеют доступ к
ним только через терминалы, не выполняющие никакой обработки, а выступающие лишь в роли
Устройств связи с центральным компьютером.
Архитектура Host/Terminal реализуется несбалансированной сетью, так как используется один
мощный компьютер (сервер) и "облегченные" рабочие места, минимальные аппаратные средства
которых позволяют только получать и отправлять информацию по сети.
Приложение и данные полностью размещаются на сервере, а доступ к ним Многочисленных
пользователей осуществляется с помощью удаленных терминалов. Такая архитектура, которую
также называют радиальной сетью, представлена на рис. 4.
Сервер понимается в данном случае только как более мощное аппаратное средство, на котором
сосредоточено программное обеспечение и которое управляет функционированием более слабых
аппаратных средств (удаленных терминалов). На сервере сосредоточены системы,
поддерживающие работу пользователей в многопользовательском режиме
Рис. 4. Архитектура Host/Terminal
Терминалы представляют собой устройства для ввода и вывода символьной информации.
Пользователь практически взаимодействует непосредственно с приложением и базой данных, имея
в своем распоряжении монитор и удаленную клавиатуру.
Специфика архитектуры Host/Terminal заключается в том, что вся бизнес-логика и все вычисления
выполняются на сервере и там же располагаются базы данных. Такой централизованный подход
облегчает администрирование, повышает сохранность данных, но одновременно и увеличивает
цену возможного сбоя или ошибки.
Кроме того, вариант Host/Terminal экономически целесообразен только в случае, когда в
качестве рабочих мест используются дешевые и простые терминалы. Если вместо
терминалов применяются современные персональные компьютеры, работающие в режиме
эмуляции терминала, их мощности используются не полностью.
Минусом является также необходимость использования высокоскоростных каналов связи.
Система очень критична к числу пользователей, одновременно обращающихся к
приложению: чем их больше, тем больше загруженность канала связи.
Свойства самого приложения должны также тщательно проверяться, особенно в
отношении его влияния на сетевой трафик.
Таким образом, основными преимуществами архитектуры Host/Terminal являются:
 экономическая целесообразность системы при условии использования
простейших терминалов;
 высокая степень защиты информации;
 простота управления данными;
 простота администрирования и обслуживания системы.
Основными недостатками архитектуры Host/Terminal являются:
 высокие требования, предъявляемые к производительности сервера и
быстродействию каналов связи;
 сложность и многообразие программного обеспечения, устанавливаемого на
сервере;
 экономическая нецелесообразность использования в качестве терминалов более
сложных вычислительных средств.
Рассматриваемая модель никоим образом не определяет, какая именно сторона инициирует
соединение в сети: это может быть как сервер (Host), так и терминал. Таким образом, возможны
ситуации, когда сервер (Host) фактически является клиентом, а терминал выступает в роли
сервера, и наоборот, когда клиентом является терминал, а сервером — центральный компьютер.
В связи с совершенствованием персональных компьютеров возникла идея их использования в
качестве терминалов таким образом, чтобы с их помощью не только отправлять запросы и
получать данные, но также максимально использовать дополнительные вычислительные
ресурсы.
Архитектура Клиент/Сервер
Приложение, которое размещается и выполняется на нескольких компьютерах, в тоже время,
сохраняя свою целостность, называется распределенным. В основе архитектуры Клиент/Сервер
лежит распределенная обработка данных.
Приложение состоит из двух частей, одна из которых располагается и выполняется на стороне
клиента, а другая — на стороне сервера, как это показано на рис. 5. Хранение и обработка
данных, как правило, осуществляется на стороне сервера, а часть приложения, реализующая
интерфейс пользователя, формирование запросов и обработку результатов запросов, — на
стороне клиента.
Обе части приложения взаимодействуют друг с другом при помощи удаленного доступа
(канала связи).
Рис. 5. Отношение Клиент/Сервер
Отношение Клиент/Сервер (Client/Server) — это отношение между двумя программами (или частями
программы), при котором одна из них посылает запрос другой, выполняющей необходимые действия
для ответа на поступивший запрос.
Отношение Клиент/Сервер может реализовываться как на автономном компьютере, так и на двух
расположенных удаленно компьютерах.
При работе в сети под отношением клиент—сервер подразумевается модель взаимодействия между
программами, расположенными в различных местах. Это, пожалуй, наиболее общее понятие в
области сетевых решений.
Клиент запрашивает некоторый сервис, а сервер этот сервис предоставляет.
Клиент
Клиент (Client) — это пользователь, программа или часть программы, посылающие запрос. Клиент
всегда является инициатором связи с серверной частью.
Под клиентом понимают также рабочее место (компьютер), с которого пользователь системы
(менеджер, поставщик, покупатель и т. д.) инициирует работу приложения и с которого может
совершать запросы к системе и получать необходимую информацию.
На компьютере пользователя, возможно, размещается часть самого приложения (клиентская
часть). Допускается также полное или частичное размещение бизнес-логики на клиентской
стороне, хотя разработчики прибегают к этому редко.
Интерфейс пользователя (User interface) — это часть программной системы, которая
устанавливается на персональные компьютеры пользователей и поддерживает взаимодействие с
приложением каждого отдельного пользователя. Например, Web-браузер является клиентом по
отношению к сайтам, которые он просматривает.
Сервер
Сервер (Server) — это программа или часть программы, локализованная на том же или другом
компьютере, ожидающая прихода запроса от клиента и осуществляющая его последующую
обработку.
Сервер — это, в общем случае, удаленный компьютер, на котором располагается приложение, и
доступ к которому осуществляется по каналам связи Интернет.
Обычно на сервере хранятся данные и выполняется (или частично выполняется) бизнес-логика
системы.
Общее представление об архитектуре Клиент/Сервер
На рис. 6 в самом общем виде представлена архитектура Клиент/Сервер (Client / Server).
Рис. 6. Архитектура Клиент/Сервер
Как и архитектура Host/Terminal, представленная на рис. 4, архитектура Клиент/Сервер
предполагает радиальную сетевую структуру, однако имеет следующие основные отличия:

функции клиента и сервера четко распределены: клиентская часть находится на
машине-клиенте серверная - на машине-сервере;
 модель Клиент/Сервер представляет собой более сбалансированную аппаратную
систему: в качестве клиентов используются более мощные, чем в модели
Host/Terminal, компьютеры, которые могут брать на себя часть функциональности и
успешно бороться с сетевым трафиком;
 надежность и быстродействие сервера возрастают в связи с передачей клиентской
стороне функций, поддерживающих работу пользователя (пользовательского
интерфейса, организации запросов, получения ответов на запросы, хранения
промежуточных результатов и т. д.);
 освободившись от части функциональности, сервер может поддерживать большее
количество клиентов.
Несмотря на явные преимущества клиент-серверной архитектуры, у этой модели есть и некоторые
недостатки:
- работа клиентской части приложения может замедлять функционирование системы в целом
из-за недостаточной мощности компьютера клиента;
- усложняются администрирование и сервисное обслуживание клиентов;
- возможно возникновение проблем при параллельной работе многих клиентов с одной и той же
базой данных;
- защита информации может стать менее надежной.
Основной проблемой практической реализации архитектуры Клиент/Сервер является
распределение приложения между клиентом и сервером.
Где реализовать бизнес-логику?
При практической реализации клиент-серверной архитектуры интерфейс пользователя реализуется
на стороне клиента, базы данных — на стороне сервера. Остается вопрос, на какой стороне
выполнять бизнес-логику системы.
Можно практически все функции возложить на сервер, облегчив клиентскую часть. Однако в этом
случае теряются все преимущества распределенного подхода, мы практически возвращаемся к
архитектуре Host/Terminal, a мощности клиентского компьютера остаются недостаточно
использованными.
При модификации бизнес-логики или модернизации системы изменения осуществляются только на
серверной стороне. Однако очень часто эти изменения влияют на пользовательский интерфейс и
вызывают соответствующие изменения на стороне клиента.
Другой крайний случай — перенос бизнес-логики на сторону клиента. При этом клиентская часть
приложения замедляет работу, время связи с сервером возрастает, что существенно ухудшает общие
характеристики системы.
Кроме того, любые изменения бизнес-логики или модернизация приложения приводят к
трудоемким изменениям на стороне клиента и переустановке клиентской части приложения на
компьютерах всех пользователей данного приложения.
Решение этой проблемы реализации бизнес-логики неоднозначно и зависит от конкретной системы,
опыта и предпочтений разработчика.
Некоторая неопределенность выбора места выполнения бизнес-логики и зависимость интерфейса
пользователя от ее реализации делают нетехнологичным процесс проектирования клиентсерверного приложения.
Логичным решением этой проблемы явилась идея выделения функциональности проектируемой
программной системы, связанной с бизнес-логикой, в отдельный архитектурный уровень.
Многоуровневые приложения
Многоуровневые приложения (Multi-tier applications) представляют собой приложения, разделенные на
части по количеству уровней, причем, эти части могут быть размещены на различных компьютерах.
Количество уровней, в принципе, не ограничено, однако обычно не бывает больше пяти.
Многоуровневые системы, как правило, одновременно являются и многопользовательскими, т. к.
предназначаются для коллективного использования. Однако для существа их архитектуры
гораздо важнее их многоуровневый характер.
Рассмотрим основную идею архитектуры многоуровневых приложений, пока не останавливаясь на
деталях и вариантах архитектурных решений.
Выделение среднего уровня
В многоуровневой программной системе выделяется Средний уровень (Middle tier), на котором
размещается бизнес-логика приложения (рис. 7).
Рис. 7. Многоуровневое приложение
Деление программной системы на уровни (tiers) является не физическим распределением
программного обеспечения между различными компьютерами, а представляет собой концептуальное
разделение задачи на уровни по логическому принципу.
Клиент всегда является инициатором связи с серверной частью. Управление данными поддерживается
системой управления базами данных.
(СУБД), которая реализует все основные действия над данными: поиск, добавление, удаление,
обновление. При этом данные могут храниться на одном компьютере или на нескольких
(распределенные базы данных).
Клиент взаимодействует с данными через API (Application Programming Interface), например, Open
Database Connectivity (ODBC) или Java Database Connectivity (JDBC).
Это отделяет клиента от конкретных деталей реализации баз данных.
Data tier (Уровень данных) из соображений защиты информации целесообразно физически
разместить на отдельном сервере.
Доступ клиента к данным возможен только через средний уровень с использованием API-системы
управления базой данных.
При реализации многоуровневого приложения возникает знакомая проблема, связанная с
размещением среднего уровня. Необходимо решить, где будет размещаться и выполняться часть
приложения, реализующая средний уровень.
Количество уровней может быть и больше. Несколько забегая вперед, приведем еще одну общую
схему многоуровневого приложения (рис. 8).
Рис. 8. Пример многоуровневой архитектуры
В данном случае на стороне клиента находится Client Presentation tier (Уровень представления
клиента), на стороне сервера — Server Presentation tier (Уровень представления сервера),
Business logic tier (Уровень бизнес-логики) и Integration tier (Уровень интеграции),
осуществляющий связь с информационной системой.
Таким образом, многоуровневая архитектура распределяет приложение между клиентской и
серверной стороной следующим образом:
- информационная часть приложения (базы данных) размещается на сервере;
- пользовательский интерфейс располагается на стороне клиента;
- бизнес-логика может находиться или на клиентской стороне (толстый клиент), или на
серверной стороне (тонкий клиент), или частично на клиентской и частично на серверной.
Для того чтобы показать, что архитектура Клиент/Сервер вписывается в общую концепцию
многоуровневой архитектуры, клиент-серверные системы называют также двухуровневыми
клиент-серверными приложениями.
Основным недостатком архитектуры Клиент/Сервер является то, что любые изменения в
бизнес-логике или функциях доступа к данным, вызывающие изменения в клиентской части
приложения (более или менее значительные, в зависимости от "толщины" клиента), требуют
переустановки новой клиентской части на всех клиентских местах.
Многоуровневая архитектура, разделяющая программную систему на три основных уровня
(представления, бизнес-логики и уровень доступа к данным), намного технологичнее:
- клиентская часть отделена от любых изменений в остальных частях приложения;
- достигается большая гибкость приложения, т. к. оно, как из строительных блоков,
формируется из сравнительно небольших модулей.
Распределенные системы
Многоуровневая
архитектура
предназначена
для
реализации
клиент-серверных
многоуровневых приложений. Приложение на основе логической концепции разбивается на
уровни, части программного кода одного приложения могут находиться на различных
компьютерах, и в этом смысле его можно считать распределенным. Однако в многоуровневых
приложениях сохраняется линейный характер взаимодействия между клиентом и сервером.
В распределенной системе все приложение представляется как набор равноправных
взаимодействующих объектов, который выполняет определенную функциональность.
Каждый объект предоставляет некоторый набор сервисов и сам может использовать сервисы,
предоставляемые другими объектами системы.
Таким образом, роли жестко не определены, и каждый объект системы может одновременно
выступать и как сервер, и как клиент.
Протокол взаимодействия между двумя объектами распределенной программной системы
определяется интерфейсом.
Так как именно интерфейс компонента определяет, какие сервисы предоставляет данный
компонент и как эти сервисы использовать, целесообразно не изменять интерфейсы в течение
жизненного цикла программной системы. В этом случае возможные изменения, модификация и
усовершенствование компонентов осуществляются на уровне реализации, не затрагивая
интерфейсы, и потому оказываются незаметными для пользователя.
Компонент (Component) — это объект распределенной системы с соответствующими интерфейсами.
Реализация компонента отделена от интерфейса, что позволяет проектировщику изменять
отдельные компоненты, не изменяя остальные части системы. Для этого необходимо сохранять
неизменными только интерфейсы всех компонентов распределенной системы.
Основные компонентные технологии, позволяющие реализовать распределенную систему, будут
рассмотрены далее.
Основные понятия архитектуры
многоуровневых приложений
В этом разделе мы рассмотрим более подробно основные понятия архитектуры распределенных
систем, ориентированных на использование в сети Интернет.
Тонкий и толстый клиент
Термины thin client {тонкий клиент) и thick client (толстый клиент), в первую очередь, используются
для обозначения мощности клиента:
- Thin client (Тонкий клиент) — малофункциональный и маломощный сетевой терминал;
- Thick client (Толстый клиент) — персональный компьютер средней мощности с достаточно
широкими функциональными возможностями.
Кроме того, эти же термины используются для обозначения того, в какой пропорции распределяется
приложение между клиентской и серверной стороной:
- Thin client (Тонкий клиент) — вариант, когда на клиентской части находится минимальная
часть программной системы, необходимая только для организации запросов и ускорения работы
пользователя в сети, а вся основная нагрузка ложится на серверную часть;
- Thick client (Толстый клиент) — вариант, при котором почти вся программная система
устанавливается на клиентской стороне, а на серверной стороне размещается, например,
только информационная часть (базы данных).
При реализации приложений уровня предприятия более предпочтительным является
использование тонкого клиента.
Браузеры
Интернет-браузер (Internet browser), как правило, является основным средством
взаимодействия клиента с серверной частью приложения. Сеть Интернет поддерживается
протоколом TCP/IP.
World Wide Web (сокращенно www) обеспечивает удобный интерфейс, позволяя работать с
гипертекстовыми ссылками.
Понятие Web объединяет серверы с хранящейся на них информацией, доступной с помощью
гипертекстовых ссылок, и браузеры для просмотра этой информации, обладающие графическим
интерфейсом.
World Wide Web поддерживает протокол HTTP (Hypertext Transfer Protocol, Протокол передачи
гипертекстовых файлов) — систему правил обмена данными в Web. Местонахождение ресурса
определяется унифицированным адресом ресурса URL (Uniform Resource Locator,
Унифицированный адрес ресурса).
Web является комбинацией многих технологий и базируется на модели Клиент/Сервер, в которой
клиентом является Web-браузер. Сервером служит, как правило, менеджер ресурсов,
поставляющий документы, рисунки и т. д.
В функции браузера входит:
- выполнение программной части, относящейся к уровню клиента;
- поиск информации в сети Интернет и загрузка HTML-страниц и JSP;
- отображение текстовой и графической информации, загружаемой с серверной стороны;
- автоматическая загрузка Java-кода и JavaScript-кода на выполнение; - передача на сервер
данных пользователя.
Несомненные преимущества, предоставляемые Web, обусловили широкое использование этого
способа доступа к ресурсам Интернет при реализации приложений уровня предприятия. В
настоящее время решение задач управления деятельностью предприятий невозможно без
предоставления информации руководителям предприятия, его сотрудникам, партнерам и
заказчикам с помощью Web.
HTTP Client
HTTP Client (HТТР-клиент) — это Web browser (Веб-браузер), установленный на персональном
компьютере пользователя и посылающий запрос серверу.
Пользователь осуществляет запрос с помощью ввода в окно браузера адреса Web-файла в
Интернет или использует для открытия Web-файла гиперссылку (Hypertext link).
Браузер организует HTTP-запрос и посылает его в Internet Protocol address (Адрес протокола
Интернет). Сервер, найденный по этому адресу, получает запрос, обрабатывает и отсылает ответ.
Унифицированный адрес ресурса
Унифицированный адрес файла или ресурса обозначается аббревиатурой URL (Uniform Resource
Locator, Универсальный адрес ресурса). URL-адреса представляют любые ресурсы, вне
зависимости от их типа и без каких-либо ограничений. Механизм представления один и тот же
для документов, изображений и приложений. Он используется, в частности, в Java для
представления протоколов RMI (Remote Method Invocation) и JDBC (Java Database Connectivity).
URL предоставляет пользователю информацию о том, где расположен ресурс и какой протокол
он использует. Наиболее распространенным является протокол HTTP, однако, URL-система
адресации поддерживает и другие протоколы.
Несмотря на то, что URL представляет адреса различных ресурсов в унифицированном виде, от
протоколов не требуется единый синтаксис. Различные синтаксисы протоколов поддерживаются
общим форматом:
scheme:sheme_specific_string
Схема (scheme) определяет протокол TCP/IP, поддерживающий обращение к ресурсу Интернет.
Большинство протоколов имеет синтаксис Common Internet Scheme Syntax, CISS (Общий
синтаксис Internet-схем):
scheme://user_name:password@host:port/path
Формат CISS является подмножеством общего формата URL.
Scheme (Схема) — это протокол связи, например, HTTP.
Перечислим наиболее распространенные форматы ресурса.
 HTTP (Hypertext Transfer Protocol, Протокол передачи гипертекстовых файлов):
http://host:port/path?querystring
В этом формате используются следующие элементы:
• host (xoct) определяет имя домена сервера или IP-адрес;
IP — Identification of Pbsition (Идентификация положения).
• port (порт) — необязательный элемент, определяющий номер порта компьютера, через
который осуществляется соединение. Номер порта по умолчанию — 80;
• path (путь) — необязательный элемент, определяющий путь к ресурсу. Если этот элемент
отсутствует, "/" перед ним опускается;
• querystring (строка запроса)— необязательный элемент, предоставляющий дополнительную
информацию о ресурсе. Если этот элемент отсутствует, знак "?" опускается.
В запросе querystring используется простой синтаксис, который обрабатывается протоколом
HTTP:
name = value (имя=значение)
Если используется составной запрос, каждый отдельный простой запрос отделяется от
следующего символом "&".
Пример HTTP URL:
http: / /www.samplesoft.com/figures?name='figurel.gif'
 FTP (File Transfer Protocol) — протокол передачи файлов, используемый в Интернет для
передачи файлов между хост-компьютерами.
Формат соответствует формату CISS:
ftp: //user_name:password@host:port/path
Имя пользователя и его пароль являются необязательными параметрами.

Mail — протокол электронной почты. Формат:
mailto:email_login@host

Telnet — сетевой теледоступ: протокол виртуального терминала в наборе протоколов Интернет,
позволяющий пользователям одного хоста подключаться к другому удаленному хосту и
работать с ним как через обычный терминал.
Формат:
telnet: //user_name : password@host: port

File
Формат:
file://host:port/path
На локальном компьютере:
file://localhost:8080/path
Для нас наиболее важным, естественно, является URL-адрес в формате протокола HTTP, т. к.
именно этот протокол использует World Wide Web.
Реализация обмена данными
Рис.9.иллюстрирует организацию связи между HTTP-клиентом и Web-сервером с использованием
протокола HTTP.
Для того чтобы пользователь в любой момент мог связаться с сервером, Web сервер находится в
состоянии ожидания, используя для этого определенный порт (предопределенный порт — 80) и
IP-адрес.
Рис. 9. Взаимодействие между HTTP-клиентом и Web-сервером
HTTP-клиент формирует необходимый URL и устанавливает соединение с сервером с помощью
клиентской программы, которая использует HTTP-протокол, номер порта и IP-адрес.
Сервер принимает и обрабатывает HTTP-запрос, сформированный клиентом и переданный по
сети с использованием протокола TCP/IP. После этого сервер передает клиенту ответ, используя
соединение TCP/IP. На стороне клиента производится обработка ответа, после чего соединение
разрывается. Просмотр результата осуществляется с помощью браузера.
Механизмы связи
Механизмы связи выбираются, исходя из бизнес-модели конкретной задачи. В таблице 2
приведены некоторые наиболее распространенные протоколы связи, поддерживающие
распределенные приложения.
Таблица 2. Механизмы связи
Сокращенное
наименование
HTTP
Полное наименование
Пояснение
Hypertext Transfer Protocol
Общий широко распространенный протокол для
организации доступа во внутренних сетях
предприятия, а также в сети Web. Этот протокол
достаточно просто устанавливается и
поддерживается
HTTPS
Hypertext Transfer Protocol
over Secure Socket Layer
(SSL)
RMI
Remote Method Invocation
Используется для Java-приложений в тех случаях,
когда не применяются аппаратно-программные
средства межсетевой защиты (firewalls). Такая
ситуация может быть, например, при реализации
приложений для функционирования во
внутренней сети предприятия
IIOP
Internet Inter-Object Request
Broker (ORB) Protocol
Стандарт OMG, который интегрирует связи между
системами и различными языками
программирования, в том числе Java
TCP
Transmission Control
Protocol
Протокол управления передачей, основной
протокол транспортного и сеансового уровней в
наборе протоколов Internet
TCP/IP
Transmission Control
Protocol/ lnternet Protocol
Протокол управления передачей/межсетевой
протокол, стек протоколов Internet для
использования в семействе сетей Internet и для
объединения неоднородных сетей
Этот протокол является версией протокола HTTP
для случаев, когда особенно важно обеспечение
защиты информации. HTTPS использует HTTPзапросы через Secure Socket Layer (SSL)
Рассмотрим основные методы протокола HTTP, так как именно этот протокол используется
наиболее часто в многоуровневых и распределенных приложениях.
Hyper Техt Transfer Protocol
Hyper Text Transfer Protocol (HTTP) - один из наиболее важных и часто используемых
протоколов при реализации многоуровневых приложений.
HTTP - прикладной протокол, использующий для передачи данных протокол транспортного
уровня TCP/IP.
Протокол HTTP не сохраняет состояние между сессиями, но допускает несколько транзакций
во время одного соединения.
В спецификации протокола HTTP определен ряд методов, реализующих клиент-серверный
протокол. Наиболее важными являются следующие три метода:
- GET;
- POST;
- HEAD.
Метод Get используется для доставки любого файла, поддерживаемогоWeb и
специфицированного с помощью URL адреса. На размер URL накладываются ограничения:
URL-должен быть представлен не более, чем 256 символами. Метод Get может дополнительно
передать серверу параметр с помощью строки запроса querystring в URL-адресе.
Метод Post также посылает информацию на сервер. При использовании метода Post эти
ограничения снимаются, т. к. информация передается через сокет. Еще одно отличие от метода
Get состоит в том, что при посылке информации с помощью Post URL не изменяется.
Метод Head доставляет заголовок или некоторую метаинформацию о ресурсе без передачи
непосредственно самого ресурса. Передаваемая мета-информация включает размер
передаваемого документа, время его модификации и т. д.
Таким образом, HTTP-клиент формирует и передает HTTP-запрос, на который получает HTTPответ.
Спецификация протокола HTTP регламентирует форматы HTTP-запроса и HTTP-ответа.
Сообщения
В зависимости от решаемой задачи, сообщения могут быть двух типов:

синхронные;

асинхронные
Синхронное сообщение предполагает отсылку сообщения и ожидание ответа, без получения которого
невозможны дальнейшие действия объекта, отославшего сообщение.
Асинхронное сообщение — это отсылка сообщения без ожидания немедленного ответа. Объект,
отославший сообщение, продолжает работу. Время на получение ответа не регламентировано,
более того, ответ может быть вообще не получен.
Транзакции
Наиболее важным понятием при конструировании Интернет-ориентированных приложений
является транзакция. Транзакция (transaction) — это способ объединения нескольких операций в
единый модуль. В результате выполнения транзакции возможны только две ситуации: или все
операции, входящие в данный модуль, успешно выполнились, или не выполнилась ни одна из
операций, т. е. сохранилось состояние системы, предшествовавшее транзакции.
Например, в системе автоматизации бухгалтерского учета при программной реализации
бухгалтерской проводки остаток некоторого счета (счет кредита) должен уменьшиться на сумму
проводки, а сумма корреспондирующего с ним счета — увеличиться на ту же сумму.
Недопустима ситуация, при которой остаток первого счета уменьшится, а остаток второго счета
не увеличится. Оба взаимосвязанных действия должны или произойти совместно, или не должно
состояться ни одно из них. Аналогичные проблемы возникают при переводе денежных средств с
одного расчетного счета на другой и т. д. Любые изменения информации в программной системе
должны происходить согласованно.
Таким образом, транзакция либо фиксируется при положительном завершении всех
взаимосвязанных операций, либо происходит откат (rollback) в исходное состояние. Транзакции
характеризуются следующими свойствами: атомарностью, согласованностью, устойчивостью и
изолированностью.
Для обозначения основных свойств транзакций применяется аббревиатура ACID:
 Atomicity (Атомарность);
 Consistency (Согласованность);
 Isolation (Изолированность);
 Durability (Устойчивость).
Атомарность (Atomicity) — это свойство транзакции либо фиксировать результат удачных
взаимосвязанных действий, относящихся к данному модулю, либо возвращать программную
систему в прежнее состояние, если хотя бы одно из взаимосвязанных действий завершилось
неудачно.
Согласованностъ (Consistency) — это свойство транзакции согласованно изменять состояние
всех объектов системы, над которыми она осуществляется.
Изолированность (Isolation) или сериализуемость — это свойство транзакции обеспечивать
независимость одновременно происходящих транзакций друг от друга. Если некоторая
транзакция начала выполняться в то время, когда какая-то другая еще не закончилась, новая
транзакция должна выполняться так, как если бы она была единственной. Одновременно
выполняющиеся транзакции не должны влиять друг на друга.
Устойчивость (Durability)— это свойство сохранять результат транзакции (как
положительный, так и отрицательный) при возможных аварийных ситуациях и сбоях.
В распределенных приложениях транзакции выполняются между удаленными компьютерами,
что существенно усложняет их обработку.
Слои в архитектуре приложений
Архитектура приложений рассматривается в различных сечениях, представленных на рис. 10.
Подробное рассмотрение проблем, связанных с архитектурой, выходит за рамки данной книги.
Однако, для общего понимания процесса проектирования, рекомендуется знать ряд терминов.
Рис. 10. Слои в архитектуре приложений
Куб на рис. 10, представляющий концептуальную структуру архитектуры системы, в трех
ортогональных плоскостях делится сечениями на слои (уровни) трех типов:
 Layers (Слои);
 Tiers (Уровни);
 Capabilities (Возможности).
Эти слои представляют различные элементы архитектуры. Таким образом, архитектура
рассматривается как набор возможных решений. При разработке архитектуры приложений уровня
предприятия проектирование ведется с учетом всех трех плоскостей.
Layers
Layers являются абстракцией, отражающей концепцию реализации системы. Каждый такой слой
скрывает детали нижнего уровня.
Например, слоями (layers) реализации Java-приложения являются:

Application (Приложение);

Virtual platform (Виртуальная платформа);

Upper platform (Платформа высокого уровня) — системное окружение, например, сервер
приложений;
 Lower platform (Платформа низкого уровня) — операционная система.
Платформа низкого уровня скрывает детали аппаратной реализации и предлагает систему
программных интерфейсов (APIs), управляющих аппаратными средствами.
Платформа высокого уровня скрывает реализацию платформы низкого уровня (потоки и
взаимодействий операционной системы) и предоставляет окружение, в котором существуют
компоненты.
Виртуальная платформа скрывает реализацию сервера приложений, предоставляя доступ к нему с
помощью программных интерфейсов (APIs).
Приложение — самый высокий слой, содержащий бизнес-логику (business logic) и логику
представления (presentation logic). Этот слой скрывает детали реализации приложения: как именно
приложение работает в данной операционной системе или на данном сервере приложений.
Tiers
Tiers - уровни, которые используются для отражения не физической, а логической
концепции разделения приложения, которая определяет роли и ответственности уровней в
системе.
Например, у многоуровневого J2EE приложения возможны следующие Уровни (tiers):





Client tier (Уровень клиента);
Presentation tier (Уровень преставления);
Business logic tier (Уровень бизнес логики);
Integration tier (Уровень интеграции);
Resource tier (Уровень ресурсов).
Client tier (уровень клиента) — это, в первую очередь, интерфейс пользователя (user interfase), а
также модули поддержки взаимодействия пользователя с системой, апплеты и т. п.
Presentation tier (Уровень преставления) — внешнее представление содержательной части системы
на основе бизнес-информации.
Business logic tier {Уровень бизнес логики) содержит бизнес-логику приложения.
Integration tier {Уровень интеграции) — логика интеграции с ресурсами.
Resource tier (Уровень ресурсов) содержит ресурсы системы, в том числе базы данных.
Capabilities
Эти слои определяют качества системы, которые не являются определенными функциями и
не могут быть представлены с помощью некоторого компонента, но характеризуют качество и
работоспособность данной системы. Наиболее существенными являются следующие качества
системы:
o Availability (Работоспособность) — мера работоспособности системы, гарантия того, что
соответствующие сервисы или ресурсы всегда доступны;
o Capacity (Емкость) — способность запускать на выполнение некоторое количество
задач в единицу времени;
o Extensibility (Расширяемость) — способность эффективно модифицировать систему
или расширять ее функциональность;
o Flexibility (Гибкость) — способность системы поддерживать изменения конфигурации
архитектуры и аппаратных средств;
o Managebility (Управляемость) — способность управлять системой с целью поддержки
других основных качеств системы;
o Performance (Выполнение) — способность достаточно быстро выполнять функции, для
того чтобы цели системы были выполнены;
o Reliability (Надежность) — способность обеспечивать целостность и сохранность
системы и ее транзакций;
o Scalability (Масштабируемость) — способность поддерживать требуемое качество работы
системы при повышении нагрузки;
o Security (Секретность) — способность обеспечивать защиту информации от
несанкционированного доступа и поддерживать только действия над данными,
предусмотренные политикой защиты информации;
o Testability (Тестируемость) — способность прогнозировать результаты.
Распределенные вычисления
В распределенных вычислениях за основу взято отношение Клиент/Сервер, при котором
приложение разделяется на много программ и распределяется между многими компьютерами.
Эти программы взаимодействуют друг с другом с помощью сети.
Если приложение построено на основе принципов объектно-ориентированного
программирования, эти программы являются объектами. В системах с распределенными
вычислениями объект, находящийся на одном компьютере, может вызывать метод объекта,
находящегося на другом компьютере.
При этом сервер может являться клиентом по отношению к другому серверу. Реализация
такой распределенной системы является довольно сложной задачей, т.к. компьютеры,
участвующие в распределенных вычислениях, могут быть различного типа.
Основными участниками функционирования приложения в сети Интернет являются клиенты
и серверы, а также программное и Web-окружение.
Распределенный характер приложений делает особенно важными проблемы взаимодействия,
средства и механизмы связи, используемые в Интернет-ориентированных системах.
Технологии реализации распределенных систем
Мы кратко рассмотрим технологии распределенных систем, т. к. корпоративные
приложения, разработанные на основе технологий J2EE, как правило, существуют не сами по
себе, а объединяются и взаимодействуют с другими приложениями, выполненными на других
платформах, образуя сложные системы, функционирующие в неоднородной распределенной
сетевой среде.
Существуют следующие технологии, использование которых дает возможность реализовать
архитектуру распределенных приложений:

Socket programming — программирование сокетов;

RPC (Remote Procedure Calls) — удаленный вызов процедур;

DCE (Distributed Computing Environment)— распределенная вычислительная среда;

DCOM (Distributed Component Object Model) — распределенная объектная модель компонентов;

RMI (Remote Method Invocation) — удаленный вызов методов;

CORBA (Common Object Request Broker Architecture) — обобщенная архитектура брокера
объектных запросов;

Web services - Web-сервисы.
Программирование сокетов
Socket (сокет) дает пользователю возможность создать канал, по которому приложения
соединяются и взаимодействуют дуг с другом. Сокет (socket) - это абстракция, которая изолирует
код прикладной программы от низкоуровневых реализаций стека протоколов TCP/IP. Сокет
описывает сетевое соединение с другим приложением. Протокол TCP/IP поддерживает набор
стандартов взаимодействия разноплатформенных систем в сети Интернет.
Сокеты эффективно используются для небольших клиент-серверных приложений. На рис. 11
представлена обобщенная схема соединения клиентов с сервером с использованием сокетов.
Рис. 11. Подключение клиентов к серверу с помощью сокетов
Сокеты используют низкоуровневый API (Application Programming Interface) — прикладной
программный интерфейс.
Протокол TCP/IP, являющийся основой Интернет, поддерживает работу с гнездами. Гнездо —
это пара (номер порта, IP-адрес), соответствующая некоторому компьютеру, участвующему в
соединении. Для того чтобы организовать соединение приложений, установленных на разных
компьютерах, используется следующая информация:
□ информация о клиенте:
• IP-адрес локального компьютера клиента;
• номер порта локального компьютера клиента, на котором установлено
приложение, ожидающее связи;
□ информация о сервере:
• IP-адрес компьютера сервера;
• номер порта компьютера сервера, на который отзывается приложение,
ожидающее связи.
Сервер ожидает подключения клиентов. Инициаторами связи выступают клиенты.
Высокая эффективность сокетов в случае простых приложений, к сожаления не
распространяется на большие распределенные системы. Так, например, с океты не
поддерживают составные типы данных.
С помощью сокетов невозможно реализовать связь между приложениями, выполненными на
разных платформах.
Краткая характеристика RPC и DCE
Remote Procedure Calls, RPC (Удаленный вызов процедур) — это протокол, поддерживающий
функционально-ориентированный интерфейс для осуществления связи на уровне гнезд (порт, IPадрес).
В этом случае работа с сокетом происходит не напрямую, а с помощью специально определенных
промежуточных функций. Клиент посылает на сервер сообщение, содержащее параметры вызова
удаленной процедуры, находящейся на сервере. Результаты выполнения процедуры сервер
посылает клиенту в другом сообщении. Таким образом, программа, установленная на одном
компьютере, инициирует выполнение необходимой программы на другом компьютере.
Идея использования посредника была задействована и развита в технологии RMI.
Distributed Computing Environment, DCE (Распределенная вычислительная среда) — это совокупность
стандартов, определяющих использование RPC. Система стандартов DCE, разработанная группой
Open Software Foundation (Фонд открытого программного обеспечения), представляла набор
функций, не зависящих от конкретной платформы и предназначенных для поддержки работы
распределенных систем.
В состав DCE входят функции присвоения имен, обслуживания распределенных файлов и
потоков, удаленного вызова процедур, поддержания информационной безопасности и др.
Несмотря на то, что эта система стандартов не нашла широкого практического применения,
стандарты DCE учитываются во всех наиболее распространенных системах. Эти стандарты
также оказали существенное влияние на развитие других технологий, поддерживающих
распределенные системы.
Использование компонентных технологий для реализации
распределенных корпоративных систем
Основная идея компонентных моделей состоит в том, чтобы предоставить пользователю
возможность построения приложения с использованием набора совместимых друг с другом
компонентов. Каждый компонент при этом представляет собой независимый "строительный" блок
программного кода. Основываясь на компонентном подходе, объектные архитектуры позволяют
создавать распределенные системы и интегрировать программное обеспечение, написанное на
разных языках и запускаемое в отдельных процессах или на разных машинах. Пользователю
предоставляется возможность использовать набор неких компонентов (сервисов) вне
зависимости от того, кто обеспечивает и поддерживает эти компоненты и где они размещаются.
Общие принципы компонентных технологий
Главные принципы компонентных технологий:
- использование преимуществ объектно-ориентированных концепций;
- способность работать с наследуемым кодом.
Сервисы
Сервис (Service) — это часть программного обеспечения, отвечающего за решение конкретной четко
определенной подзадачи в рамках решения общей проблемы.
Физически сервисы могут быть представлены разными способами с возможностью реализации через
системные вызовы, вызовы функций библиотек и т. д.
Компоненты
Под компонентом понимается часть программного обеспечения, которая также решает какую-то
определенную подзадачу общей задачи, но разбиение происходит не по функциональному
признаку, а с точки зрения удобства программирования, распространения, инсталляции и т. п.
Программный компонент — это повторно используемые части кода и данных в двоичной форме,
которые могут быть с относительно малыми усилиями вставлены в другие программные
компоненты, предоставляемые другими производителями.
Программные компоненты должны иметь возможность соединяться в соответствии с некоторым
внешним двоичным стандартом, а их внутренняя реализация не должна быть никак ограничена.
Компоненты могут быть созданы с использованием процедурных языков, объектноориентированных языков оболочек и т. п.
Сервис может состоять из одного и более компонентов, часто компонент и является сервисом. В
любом случае, сам компонент состоит из одного или более объектов, причем, каждый объект
обеспечивает свою функциональность через один или более интерфейсов. Интерфейс
содержит один или более методов. Именно через интерфейсы работает компонент. Существуют
простые сервисы распределения памяти, которые имеют один компонент, один объект и один
интерфейс на объект. Наряду с этим, другие компоненты могут иметь несколько объектов,
каждый из которых выставляет несколько интерфейсов для доступа к множеству свойств.
Таким образом, создается компьютерное окружение, в котором разработчики и ко нечные
пользователи могут последовательно добавлять новые свойства в свои приложения, просто
покупая дополнительные компоненты.
Компонентные технологии
Компонентное программное обеспечение — ориентированная на потребителя реализация
принципов объектно-ориентированного программирования.
Основными компонентными технологиями, используемыми для реализации распределенных
приложений, являются COM/DCOM и CORBA.
Практика показывает, что сложное корпоративное приложение невозможно реализовать на
одном, даже самом развитом, объектно-ориентированном языке программирования и на одной
платформе. Компонентные технологии поддерживают взаимодействие разнородных объектов,
предоставляя промежуточное программное обеспечение. Тем самым создается инфраструктура для
работы распределенных систем.
Компонентные технологии распределенных приложений поддерживают три основных принципа:
- независимость компонентов от их физического размещения;
- независимость компонентов от платформы;
- независимость компонентов от выбранного языка программирования.
Кроме того, компонентные технологии обеспечивают:
 расширяемость архитектуры;
 возможность создавать программные компоненты, которые можно распространять и повторно
использовать;
 единый подход к созданию всех типов программных сервисов;
 решение проблемы контроля версий: клиент должен иметь возможность безболезненной
замены одного компонента на другой, более совершенный.
Эти требования означают, что компоненты промежуточного программного обеспечения могут
физически находиться в разных файлах, размещаться на разных компьютерах, выполняться на разных
аппаратных платформах и в разных операционных системах. Сами компоненты могут разрабатываться
с использованием различных языков программирования.
Различия в реализации компонентов не должны влиять на их взаимодействие.
Компонентные технологии поддерживают архитектуру Клиент/Сервер. Доступ клиента к объекту
на сервере реализуется с помощью абстрактных интерфейсов. Абстрактный интерфейс
предоставляет клиенту возможность вызова ряда методов, скрывая от него детали реализации
этих методов.
Клиент вызывает метод объекта через его интерфейс (interface) (рис.12). Вызванные методы
выполняются на сервере. Таким образом, интерфейс (interface) — это абстрактный набор вызовов
методов, не содержащий деталей реализации. Реализация (implementation) представляет код,
обеспечивающий выполнение методов, доступ к которым осуществляется через интерфейсы.
Конкретный метод, реализующий некоторую функциональность объекта, вызывается по ссылке.
Рис. 12. Интерфейс и его реализация
В связи с тем, что детали реализации (implementation) скрыты, и клиенту виден только интерфейс,
для клиента совершенно неважно, в рамках какой платформы выполнен вызываемый объект.
Способ удаленного вызова метода объекта напоминает механизмы, заложенные в технологии
RPC, с той разницей, что в данном случае взаимодействие происходит между объектами. Клиент
передает сообщение серверу с вызовом метода, а сервер присылает клиенту ответ. Этот механизм
взаимодействия клиента и сервера поддерживают специальные компоненты:
 Client stab {Стаб, Суррогат клиента);
 Server stab (Стаб, Суррогат сервера).
Client stub и Server stub иногда также называют заглушками. На рис. 13 показано, как
взаимодействуют клиентская и серверная стороны при использовании компонентных технологий.
Рис. 13. Компонентные технологии: взаимодействие клиента и сервера
Вызов клиентом метода объекта, находящегося на стороне сервера, происходит следующим
образом:
1. Объект object 1 на стороне клиента обращается к клиентскому стабу.
2. Стаб формирует запрос в упакованном виде и передает транспортному протоколу TCP/IP.
3. С помощью транспортного протокола TCP/IP сообщение-запрос доставляется серверу.
4. Стаб на серверной стороне распаковывает полученное сообщение-запрос.
5. Стаб на серверной стороне вызывает необходимый метод объекта object 2, находящегося на
сервере.
6. После выполнения метода объект object 2 передает стабу серверной стороны результат
деятельности метода.
7. Стаб на стороне сервера запаковывает результат и связывается с транспортным уровнем.
8. С помощью транспортного протокола TCP/IP сообщение-ответ доставляется клиенту.
9. Стаб на стороне клиента распаковывает сообщение ответ. 10. Стаб на стороне клиента
передает результат объекту-клиенту object l.
Сообщение-запрос содержит вызов метода и некоторые аргументы, сообщение-ответ - результат
работы метода. Если объект-клиент и объект-сервер выполнены на различных платформах,
параметры вызова, сформированные на клиенте, могут быть "непонятны" серверу, а ответ сервера
не будет соответствовать языковой платформе клиента. Промежуточное программное обеспечение
(стабы клиента и сервера) осуществляют сопряжение различных платформ, осуществляя
преобразование параметров вызова на клиентской стороне и результата на серверной стороне к
стандартизованной универсальной форме представления. Эта форма не зависит от платформы и
архитектуры участников распределенной системы.
Между разными компонентными технологиями существуют отличия, связанные с конкретной
реализацией объектов, интерфейсов и механизма вызова методов. Каждой технологии
соответствует своя обобщенная объектная модель.
Компонентная технология DCOM
Distributed Component Object Model, DCOM (Распределенная компонентная обектная модель) — это
компонентная технология, являющаяся расширением модели Component Object Model, COM
{Компонентная объектная модель) фирмы Microsoft, ориентированная на поддержку и интеграцию
распределений объектных приложений, взаимодействующих в сети.
Технологии COM/DCOM разработаны, в основном, под платформу Windows, что несколько
ограничивает область их применения.
Краткая характеристика технологии СОМ
Component Object Model, COM (Объектная модель компонентов) — стандартная компонентная модель,
реализованная на платформе Microsoft. Технология СОМ предоставляет пользователю компонентный
подход к разработке программного обеспечения. Каждый компонент обладает набором средств,
достаточных для того, чтобы другая программа, обратившись к компоненту, могла получить
определенные услуги. Термин СОМ тесно связан с терминами ActiveX и Object Linking and
Embedding, OLE (Технология создания составных документов внедрением и связыванием) фирмы
Microsoft.
Составной документ — это документ, который собирается из множества источников (текст, графика,
диаграммы, таблицы, звук, видео и т. п.).
Технология ActiveX — расширяемая архитектура, основанная на множестве ключевых
приспосабливаемых к требованиям пользователя (customized) сервисов, каждый из которых
обеспечивает создание пользовательских сервисов любой сложности, в свою очередь,
расширяющих данную архитектуру.
Все сервисы, вне зависимости от их сложности, реализации, места размещения и выполнения, могут
быть использованы всеми приложениями, операционными системами или другими сервисами.
ActiveX применяется для совместного использования частей приложения с другими приложениями и
для доступа к другим разделяемым компонентам.
Программы, использующие технологию СОМ, называют ActiveX или OLE. Технология СОМ
поддерживает также Microsoft Transaction Server (Сервер транзакций Microsoft). На рис. 14
представлена модель СОМ. Архитектура СОМ первоначально не предназначалась для
распределеннных систем. Предполагалось, что речь идет о взаимодействии процессов,
протекающих на одной машине. ActiveX и OLE используются для создания сложных объектов.
Объект СОМ — это экземпляр СОМ класса, представляющий собой набор функций,
поддерживающих компоненты, но не сохраняющих информацию о состоянии между
вызовами. Класс реализует один или несколько интерфейсов.
Рис. 14. Технология СОМ
Суть архитектуры СОМ показана на рис. 15.
Рис. 15. Архитектура технологии СОМ
Приложение-клиент
напрямую взаимодействует с объектом серверного приложения через
интерфейс этого объекта. СОМ поддерживает связь между клиентом и сервером. Microsoft
Transaction Server (Монитор транзакций) поддерживает долговременное сохранение информации
во
внешней
памяти.
Другим способом, имитирующим сохранение данных, является
использование так называемых "защелок" (moniker). В технологии СОМ не используются объектные
ссылки. Вместо них применяются "защелки", преобразующие символьное имя сохраняемого объекта
в указатель интерфейса.
Проблема межсетевой идентификации объектов
В технологии COM/DCOM для доступа к объектам используются глобальные уникальные
идентификаторы (Global Unique Identifiers, GUIDs).
Клиент может вызвать объект только через его интерфейс.
Существует четыре основных пути уникально идентифицировать класс:
 по имени API-функции, которая создает или возвращает объект класса;
 по позиции объекта внутри иерархии компонентов (через имя функции интерфейса,
которая обеспечивает к нему доступ);
 по некоторому внутреннему имени класса или структуры, которое создается, когда
создается сам объект и затем выставляется наружу клиенту;
 по глобальному уникальному идентификатору класса (Class Identifier, CLSID).
Распределенное окружение имеет множество компонентов, объектов и интерфейсов, которые
нужно идентифицировать единственным образом. Проблема уникальной межсетевой
идентификации возникла еще до появления технологии СОМ. Эта проблема решалась в
технологии Remote Procedure Calls (RPC). Поэтому организация Open Software Foundation (OSF)
ввела понятие универсального уникального идентификатора (Universally Unique Identifier —
UUID) как часть спецификации распределенного вычислительного окружения (Distributed
Computing Environment — DCE). В COM/DCOM используются те же универсальные уникальные
идентификаторы (UUID), что и в спецификации DCE / RPC. Объектом в СОМ является
экземпляр класса. Клиент получает доступ к объекту с помощью указателя на один из его
интерфейсов (interface pointer). Связь между классом и множеством поддерживаемых им
интерфейсов достаточно произвольна. Идентификатор класса ссылается на конкретную
реализацию, и фактический набор интерфейсов для данной реализации определяется только
на стадии выполнения.
Уникальный идентификатор в COM/DCOM называется Globally Unique Identifier, GLJID
(Глобальный уникальный идентификатор) и представляет собой 128-битное целое, которое
фактически гарантированно уникально для всего мира в пространстве и времени.
В технологии COM/DCOM GUID используются для того, чтобы программно идентифицировать
классы компонентов (CLSID), интерфейсы (IID), программы (ProgID), категории компонентов
(CATID), приложения (APPID) и др.
Категории компонентов
Чтобы понять функциональность компонента, необходимо знать, какие интерфейсы этот
компонент поддерживает. Можно узнать о поддерживаемых компонентом интерфейсах, не
создавая экземпляр компонента, а используя так называемые категории компонентов,
Категория компонентов— это набор интерфейсов, которому присвоен GUID, называемый в таком
случае Category Global Identifier, CATID (Глобальный идентификатор категории компонентов).
Компоненты, реализующие все интерфейсы данной категории, могут зарегистрироваться как
члены этой категории. Клиенты могут выбирать компоненты из реестра, рассматривая только
компоненты определенной категории. Регистрируя себя в некоторой категории, компонент
гарантирует, что поддерживает все интерфейсы этой категории.
Использование категорий аналогично использованию абстрактных базовых классов. Компонент
определенной категории является конкретной реализацией этой категории.
Компонент может входить в любое число категорий, так как может поддерживать любое количество
интерфейсов.
Определение и реализация интерфейсов
Объект и клиент должны иметь заранее согласованный способ описания интерфейса, а
именно, соответствовать стандарту двоичного интерфейса СОМ. Обычно на конкретной
платформе все методы всех интерфейсов используют единое соглашение о вызове.
Несмотря на наличие двоичного стандарта, в СОМ имеется универсальный инструмент для
определения интерфейсов СОМ — Interface Definition Language, IDL (Язык описания
интерфейсов). IDL является расширением языка IDL Microsoft RPC, который, в свою очередь,
заимствован у IDL OSF DCE (Open Software Foundation Distributed Computing Environment).
Разработчик может определить новый интерфейс посредством написания файла определения
интерфейса (interface definition file). В этом файле IDL используется для описания типов данных и
методов интерфейса. Файл определения интерфейса содержит информацию, которая
описывает реальные соглашения между приложением-клиентом и серверным объектом:
o связь с языком определяет программную модель, которая применяется приложением,
использующим тот или иной язык программирования;
o двоичный интерфейс приложения определяет, как клиенты и провайдеры взаимодействуют
на определенной платформе;
o сетевой интерфейс определяет, как клиентские приложения осуществляют доступ к
удаленным объектам через границы сети.
Маршалинг
В COM/DCOM технологии существует три типа серверов: G сервер "в процессе" (in-proc):
 локальный сервер (local server);
 удаленный сервер (remote server).
Если речь идет о сервере в процессе, указатель, который имеет клиент, на самом деле
указывает на интерфейс объекта, т. к. сам объект реализован в виде DLL. Такой вызов
является достаточно эффективным. Локальный сервер — это независимый процесс,
исполняющийся на той же машине. Реализуется механизм межпроцессных коммуникаций, т.
к. клиент не может напрямую поддерживать указатель на объект в другом процессе.
В этом случае указатель, имеющийся у клиента, указывает на специальный объект —
заместитель (proxy), находящийся в процессе клиента.
Proxy (Заместитель) — это СОМ-объект, предоставляющий клиенту те же интерфейсы, что и
локальный сервер, с которым собирается работать клиент.
Если клиент вызывает некоторый метод интерфейса, сначала вызывается код заместителя
(proxy). Заместитель упаковывает параметры метода для пересылки между процессами и
передает запрос с параметрами в процесс, в котором выполняется вызываемый объект.
На стороне сервера имеется свой заместитель — заглушка (stub), назначение которого —
распаковать параметры и вызвать метод внутри объекта. Вызов метода объекта локального
сервера выполняется медленнее, чем вызов метода сервера "в процессе". Архитектура для
вызова удаленных серверов такая же, как и для вызова локальных. Только в качестве
инфраструктуры используется DCOM.
Маршалинг (Marshaling) — это упаковка параметров вызова в стандартный формат для
последующей пересылки.
Демаршалинг (Unmarshaling) — это обратная операция распаковки из стандартного формата в
форму, приемлемую для принимающего процесса. Таким образом, задачей заместителей и
заглушек является выполнение маршалинга и демаршалинга, соответственно. При этом
используется стандартный (standard) или специализированный (custom) маршалинг. При
использовании стандартного маршалинга разработчику ничего не нужно программировать.
Просто по спецификации интерфейса на языке IDL компилятор производит код зам естителя и
заглушки.
Специализированный маршалинг позволяет повысить эффективность вызовов, используя
специальные знания об объекте и клиенте. Для реализации специализированного маршалинга
разработчик должен сам реализовать объекты с интерфейсом Marshal.
Архитектура технологии DCOM
Distributed Component Object Model, DCOM (Распределенная объектная модель компонентов)
является расширением технологии СОМ на сетевой случай, Эта технология непосредственно
предназначена для реализации распределенных систем.
Механизм взаимодействия соответствует общей идее взаимодействия объектов распределенной
системы, представленной на рис. 13. Как мы уже отмечали, стаб на стороне клиента в
технологии COM/DCOM называется proxy. Для стаба на стороне сервера специальный термин
отсутствует.
Для организации взаимодействия между объектами распределенной системы применяется
объектный вариант технологий DCE и RPC.
Рис. 16 дает представление об архитектуре DCOM.
Рис. 8.16. Архитектура DCOM.
При создании объекта на сервере клиенту возвращается интерфейс этого объекта. Клиент
практически имеет доступ к DCOM-интерфейсу объекта через DCOM proxy-интерфейс, а proxyвызовы преобразуются в RPC-вызовы, которые затем передаются с помощью протокола TCP/IP.
Технология DCOM, основывающаяся на СОМ, имеет следующие сервисные средства:
- служба имен;
- поставка услуг;
- поддержка постоянных объектов;
- служба транзакций и координации доступа; - служба защиты информации; - поддержка событий и
сообщений.
Компонентная технология CORBA
Технология CORBA разработана с целью интеграции разнообразных объектных программных
систем.
Common Object Request Broker Architecture, CORBA (Архитектура универсального брокера
запросов объектов) — это технология построения распределенных объектных приложений,
описываемая набором спецификаций, разработанных группой Object Management Group
(OMG). Группа OMG объединила ведущие предприятия различных индустрии с целью
разработки стандартов, риентированных на реализацию объектно-ориентированного подхода.
В состав группы входит более 800 предприятий, в частности, такие мировые гиганты как IBM,
Hewlett-Packard, DEC. Одной из основных задач этой группы было создание стандартной
архитектуры для взаимодействия объектов в неоднородной корпоративной среде.
Общее представление об архитектуре CORBA|
Кроме набора спецификаций CORBA, группа OMG разработала Internet Inter-OMG Protocol, IIOP
- протокол, определяющий передачу сообщений между сетевыми объектами по TCP\IP,
являющийся стандартным протоколом для технологии CORBA. Использование технологий J2EE
было бы неполным без возможности интеграции с технологией CORBA. CORBA поддерживает
взаимодействие J2EE-приложений с приложениями CORBA. Кроме того, многие идеи, лежащие
в основе технологии EJB, развивались на основе концепций CORBA.
Спецификации CORBA определяют, как создавать удаленные объекты и как эти объекты должны
взаимодействовать, вне зависимости от их размещения и базовой аппаратной, операционной и
языковой платформы. CORBA не зависит также и от конкретного производителя. CORBA
позволяет объединять в единую систему программные коды, написанные на разных языках.,
Стандарты CORBA поддерживают разработку среднего уровня распределенных приложений.
Несмотря на некоторые недостатки, связанные, в основ-ном с не очень высоким
быстродействием и большим объемом документации, CORBA является общепризнанным
стандартом разработки распределенных приложений.
Используя стандартный протокол НОР, программа, основывающаяся на CORBA (созданная
любым производителем), установленная на любом компьютере и под любой операционной
системой, написанная на любом языке программирования и функционирующая в некоторой сети, может взаимодействовать с другой программой, основанной на CORBA того же или другого
производителя, написанной на том же или другом языке программирования и установленной на
другом компьютере, под другой операционной системой, в другой сети.
CORBA автоматизирует многие задачи сетевого программирования: регистрацию объектов, их
создание и активацию, маршалинг и демаршалинг, обработку ошибок, диспетчеризацию операций
и т. д.
Коммерческие продукты, реализующие CORBA, были разработаны несколькими фирмами. Между
прочим, Java Development Kit (JDK), базовый пакет инструментальных средств для
написания, тестирований и отладки Java-приложений и апплетов, — также возник на основе
программных интерфейсов CORBA API..
На рис. 17 дано общее представление о процессах, происходящих при вызове клиентом удаленного
CORBA объекта.
Рис. 17. Вызов удаленного объекта в CORBA
Из рис. 17 видно, что клиентом посылается запрос к реализации объекта.
Client (Клиент) — это сущность, которая хочет получить доступ к объекту и совершить над ним
некоторое действие.
Object implemrntation (Реализация объекта)— это программный код и данные, которые в
действительности реализуют объект.
Основным документом, содержащим описание CORBA, являются соответствующие стандарты OMG
(http://www.omg.org/corba).
Object Request Broker
Object Request Broker, ORB (Брокер запросов объектов) является ядром реализации
спецификаций CORBA, ядром архитектуры CORBA. Это — открытая инфраструктура для
распределенных объектов, разработанная группой ОМG. Технология ORB поддерживает
взаимодействие локальных и удаленных объ-ектов, реализуя механизм объектных взаимодействий,
сходный с RPC. ORB обеспечивает:
 поиск реализации удаленного объекта по запросу клиента;
 подготовку к получению и обработке запроса;
 подготовку к передаче и обработке запроса;
 передачу запроса с параметрами;
 доставку результатов запроса клиенту.
Центральная роль ORB в архитектуре CORBA видна из рис. 18.
Рис. 18. Object Request Broker
Stub (стаб, суррогат) на стороне клиента в стандартах CORBA не имеет специального названия,
серверный стаб называется skeleton {скелетон). Для реализации вызова клиент может использовать:
o Dynamic Invocation Interface — единый интерфейс динамических вызовов, зависящий от
текущего объекта;
o Stub (Стаб), реализованный с помощью языка описания интерфейсов (Interface Definition
Language, IDL);
o ORB Interface (Интерфейс ORB).
Object Implementation (Реализация объекта) получает запрос следующими способами:
 через скелетон, сгенерированный с помощью IDL;
 через динамический скелетон;
 с помощью вызова адаптера объектов (Object Adapter).
Не останавливаясь на деталях организации ORB, отметим только, что интерфейсы могут
определяться как статически на языке IDL, так и с использованием специальных сервисов ORB.
Организуя запрос, клиент получает доступ к объекту через ссылку на объект (object reference),
которая уникальным образом идентифицирует объект в сети. Экземпляр объекта имеет право на
существование в течение некоторого времени. Объекты могут активироваться, сохраняться в
долговременную память, позже вновь деактивироваться и т. д. При этом объектная ссылка будет
указывать на один и тот же конкретный экземпляр объекта.
Клиент "знает" только логическую структуру объекта, представленную его интерфейсом, и
поведение объекта. Семантику объекта представляет его реализация, которая задает данные,
необходимые для функционирования объекта, и код реализации методов объекта. Реализация
объекта может одновременно являться клиентом другого объекта, как показано на рис. 19.
Рис. 19. Связь между удаленными объектами с помощью ORB
Клиенту безразлично, как реализован объект, на каком языке написан программный код,
какая платформа используется, как реализован сам ORB и т. д.
В свою очередь, реализация объекта не зависит от того, как и кем реализован ORB, каким
образом произошел вызов объекта.
Терминология CORBA
Основные термины, используемые в CORBA, сведены в таблицу 3.
Таблица 3. Основные термины CORBA
Наименование на
английском языке
Наименование на русском
языке
Значение термина
Object
Объект
Программная CORBA-сущность, имеющая интерфейс и
реализацию (Servant)
Servant
Сервант
Реализация объекта на некотором языке
программирования (С, C++, Java и др.),
поддерживающая интерфейсы CORBA IDL
Client
Клиент
Программная сущность, которая вызывает операции
реализации объекта. Клиент фактически осуществляет
удаленный вызов методов объекта
Object Request Broker (ORB)
Брокер запросов объектов
Технология CORBA, обеспечивающая прозрачный
механизм доступа запросов клиентов к текущей
реализации объекта. ORB упрощает распределенное
программирование, освобождая клиента от
необходимости знать детали реализации объекта.
Запросы клиента, таким образом, становятся
похожими на вызовы локальных процедур. ORB
обеспечивает поиск и идентификацию реализации
объекта, активацию объекта, выполнение запроса и
доставку результатов клиенту
ORВ Interface
Интерфейс ORB
Абстрактный интерфейс ORB, скрывающий детали
реализации объекта. Этот интерфейс обеспечивает
ряд вспомогательных функций, таких, как
преобразование объектных ссылок в строки и
обратно, создание списка аргументов динамических
вызовов и т. п.
CORBA IDL stubs and
skeletons
Стабы и скелетоны CORBA
IDL
Dynamic Invocation Interface
(DII)
Интерфейс динамических
вызовов
Dynamic Skeleton Interface
(DSI)
Интерфейс динамического
скелетона
Object Adapter
Объектный адаптер
Связующие звенья между клиентским и серверным
приложениями, соответственно. Преобразования между
определениями CORBA IDL и выбранным языком
программирования осуществляются компилятором
CORBA IDL. IDL-стабы поддерживают RPC (Remote
Procedure Са11)-запросы
Интерфейс прямого доступа к основному механизму
запросов, реализуемому ORB. Приложение использует
механизм динамических вызовов без использования
специфических IDL-стабов, DII поддерживает также
односторонние (one-way) вызовы и отложенные запросы
Серверный аналог DIL Поддерживает доставку
запросов. Клиент, делающий запрос, не обязан знать,
как реализован объект: использует ли он
специфические IDL-скелетоны или динамические
скелетоны
Программное обеспечение, помогающее ORB с
доставкой запросов к объектам и с активацией объектов.
Объектные адаптеры связывают реализацию объекта с
ORB, поддерживая различные стили реализации
объектов
Object Management Architecture
CORBA включает несколько групп реализаций объектов. Object Management Architecture, ОМА
(Архитектура управления объектами), согласно спецификации OMG, классифицирует все
объекты CORBA на четыре основные категории:
 CORBA services (Сервисы CORBA);
 CORBA facilities (Средства CORBA);
 Domain CORBA facilities (Домены CORBA);
 Application Objects (Прикладные объекты).
На рис. 20 представлена классическая диаграмма ОМА.
Архитектуру, изображенную на рис. 20, иногда называют Reference Model Architecture
(Архитектура модели ссылок).
CORBA services (Сервисы CORBA) представляют внутренние службы СОRBA, не зависящие от
доменов, например, такие, как служба транзакций, служба имен, служба долговременного
хранения данных, служба событий, служба поиска объектов, служба защиты информации и
др.
Например, для объектов, рассчитанных на длительное использование, объектные ссылки могут
сохраняться с помощью службы каталогов и службы имен.
Рис. 20. Object Management Architecture
Эти сервисы, обеспечивающие основную функциональность CORBA, предназначены для поддержки
различных объектно-ориентированных платформ и создания инфраструктуры ORB.
Разработаны спецификации, предназначенные для управления жизненным циклом объектов,
обеспечения защиты информации, поддержки транзакций и т. д.
CORBA facilities (Средства CORBA) — это средства реализации объектов, которые могут быть
использованы большим числом различных приложений, например, поддержка составных
документов, потоков заданий и т. п. Средства CORBA иногда называют также Horizontal CORBA
facilities (Горизонтальные средства CORBA), чтобы подчеркнуть их отличие от доменов CORBA,
для которых существенна их вертикальная направленность. Это - средства, которые могут быть
использованы различными областями, например, реализация печати, интернационализация,
организация мобильной связи и т. д.
Domain CORBA facilities (Домены CORBA) - приложения, предназначенные для так называемых
вертикальных рынков — здравоохранения, страхования, финансового рынка, производственных
отраслей и т. д. Домены CORBA, называемые также Vertical CORBA facilities (Вертикальные
средства CORBA) - объекты, часто используемые в рамках некоторой отрасли (домена). CORBA
позволяет определить стандартные интерфейсы для стандартных объектов, доступные для
любого предприятия данной отрасли. Структура доменов была предложена организацией
Domain Technology Committee (Комитет по технологии доменов) в 1996 г., и к 2000г.
насчитывалось уже 9 доменов, соответствующих основным индустриям.
Application Objects (Объекты-приложения) — это приложения пользователя, реализующие
необходимую функциональность или бизнес-процессы. Эта категория представляет собой
приложения, реализующие функциональность, необходимую для индивидуального пользователя,
поэтому объекты данной категории не охвачены стандартизацией.
Связующим звеном между CORBA и приложениями, разработанными на основе Java, является
протокол RMI/LIOP.
Язык описания интерфейсов
OMG Interface Definition Language, OMG IDL {Язык описания интерфейсов, разработанный группой
OMG) определяет типы объектов, специфицируя их интерфейсы.
Интерфейс состоит из набора поименованных операций и параметров к этим операциям. Таким
образом, IDL предоставляет способ, с помощью которого некоторая реализация объекта дает знать
своим потенциальным клиентам, какие операции объекта доступны и как они могут быть вызваны.
Пользуясь определениями IDL, можно преобразовать объекты CORBA в коды, соответствующие
конкретным языкам программирования или объектным системам.
Тип объекта — это тип его интерфейса. Интерфейс идентифицируется именем, представленным
последовательностью символов. CORBA: -.object является базовым типом для всех объектов.
Объект поддерживает тип своего непосредственного интерфейса и, по принципу наследования,
все его базовые типы. Все интерфейсы и типы данных определяются на IDL. Различные языки
программирования поддерживаются благодаря заданным отображениям между описаниями
типов данных на IDL в соответствующие определения на конкретном языке. CORBA IDL задает
определения, которые могут отображаться в множество различных языков без каких-либо
изменений целевого языка. Эти отображения реализуются компилятором IDL. OMG IDL играет
основную роль в интеграции объектов CORBA. Механизм Dynamic Invocation Interface, DII
(Интерфейс динамических вызовов) поддерживается репозитарием интерфейсов (Interface
Repository), в котором содержатся написанные на IDL определения типов данных и
интерфейсов. Кроме организации динамических вызовов, репозитарии интерфейсов
используется для систематической организации и хранения данных приложения.
Web-сервисы
Технология Web-сервисов, появившаяся сравнительно недавно, получает все большее
распространение как новый, революционный этап в развитии электронного бизнеса. Эта
технология предоставляет новые возможности создания распределенных приложений.
Web service (Web-сервис) — это самодостаточное модульное Web-приложение, имеющее
собственное описание, которое может быть опубликовано и размещено на сервере
провайдера, а затем вызвано с помощью Web. Web-сервисы могут предоставлять
пользователю как простые функции, так и реализации достаточно сложных бизнес-процессов.
Опубликованный Web-сервис может быть вызван другим Web-сервисом или приложением.
Приложение, базирующееся на Web-сервисах, описывает использующиеся Web-сервисы и
соответствующие визуальные компоненты. Это приложение сходно с Web-приложением,
которое также использует некоторый визуальный интерфейс пользователя, поэтому
существующие Web-приложения могут быть преобразованы в Web-сервисные приложения.
Существуют специальные средства разработки Web-сервисов. Так, например, фирмой IBM
предлагаются IBM Web services development environment (Среда разработки Web-сервисов фирмы IBM),
IBM Web services toolkit (Набор инструментов разработки Web-сервисов) и пр., поддерживающие
процесс создания Web-сервисов (http://www-3.ibm.com/software/solutions/webservices/). Спецификация
Web Services Description Language, WSDL (Язык описания Web сервисов) представлена на сайте
http://www.w3.org/TR/wsdl.
Web-сервисы используют следующие основные технологии:
 протокол TCP/IP (Transmission Control Protocol/Internet Protocol) — универсальный
сетевой протокол;
 универсальный интерфейс пользователя HTML;
 универсальный язык программирования Java;
 XML (Extensible Markup Language) — универсальный язык разработки текстовых
документов, облегчающий передачу структурированных данных через Web;
 SOAP (Simple Object Access Protocol) — гибкий протокол удаленного вызова методов,
использующий XML.
Опишем очень кратко основы архитектуры Web-сервисов.
Архитектура Web-сервисов
Общее представление об архитектуре Web-сервисов дает рис. 21. Web-сервисы создаются и
размещаются на сервере приложений, а затем регистрируются (публикуются) в Web-сети с
помощью известных провайдеров (операторов) Web-сервисов, например, Microsoft или IBM.
Рис. 21. Архитектура Web-сервисов
Описание функций, доступных с помощью зарегистрированного Web-сервиса, выполняется с
использованием специального языка описаний Web Services Description Language, WSDL (Язык
описания Web-сервисов). Брокер сервисов поддерживает взаимодействие провайдеров сервисов и
пользователей сервисов. Пользователь обращается к брокеру сервисов с помощью API, получая
доступ к нужному Web-сервису. Взаимодействие с Web-сервисами поддерживается протоколом
связи, например, SOAP (Simple Object Access Protocol). SOAP — это протокол, базирующийся
на XML и поддерживающий вызов методов удаленных объектов. Основные компоненты Webсервисов представлены в табл. 4.
Таблица 4. Компоненты Web-сервисов
Наименование
Наименование
компонента на английском компонента на русском
языке
языке
Назначение компонента
Service provider
Провайдер сервиса
Доставляет сервис и обеспечивает его регистрацию и
доступ к нему пользователей
Service broker
Брокер сервиса
Осуществляет связь между провайдерами и
пользователями сервиса
Service requestor
Пользователь сервиса
Взаимодействует с брокером, для того чтобы найти
нужный сервис и вызвать его
Отметим основные преимущества Web-сервисов.
 Поддержка полной независимости от платформы и языка программирования.
Взаимодействие пользователя и провайдера происходит на основе универсальных WSDLдокументов, определяющих интерфейс и описывающих Web-сервис, и универсального
протокола Интернет.
 Возможность оперативной интеграции. Пользователи используют брокеры сервисов для
обнаружения провайдеров сервисов, поэтому поиск реализуется динамически. WSDLдокумент служит для связывания пользователя, запрашивающего сервис, с
конкретным сервисом. Таким образом, пользователь, провайдер и брокер действуют
совместно, создавая надежные, гибкие, автоконфигурируемые системы.
 Web-сервисы уменьшают сложность системы с помощью инкапсуляции. Как
пользователь, так и провайдер представляются своими интерфейсами, скрывающими
детали реализации. Пользователь не знает, каким образом и на какой платформе
провайдер реализует свой сервис, а провайдер не имеет представления о том, как
пользователь этот сервис использует. Детали реализации инкапсулируются внутри
пользовательского кода и кода провайдера.
 Эффективная поддержка защиты информации.
Для работы Web-сервисов необходима определенная инфраструктура. Провайдеры Web-сервисов
нуждаются в их описании, пользователям требуется описание того, какие сервисы они ищут,
брокерам необходим четкий механизм определения взаимодействующих пар провайдер —
пользователь.
Операции с Web-сервисами
Возможны три операции с Web-сервисами:
 Publish/Unpublish (Публикация / Удаление опубликованного сервиса);
 Find (Поиск);
 Bind (Связывание).
Публикация Web-сервиса заключается в объявлении и регистрации сервиса на сервере
провайдера. Провайдер взаимодействует с брокером для публикации сервиса или его удаления.
Операция поиска реализуется пользователем совместно с брокером: пользователь описывает,
какой именно сервис он хочет найти, а брокер на основе этого описания доставляет результаты,
которые наиболее соответствуют запросу.
Операция связывания имеет место между пользователем и провайдером. С помощью
связывания осуществляется доступ пользователя к сервису и его вызов.
Универсальное обнаружение, описание и интеграция
Web-сервисов
Universal Discovery, Description and Integration, UDDI (Универсальное обнаружение,
описание и интеграция) — это спецификация информации, необходимой для регистрации Webсервисов. Система регистрации, базирующаяся на UDDI, используется для обнаружения бизнесов
и сервисов, распределенных в Web-сети. Соответствующие структурированные данные хранятся в
общем формате XML, что облегчает их поиск и анализ.
Регистры UDDI, по сути дела, представляют собой базы данных, содержащие бизнесы и сервисы,
поддерживаемые группами компаний, называемых провайдерами или операторами. Каждый
бизнес и каждый сервис имеют свое имя и другие свойства, содержащие информацию о бизнесе
или сервисе. Бизнесы и сервисы, размещаемые на сайте оператора, группируются по категориям,
что облегчает их поиск.
Язык описания Web-сервисов
Web Services Description Language, WSDL (Язык описания Web-сервисов) — общий язык
описания Web-сервисов, используемый как при создании, так и при поиске сервисов. Каждому
Web-сервису ставится в соответствие его описание на WSDL.
WSDL-файлы осуществляют связь между Web-сервисами и их клиентами. Более того, WSDL-файл
может служить основой для генерации proxy клиентов к Web-сервисам.
Поддержка Web-сервисов в Together ControlCenter
Together ControlCenter поддерживает различные платформы Web-сервисов:
 Apache SOAP (http:// xml.apache.org/soap), для использования Apache SOAP необходимо
установить сервер приложений, например Apache Tomcat;

BEA WebLogic 6.1 (http://e-docs.bea.com/wls/docs6I),

IBM WebSphere AES 4.0 (http://www-4.ibm.com/).
Различные серверы приложений используют различные подходы к Web-сервисам. Так, например,
Apache SOAP поддерживает создание Web-сервисов из простых классов, в то время как BEA
WebLogic 6.1 ориентирован на создание Web-сервисов на основе EJB-компонентов.
Together ControlCenter автоматизирует следующие процессы:
 Создания и размещения Web-сервисов;
 Генерации соответствующих WSDL-файлов;
 Генерации клиентов к Web-сервисам на основе существующих WSDL-файлов;
 Предоставляет пользователю UDDI-браузер для регистрации (публикации) и поиска Webсервисов.
WSRP: интеграция портлетов в порталы
Консорциум по стандартам (OASIS) утвердил стандарт WSRP (Web Services for Remote
Portlets), определяющий, как порталы и Web-сервисы должны взаимодействовать друг с
другом. На примере программных продуктов IBM WebSphere Portal и Plumtree Portal
рассмотрим существующие варианты интеграции приложений в порталы, покажем,
почему возникла необходимость разработки WSRP, выясним основные положения
стандарта.
Web-cервисом , как уже говорилось выше, называется доступный в Сети программный
компонент, поддерживающий стандарты UDDI, WSDL и SOAP. Стандарт UDDI помогает
Web-сервис найти, WSDL — его охарактеризовать, а SOAP — взаимодействовать с ним. В
мире Internet масса компонентов, которые могут быть доступны: HTML-страницы,
программы, работающие по интерфейсу CGI, программы ASP/PHP/JSP, наконец,
сервлеты, однако все они не являются Web-сервисами, поскольку не поддерживают
совокупность указанных выше стандартов.
(В приведенном определении базовой характеристикой Web-сервиса является
использование им протокола SOAP. Однако существует и более широкое понимание того,
что следует понимать под Web-сервисом. В частности, альтернативу стандартному
подходу, основанному на стеке «трех протоколов», предлагает архитектура REST.)
Под корпоративным порталом будем понимать набор программных технологий, который
формирует платформу предприятия, позволяющую осуществить интеграцию
корпоративных данных на уровне процедур их обработки, представления и управления.
Следует подчеркнуть, что платформа не в состоянии осуществить интеграцию
самостоятельно: она является только средством интеграции, ее ядром. Выбор платформы
— важная задача, поскольку именно платформа является тем стержнем, вокруг которого
будут наращиваться остальные программные решения.
На базе платформы создаются промежуточные (между порталом и интегрируемым
приложением) программные модули — портлеты, которые решают задачу интеграции
приложения в портал. Портлетом называют такой программный компонент, который, вопервых, генерирует контент в форме доступной для интеграции, а во-вторых, в состоянии
взаимодействовать со сформированным им же контентом. Принципиальным отличием
такого подхода от клиент-серверной архитектуры является наличие промежуточного звена
— встраиваемого, например, в портал, контента портлета. Именно с этим промежуточным
звеном общается пользователь портала, и именно от этого звена портлет должен уметь
принимать и обрабатывать запросы. Сформированный портлетом контент может быть
подвергнут дополнительной обработке средой, в которую осуществляется интеграция,
причем различные среды (порталы) сделают это по-разному. Поэтому в общем случае
портлет может не иметь полного представления о характеристиках сформированного им
контента, однако это не должно препятствовать взаимодействию с ним.
Существует формальное деление портлетов на две группы — локальные и удаленные.
Портлет называют локальным, если он выполняется в среде портала. Для программного
обеспечения IBM WebSphere Portal такой средой является сервер приложений IBM
WebSphere Application Server. Среда выполнения портлета Plumtree зависит от версии
портала и операционной системы. В обоих случаях локальный портлет обладает
возможностью полного доступа к встроенным объектам портала через его API. В случае
IBM WebSphere Portal локальный портлет получает также доступ к возможностям сервера
приложений IBM.
В определении удаленного портлета могут встречаться различия. В частности, IBM
WebSphere Portal считает портлет удаленным, если он выполняется на удаленном сервере
и оформлен как Web-сервис. В Plumtree Portal портлет может быть удаленным, даже если
он физически размещен на машине, на которой работает портал. Размещенный же на
другом сервере, удаленный портлет Plumtree не обязан быть оформлен как Web-сервис.
Стандарт WSRP вводит новое понятие. WSRP-сервис — это презентационноориентированный Web-сервис, который может быть использован любым
заинтересованным в нем клиентским приложением. Для этого WSRP-сервис имеет
специальные «презентационные» интерфейсы, которые и специфицируются в стандарте
WSRP. Остановимся на основных положениях стандарта подробнее.
Варианты «классической» интеграции
Прежде чем рассматривать подход, который вводит WSRP для интеграции приложений,
остановимся на мотивах, способствовавших появлению стандарта. Для этого
продемонстрируем используемые сегодня варианты интеграции приложений в порталы.
На рис. 22 показана общая схема интеграции удаленного приложения посредством
локального портлета.
Рис. 22. Интеграция удаленного приложения посредством локального портлета
В такой интеграции участвуют четыре компонента: приложение, адаптер приложения на
стороне портала, портлет и сам портал в качестве модуля агрегации данных. Приложение
выступает поставщиком информации, и в общем случае нет никаких формальных
ограничений относительно того, как эти данные должны быть представлены и переданы
от источника к потребителю. Поэтому приложение должно иметь своего «представителя»
на стороне портала — адаптер приложения, который берет на себя все тонкости общения с
приложением. В качестве базового протокола используется TCP/IP, а протокол верхнего
уровня может быть любым: DCOM, RMI или собственный протокол приложения.
Непосредственно с адаптером общается портлет, который через интерфейсы адаптера
получает данные, обрабатывает их на уровне логики задачи, формирует
«презентационные» данные и направляет результат порталу. Портал объединяет
результаты, полученные от разных портлетов, и отсылает их клиенту. В рассмотренном
варианте портлет отвечает как за логику задачи, так и за способ представления
результатов. Оба рассматриваемых нами варианта портального программного
обеспечения поддерживают такую схему интеграции.
Рис. 23. Интеграция удаленного приложения посредством удаленного портлета
Рассмотрим теперь интеграцию приложения посредством удаленного портлета. Основной
идеей такого подхода является вынос функций портлета на удаленный сервер. На рис. 23
показана общая схема интеграции удаленного приложения посредством удаленного
портлета. На схеме преведено два варианта интеграции:


удаленный портлет как Web-сервис;
удаленный портлет как удаленная программа.
В первом случае на стороне портала присутствует модуль (портлет 1), который общается с
Web-сервисом, получает от него обработанные на уровне логики данные, формирует
«презентационный» уровень и отсылает его порталу. Во втором случае, как и в случае
локального портлета, сам портлет содержит как логику задачи, так и способ
представления результатов. Достигается это за счет адаптера портала, который
обеспечивает доступ к пользовательским установкам портлета, хранящимся в базе данных
портала, и прием текущих данных от пользователя (стандартным образом, по протоколу
HTTP). Портлет может также формировать результат в формате HTML или XML.
Первый вариант интеграции, через Web-сервис, возможен как для IBM WebSphere Portal,
так и для Plumtree Portal. Вариант интеграции через удаленную программу предусмотрен в
Plumtree Portal.
Рассмотрим теперь конкретный пример интеграции систем документооборота
Documentum и Open Text LiveLink. Покажем, какие средства интеграции предоставляют
нам системы документооборота, и как ими воспользоваться в порталах.
В случае с Documentum в качестве адаптера источника данных выступает библиотека DFC
(Documentum Foundation Class Library), которая инкапсулирует в себе все тонкости
общения с сервером Documentum. Интерфейсы DFC могут напрямую вызываться из Java,
либо из скриптовых языков (например, ASP) посредством COM. Это означает, что
Documentum имеет широкие возможности интеграции и не накладывает существенных
ограничений на язык программирования, на котором создается портлет.
При интеграции в IBM WebSphere Portal, если портлет локальный, портал выдвигает
требования к языку программирования портлета. В данном случае это Java, который
удачно сочетается с возможностью прямой работы с интерфейсами DFC. Если портлет
удаленный, единственным требованием выступает оформление портлета в виде Webсервиса. Как Web-сервис будет общаться с Documentum, и на каком языке он написан,
порталу не важно.
В Plumtree Portal имеется дополнительный вариант интеграции, через удаленную
программу. Этот вариант особенно удобен, если приложение предоставляет возможность
вызова своих интерфейсов из скриптовых языков, поскольку в этом случае приложение
легко интегрируется в портал за счет промежуточного удаленного модуля, генерирующего
обычный HTML.
Похожим образом проходит интеграция системы документооборота OpenText LiveLink. В
качестве адаптера источника данных здесь выступает LAPI (Livelink Application
Programming Interface). Доступ к LAPI возможен на языках программирования C++, Java,
Visual Basic, а также через Microsoft .NET (в этом случае могут использоваться C#,
Managed С++ и VB). Однако в отличие от Documentum, здесь невозможен доступ
посредством COM, что делает невозможной интеграцию через скриптовые языки.
Итак, рассмотрены «классические» варианты интеграции приложений в портальные
системы. Какие можно сделать выводы? Во-первых, такая интеграция требует
обязательного написания портлета, который будет общаться с адаптером приложения. Вовторых, адаптер приложения требуется установить на портал или удаленный сервер, а в
некоторых случаях разработать его. В-третьих, если имеется N приложений, то в общем
случае эти действия требуется повторить N раз. И самое главное, все вышеперечисленное
возможно, только если это позволяют как портальная платформа, так и само приложение.
Таким образом, мотивов для появления нового стандарта было предостаточно.
Интеграция по WSRP
Разработка стандарта WSRP была инициирована группой компаний, входящих в
консорциум по стандартам OASIS. Консорциум, созданный в 1993 году, первоначально
имел довольно узкую цель по выработке общих правил работы с языком разметки SGML
и поэтому получил соответствующее наименование — SGML Open. В 1998 году спектр
стоящих перед ним задач был расширен; появился OASIS.
Непосредственно разработкой стандарта WSRP занимались специалисты, входящие в две
технические подгруппы OASIS — WSIA (Web-сервисы для интерактивных приложений) и
WSRP (Web-сервисы для удаленных портлетов). Работа началась весной 2002 года и
продолжается по настоящее время. Следующей задачей за утверждением первой версии
стандарта является разработка версии 1.1, выход которой планируется весной 2004 года.
Наиболее интересным новшеством версии 1.1 станет включение в WSRP правил по работе
со специализированными языками разметки VoiceXML и WML.
Целью стандартизации WSRP является не только устранение указанных в предыдущем
разделе проблем, но и расширение функциональности, например, за счет возможностей
автоматического подключения удаленных портлетов, отвечающих стандарту. Достичь
этого можно, если, во-первых, формализовать способ взаимодействия между порталом и
приложением, а во-вторых, унифицировать технологию представления результатов, введя
для всех WSRP-сервисов одинаковые «презентационные» интерфейсы, позволяющие
любому WSRP-совместимому порталу использовать их.
Первая задача решалась соглашением о том, что WSRP-сервисы являются Web-cервисами,
следовательно, в основе работы с ними лежит стек протоколов UDDI, WSDL и SOAP.
Вторая задача решалась разработкой и согласованием «презентационных» WSRPинтерфейсов. Интеграция по стандарту WSRP показана на рис. 24.
Рис. 24. Интеграция по стандарту WSRP
В свое время технология COM позволила создавать внешние интерфейсы для
приложений, содержащих объектно-ориентированные структуры выходных данных
произвольной сложности. Похожим образом новый стандарт определяет структуры
данных и интерфейсы, позволяющие удаленным приложениям предоставлять свои данные
универсальным способом, через WSRP-сервисы. Например, для получения данных от
сервиса необходимо использовать интерфейс getMarkup(). Один из параметров этого
интерфейса позволяет передать информацию о том, в каком виде пользователь (в нашем
случае портал) желает видеть возвращаемые сервисом данные. По спецификации сервис
может вернуть данные в любом из имеющихся типов данных MIME. Можно даже
определить массив, который в приоритетном порядке будет содержать желательные для
возврата типы данных.
Если сервис не поддерживает, скажем, графический интерфейс, то данные могут быть
возвращены в виде HTML-таблицы или в формате XML. Кроме того, первая версия
стандарта закладывает основы его дальнейшего развития, рассматривая более сложные
ситуации: реакция WSRP-сервисов на действия пользователей, сохранение
промежуточных состояний сервиса, обработка ошибок, передача данных в двоичном виде,
шифрование и др. В частности, интерактивная работа подразумевает сохранение текущих
пользовательских установок; следовательно, необходимо контролировать состояние
текущего сеанса для данного WSRP-сервиса. WSRP-сервисы могут иметь и
конфигурационные установки. Стандарт указывает способ сохранения и получения таких
установок через представителя WSRP-сервиса на портале, т.е. WSRP-портлета.
Жизненный цикл WSRP-сервиса, технология публикации сервиса, вопросы кэширования
— все это рассматривается в спецификации.
Привлекательность WSRP-интеграции заключается еще и в том, что WSRP-совместимый
портал имеет встроенный модуль, который берет на себя функции поиска и встраивания
WSRP-сервисов. Результатом его работы является автоматически сгенерированный
представитель WSRP-сервиса на портале — WSRP-портлет (Portlet proxy). Таким образом,
интеграция приложений через WSRP-сервисы осуществляется административными
средствами портала, никаких дополнительных усилий по разработке промежуточных
модулей теперь не требуется.
Развитие этого сектора рынка настолько стремительно, что еще до окончательного
утверждения стандарта некоторые компании производители портальных решений заявили
о включении в свои продукты модулей, расширяющих их портальные платформы
поддержкой WSRP. Так, IBM WebSphere Portal 5.0 поддерживает WSRP с начала 2003
года, а компания Plumtree сообщила о разработке соответствующего модуля, Plumtree
WSRP Portlet Consumer, сразу после утверждения стандарта. В отличие от других
портальных решений и в соответствии с общей архитектурой платформы Plumtree, WSRPмодуль может быть установлен и работать не только в среде портала, но и на удаленном
сервере, выступая промежуточным звеном между порталом и WSRP сервисом. Такое
решение обладает масштабируемостью и гибкостью, поскольку освобождает портал от
дополнительной нагрузки, а также увеличивает общую надежность работы портала за счет
уменьшения риска от подключения нового сервиса.
Одним из самых последних по времени усилий, предпринятых компаниями,
заинтересованными в продвижении стандарта WSRP, является организация в Internet
сайта POST (Portlet Open Source Trading — portlet-opensrc.sourceforge.net). Данный сайт,
организованный усилиями компаний Plumtree, Documentum, BEA Systems и Sun
Microsystems, предназначен для обмена опытом между разработчиками WSRP-портлетов
и позволяет потенциальным потребителям WSRP-сервисов получить к ним свободный
доступ.
Мы рассмотрели схемы интеграции, которые применяются сегодня при встраивании
внешних приложений в порталы, показали усилия, необходимые для осуществления
интеграции по «классическим» схемам, продемонстрировали основные идеи, лежащие в
основе WSRP-стандарта. Еще раз подчеркнем ключевое достоинство WSRP-сервисов —
они доступны для автоматического подключения к любому WSRP-совместимому порталу.
Разработчик WSRP-сервиса или WSRP-портлета может не беспокоиться о портальной
платформе потенциального клиента, поскольку такой сервис будет доступен любому
порталу.
При реализации сложных проектов, где функции портлета не ограничиваются
презентационной логикой, альтернатив «классической» интеграции пока нет. Тем не
менее, первую версию стандарта можно считать важным шагом вперед, поскольку он уже
сегодня предоставляет целому классу задач новые возможности, а в будущем позволит
реализовывать сложные интеграционные задачи, оформляя их как сервисы, способные
интегрироваться в любой портал.