АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
ГЛАВА 12. ИНТЕГРАЦИЯ ДАННЫХ И ПРИЛОЖЕНИЙ 12.1. Общие принципы организации взаимодействий в ИС Значительная часть существующих приложений представляет собой распределенные приложения, причем очень часто речь идет об интеграции уже существующих подсистем в единую ИС. Типовыми проблемами, возникающими при создании распределенных ИС и, в частности КИС, являются следующие: различия между приложениями; необходимость внесение изменений в код интегрируемых приложений; ограниченная скорость передачи данных; ненадежность сетевой инфраструктуры. Отдельные приложения, входящие в состав распределенной системы, могут работать на разных платформах аппаратных и программных платформах, написаны на разных языках программирования, использовать разные форматы данных и т.д. Некоторые приложения на этане разработки не были рассчитаны на работу в составе распределенных ИС, и их интеграция требует внесение изменений в исходный код. Практически все интеграционные решения предполагают наличие каналов передачи данных устройствами. В отличие от процессов, выполняющихся в пределах одного хоста, в распределенных ИС данные передаются через маршрутизаторы, коммутаторы, общедоступные сети и спутниковые каналы связи, что может приводить к задержкам и рискам потери и искажения данных. Обычно выделяют четыре базовых механизма интеграции приложений, входящих в состав распределенной ИС [158]: разделяемые файлы; разделяемая база данных; удаленный вызов процедуры и методов; обмен сообщениями. Разделяемые файлы. Несколько приложений имеют доступ к одному и тому же файлу. Одно приложение создает файл, а другое приложение считывает его. Приложения должны согласовать имя файла, его расположение, формат, время записи/считывания, а также процедуру удаления. Это один и самых старых подходов к интеграции приложений. Основная идея данного подхода состоит в том, что файл рассматривается как универсальный механизм обмена данными. Можно выделить два альтернативных подхода: распределенные файловые системы и системы, основанные на пересылке файлов. При использовании распределенных файловых систем обмен осуществляется через общие файлы, которые включаются в состав файловых систем взаимодействующих приложений. Альтернативой рассмотренного выше варианта взаимодействия приложений состоит в том, что файлы, в которых содержится информация, определяющая взаимодействие пересылаются между хостами. По этому принципу построена, например, описанная выше система Unix-Unix Copy и ряд других систем. При использовании данного подхода одним из наиболее важных решений является выбор общего формата файлов. В ранних приложениях наиболее распространенным стандартным форматом файлов являлся простой текстовый файл. В современных интеграционных решениях обычно используется XML формата. Основным достоинством рассматриваемого подхода является простота, поскольку единственными общедоступными интерфейсами приложений являются создаваемые этими приложениями файлы. В данном случае используется слабый вариант связи между приложениями. Кроме того, данный подход характеризуется простотой реализации, которая обусловливается отсутствием необходимости в привлечении дополнительных средств или пакетов для интеграции. Вместе с тем это приводит к возрастанию нагрузки, ложащейся на плечи разработчиков интеграционного решения. Объединяемые приложения должны использовать общее соглашение об именовании и расположении файлов. Один из наиболее существенных недостатков передачи файла заключается в сложности синхронизации процессов и сложности разработки кода. Данный вариант взаимодействия может иметь смысл, если взаимодействие между приложениями носит эпизодический характер. Разделяемая БД. Основная идея данного подхода состоит в том, что данные хранятся в центральной БД, доступной для всех интегрируемых приложений. Общая БД обеспечивает согласованность хранящейся в ней информации. Синхронизация доступа к данным реализуется посредством использования, например, механизма транзакций. Самый простой способ реализации общей БД состоит в использовании реляционной СУБД с поддержкой SQL. Язык запросов SQL поддерживается практически всеми платформами для разработки приложений, что позволяет не беспокоиться о различии в форматах файлов и избавляет от необходимости изучения новых языков программирования и новых технологий. Все вопросы, связанные с интерпретацией данных, могут быть решены на этапе проектирования и реализации интеграционного решения. С возрастанием числа обращений к общей базе данных она становится узким местом, что приводит к задержкам в работе приложений. Если обращения к разделяемой БД осуществляется через локальную и особенно глобальную сеть, то это лишь усугубляет ситуацию с задержками. Подход к интеграции, основанный на использовании разделяемой базы данных предполагает использование общей логической структуры данных. Разделяемая БД представляет собой неинкапсулированную структуру. Изменения в приложении могут потребовать изменения в структуре БД, что, в свою очередь, скажется на других приложениях, поэтому организации, использующие общую БД, обычно без энтузиазма относятся к необходимости ее изменения, что затруднить внедрение новых бизнес решений. Удаленный вызов процедуры и методов. С точки зрения интеграции приложений, удаленный вызов процедуры представляет собой применение принципов инкапсуляции данных. Если приложение хочет получить доступ к данным, которые поддерживаются другим приложением, то оно обращается к требуемым данным посредством вызова функции, т.е. каждое приложение самостоятельно обеспечивает целостность своих данных и может изменять их формат, не затрагивая при этом другие приложения. Удаленный вызов процедуры и работа с удаленными объектами поддерживается множеством технологий, таких как RPC, Java RMI, CORBA, DCOM, .NET Remoting. Несмотря на внешнюю схожесть, удаленный вызов процедуры и вызов локальной функции имеют принципиальные отличия, способные оказать существенное влияние на интеграционное решение [159]. Следует отметить, что удаленный вызов процедуры характеризуется самой сильной степенью связывания приложений. Обмен сообщениями. Идея обмена сообщениями состоит в том, что реализуется асинхронный механизм взаимодействия между приложениями, который позволяет им регулярно обмениваться небольшими порциями информации. Асинхронный обмен сообщениями устраняет большинство недостатков, присущих системам, основанным на вызове удаленных процедур, поскольку для передачи сообщения не требуется одновременной доступности отправителя и получателя. Кроме того, сам факт использования асинхронного обмена данными побуждает разработчиков к созданию приложений, не требующих частого удаленного взаимодействия. В табл. 12.1 приведены сведения о достоинствах, недостатках и условиях, при которых целесообразно применение 4-х перечисленных выше подходов к интеграции приложений. Таблица 12.1. Сравнительный аназиз подходов к интеграции приложжений
Рассмотрим типы интеграционных задач. В широком смысле под термином интеграция можно понимать объединение ИС и отдельных приложений, входящих в их состав, интеграцию компаний (бизнеса) компаний или людей. В более узком смысле под интеграций можно понимать объединение отдельных приложений в ИТ-систему, объединение отдельных ИС в более крупную систему и организацию взаимодействия между отдельными ИС по принципу B2B. Интеграция приложений может принимать различные формы, прежде всего можно выделить внутреннюю и внешнюю интеграцию. Внутреннюю интеграцию обычно называют интеграцией корпоративных приложений (Enterprise Application Integration, EAI), а во втором — бизнес-бизнес интеграцией (Business-to-Business Application Integration, B2B). Исходя из последнего определения выделим четыре типовых подхода к решению задачи интеграции [160]: интеграция на уровне данных; бизнес-функций и бизнес-объектs; реализация бизнес-процессов; порталы. Конечно же, приведенный выше список ни в коем случае не претендует на звание исчерпывающей классификации задач интеграции. Тем не менее, он дает определенное представление о проектах в области интеграционных решений. Некоторые интеграционные задачи объединяют в себе сразу несколько типов интеграции. Интеграция на уровне данных. Данный подход называют также интеграцией, ориентированной на информацию (Information-Oriented Integration) [160]. Этот подход ориентирован, в первую очередь, на интеграцию данных, которые хранятся в базах данных и обычно имеет целью создание API, позволяющего программисту унифицированным образом работать с множеством БД, которые могут быть территориально разнесены и принадлежать разным производителям. В рамках данного подхода можно выделить, по крайней мере, три группы технологий: системы репликации баз данных; федеративные базы данных; использование API для доступа к стандартным ERP системам. В процессе функционирования многих ИС различным приложениям часто требуется получать доступ к одним и тем же данным. Например, такая информация, как адрес проживания клиента, может использоваться как системой гарантийного обслуживания клиентов, так и подразделениями, занимающимися рекламой. Некоторые из этих систем могут иметь собственные хранилища данных. При изменении адреса клиента каждая из подсистем должна получить копию обновленной информации. Этого можно добиться с помощью такого типа интеграции, как репликация данных. Существует множество различных способов реализации репликации данных. Функция поддержки репликаций может быть встроена в СУБД; нужные сведения можно экспортировать в файл для последующего импорта в другой системе, а также переслать внутри сообщений с помощью соответствующего промежуточного ПО. Более подробную информацию об общих принципах реализации механизмов реализации механизмов репликации можно найти, например, в [23] Федеративные БД (Federated Database System) – это системы, которые позволяют прозрачным для пользователя образом интегрировать множество автономных БД, которые могут располагаться на разных хостах сети. Федеративные БД называют также виртуальными БД. Федеративная (виртуальная) БД предоставляет пользователю единый хорошо определенный интерфейс для доступа к распределенным данным, при этом сами данные не перемещаются и не изменяются, т. е. нет препятствий для того, чтобы одна и та же автономная БД входила в состав более чем одной виртуальной БД. Использование API для доступа к стандартным ERP системам предполагает использование хорошо определенных интерфейсов для организации взаимодействия создаваемых пользовательских приложений с такими пакетными приложениями как Enterprise Resource Planning (ERP) системы, такими как SAP, Oracle, PeopleSoft. Обычно это делается посредством использования адаптеров (коннекторов). Бизнес-функции и бизнес-объекты. Во многих ИС можно выделить функциональность, которая является общими для нескольких приложениях, входящих в состав ИС. Каждую из таких функций можно вынести за пределы приложений и реализовать в виде функций совместного использования, доступных всем системам в виде сервисов (служб). Например, если организация занимается созданием ИС для систем розничной торговли, то можно создать, например, сервис GetCustomerAddress. Если организация разрабатывает несколько проектов, в которых используется данная бизнес-функция, то будет разумно сделать ее общей для нескольких проектов. Отдельные бизнес функции можно объединить с целью создания более сложной бизнес-функции, например, такую как поставить изделие на гарантийное обслуживание. Если используется СОА, то данный подход используется для создания бизнес сервисов. Если используется компонентный подход, то создаются бизнес-объекты (бизнес-компоненты). Совместно используемая бизнес-функция и репликация данных могут преследовать схожие цели. К примеру, копирование адреса проживания клиента во все требуемые системы можно заменить созданием совместно используемой бизнес-функции GetCustomerAddress. Выбор между двумя различными типами интеграции основывается на многочисленных критериях, таких как степень контроля над интегрируемыми системами (в отличие от помещения информации в БД, вызов совместно используемой функции предполагает более глубокое вмешательство в систему) и частота изменения данных (доступ к адресу проживания клиента осуществляется часто, а вот вероятность изменения последнего невысока). Бизнес-процессы. Данный подход имеет много общего с описанным выше подходом, основанным на использовании бизнес-функций. Основное отличие заключается в том, что появляется новый уровень интеграции – уровень бизнес-процессов. Бизнес процессы работают поверх уровня сервисов и используют собственный язык для описания последовательности вызова сервисов. Бизнес процессы, обеспечивающие внутреннюю интеграции, и бизнес процессы, обеспечивающий B2B интеграцию во многом различны. В бизнес процессах, ориентированных на внутреннюю интеграция обычно задействовано достаточно большое количество сервисов. Типовая задача B2B интеграции состоит в организации взаимодействия между двумя сервисами. Это может быть, например, бизнес процесс приобретения некоторого товара, при котором стороны договариваются о цене на товар и оформляют покупку. Порталы. Основная функция информационных порталов заключается в обеспечении представления информации из нескольких источников, в качестве которых могут выступать, в частности, приложения, которые участвуют в реализации некоторой функции, реализованной средствами бизнес процессов. Порталы, как правило, реализуют персофицированный доступ к информации и его вид может настраиваться пользователем. Порталы можно рассматривать как графический интерфейс бизнес процессов, в которых участвуют конкретные пользователи. 12.2. Порталы и портлеты Порталы. Порталом принято называть Web-приложение, которое предоставляет пользователю Интернета или Интранета доступ к различным сервисам. Термин portal происходит от латинского porta — ворота. Часто термин портал определяют единую точку доступа пользователя в информационное пространство, при этом предполагается, что пользователь зайдя на портал может получить доступ ко всем необходимым для него источникам информации и приложениям, поэтому порталы иногда определяют как рабочий стол (десктоп) нового поколения. В процессе работы пользователи, как правило, имеет дело с данными различных формата и происхождения и используют для их обработки различные приложения. Рабочее место, кроме того, предоставлять средства для интеграции людей и, в частности средства для коллективной работы. По своей идеи портал — это Web-сайт, который ориентирован на удовлетворение информационных потребностей определенной категории пользователей, при этом каждый пользователь может настраивать портал под свои собственные потребности и может получать доступ к порталу с помощью любого устройства, имеющего выход в Internet. Портал предоставляет пользователю доступ ко всему информационному контенту и приложениям, которые необходимы ему для решения его конкретных задач, а также рабочее пространство для коллективной работы. Типовое портальное решение обеспечивает пользователя средствами поиска, обеспечением безопасности, доступ к системам электронного обучения и корпоративного документооборота. С точки зрения пользовательского интерфейса, портал представляет собой многооконное интегрированное приложение, каждое окно представляет собой "зону", изображение в каждой зоне формируется отдельным приложением. За каждую зону отвечает отдельное приложение, однако приложения могут связываться между собой как автоматически, так и по требованию пользователя, при этом информация может синхронизироваться. Часто разработчики называют порталами многостраничные сайты. Следует отметить, что не всегда бывает просто провести границу между порталом и сайтом, однако можно выделить, по крайней мере, три существенных различия между сайтом и порталом. Во-первых, портал многофункционален. Титульная страница портала содержит все или почти все, что нужно для работы конкретного пользователя. Во-вторых, портал представляет пользователю преимущественно динамический контент, который генерируется активными программными компонентами, при этом имеется возможность синхронизации и обмена контентом между приложениями. В-третьих, портал может быть персонализирован, то есть, состав и внешний вид рабочего места зависит от роли пользователя и, кроме того, может быть изменен и настроен для удобства работы конкретного пользователя или группы пользователей. Типовой портал кроме возможности одновременной работы с несколькими приложениями обеспечивает пользователю доступ к ряду сервисов общего назначения, таких как: сервис однократной регистрации, обеспечивающий аутентификацию пользователя при работе с порталом; сервис настройки и персонализации, позволяющий настраивать внешний вид, функциональность и информационное наполнение портала для нужд конкретного пользователя с учетом его роли; сервисы доступа к приложениям (сервисы обработки); сервисы доступа к бизнес-процессам, позволяющие пользовать быть участником бизнес-процесса в соответствии с определенной ему ролью; сервисы доступа к данным, обеспечивающие подключение пользователя к источниками консолидированной информации, такими как СУБД или хранилища данных; сервис поиска информации в Интернете и интранете; сервис совместной работы, позволяющий пользователям работать в команде с целью решения общей задачи (разделяемые библиотеки документов, доски объявлений, онлайновые конференции, новостные группы); сервис публикации, позволяющие пользователю сохранять документы в хранилище контента портала; сервис подписки, который позволяет пользователя оформлять подписку, что позволяет пользователю получать уведомления об изменении или появлении новой информации, при этом правила доставки/извещения и фильтрации могут настраиваться пользователем; сервис администрирования, позволяющий управлять правами доступа пользователей, создавать и удалять пользователей. Большинство порталов представляют собой Web-порталы, работающие по принципу тонкого клиента, рабочим окном которых является окно Web-браузера. С точки зрения назначения, принято выделять три основных типа порталов: горизонтальные порталы; вертикальные порталы; корпоративные порталы. Горизонтальные или общедоступные порталы ориентированы на самую широкую аудиторию. Обычно контент таких порталов носит общий характер. Как правило, это новостная информация, рассылки, электронная почта и т.п. Горизонтальные порталы имеют много общего со средствами массовой информации и могут рассматриваться как порталы общего назначения. В качестве примеров горизонтальных порталов могут выступать такие известные порталы как Rambler, Lycos, Excite,. Yahoo!. Вертикальные порталы можно рассматривать как специализированные порталы, предназначенные для информационного обслуживания конкретных групп пользователей. В качестве примеров горизонтальных порталов могут служить B2C (Business-to-consumer) порталы, B2B (business-to-business) порталы, а также порталы типа B2E (Business-to-employees) порталы, которые обычно называют корпоративными порталами. Примерами B2C порталов могут служить порталы турфирм, предоставляющие такие услуги как заказ билетов, бронирование мест в гостиницах и т.п. B2B порталы позволяют пользователям клиентам реализовывать совместные бизнес-операции, такие как выбор поставщиков, закупку товаров, проведение и участие в аукционах и т.д. Число B2B порталов растет быстрыми темпами. B2E порталы, которые обычно называют корпоративными порталами, предназначены для сотрудников, клиентов и партнеров одного предприятия. Пользователи корпоративных порталов обычно получают доступ к сервисам и приложениям в зависимости от роли, назначенной конкретному пользователю. Основным назначением корпоративного портала является предоставление внешним и внутренним пользователям возможности персонифицированного доступа к сервисам, приложениям и корпоративным данным, объединение изолированных моделей бизнеса, интеграция различных корпоративных приложений, включая приложения бизнес-партнеров, обеспечение доступа как стационарных, так и мобильных пользователей к корпоративным ресурсам независимо от места нахождения пользователя. Следует отметить, что корпоративные порталы развиваются быстрыми темпами. Обычно принято выделять четыре поколения корпоративных порталов [161]. Корпоративные порталы первого поколения ориентированы на предоставление пользователю преимущественно статического Web-контента и Web-документов. Обычно целью разработки таких порталов является создание единой точки доступа к корпоративной информации, распределенной по разным подразделениям организации. Такие порталы, как правило, реализует следующий типовой набор функций: персонализация; системы поиска информации; управление контентом и его агрегация; наличие средств и инструментов интерации приложений. В корпоративных порталах второго поколения появляются такие черты, как наличие персонализации контента, присутствие поисковика. Эти порталы ориентированы на использование в качестве составной части КИС, и для них характерны: надежная среда реализации приложений; мощные инструменты разработки и интеграции приложений; соответствие требованиям, предъявляемым к ИС системам масштаба предприятия; поддержка интеграции с ИС партнеров; наличие поддержки мобильного доступа к ресурсам.  Рис. 12.1. Составе типовой КИС, ориентированной на использование порталов Корпоративные порталы третьего поколения ориентированы преимущественно на предоставление сервисов в отличие от порталов первого и второго поколений, которые ориентированы на предоставление контента. Отличительной чертой порталов третьего поколения является то, что в них реализуется идея сотрудничества (сollaboration). Порталы третьего поколения предоставляют возможность сотрудникам работать в виртуальном офисе и предоставляют такие возможности как чаты, e-mail, возможность групповой работы над проектами. Порталы третьего поколения – это преимущественно корпоративные порталы. Для четвёртого поколения корпоративных порталов характерны: ориентация на электронный бизнес, что подразумевает интеграцию с модифицируемыми, переносимыми в новое окружение приложениями; возможность работы не только с сервисами, но и с политиками; пользователя предоставляется возможность получать доступ к информации с помощью многих типов устройств, в частности, мобильных устройств. Современный корпоративный портал обычно представляет собой продукт или набор продуктов, который базируется на определенной инфраструктуре, в качестве которой, как минимум, выступают серверы приложений и серверы баз данных. В составе типовой КИС, ориентированной на использование порталов можно выделить три основных функциональных слоя (рис. 12.1): слой базовой инфраструктуры; слой интеграции приложений; слой интерфейсов (адаптеров). Слой базовой инфраструктуры, отвечает за предоставление таких базовые сервисов как управление пользователями, управление безопасностью, управление транзакциями др. Слой интеграции приложений обеспечивает взаимодействие портала с приложениями, такими как ERP- и CRM- системы, унаследованные приложения, СУБД и др. К интерфейсному слою принадлежат визуальные и невизуальные компоненты порталов, называемые обычно портлетами. Интерфейсный слой, включающий в себя средства управления информационным наполнением, адаптеры для обмена данными с информационными системами бизнес-партнеров, интерфейсные модули для поддержки взаимодействия с мобильными устройствами и др.  Рис. 12.2. Типовая структура портальной страницы Портлеты. Информационное наполнение порталов часто предоставляется пользователям в форме портлетов — контейнеров, которые, можно рассматривать как пользовательское представление соответствующего им персонифицированного информационного наполнения. С точки зрения реализации, портлет представляет собой фрагмент кода, исполняемый на портальном сервере. Когда говорят о портлетах, то речь ведется в терминах JEE, поскольку эта платформа поддерживает работу с портлетами, хотя порталы с успехом можно строить и на других платформах. Портлет представляет собой приложение, предоставляющее пользователю некоторую информацию или сервис. Он может быть включен в качестве составной части в портальную страницу. Портлет работает под управлением контейнера, который обрабатывает запросы и генерирует динамический контент, и представляет собой plugin, ответственный за представление информации пользователю. Динамически сгенерированный контент портлета называют фрагментом. Контент нескольких портлетов можно объединять в рамках одной портальной страницы. Типовая структура портальной страницы показана на рис. 12.2. Клиент, обычно это Web-клиент, взаимодействует с портлетом в режиме запрос-ответ. Для разных пользователей портлет может иметь разный внешний вид в зависимости от настроек. Портлеты могут реализовываться на разных платформах. При реализации на Java платформе портлет рассматривается как Web компонент. На данный момент рабочей является версия 2.0. Ниже изложение ведется применительно к данной спецификации. Клиент, обычно это Web клиент, взаимодействует с портлетом в режиме запрос-ответ. Для разных пользователей портлет может иметь разный внешний вид в зависимости от настроек. Портлеты могут реализовываться на разных платформах. При реализации на Java платформе портлет рассматривается как Web компонент. На момент написания книги рабочей является версия 2.0. Ниже изложение ведется применительно к данной спецификации. Контейнер портлетов представляет собой среду, в которой «живут» портлеты. Контейнер управляет жизненным циклом портлетов, однако не отвечает за агрегацию портлетов. Обычно портал или точнее портальный движок и контейнер могут реализовываться как один монолитный компонент или как два независимых компонента. В самом общем виде работа с портальной страницей происходит следующим образом. 1. Web клиент посылает HTTP запрос к порталу. 2. Портал получает запрос и определяет к какому из портлетов, относящихся к данной портальной странице, относится запрос. 3. Портал запускает портлет через контейнер и получает требуемый контент. 4. Портал агрегирует полученный контент в портальную страницу и отправляет ее клиенту.  Рис. 12.3. Формирование портальной страницы Следует заметить, что портлеты имеют много общего с сервлетами, в частности: как сервлеты, так и портлеты являются Web компонентами; подобно сервлетам, портлеты работают под управлением контейнера; портлеты подобно сервлетам генерируют динамический контент; клиент работает через Web интерфейс. Отличие портлетов от сервлетов состоит в следующем: портлет представляет собой только часть изображения, портальная страница формируется из фрагментов средствами портального сервера; Web клиент взаимодействуют с портлетом не напрямую, а через портальную систему; форматом отображения портлета можно управлять; на одной портальной странице один и тот же портлет может появляться несколько раз. Кроме того, портлеты по сравнению с сервлетами, обладают следующей дополнительной функциональностью: портлеты работают с конфигурационными файлами; портлеты имеют доступ к профилям пользователей; портлеты могут сохранять свое состояние; портлеты могут взаимодействовать друг с другом и контейнером посредством сообщений. Контейнер портлетов можно рассматривать как расширение Web контейнеров. Портлет генерирует фрагмент в форме гипертекста. Портал формирует окно портлета посредством добавления к сгенерированному фрагменту обрамления, включающее рамку и кнопки. Затем окна портлетов агрегируются в портальную страницу (рис. 12.3). Для формирования портлетов могут использоваться либо JSP, либо такие фреймворки как Java Server Faces (JSF), Struts, Spring [162] и др. Портлеты могут функционировать в нескольких режимах. Пользователь может работать с информационным наполнением, может настраивать внешний вид портлета в соответствии со своими предпочттениями, а администраторы могут конфигурировать портал для предоставления. Режим, который пользователи выбирают, определяет, какой интерфейс портлета они видят. Представление может находиться в одном из следующих состояний: «нормальное» (normal), «максимизированное» (maximized),. «минимизированное» (minimized), «закрытое» (closed). Свойства, существенные для размещения портлетов хранятся в дескрипторе. Сервер порталов предоставляет портлету сервис получения информационного наполнения и сервис сохранения состояния между сеансами, а также сервис доступа к пользовательской информации, которая дает портлетам доступ к информации, касающейся пользователей, в том числе предпочтения пользователя, данные о настройке и т.д. API портлетов определяет интерфейс между портлетом и контейнером портлетов. Концепция порталов создавалась постепенно в течение достаточно длительного промежутка времени. Еще за много лет до появления самого терминов «портал» и «портлет» разработчики сайтов широко использовали такие приемы как введение динамического контента, фреймы, элементы персонализации страницы, однако различные Web-серверы и серверы приложений обеспечивали эти возможности разными способами. С появлением концепции портала появилась необходимость стандартизации средств построения портальных приложений. В рамках технологии JEE в 2003 году появилась спецификации JSR-168, которая была разработана совместно фирмами IBM и Sun Microsystems, которая определяла портлеты, написанные на языке Java. В 2007 году появилась вторая версия данной спецификации под номером JSR-286 [163], которая является расширением версии 1. Обе версии совместимы на двоичном уровне и это означает, что все портлеты, созданные в соответствии со спецификацией JSR-168 могут работать в контейнере, созданном в соответствии со спецификацией JSR-286. На практике портлеты, созданные в соответствии со специцификацией JSR-168 продолжают активно использоваться. Функции для работы с портлетами определены в пакете javax.portlet. API портлетов определены таким образом, чтобы можно было провести четкую границу между портлетом и портальной инфраструктурой. Хотя API портлетов во многом похожи на API сервлетов, но имеются и отличия, в частности, для контейнер портлетов различает и позволяет поддерживать как состояние портлета, так и состояние окна. Состояние окна определяет, какую часть экранной страницы занимает данный портлет. Окно может находиться в одном из 3-х состояний: нормальном, минимизированном или максимизированном. В соответствии со спецификацией JSR-168 определяются следующие методы интерфейса Portlet: init(), processAction(), render(), destroy(). Метод init() используется для инициализации портлета. Метд processAction() вызывается для обработки действий пользователя в портлете. Метод render() вызывается при необходимости перерисовки изображения портлета. Метод destroy() вызывается перед удалением портлета из памяти. Портлет может находиться в одном из трех состояний: View (Представление); Edit (Редактирование); Help (Помощь). В состоянии «Представление» портлет реализует свою функциональность, в состоянии «Редактирование» реализуются функции, связанные с настройка портлета, а в состоянии «Помощь» отображаются подсказки. Наряду с интерфейсом Portlet, в пакете определется класс GenericPortlet, где метод render() определен таким образом, что управление в зависимости от текущего состояния портлета.передается одному из методов: doView(), doEdit() или doHelp(). Большинство реальных портлетов наследуют от класса GenericPortlet. Ключевым при работе с портлетом безусловно является метод processAction(), который работает с объектами типа запрос и ответ - объекты ActionRequest и ActionResponse соответственно. Для метода render() и вызываемых им методов doXxx() в качестве аргументов и результатов выступают объекты RenderRequest и RenderResponse. Используя эти объекты, портлет может управлять состоянием и взаимодействовать с другими портлетами, сервлетами, принимать данные, вводимые пользователем в экранные формы портлета, создавать изображение для отображения в портале и посылать его клиенту и определять состояние портлета. Запрос клиента инициируется при помощи ссылок URL, создаваемых портлетом. URL портлета могут быть двух типов: URL действия и URL перерисовки. Портлет создает свои URL, вызывая методы createActionURL и createRenderURL интерфейса RenderResponse. Эти методы возвращают интерфейс PortletURL. URL перерисовки может быть уточнен указанием состояния портлета, для которого этот URL применяется. Обычно запрос клиента, инициируемый URL действия, превращается в один запрос действия и много запросов перерисовки - по одному на каждый портлет на странице портала. Если портлет может кешироваться (это определяется в дескрипторе портлета), метод render может не вызываться. Портлет являются настраиваемыми элементами. Настройки портлета сохраняются в виде наборов пар "имя - значение". За сохранение конфигурации портлета отвечает контейнер. Программист работает с настройками посредством объекта типа PortletPreferences, который имеет методы setValue() и getValue() установки (изменения) значений настроек и чтения их значений соответственно. Портлеты упаковываются как стандартные в JEE Web-архивы (файлы WAR), которые кроме дескриптора развертывания web.xml, дополнительно содержат дескриптор портлета - portlet.xml, в котором определены элементы конфигурации портлета. Основными средствами обеспечения безопасности портлетов в рамках спецификации JSR-168 являются возможность установки в дескрипторе портлета флажка, требующего, чтобы портлет работал только через защищенный протокол HTTPS и возможности аутентификации пользователей и ролей, при этом не определяет, каким образом реализованы пользователи и их роли. Кроме того, определяется библиотека тегов JSP, которая помогает отображать портлет при помощи технологии Java Server Pages. При реализации портлетов довольно часто в методе, например, doView() выполняется логика, связанная с анализом состояния, возможно, некоторая бизнес-логика, а для отображения портлет вызывает страницу JSP, формирующую код фрагмента HTML-страницы. При вызове страницы JSP ей передаются запрос и отклик портлета. Перед вызовом страницы портлет может сохранить какие-то объекты как атрибуты запроса. Страница может направлять запрос в портлет, определяя адрес портлета через теги специальной библиотеки. За агрегацию фрагментов, поставляемых разными портлетами, в полную страницу портала отвечает контейнер портлетов. Стандартизация портлетов (как и само осознание концепции порталов) несколько задержалась. На момент создания спецификации уже существовало большое число реализаций серверов порталов, в которых использовались фирменные средства и собственные API. Спецификация JSR-168, однако, была принята производителями серверов порталов, и в настоящее время большинство продуктов этого класса проходят или уже прошли процесс адаптации к стандарту. Вместе с тем, эти продукты вынуждены поддерживать и свои старые API, так что различия в диалектах API быстро исчезнуть не могут. Следует отметить, что спецификация JSR-168 определяет только базовые средства работы с портлетами. Обычно развитые портальные серверы предлагают многочисленные не предусмотренные спецификацией дополнительные возможности, при этом у каждого из производителей имеются собственные расширения для работы с портлетами. В 2007 году в рамках Java Community Process была опубликована окончательная версия второй версии спецификации портлетов (JSR-286), которая, дополняет предудущую спецификацию, обеспечивая стандартизацию некоторых возможностей, не охваченных в JSR-168. В качестве новых элементов, появившихся в рамках спецификации JSR-268 можно выделить следующие: обеспечение механизмов обмена событиями между портлетами: портлет может объявлять события, которые он хочет генерировать, и события, которые он хочет получать; контейнер работает как диспетчер событий; поддержка работы с фильтрами, которая выражается в возможности преообазовывать «на лету» как входную, так и выходную информацию; работы с фильтрами, обеспечение возможности для портлетов совместно использовать общий сеанс (сеанс пользователя) и данные, относящиеся к общему сеансу; обеспечение поддержки работы фреймворками Java AJAX, Server Faces, Struts и др.  Рис. 12.4. Процесс создания портлета Обычно портал получает информационное наполнение для своих портлетов из многих как внутренних, так и внешних источников. Чтобы интегрировать новый источник, администратор портал должен адаптировать информационное наполнение к формату, который воспринимается порталом, что может оказаться весьма длительным и трудоемким процессом. Возможна два альтернативных подхода к решению данной задачи. Первый подход предполагает, что в каждом случае создается портлет, который обеспечивает пользовательский интерфейс для выполняемой сервисом функции: ввод параметров запроса и представление результатов. На основании полученных данных портлет получает требуемые данные, например, из БД, либо формирует SOAP-запрос к сервису и превращает отклик сервиса в графическое экранное представление. Все портлеты работают на одном портальном сервере. Подобный подход требует написания кода портлета, обеспечивающего пользовательский интерфейс, извлечение данных и развертывания портлета. Альтернативный подход заключается в том, что удаленный Web-сервис сам будет генерировать фрагмент разметки страницы, который непосредственно будет включаться в страницу нашего портала. Второй подход предполагает использование специальных посредников, использование которых, позволяет позволяют провайдерам поставлять контент без использования ручных настроек (рис. 12.4). Идея состоит в том, чтобы вместо того, чтобы добавлять сам портлет в портальный сервер, туда помещают его заместитель, который взаимодействует с удаленным портлетом. Сам удаленный портлет поддерживаются другим сервером порталов или модулем исполнения портлетов, который представляет упрощенный сервер порталов, который представляет собой среду исполнения портлетов и обеспечивает возможность удаленному портлету реагировать на вызовы посредника и может быть реализован в другой технологии, например,.Net, но должен поддерживать протокол удаленного вызова портлета. Для обеспечения совместимости между портальными серверами разных производителей и поставщиками информационного наполнения, требуется стандартизованная модель взаимодействий для посредника портлета и удаленного портлета. Подобный стандарт создан в рамках организация Organization for the Advancement of Structured Information Standards (OASIS) это Web-службы для удаленных порталов (Web services for remote portals, WSRP). Спецификация WSRP является продуктом международной организации Organization for the Advancement of Structured Information Standards (OASIS, Организация по развитию стандартизации структурированной информации), являющейся консорциумом, содействующим принятию технических стандартов. Версия 1.0 спецификации WSRP была закончена в 2003, а версия 2.0 появилась в 2008 году [164]. Спецификация WSRP определяет интерфейс для взаимодействия с подключаемыми, ориентированными на представление Web-сервисами, которые обеспечивают взаимодействиями с пользователями и выступают в качестве поставщиков фрагментов кода на языке разметки для агрегирования в портальные страницы. WSRP представляют из себя визуальные компоненты, которые можно подключать с использованием технологии визуального проектирования. В определенном смысле удаленные портлеты можно рассматривать как Web-сервис, обладающие графическим интерфейсом и для их описания может использоваться WSDL. WSRP работает следующим образом. Поставщики информационного контента реализуют свой сервис как Web-сервис удаленного портала и публикуют ее, например, в UDDI. Следует заметить, что удаленные и локальные портлеты могут работать на одном портале и для конечного пользователя они неразличимы. Работа с удаленным портлетом выглядит следующим образом. Поставщик предлагает один или несколько портлетов и реализует ряд интерфейсов WSRP, которые обеспечивают общий набор операций для конечных пользователей. WSRP-портлет представляет собой подключаемый компонент, формирующий интерфейс конечного пользователя, выполняемый внутри поставщика WSRP и доступный удаленно через интерфейс, определенный этим поставщиком. Потребитель WSRP – представляет собой клиент Web-сервиса, который вызывает предлагаемый поставщиком WSRP сервис и обеспечивает среду взаимодействия пользователя с портлетами, предлагаемыми одним или несколькими поставщиками; обычно роль потребителя WSRP играет портал. Реально Web-сервисом является не WSRP-портлет, а поставщик WSRP, именно он имеет стандартное описание на языке WSDL и набор конечных точек. Обращение к WSRP-портлету возможно только через поставщика. Поставщик принимает SOAP-запрос, выделяет из него обращение к портлету и упаковывает фрагмент разметки, генерируемый портлетом, в ответное SOAP-сообщение. В функции же потребителя WSRP входит упаковка в SOAP-запрос параметров формы, поступившей от пользователя, и выделение из SOAP-отклика фрагмента разметки, присланного поставщиком и WSRP-портлетом. В рамках спецификации WSRP определены два обязательных и два не обязательных интерфейса, которые должны реализовывать поставщики WSRP и которые должны использовать потребители WSRP для взаимодействия с удаленными портлетами. Стандартизация этих интерфейсов дает возможность потребителю WSRP обращаться к любому поставщику. Обязательными для реализации интерфейсами WSRP являются интерфейс описания сервиса (Service Description Interface) и интерфейс разметки (Markup Interface). Через Интерфейс описания сервиса потребители могут запрашивать, какие портлеты предлагает поставщик и получать информацию о самом поставщике. Интерфейс разметки (MarkupInterface) предназначен для поддержки взаимодействия поставщика с удалёнными портлетами; он позволяет , посылать им формы, полученные от пользователя портальной страницы, и получать от них информацию о текущем состоянии портлета. Не обязательным интерфейсом WSRP является интерфейс регистрации (Registration Interface), предназначен для поддержки процесса регистрации потребителя перед как тот сможет обратиться к сервису, что позволяет поставщику сервиса адаптировать свое поведение применительно к определенному типу потребителя; через этот интерфейс поставщик и потребитель могут обмениваясь сведениями о себе. Интерфейс управления портлетом (Portlet Management Interface) позволяет пользователю управлять жизненным циклом удаленного портлета и настроить его поведение. Все перечисленные выше интерфейсы WSRP представляют собой XML-протоколы и, соответственно, платформенно независимы. Следует особо отметить, что WSRP не заменяет стандарты Web-сервисов, а дополняет их и предствляет собой надстройку над ними. Все взаимодействия между потребителем и поставщиком WSRP осуществляются по протоколу SOAP, а операции интерфейсов WSRP определяются в WSDL-описании WSRP. Использование подобного подхода позволяет осуществлять публикацию WSDL-описаний WSRP-портлетов в реестрах UDDI. Типовой типичный сценарий использования WSRP на основе технологии UDDI, выглядит следующим образом. Провайдер разрабатывает набор портлетов, назначая WSRP-поставщика и отображая их как WSRP-портлеты. Если провайдер хочет сделать эти портлеты использовались как удаленные, то он публикует описания в реестре. Пользователь, заинтересованный в работе с удаленными портлетами ищет портлет нужный ему портлет, используемые предоставляемые порталом средства, либо независимое приложение. После обнаружения желаемого портлета пользователь добавляет новое приложение к одной из своих портальных страниц. Если пользователю не разрешено добавление портлетов к своей странице, то администратор портала находит их в UDDI-реестре и сделать их доступными для пользователей, добавив во внутренний реестр портала. После того как удаленный портлет помещен на портальную страницу пользователя, он увидит на своей портальной странице выполняющийся удаленно портлет, при обращении к которому портальный сервер выполняет запрос к соответствующему Web-сервису посредством отправки SOAP послания, а в ответ получает SOAP послание, содержащее фрагмент на языке разметки страниц, который портал интегрирует в отображаемую страницу. При этом конечный пользователь полностью избавлен от необходимости знать детали работы WSRP. Как у всякой технологии у технологии портлетов имеются свои достоинства, свои недостатки и области применения. Достоинства портлетов. 1. Портлеты могут работать на различных клиентских устройствах, что позволяет пользователям перемещаться с компьютера на компьютер, и с одного мобильного устройство на другое, и при этом использовать ту информацию и те приложения, которые им нужны. 2. Внешний вид и функциональность портлетов можно настраивать для различных групп пользователей, а сами пользователи могут настраивать внешний вид портлетов в соответствии со своими предпочтениями. 3. Портлеты могут быть опубликованы как Web-сервисы с целью обеспечения доступа к ним внешних пользователей. 4. Портлеты позволяют сложные приложения на отдельные задачи по принципу - одна группа тесно связанных задач представлена одним портлетом. 5. Портлеты позволяют относительно легко добавлять новую функциональность к уже существующим приложениям. 6. Портлеты подобно другим Web-приложения хорошо совместимы с брандмауэрами (firewalls). Недостатки Портлеты не могут быть решением для каждого проекта. Ниже перечислены типовые ситуации, когда не следует использовать от использования портлетов. 1. Сложные пользовательские интерфейсы плохо переводятся в портлеты, использующие языки разметки. 2. Если требуется реализовать пользовательские интерфейсы с часто обновляемыми данными, то использование портлетов может привести к замедлению работы системы, поскольку, когда обновляете один портлет, то перерисовывается вся портальная страница. 3. Высоко-интерактивные пользовательские интерфейсы не достаточно хорошо переводятся в Web-приложения вообще и в портлеты в частности. Если необходимо, чтобы интерфейс приложения изменялся в процессе работы, например, появлялись выпадающего меню, вы можете либо использовать форму и обновлять всю страницу полностью, или использовать скрипты, чтобы изменить портлет. Однако всплывающие окна и скрипты обычно не могут использоваться на мобильных устройствах. 4. Имеются проблемы при работе с формами (Внутренние фреймы разрешены, но только пользователи Microsoft Internet Explorer могут их видеть). 5. Портлеты полностью не стандартизированы, и они еще не поддерживаются на стольких платформах как другие Java-технологии. Области применения Использование портлетов безусловно целесообразно в случае, если цель проекта состоит в том, чтобы объединить Web-приложения и информацию в одном удобном месте, если требуется использовать сервисы внешних поставщиков и (или) выступать в качестве поставщика сервиса. Если пользователи активно перемещаются и пользуются мобильными устройствами, то портлеты - очевидный выбор. Если цели проекта отличаются указанных выше, то следует рассмотреть другие альтернативы. |