Преобразуем XML в JSON с помощью XStream

Иногда возникает задача преобразовать существующий XML-документ в эквивалентное ему JSON-представление. Например, такая задача может возникнуть, если вы разрабатываете AJAX-интерфейс к существующей системе, которая генерирует XML. Дело в том, что из JavaScript гораздо проще оперировать объектами, представленными в формате JSON, нежели XML, просто потому что первый формат - нативный.

Так вот, быстро преобразовать XML в JSON можно с помощью замечательной библиотеки XStream, подробное введение в которую опубликовано в статье xstream - сериализуем Java-класс в XML. В состав данной библиотеки входит драйвер JettisonMappedXmlDriver, отвечающий за быстрое преобразование XML -> JSON. Порядок преобразования следующий:

Когда система тормозит...

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

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

ECF: Взаимодействуем с Twitter с помощью REST API и XStream

Продолжаем беседу об Eclipse Communication Framework. Сегодня мы рассмотрим, как использовать появившийся в версии 3.1 REST API на примере взаимодействия с наиболее популярным сервисом микроблогов - с Twitter.

Поддержка REST была добавлена в ECF этой осенью горячим немецким парнем по имени Holger Staudacher в рамках Google Summer of Code (который я, кстати, считаю гораздо более полезным, нежели Imagine Cup от небезызвестной корпорации). Реализация данной функциональности представленна контейнером ecf.rest.client и базируется на Remote services API.

ECF: Пишем Jabber-бота с использованием Habra API

Сегодня Суровый челябинский программист хочет поделиться исключительно Just for fun'ом, а именно - рассказом о том, как легко и непринужденно написать Jabber-бота с использованием Bot Framework. Наш бот будет принимать команды вида ~karma %username% и воозвращать соответствующую информацию о хабражителе с указанным именем. Для получения данной информации используется Habra API.

Сначала поговорим о содержательной части задачи. Habra API предоставляет возможность получать с помощью GET-запросов по определенному урлу (заданному в формате http://habrahabr.ru/api/profile/%username%) XML-документ с информацией о пользователе или об ошибке, если, например, такой пользователь не зарегистрирован в системе. Понятно, что хотелось бы большего, в частности - получать информацию о месторасположении пользователя или его интересах, а также иметь возможность вытягивать посты целиком или даже публиковать информацию через API. Надеюсь, что хотя бы часть из этого хаброавторы сделают, пока же мы имеем то, что имеем.

Теперь, что касается Bot framework. Данный фреймворк представлен бандлом org.eclipse.ecf.presence.bot и позволяет писать ботов, работающих с поддерживаемыми ECF Messenger-ами (например, Jabber, Skype, Yahoo) и т.н. ChatRoom-ботов, т.е. роботов для IRC-каналов и/или Jabber-конференций. Включает в себя четыре точки расширения, позволяющие регистрировать роботов и обработчики команд. Рассмотрим их подробнее:

Небольшое введение в механизм точек расширения Eclipse

Здравствуйте, уважаемые читатели. Суровый челябинский программист вернулся из земли Египетской, акклиматизировался и готов порадовать вас новой статьей (хотя, конечно, переход от +28 к - 20 это жестоко).

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

Суть заключается в следующем: в корне плагина находится файл plugin.xml, в котором содержатся объявления точек расширения (тег extension-point) - элементов описывающих те места системы, которые можно расширять. В платформе Eclipse RCP определены точки расширения для регистрации своих адаптеров, видов, перспектив, пунктов меню, кнопочек на панели быстрого запуска и т.д. и т.п.

Точка расширения характеризуется уникальным идентификатором (атрибут id, который обычно задают, придерживаясь доменной модели, как и java-пакеты; именем (атрибут name), служащим больше для удобства программиста, и схемой (атрибут scheme) - путем к exsd-файлу, который содержит XScheme, описывающую формат расширения.

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

ECF: Распределенная обработка событий

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

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

Вся обработка событий в OSGi базируется на интерфейсе EventAdmin. ECF предлагает свою реализацию этого интерфейса - класс DistributedEventAdmin, который расположен в бандле org.eclipse.ecf.remoteservice.eventadmin. К сожалению, данный бандл не входит в поставку ECF 3.0/3.1, поэтому его придется взять на CVS-сервере: pserver://dev.eclipse.org//cvsroot/rt в каталоге org.eclipse.ecf/server-side/bundles/org.eclipse.ecf.remoteservice.eventadmin.

Работает этот механизм так: DistributedEventAdmin представляет собой SharedObject. Как мы уже говорили, такие объекты копируются между ECF-контейнерами и могут обмениваться сообщениями. Соответственно, все вызовы sendEvent и postEvent - это отправка сообщений между репликами объекта DistributedEventAdmin (синхронная и асинхронная, соответственно).

ECF: Средства для взаимодействия команды разработчиков с помощью Eclipse

Мы уже успели поговорить и о том, что такое Eclipse Communication Framework, и о том, как программировать с его помощью. Сегодня рассмотрим графические средства, которые ECF предоставляет для Eclipse (и, соответственно, RCP-приложений).

Под графическими средствами подразумевается перспектива Communications и виды, которые представлены в группах Communications и File Transfer. Прежде всего эти компоненты GUI обеспечивают возможность взаимодействия разработчиков, использующих Eclipse между собой в команде. Однако, обо всем по-порядку.