JiBX 1.2: Часть 2. От XML-схемы к коду Java

August 13th, 2010 No comments

JiBX — это инструмент для установления соответствия между данными XML и объектами Java. JiBX давно известен как самый быстрый и гибкий способ установления соответствия между кодом Java и XML. Однако сложность этих определений соответствия и ограниченная поддержка все более широко используемых определений XML-схемы иногда расхолаживали пользователей. К счастью, в версии JiBX 1.2 сделано многое для решения этих проблем. Из этого руководства вы узнаете об использовании новых функций JiBX 1.2 для простой генерации кода Java из существующего определения XML-схемы и для чтения/записи XML-документов в соответствии со сгенерированными определениями схемы — и все это без необходимости вдаваться в детали определений соответствия JiBX.

В первой части был описан обратный процесс преобразования кода Java в определения XML-схемы.

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

Смотрите другие материалы о Java на IBM developerWorks Россия

JiBX 1.2: Часть 1. От кода Java к XML-схеме

August 4th, 2010 No comments

JiBX – это инструмент для установления соответствия между данными XML и объектами Java. JiBX давно известен как самый быстрый и гибкий способ установления соответствия между кодом Java и XML. Однако сложность этих определений соответствия и ограниченная поддержка все более широко используемых определений XML-схемы иногда расхолаживали пользователей. К счастью, в версии JiBX 1.2 многое сделано для решения этих проблем. Из этого руководства вы узнаете об использовании новых функций JiBX 1.2 для простой генерации определений XML-схемы из существующего кода Java и чтении и записи XML-документов в соответствии со сгенерированными определениями схемы – и все это без необходимости вдаваться в детали определений соответствия JiBX. Во второй части описан обратный процесс преобразования определений XML-схемы в код Java.

Это руководство проведет вас по процессу использования JiBX для генерации определений XML-схемы из кода Java. Сначала вы увидите, как на основе простой модели данных Java сгенерировать соответствующую этой модели схему с параметрами по умолчанию. Оттолкнувшись от этой платформы, вы научитесь легко применять целый ряд настроек для управления фактическими значениями, которые используют и к которым обращаются ваши классы Java, будь то обязательные или опциональные значения, используемые в XML имена и пространства имен и даже сгенерированная структура определений схемы. В процессе чтения вы увидите, как JiBX повышает ценность сгенерированных вами схем, используя ваши инвестиции в Javadocs для автоматического документирования определений схемы. Проведя работу с приведенными здесь примерами, вы сможете использовать JiBX для генерации качественных определений XML-схемы из своих собственных классов структуры данных Java.

Подробнее на IBM developerWorks Россия

MySQL & PostgreSQL

July 28th, 2010 No comments

При сравнении MySQL и PostgreSQL исторически сформировался следующий подход:

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

Часть 1: Сравнительный анализ.
MySQL и PostgreSQL – две наиболее популярные open-source базы данных в мире. Каждая база имеет свои особенности и отличия. Если вам нужно быстрое хранилище для простых запросов с минимальной настройкой, я бы порекомендовал MySQL. Если вам нужно надежное хранилище для большого объема данных с возможностью расширения, репликации, полностью соответствующее современным стандартам языка SQL, я бы предложил использовать PostgreSQL.

Часть 2: Конфигурация MySQL.

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

Часть 3: Конфигурация PostgreSQL.

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

Часть 4: Масштабирование MySQL.

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

Часть 5: Масштабирование PostgreSQL.

В предыдущей статье мы обсудили вопросы масштабирования MySQL. Рассмотрим эти моменты для сервера баз данных PostgreSQL.

Часть 6: Репликация MySQL.

Реализация репликаций в MySQL имеет ряд недостатков, над которыми активно ведется работа. Google выпустил несколько патчей, улучшающих возможности репликации. Ведется работа над multimaster и построчной репликациями, которые появятся в будущих версиях. Имеются планы по автоматической конфигурации слэйвов. Все это вселяет уверенность в том, что одна из самых востребованных на сегодняшний день open-source баз данных MySQL станет еще продуктивнее, еще быстрее, еще надежнее.

Защита JavaBeans в приложениях JSF

July 21st, 2010 No comments

Эта серия из пяти статей знакомит с системой безопасности Acegi и показывает, как использовать Acegi для обеспечения безопасности корпоративных Java-приложений. Эта заключительная статья продолжает обсуждение использования Acegi для обеспечения безопасности приложений JSF. В части 4 я показал, как можно обеспечить безопасность страницы JavaServer Faces (JSF) с использованием Acegi без написания какого-либо программного кода на Java. Я также подробно разобрал события, которые происходят при развертывании приложения JSF-Acegi и при обращении пользователя к нему. В этот раз я сосредоточусь на методах обеспечения безопасности JavaBeans в приложениях JSF.

Сначала я покажу, что концепции безопасности bean-компонентов, которые я описывал в части 3 этой серии, могут применяться и к приложениям JSF, но не идеальны для них. Затем я продемонстрирую пару новых методов, особенно удобных для обеспечения безопасности JavaBeans, используемых в приложениях JSF. Я закончу обсуждение представлением четырехступенчатой стратегии, которая позволяет использовать Acegi для обеспечения безопасности bean-компонентов в приложениях JSF без написания какой-либо защитной программы на Java.


Подробнее на IBM developerWorks Россия

Новые возможности Apache Solr

July 14th, 2010 No comments

Apache Solr представляет собой поисковый сервер с открытым исходным кодом, основанный на Apache Lucene и работающий преимущественно через протокол HTTP. В 2007 г. на сайте developerWorks была опубликована серия из двух статей под названием Умный поиск при помощи Apache Solr, в которых содержалась вводная информация о Solr. Однако после выпуска версии 1.3 пришло время описать множество новых возможностей и усовершенствований, появившихся с тех времен.

Solr предоставляет множество функций, делающих его пригодным для использования в корпоративных приложениях, а именно: поддержку простого конфигурирования и администрирования, поддержку множественных связей между клиентами и языками, репликацию индексов, кэширование, статистику и журналирование. Кроме того, в версии 1.3 существенно улучшена производительность благодаря громадному прогрессу в быстродействии Apache Lucene 2.3, а также использованию новой обратно совместимой и встраиваемой компонентной архитектуре. Данная архитектура послужила основанием для появления большого числа новых компонентов, которые дополнительно расширяют возможности Solr. Например, в релиз 1.3 вошли следующие компоненты:

* проверка орфографии с поддержкой функции “Вы, наверное, имели в виду следующее?”;
* поиск документов по принципу схожести;
* возможность переопределения результатов поиска (так называемое “платное размещение”).

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

Мы начнем с краткого описания ключевых моментов в Solr, а затем перейдем к последней версии и ее установке (в том числе к некоторым моментам перехода с предыдущей версии). Далее мы рассмотрим некоторые из главных улучшений по сравнению с предыдущим релизом и закончим обзором некоторых новых функций Solr.

Подробнее на IBM developerWorks Россия

Новые математические возможности Java

July 7th, 2010 No comments

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

В пятой версии спецификации языка Java™ (Java Language Specification) было добавлено 10 новых методов в классы java.lang.Math и java.lang.StrictMath. Еще 10 методов появилось в шестой версии. В первой статье серии были рассмотрены методы, имеющие четкое математическое определение, знакомое математикам, жившим до изобретения компьютеров. В этой статье основное внимание будет уделено методам, смысл которых становится ясен только при осознании того, что они оперируют с числами с плавающей точкой, а не c абстрактными вещественными числами.

В первой части отмечалось важное отличие вещественных чисел, таких как e или 0.2, от их машинного представления, например, типа данных double в Java. Точное представление вещественного числа может быть бесконечно длинным, в то время как в Java на представление отводится фиксированное число битов (32 для float и 64 для double). Максимальным числом, представимым в формате float, является примерно 3.4*1038. Этого в некоторых случаях может не хватить, например, для числа электронов во Вселенной.

Тип данных double способен представлять числа до 1.8*10308, чего, как мне кажется, должно хватать для практически всех физических величин. Однако при вычислении абстрактных математических значений можно выйти за пределы этого ограничения. Например, число 171! (171 * 170 * 169 * 168 * … * 1) больше максимального числа, представимого в формате double, а float не хватает уже для вычисления 35!. Малые числа (числа, близкие к нулю) также могут представлять собой проблему, поэтому вычисления, в которых участвуют очень большие либо очень малые числа, являются потенциально небезопасными.

В стандарте IEEE 754 для операций с плавающей точкой (см. раздел Ресурсы) вводятся специальные величины: Inf для представления бесконечности и NaN (Not a Number) для представления всего, что не является числом. В этом стандарте также определены положительные и отрицательные нули (в обычной математике ноль не обладает знаком, а в компьютерной – может обладать любым знаком). Эти значения являются настоящим бедствием при доказательстве классических теорем. В частности, закон исключенного среднего (law of exluded middle) не выполняется в присутствии NaN, поскольку утверждение x == y или x != y оказывается ложным, если x или y равен NaN.

Часть 1. Вещественные числа
Часть 2. Числа с плавающей точкой

JavaScript EE: Часть 1. Исполнение файлов JavaScript на стороне сервера

June 30th, 2010 No comments

Комбинирование JavaScript с кодом Java™ на сервере позволяет свободно использовать одни и те же программы JavaScript как в серверных, так и в клиентских системах. Кроме того, методы, представленные в этой серии статей, позволяют работать с одной и той же базой кода как на Ajax-, так и на не-Ajax клиентских системах. Так как большая часть кода для сервера все равно пишется на языке Java, функции Java Platform, Enterprise Edition (Java EE) желательно сделать доступными для JavaScript. В этих статьях показано, как исполнять файлы JavaScript со стороны сервера, вызывать функции JavaScript с помощью Ajax и использовать API Java Scripting с технологией JavaServer Pages (JSP).

На стороне клиента типичные приложения Ajax используют JavaScript, а на стороне сервера — другие языки, такие как Java. В результате разработчикам приходится создавать некоторые программы дважды, используя для Web-браузера JavaScript, а для сервера другой язык. Этой двойной работы можно избежать, воспользовавшись на стороне сервера языком JavaScript в сочетании с Java, чтобы получить полную поддержку языков сценариев через API javax.script. К тому же Java SE Development Kit (JDK) 6 уже содержит механизм JavaScript Rhino от Mozilla, поэтому дополнительно устанавливать ничего не нужно.

В этой первой статье данной серии мы воспользуемся простым сценарием, который позволяет исполнять файлы JavaScript внутри приложений Java ЕЕ. Сценарии будут иметь доступ к так называемым “неявным объектам” (implicit objects), которые используются в страницах JSP, таким как application, session, request и response. Большинство примеров состоит из многократно используемого кода, так что вам будет легко перейти к применению JavaScript на сервере в своих собственных приложениях.

Подробнее на IBM developerWorks Россия

Удалённые вычисления с nanoHUB

June 23rd, 2010 No comments

nanoHUB — это виртуальный вычислительный центр, созданный для поддержки исследований в области нанотехнологий. Он использует компоненты с открытым исходным кодом для получения гораздо более впечатляющих результатов, чем используемые ранее средства удалённого доступа. Эта статья подробно описывает частные настройки и усовершенствования, необходимые для получения максимальной производительности, безопасности и удобства в использовании от применения такого известного программного обеспечения, как VNC и WebDAV.

nanoHUB.org использует уникальную систему ПО Middleware, в которой обеспечен точный баланс безопасности, производительности и гибкости для поддержки распределённых публичных исследований в области нанотехнологий. Учёные, которые используют этот «исследовательский шлюз», могут больше внимания уделять своим исследованиям, а не вычислительным задачам.

Между тем, помимо явных важных преимуществ, nanoHUB дает представление о том, как можно настроить и улучшить хорошо известные в мире открытого ПО программы для значительного расширения возможности виртуальных вычислений. Говоря об этом проекте, Суприйо Датта, директор института наноэлектроники вычислений NASA/Purdue, подчеркнул: “Приложив совсем немного усилий, мы сделали наши инструменты моделирования доступными для наших коллег. Теперь наши коллеги могут легко запускать программу молекулярного электронного моделирования”. Как видно из рисунка 1, nanoHUB приятно сочетает в себе простоту использования для учёных, которые публикуют с его помощью свои работы, и для их коллег, которые знакомятся с этими публикациями.

Источник IBM developerWorks Россия

Восстановление AIX-систем после аварий

June 16th, 2010 No comments

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

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

Многие IT-отделы пытаются поддерживать многочисленные стандарты реализации, одни — для кластерных систем, другие — для систем, не объединённых в кластер, третьи — для катастрофоустойчивых систем. Поддержка многочисленных стандартов сама по себе может быть источником и причиной конфликтов во время выполнения аварийного восстановления. Объединение множества стандартов в единый стандарт должно стать целью планирования проекта аварийного восстановления и общей стратегией непрерывности бизнеса.

Можно выделить несколько типичных проблем, возникающих во время аварийного восстановления систем AIX:

* Резервные системы по своим характеристикам (тип, число процессоров и емкость) отличаются от продукционных систем; обычно это более новые системы с обновленными ОС
* Проблемы прав доступа пользователей и групп
* Множество экземпляров одного приложения (каждое приложение развертывается на отдельной продукционной системе, но в резервной системе может быть установлено несколько приложений)
* Проблемы с сетевыми именами и проблемы адресации
* Продукционные приложения (привязанные к конкретному сетевому адресу или сетевому имени во время установки)
* Конфликты между именами узлов и именами хостов в сети (конфликты между системами, установленными в ЦОДе, и новыми системами, которые запускаются при аварии)
* Многочисленные стандарты реализации для разной функциональности (автономность, отказоустойчивость и восстановление после катастроф)

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

Подробнее на IBM developerWorks Россия

Создание высокопроизводительных Java-приложений для доступа к данным: Часть 3. Практические приемы работы с API pureQuery в Data Studio

June 9th, 2010 No comments

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

Первые две статьи данной серии содержали подробное описание двух стилей API, предлагаемых IBM pureQuery: на основе встроенных методов и на основе аннотированных методов. В третьей статье мы рассмотрим разнообразные практические приемы разработки с использованием API pureQuery. В большинстве этих приемов применяются сложные функции API pureQuery. По возможности, для иллюстрации использования описываемых функций приводятся примеры из реальной жизни. Фрагменты кода включены исключительно в демонстрационных целях, но должны дать вам представление о том, как использовать API.

Источник IBM developerWorks Россия