[Выбор редактора: IBM Workplace - это синоним Lotus Workplace. В данной статье мы ссылаемся на IBM Workplace (либо просто Workplace), но на Workplace Products API Toolkit 1.0 мы ссылаемся как на Lotus Workplace Products API Toolkit. Другие продукты, известные прежде как семейство Lotus Workplace, например, Lotus Workplace Team Collaboration, упоминаются как Workplace: Workplace Team Collaboration, Workplace Messaging и т.д.]
После ознакомления с общей архитектурой сервера и некоторыми ключевыми концепциями разработки приложений в первой части этой серии статей мы более детально рассмотрим общую модель программирования для IBM Workplace и особенно то, что требуется для реализации новых специализированных компонентов и для интеграции их с инфраструктурой приложений IBM Workplace.
Lotus Workplace Products API Toolkit предоставляет набор средств разработки, а также документацию и примеры. Вы можете загрузить этот набор инструментальных программ со страницы Lotus Workplace Products API Toolkit. В этой статье мы представим различные API и SPI, составляющие данный набор инструментальных программ. Перед погружением в Collaborative Application Component Interfaces мы повторно рассмотрим рекомендованную архитектуру бизнес-компонентов, которая кратко была представлена в первой части. И, в завершение, мы опишем требуемые шаги для использования новых специализированных компонентов в Workplace-шаблонах и приложениях.
Lotus Workplace Products API Toolkit дополняет другие средства разработки J2EE (WebSphere и WebSphere Portal), которые не описаны в данной статье. Читатель должен быть знаком с основами разработки J2EE-приложений (особенно EJB-компонентов), а также с разработкой портлетов для WebSphere Portal.
Lotus Workplace Products API Toolkit 1.0
Успех такой инфраструктуры взаимодействия приложений как IBM Workplace сильно зависит от способности разработчиков, пользователей, бизнес-партнеров, ISV и поставщиков решений создавать новые приложения, расширять существующие приложения под свои требования и интегрировать приложения с другими системами. Чтобы выполнить эти требования, Lotus предоставляет Lotus Workplace Products API Toolkit 1.0 для семейства продуктов IBM Workplace 2.0. Этот набор инструментальных программ представляет собой коллекцию нескольких интерфейсов прикладного программирования (application programming interfaces - API) и интерфейсов предоставления служб (service provider interfaces - SPI), которые вы можете использовать для расширения или интеграции функциональности IBM Workplace.
Workplace Mail Messaging SPI
Workplace Mail Messaging SPI предоставляет расширения почтовой службы IBM Workplace Messaging. Эти расширения почтовой службы принимают форму Java-классов, соответствующих одному из двух интерфейсов, называемых обработчиками (handlers) и поставщиками (deliverers). Обычными примерами применениями SPI являются антивирусы для почты, средства защиты от спама и др.
Расширение handler может исследовать конверт и содержимое любого сообщения, проходящего через почтовую службу. Handler может изменить содержимое сообщения путем добавления или удаления данных. Handler может также отклонить почтовое сообщение, т.е., оно не будет доставлено. Расширение deliverer может изменить папку, в которую доставляется сообщение.
Все расширения handler и deliverer становятся известными для сервера Workplace Messaging вследствие добавления записей в файл Workplace Messaging workplace.properties.
Workplace Instant Messaging SPI
Workplace Instant Messaging SPI используется для создания обработчиков мгновенных сообщений в IBM Workplace 2.0 или 2.0.1. Наиболее традиционным использованием этого SPI является регистрация интерактивных переговоров (chat logging), но вы можете использовать его и для выполнения других задач, например, для преобразования сообщений.
Workplace Instant Messaging SPI является частью служб присутствия и мгновенного обмена сообщениями IBM Workplace 2.0. Этот SPI доступен через сервлеты, установленные на WebSphere Portal, одном из трех серверов, являющихся частью IBM Workplace 2.0. Основными интерфейсами SPI являются:
- MessagingListener для получения событий для каждого сообщения, проходящего через сервер системы мгновенного обмена сообщениями.
- MessagingService для управления всеми экземплярами MessagingListener.
- Contact, который представляет SIP-соединение (Session Initiation Protocol) для проверки того, кому посылаются сообщения.
Теги Workplace JSP
Кроме интерфейсов API и SPI для серверной интеграции набор инструментальных программ предоставляет два JSP-тега, позволяющих усовершенствовать пользовательские портлеты, созданные для сервера IBM Workplace, дополнительными функциональными возможностями совместной работы.
Тег Person
Тег Person применяется при использовании функции информированности о человеке (people awareness) в ваших приложениях. Тег Person предоставляет функциональность контекстно-зависимого взаимодействия с указанным человеком. Вы можете использовать этот тег для генерирования меню ссылок взаимных действий, например, передачи почтового сообщения человеку. Тег Person генерирует HTML и требует разрешения работы Java и JavaScript на клиентском рабочем месте. Тег IBM Workplace Person является расширением существующего WebSphere Portal PersonTag.
Тег Online Center
Тег Online Center требуется для предоставления функции информированности о присутствии. Она уже встроена в верхнюю часть страницы в теме IBM Workplace, но если вы создаете портлет во всплывающем окне, вам понадобится этот тег для добавления на страницу информированности о присутствии. Тег Person не обеспечивает информированность во всплывающем окне до тех пор, пока этот тег не будет использоваться на этой же странице. В Online Center пользователь может изменить свое состояние интерактивности (online status), а также открыть всплывающее окно Customize Status для изменения сообщения о состоянии, которое остальные видят в меню тега Person и в тексте плавающей подсказки.
Collaborative Application Component Interfaces
В контексте данной статьи Collaborative Application Component Interfaces (CACI) являются самыми важными частями Lotus Workplace Products API Toolkit 1.0. Эти интерфейсы позволяют разработчикам реализовать бизнес-компоненты, которые полностью интегрированы с инфраструктурой Workplace-шаблонов и приложений, представленных в первой части этой серии статей.
IBM Workplace требует от разработчиков компонентов реализации CACI в виде сессионных EJB-компонентов для разрешения управления в инфраструктуре приложений определенными аспектами системы времени исполнения компонентов. Каждый аспект инкапсулирован в отдельном интерфейсе: Lifecycle, Membership, Templatable, Sensor и Transactional. Компонент может выбирать, какой из этих аспектов он должен реализовать для выполнения своих бизнес-требований, но для использования Membership, Templatable и Sensor вы должны реализовать, по крайней мере, интерфейс Lifecycle.
В будущем Workplace Products API Toolkit 2.5 добавит API служб компонентов, для того чтобы позволить использовать службы из существующих компонентов IBM Workplace, таких как discussion, messaging, calendar и т.д. Более того, версия 2.5 набора инструментальных средств будет предоставлять API для взаимодействия со службой инфраструктуры приложений и позволять программно активизировать приложения, а также управлять экземплярами шаблонов и приложений. И, наконец, в версии 2.5 впервые появятся интерфейсы IBM Workplace Client API, которые предоставят службы инфраструктуры, а также подмножество служб компонентов для клиентской платформы IBM Workplace Client Technology rich client edition.
После рассмотрения различных API и SPI Lotus Workplace API Toolkit давайте снова сфокусируемся на том, что необходимо для реализации специализированных прикладных компонентов для сервера IBM Workplace. Как мы утверждали ранее, ключом интегрирования компонента в инфраструктуру Workplace-приложения является реализация CACI. Но перед более детальным рассмотрением каждого из этих интерфейсов мы должны вспомнить и повторно рассмотреть архитектурный шаблон бизнес-компонента и его преимущества для провайдеров компонентов.
Рекомендованная архитектура бизнес-компонента
Такие проблемы как возможность удаленной работы и масштабируемость, а также обслуживаемость, скорость и гибкость адаптации к изменяющимся бизнес-потребностям - это нефункциональные требования, которые каждый из нас пытается решить в той или иной степени при проектировании программной системы. Одним из способов решения этих проблем является компонентная разработка, которая является ключевой концепцией архитектуры Workplace.
Рекомендованная архитектура бизнес-компонента Workplace описывает шаблон для организации, структуру и поведение Workplace-компонентов. Она четко разделяет сферы ответственности внутри компонента на различные уровни. Мы поближе рассмотрим каждый из этих уровней в контексте примера компонента noteboard (доска объявлений) и объясним, какие артефакты делают явным каждый конкретный уровень в бизнес-компоненте. Компонент noteboard позволяет приложениям иметь свои собственные доски сообщений с размещенными на них зависящими от приложения сообщениями. В третьей части данной серии статей мы реализуем части этого компонента на основе примера набора программ. Хотя реализация в третьей части для упрощения не затрагивает некоторые аспекты, например, персистенцию, сейчас мы будем подразумевать полнофункциональную реализацию.
Рисунок 1. Четырехуровневая архитектура компонента noteboard 
Давайте начнем с уровня Resource (ресурсов). Для того чтобы сохранить экземпляры noteboard и размещенные на них сообщения, приложению нужна система персистенции. Сейчас мы предполагаем, что для компонента noteboard была выбрана реляционная база данных. Уровень Resource определяет систему персистенции, используемую компонентом. Для нашего примера ею могли быть SQL-шаблоны и JDBC для управления данными в реляционных базах данных. Более того, частью уровня Resource являются схема для базы данных noteboard, определения таблиц и т.д. Схема и база данных недоступны извне компонента; только уровень Service самого бизнес-компонента взаимодействует с уровнем Resource. Использование источников данных позволяет нам использовать либо локальную, либо удаленную базу данных, в зависимости от требований масштабируемости компонента.
Уровень Service (служб) реализует бизнес-логику компонента noteboard и обращается к уровню Resource для извлечения данных или их изменения. Такие методы как, например, updateNotice() или deleteNotice(), являются частью интерфейса служб, реализованного на уровне Service. Уровень Service также осуществляет контроль доступа и другие требования бизнес-логики. Для возможности удаленной работы и, следовательно, дополнительной масштабируемости и поддержки управляемых контейнером транзакций, уровень Service в компонентах Workplace реализуется в виде не сохраняющих состояния сессионных EJB-компонентов (stateless session EJB). В EJB-реализации компоненты должны отображать как локальные, так и удаленные связывания для использования при необходимости преимуществ либо локального, либо удаленного доступа.
В трехуровневой архитектуре уровень User (пользователя) должен непосредственно взаимодействовать с уровнем Service. Но у такой реализации есть недостаток - детали протокола и транспортировки при взаимодействии со службой отображаются на UI-код. Тот факт, что уровень Service реализован как не сохраняющий состояния сессионный EJB-компонент или Web-служба, совершенно не должен иметь отношения к реализации пользовательского интерфейса. Для сокрытия этих деталей транспортировки и протокола в IBM Workplace был определен уровень Workspace (рабочего пространства) для использования шаблона Business Delegate в комбинации с шаблоном Service Locator. В то время как вызов к уровню Service может быть либо удаленным вызовом к развернутым удаленно EJB-компоненту или Web-службе, либо локальным вызовом к локальному EJB-компоненту, код пользовательского интерфейса всегда взаимодействует с локальным прокси, только с Business Delegate. Delegate может либо отображать аналогичные интерфейсы служб, либо предоставлять дополнительную функциональность, например, кэширование или упрощение интерфейсов, но главное здесь то, что он не отображает каких-либо особенностей протокола, например, RemoteExceptions или обычных исключительных ситуаций EJB. Для организации слабого связывания пользовательского интерфейса и уровня Service, Business Delegate должен воспользоваться шаблоном Service Locator для поиска реализации уровня Service. При этом изменения в топологии развертывания не требуют каких-либо изменений кода, а только перенастройки Service Locator. Lotus Workplace Products API Toolkit не предоставляет открытой реализации Service Locator.
Наконец, уровень User отвечает за реализацию пользовательского интерфейса в соответствии с клиентской стратегией компонента. Компонент noteboard предоставляет пользовательский интерфейс, основанный на WebSphere Portal, через портлет Noteboard. Портлет позволяет пользователям просматривать списки сообщений на доске, а также создавать новые, либо удалять существующие. Он использует тег Person для демонстрации того, насколько легко приложения могут быть усовершенствованы функциональными возможностями совместной работы, предоставляемыми IBM Workplace.
Альтернативной реализацией уровня User мог бы быть клиентский Workplace-вид (view), но для нашего примера мы выбрали основанную на портлете реализацию. Для использования бизнес-компонента как взаимодействующего прикладного компонента внутри инфраструктуры Workplace-приложения 2.0.1 необходима реализация основанного на порталах уровня User.
Теперь, когда мы знаем, как организовать и структурировать наш компонент noteboard, как мы можем сделать его взаимодействующим компонентом, который может быть использован повторно в Workplace-шаблонах и приложениях?
От бизнес-компонента к взаимодействующему прикладному компоненту
На основе рекомендованной архитектуры бизнес-компонентов мы уже могли бы создать компонент noteboard, который позволял бы нам создать одну доску объявлений для использования всеми Workplace-пользователями на сервере. Но вместо одной глобальной доски объявлений мы предоставим рабочим группам отдельные доски объявлений в каждом из Workplace-приложений, в которых они работают. Фактически, мы хотим добавить компонент noteboard к любому Workplace-шаблону или приложению; noteboard всегда должен показывать сообщения, размещенные только для этого конкретного экземпляра приложения. Мы хотели бы также использовать информацию о членах групп пользователей экземпляров приложения для определения того, кто может удалять сообщения из существующего экземпляра noteboard.
Как мы можем сделать компонент noteboard взаимодействующим прикладным компонентом? Чего не хватает в нашем бизнес-компоненте для продвижения его на этот уровень интеграции?
Из обзора набора инструментальных программ мы уже знаем одну часть ответа на этот вопрос. Мы должны реализовать интерфейсы CACI в не сохраняющем состояния сессионном EJB-компоненте.
Рисунок 2. Взаимодействующий прикладной компонент
Интерфейсы CACI, определенные открытым API, немного отличаются от соответствующих интерфейсов, используемых внутри инфраструктуры приложения. Они требуют от разработчиков компонентов использования CollabComponentAdapterEJB, который предоставляется как часть примера набора инструментальных программ. CollabComponentAdapterEJB реализует внутренние интерфейсы, которые ожидает инфраструктура приложения и вызывает локальный не сохраняющий состояния сессионный компонент, который мы здесь назвали CollabCompEJB, реализующий открытые CACI. Реализуя открытые интерфейсы в CollabCompEJB, инфраструктура приложения может уведомлять компонент noteboard в любое время, когда возникает важное событие, на которое компонент должен среагировать. Оба компонента (Noteboard Service EJB и CollabCompEJB) используют набор классов доступа к данным, заключенным в Noteboard Resource API, для доступа или управления данными на уровне Resource.
Для вызова EJB инфраструктура приложения нуждается более чем просто в уверенности, что компонент реализует необходимые интерфейсы. Она нуждается в JNDI-имени для поиска домашнего интерфейса EJB.
В первой части данной серии статей мы представили Workplace Builder, основанное на браузере инструментальное средство, позволяющее создавать и управлять Workplace-шаблонами и приложениями. Для добавления нового компонента к шаблону или приложению Workplace Builder позволяет выбирать компоненты из Portlet Catalog. Следовательно, взаимодействующие прикладные компоненты должны реализовать свой уровень User как портлет, для того чтобы Workplace Builder добавил их к шаблону. Более того, портлет взаимодействующего компонента должен указать специальный параметр portlet в его portlet.xml под названием WP_BUSINESS_OBJECT, который должен содержать JNDI-имя компонента CollabComponentAdapterEJB в своем значении. Просматривая portlet.xml, Workplace Builder может затем добавить необходимую информацию и о портлете, и об EJB-адаптере, а также его JNDI-имя в шаблон, и, следовательно, разрешить инфраструктуре приложения уведомлять компонент через интерфейсы CACI во время исполнения.
Collaborative Application Component Interfaces
Теперь у нас есть все, что нужно для реализации Collaborative Application Component Interfaces и для интеграции нашего компонента noteboard с инфраструктурой Workplace-приложения. Давайте поближе рассмотрим каждый из этих интерфейсов, а также то, что дает реализация каждого из них.
LifecycleLocal
Интерфейс LifecycleLocal уведомляет ваш компонент при создании и уничтожении содержащего его приложения или при добавлении компонента в шаблон. Он состоит из двух методов (String createInstance(InstanceDescription description) и removeInstance(String id)), которые позволяют компоненту создавать и разрушать все ресурсы, необходимые во время работы приложения. Возвращаемый из createInstance() параметр String должен быть уникальным идентификатором этого конкретного экземпляра вашего компонента; он используется во всех других интерфейсах для идентификации экземпляра компонента, для которого предназначено соответствующее событие.
Для нашего компонента noteboard мы имеем одну доску сообщений на каждый экземпляр приложения. Следовательно, createInstance() должен создать новый набор данных (dataset) доски сообщений в нашем персистентном хранилище и возвратить уникальный идентификатор этого нового экземпляра noteboard в инфраструктуру приложения. Портлет noteboard затем мог бы вызвать Noteboard Service EJB для извлечения всех сообщений, размещенных на этом конкретном экземпляре noteboard путем указания его уникального идентификатора экземпляра.
Но подождите, откуда портлет знает об уникальном идентификаторе соответствующего экземпляра noteboard в экземпляре приложения? При создании экземпляра нового приложения происходят две вещи. Во-первых, инфраструктура приложения вызывает createInstance() всех компонентов приложения. Затем она создает страницы портала, определенные в соответствующем шаблоне, и развертывает конкретные экземпляры портлетов компонентов на этих страницах. Как часть этого шага, инфраструктура приложения сохраняет идентификатор экземпляра каждого компонента внутри PortletData в параметре под названием BcId для соответствующего конкретного экземпляра портлета. Ваш код портлета компонента может затем использовать IBM WebSphere Portal API для извлечения этого параметра из его PortletData и передать его при взаимодействии с Noteboard Service EJB.
MembershipLocal
Интерфейс MembershipLocal используется для уведомления вашего компонента о добавлении или удалении членов из ролей сообщества через методы addMembers(String id, DataObjectList members) и removeMembers(String id, DataObjectList members). Эти методы позволяют компоненту предоставлять или отменять права доступа к ресурсам, которыми управляет конкретный экземпляр компонента. Более того, он обеспечивает Workplace Builder информацией о том, какие специфичные роли компонента поддерживает ваш компонент через метод DataObjectList getRoles(String id).
Наш пример компонента noteboard определяет две роли компонента: Administrator и User. Только члены с ролью Administrator могут удалять сообщения из noteboard, а размещать сообщения могут как Administrator, так и User. Следовательно, компонент noteboard должен реализовать все три метода интерфейса MembershipLocal. Метод getRoles() реализуется для передачи информации о ролях Administrator и User в Workplace Builder. Редакторы шаблона или владельцы приложения могут затем использовать механизм отображения Role в Workplace Builder для отображения ролей noteboard в любые роли приложения, которые определяет шаблон.
Когда бы ни добавлялся или удалялся член из экземпляра приложения, содержащего noteboard, вызываются методы addMembers() или removeMembers() компонента noteboard, а затем он может добавить или отменить доступ для соответствующих членов.
TemplatableLocal
Вы можете использовать интерфейс TemplatableLocal для двух различных целей. С одной стороны, он позволяет вашему компоненту указать так называемые точки изменчивости, которые он поддерживает. Они могут использоваться в шаблоне для конфигурирования вашего компонента по-разному внутри контекста каждого конкретного шаблона. С другой стороны, интерфейс TemplatableLocal позволяет вашему компоненту сохранять произвольные данные времени исполнения в шаблоне и передавать их в метод createInstance() при создании экземпляра приложения, основанного на этом шаблоне.
Интерфейс TemplatableLocal не был реализован для примера компонента noteboard. Темнее менее, реализация этого интерфейса может повысить степень повторной используемости компонента. Это могло бы позволить вам адаптировать компонент к различным бизнес-требованиям через точки изменчивости или шаблонный контент, который может быть использован повторно в различных контекстах.
Расширенный пример noteboard мог бы позволить вам создать определенные базовые сообщения, например, принципы компании или сообщение приветствия, частью каждого нового экземпляра noteboard. Он также мог бы отобразить точки изменчивости для разрешения редакторам шаблонов изменять правила контроля доступа более гибко и определять на уровне шаблона, нужно ли ролям Administrator и/или User разрешать удалять сообщения из noteboard.
SensorLocal
Интерфейс SensorLocal применяется для получения информации о ресурсах, управляемых компонентом через метод DataObjectList getSensorValues(String id). Эта информация может быть использована для обеспечения системы квот для Workplace-приложения. В IBM Workplace 2.0 и 2.0.1 поддерживаются четыре различные значения датчиков; к ним относятся: размер дискового пространства, дата создания экземпляра, дата последнего доступа и дата последней модификации.
Сервер IBM Workplace периодически собирает эту информацию из всех существующих экземпляров компонентов и позволяет администраторам Workplace осуществлять мониторинг использования и мониторинг размера дискового пространства для приложений и компонентов.
TransactionalLocal
Интерфейс TransactionalLocal расширен интерфейсами LifecycleLocal и MembershipLocal и используется для определения того, поддерживают или нет методы LifecycleLocal и MembershipLocal вашего компонента глобальные транзакции.
Создание специализированных шаблонов и приложений
Для использования ваших новых специализированных компонентов в Workplace-приложениях после реализации интерфейсов CACI необходимо выполнить несколько дополнительных шагов. Очень подробная информация по необходимым шагам приведена в третьей части нашей серии статей и в документации по Lotus Workplace Products API Toolkit.
Вообще говоря, существуют три дополнительных шага, которые нужно сделать перед тем, как вы сможете использовать ваш новый компонент в Workplace-приложении. Если это взаимодействующий компонент приложения, созданный согласно рекомендованной архитектуре бизнес-компонентов и состоящий из нескольких J2EE-артефактов, вы должны спакетировать их корректно, так чтобы их можно было развернуть на вашем сервере IBM Workplace. В то время как портлет должен быть спакетирован отдельно в WAR-файле (Web application archive), EJB-компоненты и любые дополнительные Java-классы должны быть спакетированы в EAR-файле (enterprise application archive).
После создания обоих архивных файлов вы должны развернуть EAR-файл на сервере IBM Workplace через консоль администратора сервера Workplace, а портлет может быть установлен либо через xmlaccess, либо через портлеты WebSphere Portal Administration. Если ваш компонент использует какие-либо источники данных или другие ресурсы, они должны быть определены и сконфигурированы соответствующим образом.
После пакетирования и развертывания всех J2EE-артефактов вашего компонента вы можете добавить ваш новый компонент к общему шаблону при помощи Workplace Builder. Просто выберите портлет вашего компонента в Component Catalog и настройте отображение ролей и точки изменчивости. Это все! Вы готовы к созданию Workplace-приложений, включающих ваши собственные специализированные компоненты приложения.
Резюме
В первой и второй частях данной серии статей мы объяснили концепции и архитектуру компонентного подхода к разработке приложений для сервера IBM Workplace 2.0.1. В третьей части мы рассмотрим полный процесс расширения примера Lotus Workplace Products API Toolkit для реализации примера компонента noteboard и продемонстрируем, насколько легко можно расширить IBM Workplace и удовлетворить ваши собственные требования, используя функциональные возможности для совместной работы и компонентный подход платформы Workplace.