Ералиева Б.Ш.
Таразский Государственный Университет им. М.Х. Дулати
г.Тараз, Казахстан
ЭВОЛЮЦИЯ ПОДХОДОВ К РАЗРАБОТКЕ ВЕБ-ПРИЛОЖЕНЙ НА
БАЗЕ ТЕХНОЛОГИИ JAVA
В данной статье
описывается эволюция подходов к разработке веб-приложений на базе технологии
Java с учетом современных потребностей разработчиков, разрабатываемых в
настоящее время спецификаций и программного обеспечения. Рассматриваемые
подходы представлены в основных идеях без второстепенных деталей, Общая цель-
дать существующим и будущим разработчикам веб-проектов ретроспективный обзор
рабочих инструментов и подходов. Статья рассчитана на программистов, в том
числе только знакомящихся с веб-программированием на Java, может пригодиться и
архитекторам веб-проектов.
Попробуем суммировать основные тенденции,
прослеживающийся в развитии подходов для построения веб-приложений из
приведенных примеров:
1. Везде, где требуется обмениваться данными с пользователем (главным образом,
посредством форм), прямо-таки напрашивается необходимость применения MVC;
2. Дизайнеры/верстальщики по-прежнему хотят работать не с java-кодом, а со
страницами, фрагментами, стилями (в т.ч. в WYSIWYG-редакторах);
3. В сложных веб-приложениях происходит выделение такого понятия как ресурсы
(resource-bundles, properties-files - особенно для i18n);
4. На уровне "контроллера" в веб-приложениях напрашивается поддержка
событий;
Симптомы очень напоминают другой случай, который имел
место для традиционных приложений, или "rich clients".
Язык Java
отлично подходит для быстрой разработки масштабируемых, надежных сетевых
бизнес-приложений, он универсален, переносим, обладает синтаксисом, сразу
понятным для большинства программистов, выросших на C/C++, имеет мощную
корпоративную поддержку и удобные средства локализации, доступа к базам данных
и обработки XML-документов. Java - это даже не орудие, это целый арсенал.
Вдобавок в Java изначально поддерживается Unicode. В общем, есть мнение,
что Java для означенных задач - самое оно. Мы живем во время начала широкого
распространения разнообразных тонких клиентов. Что характерно, разработчики
стандартов тоже не стоят на месте. HTML безнадежно устарел, сегодня он - не
более чем пережиток прошлого века, всего лишь один из частных выходных форматов
для мощного современного веб-приложения на основе XML. Для приема данных от
клиента пока еще приходится пользоваться HTML-формами, но уже почти разработан
новый продвинутый стандарт от W3C -XForms. В связи с
постоянным увеличением роли тонких клиентов в нашей жизни нам будет требоваться
все больше возможностей от веб-приложений. Как можно ожидать, такая ситуация
приведет к постепенному стиранию различий между "традиционными" и
веб-приложениями, а с точки зрения программиста - к структурной конвергенции
подходов и средств для их разработки. В данной статье эта тенденция
прослеживается для веб-приложений на Java.
Когда-то для веб-программистов на Java были доступны только сервлеты. Такие
объекты, которые живут в сервлет-контейнере (из обычного - Tomcat, Jetty илиResin), доступны по URI и обрабатывают запросы. Обрабатывают
быстро, так как живут в памяти. Первоначально весь динамический вывод
записывался внутрь конструкций печати в сервлетах.
Server Pages - это когда
внутри будущей веб-страницы пишется код на каком-то языке: объявляются
переменные, крутятся циклы, делаются выборки из БД и т.п. Когда к странице
обращаются, веб-сервер не посылает ее сразу, а отдает на предмет достройки
специальному обработчику (часто - модуль веб-сервера), который выполняет то,
что велено, заполняет данными, достраивает до готовой страницы и отдает назад
веб-серверу для отправки. Таким образом, подобная страница является на самом
деле шаблоном для целого семейства страниц.Страница JSP - это сервлет
навыворот : код разметки в ней можно писать безо всяких затей, а настоящий
java-код - в специальных тегах (<% ... %>). При первом обращении страница
превращается в нормальный сервлет, который (как и полагается сервлету) компилируется,
ложится в память и потом молотит запросы. Есть еще в JSP ряд полезных тегов и
страницы JSP можно подставлять одну в другую вроде достопамятного
"#include stdio.h". В один файл можно поместить шапку, в другой -
меню, в третью - контент и т.п. Самое ценное, что JSP-файлы (шаблоны страниц
или их фрагментов) можно править в WYSIWYG-редакторе, соответственно изменять
дизайн стало проще.
JSP - далеко не единственный template engine для Java. Можно использовать
шаблоны Velocity, Castor. Но JSP - это мэйнстрим, который надолго
и для постоянного использования.
Для создания действительно
управляемой системы, причем быстрого, просто необходимо добиться четкого
разделения труда между участниками процесса разработки. На самом деле дело не в
каких-то мифических дурных дизайнерах. С обособлением представления и кода
проект действительно становится проще развивать. При разумном дизайне с каждой
из этих, в общем-то, довольно разных частей легче справиться
Схема построения веб-приложения, когда за доступ к данным отвечает
разработанный под задачу набор javabeans, а все остальное берут на себя
JSP-страницы, в литературе (изначально термин появился в J2EE
Blueprints)
называется JSP Model1. Вышеупомянутые javabeans являются "моделью"
данных, с которыми работает приложение (любители паттернов скажут, что здесь
используется паттерн facade), а JSP-страницы, работающие с экземплярами этих
javabeans - "представлением", но при этом еще и производят всю
обработку.
Проект Tapestry ( Apache Tapestry) на сегодняшний
день - это наиболее известная среда веб-компонентов для Java. Несмотря на
использование Java, создатели Tapestry устроили все так, что большая часть
свойств объектов и отношений между ними задается формально, в XML-файлах, так
что вместо изучения API более важным для пользователя представляется изучение
DTD XML-спецификаций. Человеку, до сих пор работавшему с разными Server Pages,
Tapestry покажется другой планетой.
С формальной точки зрения компонент в Tapestry - это объект с набором
параметров, использующий ряд внешних ресурсов - картинки, звуковые и
видео-файлы, flash-ролики и т.п., объединяемое в Tapestry понятием
"assets". Компонент может включать в себя набор более мелких
компонент. Описание всех перечисленных составляющих (параметров, ресурсов, субкомпонент
и др.) дается разработчиком компонента в специально созданном XML-файле
спецификации компонента, обычно имеющем расширение ".jwc".
Компоненты вкладываются друг
в друга, а самые верхние компоненты вкладываются в "страницу"
(компонент высшего уровня). Как правило, каждому компоненту сопоставляется
HTML-шаблон, где с помощью помеченных элементов задаются позиции включения
компонент более низкого уровня. Для меток используется аттрибут
"jwcid" (Java web component id), а внутри помеченного элемента может
располагаться дизайнерский текст, элемент "рыбы", который будет
заменен при обработке шаблона. Например, для компонента, выводящего список
ссылок на страницы (почти как в учебнике по Tapestry). За конкретную
программную реализацию отвечает java-класс, расширяющий базовый класс
компонентов. Если компонент слишком простой и ему не нужен HTML-шаблон, базовым
классом будет AbstractComponent и в классе реализации требуется определить
метод отрисовки render(). Если компоненту требуется HTML-шаблон, базовым
классом будет BaseComponent и метод render не переопределяется.
Если от класса реализации
компонента не требуется хранить никакие переменные (или эта задача решается
через helper beans), можно вообще не создавать собственный класс, использовав
вместо него базовый. От класса реализации не требуется хранить какие-то
представления параметров: параметры компонент Tapestry - это
"трансцендентные сущности", которыми пользователь оперирует в
XML-спецификациях.
Страницы - это компоненты, с
классами реализации, HTML-шаблонами и XML-спецификациями, но без параметров,
т.к. являются самыми верхними в деревьях компонент. Зато страницы обычно имеют
много свойств (переменные в классе реализации, сопровождающиеся методами
get/set). Экземпляр страницы возникает в ответ на первый запрос этой страницы
пользователем, по обработке его обнуляет свои свойства в методе detach() и
размещается в специальном пуле до следующего (повторного) запроса любого
пользователя. На время повторного запроза экземпляр извлекается из пула,
восстанавливает переменные, участвует в обработке запроса, а потом опять
"спрыгивает" в пул, так что при малой частоте обращений к странице
всех пользователей обслуживает один ее экземпляр. Если в какой-то момент возникает
приходят дополнительные запросы, а первый экземпляр страницы временно занят,
программное окружение создает дополнительные экземпляры страниц на время
обработки этих запросов. Если к экземпляру в пуле долго не обращались, он
уничтожается.
В этой статье показано, в каком направлении
происходила и происходит эволюция подходов к разработке веб-приложений на
примере Java. Последним результатом этой эволюции являются компонентные
подходы, такие как Java Server Faces для Servlets/JSP и WebForms для ASP.Net.
Повышение сложности решаемых задач привело к сближению, конвергенции подходов,
применяемых для традиционных и веб-приложений - сегодня их можно делать
по-одинаковому, а завтра, в эру тонких клиентов, эти понятия, видимо,
перестанут существовать как отдельные, слившись в единое целое.
Список литературы
1. Хемраджани А. Гибкая разработка
приложений на Java с помощью Spring, Hibernate и Eclipse М.: Вильямс, 2008
2. Машинин Т.С.
Разработка RCP-, Web-,
Ajax-, b Android-приложений на JavaБХВ-Петербург,2013 год, 384 стр.
3. Монахов
В.В.
Материалы курсов, разработанных в рамках программы Sun Microsystems Teaching
Grants в 2006 году «Язык программирования Java». СПбГУ, 2006