Приложения. Приложения в архитектуре Luther ответственны за объединение системы в единую функциональную сущность и предоставление интерфейсов прикладного

Приложения в архитектуре Luther ответственны за объединение системы в единую функциональную сущность и предоставление интерфейсов прикладного програм­мирования (APIs), ориентированных на взаимодействие с системой. Обращаясь к API, пользовательские интерфейсы предлагают их характеристики конечному пользователю.

Приложения могут находиться между произвольным числом пользователь­ских интерфейсов и компонентов. Таким образом, приложения связывают m ком­понентов и выставляют напоказ совокупную «прикладную» функциональность n пользовательских интерфейсов. Такие приложения «не распознают» пользова­тельские интерфейсы — иначе говоря, они способны выставлять напоказ такую функциональность, которую может использовать любой пользовательский интер­фейс. В зависимости от ситуации любой пользовательский интерфейс выставля­ет напоказ всю функциональность или какое-то из ее подмножеств. К примеру, пользовательский интерфейс, исполняемый на мобильном клиенте (например, на устройстве с операционной системой Windows СЕ), не может предлагать воз­можности администрирования, которые были бы вполне приемлемы в рамках версии этого интерфейса для настольной системы. Идея в том, чтобы выставлять напоказ все функции, которые могут быть выполнены в данной системе. Реше­ние о том, какие из них предоставить пользователю и как это сделать, каждый пользовательский интерфейс принимает самостоятельно.

Согласно требованию об оперативности разработки и размещения, приложе­ние разрабатывается в как можно более тонком виде. Реализуется эта задача путем делегирования большей части бизнес-задач компонентам (об этом мы по­говорим в следующем разделе). Критерий, исходя из которого прикладной код передается компонентам, очень прост. Сформулировать его можно так: «Преду­сматривает ли данная функциональность возможность повторного использова­ния?». Если предусматривает, то ее необходимо обобщить, тем самым увеличив шансы на многократное применение, и, соответственно, реализовать как компо­нент. Если же вероятность повторного использования данного функционального блока низка, значит, его стоит встроить в приложение.

Ниже перечислены основные элементы приложений.

♦ Интерфейс прикладного программирования. Представляет собой фасад функ­ций, которые система выставляет напоказ пользовательским интерфейсам. Обратите внимание на то, что данные, передаваемые через интерфейс при­кладного программирования, не адаптированы к конкретному представле­нию (например, HTML) и носят универсальный характер (например, XML).

♦ Состояние, сеанса. После инициализации, происходящей и результате аутен­тификации пользователя, информация о состоянии сеанса сохраняется вплоть до закрытия клиентской программы. В архитектуре J2EE управле­ние сеансом упрощается за счет того, что контейнеры не только хранят и извлекают информацию о состоянии сеанса, но также предусматривают аутентификацию и авторизацию. Приложение определяет данные, которые необходимо сохранять между запросами, и для их хранения и извлечения делает соответствующие вызовы.

♦ Прикладная бизнес-логика. Это любая логика, которая является уникаль­ной для приложения и не предусматривает повторного использования в дру­гих приложениях.

♦ Делегирование компонентам. Это код, предназначенный для делегирования задач компонентам. Как правило, реализуется посредством образца проек­тирования под названием «бизнес-делегат» (Business Delegate^[9]).

Эти элементы появляются в результате применения тактики «прогнозирова­ние ожидаемых изменений» и родственны тактике реализации модифицируемо­сти под названием «отделение пользовательского интерфейса».

При создании нового пользовательского интерфейса совершенно не обяза­тельно вносить изменения в прикладной уровень или в компонент. Интеграция новой реализации компонента в систему проходит независимо от прикладного уровня и пользовательских интерфейсов. При введении в систему новой функ­циональности она дополняется новым компонентом. В прикладной уровень вво­дятся соответствующие методы интерфейса прикладного программирования (API), а в пользовательский интерфейс вводятся (или не вводятся) новые харак­теристики, обеспечивающие выставление напоказ новых функций.