Erster Blick auf Microsoft BizTalk RFID

This blog-post is based on the English-language post "First look at Microsoft BizTalk RFID" found in the blog of Damir Dobric. There is no new information in the German language version.
Dieser Blog-Post basiert auf dem englischsprachigen Post "First look at Microsoft BizTalk RFID" aus dem Blog von Damir Dobric. Er enthält keine grundsätzlich neue Aussagen oder Informationen gegenüber der englischsprachigen Version.

Microsoft BizTalk RFID ist eine offene Plattform, welche es Herstellern möglich macht, auf Microsoft Technologien basierende RFID Lösungen zu entwickeln. Im Kern ist es ein Satz von APIs, welche auf dem .NET Framework 2.0 aufsetzen, die es erlauben, Anwendungen durch sogenannte Eventhandler zu erstellen. Generell bietet das Microsoft RFID Services Framework einen recht mächtigen Funktionssatz in folgenden Bereichen an:

1. Synchrone Kommunikation mit Endgeräten (devices)
2. Asynchrone Eventverarbeitung
3. Management Funktionalitäten

API und Befehlsmodell (Command Model)

Das synchrone Befehlsmodel ist dadurch gekennzeichnet, dass ein Aufrufer einen Aufruf (Request) über BizTalk RFID Services Framework an ein RFID-Endgerät (device) schickt und solange wartet, bis er eine Antwort durch den RFID service erhält. model is when the caller issues a request to BizTalk RFID Services Framework
and waits until it receives a response from the RFID service. Ein solches Endgerät kann beispielsweise ein RFID Reader (RFID-Lesegerät) oder ein RFID Printer (RFID Drucker) sein. Mit RFID Drucker können Labels, also Etiketten mit RFID-Tag, bedrucken und den RFID-Tag gegebenenfalls mit spezifischen Daten füllen.

Im asynchronen Befehlsmodell schicken RFID Geräte Benachrichtigungen an das BizTalk RFID Services Framework, welches dann dies als Ereignisse (Events) verarbeitet und an passende RFID Prozess-Pipelines weiterleitet. Dies ist das am häufigsten verwendete Muster, welches man in RFID-Anwendungen, die auf dieser Plattform basieren, finden wird.

Das Management Befehlsmodell beinhaltete administrative Ereignisse, z. B. über das Versagen von spezifischen Endgeräten oder über den Ausfall der Stromversorgung der Endgeräte, oder wenn ein Prozess gestoppt wird.

Abbildung von Prozessen Dealing with Processes

Das RFID services Framework ist im Namespace "Microsoft.SensorServices.RFID" implementiert, welches au seiner reihe von managed (.NET 2.0) Assemblies besteht. Das Framework selbst läuft in einem Windows-Service namens BizTalkRfid, der im Prozess RfidServices.exe gehostet wird.

RFID Dienste werden in durch die durch die unten abgebildete RFID Management Konsole verwaltet:

Alle Einstellungen, welche in dieser Konsole getroffen werden können, sind in einer Datenbank gespeichert. Diese Datenbank heißt per Default "RFIDSTORE". Die Management Konsole steuert RFID relevante Geschäftsprozesse. Im oberen Bild sind drei Geschäftsprozesse aufgeführt: ScannenEingang, TestProcess and xasd.

Wenn man mit RFID Diensten zu tun hat, gibt es einige wichtige Entitäten, welche im folgenden erklärt werden:

Device (Endgerät)
Die erste wichtige Entität ist das RFID Device, also das physische Endgerät. Dies kann zum Beispiel ein RFID-Reader sein. Um dieses Gerät zu nutzen, muss ein Provider für das Gerät installiert sein. Dieser RFID Device Provider ist ein gemanagter Treiber und implementiert die gerätespezifische Kommunikation ab. Durch ihn werden Device Management, sowie das Lesen oder Schreiben von Daten in allen drei genannten Befehlsmodellen abgebildet. Die Architektur des Frameworks erlaubt übrigens, auch Provider zu implementieren, welche nicht nur mit RFID Geräten umgehen, sondern mit beliebigen Arten von Sensoren. Die Plattform bietet nach unserer Meinung viel mehr, als nur RFID spezifische Funktionalitäten. Der Namespace der Assembly "Microsoft.SensorServices.RFID" deutet ebenfalls in die Richtung, dass man weiter denkt, als nur RFID-spezifische Funktionalitäten auf dieser Infrastruktur aufzusetzen. Wir experimentierten bereits mit verschiedenen anderen Datenquellen wie Ultraschalldaten, File IO-Ereignissen usw. Wenn man in der Lage ist, einen passenden funktionierenden Provider zu erstellen, gibt es keine technische Limitierung, irgendeine andere Art von "Sensorik" in das Framework einzubinden. Es gibt noch eine Unterscheidung zwischen logischen und physischen Devices, auf welche hier aber nicht eingegangen wird.

Component (Komponente)
Eine Komponente ist eine .NET Assembly, welches ein spezifisches Interface implementiert und in einer Kette von Eventhandlern installiert wird. Die vom Gerät gelesenen Daten werden asynchron zum ersten Eventhandler geschickt. Nach der Verarbeitung kann der Eventhandler die Daten unverändert oder manipuliert an den nächsten Eventhandler in der Kette weitersenden. Der letzte Eventhandler im Stack ist die sogenannte Eventsenke (Event Sink). BizTalk RFID wird mit einer SQL-Eventsenke ausgeliefert, welche die empfangenen Daten in einer SQL Server Datenbank speichert.

Process (Prozess)
Jeder Businessprozess ist eine logische Entität, welche eine Menge von Geräten (devices) oder Device-Gruppen mit einem Satz von Komponenten verbindet. Nehmen wir zum Beispiel an, dass es zwei Geräte D1 und D2 gibt, welche als Gruppe G1 zusammengefasst sind und nehmen wir an, dass es zwei Komponenten (Eventhandler) EH1 und EH2 gibt. Der erste Handler EH1 könnte verwendet werden, um Dubletten herauszufiltern und der zweite Handler EH2 könnte die SQL-Eventsenke sein, welche einfach Daten in die Datenbank schreibt. Man kann nun einen Prozess P1 definieren, welcher die Device-Gruppe G1 mit den Komponenten (Eventhandlern) EH1 und EH2 verbindet. Zur Veranschaulichung: Der Prozess P1 ist ein Geschäftsprozess welcher Daten von den Readern liest, welche sich hinter den Devices D1 und D2 verbergen, dann zuerst die doppelten, redundanten Tag-Leseereignisse ausfiltert und diese zur späteren Auswertung in eine Datenbank schreibt.

Das ist in Kürze die Kernidee, welche hinter der RFID Services Plattform steckt.

Wir hören oft die Frage: Was hat die Microsoft RFID Services Plattform mit BizTalk Server zu tun?

Die Antwort ist zweigeteilt:
Technisch gesehen derzeit nichts. Aus einer Marketing und Produktsicht kann es aber Sinn machen, dies zusammenzubundeln, was in diesem Post nicht weiter diskutiert wird.
Aber man darf in diesem Kontext nicht vergessen, dass BizTalk RFID auf einem technisch sehr aktuellem Stand ist, während die BizTalk Server Engine und Infrastruktur eine seit mehreren Jahren gewachsene Struktur darstellt. Eine stärkere "technische" Integration hätte entweder erfordert, große Teile des BizTalk Server umzubauen, oder hätte möglicherweise dazu geführt, dass BizTalk RFID nicht konsequent auf einem technisch aktuellem Framework (.NET 2.0) aufsetzen kann. Es gibt, wie wir in späteren Posts sehen werden, Möglichkeiten, die Integration mit dem "Rest" des Produktes BizTalk Server mit relativ geringem Aufwand stattfinden zu lassen.

Wir hoffen, dass dieses Post hilft, die (hier stark vereinfachten) Grundlagen der Microsoft RFID Plattform zu verstehen.