Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Развитые Интернет-приложения

Пит Пэйн

Web 2.0 — термин, который понимают все ИТ-специалисты (хотя далеко не всем он нравится), охватывает ряд интернетовских методов и технологий следующего поколения. Одна из выдающихся концепций, входящих в данное понятие, — это концепция “развитых Интернет-приложений” (Rich Internet Applications — RIA).

При правильной реализации RIA позволяют Web-браузеру быть “более равноправным партнером” Web-сервера, чем при простом кэшировании загружаемых данных. Пользователю не приходится ждать, пока сервер отправит целую страницу данных, а браузер ее отобразит. Вместо этого данные извлекаются и отображаются по мере возникновения необходимости в них. Использование Web-браузера становится более похожим на применение приложения настольной системы. Организациям приложения RIA обещают целый ряд выгод, включая повышение продуктивности работы пользователей благодаря более четким и менее инерционным интерфейсам.

Однако, как и у Луны, у RIA есть своя темная сторона. Для того чтобы концепция стала успешной, необходимо решить проблемы информационной безопасности, администрирования и масштабируемости. При работе RIA будет возникать перегрузка по обмену сообщениями и числу устанавливаемых сессий, поскольку для снабжения клиентов данными серверам приходится работать более интенсивно. Далее, разработка приложений RIA вручную — это занятие “не для слабых духом”. Чтобы проект RIA оказался успешным, необходимо учитывать множество иногда очень тонких различий между браузерами. Хорошо, что некоторые поставщики это понимают и предпринимают меры к тому, чтобы облегчить данную задачу. Так, компании Adobe, Google и ассоциация Dojo Foundation — занимаются решением этой проблемы, подступаясь к ней с трех разных сторон.

Немного истории

В прежнее время любая работа со “Всемирной паутиной” представляла собой простые челночные рейсы между Web-браузером и сервером. В общем случае браузер выдавал запрос серверу и ждал, пока тот соберет требуемые ресурсы, обработает данные, проведет форматирование текстов, загрузит картинки и в конечном счете перешлет результаты пользователю. Последнему приходилось терпеливо ждать, иногда так долго, что он начинал нервно хвататься за мышь в тщетных попытках заставить систему сдвинуться с места. В следующий раз, когда пользователю необходимо было обновить страницу, либо перейти по какой-либо ссылке, история повторялась и вновь запускался утомительный процесс формирования очередной порции данных, в виде Web-страницы. Такая модель работы с Web была приемлема, когда большинство сайтов содержало оптимизированную графику (сегодня об этом уже говорят, как об утраченном искусстве), простые данные и статический HTML-контент.

Однако с появлением более сложных Web-страниц и увеличением объемов подлежащих передаче данных пользователи стали с меньшей терпимостью относиться к чрезмерно большому времени ожидания. Проблема не потеряла своей остроты даже при повсеместном внедрении широкополосных услуг связи. Web-страницы стали слишком большими, чтобы можно было позволить обновлять их целиком каждый раз, даже если менялся всего один их элемент. В конечном счете пользователи хотят, чтобы просмотр Web-страниц был близок по скорости, инерционности и восприятию к работе с настольными приложениями. Первые попытки добиться этого, отразившиеся в продуктах ActiveX компании Microsoft, Flash компании Macromedia (сейчас Adobe), LiveConnect компании Netscape, Java-приложениях и некоторых других, имели весьма скромный успех.

Конвергенция Интернет-технологий вооружила разработчиков рядом средств для ускорения Web-просмотра. С появлением продукта Netscape Navigator в браузеры была включена функция отработки сценариев на клиентской стороне — главным образом при помощи JavaScript и DOM (Document Object Model). Каскадируемые стилевые таблицы CSS (Cascading Style Sheets) дали тем же разработчикам значительно более глубокий контроль над представлением Web-страниц. В комплексе (как это сделано в DHTML — Dynamic HTML) эти технологии сделали Web-страницы намного более оперативными и более живо откликающимися на вводы пользователя. И тем не менее очень важный элемент все еще отсутствовал.

Принятие стандарта XML и объекта XMLHTTP-Request заложило основу для разработки концепции RIA в той форме, в которой мы знаем ее сегодня. Технология DHTML, включившая в себя DOM, CSS, HTML и JavaScript, а также XML составили инструментарий стандарта Ajax (чтобы получить более полное представление об Ajax и гибридных Web-приложениях см.: Сети и системы связи. 2007. № 6. С. 52 ). В комплексе эти технологии позволяют обновлять Web-страницу по секциям, а не целиком. Другими словами, разработчики могут изменять содержание небольших частей страницы, делая запросы Web-серверу только на предмет получения данных, необходимых для такого изменения. В результате пользователю больше не приходится ждать, пока целая страница (в которой имеется много избыточной информации) будет скомпилирована Web-сервером, передана и после этого отображена браузером.

Если организация приняла решение пойти по пути RIA, то какие подходы к разработке таких приложений следует проводить? К сожалению, разные реализации очень плохо совместимы, так что однажды сделанный выбор может жестко и на долгое время привязать вас к конкретному решению. Рассмотрим преимущества каждого из известных подходов: насколько хорошо он будет укладываться в рамки вашей системы, насколько зрелым он является, и какое влияние он окажет на работу ваших пользователей и вашей службы оперативной поддержки. Несомненно, что в одной и той же среде разработки и на одних и тех же Web-серверах могут сосуществовать различные инструментарии, но на уровне кодов создаваемые с их помощью программы останутся несовместимыми. Те же самые соображения касаются и ситуации, когда выбор делается в пользу совсем иных подходов, включая решения Microsoft и Oracle.

Общие библиотеки

В настоящее время внимание разработчиков привлекают три подхода. Первый — его представляет продукт Dojo Toolkit ассоциации Dojo Foundation — сводится к применению средств, предоставляемых браузером, а именно JavaScript, DOM, DHTML и CSS. Dojo Toolkit строится на наиболее общих средствах разработки Web-страниц: HTML и JavaScript. Кроме того, он обеспечивает хранилище данных на стороне клиента и несколько механизмов их транспортировки, отвечающих требованиям стандартов. Следует отметить также, что Dojo Toolkit поддерживается многими ведущими поставщиками Интернет- и корпоративных продуктов.

Разработка с применением JavaScript и HTML имеет результатом код, подлежащий исполнению без изменения его браузером. Эта методология пользуется поддержкой организации OpenAjax Alliance, членами которой являются компании BEA Systems, Borland Software, IBM, Laszlo Systems, Mozilla, Novell, Oracle, SAP и др. Альянс был соз-дан для содействия распространению интероперабельных технологий Ajax. Пропагандируя общий набор библиотек JavaScript, организация надеется продвигать разработки на базе Ajax, по мере того как библиотеки будут становиться все менее зависимыми от поставщиков и от особенностей конкретной реализации. Ассоциация Dojo Foundation тоже является членом OpenAjax Alliance и сейчас создает свой типовой инструментарий.

Продукт Dojo Toolkit состоит из библиотек JavaScript, ориентированных на функциональность браузера. При этом имеется базовая библиотека для поддержки основных функций и дополнительные библиотеки, “специализирующиеся” на элементах пользовательского интерфейса, интерфейсе по данным, графике, построению диаграмм, поддержке разных языков, обработке событий и т. п. Dojo Toolkit использует набор расширений до стандарта HTML, именуемый DojoML и определяющий специальные графические элементы, которыми могут оперировать библиотеки JavaScript.

Пользоваться продуктом Dojo Toolkit сравнительно просто. Ссылки на желательные библиотеки JavaScript вводятся в Web-страницу посредством метки <SCRIPT> и там, где требуется, вставляются операторы языка DojoML. Благодаря простому выполнению этих операций вводится обширная функциональность. Разработчики могут также вводить код JavaScript для выполнения специализированных функций, таких, как извлечение данных и оперирование ими или обработка информации, вводимой пользователем. По завершении разработки результирующие библиотеки и HTML распространяются как часть готового приложения.

Чтобы еще больше упростить программирование, созданы несколько интегрированных сред разработки или подключаемых модулей (плагинов) для существующих сред, таких, как Eclipse. Во всех рассматриваемых инструментариях разработку можно вести с применением простых текстовых редакторов, однако опытный программист наверняка захочет использовать контрольные точки, отслеживание переменных, трассирование стека и другие приемы. Иными словами, если какая-либо интегрированная среда разработки имеется, то ею следует пользоваться.

Соединения для удаленного получения данных устанавливаются при помощи механизма XML и осуществляются по HTTP или с помощью механизма RPC (Remote Procedure Call). В локальной системе инструментарий позволяет пользователям хранить данные с привлечением объектов Flash SharedObjects или WHAT WG Storage Provider в браузере Firefox. Хотя локальное хранилище данных не является частью концепции RIA, иметь его полезно для хранения параметров локальных конфигураций, копий объектов, которые в противном случае пришлось бы снова загружать с сервера, а также для специфических данных пользователя, таких, как документы или изображения.

Выбор языка

Второй подход к RIA, который лучше всего иллюстрируется продуктом Google Web Toolkit (GWT), базируется на применении языка Java, позволяя разработчикам писать программы на этом языке, а развертывать RIA с применением JavaScript и HTML. Кодирование упрощается благодаря специальным средствам, предоставляемым компанией Google. С целью облегчить тестирование блоков приложений интсрументарий GWT интегрируется с базирующейся на Java тестовой библиотекой JUnit. Однако транспортировка данных ограничивается только механизмами RPC и JSON (JavaScript Object Notation). Возможность локального хранения данных отсутствует.

И в случае GWT JavaScript исполняется в браузере с передачей соответствующих запросов DOM, DHTML и CSS, но для написания RIA используются не библиотеки JavaScript, а еще один специальный набор инструментальных средств на другом языке. В некоторых случаях выбирается Java, а в других ASP.NET (Active Server Pages.NET). Вне зависимости от набора инструментальных средств программный код компилируется в сценарий JavaScript, который передается на клиент и исполняется.

Разработчики RIA, работающие с GWT, используют некоторое подмножество языка Java для создания интерфейсных элементов браузера, генерации запросов к и обработки событий. Google предлагает также набор графических компонентов для создания пользовательского интерфейса. Java-код исполняется специальным браузером в среде JRE (Java Runtime Environment), благодаря чему обеспечивается простота отладки и тестирования. Использование IDE-средств (мы, например, использовали Eclipse) ускоряет процесс и облегчает жизнь разработчикам. В базу продукта с целью улучшить тестирование и отладку включена также библиотека JUnit. По завершении разработки или в ходе процесса исходная программа на Java может быть пропущена через входящий в состав инструментария компилятор, который преобразует Java-программу в JavaScript и HTML.

Следует предостеречь: компания Google воспроизвела многие базовые библиотеки Java, но эта работа еще далека от завершения. Предлагаемые пакеты java.lang и java.util почти полностью совместимы со стандартными библиотеками Java. Однако Java-объекты других классов компилятор транслировать не может и поэтому их нельзя использовать при построении RIA. На посвященной GWT Web-странице дается подробная информация о том, какие классы поддаются трансляции, а каких следует избегать. Если доступные Java-классы не обеспечивают требуемую функциональность, то разработчик может воспользоваться преимуществами интерфейсного средства JSNI (JavaScript Native Interface). Это метод позволяет включить JavaScript в Java-код во время разработки. JavaScript может взаимодействовать с Java-кодом в процессе разработки и с результирующим кодом JavaScript после компиляции, который обеспечивает вызов функции и обработку исключительных ситуаций, но такую разработку нужно вести с особым вниманием. Результирующий код часто получается не лишенным недостатков: затруднительным является переход от одного браузера к другому, может возникать “утечка памяти” (ее захват без последующего освобождения), компилятору бывает трудно произвести оптимизацию кода.

GWT предусматривает соединения для получения данных в соответствии с механизмами JSON (JavaScript Object Notation) и RPC. При этом число создаваемых соединений сделано сравнительно небольшим, с тем чтобы упростить разработку и ускорить исполнение результирующего кода. GWT предлагает “обходные” пути организации доступа к Web-сервисам, а при необходимости дополнительные варианты такого доступа могут быть запрограммированы вручную.

Инструментарии Flex

Третий подход, лидером в котором является компания Adobe, демонстрирует полный уход от CSS, DOM, DHTML и JavaScript. Инструментарии Flex упомянутой компании создают объекты Flash, в которых инкапсулированы приложения RIA. Разработка выполняется с применением языка ActionScript и специальных разметочных кодов, а доступ к данным осуществляется разными методами, включая методы, являющиеся коммерческими разработками компании. По завершении разработки исходный текст компилируется в машинный код с байтовым представлением, который исполняется в рамках браузера практически независимо от CSS, DHTML и DOM. Хотя в данном случае мы наблюдаем отход от “чистой” технологии Ajax, тем не менее Flex продолжает оставаться в рамках концепции RIA.

Основываясь на приобретениях, сделанных в результате недавнего поглощения фирмы Macromedia, компания Adobe выпустила набор инструментария Flex. Он требует, чтобы разработчики писали программный код, пользуясь языком ActionScript, который представляет собой язык, совместимый со стандартом ECMAScript и языком разметки MXML, базирующимся на XML. Кодирование может быть сделано вводом командных строк с экрана или (по вашему желанию) с привлечением других инструментариев в той или иной среде разработки IDE (мы, конечно же, снова пользовались средой Eclipse).

Результирующий код компилируется и преобразуется во Flash-объект. Этот объект затем распространяется на Web-браузеры как RIA. Как и любой Flash-контент, этот объект исполняется в среде пакета Flash Player, хостируемого Web-браузером. Элементы пользовательского интерфейса, обработка изображений, графика, поддержка событий и почти все остальные задачи выполняются в среде Flash Player. Поскольку последняя имеется практически во всех Web-браузерах, распространение RIA-приложений в большинстве случаев не ограничивается типами браузеров или их версий. В этом мы видим потенциальную ловушку для приложений RIA, базирующихся на языке JavaScript, хотя по мере его совершенствования и продвижения поставщиков к Web-стандартам мы ожидаем, что будет все меньше различий между RIA, исполняемыми с использованием JavaScript, и RIA, основанными на Flash. С целью упростить разработку и стимулировать автоматизированное тестирование программных модулей в состав Flex включена тестовая среда Flex Unit, похожая на JUnit.

Инструментарии Flex предлагают большинство известных вариантов соединений для работы с данными. Если стандартный инструментарий Flex предусматривает те же методы передачи данных, что и другие инструментарии, то за отдельную плату компания Adobe продает еще и специальное приложение Flex Data Services 2. Этот пакет размещается на сервере приложений Java EE Application Server и “снабжает” данными программы-клиенты Flex, пользуясь для этого удаленными объектами (Action Message Format), JMS или RTMP (RealTime Message Protocol). Последний представляет собой заказной протокол, поддерживаемый пакетом Flash Player. Аналогично инструментарию Dojo Toolkit Flex предусматривает хранилище данных на стороне клиента и извлечение их посредством объектов общего пользования SharedObjects.

Важные соображения

Перед созданием инфраструктуры RIA необходимо рассмотреть ряд вопросов. Особую важность представляет информационная безопасность. Не снижают ли эти приложения уровень безопасно-сти организации? При правильной разработке, развертывании и администрировании в общем случае угрозы безопасности не возникает. Как и в случае любого Web-приложения, обращающегося к вашим данным, в обязательном порядке должны осуществляться аутентификация и авторизация. Для транспортировки данных, выдачи запросов и получения ответов все подходы к разработке RIA пользуются браузером, что позволяет положиться на те модели обеспечения информационной безопасности, которые уже существуют в отношении Web-доступа, например, на механизм SSL. Однако это приводит к дополнительной нагрузке, что может отрицательно сказаться на производительности серверов и сети. Поэтому пользоваться этим решением следует с учетом данного обстоятельства.

Как обычно, из всякого правила есть хотя бы одно исключение. “Родной” механизм транспортировки данных Flash — протокол передачи сообщений в реальном времени RTMP — устанавливает постоянные соединения с Flex Data Services без обращения к браузеру. Безопасность здесь обеспечивается средствами Flex, а значит, этот способ передачи данных априори не является безопасным, и сетевые администраторы и разработчики должны учитывать возможные отрицательные последствия применения данного механизма.

В вопросе обеспечения безопасности приложения RIA опираются на архитектуру браузера. Каждое развернутое приложение исполняется в “песочнице” (изолированной программной среде): для Dojo и GWT это JavaScript; для Flex это Flash Player. В большинстве случаев риски, связанные с информационной безопасностью, вполне осознаются, и каждый поставщик понимает, какие ограничения в этом смысле накладываются средой, в которой исполняются RIA. И хотя благоразумие диктует необходимость учитывать все угрозы для обеспечения безопасности, по мере совершенствования этих сред риски становятся все меньшими.

Меньше осознается и хуже воспринимается на интуитивном уровне воздействие RIA на сеть и на серверы. Чем дальше Web-браузеры отходят от изначальной модели работы, которая описывается парадигмой “запрос страницы — отображение страницы”, тем больше от них поступает становящихся все более дробными запросов к Web-серверам. В общем случае эта тенденция представляется положительной. Однако из-за перегрузки, связанной с маршрутизацией сообщений и ресурсов, необходимых для сбора требуемых данных, в один прекрасный момент вы можете обнаружить, что ваши серверы окажутся на гране перегрузки.

От серверов, которые были оптимизированы на сравнительно нечастую доставку больших порций данных, теперь требуется доставлять значительно меньшие наборы данных, но делать это в гораздо более высоком темпе. Даже если сетевой трафик при этом не увеличивается, число соединений с Web-сервером растет, из-за чего ненадлежащим образом настроенные серверы могут просто “выдохнуться”. Более частое извлечение данных способно также неожиданным образом повлиять на работу серверов баз данных. Начальная загрузка Web-страницы с RIA может потребовать большего объема памяти, чем стандартные Web-страницы, что также отрицательно скажется на производительности сервера и сети.

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

Еще одна область применения RIA, которая вызывает беспокойство, — это администрирование. Поскольку эта технология в отличие от традиционных Web-приложений не транспортирует данные в четкой последовательности “запрос — ответ”, то трудно замерить, сколько данных запрашивает и получает то или иное RIA-приложение. Число загрузок страниц и количество запросов больше не могут служить надежной мерой объема передаваемых данных. А ведь в отношении традиционных приложений это был ключевой критерий при определении их эффективности и коэффициента использования Web-сервера. Так что требуются другие методы измерения.

Еще одна потенциальная ловушка связана с процессом разработки. Хотя рассмотренные выше инструментарии значительно облегчают эту задачу, они не помогают формировать новый менталитет, который требуется для извлечения максимальной пользы из преимуществ RIA. Традиционные Web-приложения ориентировались на специфические концепции передачи данных, пользовательские интерфейсы и системные процессы. Технология RIA влияет на все эти аспекты на всех стадиях процесса разработки: проектирование, кодирование, тестирование и развертывание. Поскольку методы, используемые при создании RIA-приложений, еще достаточно “молодые”, то на протяжении жизненного цикла разработки будут иметь место повышенные трудозатраты и расходы. Наконец, как мы уже упоминали, рассматриваемые инструментарии не являются взаимозаменяемыми, поэтому после принятия соответствующего решения хода назад уже нет. Если вы захотите перейти на другой инструментарий, то вам придется начать работу с нуля.

Предположим, что вы хорошо разобрались во всем вышеописанном, и не потеряли решимости броситься в пучину RIA. Тогда возникает вопрос: какой из рассмотренных инструментариев лучше подходит для вашей организации? Исходя из уровня зрелости инструментария и ориентированности на внутренние интерфейсы, мы бы остановились на пакете Flex компании Adobe при условии, что он подойдет вам по стоимости, и если вы не являетесь противником фирменных решений.

Самый развитый вариант этого инструментария стоит 749 долл. в расчете на одного разработчика. Ориентированная на корпоративных пользователей версия Enterprise Edition сервера Flex Data Services 2.0 обойдется вам еще в 20 тыс. долл. в расчете на один ЦП. Бесплатные и имеющие открытый код инструментарии GWT и Dojo по сервисам обращения к данным не могут сравниться с вышеупомянутым пакетом Flex. Однако, если такие сервисы вам не нужны, или если у вас уже имеются свои собственные средства для этой цели, то непременно следует рассмотреть вопрос о применении GWT и Dojo Toolkit..





  
9 '2007
СОДЕРЖАНИЕ

бизнес

• Измеряем качество работы контакт-центра

инфраструктура

• Беспроводные ячеистые сети на пути к успеху

• Отвод тепла в ЦОДе. Анализ проектов. Часть 2

• Дедупликация данных сокращает обьемы информационных хранилищ

• Системы FSO: пропускная способность растет, цены снижаются

информационные системы

• Аутсорсинг приложений: собака та же, блохи другие

• Развитые интернет-приложения

сети связи

• Три поколения провалов в телефонии

кабельные системы

• Кабельные смазки и характеристики высокопроизводительных кабелей

• Администрирование СКС и принцип конструктивной неоднородности

• Ленточные кабели и соблюдение полярности оптических соединений

защита данных

• Хладнокровные «черви»


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх