 | Уровень сложности: простой Джо Грант, старший инженер-программист, IBM
Крейг Уолперт, старший инженер-программист, IBM
10.02.2009 Учимся определять и оптимизировать шаблоны проектирования при разработке составных приложений.
Примечание редактора: это - третья статья из серии, посвящённой составным приложениям, которая будет публиковаться на developerWorks Lotus в течение следующих нескольких месяцев. Ознакомьтесь с предыдущими статьями: Разработка составных приложений: проектирование компонентов и Приложение Lead Manager в IBM Lotus Notes V8: краткий обзор.
Составные приложения - ключевой элемент в сервис-ориентированной архитектуре (SOA) и в стратегии контекстуального сотрудничества. Они обеспечивают гибкость коммерческой деятельности компаний и организаций, которым необходимо быстро реагировать на меняющиеся потребности основанного на жёсткой конкуренции современного рынка. Составные приложения представляют собой совокупности компонентов пользовательского интерфейса, которые связаны между собой лишь в степени, необходимой для обеспечения межкомпонентного взаимодействия.
Компоненты можно многократно использовать в различных составных приложениях. Возможность комбинирования различных технологий в одном приложении имеет большое коммерческое значение. Она позволяет компаниям обеспечивать более гибко защищать существующие активы и распространять сферу их применения, быстро и без лишних затрат реагируя на возникающие потребности бизнеса с помощью приложений, создавать которые гораздо проще, чем в большинстве сред разработки приложений.
Такая слабая связанность компонентов в архитектуре составного приложения также позволяет различным группам, находящимся в разных местах, объединять усилия и взаимодействовать друг с другом. Например, одно подразделение может заниматься разработкой программы автоматизации бухгалтерского учета компании, в то время как другая группа работает над приложением по отслеживанию рынка потенциальных покупателей (приложение управления продажами). В составном приложении можно добавить в бухгалтерское приложение некоторые компоненты из приложения управления продажами для отображения актуальных бухгалтерских данных. Точно так же приложение управления продажами может включать в себя компоненты бухгалтерского приложения для предоставления финансовой информации по имеющимся активам. По мере разработки компанией все большего числа составных приложений возможности интеграции увеличиваются. Основная идея состоит в том, что полученное в итоге целое превосходит сумму отдельно взятых его частей.
Модель составного приложения уже знакома разработчикам IBM WebSphere Portal. Этот подход был распространён и на IBM Lotus Notes V8, что позволило разработчикам оформлять свои приложения Lotus Notes в виде компонентов составного приложения. Кроме того, в IBM Lotus Domino Designer была введена поддержка брокера свойств и реализована более интуитивно-понятная среда пользователя. Lotus Notes V8 также поддерживает вставку компонентов Eclipse. В составном приложении могут присутствовать любые комбинации компонентов Lotus Notes и Eclipse. Эти компоненты могут отображаться вместе в одном пользовательском интерфейсе за счёт "прозрачной" интеграции, или, если используется брокер свойств, полностью взаимодействовать друг с другом. Для определения составных приложений можно использовать редактор составных приложений Composite Application Editor или редактор шаблонов приложений WebSphere Portal Application Template Editor.
Разработка компонентов для составных приложений отличается от традиционной разработки приложений в Eclipse или Lotus Notes. Желательно создавать компоненты достаточно гибкими, чтобы позднее их можно было использовать в приложениях без значительных доработок. В данной статье описаны подходы и оптимальные методики, которые можно использовать при проектировании таких компонентов.
Предварительные требования
Предполагается, что читатель знаком с составными приложениями в IBM Lotus Notes, поэтому, возможно, будет полезно обратиться к разделу "Введение в составные приложения" Справки по IBM Lotus Domino Designer.
Также ознакомьтесь со статьями developerWorks Lotus: Приложение Lead Manager в IBM Lotus Notes V8: краткий обзор и Разработка составных приложений: проектирование компонентов, в которых в общих чертах рассматривается разработка компонентов. В них обсуждаются доменоцентрические (ориентированные на домен) и контекстно-зависимые компоненты (компоненты контекста домена), которые сами по себе являются меташаблонами.
Шаблоны разработки
Мысль о том, что при разработке нам часто приходится решать одинаковые задачи похожими способами, получила большое распространение. Эта идея вышла рамки объектно-ориентированного программирования, где использовалась первоначально: выяснилось, что во многих средах работу эффективнее выполнять с помощью шаблонов, другими словами, для типичных проблем должны быть выработаны общие решения, имеющие широкое применение. Проектирование и разработка составных приложений не являются исключением, поэтому в данной статье будут рассмотрены шаблоны, соответствующие такому подходу.
Для систематизации материала разделим типы шаблонов на несколько категорий:
- Шаблоны для определения универсальных типов компонентов
- Шаблоны для определения групп компонентов в зависимости от их устройства и способа взаимодействия
- Шаблоны приложений или методы проектирования в целом, используемые при формировании структуры одного составного приложения или пакета составных приложений
Шаблоны компонентов
В этом разделе описываются различные универсальные типы компонентов.
Компоненты выбора
Компоненты выбора позволяют обмениваться значениями между информационными доменами. Например, в заявлении на командировку может содержаться номер сотрудника, соответствующий записи в приложении Human Resources (Управление персоналом), или данные о центре затрат, определяющие центр управления в пакете бухгалтерского учета. Приложение для подачи заявки на командировку отслеживает эти значения только для получения справочной информации и только для той части бизнес-логики, которая пересекается с соответствующими информационными доменами. На уровне пользовательского интерфейса поля для значений, не заданных информационными доменами, часто представляют собой ячейки для заполнения, и поэтому в них могут содержаться ошибки, допущенные при наборе текста.
Каждое приложение может создать несколько компонентов выбора в соответствии со своим доменом. Поскольку у приложения есть вся информация о домене, оно может предоставить пользователю все необходимые методы выбора. Это классический пример контекстно-зависимого компонента, описанного в статье developerWorks Lotus: Разработка составных приложений: проектирование компонентов. В нашем предыдущем примере приложение Human Resources может создать компонент для выбора сотрудников, который позволяет осуществлять поиск по имени, электронному адресу, телефону, месту работы и прочим полям, имеющимся в распоряжении у приложения. В результате компонент возвратит значение любого из этих полей или номер сотрудника, необходимый для заявления на командировку.
Компонент может быть представлен двумя способами:
- Он может присутствовать в пользовательском интерфейсе на краю страницы приложения, в которой происходит формирование первичной записи, или на панели дополнительных компонентов (dashboard). Поля для редактирования связываются с компонентом выбора. Если значение известно, его можно просто напечатать в редакторе; если нет, компонент выбора используется для поиска и выбора нужного значения, после чего оно появляется в редактируемой строке.
- Компонент может быть невидимым и иметь минимальный пользовательский интерфейс. Помимо свойств и операций, которые получают и передают значение, указанное в запросе, также существует еще одно значение, сообщающее о том, что надо отображать интерфейс данного компонента. Это всплывающее диалоговое окно содержит те же возможности поиска, что и при визуальном отображении компонента. И хотя на исходном компоненте потребуется дополнительная кнопка Lookup, (что делает его чуть менее "свободно связанным"), он использует пользовательский интерфейс более эффективно. Поисковая панель появляется только при необходимости.
Информационный компонент
Данная разновидность компонентов предоставляет более подробную информацию об отдельной записи. Это может быть полное детализированное представление, показывающее каждый элемент данных в записи, либо краткая справка, содержащая только основную информацию. Также можно задавать определенный набор данных записи. В примере приложения Lead Manager, доступном на developerWorks Lotus, есть информационные компоненты для Companies (компаний) и Leads (лидов). Для каждого существует компонент Detail (Подробности), , содержащий первоначальную полную форму Lotus Notes, и компонент Summary, в котором содержится только основная информация.
Как и в случае с компонентом выбора, можно сделать так, чтобы информационный компонент имел минимальное отображение на экране. При активации, программным путем или через пользовательский интерфейс, может создаваться всплывающее диалоговое окно с содержащейся в нём информацией. Это позволяет сохранить свободное пространство видимой части экрана без потери функциональности. Такие всплывающие окна часто используются в примере Lead Manager.
Компонент запуска
Компонент запуска - это еще один тип контекстно-зависимого компонента. Он не дополняет информацией содержащее его приложение, а добавляет ему функциональности. Компонент может быть настроен на получение элементов данных из контекста содержащего его приложения и отображение вариантов обработки этой информации с помощью процессов собственного домена. Он может предоставить собственный интерфейс (UI) для того, чтобы пользователь выбрал в нем нужное действие, или может принимать действие на вход. Это позволяет другому доменоцентрическому компоненту управлять им, подобно компоненту выбора в режиме всплывающих окон. И хотя связь получается менее свободной, чем хотелось бы, это способствует созданию более компактного интерфейса. Если компонент работает в режиме прямого действия (direct action) или взаимодействия с пользователем, выбор остается за сборщиком приложений.
Например, в следующих версиях приложения Lead Manager предполагается связать между собой информационный домен коммерческих лидов (указаний на потенциальных покупателей) и домены почты и обмена мгновенными сообщениями. Почтовый компонент инициирует действие, позволяющее создать электронное сообщение: при его запуске открывается соответствующее окно для ввода текста письма. При просмотре записей о лидах или информации о компании появляется опция в пользовательском интерфейсе - послать почтовое сообщение для связи с конкретным лидом или компанией. Это происходит потому, что компонент генерирует взаимосвязь с почтовым компонентом. Похожий метод используется для предоставления возможности начать сессию обмена короткими сообщениями.
Поскольку многие записи о лидах начинаются с электронного адреса, можно создать компонент запуска, который принимает некоторое количество свойств, относящихся к вводимым записям для нового лида, и выводит кнопку Create Sales Lead (Создать лид). При нажатии на кнопку контекст переключается к приложению, содержащему базу данных лидов, а компонент инициирует интерфейс для создания новой записи о лиде и заполняет ее имеющейся информацией. Этот компонент можно разместить в почтовом шаблоне (или другой базе данных, являющейся отправной точкой при начале работы), при этом поле To (Кому) выбранного в данный момент почтового сообщения будет связано со свойством Salesperson (Продавец) компонента запуска, а поле From (От кого) со свойством Customer (Покупатель). При выборе опции Create Sales Lead во время просмотра почтового сообщения интерфейс для создания нового лида выводится на экран с уже заполненными полями Salesman и Customer.
Компонент вычисления
Цель компонента вычисления - получение одного или нескольких значений в качестве входных данных и генерирование одного или нескольких производных значений в качестве выходных данных. Он может принимать различные формы, начиная с простых арифметических вычислений и заканчивая контекстным поиском по домену. Во многих случаях такие компоненты не имеют интерактивного интерфейса. Они могут быть пустыми и занимать незначительное место в приложении, или отображаться в виде логотипа или какой-либо другой фирменной символики.
Простой пример вычислительного компонента - обработка списка значений, разделенных запятыми, и вывод их суммы. И если впоследствии у вас появится компонент списка, который может передавать столбец в виде списка значений, его можно будет соединить с суммирующим компонентом, чей результат будет связан с другим компонентом для вывода на экран итоговой суммы.
Другая разновидность этого типа компонентов - это специализированная форма компонента выбора. Представьте, что существует приложение обработки заказов на покупку (purchase order application). Покупки свыше определенной стоимости должны одобряться менеджером. Часть процедуры подачи заказа на покупку требует от пользователя ввода имени и адреса электронной почты менеджера. Компонент выбора в данном случае не сможет исключить вероятность того, что пользователь укажет неверное имя менеджера. В качестве альтернативного решения можно разработать контекстно-зависимый компонент на основе приложения базы данных сотрудников, который получает информацию о событии, содержащую имя сотрудника, и затем выводит дополнительные сведения о нем. Сборщик приложения сможет впоследствии связать информацию о менеджере с введенными в форму данными. Можно даже заменить в форме поле ввода на вычисляемое поле, чтобы избежать ошибок ввода со стороны пользователя.
Помимо отображения данных, эти компоненты также могут отображать бизнес-логику. Предположим, что в предыдущем примере лимит расходов у каждого сотрудника разный и зависит от внутренних правил, например, от региона. Компонент вычисления, просмотрев домен с бухгалтерской информацией, может взять оттуда имя сотрудника и вернуть значение его лимита расходов. Привязанный к домену компонент в приложении обработки заказов на покупку впоследствии сможет проверить этот лимит в режиме реального времени, вместо того чтобы ждать, пока его проконтролирует серверный процесс.
Еще одна специализированная форма этого компонента связана с преобразованием типов данных. Определение строгих (strong) типов данных для свойств и действий компонентов способствует более точной сборке приложения. Однако в некоторых случаях может потребоваться использовать универсальные компоненты с нестрого типизированными свойствами и действиями. Простой вычислительный компонент может получить событие одного типа и опубликовать свойство, где те же самые данные будут описаны как другой тип. Такие вспомогательные компоненты можно при развёртывании сделать невидимыми (или с минимальным интерфейсом) и связать ими как преобразователями формата два несовместимых ранее компонента (например, компонент, принимающий на вход почтовый индекс (zip code) и выдающий строку, содержащую город и страну).
Компонент агрегации (объединения данных)
Некоторые составные приложения могут состоять из нескольких страниц. Контекст простого приложения можно сохранять при переходе между страницами при помощи межстраничных связей, которые предоставляются платформой и поддерживаются Редактором составных приложений (Composite Application Editor). Когда необходимо изменить контекст страницы, свойство соединяется с действием на другой странице посредством межстраничной связи. Генерирование свойства влечет за собой изменение страницы и передачу контекста на новую страницу. В более сложном варианте, скорее всего, вряд ли удастся обойтись простой поддержкой контекста одним элементом и связыванием переходов между страницами с передачей контекста. Контекст может подразумевать под собой отслеживание множества значений, а переходы между страницами могут инициироваться при других действиях пользователя.
Компонент агрегации является компонентом хранилища данных (data warehousing component). Он оперирует набором значений с аналогичными (симметричными) свойствами и действиями для каждого значения. Когда какое-либо значение устанавливается действием, генерируется соответствующее свойство. В дополнение к этому, когда компонент определяет, что страница, на которой он расположен, стала видимой, он генерирует все известные свойства. Основной принцип заключается в том, что компонент поддерживает единую модель данных для всех экземпляров в приложении. Это значит, что при размещении на нескольких страницах значения, установленные на одной из них, будут доступны для поиска и считывания на другой странице.
При использовании компонента агрегации не применяется обычный метод связывания значений напрямую от одного компонента к другому. Вместо этого важные для контекста значения связываются так: свойство первого компонента связывается с действием агрегатора, а потом соответствующее свойство агрегатора - с действием компонента-получателя. При обычной работе на отдельной странице всё происходит точно так же. Изменение свойства на первом компоненте распространяется через агрегатор на целевой компонент. Однако при переходе на другую страницу агрегатор публикует все известные ему значения, когда страница становится видимой. В результате все целевые компоненты на открываемой странице обновляются вместе со связями, подключенными через агрегатор.
Например, приложение управления продажами должно отслеживать информацию о конкретной компании, торговом лиде и торговом представителе (агенте). Одна из страниц может содержать информацию о компании вместе со списком ее торговых представителей. При выборе одного из них появляется всплывающее окно с телефонным номером и адресом электронной почты этого представителя. Если выбрать опцию "создать новый лид", вы перейдёте на другую страницу составного приложения. Однако нам нужно, чтобы поля с названием компании и соответствующими торговыми агентами были уже заполнены на основе их текущего значения, а с помощью простой межстраничной связи это сделать невозможно.
Чтобы это осуществить, нужно поместить на первую страницу компонент агрегации. Компоненты, отвечающие за возможность выбора компаний и торговых представителей, направляют свои связи через компонент агрегации. Затем нужно поместить другой экземпляр того же самого компонента агрегации на вторую страницу, где будет создаваться запись о торговом лиде. Далее связываем свойства определенной компании и торгового агента с соответствующими полями для ввода, и теперь при переходе на эту страницу компонент агрегации определит это, сгенерирует свойства и заполнит форму.
Другие шаблоны компонентов
В течение нескольких месяцев в следующих частях данной серии статей будут подробно рассмотрены информационные компоненты, компоненты редактирования, обобщающие компоненты, компоненты списка и компоненты структурированного списка. Хотя статьи будут написаны в контексте Lotus Notes, эти шаблоны применимы к любой разновидности разработки компонентов.
Шаблоны компоновки
В этом разделе описываются типы шаблонов размещения компонентов.
Область дополнительных компонентов (Radiating dashboard)
Составные приложения могут добавлять релевантную информацию в контекст процесса, над которым вы работаете; тем не менее, ваше внимание должно быть главным образом направлено на вашу основную деятельность. Один из способов сбалансировать эти две необходимости - использовать шаблон, в котором компоненты, требующиеся для выполнения основной деятельности на этой странице, занимают в ней центральное место. Обычно это доменоцентрические компоненты для просмотра, управления или обработки отдельных записей и наборов данных.
В оставшейся части экрана располагаются другие контекстно-зависимые компоненты, предоставляющие дополнительную информацию к основным функциональным элементам. Эта область дополнительных компонентов может располагаться вокруг основной центральной области слева, снизу, справа и даже сверху, в зависимости от ваших потребностей. Можно распределить компоненты по вкладкам, что позволяет экономить свободное пространство экрана и предоставляет быстрый доступ к большому объему разнообразной информации, не перегружая компоновку. Можно также организовать пространство с помощью всплывающих компонентов, которые представлены в виде свернутых значков, пока в них нет необходимости.
Подключение панели дополнительных компонентов страницы происходит достаточно просто. В большинстве случаев между источником контекста (например, выбором пользователя, межстраничной связью или компонентом агрегации) и главными, связанными с доменом компонентами, существуют связи для предоставления данных. Эти связи также установлены с компонентами на дополнительной панели, благодаря чему отображаемые ими данные индексируются.
С таким размещением компонентов организованы несколько страниц в приложении Lead Manager , в частности Sales Lead Details и Company Details (см. рис. 1). Центральную часть экрана занимает компонент, показывающий дополнительную информацию выделенной первичной записи. Область дополнительных компонентов содержит панель с вкладками, содержащими подробную информацию по записи.
Рисунок 1. Подробная информация о компании
В режиме "только чтение" при нажатии кнопки Info (Информация) отображаются всплывающие компоненты (см. рисунок 2), содержащие дополнительную информацию. В режиме редактирования всплывающие компоненты становятся компонентами выбора, что облегчает заполнение полей.
Рисунок 2. Подробная информация о компании с всплывающим компонентом
Страница списка
Страница списка предназначена для отображения сводной информации о множестве записей. Центральная часть страницы обычно состоит из компонента списка или структурированного списка, предлагающего несколько способов сортировки или отображения записей. Помимо этого, существуют дополнительные информационные компоненты, суммирующие совокупную информацию о том, что было отображено или выбрано. В приложении Help Desk можно просмотреть журнал звонков определенного сотрудника из компонента списка, а информационный компонент может вывести среднее время отображенных звонков. В приложении бухгалтерского учета можно вывести список транзакций по счёту, а обобщающий компонент покажет общее значение просматриваемых транзакций.
Страница выбора
Страница выбора является одним из вариантов страницы списка. Информация, содержащаяся на странице списка, просматривается для получения общего представления об этом информационном блоке. На странице выбора такая же информация представлена по определенным элементам данных, при выборе которых отображается подробная информация. Через существующие страницы интерфейса можно также перейти к страницам с дальнейшей детализацией, расположенным в других областях (например, в области дополнительных компонентов).
Страницы выбора часто состоят из одного или нескольких компонентов выбора, позволяющих задать критерии, по которым набор данных будет отсортирован в компоненте фильтрованного списка. Выбор компонента фильтрованного списка может в дальнейшем быть перенесен на панель информационных компонентов для большей детализации и последующего выбора. Когда сделан окончательный выбор данных, о которых нужно вывести дополнительную информацию, этот выбор можно активизировать, например, с помощью однократного или двойного нажатия левой кнопки мыши; при этом устанавливается контекст и осуществляется переход на нужную страницу. Если контекст простой, это можно сделать посредством межстраничной связи; в противном случае для выполнения этого действия можно использовать компонент агрегации совместно с компонентом переключения между страницами.
Привязка компонента выбора немного сложнее, чем связывание страниц с областями дополнительных компонентов. Компоненты выбора должны быть связаны со структурированным списком, который, в свою очередь, привязан к компонентам информационной панели. Если имеется множество переключателей выбора (selectors) или множество списков, возможно, понадобится некоторое количество наборов параллельных связей, чтобы обеспечить корректные потоки данных при активации соответствующего элемента управления.
ПРИМЕЧАНИЕ: Будьте внимательны при использовании вкладок. Например, если информационные компоненты, не распределенные по вкладкам, связаны с вкладками структурированных списков, эти списки должны передавать свое текущее (выбранное) состояние не только когда выбор изменяется, но также при изменении видимости, чтобы обеспечить отображение информационными компонентами сведений, соответствующих тому, что в данный момент показано на экране.
В приложении Lead Manager страница Sales Leads (см. рисунок 3) сформирована по схеме Selection Page. Компонент Lead Browser находится в левой части экрана и может отображать разные режимы выбора. Можно вывести список компаний (отсортированных и отобранных по размеру дохода, сфере деятельности и т. д.), а также вывести список лидов определенной компании. Также можно вывести список собственных сотрудников, занимающихся продажами, и отобразить лиды, находящиеся в разработке у конкретных лиц. Все эти данные вводятся в набор компонентов структурированного списка с правой стороны, который отображает ожидающие обработки и закрытые лиды в соответствии с выбранными в браузере значениями, а в дальнейшем - в соответствии с текущим состоянием лида.
При обновлении выбора информационные компоненты внизу экрана отобразят краткую информацию о выбранном лиде и компании, которой принадлежит этот лид. Если дважды щелкнуть на записи лида, информация о нем передается через межстраничную связь и выполняется переход на страницу с подробной информацией о выбранном лиде.
Рисунок 3. Страница Sales Leads
Страница отображения записей
Данная страница целиком посвящена подробной информации об определенном типе записи. В основной области просмотра отображается подробная информация о типе записи, указанной в запросе. В области информационной панели расположены дополнительные компоненты для вывода подробной информации, касающейся той записи.
В приложении Lead Manager по такой схеме организован экран Company Details (Сведения о компании - см. рисунок 1). Центральную часть экрана занимает подробная информация о компании. Информационная панель содержит вкладки с компонентами, отображающими лиды этой компании, обсуждения данной компании, ее корпоративную Web-страницу и так далее. Нажатие кнопок Info вызовет появление всплывающих компонентов с более подробной информацией (см. рисунок 2).
Страница редактирования записей
Эта страница похожа на страницу отображения записей, но в ней рассматриваемая запись находится в режиме редактирования. Наличие информационной панели для соответствующих данных при этом не имеет смысла, поскольку значения записи неполные либо находятся в процессе создания. Вместо этого информационная панель содержит компоненты, которые могут помочь при создании записи.
Например, можно поместить туда компонент выбора, указывающий на корпоративную базу данных, привязанную к полям, которые необходимо заполнить сотруднику; или представление, содержащее недавнюю электронную переписку, чтобы по ней можно было сформировать поля контактов; или Web-браузер для общего поиска, реализующий импорт текущего адреса Web-страницы в соответствующие поля.
В зависимости от нужд пользователя можно создать страницу, которая является одновременно страницей просмотра и страницей редактирования записей. Преимущество этого способа в том, что детали записи всегда присутствуют в фиксированном формате, но если какие-нибудь информационные компоненты относятся только к режиму "только для чтения" или только к режиму редактирования, нужно убедиться, что их доступность или видимость настроена корректно.
Шаблоны приложений
В этом разделе описываются шаблоны приложений.
Информационно-ориентированные
Информационно-ориентированные приложения нацелены на работу с данными. Такое приложение конструируется путем выбора нескольких первичных записей из информационных доменов, с которыми будет работать приложение. Для отображения агрегированной информации о совокупностях данных создаются страницы списков. Для каждого используемого типа записи может быть создана страница, на которой отображаются такие записи; аналогичным образом создаются страницы редактирования записей - для каждого типа записи, который может быть создан или отредактирован. Эти страницы могут быть сгруппированы в дерево, где страницы списка будут "ветвями", а страницы записей - "листьями". Для переключения между страницами можно использовать встроенный навигатор составного приложения, а для поддержки контекста при переходе между страницами - компонент агрегации. Страницы-"листья" могут быть скрыты для навигации; их активация и создание контекста может быть выполнена с помощью межстраничных связей.
Приведенное в примере приложение Lead Manager разработано главным образом по такому шаблону. Поскольку в нем предусмотрена возможность перехода в режим редактирования, можно просматривать списки Sales Leads, Companies, Contacts, Discussions и Contracts (например, на страницах выбора) или индивидуальные объекты (например, на странице отображения записи). Каждая из этих основных областей является самым верхним уровнем, а из неё можно перейти к более подробной информации. Перекрестные связи также поддерживаются, и это позволяет переходить от одного детализированного контекста к другому там, где это уместно. В примере Lead Manager перекрестные связи предусмотрены между отдельными доменами приложений Leads/Companies, Discussions, Contracts и Contacts.
Процессно-ориентированные
Процессно-ориентированное приложение нацелено в большей степени на выполнение определенных задач, нежели на работу с данными. На основе сценария последовательности действий для роли отдельного сотрудника в приложении создается серия страниц, которые позволяют ему работать с назначенными задачами. Например, в приложении, которое управляет процессом создания рекламных материалов, существуют определенные этапы выполнения операций: обозначение целей и требований, поиск агентства, контроль и утверждение работы этого агентства, и, наконец, архивирование.
Во всех случаях вы можете иметь дело с одним и тем же набором данных. При обозначении целей и требований можно связать запись о кампании с областью дискуссий по определенному роду деятельности, в которой участники вырабатывают цели и задачи данной кампании. На этапе поиска агентства можно создать несколько компонентов, которые преобразовывают ранее определенные цели в ключевые слова для поиска, или использовать компоненты каталога, показывающие отклики по ранее используемым агентствам. При ведении проекта можно использовать базу данных почты для отслеживания корреспонденции и управления процессом утверждения документов (sign off). На итоговой стадии архивирования могут понадобиться агрегированные списки предыдущих кампаний или ресурсы, созданные в результате этих кампаний.
В случае ориентированных на процесс приложений наборы страниц специально настраиваются на текущие задачи и на определенную стадию в последовательности выполняемых действий для первичной записи. Сотрудники с разными ролями видят только необходимые им страницы, что в приложении на базе WebSphere Portal достигалось установкой разрешений на страницах составного приложения. Этот метод недоступен для составных приложений на основе NSF; в них проще создать разные составные приложения для каждой роли, содержащие только необходимые это роли страницы.
На самом деле одним из существенных плюсов составных приложений является то, что при относительно малых затраченных усилиях можно конструировать различные приложения, четко нацеленные на конкретные области. Благодаря многократному использованию компонентов можно создавать эффективные, нацеленные на конкретную задачу и повышающие продуктивность приложения без значительной разработки и реорганизации.
Как уже говорилось, в примере Lead Manager эффективно используется информационно-ориентированный шаблон приложения. Кроме того, с помощью повторного использования компонентов из примера Lead Manager можно создать новое составное приложение - например, приложение, управляющее процессами, связанными контрактами. После создания менеджером по проекту контракта для определенного лида этот контракт проверяется юридическим отделом, а затем покупателем. Составное приложение позволяет определить и ускорить этот процесс проверки.
Модель агрегации
Приложение агрегации содержит в себе несколько объединенных процессов, но их связь главным образом прозрачная. Преимущество заключается в том, что все средства, необходимые пользователю для выполнения работы, собраны в одном месте. Это минимальный уровень интеграции с небольшим взаимодействием, но такое приложение быстро и легко создавать, и оно может быть первой стадией плана по внедрению взаимодействия пользовательских инструментов. Его можно использовать для развёртывания некоторых полезных функций составных приложений для большой группы пользователей, чтобы персонал мог изучить их более детально.
Можно организовать обратную связь с пользователями, рассматривая их предложения о том, где взаимодействие действительно необходимо и может помочь в их работе. Здесь можно применить подход последовательного деления. Сначала используется единый компонент, заключающий в себе целое приложение, а затем на основе требований пользователей можно разбивать этот компонент на более мелкие части, доступные для других применений.
Шаблон агрегации с самого начала использовался при разработке примера Lead Manager. Пользователь взаимодействует с четырьмя приложениями: Leads/Companies, Discussions, Contracts и Contacts. Преимущества составных приложений здесь реализуются прежде всего за счёт объединения этих отдельных NSF-приложений в единое многостраничное составное приложение.
Заключение
Шаблоны, описанные в статье, - это всего лишь небольшой набор возможных шаблонов составных приложений и компонентов. Мы классифицировали их по компонентам, схеме компоновки и приложениям; возможно, что в вашем случае их будет нельзя применить. Полезно иметь представление обо всех категориях шаблонов, чтобы понимать, как можно использовать компоненты и собирать приложения.
Многие из шаблонов оказались полезны при разработке модели Lead Manager и других составных приложений. Некоторые шаблоны могут показаться очевидными, но, научившись определять разные шаблоны разработки, вы сможете создавать приложения, имеющие единообразные внешний вид и функции и основывающиеся на проверенных технологиях и компонентах.
При работе с составными приложениями можно обнаружить и другие пути решения встретившихся проблем. Изучите их, найдите повторяющиеся подходы, эффективные при решении аналогичных проблем, и начните создавать собственную библиотеку шаблонов.
Ресурсы Научиться
Получить продукты и технологии
Обсудить
Об авторах | | | Джо Грант (Jo Grant) - старший инженер-программист IBM Lotus, специализирующийся на технологиях на основе Eclipse. |
| | | Крейг Уолперт (Craig Wolpert) - старший инженер-программист программы поддержки независимых производителей ПО в IBM Lotus Software. |
Выскажите мнение об этой странице
| |
