Клиенты на основе браузера

Клиенты пользовательского интерфейса на основе браузера напрямую соответ­ствуют предусмотренным в архитектуре J2EE клиентам на основе браузера. При этом они не ограничены веб-браузерами. В равной степени они поддерживают другие формы разметки — в частности, язык разметки беспроводных систем (Wireless Markup Language, WML) для беспроводного прикладного протокола (Wireless Application Protocol, WAP), применяемого в мобильных телефонах. Несмотря на различия по части языка разметки, для предоставления контента используются все те же механизмы, а именно: сочетание сервлетов и JavaServer Pages OSP).

Обмен информации осуществляется клиентом на основе браузера посредством стандартных методов (то есть коммерческих веб-браузеров на стороне клиента, HTTP посредством стека TCP/IP в качестве сетевого протокола и JSP и Java-сервлетов на стороне сервера) в универсальных форматах данных (гипертекстовые документы и таблицы стилей). Для того чтобы сделать клиента тонким, большая часть логики представления реализуется на сервере. Таким образом, возможно­сти создания интерфейса, обладающего переносимостью на браузеры разных про­изводителей и версий, значительно увеличивается.

Рис. 17.4. Интерфейс, отображаемый в браузере и предназначенный для выполнения

процедуры технического обслуживания

Рис. 17.5. Специализированный пользовательский веб-интерфейс

Рис. 17.6. Пользовательский интерфейс в представлении «компонент и соединитель»,

наложенном на представление размещения

Клиенты на основе браузера в основном ориентируются на:

♦ устройства с поддержкой браузеров и традиционных устройств ввода (пе­рьев, клавиатуры и мыши);

♦ приложения, которые отображают информацию, легко представляемую на языках разметки, обеспечивают удобство вывода в браузере и расширения посредством сменных модулей.

Первоначально браузеры разрабатывались в расчете на настольные компью­теры, которые должны были стать оптимальным целевым устройством. На сегод­няшний день поддержка браузеров присутствует в мобильных устройствах.

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

Специальные веб-клиенты

Специальные пользовательские веб-интерфейсы довольно сложны. Они не де­монстрируют прямого соответствия специальному клиенту, который в рамках архитектуры J2EE рассматривается как автономная программа, реализующая всю логику представления и взаимодействующая напрямую с бизнес-логикой (и част­ности, с элементами EJB) посредством удаленного вызова методов (remote method invocation, RMI) по межброкерному протоколу Интернета (Internet inter-ORB protocol, IIOP). Специальные веб-клиенты действительно представляют собой автономные программы, однако, в отличие от специальных клиентов по версии J2EE, для связи с сервером и взаимодействия с сущностями веб-звена (наподо­бие сервлетов nJSP) они используют протокол HTTP, демонстрируя тем самым схожесть с клиентами на основе браузера. Специальные веб-клиенты пишутся в собственной среде разработки в расчете на конкретное устройство или класс устройств. Являясь автономной программой, пользовательский интерфейс рас­сматриваемого типа предоставляет проектировщикам значительную свободу по части поддерживаемых моделей взаимодействия с пользователем. Отсюда — воз­можность оптимального освоения ресурсов наподобие пространства экрана. Воз­можность эта достигается за счет повышения стоимости разработки.

Как показано на рис. 17.6, в архитектуре Luther предпринята попытка мини­мизировать объем собственного кода при написании специального веб-клиента. Задача эта решается с помощью клиентского каркаса, поддерживающего интер­фейсы данного типа. По сути, этот каркас стандартизирует элементы, задейство­ванные в разных приложениях, — в частности, такие элементы, как управление сеансом, аутентификация, а также средства создания и упорядочивания логики представления со стороны клиента, веб-контейнера или с обеих этих сторон. Та­ким образом, клиент представляет собой тонкую автономную программу, которая создает или систематизирует свойственные пользовательским интерфейсам сред­ства. Кроме того, она реализует некоторую часть логики приложения — в частно­сти, проверку входных данных на правильность и сортировку информации в таб­личном представлении. Равно как и в случае с клиентами на основе браузера, большая часть логики представления реализуется в веб-звене, а конкретнее — в компонентах, управляемых клиентским каркасом.

Специальные веб-клиенты обладают множеством преимуществ над другими типами специализированных пользовательских интерфейсов. Во-первых, они тон­кие — другими словами, в сравнении с толстым клиентом (то есть специальной программой, в которой вся логика представления реализуется в клиентском зве­не) они компактнее, удобнее в сопровождении, а кроме того, способствуют пере­носимости между разными устройствами. Во-вторых, для взаимодействия с веб­-звеном они обращаются к протоколу HTTP и этим отличаются от специальных клиентов по версии J2EE, которые используют удаленный вызов методов (RMI) по протоколу IIOP Таким образом, они лучше подходят для реализаций, напи­санных не на Java, и применения в беспроводных сетях.

Создавать специальные собственные пользовательские интерфейсы для каж­дого приложения на каждом устройстве — слишком дорого, даже если этих уст­ройств не так уж и много. Повышения стоимости разработки удается избежать путем разделения устройств на классы, исходя из их характеристик. Для каждого из таких классов изложенными выше методами конструируется высокоточный интерфейс. Большую часть задач по реализации этого интерфейса в рамках дан­ного класса устройств выполняется клиентским каркасом. Аналогичным образом, при реализации значительной части логики представления и веб-звене клиент­ские устройства, приписанные к одному классу, могут обращаться к клиентскому каркасу и совместно использовать определенную часть собственной реализации. Наконец, клиентский каркас предусматривает характеристики, позволяющие устройству объявлять характеристики своих интерфейсов. Эта информация до­ступна логике представления в веб-звене, и, таким образом, перед доставкой кон­тента клиенту с ним можно проводить ряд действий по адаптации.

Приложения

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-04-25