Развертывание – это еще один аспект создания программного продукта, который хорошо поддается автоматизации. Это позволяет получить все преимущества надежного процесса: повысить точность, скорость и контроль над выполнением нужных действий. В первой части были рассмотрены восемь принципов автоматизированного развертывания приложений. В этой статье мы поговорим о следующих семи не менее полезных принципах:
Принцип двоичной согласованности, гарантирующий, что ни один артефакт не будет потерян в процессе развертывания приложения в целевых окружениях.
Принцип одноразового контейнера, в соответствии с которым среда для развертывания должна переводиться в заранее известное состояние. Благодаря этому снижается вероятность ошибок.
Принцип удаленного развертывания, гарантирующий взаимодействие с несколькими удаленными серверами с центрального компьютера или кластера.
Принцип обновления базы данных, целями которого являются организация и централизованное управление скриптовым процессом для выполнения последовательных изменений в базе данных.
Эндрю Гловер (Andrew Glover) начал писать о Groovy для сайта developerWorks еще в 2004 г. Первой в свет вышла статья Почувствуйте Groovy в серии alt.lang.jre, которая была продолжена длинной чередой статей под общим названием Groovy на практике. В те времена еще не было выпущено ни одной книги по Groovy (сейчас их уже более десятка). Более того, до выхода Groovy 1.0 оставалось еще несколько лет. В общем, многое успело измениться с тех пор, как в 2006 г. на сайте developerWorks была опубликована последняя статья из серии «Groovy на практике».
В настоящее время количество загрузок дистрибутива Groovy в Интернет достигло примерно 35 тыс. копий в месяц. Приложения компаний, отличающихся своей консервативностью, например Mutual или Omaha, уже включают более 70 тыс. строк кода на Groovy. Список рассылки, относящийся к Groovy, является одним из наиболее популярных на сайте Codehaus.org, на котором и размещается проект Groovy (см. раздел Ресурсы). Groovy уступает по количеству загрузок и популярности списка рассылки только одному проекту: Grails – инфраструктуре для разработки Web-приложений, причем она написана на Groovy (см. раздел Ресурсы).
Java неразрывно связывают с аплетами. И действительно, аплеты — неотъемлемая часть как языка, так и платформы Java в целом. К тому же их создание — удачный маркетинговый шаг Sun. Без аплетов мир о Java не узнал бы так быстро.
Идея встраиваемых приложений в гипертекстовые документы (HTML) не так уж и нова. Многие фирмы пытались продвинуть свои технологии на этот сектор рынка, но в настоящее время конкурентов у Java здесь немного. На сегодня это, пожалуй, JavaScript, ActiveX и технология Flash. Две последние, правда, работают только под управлением Windows.
Что привлекает в Java программистов? Мощная модель безопасности, единый код для всех платформ, широкие возможности для использования готовых библиотек, простота программирования. В действительности все не так радужно, как хотелось бы. Модель безопасности, безусловно, не плоха, но ее реализации, выполненные теми или иными производителями, различаются. В результате код, прекрасно работающий под управлением одного браузера, не работает под управлением другого.
“Создаешь один раз — используешь где угодно” (“Write once — run anywhere”). Вторая часть этого лозунга создателей Java содержит утверждение, что Java-программа работает везде одинаково. К сожалению, в действительности все не так просто. Java-машины различных компаний на различных платформах НЕ стопроцентно совместимы друг с другом.
Отличия в работе Java-машин на разных платформах существуют и в реализации мультизадачности, и в работе оконной библиотеки (AWT). Сложные Java-программы необходимо “прогонять” на разных платформах, чтобы убедиться, что все в порядке. Вообще говоря, даже и на одной платформе, но на разных машинах, подобные программы могут выполняться по-разному.
Например, программист может столкнуться с ситуацией, когда его код на многопроцессорной машине ведет себя иначе, чем на однопроцессорной. Особо следует упомянуть Java-машину, созданную компанией Microsoft (далее MS JVM). Она носит название Java не совсем законно (что было подтверждено недавним решением суда).
JiBX — это инструмент для установления соответствия между данными XML и объектами Java. JiBX давно известен как самый быстрый и гибкий способ установления соответствия между кодом Java и XML. Однако сложность этих определений соответствия и ограниченная поддержка все более широко используемых определений XML-схемы иногда расхолаживали пользователей. К счастью, в версии JiBX 1.2 сделано многое для решения этих проблем. Из этого руководства вы узнаете об использовании новых функций JiBX 1.2 для простой генерации кода Java из существующего определения XML-схемы и для чтения/записи XML-документов в соответствии со сгенерированными определениями схемы — и все это без необходимости вдаваться в детали определений соответствия JiBX. В первой части был описан обратный процесс преобразования кода Java в определения XML-схемы.
