Представьте себе, что вам поставили задачу создать новое приложение, которое будет существовать в мире Web 2.0. Некоторых из ваших пользователей полностью устраивают HTML-основанные пользовательские интерфейсы, в то время как другие ожидают, что каждое приложение, которое они используют, будет вести себя как Excel. Ваш бизнес-спонсор хочет удобный в пользовании, эффективный и производительный интерфейс, а руководитель информационной службы не разрешает вам разрабатывать что бы то ни было, если оно требует ручного развёртывания пользователем. Вы знаете, что HTML с этим не справится, но что же есть ещё? В статье исследуется набор технологий пользовательского интерфейса Web 2.0, позволяющих вам создавать удобные для пользователей приложения, выходящие за рамки возможностей обычного браузера. В результате вы можете централизованно развёртывать приложения и управлять ими, как и любыми другими приложениями Java 2 Enterprise Edition (Java EE).
В настоящее время разработчик корпоративных приложений испытывает давление как со стороны пользователей, так и со стороны специалистов, когда речь заходит о пользовательских интерфейсах. В одном лагере находятся бизнес-подразделения, представляющие пользователей. Они хотят, чтобы их приложения имели богатый пользовательский интерфейс, способствующий увеличению производительности труда пользователей. Представители этой группы предпочитают, чтобы все их приложения вели себя как Microsoft Excel или другие подобные приложения, устанавливаемые на клиентах. Они желают, чтобы приложения обеспечивали им мгновенное время отклика. Если имеется несколько представлений одних и тех же данных (например таблица и график), и одно из них изменяется, они хотят, чтобы и другое отображаемое представление мгновенно отражало бы изменения.
Представители же IT-специалистов любят чистую, сервер-основанную модель доставки. Признавая, что работать пользователям с HTML менее удобно, чем с родным интерфейсом операционной системы, они считают стоимость установки, настройки и управления кодом на клиентских машинах слишком высокой, несмотря на более удобную работу для пользователей, которую даёт это решение.
Многие из IT-специалистов в 1990-х гг. пережили клиент/серверную модель развёртывания и не хотят снова иметь с ней дело. В действительности, многие приложения Java 2 Enterprise Edition (Java EE), возможно, так и не были бы созданы, если бы в них существовал клиентский компонент, так как его стоимость свела бы на нет коммерческую выгодность приложения. Модель серверного развёртывания даёт IT-подразделениям желаемый простор и свободу действий в плане экономической эффективности, о которой можно было только мечтать в девяностых. Большинство организаций, сталкивавшихся с экономическими характеристиками развёртываемого на сервере приложения Java EE, никогда не будут рассматривать возможность развёртывания кода, который они должны будут установить на отдельные клиентские машины, если только не возникнет острая необходимость.
Так что же делать бедным корпоративным разработчикам? Пользователи не хотят терять продуктивность из-за многосекундных задержек отклика от сервера, а группы IT-специалистов не хотят возвращаться к старым способам развёртывания и управления кодом на клиентских машинах. Как примирить эти, казалось бы, противоречащие друг другу требования таким образом, чтобы оба лагеря остались довольны?
К счастью, существуют технологии, позволяющие вам достичь удобства пользователя при работе с функциями, превышающими возможности обычного браузера, и при этом не требующие от вас ручной установки кода на клиентских машинах. Приложения, создаваемые при помощи этих технологий, иногда называют приложениями Web 2.0. В своей статье, "Что такое Web 2.0? Конструктивные шаблоны и бизнес-модели следующего поколения ПО", Тим О'Рейли заявляет:
Мы вступаем в беспрецедентный период инноваций в области пользовательского интерфейса, так как Web-разработчики наконец-то получили возможность создавать Web-приложения, так же богатые функционально, как и локальные PC-приложения.
Приложения Web 2.0 берут всё самое лучшее из обоих миров: экономически эффективная сервер-основанная модель развёртывания сочетается с высоким удобством работы пользователей, в основном сравнимой с комфортностью работы в установленных на клиенте приложениях.
Ниже перечислены различные технологии, которые вы можете выбрать для создания привлекательной и удобной для пользователей среды в сегодняшних приложениях Java EE:
- Flex и OpenLaszlo
- IBM® Workplace™ Managed Client и IBM Lotus® Expeditor
- Faces Client Components
- Ajax
- HTML
Flex и OpenLaszlo
Flex и OpenLaszlo - похожие декларативные походы к созданию превышающих возможности браузеров интерфейсов для приложений Java EE. Flex предлагается Adobe/Macromedia, а OpenLaszlo - ПО с открытым исходным кодом, изначально созданное Laszlo Systems Inc. В обоих средах для проектирования и создания пользовательского интерфейса вы используете уникальную, привязанную к конкретной технологии грамматику на основе XML.
Например, чтобы использовать кнопку во Flex, вы можете написать следующий код на MXML (Multimedia XML): <a name="code-text"><mx:Button label="Submit"</mx:Button></a>
А в OpenLaszlo вы пишете следующее на LZX (LasZlo XML): <a name="code-text"><button<Submit</ button></a>
Чтобы разрешить различным элемента интерфейса взаимодействовать и поддерживать связь с сервером, вы пишете скрипт либо на ActionScript (Flex), либо на JavaScript (OpenLaszlo).
Хотя обе технологии во многом сходны, имеется и ключевое отличие - им требуется различная инфраструктура выполнения. Чтобы клиент обменялся данными с сервером, для Flex необходим Flex Data Services Server, который устанавливает связь с клиентом, работающим в плагине Flash Player. Сервер в значительной степени служит посредником для любого обмена данными между клиентом и серверным компонентом приложения.
В последней версии OpenLaszlo имеются некоторые изменения в области выполнения, которые могут сделать её более привлекательной для разработчиков. Одним из изменений является то, что в Версии 3 появился режим развёртывания SOLO, исключающий необходимость в Laszlo Presentation Server в некоторых конфигурациях. Ещё одно важное усовершенствование - это среда выполнения клиента. Новейший релиз, OpenLazlo 4 (в настоящее время бета-версия), позволяет основанным на Laszlo приложениям выполняться без плагина Adobe/Macromedia Flash Player. Многим компаниям, обеспокоенным тем, что им приходится использовать проприетарный плагин вроде Flash Player, это изменение придётся по вкусу.
Как определить, что лучше для вашей организации? В случае Flex, ключевым преимуществом является то, что вы имеете полную поддержку от Adobe/Macromedia, но вы понесёте расходы на приобретение лицензии на Flex Data Services Server. Для некоторых компаний стоимость лицензии не так важна, как полная поддержка продукта. Приложениям Adobe Flex 2 также требуется плагин Flash Player V9. Несмотря на то, что Flex может помочь создать привлекательную пользовательскую среду, его стоимость, а также тот факт, что ему требуется плагин, может отпугнуть некоторые компании.
Технология OpenLaszlo изначально выпускалась как коммерческий продукт, но в 2004 г. Laszlo Systems решила перевести её на опенсорсные рельсы, лицензировав её под Common Public License (V1.0). Laszlo Systems не предлагает поддержки по подписке, и так как это открытый проект, вы можете осуществлять поддержку через свободно доступные источники. В случае OpenLaszlo, стоимость, как очевидно, не является проблемой, однако во многих компаниях проводится достаточно жёсткая политика против использования ПО с открытым исходным кодом, поэтому OpenLaszlo не является для них альтернативой.
IBM Workplace Managed Client и Lotus Expeditor
И IBM Workplace Managed Client, и Lotus Expeditor построены на основе открытого кода EclipseRPC. В основе технологии EclipseRPC лежит рабочая среда инструментов разработки Eclipse, общая платформа, управляемая и контролируемая eclipse.org. Если в соответствии с вашим бизнес-требованиями необходимы отсоединённые операции и вы можете устанавливать компоненты на клиентской машине, Workplace Managed Client и/или Lotus Expeditor - лучшие технологии для создания и развёртывания приложений.
IBM Workplace Managed Client является компонентом семейства продуктов IBM Workplace. Оно объединяет различные сервисы для совместной работы в одну интегрированную среду, или среду рабочего стола. В ней имеются такие возможности как управление документооборотом, работа с сообщениями (в том числе и мгновенными), Web-браузинг, прямой интерфейс к Notes® 7, eLearning, поддержка team spaces, Web-конференции, а также функция activity explorer для отслеживания потоков, связанными с рабочими заданиями. Lotus Expeditor предоставляет расширенную клиентскую платформу, поддерживающую корпоративные приложения, транзакции, управление устройствами и Web-сервисы. Есть много причин выбрать Workplace Managed Client или Lotus Expeditor. Workplace Managed Client обычно является лучшим выбором в том случае, если ваше приложение по природе своей коллаборативно. Если же приложение больше предназначено для работы с транзакциями, обычно рекомендуют Lotus Expeditor.
И Workplace Managed Client, и Lotus Expeditor позволяют разработчикам создавать расширенные клиентские приложения, устанавливающиеся на клиентской машине, а также добавлять в них поддержку отсоединённых операций. Поскольку приложение устанавливается на клиенте, клиент может наиболее полным образом использовать мощности рабочей станции, на которой он работает, что позволяет вам создавать привлекательную и удобную среду для пользователей. Общая и для Workplace Managed Client, и для Lotus Expeditor основа Eclipse предоставляет независимую от ОС платформу, которая скрывает от вас нюансы операционной системы, в то же время применяя родные службы ОС, где это возможно. Это позволяет вам разрабатывать общий основной Java-код, выполняющийся и в Linux™, и в Windows™, а в будущем и на Macintosh.
Чтобы получить максимальную выгоду от этой технологии, вам нужно проектировать ваши приложения таким образом, чтобы задействовать архитектуру плагинов Eclipse. Компоненты пользовательского интерфейса создаются при помощи виджетов SWT (Standard Widget Toolkit) или компонентов jFace. SWT - это набор виджетов и графическая библиотека, интегрированная в родную оконную систему, но с ОС-независимым API, а jFace - инструментарий пользовательского интерфейса, реализованный с помощью SWT, который упрощает многие типичные задачи по программированию пользовательского интерфейса. jFace не зависит от оконного менеджера ни в плане API, ни в плане реализации, и предназначается для работы с SWT, не скрывая последний. Конечным результатом является более высокая интерактивность и удобство пользователя, ощущения напоминают работу со знакомыми пользователю приложениями операционной системы.
Наконец, тот факт, что основанными на Workplace Managed Client или Lotus Expeditor приложениями можно управлять через сервер, отличает их от родных Windows-приложений. Эта ключевая возможность сводит к минимуму, если полностью не ликвидирует все затраты на системное администрирование, связанное с размещённым на клиентах кодом приложений. В результате, предприятие, развёртывающее приложение получает все преимущества владения развёртываемым на сервере приложением Java EE, а пользователь - удобное в пользовании, "заточенное" под конкретную ОС и устанавливаемое на клиенте приложение; это выигрышное решение для большинства организаций.
Faces Client Components
JavaServer Faces (JSF) - это компонент Java EE 1.4, изначально разрабатываемый как JSR 127. Ключевой целью данной технологии было снизить уровень квалификации Java-разработчиков, необходимый для разработки пользовательских интерфейсов для своих приложений Java EE. Так как JSF является рабочей средой, в ней имеется много готовых возможностей, которые в прошлом разработчикам приходилось программировать вручную при создании такого же интерфейса с помощью JavaServer Pages (JSPs).
Например, предположим, что у вас есть большой набор результатов JDBC™, который необходимо отобразить для пользователя. Рабочая среда JSF предоставляет виджет DataTable, который можно использовать для отображения данных. Если вы уже создали пользовательский интерфейс с помощью простых JSP, вам придётся управлять взаимодействием пользователя с таблицей и определить, какие строки данных должны выводиться пользователю.
В JSF DataTable, когда пользователь нажимает Next, чтобы отобразить следующие x строк данных в таблице, рабочая среда JSF будет обрабатывать запрос Next, и вам ничего не нужно кодировать самостоятельно. Наряду с тем, что JSF облегчает вам создание расширенных HTML-основанных пользовательских интерфейсов, JSF предумышленно сделано серверной технологией. Запрос следующих x строк данных идёт от браузера на сервер, где код рабочей среды JSF обрабатывает его. JSF требует двустороннего взаимодействия с сервером.
Для улучшения базовых JSF-виджетов в IBM Rational® Application Developer V6 введены Faces Client Components. Faces Client Components - это расширение технологии JavaServer Faces, позволяющей вам выполнять некоторые сервисы рабочей среды JSF на стороне клиента. Например, если вы использовали компонент DataGrid Faces в приведённом выше примере, отображение следующих x строк данных не будет требовать двустороннего взаимодействия с сервером.
Использование Faces Client Components естественным образом приведёт к JSF-разработчику из Rational Application Developer. Чтобы использовать Faces Client Components, вы должны создать страницу Faces JSP и выбрать "Basic with client-side data caching (Базовый, с кэшированием данных на стороне клиента)" в качестве модели. Затем, когда вы конструируете пользовательский интерфейс в Rational Application Developer, просто выберите соответствующие элементы управления UI из секции Faces Client Components палитры инструментов в Rational Application Developer.
Многое происходит под прикрытием Faces Client Component. Вы загружаете JavaScript-реализации элементов управления JSF в браузер и используете находящийся на стадии становления промышленный стандарт Service Data Objects для связи между браузером и сервером. Однако, как это и должно быть, всё протекает незаметно для пользователя; он просто замечает, что приложение реагирует гораздо быстрее, чем типичное браузер-основанное приложение.
Ajax
Ajax (Asynchronous JavaScript and XML), термин, составленный Джесси Джеймсом Гарреттом (Jesse James Garrett), является основанной на стандартах методикой (и конструктивным шаблоном) для разработки превышающих возможности браузеров пользовательских интерфейсов для развёртываемых на сервере приложений. Ajax не зависит от используемой серверной технологии и может работать с приложениями Java EE, .Net и другими. С Ajax вы пишете код JavaScript в дополнение к стандартному HTML и создаёте богатый, интерактивный пользовательский интерфейс. Например, JavaScript может выполнять проверку ввода локального пользователя, предоставлять различные режимы отображения одних и тех же данных (линейный график - таблица - круговая диаграмма), или асинхронно взаимодействовать с серверным компонентом приложения через объект XMLHTTPRequest браузера.
В соответствии с отчётом Gartner Group под названием Цикл ажиотажа вокруг новых технологий (Hype Cycle for Emerging Technologies 2000, 18 июля 2006 г.), Ajax уже достиг "Пика завышенных ожиданий" и теперь находится на стадии "Впадина разочарований." Вы также можете оценить ажиотаж вокруг Ajax по количеству продаваемых в магазинах книг. По моему мнению, три вещи помогли Ajax преодолеть технологическую пропасть Джеффри Мура:
- Современные браузеры. В прошлом, разработчикам JavaScript приходилось справляться с многочисленными несовместимостями между Netscape, Internet Explorer и другими браузерами. В некоторых случаях даже различные версии одного браузера были несовместимы. Хотя некоторые из этих несовместимостей по-прежнему существуют, большинство интранет-приложений обычно требуют Internet Explorer 5.5 и выше и/или Firefox 1.0 и выше, где большинство этих ранее существовавших проблем с несовместимостью были решены. Недавно был также образован открытый промышленный консорциум, OpenAjax, который должен заниматься проблемами несовместимости в Ajax, как и другими связанными с Ajax вопросами.
- Инструментарии Ajax. В прошлом, большинству разработчиков, которые хотели работать с Ajax, приходилось начинать практически с нуля, выполняя большое количество рутинных операций, которые теперь могут выполнять инструментарии Ajax. Инструментарии обеспечивают различные встроенные JavaScript-основанные элементы управления пользовательского интерфейса (виджеты), чтобы облегчить разработчикам создание основанных на Ajax интерфейсов. Инструментарии также обычно предоставляют более высокий уровень абстракции, скрывая от разработчика вышеупомянутую несовместимость браузеров.
- Инструменты. До недавнего времени, большинство разработчиков JavaScript практически не имели инструментов разработки, которые могли бы им помочь при отладке и вообще облегчить им жизнь. С момента выхода браузера Firefox, в нём имелись некоторые полезные плагины для разработчиков Ajax, а IBM недавно интегрировала набор полезных технологий в Ajax Toolkit Framework с целью помощь в решении этой проблемы. В ATF (Ajax Toolkit Framework), который можно загрузить бесплатно с сайта Apache, имеется основанная на Eclipse Ajax среда разработки. В ATF также есть такие инструменты, как чувствительный к синтаксису редактор JavaScript, консоль JavaScript и просмотровщик объектов
XMLHTTPRequest. Кроме того, в ATF уже встроены Dojo, Zimbra и Rico.
Наконец, по моему мнению, звёздный час Ajax наступил, когда Google выпустил бета-версию своего основанного на Ajax приложения Google Maps. Любой человек, который ранее работал с картографическим Web-сайтом, быстро заметил преимущество ПО Google над другим подобными интернет-сайтами. Пока неспециалисты удивлялись и гадали, как же Google сделал это, программисты, смотревшие глубже, обнаружили там Ajax, и начали размышлять, как бы и им использовать технологии на его основе для улучшения удобства пользования и скорости реакции собственных приложений.
Чистый HTML
Хотя многие разработчики и полагают, что у всех пользователей, как и у них самих, стоит последний Firefox с десятью самыми популярными плагинами, в действительности на многих машинах для доступа в интернет по-прежнему используются Netscape 3.x или Internet Explorer 4.x. Браузеры этого уровня могут применяться с целью доступа к конкретному приложению (исходники которого потеряны и его нельзя изменить), или же они могут просто быть установлены дома у консервативного пользователя, продолжающего использовать Internet Explorer 4.0, лишь потому, что он придерживается принципа "работает - не чини" в отношении обновления браузера.
Хотя совершенно очевидно, что HTML не может обеспечить такого удобства пользователя, как любая из вышеперечисленных технологий, основанные на HTML пользовательские интерфейсы в долгосрочной перспективе по-прежнему будут играть важную роль. Никакая другая технология не позволит приложению быть доступным для такого большого числа пользователей, как чистый HTML. В результате многие приложения по-прежнему будут предоставлять такие пользовательские интерфейсы ещё много лет.
В заключение
В общем и целом, основным направлением в промышленности сегодня является улучшение удобства работы пользователя с серверными приложениями. Ajax, хотя и ещё не совсем зрелый, уже набрал большие обороты, и многие предприятия, большие и малые, начинают использовать его в производстве. Другие упомянутые в статье технологии имеют мало поклонников, но на данный момент ни одна из них ещё не раскрутилась по настоящему.
Существуют и другие технологии пользовательского интерфейса, как коммерческие, так и свободные (например Nexaweb, Backbase и JackBE), но в статье о них речь не шла в целях краткости. Важно то, что не одна из этих технологий не является универсальной и всеобъемлющей, следовательно, ни одна не подходит полностью во всех ситуациях. Каждая из вышеперечисленных технологий имеет свои преимущества и может быть хорошим выбором в зависимости от обстоятельств.
Так как же делать выбор? Для начинающих нет ничего лучше старого доброго HTML, если выбор технологии мотивируется максимальной пользовательской аудиторией. С другой стороны, если вам требуются отсоединённые операции, и вы можете устанавливать ваше приложение на машины пользователей, наилучшим выбором будет одна из альтернатив на основе EclipseRPC, Workplace Managed Client или Lotus Expeditor.
Если вам требуется богатый пользовательский интерфейс, обладающий точностью и надёжностью Flash Player, возможно, будет оправдан выбор Flex или OpenLaszlo. Если вы создаёте приложения с помощью JavaServer Faces, лучше прибегнуть к Faces Client Components.
Наконец, если ваша цель - просто заткнуть дыры в существующем HTML-интерфейсе или разработать основанный на стандартах, не требующий плагинов пользовательский интерфейс с функциональностью, лучше чем у браузеров, ваш выбор - Ajax. В данный момент "цикла ажиотажа", Ajax, кажется, становится самой популярной технологией Web 2.0, но я бы не стал списывать со счетов другие технологии - они возьмут своё, когда возмужают.
Ключом к правильному выбору являются требования к приложению, которыми следует руководствоваться при выборе технологии создания пользовательского интерфейса. Хотя эта рекомендация кажется простой и очевидной, во многих случаях разработчики делают как раз всё наоборот, что может привести ко многим проблемам при реализации и развёртывании (что в свою очередь вызывает значительные задержки и осложнения при разработке проекта). Не допускайте, чтобы это происходило и с вами.