Linuxformat - Вклад участника [ru]

LXF95:Что за штука

2009-02-06T06:43:32Z

Dionysius:

<div style="text-align: justify;">    '''''Пол Хадсон''' проливает свет на новое зелье от Sun, соперника интерактивных web-приложений Flash, Ajax и Silverlight...''

'''В позапрошлом номере на этих страницах был D. Месяц назад – E. Думаете, мне охота слушать о языках программирования три месяца подряд? Я уж лучше пойду…'''
<br><br>
Нет, нет – погодите! Не захлопывайте страницу!
<br><br>
'''Что?'''<br><br>
Никакого программирования.
<br><br>
'''Ладно, у вас пять минут для того, чтобы заинтересовать меня. Время пошло.'''
<br><br>
Хорошо: JavaFX – новая крутая платформа от Sun для создания полноценных Интернет-приложений, конкурент Ajax. Это, кстати, та самая приправа, которой Google Mail обязан интеллектом. Ajax базируется на JavaScript, и это порождает целый спектр проблем совместимости с браузерами. Например, Google Docs прекрасно обрабатываются Firefox, но отказываются работать на Safari. Если вы пользователь Opera, то, как я слышал, OpenOffice.org хорош для редактирования документов. Но даже на Firefox Ajax не станет работать ни минуты, пока вы в оффлайне.
<br><br>
'''Значит JavaFX призван заменить Ajax?'''<br><br>
Я ещё не закончил. На ряду с Ajax для строительства привелекательных web-приложений всё шире применяется технология Flash от Adobe, но, хотя он и работает оффлайн, Flash Player – все-таки не открытое ПО. Возникают проблемы, если у вас неподдерживаемое оборудование, или вам некогда ждать, пока Adobe наконец выпустит новую версию для Linux. И, конечно, если вы идейный противник проприетарного ПО, Flash тоже не для вас.
<br><br>
'''Подождите – так JavaFX заменит и Ajax, и Flash? Как бы не откусить больше, чем можешь прожевать…'''
<br><br>
Вот тут в дело вступает часть ‘Java’ от ‘JavaFX’: тут все основано на Java-платформе, то есть вся функциональность уже готова – Sun лишь надстраивает немного сверху. Например, есть Java 2D – библиотека, задуманная для высокоскоростной отрисовки графики, и она превосходна для создания блестящих графических интерфейсов. JavaFX располагает также всеми сетевыми и XML-библиотеками, необходимыми для отправки и получения данных по проводам, а также их кэширования оффлайн. Фактически, онлайн-приложения работают и в оффлайн-режиме.
<br><br>
'''Значит, экономится трафик?'''
<br><br>
Ну, объем передаваемого кода прежний, а браузер кэширует столько JavaScript, сколько можно, так что особой экономии ждать не приходится. Но JavaFX имеет определенные преимущества в вопросах безопасности, так как весь код исполняется внутри сверхбезопасной «песочницы» Java. Даже если у самого браузера проблемы с безопасностью, Java сохранит данные в неприкосновенности.
<br><br>
'''Значит, JavaFX работает оффлайн, поддерживается многими браузерами, да еще и безопаснее. Мне начинает нравиться.'''
<br><br>
Я ж говорил, это здорово! На самом деле, предлагается много больше. Помните старый слоган Java: «Написано однажды, работает везде»?
<br><br>
'''Мне помнится, было немного иначе: «Написано однажды, ломается везде».'''
<br><br>
Не спорю, раньше так и было. Но ведь Java с тех пор здорово усовершенствована, а это значит, что JavaFX будет работать на любом Java-совместимом устройстве. Да-да, и на вашем мобильном телефоне тоже. JavaScript очень медленно обрабатывается, потому и Google Doc на мобильных устройствах с их слабыми процессорами идут со скрипом, да и то если у браузера есть все необходимые средства для обработки JavaScript!
<br><br>
'''Но ведь и Java не из скороходов…'''
<br><br>
Напротив – язык Java для телефонов и других мобильных устройств существенно оптимизирован с целью извлечь максимум возможного из весьма ограниченных ресурсов. На телефонах не только слабые процессоры, но и весьма ограниченные объемы оперативной памяти, поэтому оптимизация Java пришлась как нельзя кстати – не нужны никакие хаки и прочая заумь, с помощью которых Ajax-приложения пытаются заставить работать на настольных ПК: все-таки Java – хорошо изученная платформа. Слой JavaFX просто ставится поверх виртуальной Java-машины (как на настольном ПК, так и на мобильнике), а это означает, что любой компьютер, инсталлировавший тонкий слой JavaFX, способен пользоваться подлинно кроссплатформенными JavaFX-приложениями.
<br><br>
'''А не выйдет ли так, что использование Java затруднит изучение JavaFX рядовыми программистами?'''
<br><br>
Это вполне могло случиться, если бы Sun одновременно не представила JavaFX Script.
<br><br>
'''Это что-то вроде JavaScript?'''
<br><br>
Не забывайте о том, что JavaScript – всего лишь претендент на трон Java. JavaScript не имеет ничего общего с Java, он даже изобретен не в Sun! JavaFX Script – который, будучи ядром JavaFX, вполне может называться просто «JavaFX» – тоже совершенно не похож на Java. JavaFX Script предназначен для упрощенного создания пользовательских интерфейсов с Java-библиотеками Swing, но он обладает полным доступом к основным библиотекам Java, если в том возникает потребность.
<br><br>
'''Мне смутно вспоминается что-то из прошлых лет. Grove? Groove?'''
<br><br>
Верно. Вы вспомнили Groovy, мы об этом писали в LXF67. Конечно, между Groovy и JavaFX есть определенное сходство, но JavaFX предназначен для создания web-приложений, и инструментарий у него соответствующий. Groovy был более общим, то есть недостающую функциональность нужно было достраивать самому.
<br><br>
'''Понимаю, как это нудно. Как же Sun умудрилась так быстро все обстряпать?'''
<br><br>
На самом деле проект разрабатывался довольно долго, под условным названием F3 (Form Follows Function). Недавно Microsoft представила нечто очень похожее на JavaFX, под названием Silverlight. В Microsoft-варианте в web-браузер встраивается .NET вместе с графическим холстом, поэтому можно писать код на C# или JavaScript и получать примерно те же вещи, что с JavaFX.
<br><br>
'''Подождите, зачем тогда JavaFX?'''
<br><br>
Видите ли, несмотря на все наши надежды, Microsoft не сделала ощутимого поворота в своей политике по открытому ПО, а Sun уже открыла общедоступный сайт, на котором выложила GPL-лицензированный код JavaFX. Разработчики Mono тоже ухватились за идею Silverlight и начали работу над свободным клоном на основе Mono и Cairo. Но все это – дело будущего, а JavaFX есть уже здесь и сейчас, хотя и в альфа-версии, и образцы его кода уже можно «потрогать руками».
<br><br>
'''То есть, JavaFX можно попробовать прямо сейчас?'''
<br><br>
Конечно! Sun выпустила даже JavaFX Mobile, встраиваемый в мобильные операционные платформы на основе Linux. На выходе и другие продукты семейства JavaFX, но в наличии пока только JavaFX Mobile и JavaFX Script. В настоящее время код довольно сырой, поэтому не ждите от него чудес – но с помощью JavaFX уже можно строить и связывать между собой интерфейсы Swing.
<br><br>
'''Советуете немного подождать?'''
<br><br>
Наоборот, я рекомендовал бы включиться прямо сейчас, ведь первозданное состояние JavaFX позволяет вылепить из него все, что угодно, и на этой стадии ваши подсказки и пожелания очень бы пригодились.
<br><br>
'''Вы убедили меня как минимум загрузить и попробовать JavaFX. Назовите, пожалуйста, несколько URL, пока я в теме…'''
<br><br>
Вот они: домашняя страница JavaFX [http://www.sun.com/software/javafx], там вы найдёте ссылки на информацию, пресс-релизы и прочие маркетинговые детали. Если вы действительно решили ознакомиться с образцами кода, демо и руководствами, то вам сюда: [http://www.openjfx.dev.java.net], это домашняя страница кода. Полезно посетить и такую страничку: [http://www.blogs.sun.com/chrisoliver] – блог того парня, который создал F3 и довел его до JavaFX. Там находится немало примеров кода, готовых к работе. Удачи вам! ''LXF''</div>

LXF80:Seapine Surround SCM 4.1

2009-02-06T06:42:58Z

Dionysius: /* Большая разница */

Система управления версиями

== Seapine Surround SCM 4.1 ==

''Кажется, кто-то забыл сделать check-in нововведений в этом выпуске, подозревает '''Пол Хадсон'''.''

{{Врезка
|Заголовок = '''Самое главное'''
|Содержание = Проприетарная система управления версиями с приятным GUI. Аналоги:
''Subversion'', ''BitKeeper'', ''Bazaar-NG''.
*'''Разработчик''': Seapine
*'''Сайт''': www.seapine.co.uk
*'''Цена''': 395 фунтов стерлингов за именную или 995 за плавающую лицензию
|Ширина=300px}}

SourceForge недавно перешла от CVS к ''Subversion ''для управления своим репозитарием исходных текстов. Этот шаг сделал ''Subversion н''омером один среди систем управления версиями. Конечно, есть другие системы: B''itKeeper ''сохранил популярность даже после фиаско с ядром Linux; новичок ''BazaarNG ''уже задействован в нескольких проектах; и конечно же, проект Git, детище команды разработчиков ядра, достиг зрелого состояния.

{{Врезка
|Заголовок= '''ЗАЧЕМ НУЖЕН SUBVERSION?'''
|Содержание= Subversion использует особую систему транзакций: файлы, которые выгружаются в репозитарий, недоступны другим пользователям до тех пор, пока не будут зафиксированы изменения в последнем из них. Например, мы фиксируем три файла, а в это время кто-то другой пытается получить доступ к одному из них — тогда Subversion отправит ему старую версию файла без внесенных нами изменений. Таким образом обеспечивается целостность проекта, независимо от числа разработчиков и их месторасположения.
|Ширина=300px}}

Однако рынок систем контроля версий не ограничен одними открытыми программами, о которых мы слышим каждый день. Мы следим за развитием проприетарной системы контроля версий ''Seapine Surround SCM ''с ее первого выпуска: многообещающее приложение, которое было бы превосходным, если бы разработчики добавили в него пару ключевых возможностей, расцвело в... опять-таки многообещающее приложение, которому не хватает все тех же возможностей.

=== Большая разница ===
Последний раз мы обсуждали ''Surround SCM ''версии 3.0 в ''LXF61''. С тех пор было добавлено несколько интересных возможностей, включая поддержку WebDAV (чтение и запись репозитория через webсервер), поддержка Unicode и усиленная интеграция с различными IDE. Особенно хороша поддержка WebDAV, так как Windows, Mac OS X и Linux могут читать и осуществлять запись на серверы WebDAV, что во многих случаях устраняет необходимость устанавливать ''Surround''-клиент.

[[Изображение:Img_80_14_1.jpg|frame| ]]

Поддержка IDE пригодится вам лишь в случае, если ваша среда поддерживается программой. В список поддерживаемых IDE входят ''Visual Studio'', ''Dreamweaver, WebSphere'', ''CodeWarrior'', ''IntelliJ IDEA, JBuilder ''и ''Eclipse'', из которых для нас важнее всего последние две, потому что они и в самом деле являются интегрированными средами разработки – мы любим, когда все наши инструменты доступны из одного приложения.

=== Провал Seapine ===
Новые возможности неплохи, но как насчет старых проблем? Для начала, ''Surround SCM ''все еще поддерживает атомарность выгрузки в репозитарий отдельных файлов, но не задания в целом, так что ктото другой вполне может загрузить некорректную версию ПО, пока вы фиксируете свои изменения. (''см. врезку Зачем нужен Subversion?)''

{{Врезка
|Заголовок= '''Вердикт Linux Format'''
|Содержание= * Функциональность 9/10
* Возможности 5/10
* Простота использования 6/10
* Скорость 4/10
* Оправданность цены 1/10
* Рейтинг 4/10
То, что оно работает под Linux, еще не повод его использовать
|Ширина=200px}}

''П''рограмма продолжает игнорировать потребность в работе без подключения к сети: постоянное общение с сервером идет даже при выполнении простейших операций. Например, если вы хотите зафиксировать несколько файлов, причем изменения произошли только в малой их части, то S''urround SCM ''будет неэффективно использовать ваш канал: перекинет все файлы на сервер, а потом заявит, что в большинстве файлов изменений нет. Реализации примитивнее и придумать нельзя, поэтому вы вправе удивляться, чего ради надо приплачивать к 395 фунтам за честь ею попользоваться.

Кстати о цене. Да, программа стоит 395 фунтов. Прибавьте к этому НДС, а также обязательный единовременный платеж в виде 20% от цены за дальнейшие обновления и поддержку, и все это только за именную лицензию (то есть выданную конкретному разработчику). Если хотите плавающую лицензию, то готовьте 995 фунтов + НДС + единовременный платеж. Для сравнения, пользователям Windows две полных копии ''Microsoft Visual Studio 2005 ''обойдутся дешевле, чем одна копия ''Seapine Surround ''с именной лицензией – причем у MS не самые низкие цены.

''Surround SCM ''имеет приятный пользовательский интерфейс, но ничего более.

Однако новизна GUI меркнет, как только вы осознаете, что никому не нужно отдельное приложение для задач, которые и без того выполняются в вашей IDE: ''Eclipse'', например, уже имеет первоклассную систему S''ubversion''. Во времена, когда царил ''CVS, Surround ''явно тянулась в лидеры. Но с приходом ''Subversion ''остался единственный выбор, и это не ''Seapine Surround''.

LXF87-88:Безопасность

2009-02-06T06:42:21Z

Dionysius: /* Настроим индивидуальные фильтры */

{{цикл/Безопасность}}

== Строим межсетевой экран на базе Linux ==
''ЧАСТЬ 4 Любой подключенный к сети компьютер открыт для атаки. Д-р '''Крис Браун''' научит, как уменьшить вашу уязвимость, создав заслон при помощи стандартных утилит Linux.''

В речи по поводу Дюнкеркской эвакуации, перед тем, как сказать
«Мы будем сражаться на пляжах», Уинстон Черчилль изрек
«Мы защитим наш остров любой ценой». Компьютеры — наши
прекрасные маленькие островки, но они всегда находятся под обстрелом, о чем свидетельствуют журналы любого Linux-сервера, имеющего
внешний IP-адрес.

Межсетевые экраны (брандмауэры) — один из наиболее важных
рубежей обороны вашего компьютера. Это сетевые устройства (как
аппаратные, так и программные, запускаемые на обычном компьютере), контролирующие трафик между внутренней сетью и Интернетом.
Есть несколько технологий создания таких экранов. Например, запросы от клиента по протоколам прикладного уровня (HTTP, FTP или
DNS) перенаправляются через прокси-сервер; таким образом, прямое
соединение между узлом локальной сети и Интернетом становится
ненужным. Трансляция сетевых адресов (NAT или маскарадинг) также
делает вашу сеть невидимой снаружи, позволяя еще и использовать
свой диапазон адресов внутри сети. Однако наш сегодняшний урок
посвящен классическому пакетному фильтру, работающему на сетевом уровне (IP). Я покажу вам, как настроить его в Linux.

=== Часть 1: Разбираем iptables ===
[[Изображение:Img 87-88 60 2.png|250px|thumb|Рис. 1. Три стандартных цепочки позволяют фильтровать входящие, исходящие и проходящие пакеты.]]
В недрах ядра скрывается кусок кода под названием netfilter (сетевой
фильтр) — он выполняет фильтрацию IP-пакетов: проверяет каждый
исходящий и входящий пакет и решает его судьбу, основываясь на
его параметрах, таких, как исходные и конечные адреса и порты или
флаги заголовка TCP.

Два главных действия, выполняемых netfilter — принять пакет
или, соответственно, отклонить его. Он также может вести журнал с
помощью сервиса syslogd. Используя netfilter, можно настроить Linux-машину как межсетевой экран с фильтрацией пакетов.

Обычно в роли межсетевого экрана выступает машина, работающая
между внутренней сетью предприятия и большим и злым Интернетом
и защищающая данные корпоративных компьютеров от взломщиков,
коварных скриптописцев и вирусов. В данном случае фильтрация применяется к пакетам, приходящим извне и переправляемым во внутреннюю сеть. Можно также фильтровать пакеты, идущие на межсетевой
экран изнутри или исходящие из него; то есть использовать netfilter как
персональный брандмауэр, пригодный даже для одиночной домашней
машины, подключенной к сети через ADSL или модем.

Netfilter настраивается с помощью специальных правил, задаваемых из консоли командой iptables. Ее синтаксис — полноценный язык
со своими правилами. Типичное правило включает в себя компоненты
для распознавания определенных пакетов и заканчивается директивой
принятия или отклонения подобного пакета. Вот пример того, как это
выглядит:
<pre>iptables -A INPUT -i eth0 -p udp -s $NAMESERVER --sport 53 -d 140.116.5.1 --dport 53 -J ACCEPT</pre>
Чтобы разобраться в этом, нужно представить, какими путями пакеты приходят, проходят и уходят с вашей машины. Есть три варианта,
показанные на рис. 1. Входящий пакет проверяется пакетным фильтром, и следует его решению. Если адрес доставки пакета соответствует данной машине, пакет проходит через входную цепочку (Input) и
идет вверх по стеку протоколов. Если пакет предназначен для другой
машины, реализация протокола сетевого уровня опрашивает таблицу
маршрутизации, чтобы узнать, на какой сетевой интерфейс его отправить. Затем он идет по цепочке Forward и возвращается в сеть. Наконец,
пакеты, формируемые на данной машине, проходят через выходную
цепочку (Output) и попадают в сеть. Каждая из этих цепочек, в сущности, является простым набором условий, через проверку которых и
проходит пакет.

{{Врезка|center|
|Заголовок=Зачем вам брандмауэр?
|Содержание=Интернет, увы, становится враждебным окружением, к которому уже
нельзя подключаться непосредственно, без брандмауэра (он же
firewall). Однако домашние пользователи с широкополосным доступом должны различать две вещи. Если ADSL-модем воткнут в вашу
машину напрямую (ну, или через USB), то у нее есть реальный IP-адрес, к которому можно подключиться извне, и она нуждается в
защите.

А если вы подключаетесь к внешнему ADSL-модему через Ethernet,
то в такой модем уже встроен маршрутизатор, выполняющий преобразование адресов (Network address translation – NAT). Большое преимущество NAT состоит в том, что машинам из внешнего мира запрещено подключение к внутренним – т.е. к вашей домашней машине [по
такому принципу работают многие российские интернет-провайдеры,
однако, имейте в виду, что в этом случае ваши соседи по сегменту также потенциально опасны – кое-кто из них, например, не побрезгует
воспользоваться «дырой» в чужой системе, чтобы посидеть в
Интернете за ваш счет, – прим. ред.].
|Ширина=}}

==== Настроим индивидуальные фильтры ====
{{Врезка
|Заголовок=Скорая помощь
|Содержание=Будьте осторожны,
когда настраиваете
брандмауэр на
машине, к которой у
вас нет физического доступа. Очень
легко заблокировать все входящие
соединения, задавая
политику по умолчанию: вы и охнуть не
успеете. Верьте мне!
Я уже пробовал…
|Ширина=150px}}
Теперь вы понимаете, что в примере выше мы добавляем правило во
входную цепочку (-A INPUT). Условие гласит, что пакет должен придти
на сетевой интерфейс eth0, и это должен быть UDP-пакет. Оно также
указывает исходные адрес и порт, а также адрес и порт назначения,
которым должен соответствовать пакет. Эта информация передается
в заголовке пакета. Завершающая часть (-J ACCEPT) говорит netfilter,
что делать с тем пакетом, который соответствует всем указанным в
правиле параметрам. Эта часть называется целью условия. Возможные
цели таковы:
* ACCEPT — принять пакет;
* DROP — молча отклонить пакет;
* REJECT — отклонить пакет и сказать об этом отправителю;
* LOG — записать прибытие пакета (и позволить ему пройти к следующему условию).
Списки условий для цепочки могут быть весьма длинными: 50 — обычнейшее количество. Для каждого пакета проверяется каждое
условие. Как только произойдет совпадение, будет предпринято соответствующее решение (цель), и следующие условия проверяться уже не
будут. Если пакет доходит до конца цепочки, не удовлетворив ни одному условию, его судьба зависит от «политики» цепочки. Например,
<pre>iptables -P INPUT DROP</pre>
говорит, что все такие пакеты будут отклонены. Простейший способ
создания набора условий — установить политику по умолчанию в DROP,
а затем добавлять условия для нужных пакетов. Это подход с «презумпцией виновности». Другой подход (установка политики по умолчанию в ACCEPT, а затем создание правил для блокировки ненужных
пакетов) гораздо сложнее, менее безопасен и не рекомендуется.
Вы можете улучшить организацию ваших правил, определив собственные цепочки и присвоив им имена. Например, я могу определить
цепочки TCP_RULES и UDP_RULES. Затем, в главной входной цепочке
я могу задать всего два предопределенных правила:
<pre>iptables -A INPUT -p tcp -J TCP_RULES
iptables -A INPUT -p udp -J UDP_RULES</pre>
Это позволяет более гибко управлять наборами правил, да и более
эффективно; например, UDP-пакет никогда не будет сравниваться
с правилами из цепочки TCP_RULES. Я предпочитаю думать, что прыжки по цепочке аналогичны проходам по процедурам (подпрограммам).

Механизм «попакетной» проверки IP-трафика — лишь половина
умений iptables. Возможно еще записывать, когда происходит TCP или
UDP-транзакция, и проверять пакеты не только по их заголовкам, но и
в контексте совершаемого соединения… Борюсь с искушением вдаться
в подробности, иначе урок разросся бы до размеров журнала.

Можно настроить межсетевой экран путем создания полного набора правил и команды iptables, как было показано. Начните с политики
безопасности, определяющей, какие сервисы должны быть доступны,
вычислите, какой трафик они генерируют, поместите соответствующие
правила в цепочки, а все остальное запретите. Все это требует отличного знания TCP/IP и большой внимательности. Построение межсетевого экрана таким способом аналогично созданию большого web-сайта путем ручной верстки в vi или написанию программ на Ассемблере.
Другими словами, это лучше оставить экспертам, которым нужен полный контроль над каждой настройкой.

Но если вы все-таки решите дерзнуть, ознакомьтесь с материалом
по iptables из LXF47. Мы положили его на диск в формате PDF.

=== Часть 2: Простой путь ===
{{Врезка
|Заголовок=Скорая помощь
|Содержание=Рискуя быть
навязчивым,
я хочу подчеркнуть
важность политики
безопасности.
Пока вы не сядете
и не зададитесь
вопросом «Кто
и что может делать
с моей машиной?»,
вы не готовы
настраивать правила межсетевого
экрана, отключать
ненужные сервисы
и повышать
безопасность
компьютера.
|Ширина=150px}}
Я показал вам продвинутый путь настройки межсетевого экрана, однако большинство из нас (включая меня), возможно, предпочтут использование утилиты, которая позволит указать политику безопасности на
более высоком уровне и сгенерирует команды iptables сама. А потом их
можно будет подредактировать, как описано в первой части.

[[Изображение:Img 87-88 62 2.png|400px|left|thumb|Рис. 2. Межсетевой экран с тремя интерфейсами защищает DMZ и внутреннюю сеть от внешнего мира. Для каждой сети можно выбрать свой уровень фильтрации.]]
Мне нравится модуль конфигурации брандмауэра YaST в SUSE.
Он позволит вам настроить брандмауэр примерно на том же уровне,
на котором вы задаете политику безопасности, в противоположность
уже рассмотренному нудному процессу ручного ввода команд. Модуль
требует указать для каждого сетевого интерфейса три зоны: внешнюю,
внутреннюю или демилитаризованную. Эти термины иллюстрируются
рис. 2, где показана архитектура классического межсетевого экрана в
корпоративной сети.

Внешние интерфейсы — те, что подключены к огромному злому Интернету; в домашних условиях это обычно ADSL или простой
модем. Если у вас всего одна машина, ваш сетевой интерфейс будет
внешним.

Внутренние сетевые интерфейсы — те, что подключены к доверенным узлам. В небольшом офисе, где как шлюз используется Linux-машина, это будет интерфейс, подключенный к локальной сети.

Демилитаризованная зона (DMZ) — это сеть, в которой находятся видимые снаружи машины, например, Web/FTP/почтовые-серверы. Сказать по правде, если вы настраиваете межсетевой экран для
использования в корпоративной среде с DMZ, вы обязаны изучить
более глубокие материалы по данной тематике. Тот же модуль YaST, к
примеру, недостаточно гибок для настройки направления пакетов между внутренней сетью и DMZ; он всего лишь определяет правила ограничения доступа к машине из всех трех зон.

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

[[Изображение:Img 87-88 62 1.png|thumb|Рис. 3 Модуль YaST для настройки брандмауэра. Здесь указывается, какие сервисы доступны в каждой из трех зон.]]
Определив, какие сетевые интерфейсы соответствуют нужным
зонам, переходите на экран доступных сервисов для каждой из зон
(рис. 3). Слева вы видите перечень семи экранов модуля YaST, справа — выпадающие списки зон и сервисов (DNS, IMAP, HTTP и т. д.).
Выберите зону и определите доступные ей сервисы.

Для разрешения доступа к сервису, выберите его из списка и
нажмите Add (Добавить). Чтобы запретить сервис, выделите его и
нажмите Remove (Удалить). Для сервисов, которых нет в списке,
вы должны будете указать номер порта. Например, для разрешения
Telnet-сеансов (возможно, вы захотите разрешить их только для внутренней сети, поскольку Telnet небезопасен) нажмите на Advanced… и
введите номер порта (23) в поле TCP Ports. Внутренняя зона должна обрабатываться по-особому. Внизу вы найдете флажок Protect
Firewall From Internal Zone. Пока он не отмечен, к пакетам, исходящим
из внутренней сети, не будут применяться никакие правила.

==== За кулисами ====
{{Врезка|left|
|Заголовок=Скорая помощь
|Содержание=Сканер портов,
типа Nmap,
рассмотренного
на прошлом
уроке — отличная
утилита для проверки корректной
работы правил вашего межсетевого
экрана.
|Ширина=150px}}
Модуль YaST не генерирует правила iptables напрямую. Вместо этого
он редактирует файл /etc/sysconfig/SuSEfirewall2. Если у вас SUSE,
рекомендую изучить этот файл. Он очень хорошо прокомментирован и
углубит ваше понимание действий YaST, а также предоставит синтаксически более сложные примеры.

Сам межсетевой экран настраивается на
раннем этапе загрузки через два скрипта,
SuSEfirewall2_init и SuSEfirewall2_setup, находящиеся в директории /etc/init.d. Первый
запирает брандмауэр (пропуская только трафик bootp и ping), а второй, запускающийся
несколько позже, устанавливает цепочки правил при включении брандмауэра и очищает
их при отключении. Оба скрипта в конечном
итоге вызывают /sbin/SuSEfirewall2: это движок механизма межсетевого экрана в SUSE, и
в нем генерируются команды iptables. Я бы не
рекомендовал вам в нем копаться (особенно
после плотного обеда), если вы не любитель
скриптоужастиков.

==== Брандмауэр Fedora ====
{{Врезка
|Заголовок=Скорая помощь
|Содержание=Если вы столкнетесь с проблемами,
заставляя какой-либо сетевой
сервис работать,
стоит проверить,
не стоит ли на его
пути netfilter. Мне
случалось потерять
много времени,
прежде чем я обнаруживал, что все
дело в брандмауэре. Его отключение
(ненадолго!) значительно упростит
настройку.
|Ширина=150px}}
[[Изображение:Img 87-88 63 1.jpg|thumb|Рис. 4 Утилита настройки брандмауэра в Fedora сгодится при создании личного брандмауэра, но не более того.]]
Не только в SUSE есть графические утилиты
для настройки брандмауэра. На рис. 4 показана утилита system-config-securitylevel, входящая в Fedora. Это более простой инструмент,
чем модуль YaST. Она не позволяет определять
зоны, а просто закрывает и открывает нужные
порты, и подходит только для настройки личного брандмауэра на одиночной машине.

[[Изображение:Img 87-88 63 2.png|thumb|Рис. 5 Просмотр действующих правил командой iptables-save. Если сохранить их в файле, можно будет их восстановить командой iptables-restore.]]
Вы можете просмотреть ваши правила, выполнив команду iptablessave
(ее вывод показан на рис. 5). Здесь вы видите пример определенной пользователем цепочки (RH-Firewall-1-INPUT), устанавливающей
правила как для входящей, так и для исходящей цепочек. Если сохранить вывод iptables-save в файле, из него можно будет восстановить
правила командой iptables-restore.

Netfilter имеет и другие возможности (например, NAT и фильтрацию
по состояниям), я о них успел только намекнуть. Есть и другие методы,
например, прокси-серверы уровня приложений, они тоже полезны при
настройке межсетевого экрана.

{{Врезка|center|
|Заголовок=Предотвращение скрытого сканирования
|Содержание=В прошлом месяце я рассказывал о скрытом сканировании с помощью Nmap. Этот вид сканирования использует нештатные комбинации флагов TCP-пакетов, а скрытым называется, поскольку маловероятно, что системный журнал его зафиксирует. Однако, используя
способность netfilter проверять флаги в заголовке TCP-пакета и
записывать события в журнал, можно не только блокировать подобные попытки, но и регистрировать факт их наличия. Подробности
довольно запутанны, но пример пары правил против FIN-сканирования прояснит суть этой идеи:
<pre>iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j LOG --log-prefix "Stealth scan"
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP</pre>
Первое правило служит для обязательной записи события в журнал. После цели LOG пакет продолжает движение по цепочке условий (в отличие от целей DROP и ACCEPT. Принятые или отклоненные
пакеты на дальнейшую проверку не пойдут). В данном случае пакет,
удовлетворяющий первому условию, удовлетворит и второму,
согласно которому он будет отклонен. Параметры --tcp-flags ACK,FIN
FIN описывают комбинацию TCP-флагов. Первый список состояний
(ACK,FIN) перечисляет тестируемые флаги, второй (FIN) – те из них,
что установлены. Таким образом, условие соответствует тем пакетам, в которых есть FIN-флаг, но нет ACK. При нормальном TCP-соединении эта комбинация невозможна, зато типична для скрытого
сканирования.

Проведите эксперимент: если у вас две Linux-системы, выберите
одну из них мишенью, а на второй запустите нечто вроде
<pre>nmap -sF -p1-50 192.168.0.3</pre>
(подставьте нужный IP-адрес). Nmap сообщит вам об открытых портах. Если вы проследите судьбу пакетов через Ethereal, то увидите,
что FIN-пакеты достигли цели, а в ответ были отправлены пакеты
RST,ACK. Теперь добавьте на системе-мишени два правила, показанных выше, и повторите попытку. Вы увидите, что Nmap больше не
обнаруживает открытые порты, а в журнале (у меня это /var/log/firewall) появились новые сообщения. Ethereal покажет, что FIN-пакеты по-прежнему доходят, но не получают ответа. На подобных экспериментах можно научиться многому. Вот вам развлечение для
дождливого вечера!
|Ширина=}}

{{Врезка|center|
|Заголовок=Рекомендуется прочесть
|Содержание=Лучшая книга по брандмауэрам в Linux, конечно же, Linux Firewalls Стива Сьюринга [Steve
Sturing] и Роберта Циглера [Robert Ziegler], третье издание (и, будете смеяться, третий издатель,
Novell Press). Эта книга не только подробнейше описывает использование iptables, но и рассматривает внутреннюю защиту, SELinux и мониторинг сети.
|Ширина=}}

LXF92:Rosegarden

2009-02-06T06:39:25Z

Dionysius: /* Мутная аудиоконверсия */

__TOC__

= Rosegarden 1.5 =

''Система нумерации версий более разумная, кодовая база переработана, но розы-то в этом саду остались? '''Грэм Моррисон''' принюхивается.''

{{Врезка|left|
Заголовок = Вкратце… |
Содержание = MIDI- и аудиосеквенсор с поддержкой программного синтезатора и эффектов реального времени. См. также: ''Ardour'' и ''Muse''. |
Ширина=250px}}

За два года, прошедшие со времени выхода последней версии Rosegarden (почему-то названной версией 4), разработчики хорошо потрудились над добавлением функций и оптимизацией кода. Заодно они создали Fervent Software и выпустили коммерческий Linux-дистрибутив под названием Studio To Go. Rosegarden составляет сердцевину Studio To Go, и по функциональности это
открытое приложение ближе всего подходит к уровню программ, используемых мировыми лидерами звукозаписи: Steinberg Cubase, Logic Pro от Apple и Digital Performer от MOTU.

Rosegarden использует окно аранжировки: вертикальные дорожки, содержащие аудио- или MIDI-данные, располагаются слева, а сегменты данных каждой дорожки растягиваются вправо. Каждая дорожка обычно – отдельный инструмент или запись, а каждый сегмент – музыкальный фрагмент. Окном аранжировки оно называется потому, что в нем можно свободно перетаскивать блоки влево и вправо по времени, вверх и вниз между инструментами, эффективно меняя «аранжировку» музыкального фрагмента. Cubase, Logic и Digital Performer встраивают в такое окно функции правки, позволяющие редактировать MIDI-ноты и менять громкость фрагментов. Rosegarden этого не умеет (пока), но в новой версии переключение между дорожками и управление инструментами значительно упростилось.
[[Изображение:Img_92_13_2.jpg|left|thumb|Интерфейс Rosegarden]]

Особенно впечатляет программный синтезатор. Мы впервые видим DSSI-инструменты, так хорошо интегрированные в музыкальное
приложение для Linux. Избранные инструменты и настройки хранятся вместе с проектом, поэтому обмениваться материалами с
другими пользователями теперь можно без долгих переговоров о настройке Jack-соединений. Параметры инструментов устанавливаются с помощью точных органов управления, а звуковые дорожки и треки синтезатора могут использовать LADSPA-эффекты с панели параметров инструментов в реальном времени. Работа со звуком по-прежнему перекладывается на какой-либо внешний редактор, например Audacity, но матричное отображение для редактирования MIDI-нот заметно улучшилось. Теперь работать с нотами в Rosegarden – одно удовольствие.

=== Нету розы без шипов ===
Главных дополнений два. Первое – автоматическое преобразование аудио-фрагментов. Идея такая: если есть фрагмент длиной в один такт, а его нужно растянуть на два, нажатие Ctrl с перетаскиванием границы фрагмента автоматически подгонит звук внутри фрагмента для соответствия новой продолжительности. Масштабируя фрагмент, Rosegarden перерабатывает внешним редактором (sox или sndfile-resample) весь аудиофайл. В зависимости от размеров клипа, это может занять от нескольких секунд до убийственных для производительности нескольких минут. Лучше было бы масштабировать звук только в пределах фрагмента, именно так поступают коммерческие соперники Rosegarden.

=== Мутная аудиоконверсия ===
Второе заметное дополнение – прозрачная аудиоконверсия. К несчастью, импорт звука неинтуитивен, для него нет пункта меню.
Необходимо перетащить аудиофайл в окно аранжировки, и Rosegarden запустит фоновый процесс для его конвертации с помощью внешнего скрипта. Если у вас нет подходящего инструмента – скажем, oggdec – Rosegarden безмолвно провалит импорт.

Рассматривая Rosegarden в LXF65, мы заключили, что, при всех недостатках, это лучшая аудио/секвенсорная прогамма на Linux. Теперь мы вдвойне в этом уверены, ведь некоторые из недостатков уже исправлены. Внешние звуковые редакторы и программные синтезаторы отныне выглядят «полноправными гражданами», а не примитивными дополнениями к MIDI-секвенсору. С учетом нововведений 1.5, и если разработчики сохранят прицел на интуитивность – мы ждем не дождемся версии 2.0!

=== Вердикт ===

'''Rosegarden 1.5'''

Разработчик: Chris Cannam, Richard

Сайт: www.rosegardenmusic.com

Цена: Бесплатно под GPL

* Функциональность 9/10
* Производительность 6/10
* Простота использования 7/10
* Документация 7/10

Интуитивно и достаточно гибко для мира современной музыки.

'''Рейтинг 8/10'''

[[Категория:Обзоры]]

LXF80:Libre Graphics

2009-02-06T06:38:03Z

Dionysius: /* Scribus */

== LIBRE GRAPHICS ==
Adobe, Corel, Quark и другим стоит оглянуться – свободное программное обеспечение вот-вот догонит их продукцию. Ник Вейч посетил первую конференцию Libre Graphics, знаковое событие для всего мира open source.

Linux. У большинства людей это слово ассоциируется с безумно высокотехнологичным миром Интернета. В голову немедля приходят образы «лезвийных» серверов, кластеров, Apache и потоков кода. И пингвины. В конце девяностых доминирование свободного ПО среди технологий, определяющих развитие Интернета, стало почти неизбежным – не только Linux, но весь массив технологий, обеспечивающих развитие сети, полагается на открытый код и открытые стандарты.

Но Linux – вовсе не платформа, ориентированная всего на одну задачу, и вводная конференция Libre Graphics, проходившая на юге Франции, в Лионе, в школе Superieur Chimie Physique Electronique (CPE), это отчётливо продемонстрировала.

Организовал конференцию разработчик Gimp Дейв Нири (Dave Neary). Он затевал просто встречу с другими Gimp-программистами, но конференция довольно быстро переросла в рассмотрение графических инструментов вообще – разработчики других проектов ухватились за возможность повидать коллег, обменяться идеями и обсудить общие проблемы.

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

'''Прорыв'''

Хотя полезным было все, неформальное общение посетителей между заседаниями, вероятно, в наибольшей степени способствовало успеху. В коридорах, во время перекуров на улице, в обед и, конечно же, за ужином шли разговоры об углублении сотрудничества, объединении знаний и ресурсов для решения общих проблем, обмен дружескими советами в диапазоне от того, какие библиотеки использовать, до эффективных приёмов работы.

Впрочем, это был не просто «слёт умников»: многие из представленных проектов – действительно серьёзные графических инструменты. И большинство из них – кроссплатформенные: Inkscape, Gimp, Scribus, Blender… Далее мы подробнее рассмотрим некоторые из этих приложений, продвигающих Open Source как выбор для профессиональной графики и дизайна. Сложившийся рынок принадлежит таким фирмам, как Adobe, но молодёжь, несомненно, наступает на пятки. И вполне возможно, когда-нибудь, в не столь далёком будущем, эта конференция будет рассматриваться как поворотная точка, когда графические инструменты с открытым кодом стали взрослыми…
----
'''''LinuxFormat:''' ''Итак, почему вы организовали LGM?

'''Дейв Нири (ДН)''': Ну, есть и другие конференции, но они фокусируются не на том. Это мероприятия вроде Fosdem <nowiki>[Free and Open Source Software Developers’ Meeting, </nowiki>встреча разработчиков свободного ПО, – прим. пер.], слишком общего, или Akademy <nowiki>[всемирная конференция сообщества KDE, – прим. пер.]</nowiki>. Но ''Gimp'', да и все графические приложения несколько выпадают из этого – Blender не использует GTK или Qt, а ''Gimp ''– хотя и приложение Gnome, но фактически не связан с этим проектом.

''Gimp ''используется и в KDE, Scribus работает на Gnome. Приложения, представленные здесь, кросс-платформенные – нам нужно большее, чем специализированная конференция Linux. К тому же, у графики свои причуды: мы должны думать о «людях в оранжевых очках». Люди, в которых мы заинтересованы, наши пользователи – графические дизайнеры и арт-директора, они далеки от сферы открытого ПО. Нам нужно делать что-то конкретное, чтобы «зацепить» этот сорт людей.

'''''LXF:''' ''То есть конференция задумана, чтобы убедить людей использовать открытые инструменты?

'''ДН:''' Мы преследуем две цели: первая – собрать вместе участников этих проектов и наметить наше общее будущее – согласованное направление развития для всех этих приложений.

<nowiki>Вторая – продемонстрировать открытые программы публике, которая, возможно, вообще о них не знает, людям, которые работают с графикой. Нам нужно показать, что [даже если] мы не удовлетворим все их нужды прямо сейчас, у нас есть функциональные, стабильные и многообещающие приложения. И что у нас есть сообщество вокруг этих приложений, очень дружественное. Нам нужно больше художников, вовлечённых в свободное ПО.</nowiki>

'''''LXF:''' ''Что мешает людям использовать свободные программы для серьёзной графики?

'''ДН:''' Причин несколько. Есть неписаный кодекс поведения, порой не совсем понятный. Это барьер сообщества.

Есть технологические барьеры. Есть вещи, на которые распространяется понятие «интеллектуальная собственность». Это такая штука, которая мне ненавистна, но под действие авторских прав, торговых марок, патентов много чего подпадает. То есть вещи вроде каталога цветов Pantone, защищенного авторскими правами.

Третий барьер – рабочая сила. Кое-чего мы просто не делаем. Мы говорим о художниках – почему художники не так охотно пользуются нашими программами.Есть вещи, которые ''Gimp ''не делает, но они нужны художникам, кинопродюсерам и людям, занимающимся допечатной подготовкой.

'''''LXF:''' ''Некоторые считают, что кросс-платформенная природа этих инструментов – это плохо; что свободное ПО должно оставаться на свободной платформе.

'''ДН:''' Да, есть такие люди. Но я не из их числа. Я думаю, что наша цель – чтобы все использовали свободные программы, включая операционную систему. Тут вы можете спросить: «А не идёт ли портирование приложений GNU на Windows вразрез с этой целью?» А по-моему, будь я пользователем Windows, я не стал бы ничего менять одним махом.

Если кто-то даст мне CD с текстовым процессором, звуковым редактором, графическими инструментами и web-браузером, я могу использовать всё это в Windows и не беспокоиться об откате назад, если мне что-то не понравится. И вот вы вдруг получаете кого-то, кто использует свободные программы, но работает под Windows. Всё, что ему остаётся сделать – сменить операционную систему. Вы помогаете людям становиться на путь просвещения.

----

== Scribus ==

'''Открытая настольная издательская система становится профессиональной.'''

Во многом, Scribus – это стремительная история успеха открытого графического инструмента. Да, ''Gimp в''осхитителен, ''Inkscape о''бладает потенциалом – но ''Scribus ''поставил перед собой задачу, появившись ниоткуда, стать серьёзным, профессиональным решением для настольных издательских систем (ИС), и, следуя традиционным стандартам разработки программ, в два счёта этого достиг.

Фактически, последний выпуск ''Scribus ''(1.3.3) предоставляет возможности, превосходящие стандарты профессионального программного обеспечения для ИС, например, генерацию штрихкода без привлечения стороннего ПО. Для коммерческой ИС такое немыслимо – за пять лет пройти путь от первой строки кода до надёжного, профессионального инструмента.

'''Типы печати'''

[[Изображение:Img_80_40_3.jpg|frame|Да, Scribus умеет выполнять цветоделение, используя последние версии ghostscript]]

[[Изображение:Img_80_40_1.jpg|frame|В Scribus 1.3.3 уже есть ряд простых эффектов изображения, но будущие версии могут включить GEGL]]

Как и со всеми освещёнными здесь проектами, похоже, что выбор открытой модели разработки способствовал изрядной прозорливости ''Scribus''. Достаточно стандартная история – нужный человек оказался в нужное время в нужном месте. Везение это или нет, но команда ''Scribus с''умела собрать вокруг себя очень талантливых и компетентных людей из мира печатных изданий. S''cribus ''<nowiki>увидел свет как проект немецкого программиста-самоучки Франца Шмида [Franz Schmid]. Его первоначальная гениальная идея была создать программу вёрстки, базирующуюся на технологическом процессе PDF. Еще в 2001 году было видно, что PDF может стать </nowiki>''lingua franca ''<nowiki>[принятый язык межнационального общения, – прим. пер.] </nowiki>для печати, и так оно и вышло. Почти все крупные издательства, а также и принтеры, теперь работают преимущественно в формате PDF, который генерируется, проектируется и выводится прямо на пластины для типографии. Шмид, очевидно, прекрасно разбирался в спецификации PDF, потому что S''cribus ''выполняет фантастическую работу по генерации этих файлов –даже обрабатывает ряд интерактивных и презентационных функций, которые не используются для печати и практически не генерируются другими программами, за исключением полной версии Adobe Reader. Мы надеемся, что и LinuxFormat помог популяризации ''Scribus'', поскольку мы включали его в наш раздел HotPicks''' '''(это один из немногих проектов, фигурировавших там неоднократно, в ''LXF36'' и ''LXF50''). Однако по мере взросления программы маленький проект Шмида становился всё сложнее и запутаннее. Это само по себе привело к множеству изменений – значительную часть кода пришлось переписать или, по крайней мере, переместить. То, что имело смысл для небольшого проекта, работающего с маленькими документами, может не годиться, если пользователи намерены «отстукивать» 200-страничные книги.

'''Усложнение'''

[[Изображение:Img_80_40_2.jpg|frame|"Предстартовая" проверка означает, что от ваших PDF вам гарантирован превосходный результат ]]

С последней серией 1.3 пользователи ''Scribus ''теперь могут насладиться цветовой заливкой, управлением цветом, правильным цветоделением и т.п. В общем, ''Scribus ''вырастает в новую систему обработки текста; тут значительно увеличена скорость обновления изображений и добавлена поддержка Unicode. Полезные возможности простираются аж до назначения поднаборов глифов <nowiki>[glyph – визуальный образ символа шрифта, – прим. пер.]</nowiki>. Много народу страдало по версии ''Scribus ''для командной строки, чтобы конвертировать документы ''Scribus ''в PDF без посредства графического интерфейса, и что вы думаете? Это не такая уж далёкая перспектива!

Чувствуется, что по крайней мере в этом сегменте настольных систем программы с открытым кодом постепенно меняют позицию «как ни странно полезных» на звание профессиональных инструментов. На Libre Graphics команда продемонстрировала Le Tigre – созданную в ''Scribus ''еженедельную французскую газету, выходящую тиражом более 12 тыс. экземпляров. Она не первая и, конечно, не последняя.
----
'''ИНТЕРЬЮ LinuxFormat:'''

В чём причина успеха ''Scribus''?

'''<nowiki>Питер Линнелл [Peter Linnell] (ПЛ):</nowiki>''' Думаю, в том, что на командном уровне мы работаем очень хорошо…

'''К<nowiki>рейг Ринджер [Craig Ringer] (КР):</nowiki>''' ''Scribus ''– довольно закрытая система разработки. Есть основная команда, поддержанная добровольцами и переводчиками; некоторые добровольцы, достигшие определённого уровня профессионализма, приглашаются в команду. Отбор довольно жёсткий. Анонимный доступ к внутреннему CVS не предоставляется.

'''ПЛ:''' У нас есть внутренний CVS для команды. Насчет кода мы прямо-таки параноики. Внутренний CVS – тот, с которым мы можем экспериментировать, чтобы люди могли доверять коду, выполняя реальную работу. Мы пытаемся поддерживать систему, где «слепок» CVS всегда можно собрать и использовать. Конечно, ошибки всё равно проскальзывают, но это уже совсем другое, чем пригодность для работы вообще.

'''LXF: '''Всё-таки Scribus прошёл длинный путь за короткое время – намного быстрее многих других проектов.

ПЛ: Мы немного старше, чем обычные хакеры, работающие с открытым кодом. У Крейга значительный производственный опыт, Льюис много лет проработал в профессиональной допечатной индустрии. У нас довольно много людей, занимающихся издательской деятельностью, которые способны протестировать различные функции программы – либо пользовательский интерфейс, либо качество результата, либо цвета, либо PDF. Также у нас есть пользователи, располагающие высококачественном печатным оборудованием, и либо мы даём им файлы, либо они печатают свои собственные тесты. Это помогает нам сохранять высокий <nowiki>уровень качества. Другая причина – команда разработки очень гармонична. Требуется некоторый опыт в допечатной подготовке, чтобы знать, что делать. Например, мы не допустим, чтобы вы получили «ложный» курсив [когда буквы преобразуются в курсив на экране, вместо того чтобы использовать специально разработанную версию шрифта] – мы не допустим этого, потому что это уродство. Этого не будет. </nowiki>''Scribus ''очень прилежно относится к проверке используемых шрифтов – что они действительно присутствуют и что глифы работают.

'''LXF: '''То есть вы не терпите ошибок, по крайней мере, серьёзных? КР: Вывод PDF у нас очень надёжный. Мы исключили проблемы, приводящие к созданию плохого PDF. Если такое случится, мы сосредоточим на этом всё внимание, всё остановим и исправим.

'''ПЛ:''' Была у нас подобная проблема в 1.2, очень странная ошибка: когда вы устанавливали градиент определённым способом, все просто чернело. Обнаружив ошибку, мы исправили её за шесть часов. В 1.4 нам «посчастливилось» получить некоторую разновидность автоматизированной регрессии. По мере усложнения кода становится всё труднее по-настоящему тестировать все функции, потому что их слишком много. В прежние времена я мог пробежаться по ним за выходные. Теперь этого уже не сделать. Теперь над ошибками работает много людей – ищут их, проверяют исправления, чтобы убедиться, что всё откорректировано правильно.

'''КР:''' В процессе очистки всплывают проблемы, скрытые за двойным кодом, или код, который исполняется дважды. Я переместил буквально тысячи строк кода. При переходе на другую модель – будь то возможность конвертировать в PDF из командной строки, или запускать как сервер, или использовать меньше памяти – обнаружилось, что уйма кода располагалось там, где его было удобно прописать когда-то. Почистив код, мы можем сделать его быстрее и эффективнее.

'''LXF:''''' ''Над чем вы сейчас работаете?

'''КР:''' <nowiki>Над очисткой и перемещением кода… будет значительное повышение скорости. Пока что мы сделали новую систему отмены последнего действия [undo], предстартовую проверку, цветовое колесо... Кое-что пытаемся сделать более
дружественным к пользователю. Сейчас мы используем отдельные стили параграфов и стили строк. Но скоро появится новый менеджер стилей, который их объединит, плюс у нас будут стили символов.</nowiki>

'''ПЛ:''' Над крупным улучшением поддержки EPS <nowiki>[Encapsulated PostScript; формат для печати на PostScipt-устройствах, – прим. пер.]</nowiki>. Версия 1.3 – это путь к 1.4, и ''Scribus ''1.4 будет инструментом профессионального класса; в нём будет всё необходимое для выполнения вёрстки практически любого вида. Я думаю, ''Scribus ''некоторые планки взял. Считалось, что открытое приложение никогда не сможет работать с заливкой цветом, но мы этого добились. На подходе ещё одна вещь – улучшенная поддержка сносок в больших документах, и т.п. Верите или нет, но сейчас ''LaTeX ''или ''OpenOffice.org'', похоже, лучше всех поддерживают большие документы. Ещё у нас готовитсяизменение размера страницы на лету, и разнородные размеры страниц в документе. Также предусмотрены спуски <nowiki>[imposition; расстановка полос на печатной форме в нужной для брошюрования последовательности – прим. пер.]</nowiki>

Спуски сделать будет не сложнее, чем распечатать A3: согнуть, скрепить, и готово. Следующий шаг – добраться до книг, тонкой переплётной работы и прочего: это совершенно другой мир, с весьма специфическими инструментами, стоящими от 5000 долларов. Его мы трогать не собираемся. Пока не собираемся

== Inkscape ==
'''Задаёт стандарты будущего графического дизайна.'''

Иногда жесткие решения себя оправдывают. Стандарт SVG, предназначение которого, будем надеяться, – стать повсеместным для векторной графики, как JPEG для фотографий, никогда не разрабатывался как внутренний формат. Базирование структуры на XML делает его очень гибким и пригодным для самых разнообразных целей. Но на внутреннем уровне работа с XML – мучение, заметно снижающее эффективность. Поэтому вполне естественно, что многие разработчики графических пакетов реализуют поддержку SVG только как функцию окончательной обработки. Некоторые, со скрипом, могут и импортировать SVG, но это, как правило, немногим больше, чем поверхностная трансляция – попробуйте сохранить тот же файл, и, вполне возможно, заметите искажение.

[[Изображение:Img_80_42_3.jpg|frame|Экспериментальные эффекты, управляемые скриптами, можно получить, разрешив их использование в настройках приложения]]

[[Изображение:Img_80_42_1.jpg|frame|Трассировка растра в Inkscape в настоящее время - лучшее из имеющегося в Linux, благодаря использованию другого открытого кода]]

Группа разработчиков, однако, решила, что миру нужно слияние традиционных SVGредакторов в «программистском» стиле (которые непосредственно воздействуют на XML и позволяют программистам изменять свойства узлов и т.д.) и мира инструментов рисования. Результат – ''Inkscape ''– добавил еще одну яркую историю успеха открытых графических программ и подтвердил идею, что открытые стандарты и свободная мысль могут изменить мир. По крайней мере, мир графики.

Проект стартовал под именем ''Sodipodi''.

Критической точкой явилось несовпадение мнений о том, в каком направлении его продолжать. Это вполне обычное явление: интернет-феномен под названием ''Firefox в''озник, когда двое разработчиков покинули проект Mozilla. А в данном случае четверо из основных участников ''Sodipodi ''решили отделить код и создать проект, ныне известный как ''Inkscape''.

'''Чистовой чертёж'''

Проект придерживался этого направления, и в вопросах редактирования SVG он настолько вырвался вперёд на любой платформе, что вряд ли не сможет стать основным инструментом создания векторной графики в этом стандарте.

Как и большинство других рассмотренных здесь инструментов, I''nkscape ''является кроссплатформенным. Одна и та же версия доступна под Linux, Windows и Mac, а в мире графики это даёт огромные преимущества. Действующее сообщество художников, несомненно, для профессионального дизайна использует Mac.

[[Изображение:Img_80_40_2.jpg|frame|Inkscape вкючает мощный XML-редактор для прямых манипуляций с элементами]]

Доступность ''Inkscape н''а этой платформе не только открывает программе рынок, но также обеспечивает полезнейшую обратную связь от пользователей-профессионалов. Кое-кто еще цепляется за идею, что ''Inkscape и''спользуют только потому, что он бесплатный, но это становится всё меньше похоже на правду.

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

Отсюда также следует, что ряд людей, интересующихся проектом, включая и часть основных разработчиков, считают себя скорее художниками, чем программистами. И хотя можно подумать, что они просто пишут то, что им интересно, команда ''Inkscape о''тлично понимает различных пользователей, которых хочет привлечь, и различные их нужды.

Полезность – основное направление текущей разработки: сделать программу пригодной для широкого круга дизайнеров, а также подходящей для всех задач, использующих SVG. С распространением формата SVG в сети, на рабочих столах и в мобильных устройствах ''Inkscape ''готов стать следующим поколением Illustrator’а.
----
'''ИНТЕРЬВЮ'''

'''''LXF:''' ''Что привело вас в ''Inkscape''?

'''Джон Круз (ДК):''' Просто раскол ''Sodipodi ''произошёл, как раз когда я хотел активнее включиться в движение open source; я уже давал им советы насчет всяких трюков в Win32. Они сказали, что будут создавать самый лучший SVG-редактор – и в техническом, и в художественном смысле.

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

На мой взгляд, разработчики ядра ''Inkscape ''выбрали правильные методы. Если у вас есть хорошая идея, то реализуйте её и добавьте в проект. Если есть проблемы, люди за ними присмотрят. То есть получается очень простая организация. Это проект, и каждый работает на проект – это не код одного человека.

'''''LXF:''' ''А может, люди просто хотят заниматься тем, что им интересно?

'''ДК:''' Основная масса участников проекта старается сделать довольно серьёзные части программы. Мы пишем для пользователей. Вначале пользователями были одни разработчики, но со временем пользовательская база разрослась.

Вот в чём у меня есть некоторый опыт – так это в изучении требований. Люди приносят идеи о том, как программу можно использовать. Порой они просят о нужных с их точки зрения вещах, но не могут объяснить, что в конечном итоге достигается.

'''''LXF:''' ''То есть вы руководствуетесь тем, как пользователи в действительности используют программу, а не просто вставляете функции? Нетипично!

'''ДК:''' Да, и я думаю, это одна из вещей, за которые команду критикуют. Я думаю, это критика из разряда «Они – простые инженеры, что они понимают?». Но некоторые из наших разработчиков – художники, и они очень хорошо ладят с интерфейсом.

'''''LXF:''' ''Какие функции появятся в следующем году?

'''ДК:''' Мы думаем о просмотре свойств – преобразовании его в нечто большее, чем просмотрщик объектов, а также об улучшении диалога слоёв. Это очень нужно. Люди продолжают работать над этим и тратят много времени, чтобы сделать всё как следует. Будет здорово, но мы не хотим выпускать это в недоделанном виде.

'''''LXF:''' ''Займетесь ли вы слоями? Сейчас ''Inkscape'', похоже, использует тот же подход, что и O''penOffice''.org. Слои – это такая вещь, важность которых понимаешьне раньше, чем начнешь их использовать.

'''ДК:''' ''OpenOffice.org ''и подобные приложения должны делать хорошо каждый фрагмент. А мы фокусируемся на SVG, и мы должны уметь «вылизать» эту единственную вещь, причем превосходно. Мы также занимается переделкой пользовательского интерфейса и целевыми профилями. Например, если вы хотите создать SVG Tiny, для телефонов и мобильных устройств, мы можем упростить вашу задачу: вы выполните экспорт и получите совместимый SVG. Firefox выпустил новую версию с поддержкой SVG. И стал качественно иным.

'''''LXF:''' ''Здесь явно выплывает много сопутствующих идей, например, Cairo.

'''ДК:''' Ну, их может быть намного больше. Например, вы могли бы нацелить ''Inkscape ''<nowiki>на следующую версию рабочего стола Gnome и всюду использовать векторы. Чем легче создавать [векторные изображения], тем шире использование.</nowiki>

Уже сейчас, создав XHTML- страницу со встроенным SVG, вы сможете добиться, чтобы это работало в Firefox со скриптами и DOM, и можно делать довольно сложные вещи. Сейчас делается много интересного.

'''''LXF:''' ''Всё же не так много инструментов, ориентированных на SVG. Программные средства есть, но не такие артистичные, как ''Inkscape''.

'''ДК:''' Да, и у нас есть цель и опыт. У нас хороший круг людей… SVG – очень понятный стандарт, и в его правильности очень легко убедиться. Я знаю людей, постоянно работающих с ''Inkscape ''– если что-то не так, мы тут же услышим об этом.

== Gimp ==
'''Номер один в своей области – серьёзная графическая мощь.'''

Попросите сотню среднестатистических пользователей Linux назвать графическое приложение – и смело можно держать пари, что в ответ они выпалят одно слово: ''Gimp''.

Прошло уже более десяти лет с тех пор, когда Спенсер Кимболл (Spencer Kimball) объявил о проекте создания открытого приложения, способного соперничать с профессиональными (и дорогими) альтернативами для Mac и Windows. За это время появились бесчисленные дополнительные модули, обогатившие функции, и пользовательский интерфейс был полностью перестроен.

[[Изображение:Img_80_44_3.jpg|frame|Митч Наттерер (Mitch Natterer) объясняет, чем так хороша GEGL! (фото Романа Йооста)]]

[[Изображение:Img_80_44_1.jpg|frame|SIOX позволит вырезать контуры намного проще - только используйте бета-версию Gimp 2.3, а не расширения версии 2.2]]

''Gimp ''прошёл длинный путь, но его всё ещё критикуют за недостаток ряда ключевых функций и медленный темп разработки. Заявляют даже, что ''Gimp ''фактически тормозит развитие: его разительное первенство в редактировании растровой графики под Linux означает, что соперников ему бояться нечего – а следовательно, нет выбора и конкуренции. Хотя на самом деле причина в чрезвычайной сложности ''Gimp: д''остижение заметных улучшений требует уймы времени и усилий.

'''День GEGL'''

Хотя это и не часть собственно ''Gimp'', ''GEGL (''Generic Graphics Library – общая графическая библиотека) оказывает значительное влияние на направление будущего развития G''imp''. ''GEGL ''пока что находится на этапе разработки релиз-кандидата, и проектируется как автономная библиотека для работы с графикой «по запросу».

Управляемость по запросу – наиболее заметная особенность системы. Она означает, что окончательная обработка выполняется именно в нужный момент (т.е.
непосредственно перед выводом на экран), а не последовательно через ряд шагов.

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

''GEGL ''также умеет управляться с различными глубинами цвета, так что она пригодна для широкого круга задач по обработке изображений. Конечно, G''EGL ''будет очень полезна и для других приложений. Команда Scribus, например, очень заинтересовалась потенциалом ''GEGL ''и тем, что она может сделать для обработки изображений в издательском приложении.

'''Всё включено'''

[[Изображение:Img_80_44_2.jpg|frame|Пока не вышел Gimp 2.4, за большинство новых хитростей отвечают фильтры]]

Основная работа, идущая в выпускаемых версиях ''Gimp, з''аключается в чистке и приборке перед долгожданным релизом 2.4 – так что мы займемся дополнениями, обеспечивающими внедрение интересных новых разработок.

Мы рассматривали SIOX (Simple Interactive Object Extraction – простое интерактивное извлечение объектов) в ''[[LXF74-75:Технологии Linux-2006|LXF75]]'', но стоит остановиться на нем ещё раз. С этим замечательным инструментом можно отделить изображение переднего плана от фона, всего пару раз шаркнув мышкой. Каждый бит сгенерированного контура столь хорош, как будто вы кропотливо отслеживали каждую точку очертания самостоятельно.

SIOX будет интегрирован в финальный релиз ''Gimp ''2.4, но уже сейчас доступен как дополнительный модуль. Из-за ограничений ''Gimp ''2.2 он не столь эффективен, как будет в финальном релизе – если вы серьезно намерены его попробовать, лучше использовать разрабатываемую версию G''imp ''(имеется на нашем диске), пока не выйдет версия 2.4. Дополнительная информация по SIOX – на сайте '''www.siox.org'''.

----

'''ИНТЕРВЬЮ'''

'''''LinuxFormat''': ''Вы довольны нынешним положением дел в Gimp?

'''Свен Нойманн (СН):''' Вообще-то я рад был бы видеть его прошедшим больший путь. В прошлом у нас были грандиозные планы, но пока завершить их не удалось. Есть много вещей, о которых просят люди – скажем, поддержка большей глубины цвета или других цветовых схем, например, CMYK – мы их уже планировали. Но у нас недостаточно ресурсов, чтобы всё это реализовать.

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

'''''LXF:''' ''Многих удивит, что такой важный проект имеет всего 30–40 участников. Это всегда так было, или раньше у вас было больше людей?

'''СН:''' ''Gimp ''всегда был проектом, на который тратят свои силы всего несколько человек. Хотя эти люди всё время меняются.

Одна из проблем – то, что многие из участников-долгожителей, отлично знающих код, повзрослели: они уже не ст уденты, и у них есть работа и личная жизнь. Они просто не могут посвящать проекту так много времени, как пару лет назад. Возможно, необходимо вливание новой крови.

'''''LXF:''' ''Новым участникам потребуется немало времени, чтобы освоиться со столь сложным кодом.

'''СН:''' Ну, если людям это интересно, они могу т поработать с дополнительными модулями. В большинстве из них легко разобраться – они в основном оформлены в одном C-файле. Трудности особой нет – и есть похожие модули и примеры для иллюстрации.

Конечно, работа с ядром и внесение фундаментальных изменений в пользовательский интерфейс или ввод новой концепции – довольно сложная задача, если имеешь дело с большим объёмом кода. С другой стороны, за последние несколько лет мы значительно улучшили кодовую базу. Выполнили большую работу по очистке и, так сказать, вынесению за скобки. То, что было несколькими сотнями файлов в одном каталоге, теперь разделено и лучше организовано.

'''''LXF:''' ''Кое-кто мог бы предположить, что вы всей командой чуть ли не год отдыхали, потому что набор функций за этот год почти не изменился.

'''СН:''' <nowiki>Мы хотели [давным-давно] выпустить релиз 2.4. Мы пообещали добавить в него некоторые функции и приступили к работе над ними. А теперь мы в той ситуации, что есть пара инструментов, просто не готовых к выпуску.</nowiki>

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

'''''LXF:''' ''Вы упомянули управление цветом и CMYK – какие ещё функции вы могли бы сделать доступными в ближайшее время?

'''СН:''' CMYK не будет использоваться для хранения данных о пикселах. Но как только мы как следует реализуем управление цветом, люди получат многое из того, что они просили. Я также думаю, что наиболее важная из отсутствующих в ''Gimp ''функция в данный момент – поддержка высокой глубины цвета. Всё больше и больше камер предоставляют такие данные, и мы не должны просто отбрасывать их при импорте.

'''''LXF:''' ''Думаете ли вы, что Gimp помогла бы спонсорская помощь или включение в в какую-нибудь из имеющихся премиальных схем?

'''СН:''' Вот этим, в частности, я хотел бы заняться в следующих месяцах. Составить список того, что действительно требуется сделать в ''Gimp'', и прикинуть, куда обращаться и с кем говорить. Мы хотели бы его опубликовать, и не только в Bugzilla. Я хотел бы, чтобы все знали: мы ищем разработчиков, и видели, что нам нужно доделать. Это могло бы привлечь больше людей.

С другой стороны, премии порой создают трудности, потому что для разработчиков, которые с нами уже давно, сотрудничество с людьми, которые работают за плату, может стать демотивирующим фактором. Мы хотели бы, чтобы довольны были все. Я уверен, что это возможно.

== Xara ==
'''Профессиональный инструмент дизайна становится свободным.'''

Не больше ли радует движение Open Source одно проприетарное приложение, раскаявшееся и оставившее путь закрытого кода, чем 99 приложенийправедников? Если да, то на ''Xara ''должны изливаться потоки любви. Хотя эта программа всю жизнь разрабатываемая частной британской фирмой, она много лет лицензировалась компанией ''Corel'', распространявшей её под названием ''CorelXara''.

[[Изображение:Img_80_46_3.jpg|frame|Открытие кода Xara может привести в Linux множество новых художников]]

[[Изображение:Img_80_46_1.jpg|frame|"Живые" эффекты в Xara экономят время и очень популярны среди дизайнеров]]

Вы можете подумать, что для «освобождения» приложения достаточно опубликовать исходный код и позволить каждому им пользоваться. Для некоторых приложений так оно и есть, но проприетарное ПО – в частности, настольные приложения – очень часто используют сторонний инструментарий и библиотеки, и связанный с ними код открыть нельзя. Исключение этого кода может быть весьма кропотливой задачей, и, очевидно, оставит приложение неполным: тут какие-то подпрограммы загрузки и сохранения, там куски алгоритмов – не говоря уж о целых инструментариях GUI.

Одна из самых знаменитых функций X''ara ''– движок предпросмотра в режиме реального времени. Протащите прозрачный градиент по вашему рисунку, и экран обновится в реальном времени по мере протаскивания – никаких проб и ошибок при получении желаемого эффекта!

Обратная связь в режиме реального времени уберегает от массы трудностей и делает приложение более отзывчивым на требования пользователей. Это одна из областей программы, которая пока ещё не открыта.

Понятно, что разработчики ''Xara ''делают всё неспешно и аккуратно.

'''Стык культур?'''

Когда ''Xara ''решилась на переход, некоторые роптали, что это может закончиться конкуренцией с ''Inkscape ''за лидерство среди дизайнерских приложений для Linux, но они упустили главное: хотя общего у проектов много, они, по большому счёту, ориентированы на разные вещи.

[[Изображение:Img_80_46_2.jpg|frame|Открытая Xara Extreme готова к использованию - хотя многие из ее функций пока недоработаны. Включая "Save"!]]

У ''Xara ''длинная история новаторского и разностороннего инструмента для иллюстраций и работ для Интернета, но она не нацелена исключительно на работу с SVG, как ''Inkscape''. Не похоже, что в ''Xara ''когда-нибудь будет встроен XML-редактор, как это сделано в ''Inkscape – х''отя сейчас это открытая программа, и как знать? Очевидно одно: разработчики ''Inkscape и'' ''Xara ''стремятся к сотрудничеству. На конференции LGM они охотно обменивались идеями и работали над способом облегчить передачу данных между своими приложениями.

Чарльз Мойр (Charles Moir), владелец ''Xara'', также спонсирует разработку
«суперконвертора». Идея знакома сторонникам открытого кода – создать промежуточный формат для графики и набор инструментов для преобразования всевозможных форматов в промежуточный и промежуточного – в другие форматы. Сказать это проще, чем сделать, потому что для достижения настоящей эффективности требуются способы сохранения или, по крайней мере, корректной интерпретации характеристик каждого формата, зачастую уникальных. Проект получил название Chromista, и первый его разработчик – Эрик Вильгельм (Eric Wilhelm). Вы можете узнать больше о целях проекта на его сайте: '''http://scratchcomputing.com/projects/uber-converter'''.

Что же касается самой ''Xara'', продолжается работа по реализации всех функций проприетарной версии в открытом коде. Обещаны регулярные выпуски кода и двоичных пакетов, и команда тратит уйму усилий, чтобы включить функцию «Save» (Сохранить). Дело хорошее!
----

'''ИНТЕРВЬЮ'''

'''''LinuxFormat:''' ''Почему, спустя более 10 лет, вы открыли код X''ara''?

'''Нейл Хоу (НХ):''' Основная причина – хочется видеть, что проект способен достичь намного большего, чем есть сейчас. Проблема у нас в том, что мы – очень маленькая фирма с ограниченными ресурсами. Нам все говорят: какой ''Xara Extreme ''хороший инструмент для рисования! – и мы просто хотим выпускать его побольше. Я думаю, что придав ему кросс-платформность, обеспечив доступ и пользователям Linux, и пользователям Mac, а также сделав код открытым, мы сможем этого добиться.

Еще один фактор – мы недостаточно быстро развивали продукт. Я уверен, что каждая фирма-разработчик ПО планирует намного больше, чем в состоянии когда-либо осуществить. Мы не исключение – разве что, как я подозреваю, наш список ещё длиннее – и с имеющимися ресурсами мы не чувствовали сил для достаточно быстрого движения.

'''''LXF:''' ''То есть выходит, что даже будь у вас превосходные идеи, вы не смогли бы их реализовать?

'''НХ:''' Да, мы можем сделать не так уж много. Мы хотим видеть инструмент, добившийся определённого успеха по сравнению с подобными от Adobe и Microsoft. Если мы получим поддержку сообщества Open Source, думается, мы сможем достичь более быстрого прогресса.

'''''LXF:''' ''Вы говорите об открытии кода ''Xara''?

'''НХ:''' Да! Это было трудным решением для такой фирмы, как наша, – взять инструмент, с нашими технологиями, который мы собирали так много лет – годы усилий были потрачены на него; это значительный шаг. Тут и причина, почему мы не приняли подход «большого взрыва» – мы не просто говорим «Всё это теперь открыто». Мы осуществляем открытие в два этапа, чтобы посмотреть, как проходит первый этап, сформировать сообщество, продвинуть его вперёд, а затем полностью выпустить код.

'''''LXF:''' ''Технология, оставшаяся закрытой – движок рендеринга. Есть ли ещё компоненты, которые вы пока придержите?

'''НХ:''' Среди них, код комбинирования фигур – код для пересечения конт уров – это всё в одной и той же библиотеке. Так что закрыты пока движок и эта часть кода, они находятся в одной двоичной библиотеке, и мы поставляем ее вместе с исходным кодом, который должен с ней собираться. Точно сказать не могу, но в терминах объёма исходного кода, сейчас открыто примерно 90%.

'''''LXF:''' ''Что, как вы ожидаете, будет первым эффектом от открытиякода, и чего бы вам хотелось?

'''НХ:''' <nowiki>Мы хотели бы получить сообщество, и оно у нас уже есть. В последние месяцы мы даже частным порядком приглашали разработчиков «со стороны», чтобы сделать порт [для Linux] – мы просто открыли им доступ к коду еще до публичного выпуска. И это дало старт сообществу, если хотите, и мы рады наблюдать, как сообщество растёт, и видим, что разработчики открытого кода помогают нам завершить порт как можно быстрее. Это первая цель – сделать его столь же функциональным и надёжным, как версия для Windows, с которой мы начали.</nowiki>

'''''LXF:''' ''Сколько времени, по вашей оценке, на это потребуется?

'''НХ:''' Сложно сказать. Первоначально прогресс был медленнее, чем я ожидал. Но это в значительной степени потому, что портирование – основа всего, само оно ничего не выполняет, а просто предоставляет доступ к другим функциям.

Примерно с середины января начался действительный взлёт. Например, на этой неделе Алекс (один из разработчиков) включил два инструмента за два дня – инструмент «свободное выделение» и инструмент смешивания. Так что мы надеемся, что темпы развития сохранятся или даже возрастут.

'''''LXF:''' ''Вы сказали, что у вас огромные планы. Как вы думаете, на этом этапе вы в состоянии реализовать новые функции помимо собственно портирования?

'''НХ:''' Мы установили первую веху в функциональности ''Xtreme'', пока без того, что мы не можем открыть, как я уже упоминал. Но открытый код есть открытый код, и мы не собираемся указывать людям, что можно делать, а что нельзя. Если кто-то приходит с желанием работать над продуктом, пишет, например, новый инструмент и хочет внести его в код, мы не скажем ему «Извините, мы принимаем только заплатки».

LXF91:Java EE

2009-02-06T06:33:14Z

Dionysius:

{{Цикл/Java EE}}
[[Категория:Учебники]]
__TOC__
:В прошлый раз вы, под чутким руководством '''Александра''', разобрались с JSP и переписали "Телефонную книгу" с учетом этой технологии. Сегодня мы двинемся дальше и поговорим об авторизации, сессиях, фильтрах и использовании разделяемых объектов в web-приложениях.

:''{{oncolor||red|ЧАСТЬ 3}} Каждый линуксоид знает, что система уровня предприятия должна обеспечивать разграничение доступа. '''Антон Черноусов''' расскажет, что может предложить здесь Java EE.
[[Media:AddressBook2.tar.bz2|Скачать исходный код примера]]

==Процесс передачи информации==
Давайте рассмотрим стандартную ситуацию: пользователь вызывает различные страницы одного web-приложения. Если бы этот "диалог" происходил по телефону, он был бы примерно таким:
*'''Пользователь (набирает номер): Алло, это приложение?'''
*Приложение: Да, это приложение.
*(Пользователь кладет трубку)
*'''Пользователь (набирает номер): Меня зовут Георг.'''
*Приложение: Да, Георг, мы вас внимательно слушаем.
*(Пользователь кладет трубку)
*'''Пользователь (набирает номер): Дайте мне, пожалуйста, всю информацию.'''
*Приложение: Возьмите...
Отметим, что после каждого обмена репликами пользователь кладет трубку, разрывая соединение - именно таким образом в большинстве случаев и происходит обмен данными между браузером пользователя и сервером, на котором работает web-приложение. Возникает резонный вопрос: как передавать информацию между соединениями, открываемые в рамках одной сессии? Для этого могут использоваться самые различные методы:
*перезапись URL;
*скрытые поля;
*cookie;
*сессионный объект.
Из всех представленных методов наиболее простым и в тоже время можным является сессионный объект (Session), реализованный в Java посредством интерфейса {{oncolor||red|javax.servlet.http.Session}}.
Ранее, чтобы получить данные от пользователя или обеспечить возможность их транспортировки внутри приложения, мы использовали объект типа
{{oncolor||red|HttpServletRequest}}. Основное отличие {{oncolor||red|HttpSession}} заключается во времени жизни, схематично изображенном на '''Рис.1'''. Объект типа {{oncolor||red|HttpServletRequest}} предназначен для передачи запроса (и необходимых данных) от браузера к web-приложению и существует только между запросом и ответом, в то время как объект {{oncolor||red|HttpSession}} обеспечивает средства для хранения и доступа к данным пользователя на протяжениии всего периода работы с приложением.
)(Рис.1) Время жизни объектов HttpServletRequest и HttpSession.
Следует, однако, иметь в виду, что отследить момент, когда пользователь перестает работать с приложением, не всегда возможно. Поэтому в настройках сервера устанавливается некоторое предельное время существования объекта {{oncolor||red|HttpSession}} после получения последнего запроса.

[[Изображение:LXF91_javaee1.png|Рис. 1]]

'''Время жизни объектов ''HttpServletRequest'' и ''HttpSession'''''

==Сессия==
Объект session в JSP является предопределеным, то есть с ним можно сразу же начинать работать. Чтобы создать сессионный объект в сервлете, воспользуемся следующим методом:

HttpSession session = aRequest.getSession(true);

Здесь '''aRequest''' – это экземпляр объекта '''HttpServletRequest''', то есть
запрос переданный сервлету.

Классы, реализующие интерфейс '''HttpSession''', имеют два замечательных метода: '''setAttribute(String, Object)''' и '''getAttribute(String)'''. Метод
'''setAttribute(String, Object)''' применяется для добавления объекта в сессию, а '''getAttribute(String)''' – для извлечения объекта из нее. Например:

<source lang=java>
session.setAttribute(“sameKey”,sameObject);
SameObject aObject = (SameObject) session.getAttribute(“sameKey”);
</source>

Фактически, объект '''session''' – это таблица '''Hashtable''', в которой можно хранить любое количество пар типа «ключ – объект». При использовании сессионного объекта данные приложения не отправляются
пользователю так, как это происходит с cookie. Сессионный объект
хранится на сервере персонально для каждого клиента. Сервер различает сессии с помощью маркера, который передается пользователю.
Маркер хранится в cookies браузера до конца сессии, что накладывает
некоторые ограничения на клиентское рабочее место (использование
cookies для вашего приложения должно быть разрешено). В этом можно легко убедиться, просмотрев сохраненные cookies в вашем любимом браузере.

[[Изображение:LXF91_javaee2.png|Рис. 2]]

'''Маркер сессии. Герои романа «''Лабиринт отражений''» пытались повесить друг другу маркер под видом невинного поцелуя, а наше web-приложение действует еще хитрее и незаметнее.'''

==Авторизация==

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

Давайте создадим JSP-страницу '''auth.jsp''', которая будет запрашивать у пользователя имя и пароль. Сохраните файл в каталоге '''jsps''' и введите в него следующий текст:

<source lang=java>
<span style=”color: green;”><%=request.getAttribute(“message”)%>
</span>
<form action=”<%=request.getContextPath()%>/auth” method=”post”>
<table>
<tr><td>Логин: </td><td><input type=”text” name=”login”/>
</td></tr>
<tr><td>Пароль: </td><td>
<input type=”password” name=”password”/></td>
</tr>
<tr><td colspan=”2” align=”center”>
<input type=”submit” value=”Авторизоваться”/></td>
</tr>
</table>
</form>
</source>

Легко видеть, что в форме имеется два поля ввода и одна кнопка.
Заметим также, что поле для ввода пароля имеет тип '''password''', так что
вместо нажатых клавиш в окне браузера будут отображаться до боли
знакомые «звездочки» ('''‘*’''').

Теперь внесем изменения в '''AddressBookServlet''': расширим ветвление в методе '''handle''' следующим образом:
<source lang=java>
}else if (“/auth”.equals(target)) {
handleAuth(aRequest, aResponse);
}
</source>

Дело за малым – осталось написать метод '''handleAuth(aRequest,aResponse)''', который и будет обрабатывать данные, введенные в форму, то есть производить авторизацию пользователя.
<source lang=java>
private void handleAuth(HttpServletRequest aRequest,
HttpServletResponse aResponse) throws IOException,
ServletException {
String login = aRequest.getParameter(“login”);
String password = aRequest.getParameter(“password”);
if ((login != null) && (password != null)) {
// here is auth process
if ((login.equals(“user”)) && (password.equals(“userPass”))) {
//here is success auth
HttpSession session = aRequest.getSession(true);
session.setAttribute(“auth”,aRequest.getParameter(“login”));
aRequest.setAttribute(“message”, null);
outputPage(“index.jsp”, aRequest, aResponse);
} else {
//here is failed auth
aRequest.setAttribute(“message”,
“Неверный логин или пароль, повторите ввод
данных”);
outputPage(“auth.jsp”, aRequest, aResponse);
}
} else {
//here is no data to auth
aRequest.setAttribute(“message”,
“Логин и пароль не могут быть пустыми, повторите
ввод данных”);
outputPage(“auth.jsp”, aRequest, aResponse);
}
}
</source>

Чтобы не усложнять приложение, мы используем простейший
способ авторизации – имя пользователя и пароль жестко зашиты в
теле метода. С точки зрения безопасности и масштабируемости лучше
использовать для хранения этих данных БД.

В случае удачной авторизации мы помещаем имя пользователя в
объект '''session''' и перенаправляем его на главную страницу. Если же
авторизация не удалась (введено неверное имя пользователя и/или
пароль), пользователю будет предложено повторить попытку.

Таким образом, если авторизация прошла успешно, в сессии пользователя будет сохранен объект, содержащий его имя. Используя этот
факт, можно изменить '''index.jsp''' и спрятать ссылку на добавление нового телефона от посторонних глаз:

<source lang=java>
<%String name = (String)session.getAttribute(“auth”);
if (name != null){ %>
<p>Вы авторизованны как: <%=name%> </p>
<a href=”<%=request.getContextPath()%>/add”>Добавить
запись</a><br/>
<%} else {%>
<a href=”<%=request.getContextPath()%>/auth”>
Авторизоваться</a><br/>
<%} %>
</source>

Мы приветствуем пользователя, используя значение атрибута '''auth'''
и предоставляем ему доступ к функции добавления нового контакта.
Чтобы спрятать удаление и редактирование записей от неавторизованного пользователя, необходимо внести аналогичные изменения в
файл '''view.jsp'''.

==Фильтры==

Наше приложение, к сожалению, страдает проблемами безопасности:
злонамеренный пользователь может обойти процедуру авторизации,
обратившись к функциям редактирования/удаления напрямую, по
адресу '''request.getContextPath() + действие (/add; /edit; /remove)'''; можно также непосредственно вызывать JSP-страницы, расположенные в каталоге '''/jsps''' – нужно только узнать их имена.

Что же делать? Проверять, авторизован ли пользователь перед
выполнением привилегированного действия? Это неудобно – если
количество JSP будет расти, это заставит вас написать много строк
однотипного кода, поддержание которых будет отнимать ваше драгоценное время. Мы пойдем другим путем и воспользуемся так называемыми фильтрами.

Схема работы фильтров представлена на Рис. 3. Если для адреса,
на который отображен сервлет, осуществляется фильтрация, запрос
будет передан сервлету только после того, как пройдет через каждый
установленный фильтр.

[[Изображение:LXF91_javaee3.png|Рис. 3]]

'''Схема прохождения запроса через фильтры.'''

На самом деле, фильтр представляет из себя обыкновенный Java-
класс, реализующий интерфейс '''javax.servlet.Filter'''. Например:
<source lang=java>
public class FirstFilter implements Filter {
private FilterConfig filterConfig;
public void init(FilterConfig filterConfig) throws ServletException {
System.out.println(“Filter init”);
this.filterConfig = filterConfig;
}
public void doFilter(ServletRequest aRequest, ServletResponse
aResponse, FilterChain filterChain)
throws IOException, ServletException {
System.out.println(“Filter used”);
filterChain.doFilter(aRequest, aResponse);
}
public void destroy() {
System.out.println(“Filter dead”);
this.filterConfig = null;
}
}
</source>

Реализовав всего три метода: '''init''' (инициализация фильтра в
момент старта приложения), '''destroy''' (освобождение ресурсов перед
завершением работы приложения) и '''doFilter''' (собственно метод, выполняющий фильтрацию), вы получаете класс, способный существенным образом повлиять на работу вашего приложения.

Обратите внимание, что в приведенном выше примере метод
'''doFilter''' заканчивается вызовом метода '''doFilter(aRequest, aResponse)'''
объекта '''filterChain''' – это обеспечивает вызов следующего фильтра в
цепочке (естественно, если фильтров несколько). Если фильтров больше нет, то управление будет передано следующему ресурсу, например, сервлету.

Остановимся подробнее на методе '''init''', а точнее на объекте, реализующем интерфейс '''FilterConfig'''. Этот объект имеет четыре замечательных метода:
* '''getFilterName()''' – возвращает имя фильтра;
* '''getInitParameterNames()''' – возвращает объект '''Enumeration''', который содержит в своем теле имена параметров текущего фильтра;
* '''getInitParameter(String)''' – возвращает значение параметра, имя которого было передано в качестве аргумента;
* '''getServletContext()''' – возвращает объект '''ServletContext''', о котором мы поговорим ниже.

Как вы уже, наверное, поняли, объект '''FilterConfig''' позволяет получить доступ к конфигурации фильтра, которая была задана при его объявлении в дескрипторе развертывания ('''web.xml''').

==Ограничение доступа==

Итак, воспользуемся фильтрами для ограничения доступа к ресурсам
нашего приложения. Прежде всего, запретим пользователю обращаться напрямую к JSP, и, при попытке запросить ресурс из каталога '''/jsps''',
заставим его перейти на индексную (первую) страницу. Для этого
напишем простой фильтр '''AccessFilter'''. Метод '''doFilter''' будет выглядеть
следующим образом:

<source lang=java>
public void doFilter(ServletRequest aRequest,
ServletResponse aResponse, FilterChain filterChain)
throws IOException, ServletException {
((HttpServletResponse)aResponse).
sendRedirect(((HttpServletRequest)aRequest).getContextPath());
}
</source>

Благодаря методу '''sendRedirect''', вместо ожидаемого ресурса неавторизованный пользователь увидит '''index.jsp'''. Чтобы фильтр заработал, его необходимо подключить в дескрипторе развертывания. Это делается при помощи следующих строк:

<source lang=java>
<filter>
<filter-name>AccessFilterName</filter-name>
<filter-class>AccessFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AccessFilterName</filter-name>
<url-pattern>/jsps/*</url-pattern>
</filter-mapping>
</source>

В секции '''filter''' мы объявляем, что имени фильтра '''AccessFilterName'''
соответствует класс '''AccessFilter''', а в секции '''filter-mapping''' указываем,
на какие объекты распространяется зона действия фильтра. В данном случае фильтр работает по шаблону, то есть используется для
всех адресов типа '''/jsps/*''', где вместо звездочки может быть все, что
угодно.

Теперь давайте создадим класс '''AuthFilter''', который будет ограничивать доступ к некоторым действиям для неавторизованных пользователей. Метод '''doFilter''' будет выглядеть следующим образом:

<source lang=java>
public void doFilter(ServletRequest aRequest,
ServletResponse aResponse, FilterChain filterChain)
throws IOException, ServletException {
HttpSession session = ((HttpServletRequest) aRequest).
getSession();
String name = (String) session.getAttribute(“auth”);
if (name != null) {
filterChain.doFilter(aRequest, aResponse);
} else {
aRequest.setAttribute(“action”, “auth”);
RequestDispatcher dispatcher = aRequest.getRequestDispatcher(“/
auth”);
dispatcher.forward(aRequest, aResponse);
}
}
</source>

Если в текущей сессии не задан атрибут '''auth''', пользователь будет
отправлен на страничку авторизации. Добавим в дескриптор развертывания следующие строки:

<source lang=java>
<filter>
<filter-name>AuthEditFilter</filter-name>
<filter-class>AuthFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthEditFilter</filter-name>
<url-pattern>/edit</url-pattern>
</filter-mapping>
<filter>
<filter-name>AuthAddFilter</filter-name>
<filter-class>AuthFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthAddFilter</filter-name>
<url-pattern>/add</url-pattern>
</filter-mapping>
<filter>
<filter-name>AuthRemFilter</filter-name>
<filter-class>AuthFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthRemFilter</filter-name>
<url-pattern>/remove</url-pattern>
</filter-mapping>
</source>

Обратите внимание, что хотя наш фильтр реализован одним-единственным классом, он может быть доступен по нескольким именам (в
нашем случае: '''AuthEditFilter, AuthAddFilter, AuthRemFilter''') и работать
для разных URL.

Чтобы закрыть тему развертывания фильтров, рассмотрим пример
настройки параметров фильтра в дескрипторе:
<source lang=java>
<init-param>
<description>
That is description
</description>
<param-name>
sameParamName
</param-name>
<param-value>
sameParamValue
</param-value>
</init-param>
</source>

Секцию '''init-param''' необходимо создавать отдельно для каждого
параметра, при этом она должна быть размещена внутри секции '''filter'''.
Обязательными являются подсекции '''param-name''' и '''param-value''', которые задают название параметра и его значение, соответственно.

==Доступ к общим объектам==

Наше приложение уже вполне работоспособно, однако рано или поздно нам захочется расширить его функциональность, и, возможно, для
этого потребуется уже не один сервлет, а несколько, причем все они
будут обращаться к некому общему ресурсу (информации или объектам). Например, вы можете захотеть узнать, сколько пользователей
в данный момент авторизовано в приложении или получить из двух
несвязанных сервлетов доступ к информации, хранящейся в одном
файле.

Подобно сессионным объектам, существует и контекстный объект, который обеспечивает доступ к общим ресурсам из разных мест
приложения. Использование контекстного объекта очень похоже на
использование сессионного, и получить его экземпляр в сервлете можно следующим образом:

<source lang=java>
ServletContext sc = this.getServletContext();
</source>

Этот объект обладает следующими методами:

* '''getAttribute(String)''' – получение общего объекта по ключу;
* '''getAttributeNames()''' – получение списка ключей общих объектов;
* '''setAttribute(String, Object)''' – добавление нового объекта и соответствующего ему ключа;
* '''removeAttribute(String)''' – удаление объекта, соответствующего ключу, из списка общедоступных объектов;

Несмотря на то, что в этой статье контекстному объекту уделено
немного внимания, он является одним из мощнейших инструментов
для обеспечения работы web-приложения.

==Вместо заключения==

Сегодня мы поговорили о сессионных и контекстных объектах, узнали
как создавать и использовать фильтры, рассмотрели простейший пример авторизации пользователя (конечно, надо сделать оговорку, что
было представлено весьма небезопасное и не промышленное решение,
хотя для простого офисного приложения его может быть и достаточно).
Наконец, мы модифицировали наше web-приложение «Телефонная
книга», применяя практически все изученные возможности.

В следующий раз мы рассмотрим паттерн ''MVC'' и его вариацию для
создания web-приложений: ''Model2''. '''LXF'''

LXF99:Java EE

2009-01-01T07:45:18Z

Dionysius: /* Экстракт кофе */

{{Цикл/Java EE}}
[[Категория:Учебники]]
== Экстракт кофе ==

[[Media:JavaEE_LXF99.tar.gz‎|Скачать исходный код примера]]

'''ЧАСТЬ 11''' Наша серия, увы, подходит к концу, но на десерт '''Александр Бабаев''' припас нечто особенное — ароматные зерна ''Enterprise Java Beans''

Все предыдущие статьи содержали огромное количество полезной информации. Мы рассмотрели алгоритмы, структуры, принципы работы, множество библиотек, так или иначе связанных с созданием серьезных приложений на Java. И пусть вас не смущает то, что примеры были простые. В основе больших, серьезных, важных и сложных приложений лежит именно то, о чем мы говорили.

Теперь вы уже готовы узнать, что обозначает загадочная аббревиатура EJB3. Расшифровывается она как «Enterprise Java Beans, version 3» и содержит внутри огромный мир, окошко в который мы сегодня приоткроем.

=== Почему именно EJB3? ===

Дело в том, что это стандарт. Тройка в названии указывает, что были еще версии один и два, также была версия два-точка-один… Но только текущая, третья версия действительно является великолепным инструментов для борьбы с хаосом корпоративных систем. Все предыдущие версии строились по такому принципу: «Мы ('''Sun/IBM/''' и пр.) тут собрались, посовещались и решили, что вы (разработчики) будете использовать вот это… (EJB2.1)». Было круто, но разработчики хоть и использовали, но плевались (странно, правда?). EJB3 создавалась иначе. Те же люди собрались, посмотрели на то, как работают программисты, какие есть библиотеки, удачные решения, технологии… И, выбрав лучшее и добавив свой (огромный) опыт, выдали третью версию спецификации.

Получившийся стандарт хорош. Хорош и простотой (можно обойтись без специфических XML, которых в предыдущих вариантах были сотни), и привычностью (''Hibernate'' использовали? Нет? Ну, это теперь reference implementation, то есть стандартная реализация для ''JPA1'', части EJB3), и заменой старых неудобных частей на новые, «блестящие и шелковистые».

=== Для чего оно? ===

Большие системы никогда не создаются в одиночку. Существуют люди, которые зовутся архитекторами: они придумывают систему. Система обычно состоит из блоков. Блоки, в свою очередь, состоят из других блоков… Блоки отвечают за совершенно разные вещи: за хранение бизнес-объектов, за просчет алгоритмов, за управление элементами системы, и так далее. Разрабатываются эти составные части системы разными людьми, часто совершенно не связанными друг с другом.

В таких условиях нужен стандарт, который обеспечивал бы, чтобы блок, написанный в Индии, и блок, написанный в России, заработали вместе. Можно этот стандарт каждый раз придумывать заново, но на это никогда нет времени. Лучше использовать EJB3.

=== Общая структура EJB-проекта ===

Упрощенная схема проекта приведена на Рис. 1.

[[Изображение:LXF99_Java1.jpg|Рис. 1. Трехзвенная структура EJB-проекта.]]

Это так называемая трехзвенная структура. Она проста, и для более сложных систем может разрастись до четырех-, пяти-, n-звенной. Серверов приложений может быть кластер, СУБД тоже может представлять кластер с распределением нагрузки и резервированием, и так далее.

В качестве СУБД сгодится практически любая: у нас это будет ''MySQL'', но, грамотно используя JPA (об этом чуть дальше), СУБД можно сменить хотя и за ненулевое, но вполне приемлемое время. Клиенты могут быть либо тонкими (браузер), либо полноценными приложениями (и даже не обязательно на Java).

А вот про сервер приложений поговорим подробнее. Это именно то место, где соединяются те самые блоки, написанные в Индии, России, Китае, США и так далее. Чтобы все они работали вместе, написаны специальные приложения, которые обеспечивают связь с СУБД, предоставляют огромное количество стандартных API для работы блоков, дают возможность эти блоки выгружать и загружать без перезапуска сервера, контролировать их исполнение… и много чего еще. Сервера приложений есть как коммерческие (''IBM WebSphere'', ''BEA WebLogic''), так и бесплатные (''GlassFish'', ''JBoss'', ''IBM WebSphere Community Edition''). Мы посмотрим поближе на ''JBoss'', который, помимо прочего, продвигается Red Hat и распространяется в составе Red Hat Enterprise Linux.

=== JBoss ===

Итак, сервер приложений. Он состоит из огромного количества блоков, интегрированных вместе. Некоторые нам уже так или иначе знакомы: например, Tomcat или подсистема RMI-подключений. Но есть и множество других: Hibernate, который отвечает за «связь с СУБД», система кэширования, кластеризации, распространения сообщений, транзакций (уровня приложения), …

Короче, система большая. Мы рассмотрим относительно небольшую часть, которая работает с EJB3, задержимся на Hibernate (и JPA) и немного поглядим на транзакции (JTA). Все рассмотреть, конечно, не успеем, поэтому после статьи приведен список литературы — выберите книжку по вкусу, чтобы заняться подробным изучением.

=== Так что же такое EJB? ===

Ну, во-первых, это технология, это уже понятно. Во-вторых, это Enterprise Java Bean (без «s») — то самое «зерно», то есть блок, из множества которых строится приложение. Блок стандартным образом упаковывается, и помещается в каталог ''JBoss'', после чего (если все сделано правильно), ''JBoss'' подключает блок к системе.

То есть блок — это бин (bean). И наоборот. Бин в простейшем случае — это всего лишь класс, описанный и объявленный специальным образом. Например, пусть он считает площадь круга.

<source lang=java>
@Remote
public interface Calculator {
public double getSquare(double aRadius);
}
</source>

Пока это только объявление, то есть интерфейс — то, что видит клиент. Причем от обычного интерфейса он отличается только словом '''@Remote''' (так называемой аннотацией). Оно обозначает, что клиенты, которые используют этот бин, могут находиться как на серверном компьютере, так и на любых других узлах сети. Если доступ извне локального компьютера не предполагается, то можно использовать аннотацию '''@Local''', или вообще ничего не писать, так как интерфейсы считаются локальными по умолчанию. Умолчания — это одно из огромных достоинств EJB3, так как не нужно прописывать банальности, которые в крупных проектах превращаются в мегабайты ненужного кода.

Но где же считается сама площадь? В классе, который реализует интерфейс:

<source lang=java>
@Stateless
public class CalculatorBean implements Calculator {
public double getSquare(double aRadius) {
return Math.PI*aRadius*aRadius;
}
}
</source>

Тут опять появилась аннотация, которая обозначает, что этот бин (да, это настоящий Enterprise Java Bean; да, больше — кроме упаковки в jar — не нужно вообще ничего) является Stateless-бином, то есть не сохраняет состояние в процессе работы. Клиент вызывает метод, метод выполняется, и следующий метод ничего не будет знать о предыдущем исполнении.

Теперь давайте посмотрим на клиент и, наконец, поставим ''JBoss'', запустив наш бин.

Клиент будет немного «не в стиле EJB3». Правильный EJB3-клиент выглядит примерно так:

<source lang=java>
public class CalculatorClient {
@EJB
private Calculator _calculator;
private void start() {
System.out.println(“Square for circle with radius 2.345 = “ +
_calculator.getSquare(2.345));
}
public static void main(String[] args) {
new CalculatorClient().start();
}
}
</source>

Но ''JBoss'' (который мы будем использовать для демонстрации) такого стиля (пока) не понимает, поэтому выйдет чуть-чуть подлиннее:

<source lang=java>
public class CalculatorClient {
private Calculator _calculator;
private void start() throws NamingException {
_calculator = (Calculator) getInitialContext().
lookup(“CalculatorBean/remote”);
System.out.println(“Square for circle with radius 2.345 = “ +
_calculator.getSquare(2.345));
}
private InitialContext getInitialContext() throws NamingException {
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
“org.jnp.interfaces.NamingContextFactory”);
properties.put(Context.PROVIDER_URL, “localhost:1099”);
return new InitialContext(properties);
}
public static void main(String[] args) throws NamingException {
new CalculatorClient().start();
}
}
</source>

Разница, как можно заметить, в отсутствии аннотации '''@EJB'''. А заменяет ее тот код, который мы написали (получение контекста, а из него — ссылки на нужный нам бин).

Нужно сделать небольшое отступление. При поиске объекта мы использовали его имя: '''«CalculatorBean/remote»'''. Почему именно так? И как вообще ищутся объекты? Для этого используется так называемая служба имен Java (JNDI) — нечто похожее на реестр RMI, который использовался для регистрации и поиска RMI-серверов. А имя присваивается автоматически и по умолчанию. В принципе, можно дать указания серверу приложений, как должен называться бин в системе.

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

Осталось упаковать классы, скинуть их серверу приложений и посмотреть, что же из этого выйдет.

=== Первый бин ===

Для начала скачаем ''JBoss''. Это можно сделать на страничке http://labs.jboss.com/jbossas/downloads/; берите стабильную версию (4.2.2.GA). Ее также можно найти на диске, прилагаемом к журналу.

Установка ''JBoss''’а заключается в разархивировании его куданибудь. После этого он готов к работе (предполагается, что пути к '''/bin/java''' уже находятся в '''PATH''').

Теперь сделаем бин. Для этого нужно скомпилировать наш интерфейс и класс (путь к ''JBoss''’у, конечно, подставьте свой):

<source lang=java>
javac -cp ~/bin/jboss/server/default/lib/jboss-ejb3x.jar Calculator.java
javac -cp ~/bin/jboss/server/default/lib/jboss-ejb3x.jar CalculatorBean.
java
</source>

после чего запаковать все в jar-файл:

<source lang=java>
jar -c CalculatorBean.class Calculator.class > CalculatorEJB.jar
</source>

Теперь начинается волшебство. Запускаем ''JBoss'':

<source lang=java>
jboss/bin/run.sh -c default &
</source>

(понятно, что путь к ''JBoss''’овскому '''run.sh''' будет другой, понятно, что если требуется запустить его с возможностью закрыть терминал, нужно использовать '''nohup'''… это самый простой вариант) и кидаем jar-файл в каталог '''/jboss/server/default/deploy'''.

Все, через секунду бин «воткнут» в ''JBoss''. Теперь можно запускать клиента. Компилируем его:

<source lang=java>
javac -cp ~/bin/jboss/server/default/lib/jboss-ejb3x.jar:. CalculatorClient.
java
</source>

Запускаем клиент, при этом подключая нужные библиотеки (все они есть в ''JBoss''’е):

<source lang=java>
java -cp ~/bin/jboss/client/jbossall-client.jar:. client.CalculatorClient
</source>

Получаем:

<source lang=java>
Square for circle with radius 2.345 = 17.275696541906616
</source>

Кто не верит, пусть пересчитает на калькуляторе.

=== Второй бин. JPA ===

Почувствовали, насколько это просто и быстро? Теперь попробуем что-нибудь сохранить в СУБД. Для этого немного настроимся. Подключать будем ''MySQL'', которая запущена на локальной машине, с настройками по умолчанию (учетная запись root без пароля). Чтобы подключить СУБД, нужно положить специальный XML-файл в тот же каталог '''jboss/server/default/deploy'''. Файл будет называться '''mysql-ds.xml''', а содержать будет следующее:

<source lang=java>
<?xml version=”1.0” encoding=”UTF-8”?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/jpaPool</jndi-name>
<connection-url>jdbc:mysql://localhost:3306/nisp</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>root</user-name>
<password></password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc. vendor.MySQLExceptionSorter</exception-sorter-class-name>
</local-tx-datasource>
</datasources>
</source>

Тут все просто: строка соединения нам попадалась уже при раcсмотрении JDBC в [[LXF93:Java|LXF93]] (можно ее усложнить, введя при необходимости всякие параметры), имя учетной записи и пароль — тоже вполне самоочевидные вещи. Еще указывается '''jndi-name''', то есть имя, по которому этот пул соединений можно будет найти в недрах ''JBoss''.

Положили? Теперь перезапустите сервер приложений:

<source lang=java>
jboss/bin/shutdown.sh -s jnp://127.0.0.1:1099 -S
jboss/bin/run.sh -c default &
</source>

Теперь мы готовы; начинаем писать '''EntityBean'''. Так называются классы-сущности, экземпляры которых хранятся в СУБД.

JPA, или Java Persistence API — это стандартный API, предназначенный для того, чтобы в удобном виде хранить Java-объекты в БД. При этом создается структура БД, создаются классы, в которых при помощи аннотаций прописываются связи между полями классов и полями таблиц БД, а остальное (преобразования, проверки, …) делает конкретная реализация JPA. В ''JBoss'' это '''Hibernate'''.

Итак, сделаем микробиблиотеку. Вот класс, который хранит в БД информацию о книге:

<source lang=java>
@Entity
public class Book implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Long Id;
public String Title;
public String Author;
}
</source>

И все. Мы вновь использовали аннотацию, на сей раз '''@Entity'''. Все остальное — умолчания, а значит, поля класса '''Title''' и '''Author''' будут полями в таблице '''Book'''. '''Id''' — это идентификатор объекта, он уникален, и аннотацией мы указываем, чтобы JPA сам его создавал, когда будет нужно. Можно прописать и подробности: самостоятельно дать имена полям и таблице, указать типы полей и т. п., но пока оставим все это на усмотрение JPA.

Расширим микробиблиотеку, введя туда микрочитателей. Предположим, что один читатель может читать только одну книгу.

<source lang=java>
@Entity
public class Reader implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Long Id;
public String Name;
@OneToOne
public Book Book;
}
</source>

Аннотация '''@OneToOne''' обозначает, что связь между '''Reader''' и '''Book''' — один к одному. Физически эта связь будет реализована посредством внешнего ключа в таблице.

Возникает вопрос: а в какой таблице будет прописана связь (создан внешний ключ)? В '''Book'''? Или в '''Reader'''? Нужно как-то определиться, чтобы более четко понимать, что происходит в системе — иначе как ошибки-то искать? Для этого пропишем ссылку на '''Reader'''’а в книге, плюс укажем аннотацией, с какой стороны должна быть ссылка в БД. Теперь книга выглядит так:

<source lang=java>
@Entity
public class Book implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Long Id;
public String Title;
public String Author;
@OneToOne(mappedBy = “Book”)
public Reader Reader;
}
</source>

Параметр аннотации '''@OneToOne mappedBy''' показывает, что указанное поле в БД (в таблице Book) не существует, а извлекается из таблицы, на которую указывает связь, то есть '''Reader'''.

{{Врезка
|Заголовок=Как рекомендуется создавать бины
|Содержание=После деплоймента (установки и развертывания) бина микробиблиотеки, JPA автоматически создал все необходимые таблицы, связи между ними и так далее. Казалось бы, это счастье. Пишем код, JPA делает таблицы – все довольны... Но не так все просто.
Во-первых, зачастую таблицы уже есть. Во-вторых, далеко не всегда разработчики, которые создают бины, умеют хорошо создавать таблицы. В третьих, иногда таблицы и бины создают разные люди.

И это правильно. Нехорошо, если разработчик «и швец, и жнец, и на дуде игрец» (то есть хорошо, конечно, но где ж их взять в достаточном для пропитания количестве?). Правильный путь разработки структуры данных – когда сначала создается структура таблиц в СУБД, правильно прописываются связи, при необходимости реализуются триггеры и другие особенности, связанные с СУБД, и только потом на этой основе создаются бины, объекты, связи между ними. JPA рассчитан именно на такое применение и, в принципе, умеет не только создавать структуру СУБД по Java-файлам, но и наоборот, создавать классы по базе. Стоит это учитывать. Иначе часто получается, что «хотели как лучше, а получилось как всегда», или «что тут этот дурак JPA насоздавал – я совсем не то имел в виду; да и тормозит всё».
|Ширина=200px}}

=== Третий бин ===

Создав бины для хранимых сущностей (Entity Beans), нужно сделать бин для работы с ними: извлечения из СУБД, сохранения, выдачи книги и возврата ее обратно в библиотеку.

Для экономии места не будем увлекаться всевозможными проверками (например, выдана ли книга повторно), сосредоточимся на JPA и EJB3.

Как и в предыдущий раз, сначала интерфейс:

<source lang=java>
@Remote
public interface Library {
public void addBook(Book aBook);
public void addReader(Reader aReader);
public void giveBook(String aReaderName, Book aBook);
public void returnBook(String aReaderName);
public Reader getReader(String aReaderName);
public Book getBook(String aBookTitle);
}
</source>

Потом его реализация (и на ней остановимся поподробнее):

<source lang=java>
@Stateless
public class LibraryBean implements Library {
@PersistenceContext
private EntityManager _entityManager;
public Book addBook(Book aBook) {
_entityManager.persist(aBook);
return aBook;
}
public Reader addReader(Reader aReader) {
_entityManager.persist(aReader);
return aReader;
}
public void giveBook(String aReaderName, Book aBook) {
getReader(aReaderName).Book = aBook;
}
public void returnBook(String aReaderName) {
getReader(aReaderName).Book = null;
}
public Reader getReader(String aReaderName) {
return (Reader) _entityManager.createQuery(
“SELECT r FROM Reader AS r WHERE r.Name = :name”).
setParameter(“name”, aReaderName).getSingleResult();
}
public Book getBook(String aBookTitle) {
return (Book) _entityManager.createQuery(
“SELECT b FROM Book AS b WHERE b.Title = :title”).
setParameter(“title”, aBookTitle).getSingleResult();
}
}
</source>

Тут есть два интересных момента. Первый — '''@PersistenceContext'''. Это так называемый контекст сохранения объектов, в котором обретается все то, что должно «жить» между перезапусками приложения (то есть записываемое в БД). Он нигде не инициализируется явно, так как эту работу берет на себя JPA.

У этого контекста есть несколько (не так много, как могло бы быть) методов, которые позволяют сохранять ('''persist''') и удалять ('''remove''') объекты. Но нет метода, который позволял бы обновлять объекты… Почему? Посмотрим более внимательно на метод '''giveBook''', который «выдает книгу» читателю. Мы просто извлекаем читателя, присваиваем ему ссылку на книгу… и все. Контекст сохранения сам обновит объект в БД. Не правда ли, просто?

И последний интересный момент: запросы. Несмотря на то, что они очень похожи на ''SQL'', это совсем не ''SQL''. Это ''JPQL'' (Java Persistence Query Language), который оперирует не столбцами, но объектами. Например, предположим на минутку, что разные экземпляры одной и той же книги могут читать сразу несколько читателей (связь '''OneToMany'''). Тогда найти всех людей, которые держат книгу с определенным названием, можно так:

<source lang=java>
SELECT r FROM Reader AS r WHERE r.Book.Title=:title
</source>

На ''SQL'' нам пришлось бы выполнить '''JOIN''', учесть внешние ключи и так далее. Здесь все это будет сделано автоматически.

Мало того, контекст заботится и о транзакциях. Он сам открываеттранзакцию перед входом в методы и сам же закрывает ее после выхода. Естественно, используя JTA (Java Transaction API), это можно контролировать вручную, если есть необходимость.

=== Собираем, запускаем ===

Собрать jar-файл, чтобы положить его в ''JBoss'', можно аналогичным образом: скомпилировать, собрать jar и поместить его в каталог '''deploy'''. Но при этом нужно сделать пару вещей, которые позволят JPA автомтически создать структуру таблиц при запуске бина. Для этого необхо димо перейти в каталог '''jboss/server/default/deploy/ejb3.deployer/META-INF''' и в файле '''persistence.properties''' убрать комментарий (решетку) перед строкой

<source lang=java>
hibernate.hbm2ddl.auto=create.
</source>

После чего перезапустить ''JBoss'', скинуть jar… бины встали на место. Попробуем простенький клиент для проверки. Основной код остался тем же, что и у клиента калькулятора, поменялся только метод '''start'''.

<source lang=java>
private void start() throws NamingException {
_library = (Library) getInitialContext().
lookup(“LibraryBean/remote”);
Book book = new Book();
book.Title = “Linux strikes back”;
book.Author = “Community org.”;
book = _library.addBook(book);
Reader reader = new Reader();
reader.Name = “Hacker I.A.”;
_library.addReader(reader);
_library.giveBook(“Hacker I.A.”, book);
reader = _library.getReader(“Hacker I.A.”);
System.out.println(“У читателя \”” + reader.Name + “\” “ +
“есть книга \”” + reader.Book.Title + “\””);
}
</source>

Запустите его и убедитесь, что все работает, как надо.

=== Вместо заключения ===

Заключения тут не получится. Мы рассмотрели только камень на вершине айсберга, который называется EJB3. Чтобы только перечислить, что же оно может, нужно раз в 5-10 больше места. А чтобы разобраться, нужно потратить не одну неделю. Поэтому хочется просто отметить, что, в отличие от стандарта EJB2, который использовать очень и очень трудно, EJB3 использовать можно и нужно. Есть надежда, что скоро все основные сервера приложений будут поддерживать EJB3 в полном объеме, что позволит быстро и просто разрабатывать сложные, надежные и производительные приложения, рассчитанные на работу в системах уровня предприятия. Если вы заинтересовались данной темой, и хотите узнать про EJB3 побольше, обратите внимание на врезку '''Литература'''. Удачного освоения! '''LXF'''

=== Литература ===

К сожалению, про EJB3 пока очень мало что написано на русском языке. Но на английском есть несколько книг, из которых хочется порекомендовать следующие:

* Raghu R. Kodali, Jonathan R. Wetherbee, Peter Zadrozny. Beginning EJB 3 Application Development: From Novice to Professional (ISBN 1590596714).
* Mike Keith, Merrick Schincariol. Pro EJB 3: Java Persistence API (ISBN 1590596455).

Книги написаны приличным языком, со знанием дела (авторы участвовали в разработке стандартов и работают в компаниях, которые сами используют EJB3), читать их достаточно легко.

Ну, и, конечно, нельзя не указать на сами стандарты:
* http://java.sun.com/products/ejb/
* http://java.sun.com/products/ejb/docs.html
* http://java.sun.com/javaee/technologies/persistence.jsp

Файл:JavaEE LXF99.tar.gz

2009-01-01T07:43:37Z

Dionysius: Код урока JavaEE LXF99

Код урока JavaEE LXF99

LXF98:Java EE

2009-01-01T07:40:17Z

Dionysius: /* <font color=darkred>Struts</font>, великий и ужасный */

{{Цикл/Java EE}}
==<font color=darkred>Struts</font>, великий и ужасный==

[[Media:JavaEE_LXF98.tar.gz‎|Скачать исходный код примера]]

''<font color=darkred>'''ЧАСТЬ 10'''</font> Компьютеры были придуманы, чтобы избавить человечество от рутины – так зачем делать вручную то, что можно сгенерировать автоматически? '''Александр Бабаев''' покажет, как Struts позволяет избежать монотонного кодирования приложений J2EE.''

Вручную делать простые вещи хорошо: быстро, просто, понятно. Но что делать, если нужно так же быстро и просто создать нечто большое? Сайт-портал, например? Не тот портал, который Яндекс, а корпоративный – где интегрирована система хранения документов, информационная система, наша адресная книга?

В PHP в этом случае приходит на помощь ''CMS''. Сладкие слова, которые обещают «в два клика» сделать вам все что угодно. Маркетинг, конечно, страшная сила, но почему так много ''CMS'' на PHP, и нет на ''Java''?

Возможно, просто потому что не нужно. Место ''CMS'' в ''Java'' занимают разнообразные инструментарии разработчика, которые помогают обходить сложные и рутинные работы. В результате можно небольшими силами сделать систему, по сложности намного превосходящую то, что можно сделать «вручную».

===Что включается в Struts?===

''Struts'' не изобретает велосипедов. В его основе лежит шаблон «MODEl-View-Controller», который мы рассматривали в [[LXF92:Java EE|LXF92]], но с его помощью проще создать грамотное приложение, так как четко определены задачи по его созданию; проще разобраться, что необходимо написать для получения результата.

Итак, ''Struts'' (будем рассматривать более простую, первую версию) содержит:

*''API'' для создания обработчика запросов (менеджер, распределяющий запросы по действиям) и для создания самих действий (<font color=darkred>Actions</font>).
*''API'' для создания обработчиков форм.
*''API'' для работы с проверкой корректности заполнения (валидации) форм.
*''Tiles''. Расширение для создания модульных страниц (что-то «вроде SSI»).
*''JSP-taglib'', библиотека ''JPS''-тэгов для упрощения написания JSP-страниц.
*''XML''-конфигурационные файлы, для простой и быстрой настройки всего вышеперечисленного и связи его друг с другом.

Все это в предыдущих статьях мы делали вручную. Теперь настало время проделать то же самое более «технологично».

===Как этим пользоваться?===

Во-первых, библиотеку нужно скачать. Это можно сделать со странички http://struts.apache.org/download.cgi#struts138. После чего следует распаковать полученный файл и вытащить оттуда все JAR-архивы.

В качестве примера, создадим уже знакомую телефонную книгу. Сперва каталог; в нем, как всегда, организуем подкаталоги для исходных текстов, скомпилированного кода, библиотек и JSP-файлов. Получится что-то такое:

*'''libs'''
**''antlr-2.7.2.jar''
**''bsf-2.3.0.jar''
**''commons-beanutils-1.7.0.jar''
**''commonschain-1.1.jar''
**''commons-digester-1.8.jar''
**''commons-fileipload-1.1.1.jar''
**''commons-io-1.1.jar''
**''commons-logging-1.0.4.jar''
**''commons-validator-1.3.1.jar''
**''jstl-1.0.2.jar''
**''oro-2.0.8.jar''
**''standart-1.0.2.jar''
**''struts-core-1.3.8.jar''
**''struts-el-1.3.8.jar''
**''struts-extras-1.3.8.jar''
**''struts-faces-1.3.8.jar''
**''struts-mailreader-dao-1.3.8.jar''
**''struts-scripting-1.3.8.jar''
**''struts-taglib-1.3.8.jar''
**''struts-tiles-1.3.8.jar''
*'''out'''
*'''src'''
**''MessageResources_en.properties''
**''MessageResources_ru.properties''
**'''ru'''
*'''web'''
**''index.jsp''
**'''pages'''
**'''WEB-INF'''

Затем в каталог библиотек нужно положить JAR-файлы ''Struts''. Готово? Тогда можно приступать к кодированию.

Когда запрос приходит в сервлет, он первым делом попадает в ''Struts'', который перенаправляет его в менеджер запросов (<font color=darkred>ActionServet</font>) и далее в нужное действие (<font color=darkred>Action</font>). Это происходит примерно так:

Как видно, схема здорово напоминает примененную нами при создании адресной книги. Зачем тогда ''Struts''? А затем, чтобы не писать много-много однотипного кода, который повторяется из проекта в проект.

===Конфигурационные файлы===

Вначале научимся запускать ''Struts''. Для этого нужно перенаправить все запросы сервлету-обработчику и написать файл конфигурации. Вот
простой дескриптор для простого ''Struts''-приложения:
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<web-app>
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
</web-app>
</source>
Видно, что все запросы <font color=darkred>*.do</font> передаются сервлету <font color=darkred>action</font>, обрабатываемому классом <font color=darkred>ActionServlet</font>. Это стандартный класс Struts, который перенаправляет запросы в действия. Ему передается конфигурационный файл '''struts-config.xml'''. Вот он:
<source lang="xml">
<?xml version="1.0" encoding="UTF-8" ?>
<struts-config>
<form-beans>
<form-bean name="addForm" type="org.apache.struts.validator.DynaValidatorForm">
<form-property name="name" type="java.lang.String" initial="Name"/>
<form-property name="phone" type="java.lang.String" initial="1234567"/>
<form-property name="age" type="java.lang.Integer" initial="20"/>
<form-property name="comment" type="java.lang.String" initial="NoComment"/>
</form-bean>
<action-mappings>
<action path="/add" name="addForm" validate="true" type="ru.linuxformat.actions.Add">
<forward name="form" path="/pages/Add.jsp"/>
<forward name="done" path="/list.do"/>
</action>
<action path="/list" type="ru.linuxformat.actions.ShowAll">
<forward name="ok" path="/pages/List.jsp"/>
</action>
</action-mappings>
<message-resources parameter="MessageResources"/>
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames" value="/org/apache/struts/validator/validator-rules.xml,/WEB-INF/validation.xml"/>
</plug-in>
</struts-config>
</source>
В данном файле описана форма добавления контакта (<font color=darkred>form-bean</font>), с использованием стандартного класса формы с поддержкой автоматической проверки полей (<font color=darkred>DynaValidatorForm</font>).

После этого описано, какие запросы в какие классы перенаправляются.
<source lang="xml">
<action path="/list" type="ru.linuxformat.actions.ShowAll">
<forward name="ok" path="/pages/List.jsp"/>
</action>
</source>
В этом примере запрос <font color=darkred>/list.do</font> пойдет в класс <font color=darkred>ShowAll.Forward</font> используется внутри действия, чтобы упростить перенаправление вывода. Дальше будет понятно, как.

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

===Действия===

Перейдем к классам. Все они должны быть унаследованы от класса <font color=darkred>org.apache.struts.action.Action</font>. При этом в простейшем случае нужно переопределить только один метод, <font color=darkred>execute(…)</font>. Например, вот действие, которое показывает список контактов:
<source lang="java">
public class ShowAll extends Action {
public ActionForward execute(ActionMapping aActionMapping,
ActionForm aActionForm,
HttpServletRequest aHttpServletRequest,
HttpServletResponse aHttpServletResponse)
throws Exception {
aHttpServletRequest.setAttribute("contacts",
Contacter.getInstance().getContactsSortedByName());
return aActionMapping.findForward("ok");
}
}
</source>
В этом действии в атрибут запроса кладется список всех контактов, после чего вызывается форвард <font color=darkred>"ok"</font> – именно он был описан чуть выше.
<source lang="xml">
<action path="/list" type="ru.linuxformat.actions.ShowAll">
<forward name="ok" path="/pages/List.jsp"/>
</action>
</source>
Из описания видно, что форвард перенаправляет обработку запроса в '''List.jsp''. Посмотрим, что в нем написано:
<source lang="xml">
<%@ page pageEncoding="UTF-8" language="java" contentType="text/
html; utf-8" %>
<%@ taglib uri="http://struts.apache.org/tags-html" prefix="html" %>
<%@ taglib uri="http://struts.apache.org/tags-bean" prefix="bean" %>
<%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic" %>
<html:html>
<head>
…
</head>
<body>
…
<table border="1">
<tr>
<td><bean:message key="AddressBook.list.name"/></td>
<td><bean:message key="AddressBook.list.phone"/></td>
<td><bean:message key="AddressBook.list.comment"/></td>
<td><bean:message key="AddressBook.list.age"/></td>
</tr>
<logic:iterate id="contact" type="ru.linuxformat.Contact"
name="contacts" scope="request">
<tr>
<td><%=contact.getName()%></td>
<td><%=contact.getPhone()%></td>
<td><%=contact.getComment()%></td>
<td><%=contact.getAge()%></td>
</tr>
</logic:iterate>
</table>
</body>
</html:html>
</source>
На многоточия заменены неинтересные куски кода, а интересное – в самом начале листинга (<font color=darkred>taglib</font>). Это так называемые библиотеки тэгов. Примеры можно видеть здесь же. Скажем, <font color=darkred><bean:messagekey="AddressBook.list.name"/></font> вставляет локализованную строку, соответствующую данному ключу. А <font color=darkred><logic:iterate></font> умеет итерировать по коллекциям (списки, ассоциативные массивы и так далее). В данном случае мы итерируем по атрибуту запроса <font color=darkred>contacts</font>, который мы положили туда в действии.

===Формы, проверка корректности форм===

Другая интересная часть – формы. Второе действие, добавление контакта, выглядит следующим образом (приведен только код метода <font color=darkred>execute</font>):
<source lang="java">
if (aHttpServletRequest.getParameter("name") == null) {
return aActionMapping.findForward("form");
} else {
DynaActionForm form = (DynaActionForm) aActionForm;
Contacter.getInstance().addContact(form.getString("name"), form.
getString("phone"), form.getString("comment"), (Integer) form.
get("age"));
return aActionMapping.findForward("done");
}
</source>
Логика очень похожа на ту, что была в предыдущих статьях. Если форма не заполнена, переходим по форварду <font color=darkred>form</font>, который показывает форму для ввода. Если она заполнена (и валидирована), то контакт добавляется в список, и мы переходим на форвард <font color=darkred>done</font>. Вот и сама форма (точнее, ее основная часть):
<source lang="xml">
<html:form action="/add" method="post" onsubmit="return
validateAddForm(this);">
<table>
<tr>
<td><bean:message key="AddressBook.add.name"/>:</td>
<td><html:text property="name"/></td>
</tr>
…
<tr>
<td colspan="2"><html:submit titleKey="AddressBook.add.
submit"/></td>
</tr>
</table>
</html:form>
<html:javascript formName="addForm"/>
</source>
Тут интересны два момента. Во-первых, используются тэги ''Struts'' (<font color=darkred>html:…</font>), упрощающие создание компонентов формы. Во-вторых, используется скрипт валидации (<font color=darkred>onsubmit="…"</font> и <font color=darkred><html:Javascript …></font>). Он обеспечивает валидацию прямо в браузере, не отсылая запрос на сервер.

Сами правила валидации задаются в файле '''validation.xml'''. Вот как это выглядит:
<source lang="xml">
<form-validation>
<formset>
<form name="addForm">
<field property="age" depends="required,integer,intRange">
<arg key="AddressBook.add.age"/>
<arg position="1" name="intRange" key="10"
resource="false"/>
<arg position="2" name="intRange" key="20"
resource="false"/>
<var><var-name>min</var-name><var-value>10</var-value></
var>
<var><var-name>max</var-name><var-value>20</var-value></
var>
</field>
</form>
</formset>
</form-validation>
</source>
Форму я создал в '''struts-config'''. Называться она должна так же. Для поля <font color=darkred>age</font> задается три правила валидации: <font color=darkred>required</font>, <font color=darkred>integer</font>, <font color=darkred>intRange</font>. Первое говорит, что поле обязательно, второе – что значение должно быть целочисленным, третье правило сообщает, что значение должно лежать в пределах от 10 до 20. В качестве параметров задаются аргументы сообщений, которые будут выводиться при ошибочном заполнении формы (<font color=darkred>arg</font>), и параметры для правил валидации (<font color=darkred>var</font>).

===Локализация===

Последняя часть, пока не описанная – локализация. Сообщения хранятся в так называемых properties-файлах, причем если property-файл называется '''MessageResources''', то, например, файл русской локализации должен называться '''MessageResources_ru.properties''', а английской – '''MessageResources_en.properties'''. Если нужно уточнить – например, английский язык, Америка – то получается так: '''MessageResources_en_US.properties'''.

Структура файлов '''properties''' очень проста. Каждая строка (не пустая и не комментарий) состоит из двух частей, разделенных знаком равенства (<font color=darkred>=</font>). Слева – ключ, справа – значение этого ключа.

Эти файлы нужно положить в каталог '''src''', и проконтролировать, чтобы они переписались туда же, куда попадают class-файлы. Плюс, для неанглийских
файлов, их нужно преобразовать в ASCII-формат. Это делается утилитой ''native2ascii'' из поставки JDK. Инструкции по пользованию утилитой можно найти здесь: http://Java.sun.com/Javase/6/docs/technotes/tools/windows/native2ascii.html.

После этого можно использовать в JSP вставки вида <font color=darkred><bean:message key="AddressBook.add.name"/></font>, вместо которых будет вставлена локализованная строка, соответствующая данному ключу (в примере – <font color=darkred>AddressBook.add.name</font>).

===Что дальше?===

''Struts'' – великолепная библиотека, позволяющая упростить разработку сложных приложений. Особенно хорошо такого рода библиотеки подходят для задач, в которых много монотонной работы: больших форм, большого количества простых действий, необходимость проверки данных, вводимых в форму, локализация.

Также полезно, что используются стандартные средства: ''JSP'', ''Servlets'', да и сам ''Struts'' – самая распространенная библиотека для такого рода работ. В результате при приеме на работу, например, знание именно ''Struts'' позволяет набрать несколько дополнительных баллов.

Правда, еще больше баллов дает знание ''EJB3''. Но об этом мы поговорим в следующей, заключительной статье.

Файл:JavaEE LXF98.tar.gz

2009-01-01T07:39:31Z

Dionysius: Код урока JavaEE LXF98

Код урока JavaEE LXF98

LXF97:Java EE

2009-01-01T06:46:19Z

Dionysius: /* Почтовый сервис */

{{Цикл/Java EE}}
[[Категория:Учебники]]
==Почтовый сервис==

[[Media:JavaEE_LXF97.tar.gz‎|Скачать исходный код примера]]

: '''ЧАСТЬ 9''' Хотите оснастить свою программу возможностью писать «на деревню дедушке»? '''Александр Бабаев''' знает подходящее средство.

Несмотря на засилье браузера в серии, JEE им не ограничивается. Давайте попробуем посылать письма из Java (ведь каждая хорошая программа должна уметь сообщать разработчикам об ошибках), и сделаем это приложение не браузерным, а «обычным».

===Коротко о почте===

Чтобы работать с почтой, нужно уметь её отправлять и получать. При попытке разобраться в этом вы наткнетесь на следующие буквосочетания (с разными вариациями): '''SMTP, POP, IMAP'''. Рассмотрим кратко, что это такое и как этим пользоваться (а также где почитать поподробнее).

* '''SMTP'''
При помощи Simple Mail Transfer Protocol (простого протокола передачи почты) почта передается с клиента на сервер. Отправляется то есть. Протокол текстовый, и если есть желание, можно отправлять письма прямо из telnet’а.

* '''POP'''
Тоже текстовый протокол, но уже не для передачи, а для приема сообщений. Может выдать информацию по почтовому ящику (сколько
сообщений, какой их размер), загрузить сообщение по номеру и так далее.

* '''IMAP'''
'''POP''' предполагает, что почта скачивается на клиент и там уже раскладывается по папкам, обрабатывается, группируется. При этом с сервера сообщения стираются. Это не всегда удобно. Как раз для хранения почты на сервере создан протокол '''IMAP'''. Как и предыдущие два, он текстовый. Но с его помощью можно не только получить сообщения, но и создать на сервере папку, переместить письмо куда-нибудь, подписаться на получение изменений (новых писем) в папке, и так далее.

* '''GoogleMail/HotMail/…'''
Но и это не всё. Протоколы протоколами, но некоторые сервисы работают «по-своему». И если '''GoogleMail''' предоставляет '''POP'''-интерфейс, то '''Hotmail''', например, нет. В таком случае обычно есть какой-то свой, нестандартный протокол.

===Итого===

В итоге получается, что разных протоколов много-много (это не считая вариантов и нюансов, комбинаций которых сотни). И чтобы по-человечески все это обрабатывать, пришлось писать бы огромное количество кода. А потом его отлаживать… Поэтому обычно, рассматривая сетевые приложения, отправку/получение писем обходят стороной. Действительно, зачем? Кому нужно, и так разберется.

Но в Java, как всегда, уже позаботились о том, чтобы упростить жизнь человеку, которому нужно рассылать письма – позаботились на самом высшем уровне (в Sun Microsystems) и достаточно качественно.

===И где волшебная кнопка?===

Есть такая замечательная библиотека, '''JavaMail'''. Она достаточно крупная (224 килобайта только JAR-файл), зато и умеет очень много. А чего не умеет – можно научить, благо архитектура настраиваемая. Давайте посмотрим, как с ней работать.

===Подготовка===

Для начала скачаем саму библиотеку. Страничка продукта находится по адресу http://java.sun.com/products/javamail/; скачивать нужно, как водится, последний релиз (1.4). Также понадобится JavaBeans Activation Framework (JAF), которую можно загрузить со странички рядом: http://java.sun.com/products/javabeans/jaf/index.jsp.

После загрузки и разархивирования, получаем две библиотеки: '''mail.jar''' и '''activation.jar'''. Первая из них поддерживает все возможные протоколы, поэтому размер имеет достаточно внушительный. Если что-то из этого многообразия вам не нужно, можно воспользоваться урезанными версиями, они также содержатся в '''mail.jar'''.

Создадим каталог для проекта ('''QuickMailer'''), в нем заведем подкаталог '''libs''' и положим туда эти два jar-файла. Потом заведем другой подкаталог ('''src'''), для записи исходных текстов.

===Окошки===

Сделаем окошко для отправки сообщения. Оно будет простое, как на рис. 1.
[[Изображение:LXF97_JAVA1.jpg|Рис. 1. Окно создания и отправки сообщений.]]

Подробно рассказать про то, как создаются формы, не хватит места. Но привести код, создающий такое окошко – запросто.

<source lang="java">
import javax.swing.*;
import javax.swing.border.EmptyBorder;
import java.awt.*;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
public class QuickMailerForm extends JFrame {
private JTextField _fieldTo;
private JTextField _fieldSubject;
private JEditorPane _message;
private JButton _buttonSend;
public QuickMailerForm() throws HeadlessException {
setTitle(“Быстро Мэйлер”);
setDefaultCloseOperation(EXIT_ON_CLOSE);
createLayout();
createActions();
pack();
setSize(700, 560);
Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
setLocation((int) (screenSize.getWidth() - 700)/2, (int) ((screenSize.getHeight() - 560)/2));
}
}
</source>

Как видно, класс наследуется от '''JFrame''', это окно приложения. Имеется конструктор, где окну присваивается заголовок, устанавливается размер и положение в середине экрана. Также есть две функции: первая создает компоненты ('''createLayout'''), вторая «вешает» на кнопку Отправить обработчик события, который собирает информацию и вызывает метод отправки почты.

Вот как создаются компоненты формы:

<source lang="java">
private void createLayout() {
JPanel labelsPanel = new JPanel(new GridLayout(2, 1));
labelsPanel.add(new JLabel(“EMail получателя:”, JLabel.RIGHT));
labelsPanel.add(new JLabel(“Тема письма:”, JLabel.RIGHT));
JPanel buttonsPanel = new JPanel(new FlowLayout(FlowLayout.RIGHT));
_buttonSend = new JButton(“Отправить”);
buttonsPanel.add(_buttonSend);
JPanel fieldsPanel = new JPanel(new GridLayout(2, 1));
_fieldTo = new JTextField();
_fieldSubject = new JTextField();
fieldsPanel.add(_fieldTo);
fieldsPanel.add(_fieldSubject);
JPanel controlsPanel = new JPanel(new BorderLayout(5, 5));
controlsPanel.add(labelsPanel, BorderLayout.WEST);
controlsPanel.add(fieldsPanel, BorderLayout.CENTER);
JPanel mainPanel = new JPanel(new BorderLayout(5, 5));
_message = new JEditorPane(“text/rtf”, “”);
mainPanel.add(controlsPanel, BorderLayout.NORTH);
mainPanel.add(new JScrollPane(_message), BorderLayout.CENTER);
mainPanel.add(buttonsPanel, BorderLayout.SOUTH);
mainPanel.setBorder(new EmptyBorder(5, 5, 5, 5));
setContentPane(mainPanel);
}
</source>

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

Последний метод – создание обработчика события нажатия на кнопку:

<source lang="java">
private void createActions() {
_buttonSend.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
try {
QuickMailer.sendMessage(“alex@jdnevnik.com”, _fieldTo.getText(), _fieldSubject.getText(),
_message.getDocument().getText(0, _message.getDocument().getLength()));
} catch (Exception e1) {
e1.printStackTrace();
}
}
});
}
</source>

Тут все достаточно просто. Вытаскиваются параметры письма из полей, после чего вызывается некий метод '''sendMessage''', который мы сейчас и рассмотрим подробнее.

===Собственно отправка сообщения===

Предполагается, что у вас на localhost’е настроен smtp-сервер (у меня стоит ''postfix''), либо есть доступ к какому-то другому (который не требует авторизации: с ней разбираться пока не будем).

Для начала создадим адреса отправителя и получателя:

<source lang="java">
public static void sendMessage(String aFrom, String aTo, String aSubject,
String aMessageText) throws Exception {
InternetAddress from = new InternetAddress(aFrom, “From”);
InternetAddress to = new InternetAddress(aTo, “To”);
</source>

Теперь нужно настроить так называемый транспорт, который будет заниматься отправкой сообщения.

<source lang="java">
Properties props = new Properties();
props.put(“mail.transport.protocol”, “smtp”);
props.put(“mail.smtp.host”, “localhost”);
props.put(“mail.smtp.port”, “25”);
Session session = Session.getDefaultInstance(props);
Transport transport = session.getTransport();
</source>

Теперь – создадим само сообщение.

<source lang="java">
MimeMessage message = new MimeMessage(session);
message.setFrom(from);
message.setRecipient(Message.RecipientType.TO, to);
message.setSubject(aSubject, “utf-8”);
message.setContent(aMessageText, “text/plain; charset=utf-8”);
</source>

И, наконец, отошлем письмо.

<source lang="java">
transport.connect();
transport.sendMessage(message, new Address[]{to});
transport.close();
}
</source>

Как можно заметить, все предельно просто и понятно – но исключительно потому, что сам пример простой. Система достаточно мощная, чтобы справиться и с авторизацией, и с сообщениями на разныхязыках, и с вложениями файлов.

===Собираем все вместе===

Осталось только написать метод, который будет все это запускать.

<source lang="java">
public static void main(String[] args) {
QuickMailerForm form = new QuickMailerForm();
form.setVisible(true);
}
</source>

У меня после написания кода получилось два файла, '''QuickMailer.java''' и '''QuickMailerForm.java'''. Скомпилируем их (выполнив, находясь в каталоге, в котором находится '''src''' и '''libs'''):

<code>
javac -cp libs/activation.jar:libs/commons-email-1.0.jar:libs/mail.jar -encoding utf-8 -d out src/*.java
</code>

Обратите внимание на часть команды после '''-cp'''. Это указание компилятору, где искать используемые в коде классы, кроме стандартных. Часть команды после '''-d''' определяет каталог, куда будут складываться скомпилированные классы. И, наконец, так как мы создавали файлы в кодировке UTF-8 (в ней представлены исходные тексты на диске), то и в командной строке это нужно указать, иначе будет выбрана кодировка по умолчанию, а это не всегда верно.

Запустим:

<code>
cd out
java -cp .:../libs/activation.jar:../libs/commons-email-1.0.jar:../libs/mail.jar
QuickMailer
</code>

Можно отправлять письма.

===А получить?===

На новое окошко места уже не хватит. Ограничимся просмотром кода, который нужно написать для того, чтобы получить письмо, например, по протоколу '''POP'''.

<source lang="java">
Properties props = new Properties();
Session session = Session.getDefaultInstance(props, null);
Store store = session.getStore(“pop3”);
store.connect(aHost, aUserName, aPassword);
Folder folder = store.getFolder(“INBOX”);
folder.open(Folder.READ_ONLY);
Message message[] = folder.getMessages();
for (int i = 0, n = message.length; i < n; i++) {
System.out.println(i + “: “ + message[i].getFrom()[0] + “\t” + message[i].
getSubject());
}
folder.close(false);
store.close();
</source>

Данный кусок кода просто выведет список всех писем на сервере.

===Ну, а если не мудрить…===

Есть вариант и попроще. Если программа работает с почтой активно, можно использовать библиотеку наших постоянных друзей из ''apache-commons''. Называется она '''commons-email''', и ее страничка располагается по адресу http://commons.apache.org/email/. Скачав библиотеку, положим её в '''libs''', к '''mail.jar''' и компании. Теперь попробуем отправить письмо с ее помощью:

<source lang="java">
public static void sendMessageCommonsEMail(String aFrom, String aTo,
String aSubject, String aMessageText) throws EmailException {
SimpleEmail email = new SimpleEmail();
email.setHostName(“localhost”);
email.setFrom(aFrom, “From”);
email.addTo(aTo, “To”);
email.setSubject(aSubject);
email.setMsg(aMessageText);
email.send();
}
</source>

Насколько все проще и понятнее сразу стало! А если нужно файл приложить? Да пожалуйста:

<source lang="java">
public static void sendMessageWithAttachment(String aFrom, String aTo,
String aSubject, String aMessageText) throws EmailException {
EmailAttachment attachment = new EmailAttachment();
attachment.setPath(“attachments/attachment.zip”);
attachment.setDisposition(EmailAttachment.ATTACHMENT);
attachment.setDescription(“Файл-приложение к письму”);
attachment.setName(“attachment.zip”);
MultiPartEmail email = new MultiPartEmail();
email.setHostName(“localhost”);
email.setFrom(aFrom, “From”);
email.addTo(aTo, “To”);
email.setSubject(aSubject);
email.setMsg(aMessageText);
email.attach(attachment);
email.send();
}
</source>

Здесь тоже ничего сложного нет. Создать приложение в письме можно и используя только '''JavaMail''', но там это получается достаточно непросто, и длиннее раза в три-четыре.

===Про спам===

Конечно, работа с почтой не так проста, как это отражено в статье. Есть и проблема спама (а для программно отправляемых сообщений – проблема того, что оно с большой вероятностью посчитается именно спамом), и проблема корректности. SMTP-протокол, в частности, достаточно старый, и там много неточностей, неявных правил и так далее. В общем, то, что есть '''JavaMail''' – это отлично, и она очень сильно помогает при работе с почтовыми сообщениями, но панацеей тем не менее не является. Все равно нужно представлять себе, как работает протокол, какие заголовки нужно ставить, как обрабатывают сообщения разные почтовые клиенты (чтобы письмо нормально там показывалось, а не крякозябрами) и много чего еще.

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

Файл:JavaEE LXF97.tar.gz

2009-01-01T06:45:00Z

Dionysius: Код урока JavaEE LXF97

Код урока JavaEE LXF97

LXF96:Java EE

2009-01-01T06:42:03Z

Dionysius: /* Как докричаться? */

{{Цикл/Java EE}}

== Java Enterprise Edition: Перекличка серверов ==

''ЧАСТЬ 8, Отыскали пару лишних серверов и готовы написать настоящее распределенное приложение? '''Александр Бабаев''' подскажет подходящий способ.''

На этом уроке наше приложение будет усложнено ровно в два раза. Раньше сервер был один (он обрабатывал запросы пользователей и менял список записей телефонной книги), теперь добавим ему напарника. Предположим, что это выделенный сервер, который хранит данные пользователей — имена, пароли, дополнительную информацию, и мы решили связать web-сервер с этим вторым, чтобы, например, можно было по имени пользователя получить дополнительную информацию о нем.

Для удобства ссылок дадим серверам названия. Пускай наш старый называется Нео, а большой сервер с разной информацией — Матрица.

Прикинем, как все устроить. Для тестов все программы (оба сервера) будут запускаться на одном компьютере. Но, поменяв соответствующие IP-адреса (ниже мы разберемся, какие именно), можно будет запускать Нео и Матрицу на разных компьютерах одной и той же подсети. Правда, если между ними есть всякие-разные устройства вроде маршрутизаторов, шлюзов и мостов, тесты могут и не заработать. Это предупреждение! Реализовать более сложную схему взаимодействия тоже можно, но на это нам, к сожалению, не хватит журнального места, которое вполне конечно.

Итак, получается следующая топология сети:

[[Изображение:LXF96-JavaEE_1.png]]

=== Как докричаться? ===

[[Media:JavaEE_LXF96.tar.gz|Скачать исходный код примера]]

Классический способ связи двух разных программ — через файлы: одна пишет, другая читает. Например, можно сделать общий файл для записи команд, куда пишет Нео и откуда читает Матрица, и файл ответов, где запись/чтение происходят наоборот.

Способ простой, но плохой: возникает огромное количество проблем, из которых падение производительности — самая маленькая. Рассматривать его не будем.

Другой способ — связь через так называемый «сокет». Сокет — это такая штука, к которой можно присоединиться [англ. socket — «розетка»]. Сервер «открывает» сокет и «слушает» его. Клиент — подключается к серверному сокету, передает/получает данные, отключается. Затем подключается следующий клиент.

Можно представить себе сокет как телефон. Вы получаете номер абонента (открываете сокет), подключаете телефон (теперь вы слушаете сокет), вам звонят — соединяются с вашим сокетом… Ну, вроде бы понятно? Примерно так же соединяются и компьютеры. А чтобы определить, к какому конкретно сокету присоединяться, нужно знать адрес IP-компьютера и номер порта, на котором открыт сокет. Номер порта необходим, потому что на одном и том же компьютере может быть запущено несколько «слушающих» программ (серверов), и нужно, чтобы они не мешали друг другу. А клиент, с другой стороны, должен точно указать, какой именно сервер ему нужен.

Есть еще и третий способ, «каналы», но о нем мы поговорим несколько позже.

=== Сокеты ===
Итак, общая схема работы с сокетами достаточно проста. Сервер создает сокет:
<source lang="java">
ServerSocket serverSocket = new ServerSocket();
</source>
Дальше нужно открыть сокет для приема соединений. В Java это делается так:
<source lang="java">
serverSocket.bind(new InetSocketAddress("localhost", 10000));
</source>
Здесь мы говорим, что сервер будет слушать соединения, в адресе назначения которых указано «localhost» и порт 10000. Сразу отметим: чтобы создать сервер на портах с номерами, меньшими 1024, обычно нужны права суперпользователя.

Далее нужно ловить подключения. Обычно это делается в цикле (получили подключение, обработали, ждем следующее). Например, так:
<source lang="java">
while (true) {
Socket socket = serverSocket.accept();
int byteReceived = socket.getInputStream().read();
OutputStream outputStream = socket.getOutputStream();
outputStream.write(byteReceived + 1);
socket.close();
}
</source>
serverSocket.accept() ждет подключения, блокируя текущий поток, и как только оно появится, создает так называемый клиентский сокет, продолжая выполнение потока. Я читаю из потока сокета один байт, записываю в сокет его же плюс единицу и закрываю сокет.

Вот так все несложно. А как устроен клиент? Он создает сокет, пишет в него единицу, читает ответ (двойку) и выводит ее на экран. По Jav’овски это выглядит так:
<source lang="java">
Socket socket = new Socket("localhost", 10000);
socket.getOutputStream().write(1);
int result = socket.getInputStream().read();
System.out.println("Result is: " + result);
socket.close();
</source>
Здесь тоже все предельно просто, но тем не менее, работает. То есть, если создать два класса и в main первого поставить код сервера, запустить (он будет «висеть», слушая соединения), в main второго — код клиента, и запустить… Клиент выдаст 2.

=== NIO ===
Проблемы начинаются, когда соединений больше одного, когда их одновременно больше одного, когда они достаточно длительные, когда нужно принимать/отсылать громадные файлы или протокол работы сложный. Если все делать вручную, как мы сейчас, то получается очень и очень трудоемко: огромное количество потоков (рекомендуется, собственно, по одному на каждый запрос), проблемы отсоединений клиентов, отслеживания этих событий, сериализация (запись в поток и обратно) объектов, и так далее.

Еще один минус блокирующих сокетов в том, что они (простите за тафтологию) блокируют поток в ожидании подключения. А если под ключения нет? Значит, поток заблокирован навсегда. И дело не только в подключениях, но и в записи/чтении в/из сокета: случись что во время этих операций — заблокируют навсегда. Вдобавок при большом количестве соединений/потоков скорость работы сервера уменьшается гораздо быстрее, чем увеличивается количество соединений. То есть имеет место типичная ситуация плохой масштабируемости.

И тут на помощь приходит новый способ обработки соединений — NIO (The new I/O API), хотя и более сложный, но гораздо более масштабируемый. Эта библиотека появилась в Java 1.4, и она позволяет создавать неблокирующие соединения. Рассмотрим тот же сервер и клиент в реализации NIO.. Сначала создадим так называемый «канал»:
<source lang="java">
Selector acceptSelector = SelectorProvider.provider().openSelector();
ServerSocketChannel socketChannel = ServerSocketChannel.open();
socketChannel.configureBlocking(false);
</source>
Мы не просто создали канал, но еще и объявили его неблокирующим (работа с блокирующими каналами ничуть не лучше работы с блокирующими сокетами). Теперь нужно «объяснить» каналу, какие события нам интересны (присоединение клиента, чтение, запись, отсоединение). Займемся подсоединением клиента:
<source lang="java">
socketChannel.socket().bind(new InetSocketAddress("localhost", 10000));
socketChannel.register(acceptSelector, SelectionKey.OP_ACCEPT);
</source>
Теперь начинаем волшебный цикл обработки. В цикле проверяем, есть ли интересующие нас события в «канале», и если есть, итерируем по ним, получая клиентский сокет. Дальше с сокетом работаем так же, как было описано выше.
<source lang="java">
while (acceptSelector.select() > 0) {
Set readyKeys = acceptSelector.selectedKeys();
Iterator i = readyKeys.iterator();

while (i.hasNext()) {
SelectionKey key = (SelectionKey) i.next();
i.remove();
ServerSocketChannel nextReady = (ServerSocketChannel) key. channel();
Socket socket = nextReady.accept().socket();
outputInputPlusOne(socket);
}
}
</source>
Функция outputInputPlusOne(socket), как мы делали ранее, читает число, увеличивает его на 1 и записывает результат. При этом поток постоянно крутится в цикле, не блокируясь. Это позволяет использовать достаточно интересные методы обработки подключений: например, создавать только один поток для произволь ного количества подключений, и он один будет их все обрабатывать. Плюс, операции чтения и записи тоже можно сделать неблокирующими, и совсем будет сказка… Если бы не сложность. Переход на неблокирующую обработку подключений — увеличение объема программы в три раза. Неблокирующая запись и чтение — еще больше. В результате получается достаточно громоздкая схема. Увы, только так можно добиться хорошей производительности.

=== Минное поле ===
Но есть замечательная библиотека, где все это уже учтено. Внутри она использует NIO, поэтому отлично масштабируется. Зато наружу выходят очень простые и понятные методы, которые можно использовать, получая превосходный результат. Библиотека называется Apache Mina, она достаточно широко распространена (например, Jetty, который мы рассматривали в первой статье цикла, использует именно ее) и неплохо отлажена. Иными словами, ею можно пользоваться в «промышленных» масштабах, не особо беспокоясь о проблемах.
Сервер делается так:
<source lang="java">
SocketAcceptorConfig acceptorConfig = new SocketAcceptorConfig();
acceptorConfig.getFilterChain().addLast("Serializator", new ProtocolCodecFilter(new ObjectSerializationCodecFactory()));
DataServerHandler handler = new DataServerHandler();
SocketAcceptor acceptor = new SocketAcceptor();
acceptor.bind(new InetSocketAddress("localhost", 10000), handler, acceptorConfig);
</source>
В первой строчке создается конфигуратор (через него задаются разные параметры подключения), затем в него вставляется фильтр, через который пройдут все данные (фильтр распаковывает объекты Java из потока). В третьей строке создается обработчик событий (о нем чуть ниже), который обрабатывает события Mina, и дальше — инициализируется сервер (опять тот же bind).

Поскольку Mina использует NIO, сервер получается событийный. При подключении клиента вызывается обработчик (Handler), который обслуживает запрос. При поступлении данных — тоже вызывается Handler (уже другой метод). И так далее. Вот как выглядит обработчик — (Handler) в нашем случае:
<source lang="java">
public class DataServerHandler extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message)
throws Exception {
if (message instanceof Integer) {
session.write(((Integer) message) + 1);
session.close();
}
}
}
</source>
Мы переопредили только один метод, который отвечает за получе ние данных. Mina работает не с потоками, а с объектами (преобразованием занимается фильтр, который мы вставляли в конфигуратор). Поэтому наша задача упрощается: читаем Integer, прибавляем единицу, записываем обратно, закрываем сессию. Все.

Предыдущий клиент, правда, не подойдет — нужно создавать другой. Но он не сложнее, чем был. Вот его код:
<source lang="java">
SocketConnector connector = new SocketConnector();
SocketConnectorConfig config = new SocketConnectorConfig();
config.getFilterChain().addLast("Serializator", new ProtocolCodecFilter(new ObjectSerializationCodecFactory()));
ConnectFuture connectFuture = connector.connect(new InetSocketAddress("localhost", 10000), new DataClientHandler(), config);
connectFuture.join();
IoSession session = connectFuture.getSession();
session.write(new Integer(1));
</source>
Код клиента — практически точное повторение кода сервера. Даже обработчик есть. Только вместо Acceptor’а создаем Connector. connectFuture — это объект, который позволяет, во-первых, дождаться, пока присоединимся (.join()), а во-вторых, от него получается сессия, куда можно писать всякие объекты (в нашем случае — Integer). Обработчик, как и на сервере, простой:
<source lang="java">
public class DataClientHandler extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message)
throws Exception {
System.out.println("Result is: " + message.toString());
}
}
</source>
Все. Сложность в данном конкретном случае — четыре класса вместо двух. Но это оправданно. Mina позволяет гибко настраивать обработку данных, бегающих между клиентом и сервером: количество потоков, обрабатывающих каналы, и так далее. Все это позволяет создавать простые серверы буквально за минуты, а сложные — за считанные часы или за несколько дней.

=== RMI ===
Еще один способ соединения двух Java-программ — RMI (Remote Method Invocation, удаленный вызов метода). Это несколько другой класс соединений, который скрывает сокеты и прочую внутреннюю механику от программиста, но требует понимания совершенно других принципов.

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

После этих магических пассов методы сервера можно вызывать, как будто они находятся прямо в клиенте, в той же Java-машине. А RMI сам понимает, что вызван метод сервера, организует передачу/прием данных, преобразования всего из всего и выдает результат. На Рис. 2 приведена схема работы RMI (исключая registry):

[[Изображение:LXF96-JavaEE_2.png]]

При создании класса, который может быть вызван удаленно (схема, когда обращаются непосредственно к методу, а он скрытыми путями вызывается на удаленной машине, называется удаленным вызовом, Remote Procedure Call), генерируются специальные классы-заглушки (stubs). Они-то и делают все «взмахи волшебными палочками». На самом деле, когда клиент выполняет удаленный вызов, вызывается аналогичный серверному метод заглушки. В этом методе параметры сериализуются и через сокет передаются на сервер, где вновь десериализуются, вызывается сервер, а ответ передается таким же образом (через заглушки) клиенту.
Чтобы RMI заработал, нужно сделать интерфейс для сервера и его реализацию, написать клиент, потом сгенерировать заглушки, все скомпилировать и запустить.
Интерфейс сервера прост:
<source lang="java">
public interface IRMIServer extends Remote {
public abstract int increment(int aValue) throws RemoteException;
}
</source>
Он должен наследоваться от интерфейса Remote, и все методы, вызываемые удаленно, должны выбрасывать исключение RemoteException. Реализация сервера не менее проста:
<source lang="java">
public class RMIServer implements IRMIServer {
public RMIServer() throws RemoteException {
super();
}

public int increment(int aValue) throws RemoteException {
return aValue + 1;
}
}
</source>
Реализация должна обязательно иметь конструктор по умолчанию, который выкидывает исключение RemoteException и вызывает super(). Метод реализуется как обычно.
Регистрация сервера может быть выполнена, например, в методе main того же сервера:
<source lang="java">
public static void main(String[] args) throws Exception {
System.setSecurityManager(new RMISecurityManager());
RMIServer Server = new RMIServer();
Naming.rebind("RMIServer" , Server);
}
</source>
Здесь устанавливается менеджер безопасности (иначе нам скажут, что нет прав для работы с RMI), создается сервер и регистрируется в registry (rebind). Есть и метод bind, но он выдаст ошибку, если такой сервер уже зарегистрирован. В целях экономии места используем rebind, который проверку на существование такого же сервера не выполняет.

Клиент тоже устанавливает менеджер безопасности, после чего в registry ищет сервер (имя он знает). Как только найдет — просто вызывает метод, как если бы RMI не существовало.
<source lang="java">
public class RMIClient {
public static void main(String[] args) throws MalformedURLException,NotBoundException, RemoteException {
System.setSecurityManager(new RMISecurityManager());
String url = "//localhost/RMIServer";
IRMIServer remoteObject = (IRMIServer) Naming.lookup(url);
System.out.println("Result is " + remoteObject.increment(1));
}
}
</source>
Запуск сервера и клиента несколько более сложен, чем обычно. До сих пор мы компилировали и запускали классы «просто так». Теперь создадим заглушки и запустим registry. Это делается так:
rmic RMIServer

создаст заглушку сервера (сначала нужно все скомпилировать, а потом выполнить эту команду с полным именем класса сервера). А команда
rmiregistry &

запустит RMI Registry с параметрами по умолчанию. Чтобы разрешить менеджеру безопасности делать все что угодно, нужно запустить клиент и сервер с параметром, указывающим на файл политики безопасности. Назовем этот файл open.policy и запишем в него следующее:
<source lang="java">
grant {
permission java.security.AllPermission;
};
</source>
Теперь запустим клиент и сервер:
java -Djava.security.policy=open.policy RMIServer

и
java -Djava.security.policy=open.policy RMIClient

Вот и все. Как можно заметить, чем проще и понятнее код клиента и сервера, тем больше телодвижений нужно сделать для запуска разных вспомогательных приложений. Это общая закономерность. Пока приложения простые, зачастую удобнее использовать просто сокеты; в более тяжелых случаях (например, для работы клиент-серверных приложений уровня предприятия, тех самых Enterprise Applications) проще один раз запустить что-то вроде registry, а потом пользоваться «благами цивилизации».

Стоит отметить, что RMI, создаваемый «по умолчанию», в нормальных приложениях использовать нельзя. Слишком много ограничений, слишком много неразрешимых проблем (например, если клиент и сервер находятся в разных подсетях, соединение становится почти невозможным; или — невозможно внести в registry-сервер, который запущен не на той же машине, где и registry). Но реализации, которые предоставляют так называемые контейнеры приложений (GlassFish, Sun WebSphere, JBoss и другие) — это именно то, что используется для связи клиентов с сервером. Там это все работает, и работает отлично.

Файл:JavaEE LXF96.tar.gz

2009-01-01T06:40:49Z

Dionysius: Код урока JavaEE LXF96

Код урока JavaEE LXF96

LXF95:Java EE

2009-01-01T06:37:14Z

Dionysius: /* Серверная часть */

{{Цикл/Java EE}}
== А я? (кс) ==
''ЧАСТЬ 6 Заинтригованы ребусом в заголовке? То ли еще будет, когда прочитаете статью — '''Александр Бабаев''' большой мастер загадывать загадки, особенно если речь заходит о Web 2.0.''

Когда я начинал писать эту статью в первый раз, я думал, что
все достаточно просто. Сел-написал-отдал. Но сразу после
этого пришлось переделывать одно приложение, которое
изменило понимание и сложности, и самого Аякса. Полностью.
В чем же сложность? В несоответствии. С одной стороны, Аякс
позволяет приблизить логику работы интернет-приложений к обычной,
«десктопной». С другой стороны — все браузеры таки разные. И это
последнее «таки» местами убивает наповал. Вы думаете, что браузеров три? IE/Firefox/Opera? Хех. Для правильного приложения их нужно
протестировать десяток. IE 5.5/6/7, Firefox 1.5/2, Opera 8/9, Safari 1.3/2/
(а теперь и 3). И у каждого свой нрав.

=== Ладно, что же такое Аякс? ===
AJAX — технология асинхронного доступа к серверу с использованием
JavaScript и XML. Представим себе автомобиль. Чтобы заправить его -
едем на заправку, заправляем, уезжаем. Чтобы поменять фару — едем,
снимаем, ставим, уезжаем. Вот это — AJAX. А если бы Аякса не было,
то для каждой такой операции нужно было бы отдавать машину в сервис, а из сервиса возвращалась бы другая, хоть и максимально точная
копия вашей, с обновлениями (бак заправлен). Асинхронность — это
вообще что-то вроде дозаправки в воздухе. То есть обновление данных
без «отрыва от просмотра страницы». Давайте подробнее рассмотрим
компоненты этой технологии:

==== A ====
Асинхронность реализуется разными способами. XMLHttpRequest,
фреймы, Flash. Есть и другие (те же апплеты), но они распространены
меньше. Второй способ — самый «простой» для человека, знакомого
с HTML. Создается ма-а-аленький iframe (одна точка) и помещается
куда-нибудь далеко, чтобы не было видно. Потом при необходимости
подгрузить что-либо, запрос выполняется как обычно, но с целевым
фреймом — тем самым, маленьким. Во фрейм загружается страничка,
на которой обычно есть скрипт, который выполняется и делает свое
дело (обновляет основной фрейм). Flash — это примерно то же самое,
только вместо маленького скрытого фрейма используется маленькая
«флэшка».

Впрочем, обычно оба эти способа используются только в случае,
если не подходит «основной» — XMLHttpRequest. Это название объекта
в JavaScript, который может выполнять асинхронные (и синхронные)
HTTP-запросы. Например:
<source lang="javascript">var xmlHttpRequestValue = new XMLHttpRequest();
xmlHttpRequestValue.open(“POST”, “/ajax.jsp?action=update”, true);
xmlHttpRequestValue.onreadystatechange = processXmlHttpResponse;
xmlHttpRequestValue.send(“Информация для пересылки серверу”);</source>
Все, запрос ушел. Сразу предупрежу, что это не рабочий код, только иллюстрация. Обратите внимание на третью строчку. Выделенное
жирным — это имя функции, которая будет обрабатывать события,
генерируемые во время передачи запроса, такие, как «начат прием данных», «закончен прием заголовка», «закончен прием данных». Если мы
хотим что-либо предпринять по окончании приема данных, эта функция будет выглядеть как-то так:
<source lang="java">function processXmlHttpResponse() {
if (xmlHttpRequestValue.readyState == 4) {
…сделать «что-либо»…
}
}</source>
Число «4» как раз обозначает, что обработка завершена. Функция
processXmlHttpResponse() может вызываться много раз (даже точно не
определено, сколько), но как только readyState станет равным 4, мы это
«поймаем» и обработаем результат.

==== J ====
JavaScript — объектный язык. То есть создать класс, как в Java, в нем
нельзя. А вот новый объект — запросто. И сформировать структуру объекта (прописать методы, поля) «на лету» тоже можно.

Чаще всего JavaScript используется как простой способ динамически изменять структуру документа. Например, чтобы поменять цвет
параграфа, можно выполнить такой код:
<source lang="java">document.getElementById(“paragraph”).style.color = “red”;</source>
Параграф после этого покраснеет. Чтобы понимать, как добраться до
отдельных параграфов, нужно изучить DOM (Document Object Model).

==== X ====
XML, который попал в AJAX последней буквой, используется (как уже
упоминалось) далеко не всегда, но часто. Благо, в JavaScript есть возможности по достаточно простому преобразованию чего угодно в XML,
да и в других языках (не только в Java) библиотеки по работе с этим
форматом достаточно хорошо развиты.

=== Помощники ===
Из-за того, что реализации XMLHttpRequest различаются (в паре крупных деталей и, что хуже, в паре десятков мелочей), самому писать
кросс-браузерную обработку достаточно тяжело и долго. Поэтому
давайте посмотрим на библиотеки, в состав которых входит «AJAX-подсистема» и которые сделаны либо специально для Java-северной
составляющей, либо поддерживают ее.
*; DOJO: Огромная библиотека, которая много чего умеет. Если смотреть только на коммуникативные возможности, то тут тоже все в порядке: можно использовать XMLXttpRequest, фрейм, Flash. Первый вариант предлагается по умолчанию. Чуть ниже будет пример работы с DOJO, а сейчас просто отметим, что с учетом достаточно приличной документации, логичной организации и большого количества модулей (в том числе и для использования разных методов коммуникации), библиотеку можно назвать хорошей.
*; DWR — Direct Web Remoting: Сделана специально для Java. Достоинство состоит в том, что DWR умеет «публиковать» классы Java в JavaScript. То есть вы пишете класс в Java, настраиваете DWR (при помощи XML-дескриптора), и после запуска сервлета (обработкой запросов от DWR занимается отдельный сервлет) в JavaScript «появляются» методы этого класса, которые можно вызывать, так же, как если бы это были обычные функции JavaScript. Способ удобен, но навязывает определенный способ коммуникации. Подходит, когда не нужно контролировать каждый байт передаваемых данных и если с JavaScript вы знакомы не очень хорошо (хотя все равно его нужно знать, так как кроме коммуникации есть много чего еще).
*; GWT — Google Web Toolkit: В свое время эта библиотека наделала много шуму. Все дело в принципе ее работы. В общем и целом, если на DWR мы пишем на Java коммуникацию, то на GWT — все приложение. Затем GWT компилирует его в клиентскую часть (HTML + JavaScript) и серверную часть (Java). То есть клиент получается автоматически (не целиком, но близко к тому). GWT берет на себя все заботы и по взаимодействию клиента с сервером, и по созданию интерфейса (этот процесс несколько напоминает Swing), и многое другое. В принципе, достаточно хорошее решение, естественно со своими нюансами. Мы еще посмотрим на него поближе… к концу статьи.

=== Адресная книга с AJAX ===
Настало время потренироваться. Давайте возьмем нашу адресную
книгу и сделаем так, чтобы показывалась страничка с табличкой (списком телефонов), а по нажатии на ссылки вместо перехода на новые
странички менялся сам список: удалялись и добавлялись строки и так
далее. Использовать будем DOJO. Идеология от этого не пострадает, но
станет немного проще, короче и понятнее.

==== HTML/JavaScript ====
Вот строка HTML-таблицы, из которой видно, как будет выводиться
список телефонов.
<source lang="html4strict"><tr id=”1232323” >
<td>1232323</td><td>Vasya Beanov</td><td><td>…</td><td><a
href=”#” on click=”remove(‘1232323’); return false;”>Remove</a> / <a
href=”#” on click=”startEdit(‘1232323’); return false;”>Edit</a></td>
</tr></source>
Обратите внимание на id="…". Это своеобразные метки, которые
позволят при необходимости найти нужную строку. Теперь рассмотрим JavaScript-код, который выполняется при нажатии на «кнопку» Edit
(как самую сложную).
<source lang="javascript">function startEdit(aPhone) {
getCell(aPhone, 0).innerHTML = ‘<input type=”text” value =”’ +
getCell(aPhone, 0).innerHTML + ‘” id =”phone_’ + aPhone + ‘”/>’;
getCell(aPhone, 1).innerHTML = ‘<input type=”text” value = “’ +
getCell(aPhone, 1).innerHTML + ‘” id = “name_’ + aPhone + ‘”/>’;
getCell(aPhone, 2).innerHTML = ‘<input type = “text” value =”’ +
getCell(aPhone, 2).innerHTML + ‘” id =”comment_’ + aPhone + ‘”/>’;
getCell(aPhone, 3).innerHTML = ‘<a href = “#” onclick = “submitEdit(\’’
+ aPhone + ‘\’); return false;”>Save changes</a>’;
}</source>
Простым русским языком этом можно выразить так: ячейки с текстом заменяются на ячейки с полями ввода.

После редактирования и нажатия на кнопку Save changes данные
отсылаются на сервер, и в ячейках снова прописывается текст.
<source lang="javascript">function submitEdit(aPhone) {
getCell(aPhone, 0).innerHTML = document.getElementById(‘phone_’ +
aPhone).value;
getCell(aPhone, 1).innerHTML = document.getElementById(‘name_’ +
aPhone).value;
getCell(aPhone, 2).innerHTML = document.getElementById(‘comment_’
+ aPhone).value;
getCell(aPhone, 3).innerHTML = ‘<a href = “#” onclick = “startEdit(\’’ +
aPhone + ‘\’); return false;”>Edit</a> <a href = “#” onclick = “remove(\’’
+ aPhone + ‘\’); return false;”>Remove</a>’;
sendAJAXRequest(“action=edit” +
“&old=” + aPhone +
“&phone=” + getCell(aPhone, 0).innerHTML +
“&name=” + getCell(aPhone, 1).innerHTML +
“&comment=” + getCell(aPhone, 2).innerHTML);
}</source>
Теперь посмотрим, как отсылаются и принимаются данные. Для
этого у нас есть показательная функция loadTable(), которая загружает табличку с сервера. Остальные функции только отправляют
данные.
<source lang="javascript">function loadTable() {
dojo.io.queueBind({
url : “/ajax?action=loadTable”,
method : “get”,
load : function (aType, aData, aEvent) {
document.getElementById(“table”).innerHTML = aData;
},
preventCache : true
});
}</source>
Обратите внимание на две вещи. Первая — использование dojo.
queueBind — это местная реализация AJAX. Нам не нужно беспокоиться,
что будет использоваться «внутри» (хотя контролировать внутренности
тоже можно). Вторая — параметр load. Это функция, которая вызывается после загрузки данных с сервера (сами данные передаются в параметре aData). sendAJAXRequest выглядит абсолютно так же, только без
параметра load.

Кстати, в queueBind’е сами параметры обрамлены фигурными скобками. Это как раз и есть объектность JavaScript. Тут создается объект с
полями url, method, load и preventCache, и уже этот объект передается
в качестве параметра функции.

==== Серверная часть ====
А теперь посмотрим, как это все обрабатывать на сервере. Логика
его работы осталась той же: опять действия. Только вместо выдачи
большого количества HTML-кода (через шаблоны или напрямую), в
большинстве случаев не выдается ничего. Вот, например, код действия удаления:
<source lang="java">String phone = aRequest.getParameter(“phone”);
_recordsBook.removeRecord(phone);</source>
Только действие создания таблицы телефонов выдает код таблицы
(но только ее, а не всю страничку). Остальные методы только получают данные и сохраняют их. Изменение таблицы происходит на клиенте при помощи JavaScript (как — можно посмотреть на код submitEdit
выше или в [[Media:JavaEE_LXF95.tar.gz‎|полных исходных текстах]] на LXFDVD).

=== GWT ===
А что делать, если вы вообще ничего не понимаете в JavaScript? Не
расстраиваться, скачать GWT (он немаленький, но и перспектива
читать 1000 с лишним страниц талмуда под названием «JavaScript: The
Definitive Guide» тоже не вдохновляет, ведь правда? К тому же архив
можно найти и на нашем DVD), установить. А дальше?

Дальше процедура очень похожа на то, что позволяет делать,
например, Ruby on Rails (или аналогичные каркасы — см. [[LXF95:Akelos]]):
* Вы создаете некий код. Клиентский, серверный, шаблон странички. При необходимости также можно применять свои CSS-стили.
* Затем создаете специальный XML-дескриптор. Это файл, который описывает, что нужно запускать, что будет сервером.
* Запускаете компилятор GWT. Он читает клиентский код, создает HTML-странички (испoльзуя ваши шаблоны) и JavaScript-код, который будет связываться с сервером и выполнять запросы, которые были описаны ранее.
* Запускаете сервер GWT-приложений.
При этом вы не пишете ни строчки на JavaScript. HTML и CSS — да,
приходится, но опять же достаточно немного. Посмотрим подробнее?

==== Структура приложения GWT ====
Для начала стоит создать HTML-файл, который будет «заготовкой»
для странички. Вот его код:
<source lang="html4strict"><html>
<head><meta name=’gwt:module’ content=’phoneBook.PhoneBook’></
head>
<body>
<script language=”javascript” type=”text/javascript” src=”gwt.js”></
script>
<table>
<tr><td>Phone: </td><td id=”phoneCell”></td>
<td>Name: </td><td id=”nameCell”></td>
<td>Comment: </td><td id=”commentCell”></td>
</tr>
<tr><td colspan=”6” id=”buttonCell”></td></tr>
</table>
<div id=”main”></div>
</body>
</html></source>
Обратите внимание, что ни одной кнопки нет. И таблицы нет. Зато
есть элементы, которые помечены id, в них-то и будут вставляться компоненты GWT, которые здесь называются виджетами.

==== Виджеты ====
Сами виджеты будут вставляться уже из «Java-кода». Почему в
кавычках? Просто это код только пишется на Java, но потом компилируется в JavaScript и выполняется в браузере. Из-за этого есть множество ограничений. Например, нельзя использовать конструкции
Java 5, такие как новые циклы foreach, аннотации, обобщенное программирование (generics) и другие. Нельзя использовать все классы
подряд — только те, для которых в GWT есть «реализация» (для java.
lang.* и java.util.* — есть, и это сильно упрощает дело).
Код вставки виджетов выглядит примерно следующим образом:
<source lang="java">Button button = new Button(“Add new record”);
RootPanel.get(“buttonCell”).add(button);</source>
Первая строчка создает кнопку, вторая вставляет ее в элемент с id
«buttonCell».

Список виджетов достаточно велик, и можно также создавать свои
собственные. Например, для вывода таблицы контактов можно использовать FlexTable.
<source lang="java">FlexTable table = new FlexTable();</source>
Этот виджет умеет динамически изменяться, например, вот этак:
<source lang="java">aTable.setText(aRow, aColumn, “Текст в ячейку”);</source>
Этот код вставляет в ячейку таблицы текст. Можно также вставить
туда и другой виджет, например, так:
<source lang="java">aTable.setWidget(aRow, aColumn, new Button(“Edit”));</source>
Для работы нужны не только виджеты, но и обработчики событий. Это тоже реализовано достаточно просто: через слушателей (см.
[[LXF92:Java EE|LXF92]]), как в Swing. Вот как, например, добавляется обработчик
нажатия на кнопку:
<source lang="java">editButton.addClickListener(new ClickListener() {
public void onClick(Widget aWidget) {
код обработчика…
}
}</source>
Есть, правда, и кардинальное отличие — в асинхронности. Для этого
перейдем к сервисам.

==== Сервисы ====
Для обработки клиентских запросов пишутся так называемые сервисы. Чтобы собрать сервис, создается два интерфейса (phoneBook.client.PhoneBookService и phoneBook.client.PhoneBookServiceAsync) и реализация (phoneBook.server.PhoneBookServiceImpl). В сервис выносятся методы, которые сервер выполняет по запросу клиента (у нас это добавление,
удаление, редактирование записей и выдача списка записей).

В «асинхронном» интерфейсе прописываются те же методы, что и
в «обычном», но с одним дополнительным параметром AsyncCallback
async. Это «Callback», обратный вызов. Когда делается асинхронный
вызов, выполнение кода (работа с пользователем) продолжается. А
когда работа асинхронного запроса завершается, вызывается этот
обратный вызов, который сообщает клиенту: «Товарищ, задание партии выполнено, список пользователей доставлен».

Поэтому обработчики событий (например, кнопки удаления записи) выглядят примерно следующим образом (показан только метод
onClick соответствующего обработчика):
<source lang="java">// вызов сервиса, второй параметр – это и есть обратный вызов,
// то есть то, что вызывается после выполнения запроса
PhoneBookService.App.getInstance().
removeRecord(_phone, new AsyncCallback() {
public void onFailure(Throwable aThrowable) {
// ничего тут не будем делать
}
public void onSuccess(Object o) {
// удаляем строку из таблицы, соответствующую телефону
for (int i = 0; i < _table.getRowCount(); i++) {
if (_table.getText(i, 0).equals(_phone)) {
_table.removeRow(i);
break;
}
}
}
});</source>

==== Компиляция и запуск ====
[[Изображение:Img 95 85 1.png|thumb|Итог терзаний — все та же адресная книга и консоль на заднем плане.]]
Ранее я говорил про дескриптор. Он очень прост и выглядит примерно так:
<source lang="xml"><module>
<inherits name=’com.google.gwt.user.User’/>
<entry-point class=’phoneBook.client.PhoneBook’/>
<servlet path=’/PhoneBookService’ class=’phoneBook.server.PhoneBookServiceImpl’/>
</module></source>
Чтобы скомпилировать GWT-код, нужно запустить класс com.
google.gwt.dev.GWTCompiler с параметром «полное имя класса, который нужно скомпилировать». Также можно указать параметр -out
«каталог, куда складывать результат».

Запуск специальной оболочки для отладки осуществляется при
помощи класса com.google.gwt.dev.GWTShell, которому в качестве
параметра передается путь к HTML-файлу запуска. Более подробные
строки компиляции и запуска лучше посмотреть в примерах, которые
поставляются вместе с самим GWT. А как выглядит Google Web Toolkit
Development Shell, можно узнать из рисунка — «вон он, змей, в окне
маячит…»

=== Ну, а все-таки, если делать самому? ===
Давайте поподробнее остановимся на некоторых подводных камнях
технологии, связанных и с Java и с XMLHttpRequest’ом и с остальными
ее компонентами.

Во-первых, Java (точнее, серверная сторона). Тут проблема одна,
UTF-8. Почему-то некоторые браузеры не понимают UTF-8 в ответах.
Safari, например. Есть достаточно простой обходной путь — выставлять
не совсем правильный, но работающий тип (Content-Type) содержимого ответа (response), «text/plain; charset=utf-8».

Далее — клиентская часть. Тут подводных камней больше. Во-первых, количество соединений: на сайт браузер разрешает обычно не
более двух. Поэтому «сделаем сразу 239 AJAX-запросов» не получится.
Один-два в параллели, и все.

Во-вторых, выше упоминалось про callback, вызываемый, когда
идет процесс загрузки ответа с сервера. Как и сколько раз он вызывается — четко не определено. То есть нельзя надеяться, что он вызовется
с кодом события 4 ровно один раз.

В-третьих, на XMLHttpRequest не существует утвержденного стандарта или рекомендации, а есть только черновой вариант W3C.
Поэтому реализации в разных браузерах различаются. Радует, правда,
что не катастрофично.

Именно поэтому примеры приводятся с использованием сторонних
библиотек. А если уж и нужно сделать «самому», то стоит воспользоваться опытом и посмотреть их исходные тексты. В этом-то и сила
Open Source.

=== Вот и весь AJAX ===
{{Врезка
|Заголовок=Ссылки и интересные статьи
|Содержание=
* DOJO: http://dojotoolkit.org,
* DWR: http://getahead.org/dwr,
* GWT: http://code.google.com/webtoolkit/,
* Статья про GWT от IBM developerWorks: http://www.ibm.com/developerworks/ru/library/j-AJAX4/index.html.
|Ширина=200px}}
В статье рассмотрен AJAX «по верхам». Тема безграничная, так как
кроме технологии, использование AJAX меняет стиль и принципы
работы web-приложений. Все то, как они работали до этого, должно
быть переосмыслено на совершенно другом уровне. Дерзайте, и все
получится. Клиенты будут довольны, а, следовательно, разработчики
будут получать больше денег.

Файл:JavaEE LXF95.tar.gz

2009-01-01T06:36:29Z

Dionysius: Код урока JavaEE LXF95

Код урока JavaEE LXF95

LXF94:Java EE

2009-01-01T06:15:36Z

Dionysius: /* Команды */

{{Цикл/Java EE}}
== Команды и фабрики ==
''ЧАСТЬ 6 '''Антон Черноусов''' готов познакомить вас с очередной партией паттернов, которые помогут сделать ваши приложения еще более гибкими и расширяемыми.''

=== Вместо предисловия ===

В предыдущей статье мой коллега Александр Бабаев рассмотрел вопросы организации и использования БД в Java-приложениях, и в том числе вопросы подключения к БД посредством ConnectionPool.

Сегодня мы рассмотрим применение двух паттернов, безусловно, оказавших огромное воздействие на проектирование систем — Command и Factory Method. Их применение позволит сделать ваше приложение расширяемым.

=== Команды ===

[[Media:JavaEE_LXF94.tar.gz‎|Скачать исходный код примера]]

В [[LXF92:Java EE|LXF92]] мы кратко описали стратегии, предназначенные для реализации «Контроллера», и обещали более подробно рассмотреть стратегию Command and Controller. Чтобы выполнить это обещание, нам придется сначала познакомиться с паттерном Command.

Задача, которая стоит перед контроллером (сервлетом) при получении управляющего сигнала, как правило, заключается в выполнении последовательности действий, часто атомарной (то есть обрабатываемой как единое целое). Например, в сервлете AddressBookServlet, реализованном в предыдущей статье, метод handleEdit вызывается, когда адрес на который обращается пользователь — это «/edit».

К сожалению, на примере AddressBookServlet мы видим, что при увеличении функциональности web-приложения растёт и количество методов, реализованных в сервлете; класс «засоряется», код становится менее структурированным и читабельным. Решить проблемы с кодом можно, «обернув» методы в специальные классы, которые будут выполнять атомарные операции и предоставлять сервлету стандартный интерфейс, предназначенный для этих целей. Для выполнения поставленной задачи воспользуемся паттерном Command.

Команды удобны прежде всего тем, что они маскируют конкретную реализацию, находящуюся за интерфейсной прослойкой. Интерфейс остается одним и тем же, независимо от того, с чем работает команда [1].

<source lang=java>
public interface Command {
public void execute() throws Exception;
}
</source>

Выше представлен простой интерфейс Command всего с одним методом execute(), который и олицетворяет идею одноименного паттерна. Он будет нашим стандартым интерфейсом. Более сложная реализация интерфейса включает метод unexecute(). Класс, реализующий интерфейс Command, инкапсулирует в методе execute() обозначенные выше атомарные операции, а в методе unexecute() реализуется механизм отмены. Часто методы execute() и unexecute() называют do() и undo(), соответственно.

[[Image:Java 6 1.jpg|right|thumb|300px|Рис. 1. Диаграмма классов.]]

Выделим команды, которые нам необходимо реализовать (отметим удачное разделение на методы): Add, Auth, Edit, View, Remove. Учитывая то, что у наших команд будут некоторые идентичные методы и атрибуты, предлагаю создать абстрактный класс AbstractHTTPCommand, в котором они будут собраны. Класс будет реализовывать интерфейс Command, и его наследование автоматически позволит обеспечить необходимый уровень интеграции. Итак, в основе каждой команды будет лежать абстрактный класс AbstractHTTPCommand, в котором реализован интерфейс для выполнения операций (на Рис. 1 вы можете видеть диаграмму классов команд нашего приложения).

Определим общие методы для абстрактного класса: initCommand() — предназначен для инициализации команды, makeDataToView() — для подготовки данных для отображения в случае их изменения, outputPage() — метод для переадресации пользователя (он будет перенесен из AddressBookServlet без изменений) и другие. Ниже представлена реализация методов initCommand() и makeDataToView():

<source lang=java>
protected void initCommand(ServletContext sc, HttpServletRequest
aRequest,
HttpServletResponse aResponse, String viewPath,
String resultPath, String errorPath) {
this.setSc(sc);
this.setARequest(aRequest);
this.setAResponse(aResponse);
this.setResultPath(resultPath);
this.setErrorPath(errorPath);
this.setViewPath(viewPath);
}
public void makeDataToView() {
Map<String, String> numbers = new HashMap<String, String>();
Map<String, String> comments = new HashMap<String, String>();
for (Map.Entry<String, Contact> entry :
_addressBook.getContacts().entrySet()) {
numbers.put(entry.getKey(), entry.getValue().getNumber());
comments.put(entry.getKey(), entry.getValue().getComment());
}
aRequest.setAttribute("numbers", numbers);
aRequest.setAttribute("comments", comments);
if (aRequest.getAttribute("message") == null) {
aRequest.setAttribute("message", "");
}
}
</source>

Метод makeDataToView() — существенная часть метода handleView() класса AddressBookServlet. Вы можете удивиться, для чего метод initCommand() содержит так много параметров; это необходимо для того, чтобы в момент создания команды полностью передать ей всю необходимую для ее выполнения информацию. Параметры viewPath, resultPath и errorPath появились не случайно — они предназначены для адресов (видов, если использовать термины MVC), используемых в случае простого отображения данных, удачного и, соответственно, неудачного выполнения команды.

Перейдем к реализации самих команд. Рассмотрим, например, метод execute() класса EditHTTPCommand. Он практически полностью соответствует первоначальному методу handleEdit класса AddressBookServlet, исключая переадресацию пользователя на конкретный вид.

<source lang=java>
public void execute() throws Exception {
if (aRequest.getParameter("number") == null) {
_addressBook.removeContactByNumber(aRequest.getParameter("number"));
aRequest.setAttribute("message","Не определено, что редактировать");
outputPage(this.getErrorPath(), aRequest, aResponse);
} else if (aRequest.getParameter("edited") != null) {
_addressBook.editContactByNumber(aRequest.getParameter("edited"),
aRequest.getParameter("name"),
aRequest.getParameter("number"),
aRequest.getParameter("comment"));
aRequest.setAttribute("message", "Контакт \"" +
aRequest.getParameter("name") + "\" отредактирован");
makeDataToView();
outputPage(this.getResultPath(), aRequest, aResponse);
} else {
Contact contact = _addressBook.getContactByNumber(aRequest.getParameter("number"));
aRequest.setAttribute("action", "edit");
aRequest.setAttribute("edit.name", contact.getName());
aRequest.setAttribute("edit.number", contact.getNumber());
aRequest.setAttribute("edit.comment", contact.getComment());
outputPage(this.getViewPath(), aRequest, aResponse);
}
}
</source>

Остальные команды реализуются аналогичным образом. Исключение из общего процесса рефакторинга кода составит команда ViewHTTPCommand, для которой уже реализована большая часть функционала:

<source lang=java>
public void execute() throws Exception {
makeDataToView();
outputPage(this.getViewPath(), aRequest, aResponse);}
</source>

Выполнение любой команды унифицировано и будет выглядеть следующим образом:

<source lang=java>
Command cmd;
cmd = new EditHTTPCommand(this.getServletContext(),
aRequest, aResponse, "edit.jsp", "view.jsp", "view.jsp");
try {
cmd.execute();
} catch (Exception e) {
e.printStackTrace();
}
</source>

После создания всех команд контроллер должен преобразиться: лишние методы уйдут, а его главная функция — управление — будет восстановлена:

<source lang=java>
private void handle(HttpServletRequest aRequest,
HttpServletResponse aResponse) throws ServletException, IOException {
aRequest.setCharacterEncoding("utf-8");
String target = aRequest.getRequestURI().substring(aRequest.getContextPath().length());
Command cmd;
if (target.equals("/")) {
cmd = new ViewHTTPCommand(this.getServletContext(),aRequest, aResponse, "index.jsp", null, null);
} else if ("/add".equals(target)) {
cmd = new AddHTTPCommand(this.getServletContext(), Request, aResponse, "edit.jsp", "view.jsp", null);
} else if ("/view".equals(target)) {
cmd = new ViewHTTPCommand(this.getServletContext(), aRequest, aResponse, "view.jsp", null, null);
} else if ("/edit".equals(target)) {
cmd = new EditHTTPCommand(this.getServletContext(), aRequest, aResponse, "edit.jsp", "view.jsp", "view.jsp");
} else if ("/remove".equals(target)) {
cmd = new RemoveHTTPCommand(this.getServletContext(), aRequest, aResponse, null, "view.jsp", null);
} else if ("/auth".equals(target)) {
cmd = new AuthHTTPCommand(this.getServletContext(), aRequest, aResponse, "auth.jsp", "index.jsp", "auth.jsp");
} else {
cmd = new ViewHTTPCommand(this.getServletContext(), aRequest, aResponse, "view.jsp", null, null);
}
try {
cmd.execute();
} catch (Exception e) {
// oopst...
e.printStackTrace();
}
}
</source>

С одной стороны, от внедрения паттерна Command в наше web-приложение мы получили следующие преимущества: управление сосредоточилось в одном месте (в методе handle(), представленном выше), код стал более структурированным. С другой стороны, мы пока не добились возможности полного отторжения продукта от разработчика (при котором исходный код не передается заказчику), так как для изменения функциональности или доработки приложения (как минимум, при добавлении новой команды) необходимо производить перекомпиляцию.

В принципе, ничего непреодолимого нет, в любую программу можно внести исправления, но в одни они вносятся проще, чем в другие.
Поставим себе задачу сделать внесение исправлений в наше приложение простым. Для этого нам надо:

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

=== Хранение настроек команд ===

Для решения первой из поставленных задач мы не будем «изобретать велосипед» и воспользуемся средствами конфигурирования web-приложения. В файл web.xml введем параметры для нашего контроллера:

<source lang=java>
<servlet>
<display-name>AddressBook</display-name>
<servlet-name>ABServlet</servlet-name>
<servlet-class>AddressBookServlet</servlet-class>
<init-param>
<param-name>/</param-name>
<param-value>root</param-value>
</init-param>
<init-param>
<param-name>rootCommand</param-name>
<param-value>ViewHTTPCommand</param-value>
</init-param>
<init-param>
<param-name>rootView</param-name>
<param-value>index.jsp</param-value>
</init-param>
<init-param>
<param-name>rootResult</param-name>
<param-value>null</param-value>
</init-param>
<init-param>
<param-name>rootError</param-name>
<param-value>null</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>
</source>

Для каждого адреса вводится параметр, который мы будем называть ключом (для «/» это «root»). Ключ с добавлением суффикса (Command, View, Result, Error) обозначает конкретный параметр, значение которого мы будем извлекать прямо в приложении. Для получения необходимых данных можно воспользоваться следующим кодом (хотя мы в дальнейшем будем действовать по-другому):

<source lang=java>
ServletContext sc = this.getServletContext();
String key = sc.getInitParameter("/");
String commandName = sc.getInitParameter(key + "Command");
String commandView = sc.getInitParameter(key + "View");
String commandResult = sc.getInitParameter(key + "Result");
String commandError = sc.getInitParameter(key + "Error");
</source>

Аналогичные настройки необходимо сделать для всех адресов, с которыми работает наше приложение («/», «/add», «/auth», «/edit», «/remove», «/view»). Включение в файл конфигурации этих значений позволит настраивать web-приложение без исправлений в коде.

=== Создание экземпляра класса по имени ===

Экземпляр класса можно создавать при наличии полного имени, записанного в строке, с помощью методов forName() и newInstance() класса Class (например, для класса Date: Object o = Class.forName(«java.util.Date»).newInstance()). Если при создании объекта на основе имени
класса конструктору необходимо передать ряд параметров, то воспользоваться данным методом нельзя, но создать объект возможно с помощью класса java.lang.reflect.Constructor, например:

<source lang=java>
Class c = Class.forName(key);
Class[] parameterTypes = new Class[3];
parameterTypes[0] = String.class;
parameterTypes[1] = String.class;
parameterTypes[2] = String.class;
Constructor constructor = c.getConstructor(parameterTypes);
Object[] args = new Object[3];
args[0] = "par1";
args[1] = "par2";
args[2] = "par3";
Object o = constructor.newInstance(args);
</source>

Давайте разберем приведенный пример. Сначала мы создаем экземпляр класса Class по имени key, далее выделяем массив из типов параметров в том количестве и последовательности, как они идут в нужном нам конструкторе. Используя метод getConstructor(), в качестве параметра которому мы передаем наш массив, получаем экземпляр класса Conctructor. Если у Conctructor вызвать метод newInstance(args), то мы получим требуемый класс.

Осталось разобраться с последней проблемой, в решении которой нам поможет паттерн Factory Method.

=== Фабрика команд ===

Суть паттерна Factory Method заключается в том, что его реализация позволяет создавать экземпляры конкретных объектов, причем в этом случае сохраняется зависимость от абстрактных интерфейсов. Следовательно, данный шаблон в значительной мере может пригодиться в процессе активной разработки приложений, при которой конкретные классы обладают высоким уровнем изменчивости, что и требуется для решения последней задачи [2].

Если мы применим идею паттерна Factory Method для создания фабрики команд к нашему web-приложению, оно приобретет свойство расширяемости за счет слабосвязанности классов (см. Рис. 2), то есть класс AddressBookServlet напрямую не будет связан с конкретными командами, а будет взаимодействовать с ними посредством Command и CommandFactory.

[[Image:Java 6 2.jpg|right|thumb|320px|Рис. 2. Диаграмма классов, применение фабрики команд.]]

Ниже представлен ключевой метод getCommand() класса CommanFactory, в котором согласно параметру name извлекаются настройки из файла конфигурации web-приложения и создается экземпляр необходимой команды (метод реализован не оптимально):

<source lang=java>
public Command getCommand(String name, HttpServletRequest
aRequest,
HttpServletResponse aResponse) {
if (name != null) {
if (config.getInitParameter(name) != null) {
try {
String key = config.getInitParameter(name);
Class cmd1 = Class.forName(config.getInitParameter(key + "Command"));
try {
Class[] parameterTypes = new Class[6];
parameterTypes[0] = ServletContext.class;
parameterTypes[1] = HttpServletRequest.class;
parameterTypes[2] = HttpServletResponse.class;
parameterTypes[3] = String.class;
parameterTypes[4] = String.class;
parameterTypes[5] = String.class;
Constructor constructor = cmd1.getConstructor(parameterTypes);
Object[] args = new Object[6];
args[0] = sc;
args[1] = aRequest;
args[2] = aResponse;
args[3] = config.getInitParameter(key + "View");
args[4] = config.getInitParameter(key + "Result");
args[5] = config.getInitParameter(key + "Error");
Command cmd = (Command) constructor.newInstance(args);
return cmd;
} catch (Exception e) {
e.printStackTrace();
return null;
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
return null;
}}}
return null;}
</source>

Добавим последний штрих в web-приложение — изменим метод handle класса AddressBookServlet, чтобы он работал с созданной фабрикой:

<source lang=java>
Command cmd;
CommandFactory cf = new CommandFactory(this.getServletConfig(),this.getServletContext());
cmd = cf.getCommand(
aRequest.getRequestURI().substring(aRequest.getContextPath().length()),
aRequest, aResponse);
if (cmd == null) {
cmd = cf.getCommand("/", aRequest, aResponse);
}
try {
cmd.execute();
} catch (Exception e) {
// oopst...
e.printStackTrace();
}
</source>

Предложенная реализация закрывает для пользователя вызов не описанных в конфигурации адресов.

=== Что дальше? ===

Основной целью этой статьи было знакомство с паттернами Command и Factory Method, с чем мы неплохо справились, а заодно провели модернизацию web-приложения.

Создание экземпляров команд на основе файла конфигурации web-приложения, наверняка, не самая хорошая идея: более правильно выносить их настройку в отдельный файл (который кстати, можно будет менять из самого приложения, необходимо лишь реализовать соответствующие функции). Одно из улучшений, которое можно произвести — это изменить сами команды: сделать их stateless, то есть не хранящими внутри себя сведения о состоянии. Это улучшение позволило бы создать экземпляры команд один раз и использовать их и по мере необходимости.

Отметим, что применяя предложенные методы, можно создать приложение, модификация которого возможна без остановки его выполнения, так сказать, «на лету», но это уже тема тема отдельной статьи.

----

== Литература ==
# Тейт, Б. Горький вкус Java: Библиотека программиста. — СПб: Питер, 2003. — 333 с.
# Мартин, Р. С. Быстрая разработка программ: принципы, примеры, практика. — М.: Издательский дом «Вильямс», 2004. — 752 с.: ил.

Файл:JavaEE LXF94.tar.gz

2009-01-01T06:14:17Z

Dionysius: Код примера урока JavaEE LXF94

Код примера урока JavaEE LXF94

LXF93:Java EE

2008-12-30T18:05:33Z

Dionysius: /* Все на базу! */

{{Цикл/Java EE}}
: '''Java Enterprise Edition''' Учимся писатьклиент-серверные приложения на Java

[[Категория:Учебники]]

==Все на базу!==

[[Media:AddressBook4.tar.bz2|Скачать исходный код примера]]

:'''ЧАСТЬ 5''' Ни одно серьезное приложение не обходится без большой базы данных. '''Александр Бабаев''' расскажет, что для этого требуется.

В предыдущих статьях цикла рассказывалось, как сделать интернет-приложение: правильно разделить создание интерфейса
и бизнес-логику, а также реализовать некоторые технические
детали. Но до сих пор мы использовали для хранения записей адресной книги простейшую сериализацию. Настало время сделать все
«по-взрослому».

Хранение записей в базе данных имеет и достоинства, и недостатки. Из последних можно указать на необходимость поставки с
приложением СУБД (системы управления базами данных), а также
изучения специального языка запросов, который помогает сохранять
данные в БД и получать их оттуда и достаточно сложен, если изучать
его досконально.

Но есть и явные выгоды, иначе СУБД не использовались бы
настолько широко, как они используются сейчас. Во-первых, язык, о
котором я говорил (так называемый структурированный язык запросов, ''Structured Query Language, SQL'') – более или менее стандартен.
Это позволяет изучить его один раз, после чего использовать с разными СУБД. Эти системы также достаточно надежны и отлажены (и
имеют приличную скорость работы), что позволяет использовать их в
самых сложных ситуациях.

Хочется отметить еще одно свойство реляционных СУБД. Дело в
том, что реляционными они называются не просто так. Есть специальная область математики, которая описывает такие объекты, как таблицы и поля, а также отношения (relations) между ними – реляционная
алгебра и реляционное счисление. Знание основ этого раздела науки
позволяет очень четко представить, что может и чего не может реляционная СУБД. А это, в свою очередь, дает понимание, где ее стоит, а где –
не стоит использовать. В мире ПО это очень редкое и очень полезное
свойство. Оно означает, что если сделать программу точно по математическим лекалам, то даже в условиях сверхдальнего космоса она
будет работать так, как задумано. Значит, на нее можно положиться.

А теперь вернемся из космоса к нашим адресам…

===JDBC===

Рассмотрим, как можно обеспечить работу с СУБД, используя Java.
Есть несколько подходов (например, применение специальных СУБД,
которые имеют собственные API для Java), но в подавляющем боль-
шинстве случаев вам придется использовать ''JDBC'' (Java DataBase
Connectivity). Это библиотека, которая позволяет работать с любой
СУБД, для которой создан так называемый JDBC-драйвер. Он преобразует запросы ''JDBC'' в родные команды СУБД и обратно.

Мы будем использовать самую обычную связку: ''MySQL'' + стандартный драйвер ''MySQL JDBC''. Если вы занимаетесь созданием интернет-приложений, то эта СУБД, скорее всего, у вас уже установлена. А
драйвер можно скачать с сайта ''MySQL'' по адресу: http://dev.mysql.com/downloads/connector/j/5.0.html или найти на нашем DVD. Из всего архива нам понадобится только файл '''mysql-connector-java-5.0.5-bin.jar'''.

===Работа с JDBC===

Для выполнения дальнейших действий СУБД (''MySQLd'') должна быть
запущена.

В целом, работа с ''JDBC'' не сильно отличается от работы с любым
другим API (в PHP, например, все идеологически очень похоже). Вопервых, нужно подключиться к СУБД, т.е. создать соединение. После
работы соединение обязательно нужно закрыть. Пока соединение
«открыто», можно опрашивать СУБД, сохранять или получать данные,
используя язык ''SQL''.

Вспомним основные и самые простые команды ''SQL''. Научимся
создавать записи в БД, изменять и удалять их. Но прежде нужно
создать саму базу данных.

Если ''MySQL'' был только что установлен, то создать базу данных
можно следующей командой:

mysqladmin -uroot create database addressbook

Теперь в этой БД нужно сделать таблицу, которую мы будем
использовать для хранения записей. Сделаем маленькую программу
на Java, которая выполнит эту работу за нас (см. листинг 1). Заодно
посмотрим на общую структуру процесса работы с СУБД.

'''Листинг 1. Создание таблицы'''

<source lang=java>
import java.sql.*;
public class CreateTable {
public static void main(String[] args) throws Exception {
// эта строчка загружает драйвер MySQL, чтобы его можно было использовать
Class.forName(“org.gjt.mm.mysql.Driver”).newInstance();
// получим соединение
Connection connection = DriverManager.
getConnection(“jdbc:mysql://localhost:3306/addressbook”, “root”,“”);
try {
// создадим «выражение»
Statement statement = connection.createStatement();
statement.executeUpdate(
“CREATE TABLE `addresses` (\n” +
“`name` varchar(200) default NULL,\n” +
“`number` varchar(200) default NULL\n” +
“`comment` varchar(200) default NULL,\n” +
“) DEFAULT CHARSET=utf8”);
statement.close();
} finally {
// закроем соединение
connection.close();
}
}
}
</source>

В этой программе присутствует одна «волшебная» строчка, которая
загружает драйвер. Нужно отметить, что в Java 6 она необязательна.
Остальное более или менее понятно. Мы открываем соединение (легко видеть, что при этом мы подключаемся к локальному компьютеру,
порту 3306 и базе данных '''addressbook''', с именем пользователя root и
пустым паролем), потом генерируем выражение ('''statement''') и выполняем ''SQL''-код, который и создает таблицу. Затем выражение «закрывается», после чего в final-блоке закрывается и само соединение. Final-
блок нужен для того, чтобы соединение было закрыто независимо от
возникновения исключения в блоке '''try ... catch'''. Как правило, число
одновременных соединений ограничено, а значит, это ценный ресурс,
которым нужно пользоваться аккуратно.

Вместо кода, который создает таблицу, можно написать любой другой ''SQL''-запрос, например, добавляющий запись или изменяющий ее.
Для получения записи нужен несколько другой код, и его мы обсудим
чуть позже.

Чтобы добавить запись в уже созданную таблицу, можно использовать следующий код (См. листинг 2):

'''Листинг 2. Создание записи в таблице'''

<source lang=java>
private void addEntry(String aName, String aNumber, String aComment)
throws SQLException {
Connection connection = DriverManager.
getConnection(“jdbc:mysql://localhost:3306/addressbook”, “root”, “”);
try {
PreparedStatement statement = connection.prepareStatement(
NSERT INTO `addresses` (`name`, `number`, `comment`) VALUES (?, ?, ?)”);
statement.setString(1, aName);
statement.setString(2, aNumber);
statement.setString(3, aComment);
statement.executeUpdate();
statement.close();
} finally {
connection.close();
}
}
</source>

Чтобы поменять номер, следует воспользоваться командой '''UPDATE''':

<source lang=java>
PreparedStatement statement = connection.prepareStatement(
“UPDATE `addresses` SET `number`=?, `comment`=? WHERE
`name`=?;
</source>

Внимательный читатель может заметить, что здесь используется не
'''Statement''', а '''PreparedStatement''' (предварительно подготовленное выражение). Оба они служат одной цели – с их помощью формируются
и выполняются запросы к СУБД. Но '''Statement''' формирует запросы и
тут же выполняет их, в то время как '''PreparedStatement''' сначала подготавливает запрос, затем заполняет его параметры значениями (места вставки параметров – это вопросительные знаки), и только потом
выполняет его. '''PreparedStatement''' имеет множество преимуществ
перед обычными запросами. Во-первых, предварительно подготовленные запросы могут кэшироваться прямо в СУБД. Это ускоряет их
выполнение. Кроме того, можно выполнить несколько запросов сразу, используя пакетную обработку. Например, если нужно добавить не одну, а несколько записей, можно поступить примерно так:
* Создать '''PreparedStatement'''.
* Заполнить его ('''statement.set'''…).
* Вызывать '''statement.addBatch()'''.
* При необходимости повторить предыдущие два пункта.
* Вызывать '''statement.executeBatch()'''.

Теперь давайте разберемся, как можно вытащить информацию из
БД. Это не намного сложнее (см. листинг 3).

'''Листинг 3. Получение записи из таблицы'''

<source lang=java>
Contact result = null;
PreparedStatement statement = connection.prepareStatement(
“SELECT `name`, `number`, `comment` FROM `addresses` WHERE `name`=?”);
statement.setString(1, aName);
ResultSet resultSet = statement.executeQuery();
if (resultSet.next()) {
result.setData(resultSet.getString(1), resultSet.getString(2), resultSet.
getString(3));
}
</source>

Теперь мы вызываем метод '''statement.executeQuery()''', который возвращает '''resultSet'''. Согласно документации, он никогда не равен '''null''',
поэтому проверку я не произвожу. Далее вызывается метод '''resultSet'''.
'''next()''', который возвращает true тогда и только тогда, когда в результате есть еще одна запись, и, одновременно с этим, переходит на эту
запись. После чего можно получить доступ к полям записи. Я получаю
доступ по номерам, мне так проще. Но можно написать и '''resultSet'''.
'''getString(“name”)''', это тоже будет работать.

===Но это будет работать плохо===

{{Врезка
|Заголовок=Сокорая помощь
|Содержание=Напомню, что
для того, чтобы
подключить jar-файл к проекту,
нужно указать в параметрах ''javac'' и ''java'' '''«-cp [имя jar-файлов через разделитель]»''',
где разделителем
является точка с
запятой в Windows и
двоеточие в Unix.
|Ширина=200px
}}

Почему? Потому что никто в «нормальных» системах не работает
с соединениями напрямую, а если работает, то никогда не открывает/закрывает соединение на каждый запрос. Иногда это может
занять секунды и минуты. А сам запрос – несколько миллисекунд.
Становится ясно, что создание соединения и его закрытие – узкое
место, с которым нужно что-то делать. И решение называется «пул
соединений». Пул ('''Pool''') – это общий паттерн (см. [[LXF92:Java_EE|LXF92]]), который
состоит в следующем:
* У нас есть хранилище объектов. Представим себе оружейный ящик местной шпаны. В нем лежат несколько рогаток. Это и есть хранилище или пул.
* В каждый момент времени любой (кому позволено) может взять рогатку, попользоваться и положить обратно.
* Если рогатки нет, можно подождать, пока кто-нибудь другой не вернет ее в ящик.

Тогда, если время пользования рогаткой невелико (никто не держит
ее долго), один пул может обслуживать очень большое количество
хулиганов. Схематично пул изображен на рисунке. Видно, что при
помощи небольшого количества соединений с ограниченным ресурсом
обрабатывается большое количество «пользователей».

То же самое можно проделать и с соединениями. Создается
пул, в котором держится открытыми, например, десять соединений.
Если нужно произвести операцию с БД, соединение берется из пула,
используется и возвращается на место. При этом оно остается открытым. И получается (кроме самого первого раза) – тоже уже открытым.
Экономия зачастую просто огромна.

[[Изображение:LXF93_javaee.png|Рис. 1]]

'''Рис. 1. Схема работы пула.'''

===Полезные «Commons»===

Если взглянуть на сайт http://jakarta.apache.org/, то можно увидеть
очень много проектов, которые сделаны для ''Java''. Среди них достаточно много хороших. Нам понадобится Commons (http://jakarta.apache.org/commons/). Это проект, в котором собраны маленькие «общие»
библиотеки, которые приходится писать каждому программисту.
Вместо того, чтобы терять время зря, можно просто скачать нужный
пакет и использовать его. Сегодня нам будут интересны ''commons-dbcp''
и ''commons-pool''. Их можно загрузить со страниц http://jakarta.apache.org/site/downloads/downloads_commons-dbcp.cgi и http://jakarta.apache.org/site/downloads/downloads_commons-pool.cgi соответственно или
взять с нашего DVD. После скачивания нужно вытащить из архивов
файлы '''commons-dbcp-1.2.2.jar''' и '''commons-pool-1.3.jar'''.

Основное предназначение второй библиотеки – создание пулов,
первой – пулов соединений с СУБД. Давайте посмотрим, как все это
используется. Для начала пул нужно инициализировать. Для этого мы
напишем следующий метод:

<source lang=java>
String connectionString = “jdbc:mysql://localhost:3306/addressbook?user=root&passowrd=”;
GenericObjectPool connectionPool = new GenericObjectPool(null);
ConnectionFactory connectionFactory =
new DriverManagerConnectionFactory(connectionString, null);
new PoolableConnectionFactory(connectionFactory, connectionPool, null,
null, false, true);
PoolingDataSource _poolingDataSource = new PoolingDataSource(conne
ctionPool);
</source>

Теперь вместо создания соединения «самим» можно получать его
из '''PoolingDataSource'''. Сама работа с соединением при этом не изменится ни на грамм. Вот, например, добавление записи (листинг 4, сравните с листингом 2):

'''Листинг 4. Добавление записи (используем пул соединений)'''

<source lang=java>
private void addEntry(String aName, String aNumber, String aComment)
throws SQLException {
Connection connection = _poolingDataSource.getConnection();
try {
PreparedStatement statement = connection.prepareStatement(
INSERT INTO `addresses` (`name`, `number`, `comment`) VALUES (?,
?, ?)”);
statement.setString(1, aName);
statement.setString(2, aNumber);
statement.setString(3, aComment);
statement.executeUpdate();
statement.close();
} finally {
connection.close();
}
}
</source>

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

Стоит упомянуть, что в данном случае используется шаблон '''Proxy'''.
То есть создается класс, который унаследован от соединения, но в
котором изменено поведение одного из методов (в данном случае,
'''close'''). Благодаря этому код приложения не изменяется, но зато кардинальным образом изменяется поведение.

===Другие пути===

''JDBC'' – великолепный способ работы с базами данных. Но не единственный. Главная особенность ''JDBC'' в том, что это самая низкоуровневая библиотека для работы с базами данных в Java. Все распространенные средства (''EJB'' или ''Hibernate'' например), внутри так или иначе
используют ''JDBC''. Поэтому для понимания того, что происходит, ''JDBC''
знать просто обязательно. Иначе трудности отладки и недоумения поповоду «а что это тут произошло» будут преследовать вас постоянно и на каждом шагу.

Достоинства ''JDBC'' очевидны. Это сравнительная простота, мощность (мы не обсудили и десятой части того, что может эта библиотека:
здесь есть и транзакции, и курсоры, и блокировки, и много чего еще), а
также скорость работы. Но иногда требуется немного другое. В нашем
случае в БД была только одна таблица, которая к тому же имела простую структуру. В сложных приложениях часто приходится работать с
сотнями «бизнес-объектов», у которых бывает очень нетривиальная
структура и взаимосвязи. При этом структура СУБД получается очень
непростая. И процедура вытаскивания объектов (которые часто «раскиданы» по десяткам таблиц) – превращается в кошмар.

На этом этапе на передний план выходят другие библиотеки. В
первую очередь это ''Hibernate''. Во вторую – ''EJB''. Во вторую, потому что
''EJB'' – это не только способ хранения объектов, но несколько более
сложная «структура». А ''Hibernate'' – это типичный пример ORM (ObjectRelational Mapping, объектно-реляционное отображение), то есть биб-
лиотеки, автоматически преобразующей объекты в строки таблиц и
обратно. Работа с ''Hibernate'' сильно отличается от работы с ''JDBC'', но
внутри – это примерно то же, что мы и рассмотрели.

Также нельзя забывать, что несмотря на то, что ''JDBC'' – это унифицированная библиотека, которая работает с десятками различных
СУБД (был бы драйвер), код, написанный для одной СУБД, далеко не
всегда будет работать с другой. Разница обычно заключается в двух
вещах:

* Возможности драйвера. Иногда что-то не реализовано. Например, вам нужны транзакции, а в драйвере их просто нет.
* Разница в диалекте ''SQL''. Ни одна СУБД не повторяет никакую другу в языке запросов. Всегда есть различия. Поэтому, несмотря на стандар ты, одно приложение не обязательно будет работать со всеми СУБД.

Ну вот, собственно, и все. Адресная книга успешно «покладена» в базу данных. Это отличное начало, но пора двигаться дальше.
Интересно, а что же такое ''AJAX''? '''LXF'''

===А дайте нам ваше соединение!===

Существует еще один способ работы с соединениями, который используется в крупных приложениях. Точнее, не в крупных, а в тех, где за
соединениями следит контейнер приложений или контейнер сервлетов.

Для этого в дескрипторе нужно описать способ подключения к СУБД и
параметры подключения. И при запуске контейнера можно будет получить
'''DataSource''', который будет проинициализирован самим контейнером. Как
это делается – лучше смотреть в документации к контейнеру/СУБД.
Например, для используемого нами Tomcat нужная информация находится тут: http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html.

===Что за штука... встраиваемые СУБД?===

В ''Java 6'' появилось новшество – некая ''Java DB''. Что это? Это —
встраиваемая СУБД (embeddable DB engine).

Обычно сервер СУБД работает отдельно (часто даже на своем
собственном компьютере), но на этапе отладки приложения это
зачастую не нужно. Да и в простых приложениях хочется, с одной
стороны, использовать мощь баз данных, а с другой, распространять с программой сервер, учить пользователей им пользовать-
ся – это кошмар.

Поэтому существует специальный класс СУБД, которые запускаются вместе с приложением (например, как обычный поток
внутри вашей программы), и заканчивают работу вместе с ним. Их
использование не отличается (за исключением общих разнящихся
правил SQL-запросов) от работы с обычной СУБД: здесь тоже
нужен драйвер (всё в поставке), те же выражения… Они сродни
''Jetty'', которую мы использовали в самом начале, чтобы сделать
наш первый сервлет.

Из известных встраиваемых СУБД можно назвать ''Java DB'' (это
порт ''Apache Derby'') и ''HSQLDB'', используемую в ''OpenOffice.org'', а
из известных за пределами мира Java — ''SQLite'' (в принципе тоже подключаемую к Java).

Файл:AddressBook4.tar.bz2

2008-12-30T18:05:14Z

Dionysius: Исходный код примера урока JavaEE в LXF93

Исходный код примера урока JavaEE в LXF93

LXF92:Java EE

2008-12-30T17:59:20Z

Dionysius: /* MVC в J2EE */

{{Цикл/Java EE}}
[[Категория:Учебники]]
:'''Java Enterprise Edition''' Учимся писать клиент-серверные приложения на Java

==MVC в J2EE==

: '''ЧАСТЬ 4''' Название статьи выглядит как китайская грамота? Не волнуйтесь – '''Антон Черноусов''', вооруживщийся книгой Гамма, проведет экспресс-курс по паттернам объектно-ориентированного проектирования.

В предыдущей статье мы говорили о сессионных и контекстных объектах, о том, как создавать и использовать фильтры, и рассмотрели простой пример авторизации пользователя. Сегодня мы рассмотрим паттерн ''MVC'' и его вариацию для создания web-приложений – ''Model2''.

[[Media:AddressBook3.tar.bz2|Скачать исходный код примера]]

===Волшебное слово «паттерн»===

Паттерн ''Model-View-Controller (MVC)'' появился очень давно и достаточно активно использовался в Smalltalk-80. Он предназначен для построения интерфейсов пользователя '''[1]'''.

Прежде чем окунуться в дальнейшее изучение Java, давайте более
подробно остановимся на слове «паттерн». Паттерн – это стандартный способ эффективного решения той или иной задачи в некотором контексте, но для разработчиков программного обеспечения это слово
приобрело особое значение. К программному обеспечению этот термин был впервые применен Кристофером Александром '''[2]''', который разработал структуру для документирования паттернов и коллекцию
паттернов, которые были названы «языками паттернов».

При описании любого паттерна обычно используется следующая структура:

* название и классификация паттерна;
* назначение;
* мотивация для использования;
* рекомендации по применению паттерна;
* структура паттерна;
* участники или элементы паттерна;
* отношения между элементами;
* результаты применения;
* описание идеи реализации паттерна;
* пример кода (по возможности);
* родственные паттерны.

Представленная выше структура описания паттерна применена в
книге Э. Гамма, ставшей классическим справочником по паттернам '''[3]'''.

Фактически, паттерн является средством описания общих решений
распространенных задач, то есть это – абстрактное решение технических задач, с которыми приходится сталкиваться программистам '''[4]'''.

Если сказать еще более простым языком, то паттерн – это стандартное решение стандартной проблемы. Моему коллеге очень нравится следующий пример. Задача: построить кирпичную стену, через
которую можно видеть; решение: строить эту стену с окном. В связи с
тем, что количество стандартных задач очень велико, паттернов тоже
существует достаточно много.

===Что такое ''MVC''?===

''MVC'' – паттерн, представляющий объектно-ориентированный метод
для разделения логики представления, бизнес-логики и модели данных. ''MVC'' – не просто удачное решение, а общепринятый образец для
построения современных приложений. Иногда паттерн ''MVC'' называют
«архитектурой». На рис. 1 представлена схема взаимодействия компонентов ''MVC''.

[[Изображение:LXF92_javaee1.png|Рис. 1]]

'''Рис. 1. Архитектура ''MVC''.'''

Как вы можете видеть на этом рисунке, основными компонентами являются '''Модель (Model), Вид (View) и Контроллер (Controller)'''.
Компонент '''Модель''' представляет собой совокупную модель данных
предметной области, реализованной в приложении, например, объект,
содержащий в себе информацию о счете пользователя. '''Вид''' – это компонент, отвечающий за отображение '''Модели''' и реализацию пользовательского интерфейса. Вся логика по обработке действий пользователя сосредоточена в '''Контроллере'''.

Иными словами, все данные предметной области, участвующие в
работе приложения, сгруппированы в классы, которые предназначены для хранения данных в процессе обработки – эти классы названы '''Моделью'''. Классы, реализующие пользовательский интерфейс (какой
бы вид они ни принимали: командная строка, GUI или JSP) именуются
'''Видом''', а те классы, которые на основании внутренней логики и реакции пользователя принимают решение о выполнении тех или иных
действий, принято называть '''Контроллером'''.

Зачем нужно использовать паттерн ''MVC''? Основным мотивом является облегчение модификации или настройки каждой части в отдельности. Этот паттерн очень полезен в тех случаях, когда нужно создавать
компоненты, которые одновременно должны соответствовать требованиям гибкости и удобства сопровождения.

Что не так с гибкостью в приложениях, построенных по другим схемам? В книге Брюса Тейта '''[5]''' уделено достаточно много внимания этой
проблеме. Вся загвоздка в том, что достаточно часто модель данных
и ее представление пользователю сильно переплетены между собой,
что вызывает множество проблем при отладке программ и еще больше – при их модификации. Но немаловажной проблемой является и
то, что логика работы оказывается рассредоточенной, что опять же не
сказывается на приложении положительным образом.

===Реализация ''MVC'' в ''J2EE''-приложении.===

Паттерн ''MVC'' был предложен для классических настольных приложений, но он практически без изменений может быть использован и для построения приложений ''J2EE'', хотя здесь имеются свои нюансы.
Существует две реализации паттерна ''MVC'' для ''J2EE''-приложений – это
'''Model1''' и '''Model2'''. В качестве '''Вида''' в каждом из них используются ''JSP'', в
качестве '''Модели''' – ''JavaBean''. Основное отличие подходов заключается
в том, каким образом реализован '''Контроллер''': в '''Model1''' – это ''JSP'', а в
'''Model2''' – ''сервлет''.

Первая реализация основана на логике, которая хранится в страницах. Браузер пользователя поочередно посещает ряд страниц для
выполнения какого-либо бизнес-процесса. Такая реализация имеет
следующие недостатки.

* '''1''' Cложно обеспечить разделение труда между дизайнерами и программистами.
* '''2''' Архитектуру '''Model1''' сложно поддерживать, и она не является гибкой, что особенно критично для больших проектов '''[6]'''.

Исходя из этих предпосылок, давайте более подробно рассмотрим
реализацию компонентов '''Model2''', которая чаще всего лежит в основе
web-приложений.

===Модель – ''JavaBeans''===

Прежде всего, '''Модель''' в ''J2EE''-приложениях, как и обычных приложениях, удобно реализовывать в виде совокупности ''JavaBeans''. ''JavaBean''’ом
может называться любой класс Java, который удовлетворяет достаточно простым требованиям:

* все атрибуты класса должны быть защищенными ('''protected''');
* для каждого атрибута, предназначенного для чтения, должен быть реализован метод вида: '''PropertyClass getPropertyName(){...}''';
* для каждого атрибута, предоставляющего возможность записи должен быть реализован метод вида: '''setPropertyName(PropertyClass propertyName){...}''';
* обязательно должен быть реализован конструктор без параметров.

Для примера давайте разработаем небольшое web-приложение,
отображающее новости. Пусть Моделью приложения будут JavaBean-объекты, инкапсулирующие в себе сведения о новостях. Объект '''News''',
содержащий в себе одну-единственную новость, является простым
объектом ''JavaBean'' и имет только два метода (чтение и запись) для
всех своих атрибутов:

<source lang=java>
public class News {
protected String caption;
protected String message;
protected Date date;
public String getCaption() {
return caption;
}
}
</source>

Второй объект, логически завершающий нашу модель данных, –
это '''NewsTape''', который помимо обязательных методов, необходимых
''JavaBean'', имеет дополнительные методы, расширяющие его функциональность, что не запрещено:

<source lang=java>
public void addNews(News news) {
if (news != null) {
AllNews.add(news);
}
}
</source>

===Связь Вида и Контроллера===

Для реализации Вида нам потребуется создать две JSP, одну – для
отображения новостей ('''view.jsp'''), другую – для их добавления ('''edit.jsp''').
Вторая процедура содержит небольшую форму:

<source lang=java>
<form action=”<%=request.getContextPath()%>/
<%=request.getAttribute(“action”)%>” method=”post”>
<input type=”hidden” name=”edited”
value=”<%=request.getAttribute(“edit.number”)%>”/>
<table>
<tr><td>Заговок: </td><td><input type=”text” name=”caption”
value=”<%=request.getAttribute(“edit.caption”)%>”/></td></tr>
<tr><td>Сообщение: </td><td><input type=”text”
name=”message”
value=”<%=request.getAttribute(“edit.message”)%>”/></td></tr>
<tr><td colspan=”2” align=”center”><input type=”submit”
name=”Отправить”/></td></tr>
</table>
</form>
</source>

Для реализации контроллера нам необходимо создать сервлет,
который в соответствии с запросом пользователя производит выбор
необходимого Вида, то есть JSP, например, при помощи следующего
метода:

<source lang=java>
private void handle(HttpServletRequest aRequest, HttpServletResponse
aResponse)
throws ServletException, IOException {
aRequest.setCharacterEncoding(“utf-8”);
String target =
aRequest.getRequestURI().substring(aRequest.getContextPath().length());
if (target.equals(“/”)) {
outputPage(“index.jsp”, aRequest, aResponse);
} else if (“/add”.equals(target)) {
handleAdd(aRequest, aResponse);
} else if (“/view”.equals(target)) {
handleView(aRequest, aResponse);
}
}
</source>

Вы скажете: «Эй! Да мы подобное уже делали!» И я вам отвечу:
«Правильно, вы уже реализовывали контроллер на основе сервлета».
'''Контроллер''' определяет поведение приложения, то есть интерпретирует действия пользователя и обеспечивает изменение состояния модели
или выбор другого представления, или то и другое одновременно.

Из-за особенностей работы web-приложений, выбор '''Вида''' из
'''Контроллера''' можно произвести двумя способами: вызвав метод
'''forward''' у экземпляра класса '''RequestDispatcher''' или вызвав метод
'''sendRedirect''' у экземпляра класса '''HttpServletResponse'''. В то же время,
воздействия пользователей на «'''Контроллер'''», в основном, могут быть
переданы посредствам запросов, то есть нажатием на ссылки, или в
качестве результатов работы форм. Управление работой приложения
происходит благодаря методу '''handle''' нашего сервлета. Такой вид организации обработки принято назвать «реализация стратегии '''Servlet Front''' паттерна '''Front Controller'''». Хотя, если быть более точным, реализован подвид стратегии '''Servlet Front – Dispatcher in Controller'''.

Видимо, такое обилие терминов сбивает с толку, поэтому давайте
вкратце рассмотрим стратегии реализации паттерна '''Front Controller''',
предназначенные для реализации «'''Контроллера'''» в паттерне ''MVC''.
* '''1''' Стратегия '''Servlet Front''' фактически соответствует поведению контроллера в архитектуре '''Model2''', описанной выше. «'''Контроллер'''» редко выполняет все функции, но в случае, если это происходит, и функциональность, отвечающая за перенаправление пользователя к другим «'''Видам'''», полностью реализована в нем, то такая реализация называется '''Dispatcher in Controller'''. Еще один подвид данной стратегии – '''Base Front''', она отличается тем, что реализован не один контроллер, а несколько, причем все они расширяют некий базовый контроллер, в котором реализована базовая функциональность. Применение этой стратегии не всегда оправдано.
* '''2''' Стратегия '''JSP Front''' фактически соответствует поведению контроллера в архитектуре '''Model1''', описанной выше, и мы не будем на ней останавливаться, потому как она практически нигде не применяется.
* '''3''' '''Mapping Controller''' – это стратегия, которая тем или иным образом применяется при построении практически любого web-приложения. Технология реализована через дескриптор развертывания приложе ния и имеет следующие подвиды: '''Physical Resource Mapping''' – когда ресурс отображается по месту его физического расположения в каталогах, '''Logical Resource Mapping''' – когда ресурс отображается в соот ветствии с некоторой логикой группирования функции приложения, и '''Multiplexed Resource Mapping''' – это смешивание обоих методов разме щения ресурсов.
* '''4''' Стратегия '''Filter Controller''' – это реализация контроллера в виде фильтра, который перехватывает все запросы пользователя и в соответствии с внутренней логикой обеспечивает тот или иной бизнеспроцесс.
* '''5''' '''Command and Controller''' – это стратегия, основанная на применении двух замечательных паттернов, '''Command''' и '''Factory Method''', и, на мой взгляд, одна из самых удачных стратегий. Ее применение мы обсудим в одной из наших следующих статей.

[[Изображение:LXF92_javaee2.png|Рис. 2]]

''' Рис. 2. Схема взаимодействия некоторых объектов электронного магазина.'''

===Извещение об изменениях===

Последний вопрос, который необходимо осветить для полного обзора
паттерна ''MVC'' – это извещение '''Вида'' об изменениях состояния '''Модели'''.
К сожалению, в большинстве случаев в ''J2EE'' нельзя выполнить оповещение «'''Вида'''» за исключением случаев, когда приложение построено
с применением ряда современных технологий. Примером такой кооперации может служить ''AJAX''.

И все же, давайте рассмотрим механизм оповещения одного объекта об изменениях, произошедших в другом объекте. Реализация
механизма оповещения необходима в следующем случае: существует
как минимум один объект, рассылающий уведомления, и имеется не
менее одного получателя сообщений, причем количество сообщений
и их состав может меняться во время работы, а также различаться у
разных элементов приложения.

Классическим примером такого поведения может служить электронный магазин, где необходимо обеспечить взаимодействие корзин
покупателей, их счетов и склада с товаром. На рис. 2 представлена схема взаимодействия рассмотренных объектов. Пользователь выбирает
товар, и он помещается в корзину, корзина уведомляет объект – счет,
где формируется стоимость товара и доставки, и склад, где происходит бронирование или подготовка к дополнительному заказу товара у поставщиков.

В основе описанного процесса лежит реализация паттерна
''Observer''. Его цель – это организовать зависимость «один ко многим» между объектами так, чтобы при изменении состояния одного
объекта автоматически уведомлялись и обновлялись все его зависимые объекты.

Считается, что ''Observer'' является одним из главных паттернов
объектно-ориентированного программирования, по крайней мере, он
широко применяется в настольных приложениях. Особенно хорошо его
влияние видно в приложениях ''Swing''. Для применения этого шаблона
необходимо ответить на следующие вопросы:

* '''1''' Кто является объектом наблюдения, а кто наблюдателем?
* '''2''' Когда объект наблюдения должен послать уведомление своим наблюдателям?
* '''3''' Что должен делать наблюдатель при получении уведомления?
* '''4''' Как должно начинаться и как заканчиваться взаимодействие для организации наблюдения?

Естественно, что на все эти вопросы уже найдены ответы, поэтому давайте рассмотрим рис. 3, на котором изображена диаграмма классов паттерна ''Observer''.

[[Изображение:LXF92_javaee3.png|Рис. 3]]

'''Рис. 3. Диаграмма классов паттерна Observer.'''

В диаграмме определены два интерфейса: '''обозреватель (Observer)'''
и '''объект наблюдения (Observable)'''. Класс, реализующий интерфейс
'''Observable''', предоставляет методы для подключения и отключения
'''обозревателей''', содержит в себе текущий список наблюдателей (атрибут '''observers'''), а также имеет метод оповещения всех наблюдателей – '''notifyObserver()'''. Итак, используем интерфейсы для создания небольшого примера:

<source lang=java>
public interface Observer {
public void handleEvent();
}
public interface Observable {
public void addObserver(Observer o);
public void removeObserver(Observer o);
public void notyfyObserver();
}
</source>

Создадим объект наблюдения – пусть это будет совсем простенькая
модель погоды, которая содержит в себе сведения о температуре окружающей среды (атрибут '''temperature'''):

<source lang=java>
public class Weather implements Observable {
private Set<Observer> observers = new HashSet();
private int temperature;
public void addObserver(Observer o) { observers.add(o); }
public void removeObserver(Observer o) { observers.remove(o); }
public void notyfyObserver() {
for (Observer o : observers) {
o.handleEvent();
}
}
public Weather() { this.temperature = 0;}
public int getTemperature() { return temperature; }
public void setTemperature(int temperature) {
this.temperature = temperature;
notyfyObserver();
}
}
</source>

Теперь создадим класс для ведения наблюдения за температурой,
то есть термометр:

<source lang=java>
public class Thermometer implements Observer {
private int temperature;
private Weather weather;
public Thermometer(Weather weather) {
this.weather = weather; this.handleEvent();
}
public int getTemperature() { return temperature; }
public void setWeather(Weather weather) {
this.weather = weather; this.handleEvent();
}
public void handleEvent() {
if (weather != null) {
temperature = weather.getTemperature();
System.out.println(“температура : “ + temperature);
}
}
}
</source>

Чтобы проверить работоспособность оповещения, попробуйте
выполнить следующий код:

<source lang=java>
Weather currentWeather = new Weather();
Thermometer theThermometer1 = new Thermometer(currentWeather);
Thermometer theThermometer2 = new Thermometer(currentWeather);
currentWeather.addObserver(theThermometer1);
currentWeather.addObserver(theThermometer2);
System.out.println(“Изменение температуры 1”);
currentWeather.setTemperature(10);
System.out.println(“Изменение температуры 2”);
currentWeather.setTemperature(15);
</source>

Вы убедитесь в том, что у каждого наблюдателя вызывается
метод '''handleEvent()''', что влечет за собой изменение его внутреннего
состояния.

Подведем итоги. В этой статье мы рассмотрели реализацию шаблона ''MVC'' в ''J2EE'' и ряда других паттернов, которые позволяют реализовывать масштабируемые приложения и разобрались в требованиях,
предъявляемых к классам так называемых ''JavaBeans''. Кроме того, мы
вкратце ознакомились со способами организации '''Контроллера''' и обратили свое внимание на процесс оповещения объектов на основе паттерна ''Observer''. Пожалуй, на сегодня хватит. '''LXF'''
=== Литература ===

* '''1''' Krasner G.E., Pope S.T. A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80.// Journal of Object-Oriented Programming. – 1988. – № 3, ч. 1. – С. 26-49.

* '''2''' Alexander C., Ishikawa S., Silverstein M., Jacobson M., Fiksdahl-King I. and Angel S. A Pattern Language. – New York: Oxford University Press, 1977. – 1216 с.

* '''3''' Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб.: Питер, 2001. – 368 с.

* '''4''' Мак-Карти Д., Мак-Карти М. Программируем командный дух. – СПб.: Символ-Плюс, 2004. – 416 с.

* '''5''' Тейт Б. Горький вкус Java: Библиотека программиста. – СПб.: Питер, 2003. – 333 с.

* '''6''' Курняван Б. Создание Web-приложений на языке Java. – Москва: Издательство “ЛОРИ”, 2005. – 880 с.

Файл:AddressBook3.tar.bz2

2008-12-30T17:59:02Z

Dionysius: Исходный код примера урока JavaEE в LXF92

Исходный код примера урока JavaEE в LXF92

Файл:AddressBook.tar.bz2

2008-12-30T17:54:29Z

Dionysius: загружена новая версия «Изображение:AddressBook.tar.bz2»: Исходный код примера урока JavaEE в LXF89

Исходники к уроку JavaEE в LXF89

LXF91:Java EE

2008-12-30T17:43:44Z

Dionysius: /* Процесс передачи информации */

{{Цикл/Java EE}}
[[Категория:Учебники]]
__TOC__
:В прошлый раз вы, под чутки руководством '''Александра''', разобрались с JSP и переписали "Телефонную книгу" с учетом этой технологии. Сегодня мы двинемся дальше и поговорим об авторизации, сессиях, фильтрах и использовании разделяемых объектов в web-приложениях.

:''{{oncolor||red|ЧАСТЬ 3}} Каждый линусоид знает, что система уровня предприятия должна обеспечивать разграничение доступа. '''Антон Черноусов''' расскажет, что может предложить здесь Java EE.
[[Media:AddressBook2.tar.bz2|Скачать исходный код примера]]

==Процесс передачи информации==
Давайте рассмотрим стандартную ситуацию: пользователь вызывает различные страницы одного web-приложения. Если бы этот "диалог" происходил по телефону, он был бы примерно таким:
*'''Пользователь (набирает номер): Алло, это приложение?'''
*Приложение: Да, это приложение.
*(Пользователь кладет трубку)
*'''Пользователь (набирает номер): Меня зовут Георг.'''
*Приложение: Да, Георг, мы вас внимательно слушаем.
*(Пользователь кладет трубку)
*'''Пользователь (набирает номер): Дайте мне, пожалуйста, всю информацию.'''
*Приложение: Возьмите...
Отметим, что после каждого обмена репликами пользователь кладет трубку, разрывая соединение - именно таким образом в большинстве случаев и происходит обмен данными между браузером пользователя и сервером, на котором работает web-приложение. Возникает резонный вопрос: как передавать информацию между соединениями, открываемые в рамках одной сессии? Для этого могут использоваться самые различные методы:
*перезапись URL;
*скрытые поля;
*cookie;
*сессионный объект.
Из всех представленных методов наиболее простым и в тоже время можным является сессионный объект (Session), реализованный в Java посредством интерфейса {{oncolor||red|javax.servlet.http.Session}}.
Ранее, чтобы получить данные от пользователя или обеспечить возможность их транспортировки внутри приложения, мы использовали объект типа
{{oncolor||red|HttpServletRequest}}. Основное отличие {{oncolor||red|HttpSession}} заключается во времени жизни, схематично изображенном на '''Рис.1'''. Объект типа {{oncolor||red|HttpServletRequest}} предназначен для передачи запроса (и необходимых данных) от браузера к web-приложению и существует только между запросом и ответом, в то время как объект {{oncolor||red|HttpSession}} обеспечивает средства для хранения и доступа к данным пользователя на протяжениии всего периода работы с приложением.
)(Рис.1) Время жизни объектов HttpServletRequest и HttpSession.
Следует, однако, иметь в виду, что отследить момент, когда пользователь перестает работать с приложением, не всегда возможно. Поэтому в настройках сервера устанавливается некоторое предельное время существования объекта {{oncolor||red|HttpSession}} после получения последнего запроса.

[[Изображение:LXF91_javaee1.png|Рис. 1]]

'''Время жизни объектов ''HttpServletRequest'' и ''HttpSession'''''

==Сессия==
Объект session в JSP является предопределеным, то есть с ним можно сразу же начинать работать. Чтобы создать сессионный объект в сервлете, воспользуемся следующим методом:

HttpSession session = aRequest.getSession(true);

Здесь '''aRequest''' – это экземпляр объекта '''HttpServletRequest''', то есть
запрос переданный сервлету.

Классы, реализующие интерфейс '''HttpSession''', имеют два замечательных метода: '''setAttribute(String, Object)''' и '''getAttribute(String)'''. Метод
'''setAttribute(String, Object)''' применяется для добавления объекта в сессию, а '''getAttribute(String)''' – для извлечения объекта из нее. Например:

<source lang=java>
session.setAttribute(“sameKey”,sameObject);
SameObject aObject = (SameObject) session.getAttribute(“sameKey”);
</source>

Фактически, объект '''session''' – это таблица '''Hashtable''', в которой можно хранить любое количество пар типа «ключ – объект». При использовании сессионного объекта данные приложения не отправляются
пользователю так, как это происходит с cookie. Сессионный объект
хранится на сервере персонально для каждого клиента. Сервер различает сессии с помощью маркера, который передается пользователю.
Маркер хранится в cookies браузера до конца сессии, что накладывает
некоторые ограничения на клиентское рабочее место (использование
cookies для вашего приложения должно быть разрешено). В этом можно легко убедиться, просмотрев сохраненные cookies в вашем любимом браузере.

[[Изображение:LXF91_javaee2.png|Рис. 2]]

'''Маркер сессии. Герои романа «''Лабиринт отражений''» пытались повесить друг другу маркер под видом невинного поцелуя, а наше web-приложение действует еще хитрее и незаметнее.'''

==Авторизация==

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

Давайте создадим JSP-страницу '''auth.jsp''', которая будет запрашивать у пользователя имя и пароль. Сохраните файл в каталоге '''jsps''' и введите в него следующий текст:

<source lang=java>
<span style=”color: green;”><%=request.getAttribute(“message”)%>
</span>
<form action=”<%=request.getContextPath()%>/auth” method=”post”>
<table>
<tr><td>Логин: </td><td><input type=”text” name=”login”/>
</td></tr>
<tr><td>Пароль: </td><td>
<input type=”password” name=”password”/></td>
</tr>
<tr><td colspan=”2” align=”center”>
<input type=”submit” value=”Авторизоваться”/></td>
</tr>
</table>
</form>
</source>

Легко видеть, что в форме имеется два поля ввода и одна кнопка.
Заметим также, что поле для ввода пароля имеет тип '''password''', так что
вместо нажатых клавиш в окне браузера будут отображаться до боли
знакомые «звездочки» ('''‘*’''').

Теперь внесем изменения в '''AddressBookServlet''': расширим ветвление в методе '''handle''' следующим образом:
<source lang=java>
}else if (“/auth”.equals(target)) {
handleAuth(aRequest, aResponse);
}
</source>

Дело за малым – осталось написать метод '''handleAuth(aRequest,aResponse)''', который и будет обрабатывать данные, введенные в форму, то есть производить авторизацию пользователя.
<source lang=java>
private void handleAuth(HttpServletRequest aRequest,
HttpServletResponse aResponse) throws IOException,
ServletException {
String login = aRequest.getParameter(“login”);
String password = aRequest.getParameter(“password”);
if ((login != null) && (password != null)) {
// here is auth process
if ((login.equals(“user”)) && (password.equals(“userPass”))) {
//here is success auth
HttpSession session = aRequest.getSession(true);
session.setAttribute(“auth”,aRequest.getParameter(“login”));
aRequest.setAttribute(“message”, null);
outputPage(“index.jsp”, aRequest, aResponse);
} else {
//here is failed auth
aRequest.setAttribute(“message”,
“Неверный логин или пароль, повторите ввод
данных”);
outputPage(“auth.jsp”, aRequest, aResponse);
}
} else {
//here is no data to auth
aRequest.setAttribute(“message”,
“Логин и пароль не могут быть пустыми, повторите
ввод данных”);
outputPage(“auth.jsp”, aRequest, aResponse);
}
}
</source>

Чтобы не усложнять приложение, мы используем простейший
способ авторизации – имя пользователя и пароль жестко зашиты в
теле метода. С точки зрения безопасности и масштабируемости лучше
использовать для хранения этих данных БД.

В случае удачной авторизации мы помещаем имя пользователя в
объект '''session''' и перенаправляем его на главную страницу. Если же
авторизация не удалась (введено неверное имя пользователя и/или
пароль), пользователю будет предложено повторить попытку.

Таким образом, если авторизация прошла успешно, в сессии пользователя будет сохранен объект, содержащий его имя. Используя этот
факт, можно изменить '''index.jsp''' и спрятать ссылку на добавление нового телефона от посторонних глаз:

<source lang=java>
<%String name = (String)session.getAttribute(“auth”);
if (name != null){ %>
<p>Вы авторизованны как: <%=name%> </p>
<a href=”<%=request.getContextPath()%>/add”>Добавить
запись</a><br/>
<%} else {%>
<a href=”<%=request.getContextPath()%>/auth”>
Авторизоваться</a><br/>
<%} %>
</source>

Мы приветствуем пользователя, используя значение атрибута '''auth'''
и предоставляем ему доступ к функции добавления нового контакта.
Чтобы спрятать удаление и редактирование записей от неавторизованного пользователя, необходимо внести аналогичные изменения в
файл '''view.jsp'''.

==Фильтры==

Наше приложение, к сожалению, страдает проблемами безопасности:
злонамеренный пользователь может обойти процедуру авторизации,
обратившись к функциям редактирования/удаления напрямую, по
адресу '''request.getContextPath() + действие (/add; /edit; /remove)'''; можно также непосредственно вызывать JSP-страницы, расположенные в каталоге '''/jsps''' – нужно только узнать их имена.

Что же делать? Проверять, авторизован ли пользователь перед
выполнением привилегированного действия? Это неудобно – если
количество JSP будет расти, это заставит вас написать много строк
однотипного кода, поддержание которых будет отнимать ваше драгоценное время. Мы пойдем другим путем и воспользуемся так называемыми фильтрами.

Схема работы фильтров представлена на Рис. 3. Если для адреса,
на который отображен сервлет, осуществляется фильтрация, запрос
будет передан сервлету только после того, как пройдет через каждый
установленный фильтр.

[[Изображение:LXF91_javaee3.png|Рис. 3]]

'''Схема прохождения запроса через фильтры.'''

На самом деле, фильтр представляет из себя обыкновенный Java-
класс, реализующий интерфейс '''javax.servlet.Filter'''. Например:
<source lang=java>
public class FirstFilter implements Filter {
private FilterConfig filterConfig;
public void init(FilterConfig filterConfig) throws ServletException {
System.out.println(“Filter init”);
this.filterConfig = filterConfig;
}
public void doFilter(ServletRequest aRequest, ServletResponse
aResponse, FilterChain filterChain)
throws IOException, ServletException {
System.out.println(“Filter used”);
filterChain.doFilter(aRequest, aResponse);
}
public void destroy() {
System.out.println(“Filter dead”);
this.filterConfig = null;
}
}
</source>

Реализовав всего три метода: '''init''' (инициализация фильтра в
момент старта приложения), '''destroy''' (освобождение ресурсов перед
завершением работы приложения) и '''doFilter''' (собственно метод, выполняющий фильтрацию), вы получаете класс, способный существенным образом повлиять на работу вашего приложения.

Обратите внимание, что в приведенном выше примере метод
'''doFilter''' заканчивается вызовом метода '''doFilter(aRequest, aResponse)'''
объекта '''filterChain''' – это обеспечивает вызов следующего фильтра в
цепочке (естественно, если фильтров несколько). Если фильтров больше нет, то управление будет передано следующему ресурсу, например, сервлету.

Остановимся подробнее на методе '''init''', а точнее на объекте, реализующем интерфейс '''FilterConfig'''. Этот объект имеет четыре замечательных метода:
* '''getFilterName()''' – возвращает имя фильтра;
* '''getInitParameterNames()''' – возвращает объект '''Enumeration''', который содержит в своем теле имена параметров текущего фильтра;
* '''getInitParameter(String)''' – возвращает значение параметра, имя которого было передано в качестве аргумента;
* '''getServletContext()''' – возвращает объект '''ServletContext''', о котором мы поговорим ниже.

Как вы уже, наверное, поняли, объект '''FilterConfig''' позволяет получить доступ к конфигурации фильтра, которая была задана при его объявлении в дескрипторе развертывания ('''web.xml''').

==Ограничение доступа==

Итак, воспользуемся фильтрами для ограничения доступа к ресурсам
нашего приложения. Прежде всего, запретим пользователю обращаться напрямую к JSP, и, при попытке запросить ресурс из каталога '''/jsps''',
заставим его перейти на индексную (первую) страницу. Для этого
напишем простой фильтр '''AccessFilter'''. Метод '''doFilter''' будет выглядеть
следующим образом:

<source lang=java>
public void doFilter(ServletRequest aRequest,
ServletResponse aResponse, FilterChain filterChain)
throws IOException, ServletException {
((HttpServletResponse)aResponse).
sendRedirect(((HttpServletRequest)aRequest).getContextPath());
}
</source>

Благодаря методу '''sendRedirect''', вместо ожидаемого ресурса неавторизованный пользователь увидит '''index.jsp'''. Чтобы фильтр заработал, его необходимо подключить в дескрипторе развертывания. Это делается при помощи следующих строк:

<source lang=java>
<filter>
<filter-name>AccessFilterName</filter-name>
<filter-class>AccessFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AccessFilterName</filter-name>
<url-pattern>/jsps/*</url-pattern>
</filter-mapping>
</source>

В секции '''filter''' мы объявляем, что имени фильтра '''AccessFilterName'''
соответствует класс '''AccessFilter''', а в секции '''filter-mapping''' указываем,
на какие объекты распространяется зона действия фильтра. В данном случае фильтр работает по шаблону, то есть используется для
всех адресов типа '''/jsps/*''', где вместо звездочки может быть все, что
угодно.

Теперь давайте создадим класс '''AuthFilter''', который будет ограничивать доступ к некоторым действиям для неавторизованных пользователей. Метод '''doFilter''' будет выглядеть следующим образом:

<source lang=java>
public void doFilter(ServletRequest aRequest,
ServletResponse aResponse, FilterChain filterChain)
throws IOException, ServletException {
HttpSession session = ((HttpServletRequest) aRequest).
getSession();
String name = (String) session.getAttribute(“auth”);
if (name != null) {
filterChain.doFilter(aRequest, aResponse);
} else {
aRequest.setAttribute(“action”, “auth”);
RequestDispatcher dispatcher = aRequest.getRequestDispatcher(“/
auth”);
dispatcher.forward(aRequest, aResponse);
}
}
</source>

Если в текущей сессии не задан атрибут '''auth''', пользователь будет
отправлен на страничку авторизации. Добавим в дескриптор развертывания следующие строки:

<source lang=java>
<filter>
<filter-name>AuthEditFilter</filter-name>
<filter-class>AuthFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthEditFilter</filter-name>
<url-pattern>/edit</url-pattern>
</filter-mapping>
<filter>
<filter-name>AuthAddFilter</filter-name>
<filter-class>AuthFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthAddFilter</filter-name>
<url-pattern>/add</url-pattern>
</filter-mapping>
<filter>
<filter-name>AuthRemFilter</filter-name>
<filter-class>AuthFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthRemFilter</filter-name>
<url-pattern>/remove</url-pattern>
</filter-mapping>
</source>

Обратите внимание, что хотя наш фильтр реализован одним-единственным классом, он может быть доступен по нескольким именам (в
нашем случае: '''AuthEditFilter, AuthAddFilter, AuthRemFilter''') и работать
для разных URL.

Чтобы закрыть тему развертывания фильтров, рассмотрим пример
настройки параметров фильтра в дескрипторе:
<source lang=java>
<init-param>
<description>
That is description
</description>
<param-name>
sameParamName
</param-name>
<param-value>
sameParamValue
</param-value>
</init-param>
</source>

Секцию '''init-param''' необходимо создавать отдельно для каждого
параметра, при этом она должна быть размещена внутри секции '''filter'''.
Обязательными являются подсекции '''param-name''' и '''param-value''', которые задают название параметра и его значение, соответственно.

==Доступ к общим объектам==

Наше приложение уже вполне работоспособно, однако рано или поздно нам захочется расширить его функциональность, и, возможно, для
этого потребуется уже не один сервлет, а несколько, причем все они
будут обращаться к некому общему ресурсу (информации или объектам). Например, вы можете захотеть узнать, сколько пользователей
в данный момент авторизовано в приложении или получить из двух
несвязанных сервлетов доступ к информации, хранящейся в одном
файле.

Подобно сессионным объектам, существует и контекстный объект, который обеспечивает доступ к общим ресурсам из разных мест
приложения. Использование контекстного объекта очень похоже на
использование сессионного, и получить его экземпляр в сервлете можно следующим образом:

<source lang=java>
ServletContext sc = this.getServletContext();
</source>

Этот объект обладает следующими методами:

* '''getAttribute(String)''' – получение общего объекта по ключу;
* '''getAttributeNames()''' – получение списка ключей общих объектов;
* '''setAttribute(String, Object)''' – добавление нового объекта и соответствующего ему ключа;
* '''removeAttribute(String)''' – удаление объекта, соответствующего ключу, из списка общедоступных объектов;

Несмотря на то, что в этой статье контекстному объекту уделено
немного внимания, он является одним из мощнейших инструментов
для обеспечения работы web-приложения.

==Вместо заключения==

Сегодня мы поговорили о сессионных и контекстных объектах, узнали
как создавать и использовать фильтры, рассмотрели простейший пример авторизации пользователя (конечно, надо сделать оговорку, что
было представлено весьма небезопасное и не промышленное решение,
хотя для простого офисного приложения его может быть и достаточно).
Наконец, мы модифицировали наше web-приложение «Телефонная
книга», применяя практически все изученные возможности.

В следующий раз мы рассмотрим паттерн ''MVC'' и его вариацию для
создания web-приложений: ''Model2''. '''LXF'''

Файл:AddressBook2.tar.bz2

2008-12-30T17:40:11Z

Dionysius: Исходный код примера урока JavaEE в LXF91

Исходный код примера урока JavaEE в LXF91

Файл:AddressBook.tar.bz2

2008-12-30T17:37:48Z

Dionysius: загружена новая версия «Изображение:AddressBook.tar.bz2»: Исходный код примера урока JavaEE в LXF91

Исходники к уроку JavaEE в LXF89

LXF90:JavaEE

2008-12-30T17:33:52Z

Dionysius: /* А как это обрабатывается-то? */

{{Цикл/Java EE}}
== {{oncolor||red|Телефонная книга}}: переход на JSP ==
''{{oncolor||red|ЧАСТЬ 2}} Встречают по одежке – и Большой Босс не был сильно впечатлен созданной нами в прошлый раз адресной книгой. '''Александр Бабаев''' исправляет замеченные недочеты.''

__TOC__
В прошлый раз мы создали простейшую электронную записную книжку. Она работает в браузере и показывает несколько простых страничек, на которых можно просмотреть список контактов, добавить новый контакт, удалить его или отредактировать. А сейчас давайте попробуем сделать все это более правильно.

=== Почему было плохо? ===

Действительно, почему? Работает, и хорошо. Достаточно быстро и не слишком сложно. Но вдруг захочется поменять дизайн страничек? А захочется через десять минут работы. Или после того, как страничку посмотрит начальник.

Чтобы сделать это, можно изменить код проекта, потом перекомпилировать его, остановить сервер (А? Кто-то работал? Извините...), установить новый код и повторно запустить сервер. Метод, мягко говоря, неудобный. А можно изменить сам проект так, чтобы выполнение таких пожеланий не требовало столь сложных действий. Второй путь зовется рефакторингом и гораздо более корректен. Если разделить дизайн и логику работы приложения (бизнес-логику), то в дальнейшем можно будет, например, разделить и работу по их поддержанию. Хороший программист не всегда создает хорошие пользовательские интерфейсы, поэтому данный аспект тоже важен.

=== Как сделать хорошо? ===

Ну, вкратце уже понятно. Нужно вынести в отдельные файлы ту часть, которая меняется часто (в нашем случае, это интерфейс) и как-то подключить эти файлы из нашей программы. Плюс, желательно сделать это так, чтобы формат файлов «дизайна» был стандартным, чтобы каждый раз не переучиваться.

Решений для данной проблемы существует множество. Рассмотрим самые распространенные:

* '''Шаблоны.''' Одна из самых распространенных библиотек работы с шаблонами – ''Velocity''. При использовании шаблонных движков можно добавлять в текст специальные вставки, которые говорят: «Тут вставить значение переменной {{oncolor||red|Name}}». Иногда можно делать более сложные операции (вставка подшаблонов, вычисления, условные вставки).

* '''JSP (Java Server Pages).''' По времени появления, пожалуй, первая технология для отделения дизайна от бизнес-логики. Но я ее поставил второй, так как она сложнее, чем просто шаблонная библиотека. JSP позволяет внедрить код на (по задумке) любом языке программирования внутрь специальным образом созданной странички. Впрочем, обычно используется Java. Теоретически, можно написать серверное приложение, используя исключительно JSP. Этот подход похож на PHP, с тем отличием, что JSP-страницы – это полноценные сервлеты, они компилируются при обновлении исходного текста и обрабатываются как таковые.

* '''JSF (Java Server Faces).''' В некотором роде эта технология объединяет подходы, которые используются при создании «обычных» и «сетевых» программ. Интерфейс (как дизайн интерфейса, так и его логика) программы описывается специальным образом, а после этого пишутся JSP-странички, в которых указывается «тут вставить таблицу с именем таким-то». JSF обрабатывает эти спецвставки и «рисует» функциональные элементы интерфейса (обрабатывая события от них и так далее), позволяя дизайнеру сосредоточиться на остальном.

* '''Google Web Toolkit.''' Не могу не остановиться на этом средстве. При его использовании на выходе получается полноценное AJAX-приложение (что это такое – тема отдельной статьи, пример – Google Mail), а на входе – все тот же Java-код. Решение интересное, не лишенное своих достоинств и недостатков.

Мы же в рамках данной статьи рассмотрим «средненькое» решение – Java Server Pages. В основном – из-за его стандартности, хотя для данного конкретного случая можно выбрать какой-нибудь шаблонный движок, например, тот же Velocity (http://velocity.apache.org).

=== Общая схема работы приложения ===

Поняв, что нужно отделить логику от дизайна, давайте подумаем, каким образом это можно сделать. Предлагаю остановиться на следующей схеме - '''(Рис. 1)'''.

Сервлет выдает данные, абсолютно не заботясь о том, как они будут отображаться. Но выдает он их не в «сыром» виде, а в полностью обработанном, готовом для отображения на экране (например, если нужно полное имя человека, а в данных – его ФИО по отдельности, то сервлет должен преобразовать второе в первое перед передачей в JSP).

Возникает вопрос: как же передаются данные от сервлета в JSP? Через уже известный нам объект {{oncolor||red|request}}. К нему «прикручен» специальный ассоциативный массив «{{oncolor||red|String – Object}}», который называется атрибутами и который живет, пока жив запрос. К нему имеет доступ и сервлет, и JSP-страница, поэтому его можно (и это правильно) использовать для передачи данных.

=== Переходим на Tomcat ===

Но сначала нужно переписать наш сервлет «по-взрослому». Встроенный сервер – это замечательно для кустарных проектов, но обычно контейнер сервлетов уже стоит, и подключаться следует к нему.

Мы будем использовать Tomcat 5.5. Это классический, можно даже сказать, стандартный открытый сервлет-контейнер. Для установки Tomcat достаточно просто скачать его с http://tomcat.apache.org (или взять с нашего DVD), распаковать и запустить '''bin/startup.sh''' (или соответсвующий '''.bat'''). ''Tomcat'' работает с файлами специального типа Web Archive (WAR). Обнаружив такой файл в определенном каталоге, Tomcat разворачивает его и запускает содержащееся в нем приложение. Чтобы перезапустить или обновить программу, достаточно просто заменить один WAR-файл другим.

Предыдущий код не готов для работы с Tomcat, поэтому его нужно немного переписать. Вот что будет сделано:

* '''{{oncolor||red|AddressBook}}''' потеряет методы {{oncolor||red|start}} и {{oncolor||red|main}} и превратится в простое хранилище записей.
* '''{{oncolor||red|AddressBookHandler}}''' превратится в {{oncolor||red|AddressBookServlet}}, и в него будет добавлено примерно следующее '''(Листинг 1)''':

'''{{oncolor||red|Листинг 1. Новый AddressBook}}'''

private AddressBook _addressBook = null;

public void init(ServletConfig aServletConfig) throws ServletException {
super.init(aServletConfig);
_addressBook = new AddressBook();
}

protected void doGet(HttpServletRequest aRequest, HttpServletResponse aResponse)
throws ServletException, IOException
handle(aRequest, aResponse);
}

protected void doPost(HttpServletRequest aRequest, HttpServletResponse aResponse)
throws ServletException, IOException
handle(aRequest, aResponse);
}

Сам метод {{oncolor||red|handle}} тоже слегка преобразуется '''(Листинг 2)''':

'''{{oncolor||red|Листинг 2. Новый метод handle}}'''

private void handle(HttpServletRequest aRequest, HttpServletResponse aResponse)
throws ServletException, IOException {
aRequest.setCharacterEncoding("utf-8");

String target = aRequest.getRequestURI().substring(
aRequest.getContextPath().length());

if (target.equals("/")) {
_drawer.outputPage("index.jsp", aRequest, aResponse);
} else if ("/add".equals(target)) {
handleAdd(aRequest, aResponse);
} else if ("/view".equals(target)) {
handleView(aRequest, aResponse);
} else if ("/edit".equals(target)) {
handleEdit(aRequest, aResponse);
} else if ("/remove".equals(target)) {
handleRemove(aRequest, aResponse);
}
}

* Для того, чтобы Tomcat «понял», что ему положили сервлет, и знал, как его обрабатывать, нужно написать специальный файл, который называется «дескриптор». Несмотря на то, что слово страшное, это просто XML-документ с описанием сервлета. Если перевести с языка написания дескрипторов на русский, то получится примерно следующая информация:

** Наш сервлет называется {{oncolor||red|«ABServlet»}} и запускается классом {{oncolor||red|AddressBookServlet}}. Теоретически можно назвать сервлет так же, как и класс, но мы не будем так делать, чтобы было меньше путаницы.

** Для всех URL, которые начинаются с «/», нужно вызывать сервлет, который называется ABServlet.

А вот как он выглядит '''(Листинг 3)''':

'''{{oncolor||red|Листинг 3. Дескриптор для сервлета}}'''

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" >

<servlet>
<display-name>AddressBook</display-name>
<servlet-name>Servlet</servlet-name>
<servlet-class>AddressBookServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>Servlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>

</web-app>

* Дескриптор будет называться '''web.xml''' и храниться в специальном каталоге. Где именно – обсудим, когда будем собирать сервлет в {{oncolor||red|WAR}}
.
Сделайте указанные изменения самостоятельно или возьмите гото-вый код с DVD. Все в порядке? Тогда движемся дальше.

=== Новый метод ===

Если присмотреться более внимательно к коду нового {{oncolor||red|handle}}, можно заметить, что там появился вызов метода {{oncolor||red|outputPage}}. Раньше его, в отличие от разных {{oncolor||red|handle}}... не было. Это метод, который выбирает JSP-файл и передает ему управление для вывода страничек. Выглядит метод следующим образом '''(Листинг 4)''':

'''{{oncolor||red|Листинг 4. Метод outputPage}}'''

public void outputPage(String aJSPName, HttpServletRequest aRequest, HttpServletResponse aResponse) throws IOException, ServletException
{
RequestDispatcher dispatcher = aRequest.getRequestDispatcher("/jsps/" + aJSPName);
dispatcher.forward(aRequest, aResponse);
}

В этом методе мы берем нужный JSP-файл и говорим сервлет-контейнеру: «Обработай, пожалуйста». Остальное берет на себя контейнер. Он ищет JSP-файл, загружает его, компилирует (если это нужно), выполняет получившийся сервлет, а результат записывает в {{oncolor||red|aResponse}}.

=== JSP-страницы ===

Для начала создадим каталог, в котором будем собирать наше интернет-приложение. Назвать можно как угодно, например, {{oncolor||red|WebApp}} ({{oncolor||red|Web Application}}). В нем создадим специальный каталог '''WEB-INF''', где должен находиться дескриптор '''web.xml''', и каталог '''jsps''', в котором будут храниться JSP-странички.

Создадим три JSP-файла: для индексной странички, для редактирования (или добавления) записей и для просмотра, и назовем их, соответственно, '''index.jsp''', '''edit.jsp''', '''view.jsp'''. Не забудьте – их нужно сохранить в в {{oncolor||red|WebApp/jsps}}.

Сам JSP достаточно прост. Рассмотрим '''index.jsp''' '''(Листинг 5)''':

'''{{oncolor||red|Листинг 5. index.jsp}}'''

<nowiki>
<%@ page contentType="text/html; charset=UTF-8" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Адресная книга</title>
</head>
<body><h1>Адресная книга</h1>
<a href="<%=request.getContextPath()%>/add">Добавить запись</a><br/>
<a href="<%=request.getContextPath()%>/view">Просмотреть записи</a><br/>
</body>
</html>
</nowiki>

Первая строчка добавляет поле «Content-type» к HTTP-заголовку ответа. Это прямой аналог строки

aRequest.setContentType("text/html; charset=utf-8")

из «старого» метода {{oncolor||red|handle}}. А дальше, кроме странных вставок {{oncolor||red|<%...%>}}, идет обычный HTML-код. И это хорошо! Это понятно! Теперь разберемся с непонятным.

В JSP можно вставлять «инородный» для HTML код, который специальным образом интерпретируется сервером и может быть использован для вставки различных данных. Есть несколько типов таких вставок.

* {{oncolor||red|<%@...%>}} – обозначает специальную вставку, которая определяет параметры страницы, в нашем случае – {{oncolor||red|ContentType}}. Можно задавать, например, язык, на котором написана страница. Он же используется для секций {{oncolor||red|import}} (см. '''view.jsp''' ниже).
* {{oncolor||red|<%=...%>}} – это простой вывод переменной. Действие вставки {{oncolor||red|<%=что-нибудь%>}} аналогично вызову {{oncolor||red|request.getWriter().write(что-нибудь)}}.
* {{oncolor||red|<%...%>}} – самый общий вариант вставки, внутри может быть любой код. В нашем случае, на Java.

'''index.jsp''' – простой файл, посмотрим на нечто более сложное. Например, '''view.jsp''' '''(Листинг 6)'''.

'''{{oncolor||red|Листинг 6. view.jsp}}'''

<nowiki>
<%@ page contentType="text/html; charset=UTF-8" %>
<%@ page import="java.util.*" %>
<html>
<head><title>Адресная книга</title></head>
<body><h1>Адресная книга, список контактов</h1>
<a href="<%=request.getContextPath()%>">На главную</a><br/>
<span style="color: green;"><%=request.getAttribute("message")%></span>
<table border="1">
<tr><td width="100">Имя</td><td width="100">Номер</td><td width="100">Комментарий</td><td> - </td></tr>
<% Map numbers = (Map) request.getAttribute("numbers");
Map comments = (Map) request.getAttribute("comments");
for (Object entry : numbers.entrySet()) {
String name = (String) ((Map.Entry) entry).getKey();
String number = (String) numbers.get(name);
String comment = (String) comments.get(name); %>
<tr>
<td class="name"><%=name%></td>
<td class="number"><%=number%></td>
<td class="comment"><%=comment%></td>
<td class="name">
<a href="<%=request.getContextPath()%>/remove?number=<%=number%>">Удалить</a>
<a href="<%=request.getContextPath()%>/edit?number=<%=number%>">Редактировать</a>
</td>
</tr>
<% } %>
</table>
</body>
</html>
</nowiki>

Как можно заметить, здесь есть и импорт (о чем я говорил чуть выше), и вставка Java-кода. Данный файл отлично показывает, как, например (не самый лучший способ, конечно), сделать вывод в цикле.

=== А как это обрабатывается-то? ===

Естественно, и методы {{oncolor||red|handle}}... после такого изменения стали другими. Весь вывод HTML-кода исчез, осталась подготовка данных, и вызов метода {{oncolor||red|outputPage}}. Вот, например, метод {{oncolor||red|handleEdit(...)}} '''(Листинг 7)''':

'''{{oncolor||red|Листинг 7. Метод handleEdit, обработка редактирования записи}}'''

if (aRequest.getParameter("number") == null) {
_addressBook.removeContactByNumber(aRequest.getParameter("number"));
aRequest.setAttribute("message", "Не определено, что редактировать");
handleView(aRequest, aResponse);
} else if (aRequest.getParameter("edited") != null) {
_addressBook.editContact(aRequest.getParameter("edited"),
aRequest.getParameter("name"),
aRequest.getParameter("number"),
aRequest.getParameter("comment"));
aRequest.setAttribute("message", "Контакт \"" +
aRequest.getParameter("name") + "\" отредактирован");
handleView(aRequest, aResponse);
} else {
Contact contact = _addressBook.getContactByNumber(aRequest.getParameter("number"));
aRequest.setAttribute("action", "edit");
aRequest.setAttribute("edit.name", contact.getName());
aRequest.setAttribute("edit.number", contact.getNumber());
aRequest.setAttribute("edit.comment", contact.getComment());
outputPage("edit.jsp", aRequest, aResponse);
}

Остальные методы меняются аналогично – их [[Media:Archive.tar.bz2‎|полный код]] можно найти на диске.

=== И как все это вставить в Tomcat? ===

Теперь у нас есть:

* Классы {{oncolor||red|Contact}}, {{oncolor||red|AddressBook}}, {{oncolor||red|AddressBookServlet}}.
* Файл '''web.xml'''.
* Каталог '''jsps''' с файлами '''edit.jsp''', '''index.jsp''', '''view.jsp'''.

Для того, чтобы Tomcat понял, что ему дали полноценное приложение, нужно выполнить всего три шага:

* Скомпилировать все, что компилируется, и создать правильную иерархию файлов и каталогов, которая представлена '''на рис. 2'''.
* Создать специальный файл-описание архива («манифест»).
* Заархивировать созданную структуру при помоци утилиты ''jar'', входящей в комплект JDK.

Скомпилируем файлы. Тут ничего нового не появилось, разве что изменилась сама команда (обратите внимание на ключ {{oncolor||red|-cp}}, задающий библиотеки {{oncolor||red|classpath}}):

cd ~/Programming/AddressBook/src
javac -encoding utf-8 -cp ~/bin/tomcat/common/lib/servlet-api.jar -d ../build/WEB-INF/classes/ *.java

Переходим к созданию манифеста. Он должен называться '''MANIFEST.MF''' и располагаться в каталоге '''META-INF'''. К счастью, за этим следит сам '''jar''', поэтому нам достаточно просто сохранить где-то файл и указать его '''jar''''у как манифест. В нашем случае он предельно прост и не содержит интересной информации, но в принципе здесь могут располагаться всякие настройки для запуска вашего приложения. Вот его текст '''(Листинг 8)''':

'''{{oncolor||red|Листинг 8. Манифест для war-файла}}'''

Manifest-Version: 1.0
Created-By: Hands of programmer

Теперь соберем все в {{oncolor||red|war}} (Web Archive). Манифест для приведенной ниже команды должен быть назван '''MANIFEST.MF''' и располагаться рядом с каталогом '''build'''. Результирующий архив называется '''address.war''' и располагается там же, рядом с манифестом.

jar -cfm ../address.war ../MANIFEST.MF *

А сейчас наступает самый волшебный момент! Возьмите '''address.war''' и положите его в каталог webapps Tomcat'а. Подождите несколько секунд. Увидев новое приложение, Tomcat развернет его (появляется каталог с именем вашего war'а) и подключит к системе. После этого можно просто зайти в браузер и набрать:

http://localhost:8080/address/

Вуаля, получите ваше приложение.

=== И что теперь? ===

А теперь можно менять JSP-файлы «на лету» в распакованном каталоге '''webapps/address/jsps'''. При этом будет автоматически происходить несколько действий, в результате которых файлы подхватятся приложением. Так меняется дизайн без перекомпиляции, без рестарта серверного приложения, как это у нас было до сих пор.

Я считаю, что на данном этапе приложение «Адресная книга» работает хорошо. Оно выполняет свои несложные функции и умеет изменяться «на лету» по запросу пользователя. Оно простое – и это чуть ли не самое главное. Но есть еще достаточно аспектов, о которых стоит знать при разработке более сложных интернет-приложений. Мы рассмотрим их в следующих статьях данной серии. [http://www.linuxformat.ru LXF]

Файл:Archive.tar.bz2

2008-12-30T17:32:02Z

Dionysius: Исходный код примера урока JavaEE в LXF90

Исходный код примера урока JavaEE в LXF90

LXF89:Java EE

2008-12-30T17:29:53Z

Dionysius: /* Что нам потребуется? */

{{Цикл/Java EE}}
'''Новая серия!''' Учимся писать серверные приложения на Java

== Адресная книга ==
''ЧАСТЬ 1: Театр, как известно, начинается с вешалки, а приложения уровня предприятий – с адресной книги: надо же где-то хранить сведения о клиентах. '''Александр Бабаев''' готов познакомить вас с азбукой Java EE.''

{{Врезка
|Заголовок=Наш эксперт
|Содержание=
'''Александр Бабаев'''<br>Разработчик открытой мультиблог-системы jDnevnik – победитель конкурсов IBM WAS CE Contest 2006 и конкурса проектов для разработчиков на Java - Java конкурс 2005.
|Ширина=150px}}

Один из самых распространенных языков программирования для Интернета на настоящий момент – это PHP. Этот язык изначально задумывался для создания домашних страничек, небольших сайтов – и там работает замечательно.

В отличие от PHP, Java (та ее часть, которая помогает разрабатывать серверные приложения) сразу создавалась для крупных приложений уровня предприятия (так называемых Enterprise Applications). Поэтому в Java есть множество механизмов, которые помогают быстро строить очень крупные приложения. Очень крупные – это десятки тысяч транзакций в минуту. Сложных транзакций.

Обо всех возможностях этой технологии не рассказать ни в рамках одной статьи, ни даже в десятке. Но основные блоки JEE (Java Enterprise Edition), которые полезны не только в крупных приложениях, но и в средних и небольших, мы изучим обязательно. А на основании этого опыта можно будет двигаться дальше, читать книги, разрабатывать сложные системы.

=== Сервлеты ===
[[Изображение:Img_89_82_1.jpg|thumb|right|450px|'''Рис. 1.''' Процесс обработки запроса]]
Для начала решим, что же такое сервлет (servlet)? Этим термином принято называть серверное приложение, но чем отличается серверное приложение от клиентского? Клиентское ПО формирует запросы и отсылает их серверному, а задача серверной части – обработать запрос и вернуть на него ответ ('''рис. 1''').

На стороне клиента присутствуют только действия, которые выполняются браузером (показ формы на HTML-странице, формирование стандартизованного запроса).

Серверная сторона в Java обычно состоит из контейнера, который содержит один или несколько сервлетов. Контейнер получает запрос, решает, какому сервлету он предназначен, и запускает на выполнение этот сервлет. Формально происходит примерно следующее:

* Пришедший от клиента запрос анализируется сервлет-контейнером, который создает на его основе специальный объект '''javax.servlet.ServletRequest'''.
* Контейнер решает (как – обычно описывается в специальном конфигурационном файле), какому сервлету предназначен запрос, и передает ему созданный на предыдущем шаге объект '''javax.servlet.ServletRequest''', а также объект '''javax.servlet.ServletResponse''' – шаблон ответа, в который сервлет пишет все, что нужно возвратить клиенту.
* Сервлет обрабатывает запрос, заполняет объект '''javax.servlet.ServletResponse''' и после этого завершает работу.
* Контейнер получает заполненный объект '''javax.servlet.ServletResponse''', после чего преобразует его в стандартизованное сообщение и передает клиенту.

=== Что нам потребуется? ===
{{Врезка
|Заголовок=Коротко о HTTP
|Содержание=
Протокол HTTP был предложен Тимом Бернерсом-Ли, работавшим тогда в CERN, в марте 1990 года как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. В HTTP разделяются понятия «запрос» и «ответ», то есть то, как браузер запрашивает страницу и то, чем сервер на это отвечает. И запрос, и ответ состоят из заголовка и тела. В запросе присутствует еще и строка запроса. Заголовок описывает передаваемые данные, внутри тела передается обычно результат (страница HTML или файл). Существует несколько типов запросов, но наиболее распространены два:
* '''GET''' Запрашивает содержимое указанного ресурса.
* '''POST''' Передает пользовательские данные (например, из формы HTML) заданному ресурсу. Данные включаются в тело запроса.

Вот пример (не точный) простого HTTP-диалога:<br>
'''Запрос'''
<pre>
GET /site/index.html HTTP/1.1
Host: ru.wikipedia.org
</pre>
'''Ответ'''
<pre>
HTTP/1.0 200 OK
Server: Apache
Content-Type: text/html; charset=utf-8
Content-Length: 2121
(Дальше идет 2121 байт текста странички index.html)
</pre>
|Ширина=45%}}
Мы предполагаем, что читатель знаком с тем, что такое HTML, и пробовал делать «странички на PHP» или чем-то аналогичном. Если словосочетания «GET-запрос», «POST-запрос» являются для вас китайской грамотой – прочтите врезку «Коротко об HTTP» (и запаситесь терпением). Подробнее про протокол HTTP можно прочитать в RFC2616, например тут: http://www.w3.org/Protocols/rfc2616/rfc2616.html.

Для работы нам понадобятся следующие инструменты:
* JDK 5 (или JDK 6) – если вы выполняли все задания предыдущей серии уроков Java, нужный дистрибутив, скорее всего, уже имеется в вашей системе (вы ведь выполняли задания, не так ли?). JDK можно бесплатно загрузить с сайта http://java.sun.com или установить из репозиториев вашего дистрибутива Linux. После установки JDK необходимо убедиться, что пути к каталогу '''$JDK/bin''' прописаны в переменной окружения PATH, а каталоги, в которых располагаются библиотеки классов, перечислены в CLASSPATH.
* Ваш любимый текстовый редактор.
* Библиотека Jetty (http://www.mortbay.org/). В принципе, это полноценный web-сервер, который может очень и очень многое. Нам будет полезна его особенность, позволяющая встроить web-сервер в наше приложение.

Все необходимые библиотеки [[Media:AddressBook.tar.bz2|и исходный код примера]] есть на прилагаемом компакт-диске.

=== Что мы будем делать? ===
Для примера мы возьмем и напишем корпоративную адресную книгу, в которой будем сохранять телефоны сотрудников, причем каждый сможет добавить телефоны нужных людей, и все смогут просмотреть сохраненные телефоны. Итак, начнем.

Создадим иерархию каталогов для проекта, например, такую:
* '''~/Programming/AddressBook/.'''
* '''build''' – каталог для скомпилированных классов.
* '''src''' – исходные тексты.
* '''libs''' – каталог для библиотек.

Заполним каталоги. Для начала возьмите Jetty, распакуйте архив, найдите в нем файлы '''jetty-6.1.0rc3.jar'''; '''jetty-util-6.1.0rc3.jar'''; '''servlet-api-2.5.jar''' и поместите их в каталог '''libs''' (можно взять и другую версию,
правда, с известной долей осторожности – иногда меняются API, тогда наша программа просто не скомпилируется).

Теперь настало время придумать, как будет работать наша телефонная книга. Разумно будет создать четыре основных страницы:
* Главная – на ней будут ссылки помещены на остальные страницы приложения.
* Страница добавления нового контакта.
* Страница редактирования контакта.
* Страница поиска/просмотра контактов.

Классов в нашем приложении будет всего три:
* '''AddressBook.''' Главный класс, который запускается и «висит» в памяти, обрабатывая запросы пользователей. Обычно эту роль выполняет уже упомянутый сервлет-контейнер (роль которого может выполнять, например, Apache Tomcat), но мы избавились от него, использовав Jetty.
* '''AddressBookHandler.''' Класс-обработчик запросов пользователей. Именно этот класс и называется сервлетом. Он обычно подключается к сервлет-контейнеру через специфический конфигурационный файл, но мы избавились и от этого – спасибо, Jetty!
* '''Contact.''' Класс, который содержит поля контакта. Эти поля будут выводиться на странице и редактироваться. Его код очень простой:

'''Листинг 1.''' Контакт
<source lang="java">
import java.io.*;
public class Contact implements Serializable {
private String _name = "";
private String _number = "";
private String _comment = "";
public String getName() { return _name; }
public String getNumber() { return _number; }
public String getComment() { return _comment; }
public void setData(String aName, String aNumber, String aComment) {
_name = aName;
_number = aNumber;
_comment = aComment;
}
}
</source>

=== Основной класс/класс запуска приложения (AddressBook) ===
Этот класс содержит метод '''main''', инициализирует Jetty и подключает сервлет ('''AddressBookHandler''', '''листинг 2''').

'''Листинг 2.''' Класс запуска приложения
<source lang="java">
import org.mortbay.jetty.*;
import org.mortbay.jetty.nio.*;

import java.util.*;
import java.io.*;

public class AddressBook {
private void start() throws Exception {
try {
_contactsByName = (SortedMap<String, Contact>) new XStream().
fromXML(new FileReader("contacts.xml"));
} catch (Exception e) { }

Server _jettyServer = new Server();
Connector connector = new SelectChannelConnector();
connector.setPort(8081);
_jettyServer.setConnectors(new Connector[]{connector});
_jettyServer.setStopAtShutdown(true);
Handler handler = new AddressBookHandler(this);
_jettyServer.setHandler(handler);
_jettyServer.start();
}
public static void main(String[] args) throws Exception {
new AddressBook().start();
}
}
</source>

Также этот класс содержит саму адресную книгу:

'''Листинг 3.''' Адресная книга
<source lang="java">
private SortedMap<String, Contact> _contactsByName = new TreeMap<String,Contact>();

public SortedMap<String, Contact> getContactsByName() {
return _contactsByName;
}

public Contact getContactByNumber(String aNumber) {
for (Map.Entry<String, Contact> entry : _contactsByName.entrySet()) {
if (entry.getValue().getNumber().equals(aNumber)) {
return entry.getValue();
}
}
return null;
}
</source>

и методы, которые позволяют добавлять/удалять/редактировать контакты:

'''Листинг 4.''' Работа с контактами
<source lang="java">
public void addContact(String aName, String aNumber, String aComment)
throws IOException {
Contact contact = new Contact();
contact.setData(aName, aNumber, aComment);
_contactsByName.put(aName, contact);
saveContactsInformation();
}

public void removeContactByNumber(String aNumber) throws IOException {
Contact contact = getContactByNumber(aNumber);
if (contact != null) {
_contactsByName.remove(contact.getName());
saveContactsInformation();
}
}

public void editContact(String aEditNumber, String aName, String aNumber, String aComment)
throws IOException {
Contact contact = getContactByNumber(aEditNumber);
if (contact != null) {
contact.setData(aName, aNumber, aComment);
saveContactsInformation();
}
}

private void saveContactsInformation() throws IOException {
new XStream().toXML(_contactsByName, new FileWriter("contacts.xml"));
}
</source>

=== Класс-обработчик (AddressBookHandler) ===
Обработка событий пользователя концентрируется в одном методе ('''public void handle(…)''') класса '''AddressBookHandler'''. Самые главные параметры этого метода – второй '''aHttpServletRequest''' и третий '''aHttpServletResponse'''. '''Request''' – это запрос. В нем хранятся все данные, которые передал нам браузер пользователя. А '''Response''' – это объект, в который нужно записать все, что требуется передать пользователю. Например, на любой запрос пользователя можно отвечать страницей с гордым заголовком «адресная книга» ('''листинг 5'''):

'''Листинг 5.''' Код обработчика
<source lang="java">
import org.mortbay.jetty.handler.*;
import org.mortbay.jetty.*;

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;

public class AddressBookHandler extends AbstractHandler {
private AddressBook _addressBook = null;

public AddressBookHandler(AddressBook aAddressBook) {
_addressBook = aAddressBook;
}
public void handle(String aTarget, HttpServletRequest aRequest,
HttpServletResponse aResponse, int aDispatchMode)
throws IOException, ServletException {

((Request) aRequest).setHandled(true);
aRequest.setCharacterEncoding("utf-8");
aResponse.setCharacterEncoding("utf-8");
aResponse.addHeader("Content-type", "text/html; charset=utf-8");
PrintWriter writer = aResponse.getWriter();
writer.write("<html><head>" +
"<title>Адресная книга</title>" +
"</head><body><h1>Адресная книга</h1>");
}
}
</source>

Откомпилируйте полученный код:

<pre>
cd ~/Programming/AddressBook/src
javac –encoding utf-8 -cp ../libs/jetty-6.1.0rc3.jar:../libs/jetty-util-6.1.0rc3.
jar:../libs/servlet-api-2.5.jar -d ../build *.java
</pre>

И запустите (не забыв подключить все требуемые библиотеки):

<pre>
cd ~/Programming/AddressBook/build
java -cp ../libs/jetty-6.1.0rc3.jar:../libs/jetty-util-6.1.0rc3.jar:../libs/servletapi-
2.5.jar:. AddressBook
</pre>

Терминал выводит несколько строчек и «зависает». Все правильно, сервер запустился. Запускать наше приложение будем пока именно так, чтобы его можно было легко выключить ('''Ctrl+C'''). Теперь откройте браузер и наберите в адресной строке: '''<nowiki>http://localhost:8081</nowiki>'''. Вот он, наш заголовок!

Вернемся к обработчику и попробуем уяснить, как различать запросы пользователей. Для этого в обработчике есть две возможности. Самая простая – посмотреть на первый параметр ('''aTarget'''), который содержит «файл» запроса (например в URL’е «http://www.linuxformat.ru/index.html» '''aTarget''' будет «'''/index.html'''»); посложнее – анализировать сам объект запроса. Воспользуемся первым вариантом, дописав в конец метода '''handle''' (прямо перед закрывающей скобкой) следующее:

'''Листинг 6.''' Более сложный обработчик с разбором адреса
<source lang="java">
if ("/".equals(aTarget)) {
writer.write("<a href=\"/add\">Добавить запись</a><br/>");
writer.write("<a href=\"/view\">Просмотреть записи</a><br/>");
} else {
writer.write("<a href=\"/\">На главную</a><br/>");

if ("/add".equals(aTarget)) {
writer.write("<h2>Добавление записи</h2>");
} else if ("/view".equals(aTarget)) {
writer.write("<h2>Просмотр записей</h2>");
} else if ("/edit".equals(aTarget)) {
writer.write("<h2>Редактирование записи</h2>");
} else if ("/remove".equals(aTarget)) {
writer.write("<h2>Удаление записи</h2>");
}
}

writer.write("</body></html>");
</source>

Попробуйте снова откомпилировать и запустить приложение, предварительно остановив предыдущую версию сервера. Обновите страницу в браузере – и побегайте по только что созданным страницам нашего сайта (корневая, она же «'''/'''», «'''/add'''», «'''/edit'''», «'''/remove'''»).

Теперь в соответствующих ветках '''if''' можно написать обработчики страничек. Для упрощения вынесем эти обработчики в отдельные методы ('''листинг 7'''):

'''Листинг 7.''' Добавляем обработчики отдельных действий
<source lang="java">
if ("/add".equals(aTarget)) {
writer.write("<h2>Добавление записи</h2>");
handleAdd(aRequest, writer);
} else if ("/view".equals(aTarget)) {
writer.write("<h2>Просмотр записей</h2>");
handleView(writer);
} else if ("/edit".equals(aTarget)) {
writer.write("<h2>Редактирование записи</h2>");
handleEdit(aRequest, writer);
} else if ("/remove".equals(aTarget)) {
writer.write("<h2>Удаление записи</h2>");
handleRemove(aRequest, writer);
}
</source>

Осталось понять, как именно обрабатывать соответствующие страницы. Рассмотрим, для примера, метод '''handleAdd()''' – остальные можно написать по аналогии:

'''Листинг 8.''' Обработчик добавления записи
<source lang="java">
private void handleAdd(HttpServletRequest aRequest, PrintWriter aWriter)
throws IOException {
if (aRequest.getParameter("name") != null) {
_addressBook.addContact(aRequest.getParameter("name"),
aRequest.getParameter("number"), aRequest.getParameter("comment"));
outputMessage(aWriter, "Контакт добавлен");
}
outputForm(aWriter, aRequest, "", "", "");
}
</source>

В приведенном обработчике есть вызов метода '''aRequest.getParameter("name")'''. Этот метод выдает значение параметра, который передает браузер из формы ('''<input type="text" name="name"/>'''). Причем сервлету все равно, каким методом (GET/POST) был передан параметр. Конкретно для обработки добавления контакта в коде проверяется, равен ли результат вызова '''null'''. Если так – значит, форма «не выполнялась», и добавлять нечего. В противном случае мы считываем три параметра (имя, телефон и комментарий), сохраняем контакт и выводим форму (вдруг пользователь захочет добавить еще один контакт?).

Методы '''outputForm''' и '''outputMessage''' ('''листинг 9''') выводят форму (либо пустую, либо заполненную данными, которые нужно редактировать) и сообщение (чтобы пользователь понимал, что действие произошло, и как оно завершилось):

'''Листинг 9.''' Обработчик добавления записи
<source lang="java">
private void outputForm(PrintWriter aWriter, HttpServletRequest aRequest,
String aName, String aNumber, String aComment) {
aWriter.write(
"<form action=\"/edit\" method=\"post\">" +
"<input type=\"hidden\" name=\"edited\" value=\"" +
aRequest.getParameter("number") + "\"/>" + "<table>" +
"<tr><td>Имя: </td><td><input type=\"text\" name=\"name\" value=\"" +
aName + "\"/></td></tr>" +
"<tr><td>Телефон: </td><td><input type=\"text\" name=\"number\" value=\"" +
aNumber + "\"/></td></tr>" +
"<tr><td>Примечания: </td><td><input type=\"text\" name=\"comment\" value=\"" +
aComment + "\"/></td></tr>" +
"<tr><td colspan=\"2\" align=\"center\">" +
"<input type=\"submit\" name=\"Отправить\"/></td></tr>" +
"</table></form>");
}

private void outputMessage(PrintWriter aWriter, String aMessage) {
aWriter.write("<span style=\"color: green;\">" + aMessage + "</span>");
}
</source>

Для того, чтобы проверить работу нового обработчика, закомментируйте вызовы методов, которые еще не написаны (или напишите «заглушки» в виде пустых методов). Теперь можно снова остановить сервер, скомпилировать программу и запустить ее на выполнение. Если все набрано правильно, ошибок не последует, и можно будет просматривать табличку с контактами, добавлять их, редактировать и удалять. Наша адресная книга готова к работе!

На этом уроке вы создали свое первое JEE-приложение. Конечно, за кадром осталось множество возможностей – начиная с использования сессий, контроля корректности параметров, и заканчивая отделением дизайна от логики работы сервлета – но наша программа уже вполне работоспособна. И, конечно, история не заканчивается. В следующих статьях будет продолжение, посвященное развитию приложения в соответствии с усложнением запросов компании к адресной книге.

Файл:AddressBook.tar.bz2

2008-12-30T17:20:16Z

Dionysius: Исходники к уроку JavaEE в LXF89

Исходники к уроку JavaEE в LXF89