Обзор RFID-решения WebSphere

IBM RFID-решение WebSphere обеспечивает инфраструктуру для обработки RFID-событий. Оно включает компоненты, которые взаимодействуют с RFID-устройствами, такими как считыватели и принтеры, управляют устройствами ввода/вывода (I/O), фильтруют и обрабатывают RFID-события и передают и принимают данные с серверных систем. RFID-решение WebSphere содержит два компонента: IBM WebSphere RFID Premises Server Version 1.1.0.1 и WebSphere RFID Device Infrastructure Version 1.1.1 (см. рисунок 1).

WebSphere RFID Device Infrastructure (здесь и далее называемая Device Infrastructure) предоставляет компоненты, взаимодействующие и управляющие аппаратными RFID-устройствами. Все вместе компоненты Device Infrastructure часто называют Edge, поскольку они развертываются вблизи от RFID-устройств на границе (edge) сети. Эти компоненты получают теги из RFID-считывателей, создают и предоставляют задания на вывод информации RFID-принтерам и управляют устройствами ввода/вывода (I/O), например световой сигнализацией (light trees). Кроме взаимодействия с RFID-устройствами компоненты инфраструктуры RFID Device фильтруют и объединяют RFID-события, такие как чтение тегов, и направляют эти события на WebSphere Premises Server (здесь и далее называемый Premises Server).

Premises Server принимает RFID-события из одного или нескольких устройств Device Infrastructure Edge, затем объединяет и обрабатывает события и делает их доступными для серверных приложений. Он обеспечивает точку интеграции для доступа и работы с RFID-событиями приложениям, умеющим работать с RFID-событиями. Например, приложение может обработать событие чтения тега сервером Premises Server и, основываясь на содержащемся в событии ID тега, определяет, приписан ли продукту ожидаемый RFID-тег. Затем оно может выполнить API на Premises Server для приема событий чтения, что могло бы указать соответствующему Edge-устройству переключить световую сигнализацию с желтого цвета на зеленый.

Premises Server - это J2EE-решение (Java™2 Extended Edition), выполняющееся на WebSphere Application Server. Он содержит компонент Service Management Framework (SMF), мост (bridge), который работает как промежуточное звено между J2EE-приложениями и Device Infrastructure Edges. Взаимодействие с Edge производится через мост на Premises Server (предоставляемый компонентом Premises SMF) и мост на Edge. Мост на Premises Server преобразует сообщения между форматом сообщений Edge и JMS-форматом Premises Server. Преобразованные сообщения, принимаемые из Edges, помещаются в очередь сообщений MQ и передаются в J2EE-приложения Premises Server для обработки. JMS-сообщения, предназначенные для Edge, принимаются из J2EE-приложений Premises Server через MQ-очередь, преобразуются мостом, и передаются в соответствующий Edge-мост для распределения Edge-компонентам для обработки.

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

• Стартовый набор Dock Door Receiving предоставляет функции, необходимые для получения и обработки элементов с присоединенными RFID-тегами. К таким функциями относятся: взаимодействие с RFID-считывателем для получения событий чтения тега, фильтрация и объединение событий чтения, проверка событий чтения и предоставление визуальных и аудио-индикаторов, сигнализирующих о получении или отклонении событий чтения.
• Стартовый набор Print, Verify, and Ship предоставляет функции, необходимые для распечатки RFID-меток, объединения элементов в контейнеры, проверки того, что готовые к отправке контейнеры содержат надлежащие элементы, и для генерирования отчетов по отправке.

Более подробная информация по RFID-решению Websphere приведена в Websphere RFID Information Center и в обзоре продукта Websphere RFID Premises Server (см. раздел "Ресурсы").

В начало

Более подробно о RFID Device Infrastructure

RFID Device Infrastructure предоставляет как исполняющую систему, так и среду разработки. Исполняющая система содержит несколько адаптеров устройств, созданных фирмой IBM и поддерживающих считыватели и устройства вывода ведущих поставщиков RFID-оборудования (см. рисунок 2). Эти адаптеры обеспечивают необходимые функции для взаимодействия с аппаратными устройствами и выполнения команд. У каждого адаптера есть соответствующий агент, содержащий логику, специфичную для сценариев использования RFID-решения WebSphere. Исполняющая система содержит несколько других агентов, выполняющих различные функции, необходимые для сценариев использования RFID-решения WebSphere. Эти функции варьируются от фильтрации и объединения событий чтения тегов до управления устройствами ввода/вывода, такими как световая сигнализация и датчики движения.

Исполняющая система Device Infrastructure содержит механизм публикации и подписки, называемый MicroBroker. Агенты взаимодействуют друг с другом посредством сообщений, проходящих через MicroBroker. Сообщение публикуется в конкретную тему. Агент подписывается на темы и публикует сообщения в них согласно их функциональности. Например, агент считывателя мог бы опубликовать сообщение, указывающее на то, что произошло событие чтения тега, в тему device/reader/L1/signal/tags. Агент, ответственный за фильтрацию событий чтения тегов, мог бы подписаться на эту тему, отфильтровать повторяющиеся события чтения тегов и опубликовать другое сообщение для каждого события чтения уникального тега еще в одну тему, например, receiving/portal/L1/signal/tags.

MicroBroker имеет компонент - мост (bridge), который позволяет сообщениям передаваться от одного MicroBroker другому по протоколу MQtt. Этот мост представляет собой механизм, используемый для передачи сообщений между Edge и Premises Server. Как упоминалось ранее, компонент Premises Server SMF содержит мост MicroBroker. Мосты Premises Server и Edge настраиваются сообщениями, которые могут передаваться и приниматься ими. Мост Premises Server настраивается дополнительными параметрами, указывающими ему вызывать функции, преобразующие получаемые сообщения из Edge-формата (тема/значение) в XML-формат и помещающие сообщения в очередь JMS-сообщений.

Компоненты Device Infrastructure реализуются на Java и выполняются в IBM Service Management Framework (SMF). SMF - это реализация спецификации Open Services Gateway Initiative (OSGi) 3.0.

WebSphere RFID Device Infrastructure не продается фирмой IBM напрямую, а доступна избранным партнерам для встраивания в RFID-устройства, такие как считыватели и контроллеры. Когда пользователи реализуют RFID-решение WebSphere, они получают Device Infrastructure вместе с покупкой устройства, поддерживающего Device Infrastructure.

Инструментальные средства Device Infrastructure

Device Infrastructure включает в себя среду разработки, называемую RFID Tracking Kit. Она устанавливается как функциональность в WebSphere Studio Device Developer (здесь и далее - Device Developer) и содержит дополнительные подключаемые модули и компоненты для обеспечения возможности разработки адаптеров устройств и агентов, которые можно подключить к RFID-решению WebSphere. В Tracking Kit включены:

• Подключаемый модуль SMF, предоставляющий SMF-инструменты и среду времени исполнения, позволяющие разрабатывать, устанавливать, запускать, тестировать и отлаживать SMF-приложения, называемые комплектами (bundles), в Device Developer.
• Подключаемый модуль OSGi Application Framework (OAF), который предоставляет инструментальные средства и классы, инкапсулирующие OSGi-функции, и облегчает разработку OSGi-приложений.
• Подключаемый модуль Device Kit, предоставляющий инструментальные средства и классы, позволяющие создавать собственные адаптеры к аппаратным устройствам.
• Подключаемый модуль MicroBroker, предоставляющий механизм MicroBroker.
• Подключаемый модуль MicroBroker Application Framework (MBAF), который предоставляет классы, инкапсулирующие многие функции MicroBroker, и облегчает разработку MicroBroker-приложений.
• Java-проекты, включая исходный код, для всех агентов Device Infrastructure, которые можно загрузить в Device Developer и использовать для расширения функциональности поведения агента или в качестве моделей для новых агентов.
• Исходный код для всех адаптеров Device Infrastructure, которые можно использовать для расширения функциональности поведения адаптеров или в качестве моделей для создания новых адаптеров.
• WebSphere Everyplace Custom Environment (здесь и далее - Everyplace Custom Environment) - специализированные Java-конфигурации.
• Вспомогательный подключаемый модуль RFID Tracking Kit, интегрированный со справочной системой Device Developer, для каждого компонента Tracking Kit.

RFID Tracking Kit предоставляет все компоненты, включенные в исполняющую систему RFID Device Infrastructure, позволяя запускать и отлаживать компоненты Device Infrastructure Edge в Device Developer.

Процесс установки RFID Tracking Kit в Device Developer описан в WebSphere RFID Information Center (см. раздел "Ресурсы"). Инструкции рекомендуют использовать CD-ROM для установки Tracking Kit; если у вас нет Tracking Kit на CD-ROM, вы можете установить его с сайта обновлений Device Infrastructure (см. раздел "Ресурсы"), используя Device Developer Update Manager.

Компоненты Implementing Device Infrastructure для устройства

Чтобы использовать новое RFID-устройство (например, считыватель тегов) с IBM RFID-решениями Websphere, нужно создать новый агент Device Infrastructure и адаптер для этого устройства. В данной серии статей рассказывается, как это сделать для RFID-считывателя тегов Sirit™ INfinity 510.

Общая последовательность такова:

1. Создать адаптер устройства, используя Device Infrastructure Device Kit. Вы должны реализовать транспортный компонент Device Kit и компонент устройства для вашего аппаратного устройства.
2. Создать агента устройства, реализующего сценарий использования, в котором участвует ваше аппаратное устройство (Dock Door Receiving или Print, Verify, and Ship).

В начало

Обзор Device Developer Kit

Как упоминалось ранее, Device Kit - это компонент Device Infrastructure. Он устанавливается как подключаемый модуль при установке RFID Tracking Kit в Device Developer. Device Kit используется для создания адаптеров, взаимодействующих с RFID-устройствами, такими как считыватели и устройства вывода, а также аппаратурой, не поддерживающей RFID, например, GPS-устройства или аудио-компоненты на автомобильной мультимедийной шине (automobile entertainment bus). Создание адаптера - это первый шаг при интегрировании нового аппаратного устройства в RFID-решение Websphere.

Адаптер Device Kit можно разделить на три компонента или уровня: уровень соединения, транспортный уровень и уровень устройства (см. рисунок 3).

Уровень соединения

Уровень соединения, как следует из названия, обеспечивает подключение к аппаратному устройству. Кроме установки канала взаимодействия с аппаратным устройством, уровень соединения передает данные (записывает байты) и принимает данные (читает байты) из устройства. Device Kit содержит несколько типов соединений; самыми интересными для аппаратных RFID-устройств являются:

• TcpipConnection для клиентских соединений по TCP/IP
• SerialConnection для соединений по последовательному порту (RS232)

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

Транспортный уровень

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

Кроме управления сообщениями транспортный уровень инициирует соединение с аппаратным устройством, используя соответствующий класс connection, и управляет всем обменом данными инициализации, необходимой для устройства. Например, аппаратное устройство после установки соединения может передать запрос на ввод данных для входа в систему. В этой ситуации транспортный уровень интерпретирует принятые байты как запрос на вход в систему и отвечает соответствующим набором байтов (обычно это ID пользователя и пароль) для входа в устройство. Транспортный уровень также ответственен за передачу тактовых (heartbeat) сообщений, поддерживающих соединение с аппаратным устройством в активном состоянии.

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

При интегрировании нового аппаратного устройства в Device Infrastructure вы должны написать Java-код, реализующий транспортный уровень, специфичный для данного устройства. Реализация транспортного уровня часто является самой трудоемкой задачей.

Уровень устройства

Уровень устройства моделирует протокол аппаратного устройства, используя объекты, называемые командами (commands), измерениями (measurement) и сигналами (signals). Команды, измерения и сигналы называются элементами управления (controls). Как вы, наверное, догадались, команды используются для моделирования команд аппаратного устройства. Сигналы используются для моделирования сообщений, принимаемых из аппаратного устройства. Сообщения обычно принимаются в результате выполнения команд, но могут быть также и асинхронными. Измерения используются для моделирования свойств или атрибутов аппаратного устройства.

При интегрировании нового аппаратного устройства в Device Infrastructure уровень устройства моделируется с использованием Control Markup Language (см. CML), а затем генерируется код, реализующий элементы управления; никакого Java-кода писать не нужно.

Элементы управления устройством: Команды

Команда обеспечивает механизм передачи приложением запросов аппаратному устройству для выполнения операций. Например:

• Команда для получения версии программного обеспечения
• Команда для установки рабочего режима считывателя
• Команда для получения тегов, прочитанных считывателем
• Команда для установки коэффициента затухания антенны

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

Элементы управления устройством: Сигналы

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

Давайте рассмотрим событие Sirit INfinity 510 event.tag.report для иллюстрации работы сигнала. Представление этого события в формате ASCII-текста таково:

event.tag.report tag_id=0x3000214160C0040000A5937, antenna=1\r\n\r\n

Эта строка передается из считывателя каждый раз при захвате тега считывателем, если он настроен на автономный режим или режим опроса. Уровень устройства определяет сигнал для данного события. Сигнал содержит определение сообщения, которое отображает первую часть строки события - event.tag.report. Отображается только первая часть строки события, потому что значение tag_id (и, возможно, значение antenna) будет меняться для каждого захваченного тега. Транспортный уровень принимает (из уровня соединения) байты для события event.tag.report, переданные из считывателя, преобразует их в сообщение и доставляет на уровень устройства. На уровне устройства проверяется, совпадает ли сообщение с какими-либо заданными сигналами. Сообщение, принятое транспортным уровнем, содержит строку event.tag.report, и сигнал содержит сообщение со строкой event.tag.report, поэтому имеется совпадение. Сигнал активизируется, и уведомляются все зарегистрированные прослушиватели этого сигнала. Если приложение зарегистрировало себя как заинтересованное в этом сигнале, оно уведомляется об этом и ему передаются данные, содержащиеся в event.tag.report.

Элементы управления устройством: Измерения

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

Взаимодействия приложения, адаптера и аппаратного устройства

На рисунке 4 показана общая схема взаимодействий между агентом (приложением), адаптером Device Kit и аппаратным устройством, возникающих при использовании агентом команды для выполнения функции в аппаратном устройстве. В данном примере возникают следующие взаимодействия:

1. Агент получает команду из уровня устройства.
2. Агент получает сигнал, отображенный в ответ команды, из уровня устройства.
3. Агент добавляет себя в список прослушивателей сигнала.
4. Агент указывает команде выполниться.
5. Команда записывает сообщение в транспортный уровень.
6. Транспортный уровень преобразует сообщение в формат, ожидаемый считывателем, и записывает преобразованное сообщение в уровень соединения.
7. Уровень соединения передает байты в считыватель.
8. Уровень соединения читает ответные байты из считывателя.
9. Транспортный уровень принимает ответ из уровня соединения и преобразует его в сообщение.
10. Транспортный уровень уведомляет уровень устройства о том, что сообщение получено.
11. Сообщение соответствует сообщению, определенному для сигнала, и все прослушиватели сигнала уведомляются. В данном примере прослушиватель является агентом.

Control Markup Language (CML)

CML - это компонент Device Kit, используемый для моделирования набора команд аппаратного устройства. Это совместимый с XML 1.0 язык разметки, определяющий элементы управления, сообщения и параметры конфигурации, требующиеся адаптеру устройства и агенту для взаимодействия с аппаратным устройством и управления им. Имеется CML-файл для транспортного уровня и еще один для уровня устройства. На транспортном уровне CML-файл используется для определения сообщений (запросов и ответов), необходимых для инициализации, и тактовых сообщений. На уровне устройств CML-файл используется для определения всех элементов управления (команд, сигналов и измерений), которые должны быть доступны приложению для выполнения определенной задачи, например, тех команд RFID-считывателя, которые нужно определить для указания ему операций начала и остановки чтения и получения отчетов о считанном теге.

Инструментальные средства Device Kit используют содержимое CML-файлов для генерирования Java-кода обоих уровней - транспортного и уровня устройства. Для уровня устройства весь необходимый Java-код генерируется из CML-файла. В результате этого при создании адаптера Device Kit вся работа с уровнем устройства выполняется с использованием CML. Для транспортного уровня CML-файл используется при генерировании Java-определений сообщений, необходимых для инициализации обмена и для тактовых сообщений, а также при определении различных параметров транспортного уровня.

Мы рассмотрим некоторые специфические примеры для лучшего понимания использования CML при моделировании набора команд аппаратного устройства. В частности, мы рассмотрим CML-определения, необходимые для создания элементов управления, моделирующих команду Sirit INfinity 510 version.sw (версия программного обеспечения). Информация, приведенная на рисунках 5 и 6, взята из "Справочного руководства по протоколу INfinity 510".

Элемент <command> определяет команду. Определение команды включает в себя определение сообщения, указывающее байты, передаваемые в аппаратное устройство для выполнения команды. В листинге 1 приведен CML-файл, необходимый для моделирования команды INfinity 510 version.sw. Взглянув на определение сообщения, вы заметите, что оно содержит строку version.sw\r\n. Сообщение определяет команду и символ завершения команды (command terminator).

                
<command id="VersionSwGetRequest">
    <message id="VersionSwGetRequestMessage">
        <ascii>version.sw\r\n</ascii>
    </message>
</command>

Элемент <signal> определяет сигнал. Определение сигнала включает в себя определение шаблонного сообщения, указывающего байты, передаваемые аппаратным устройством и активизирующие сигнал. В листинге 2 приведен CML-файл, необходимый для моделирования ответа INfinity 510 на команду version.sw. Ответ из считывателя для данной команды равен ok 0.2.171\r\n\r\n. ok - это ответ команды, 0.2.171 - это версия программного обеспечения, а "\r\n\r\n" - это символы завершения ответа (response terminator). Взглянув на определение сообщения, вы заметите, что оно содержит ответ команды и символы завершения, но не содержит версии программного обеспечения. Причина заключается в том, что версия программы может отличаться у разных считывателей. Мы хотим определить сигнал, который может активизироваться при любом ответе считывателя на команду version.sw, а не только при ответе для версии 0.2.171. При работы с такими ситуациями CML позволяет определять параметры и фильтры. Параметр представляет собой заполнитель, чье значение извлекается из входящего сообщения. В данном примере параметр используется для извлечения из входящего сообщения версии программного обеспечения. Фильтр указывает битовую маску, используемую для сравнения сообщений. В данном примере фильтр гарантирует, что входящее сообщение от аппаратного устройства (содержащее версию программного обеспечения) будет соответствовать шаблонному сообщению сигнала (без версии программного обеспечения), в результате чего будет активизироваться сигнал. Элемент <sentmessage> гарантирует, что соответствие будет успешным только тогда, когда входящее сообщение будет ответом на запрос version.sw, переданный в аппаратное устройство (а не ответом на какой-то другой запрос).

                
<signal id="VersionSwReport">
    <message id="VersionSwReportMessage">
        <ascii>ok \r\n\r\n</ascii>
        <parameter type="string">
            <index>3</index>
        </parameter>
        <filter>
            <bytes format="hex">ff,ff,ff</bytes>
        </filter>
        <sentmessage idref="VersionSwGetRequestMessage"/>
    </message>
</signal>

Элемент <measurement> определяет измерение. Как упоминалось ранее, измерения реализуются с использованием команд и сигналов. Как результат этого, определение измерения должно ссылаться на определения команды, которые моделируют операции чтения и записи свойства, а также на определение сигнала, моделирующее ответ аппаратного устройства на команду чтения. В листинге 3 приведен CML-файл, необходимый для моделирования свойства version.sw как неизменяемого измерения. Изменяемые измерения включают элемент <writecommand>.

                
<measurement id="VersionSw">
    <readcommand idref="VersionSwGetRequest"/>
    <signal idref="VersionSwReport"/>
</measurement>

Подробнее о моделирующих сообщениях в CML

Как вы уже видели, при моделировании команд и сигналов используются сообщения. Сообщения - это основные модули системы моделирования Device Kit; они являются интерфейсом между аппаратным устройством и Device Kit. Моделирующие сообщения являются ключевыми для разработки адаптеров устройств и агентов Device Infrastructure. Мы приведем краткий обзор моделирующих сообщений. Более подробная информация приведена в справочной документации по Device Developer Device Kit и примерах, поставляемых с RFID Tracking Kit.

Существует два основных типа сообщений: точные (concrete) и шаблонные (template). Точные сообщения представляют собой реальные байты, передаваемые или принимаемые из аппаратного устройства. Шаблонные сообщения - это шаблоны, используемые для создания точных сообщений (кодирование), извлечения данных из точных сообщений (декодирование) или поиска соответствия с точными сообщениями. Точные сообщения могут задаваться в CML-файлах и генерироваться (или приниматься) на транспортном уровне. Шаблонные сообщения всегда моделируются в CML-файлах.

Мы уже видели одно точное сообщение - запрос Sirit INfinity version.sw. При моделировании точных сообщений в CML вы должны включить все байты сообщения. Для команды VersionSwGetRequest (см. листинг 1) сообщение содержит символы \r\n, необходимые для завершения команды согласно протоколу считывателя Sirit INfinity 510.

Шаблонные сообщения являются более сложными - они содержат параметры или фильтры. Мы видели одно шаблонное сообщение - сообщение, использованное для активизации сигнала VersionSwReport (см. листинг 2). В этом случае сообщение содержит параметр (представляющий версию программного обеспечения), фильтр (для определения факта соответствия данного точного сообщения шаблонному и необходимости активизировать сигнал) и переданное сообщение для гарантии активизации сигнала только для сообщений, являющихся ответом на запрос version.sw.

Одним из применений шаблонных сообщений является кодирование или создание точного сообщения с использованием параметризованных данных. Кодирование выполняется за кулисами процесса тогда, когда приложение выполняет команду с параметром. В листинге 4 приведен CML-файл, используемый для моделирования запроса setup.operating_mode для считывателя Sirit INfinity 510. Запрос используется для запуска (или остановки) операции чтения тегов. Корректными значениями, следующими за знаком = в сообщении, являются standby, polled и autonomous (различные режимы считывателя).

                
<command id="SetupOperatingModeSetRequest">
  <message id="SetupOperatingModeSetRequestMessage">
    <ascii>setup.operating_mode = \r\n</ascii>
    <parameter type="string">
        <insert/>
        <index>23</index>
    </parameter>
    <filter>
        <bytes format="hex">
          ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,
          ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff
        </bytes>
    </filter>
  </message>
</command>

Шаблонное сообщение можно использовать для создания точного сообщения, предоставляя значение для параметра. Байты данных будут вставляться, начиная с индекса 23 (начиная с 0) точного сообщения. Элемент <insert/> указывает на вставку байтов, а не на замещение байтов из шаблонного сообщения (в этом случае должен был бы указываться элемент <length> или <size>). Если, например, приложение выполняет Java-код commandControl.execute("autonomous"), в считыватель передается точное сообщение setup.opertaing_mode = autonomous.

Параметры могут быть одним из нескольких типов (см. справочную систему Device Developer Device Kit для получения более подробной информации). Обычными типами являются string, int, byte и nstring (строка, используемая приложением как числовое значение). Для числовых типов значение данных, используемое для кодирования, должно быть соответствующим Java-типом (Integer, Byte и т.д.). Если для сообщения определяется более одного параметра, нужно использовать в качестве данных Object[]. Существует много CML-элементов, доступных для параметров моделирования: битовое или байтовое смещения и длина, преобразования типов данных, трансформация и т.д.

Шаблонные сообщения можно также использовать для декодирования или извлечения данных из точных сообщений. Декодирование выполняется при любой активизации сигнала; соответствующие данные извлекаются из точного сообщения и делаются доступными для всех прослушивателей сигнала. Сообщение, определенное в листинге 2, можно использовать для извлечения номера версии программного обеспечения из ответа на запрос version.sw. В этом случае параметр начинается с индекса 3 и продолжается до конца фрагмента данных точного сообщения. Определение фрагмента данных сообщения реализуется классом, экземпляром которого является точное сообщение; в данном случае фрагментом данных является все до символов \r\n\r\n (не включая их) в конце сообщения. Если бы для параметра был определен элемент <length> или <size>, данные имели бы указанный размер (вместо "оставшихся данных"). Если для сообщения определено более одного параметра, возвращается экземпляр Object[]. Есть также способ возвратить List или Map (см. документацию по Device Kit).

Третьим применением шаблонных сообщений является сопоставление для проверки соответствия точному сообщению. Сопоставление выполняется при попытке определить, должно ли точное сообщение активизировать сигнал. В листинге 2 определено сообщение с фильтром, использующимся для определения необходимости активизации сигнала. Фильтр указывает, что если первые три байта ("ok ") шаблона и точного сообщения одинаковы, точное сообщение совпадает с шаблоном. Фильтры являются битовыми масками и могут соответствовать частям байта, либо биты могут исключаться из участия в процедуре сопоставления путем установки битов фильтра в 0. Например, фильтр ff,00,ff использовал бы первый и третий байты для сопоставления.

Некоторые шаблонные сообщения могут указывать передаваемое сообщение, используемое во время сопоставления. В таких случаях совпадение успешно только тогда, когда фильтр возвратил положительный ответ, и сообщение template-sent совпадает с сообщением concrete-sent, соответствующим точному сообщению. Например, в листинге 2, для того чтобы сопоставление было успешным, не только три первых байта должны совпадать с "ok ", но и точное сообщение, вызвавшее ответ, должно совпадать с VersionSwGetRequestMessage, определенным в листинге 1.

При генерировании Java-кода инструментальными программами Device Kit из CML любое сообщение, содержащее элементы <parameter>, <filter> или <sentmessage>, создается как шаблонное; все остальные являются точными сообщениями.

В начало

Использование инструментальных средств Device Kit

В Device Kit есть мастер генерирования артефактов Device Kit. В начале работы над проектом адаптера Device Kit используются мастера для генерирования начальных файлов проекта Device Developer и скелетного Java-кода для транспортного уровня и уровня устройства. После создания начального проекта могут быть использованы мастера повторного генерирования Java-кода для транспортного уровня или уровня устройств, чтобы ввести определения сообщения и элементов управления, добавленные в файлы.

При создании нового адаптера устройства вы будете использовать следующую процедуру:

1. Разберитесь с протоколом аппаратного устройства. Попробуйте передавать команды на устройство и убедитесь в точности информации, имеющейся в справочнике по протоколу работы с устройством.
2. Создайте проекты транспортного уровня и уровня устройств в Device Developer.
3. Разработайте первую версию транспортного уровня, которая может выполнять основное взаимодействие с аппаратным устройством. Это означает способность формировать сообщения из входящих байтов и передавать запросы в аппаратное устройство.
4. Смоделируйте некоторые из простейших элементов управления устройства (команды, сигналы и измерения). Проверьте правильность совместной работы уровня устройства и транспортного уровня.
5. Добавьте дополнительную обработку в транспортный уровень, например, тактовые сообщения, обработку асинхронных событий, систему защиты, начальную установку соединения и др.
6. Смоделируйте дополнительные элементы управления устройства, необходимые для поддержки агента устройства.
7. Повторяйте реализацию агента устройства, моделирование элементов управления устройства, необходимые для поддержки агента, и реализацию необходимых функциональных возможностей транспортного уровня.

Далее мы рассмотрим первоначальные шаги по созданию проектов транспортного уровня и уровня устройства в Device Devloper с использованием инструментальных средств Device Kit. Остальные шаги будут рассмотрены в следующих статьях данной серии.

Создание проекта транспортного уровня

Используйте мастер Transport Creation (см. рисунок 7) для создания начального Java-проекта, классов и CML-файла транспортного уровня. Откройте мастер в Device Developer, выбрав File => New => Other и Device Kit => Transport.

На рисунке 8 показан проект SimpleTransport, сгенерированный мастером транспортного уровня. Проект содержит Java-классы SimpleTransport (см. рисунок 9) и SimpleTransportService, а также CML-файл SimpleTransport.cml.

Сгенерированный транспортный класс, SimpleTransport, содержит реализации методов по умолчанию для получения байтов и передачи сообщений в аппаратное устройство:

protected int processInput(final byte[] bytes, final int length) throws Exception {
    return super.processInput(bytes, length);
}

protected void write(final MessageService message) throws Exception {
    super.write(message);
}

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

Создание Java-проекта уровня устройства, классов и CML

Используйте мастер Device Creation (см. рисунок 10) для создания начального Java-проекта, классов и CML-файла уровня устройства. Откройте мастер в Device Developer, выбрав File => New => Other, а затем Device Kit => Device.

При генерировании уровня устройства у вас есть вариант указать сервис транспортного уровня и классы реализации, как показано ниже. В данном примере сервисом и классами реализации являются SimpleTransportService и SimpleTransport (см. выше).

На рисунке 11 показан проект SimpleDevice, сгенерированный мастером. Проект содержит Java-классы SimpleDevice и SimpleDeviceService, а также CML-файл SimpleDevice.cml.

Как и в классах, сгенерированных в проекте SimpleTransport, после начального генерирования Java-классы SimpleDevice содержат не так много функциональности. Однако, в отличие от проекта транспортного уровня, вся работа, необходимая для создания рабочего уровня устройства, выполняется в CML-файле. XML-код, показанный в листинге 5, получается из начального файла SimpleDevice.cml, сгенерированного при создании проекта. Добавив к этому файлу CML-примеры, рассмотренные ранее, и повторно сгенерировав классы устройства из CML, вы можете создать уровень устройства с необходимой функциональностью, реализуя в приложении возможность работы с командой INfinity 510 version.sw.

                
<?xml version="1.0"?>
<!--Лицензированные материалы - Собственность Моей Компании -->
<!--(C) Copyright Моя Компания Корп. 2006 Все права защищены -->
<!--US Government Users Restricted Rights - Использование, копирование или разглашение-->
<!--ограничено согласно контракту GSA ADP Schedule с Моей Компанией Корп.-->
<cml packagebase="com.mycompany" format="hex">
  <version>3.3.0</version>
  <vendor>My Company</vendor>
  <device id="SimpleDevice"
         bundle="SimpleDevice"
         implementation="SimpleDevice">
  <description>Simple Device</description>

     <!-- Ниже приведены примеры команды, сигнала и измерения, рассмотренные ранее. -->

<command id="VersionSwGetRequest">
  <message id="VersionSwGetRequestMessage">
     <ascii>version.sw\r\n</ascii>
  </message>
</command>

<signal id="VersionSwReport">
  <message id="VersionSwReportMessage">
    <ascii>ok \r\n\r\n</ascii>
    <parameter type="string">
      <insert/>
      <index>3</index>
    </parameter>
    <filter>
      <bytes format="hex">ff,ff,ff</bytes>
    </filter>
    <sentmessage idref="VersionSwGetRequestMessage"/>
  </message>
</signal>

<measurement id="VersionSw">
  <readcommand idref="VersionSwGetRequest"/>
  <signal idref="VersionSwReport"/>
</measurement>


     <!-- Конец вставленных примеров элементов управления. -->

    <transportservice service=
      "com.mycompany.simple.transport.service.SimpleTransportService"
      implementation="com.mycompany.simple.transport.SimpleTransport"/>
    <bundle/>
  </device>
</cml>

Сгенерируйте повторно проект SimpleDevice, используя инструментальные средства Device Kit, чтобы добавить новый класс SimpleDeviceMessages в проект. Этот класс содержит поля для определения сообщения, параметра и фильтра, добавляемых в CML-файл вместе с методами getter для полей. Класс SimpleDevice тоже обновляется для создания необходимых объектов элементов управления определений команды, сигнала и измерения, добавленных в CML-файл. Эти обновления показаны на рисунках 12 и 13. На данный момент не важно знать, как работает сгенерированный код; просто знайте, что код уровня устройства "подстраивается" или разрабатывается путем моделирования спецификации устройства в CML-файле и использования инструментальных средств для генерирования кода. В третьей статье данной серии мы подробно рассмотрим работу сгенерированного кода.

В начало

Заключение

В данной статье вы узнали о компоненте WebSphere RFID Device Infrastructure RFID-решения WebSphere и о том, как можно создать адаптеры устройств при помощи Device Infrastructure Device Kit. Вы узнали о функциях, предоставляемых различными компонентами адаптера (или уровнями), а также о роли CML в создании адаптера. Также был представлен краткий обзор инструментальных средств Device Kit. Остальные статьи данной серии будут базироваться на этой информации. В них вы узнаете, как создать новый адаптер и агент, которых можно включить в RFID-решение WebSphere.

Ресурсы

Научиться

• Оригинал статьи "Developing a device adapter and agent for the WebSphere RFID solution, Part 1: Introduction to the WebSphere RFID Device Kit".
  
  
• Разработка адаптера устройства и агента для RFID-решений WebSphere, часть 2: Создание транспортного уровня (developerWorks, 2007): Описание функций, предоставляемых компонентом WebSphere RFID Device Infrastructure, а также процесса создания адаптеров устройств при помощи WebSphere RFID Device Infrastructure Device Development Kit.
  
  
• Разработка адаптера устройства и агента для RFID-решений WebSphere, часть 3: Создание компонента устройства (developerWorks, 2007): Узнайте, как создать новый уровень устройства и смоделировать команды, необходимые для чтения RFID-тегов при помощи RFID-считывателя Sirit™ INfinity 510.
  
  
• Разработка адаптера устройства и агента для RFID-решений WebSphere, часть 4: Создание агента считывателя (developerWorks, 2007): Узнайте, как создать нового агента считывателя, чтобы читать RFID-теги при помощи считывателя Sirit™ INfinity 510.
  
  
• Обзор продукта Websphere RFID Premises Server: Краткое описание RFID-решения Websphere.
  
  
• WebSphere RFID Information Center: Документация по Websphere RFID.
  
  
• Справочная система Websphere Studio Device Developer содержит информацию обо всех компонентах RFID TRacking Kit (после инсталляции RFID Tracking Kit).
  
  
• Sirit INfinity 510 Protocol Reference Guide v1.0 вскоре появится на http://www.sirit.com.
  
  
• Печать простых и сложных RFID-меток при помощи WebSphere RFID (developerWorks, ноябрь 2006): Руководство по печати RFID-меток при помощи Websphere RFID.
  
  
• Справочник IBM WebSphere RFID Handbook: A Solution Guide.
  
  
• Раздел developerWorks Wireless на WebSphere.
  
  

Получить продукты и технологии

• Загрузите пробную версию WebSphere Studio Device Developer.
  
  
• Установите RFID Tracking Kit в Device Developer при помощи Update Manager (и создайте закладку для сайта http://www.ibm.com/software/pervasive/wsdd/updates/571/rfid).
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Обзор RFID-решения WebSphere
• Более подробно о RFID Device Infrastructure
• Обзор Device Developer Kit
• Использование инструментальных средств Device Kit
• Заключение
• Ресурсы
• Об авторах
• Комментарии