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

Клиенты пользовательского интерфейса на основе браузера напрямую соответ­ствуют предусмотренным в архитектуре 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, и применения в беспроводных сетях.

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