Simulation eines Containerumschlags. Entwicklung von Prozessen, Datenbank und Weboberfläche für das SARFIR-Projekt

Inhaltsverzeichnis

Erklärung

Abstract

Abbildungsverzeichnis

1 Einleitung

2 Grundlagen, Methoden und Werkzeuge
2.1 RFID
2.2 webMethods
2.2.1 Entwicklungsplattform und verwendete Konzepte
2.2.2 webMethods Designer
2.2.3 JavaServerFaces
2.2.4 Portlet Anwendungen innerhalb CAF
2.3 Railware Controller und Controller-Gateway
2.4 SOAundBPM

3 Modell und Prozesse
3.1 Modell des Prototypen
3.2 Prozess zur Anlandung per Schiff
3.3 Prozess zum Verladen von Containern per Kran
3.4 Prozess zur Steuerung von Zug und LKW
3.5 Prozess zur Containerverfolgung

4 SARFIR Datenbank
4.1 Skalierbare Version für Unternehmen
4.1.1 Abbildung von Transportmitteln
4.1.2 Abbildung von Strecken
4.1.3 Abbildung des Terminals
4.1.4 Abbildung von Transportaufträgen
4.2 Minimierte Version
4.2.1 Abbildung der Container und Standorte
4.2.2 Protokollierung und Statusinformationen
4.3 JDBC Adapter
4.3.1 Einrichten einer Datenbankanbindung
4.3.2 Erzeugen von Adapter Services

5 Webinterface zu Steuerung der Anlage
5.1 Grundidee
5.2 Umsetzung
5.2.1 Terminal
5.2.2 Haltepunkt
5.2.3 Kran

6 Fazit

7 Ausblick

Anhang - Übersicht über Services

Adapters

ContainerAndSlots

Communication

Modelcomponents

Literaturverzeichnis

Abstract

Zu einem Modell des Containerumschlags im Hamburger Hafen werden in dieser Arbeit zugehörige Funktionen realisiert. Dieses Modell beinhaltet eine Modelleisenbahn und LKW-Strecke. Über diese und weitere Einrichtungen wird der Containerumschlag über See- und Landweg zu einem Unternehmen simuliert. Hierzu werden Radio Frequency Identification (RFID) und Service Orientierte Architektur (SOA) kombiniert.

Ziel dieser Arbeit ist es die Prozesse für Verladung, Transport und Verfolgung der Container mit Hilfe der webMethods Suite der Software AG zu realisieren. Dazu gehört ebenfalls eine Datenbank, die alle relevanten Informationen des Modells abbildet und mit dem Microsoft SQL Server erstellt wird. Im letzten Teil der Arbeit wird ein Webinterface generiert mit dem die Anlage gesteuert werden kann.

Abbildungsverzeichnis

Abbildung 1: Beziehungen zwischen Integration Server und Anwendungen in einer typischen SOA / Quelle: Eigene Darstellung

Abbildung 2: Hierarchie der Transportmittelsteuerung / Quelle: Eigene Darstellung

Abbildung 3: SOA Übersicht/Quelle: Einführung und Etablierung von SOA, Trivadis AG

Abbildung 4: Prototyp im Modell / Quelle: Darmstadt-Präsentation Foto

Abbildung 5: Modelle die Zug und LKW simulieren / Quelle: Darmstadt-Präs. Foto.

Abbildung 6: Schema des Schiffsprozesses / Quelle: Eigene Darstellung

Abbildung 7: Schema des Verladeprozesses / Quelle: Eigene Darstellung

Abbildung 8: Schema des Zug-Prozesses / Quelle: Eigene Darstellung

Abbildung 9: Schema des LKW-Prozesses / Quelle: Eigene Darstellung

Abbildung 10: Schema des Prozesses zur Containerverfolgung / Quelle: Eigene Darstellung

Abbildung 11: Transportmittel / Quelle: Eigene Darstellung

Abbildung 12: Strecke / Quelle: Eigene Darstellung

Abbildung 13: Terminal / Quelle: Eigene Darstellung

Abbildung 14: Transportaufträge / Quelle: Eigene Darstellung

Abbildung 15: Container und Standorte / Quelle: Eigene Darstellung

Abbildung 16: Ansicht der Tabelle Slots im SQL Management Studio / Quelle: Eigene Darstellung

Abbildung 17: Protokollierung und Statusinformationen / Quelle: Eigene Darstellung

Abbildung 18: High Level Ansicht eines Adapter Services der durch einen JDBC Treiber an die DB angebunden ist / Quelle: webMethods JDBC User's Guide

Abbildung 19: Einrichten einer neuen Datenbankverbindung / Quelle: Eigene Darstellung

Abbildung 20: Fertig konfigurierte Datenbankverbindung / Quelle: Eigene Darstellung

Abbildung 21: Erster Schritt beim Erstellen eines neuen Adapter Services / Quelle: Eigene Darstellung

Abbildung 22: Auswahl derArt der SQL-Abfrage / Quelle: Eigene Darstellung

Abbildung 23: Aufbau und Inhalt der ContainerTabelle / Quelle: Eigene Darstellung

Abbildung 24: Festlegen von Ein- und Ausgabewerten eines Adapter Services / Quelle: Eigene Darstellung

Abbildung 25: Hinzufügen von Tabellen zu einem Adapter Service / Quelle: Eigene Darstellung

Abbildung 26: Abfragespalten eines Adapter Services / Quelle: Eigene Darstellung

Abbildung 27: Where-Bedingungen eines Adapter Services / Quelle: Eigene Darstellung

Abbildung 28: Startpunkt eines neuen CAF Projektes zum Erstellen von Webinter­faces/Quelle: Eigene Darstellung

Abbildung 29: header.view und footer.view wurden im Designer in die default.view integriert / Quelle: Eigene Darstellung

Abbildung 30: Eigenschaften eines Links / Quelle: Eigene Darstellung

Abbildung 31: header.viewin der Implementierungsansicht / Quelle: Eigene Darstellung

Abbildung 32: footer.view in der Implementierungsansicht / Quelle: Eigene Darstellung

Abbildung 33: Startansicht des Webinterfaces / Quelle: Eigene Darstellung

Abbildung 34: CSS-Code um die Schemazeichnung des Terminals einzufügen / Quelle: Eigene Darstellung

Abbildung 35: Schemazeichnung des Terminals mit seinen Containerstellplätzen / Quelle: Eigene Darstellung

Abbildung 36: CSS-Code zur Beschreibung des Slot-Overlays / Quelle: Eigene Darstellung

Abbildung 37: Designer nach dem Einfügen eines Web Service Connectors / Quelle: Eigene Darstellung

Abbildung 38: Java Code der getContainerFromSlot Funktion / Quelle: Eigene Darstellung

Abbildung 39: Java Code zur Ermittlung der Belegung von Slot S1 / Quelle: Eigene Darstellung

Abbildung 40: Browseransicht derfertigen Terminalseite / Quelle: Eigene Darstellung

Abbildung 41: Schemazeichnung d. Strecken d. Modells / Quelle: Eig. Darstellung

Abbildung 42: CSS-Code des Overlays eines Haltepunktes / Quelle: Eigene Darstellung

Abbildung 43: haltepunkt.view im Designer mit geöffneten Eigenschaften / Quelle: Eigene Darstellung

Abbildung 44: Java Code zum Setzen eines Haltepunktes / Quelle: Eigene Darstellung

Abbildung 45: Browseransicht der fertigen Haltepunkt-Seite / Quelle: Eigene Darstellung

Abbildung 46: Rohversion der GUI des Web Services Connectors von createLoadOrder / Quelle: Eigene Darstellung

Abbildung 47: Angepasstes Formular von createLoadOrder / Quelle: Eigene Darstellung

Abbildung 48: Browseransicht der fertigen Kran-Seite / Quelle: Eigene Darstellung

Abbildung 49: Kran-Seite nach dem Absenden einen Auftrags / Quelle: Eigene Darstellung

Abbildung 50: Übersicht über die .java Dateien des Projektes / Quelle: Eigene Darstellung

1 Einleitung

Im seit 2009 laufenden SARFIR-Projekt (Service-Oriented Architecture and Radio Frequency Identification for controlling/steering a model Railway) der TUHH werden die Möglichkeiten und Vorteile der Ablösung von Barcodes durch RFID-Plaketten in der Containerlogistik untersucht. Durch RFID können bestehende Prozesse weiter automatisiert und optimiert werden (1). Dabei steht die Integration des hier vorgestellten Containertracking-Systems in bestehende Containerlogistik-Systeme im Mittelpunkt. Nur wenn diese Integration möglichst reibungsarm realisierbar und die Vorteile groß genug sind, wird ein derartiges System auch eingesetzt werden.

Um diese Punkte zu erforschen wurde im Rahmen des SARFIR-Projekts ein Prototypen-Modell gebaut, dass einen Containerumschlag und Transport von einem Schiff über Eisenbahn und LKW hin zu Abnehmern simuliert. Das System ist mit RFID-Tags und -Lesegeräten ausgestattet um einen hohen Automatisierungsgrad bei geringen Kosten zu erzielen. Das Steuerungssystem der Anlage ist hochgradig flexibel und lässt sich in aktuelle bzw. manuelle Prozesse einbinden. Hierfür wird die webMethods-Suite der Software AG genutzt, die eine serviceorientierte Architektur (SOA) bereitstellt.

Die Prozesse die die SOA steuert werden in dieser Arbeit mit Hilfe des webMethods Designer modelliert und können sich in Produktionsumgebungen einfügen. Ziel ist dabei eine Funktionierende Struktur von Prozessen zu erzeugen, die die verschiedenen Abläufe (Kran, Zug, LKW u.a.) steuern und überwachen. Des Weiteren sollen sie mit relativ geringem Aufwand an neue Szenarien anpassbar sein.

Die komplette Datenhaltung des Systems erfolgt in einer relationalen Datenbank die hier als SQL-DB ausgeführt ist. Die SOA soll Zugriff auf diese Datenbank besitzen und in ihr z.B. die aktuelle Position sowie den Zustand von Containern und den Status der Transportmittel speichern. Im Rahmen dieser Arbeit wird die Datenbank mit ihren Tabellen und Relationen definiert und implementiert. Dabei wird sowohl ein umfangreicheres System für den Unternehmenseinsatz entwickelt, wie auch eine minimierte Version die exakt die Belange des Modell-Prototypen abdeckt.

Zur Erleichterung Steuerung der kompletten Anlage soll im letzten Teil der Arbeit ein komfortables grafisches Webinterface erzeugt werden. Hierzu werden Methoden wie das Composite Application Framework (CAF) vorgestellt und genutzt, die der webMethods Designer speziell zu diesem Thema bereitstellt. Im letzten Abschnitt werden die Vorteile dieses Interfaces, sowie die detaillierte Realisierung mit Hilfe von webMethods erklärt. Durch CAF soll die Erstellung eines solchen Interfaces laut Hersteller codeless, d.h. komplett ohne die Anpassung von Quellcode, möglich sein. Dieser Aspekt soll besonders betrachtet und überprüft werden.

2 Grundlagen, Methoden und Werkzeuge

2.1 RFID

Radio-Frequency-Identifikation (RFID) beschreibt die Verwendung eines drahtlosen Funk-Systems mit dem Zweck Daten von einer Plakette (Tag) an einem Objekt zu übertragen, welches der automatischen Identifikation und Nachverfolgung dient. Einige Tags benötigen keine Batterie und werden durch Induktion betrieben, während andere eine lokale Stromquelle nutzen. Der Tag enthält elektronisch gespeicherte Informationen, die aus bis zu mehreren Metern Entfernung ausgelesen werden können. Zwei-Wege-Transmitter senden ein Signal an den Tag und lesen seine Antwort. Im Gegensatz zu einem Barcode, wird bei RFID keine Sichtverbindung benötigt und es können hunderte RFID-Tags zeitgleich gelesen werden (2).

Die Informationen auf dem Tag werden in einem nichtflüchtigen Speicher abgelegt. Der RFID-Tag enthält einen kleinen Hochfrequenz-Sender und -Empfänger. Zuerst sendet das Lesegerät ein Funksignal um den Tag auszulesen. Der Tag empfängt die Nachricht und antwortet mit seiner Kennung. Diese ist eine eindeutige Seriennummer und kann weitere produktspezifische Informationen enthalten.

Die Stromversorgung der Tags erfolgt entweder passiv per Induktion oder aktiv mit Hilfe einer Batterie. Ein passiver Tag ist preiswerter und kleiner, weil er keine Batterie beinhaltet. Stattdessen verwendet der Tag die Induktionsleistung die durch das Lesegerät übertragen wird.

Der Electronic Product Code (EPC) ist ein Standarddatentyp der in den Tags gespeichert wird. Nach dem Beschreiben mit einem RFID-Schreibgerät, enthält der Tag ein 96-Bit langes Datum (String). Die ersten acht Bits sind ein Header, der die Version des Protokolls definiert. Die nächsten 28 Bits identifizieren die Organisation, die verantwortlich für die Daten dieses Tags ist. Dieser Code wird durch das EPCGlobal Konsortium Inc. an Organisationen vergeben. Die nächsten 24 Bits identifizieren die Art des Produktes, die letzten 36 Bit sind eine tagspezifische Seriennummer. Die letzten beiden Felder werden durch die Organisation, die Tag ausgestellt, gesetzt. Ähnlich einer URL, kann die komplette elektronische Produkt­Code-Nummer als Schlüssel in einer globalen Datenbank verwendet werden um ein Produkts eindeutig zu identifizieren. (3)

Oft reagiert mehr als ein Tag auf ein Lesegerät, zum Beispiel wenn viele Produkte mit Tags in einer gemeinsamen Kiste oder auf einer gemeinsamen Palette versendet werden. Kollisionserkennung ist in diesen Fällen wichtig. Zwei verschiedene Arten von Protokollen werden verwendet, um einen bestimmten Tag einzeln isoliert lesen zu können. In einem Slotted Aloha-System, sendet der Leser einen Initialisierungsbefehl und einen Parameter, den die Tags verwenden um ihre Antworten individuell pseudo-zufällig verzögert zu senden. Bei Verwendung eines Adaptive Binary Tree-Protokolls sendet der Leser einen Intialisierungscode und danach nur jeweils ein einzelnes Bit seiner Identifikationsdaten. So reagieren nur Tags mit passenden Bits, bis schließlich nur ein Tag der vollständigen ID entspricht. (4)

RFID-Tags werden in verschiedenen Anwendungen verwendet. Wichtige Bereiche die RFID-Technologie nutzen sind u.a. Logistik und Transport. Transport-, Fracht- und Verteilungszentren lassen sich mit RFID-Tracking-Technologie ausstatten. In der Bahnindustrie werden RFID-Tags auf Lokomotiven und Waggons montiert um den Besitzer, die Identifikationsnummer und Art der Transportmittel, sowie ihre Eigenschaften zu ermitteln. Im Zusammenspiel mit einer Datenbank kann dies verwendet werden, um die Ladung, Herkunft, Ziel, usw. der Waren zu ermitteln. Außerdem werden RFID-Tags verwendet, um Gepäck und Fracht an Flughäfen nach zu verfolgen.

2.2 webMethods

2.2.1 Entwicklungsplattform und verwendete Konzepte

Die webMethods Plattform bietet eine Infrastruktur, um End-to-End-Integration im gesamten Unternehmen zu ermöglichen. Die webMethods Plattform basiert auf einer Service-orientierten Architektur (SOA), die mit der sogenannten Service-Schicht eine Abstraktionsschicht bietet, die sich zwischen dem Client und der Business-Logik befindet. Somit ermöglicht die Plattform die Erstellung von Anwendungen durch Integration, sowie die Einbindung bestehender Unternehmensanwendungen über Web-Services, Datenbanken und anderen Ressourcen. Eine Reihe von Graphical User Interface (GUI)-basierten Entwicklungswerkzeugen steht bereit um diese Aufgaben zu erfüllen.

Sogar menschliche Interaktion kann im Prozess-Design als Dienst implementiert werden. Solche Anwendungen werden z.B. bei der manuellen Ausführung und Verwaltung unternehmensweiter Geschäftsprozesse modelliert, können aber auch in automatisierten Prozessen als Teilschritte enthalten sein. Darüber hinaus bietet webMethods eine breite Palette von Sicherheitsfunktionen, wie public key Infrastructure, digitale Signaturen und SSL. Für die Verwaltung und Überwachung bietet webMethods ein Web-Interface über den sogenannten webMethods Administrator sowie den webMethods Monitor.

WebMethods besitzt eine flexible Architektur, um verschiedenen Anforderungen gerecht zu werden. Um eine hohe Flexibilität zu erreichen besitzt die Plattform ein dezentrales Ausführungsmodell, das es erlaubt Code sowohl in Adaptern als auch in Servern auszuführen und damit maximale Performance und Skalierbarkeit zu erreichen. Die Basis für diese Fähigkeiten liegt in der Laufzeit-Architektur. Sie bietet Konnektivität zu den Anwendungen und ermöglicht die zuverlässige und sichere Kommunikation zwischen den verschiedenen Komponenten. Sie ist auch verantwortlich für die Daten-Transformationen und die Ausführung der Business­Prozesse. Sie besteht aus drei Teilen, die für die Ausführung der Business-Prozesse notwendig sind: Den Adaptern, dem Integration Server und dem Message Brokern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Beziehungen zwischen Integration Server und Anwendungen in einer typischen SOA/Quelle: Eigene Darstellung

Der Integration Server implementiert die Logik die in den Business-Prozessen definiert wurde. Sie stellt eine erweiterte Version eines Adapters dar und bietet mehr Möglichkeiten als diese.

Im Gegensatz zum Ansatz der verteilten Anwendung mit unabhängigen Adaptern, bietet der Integration Server eine Agglomeration aus mehreren Adaptern für eine enge Kopplung der Logik für schnelle Datenzuweisung und Datentransformation. Zum Beispiel zum Generieren eines Ergebnisses durch mehrere Anwendungen innerhalb eines einzigen Prozesses.

2.2.2 webMethods Designer

Der webMethods Designer ist das primäre Werkzeug zum Design und zur Implementierung der (Business-)Prozesse. Ein Business-Prozess stellt eine mehrstufige Interaktion zwischen verschiedenen Diensten dar. Im Designer werden die Interaktionen und Beziehungen einer Reihe von Aktivitäten in einem Prozess durch gängige Prozess-Modellierungseinheiten beschrieben. Der Designer realisiert den Top-down-Ansatz, der die Modellierung eines Prozesses ermöglicht, ohne die technischen Aspekte der erbrachten Dienstleistungen verstehen zu müssen.

Prozess-Modelle die mit dem Designer erstellt werden beschreiben eine Abfolge von Schritten und spezifizieren wie die Informationen zwischen ihnen fließen. Dabei besteht ein Prozessmodell aus Schritten, Übergängen und Dokumenten. Ein Schritt stellt eine Arbeitseinheit dar, die von einem Service auf einem Integration Server oder innerhalb eines Adapters ausgeführt wird. Sie kann aber auch eine Aktivität darstellen, die durch eine externe Komponente erbracht wird. Sie nimmt Dokumente entgegen oder erzeugt Dokumente zum Zeitpunkt ihrer Ausführung. Ein Übergang stellt den Ablauf der Steuerung dar und verbindet einen Schritt mit dem nächsten, mit der Möglichkeit regelbasierte Übergänge, eine Verzweigung oder eine Verbindung zu definieren. Die Daten die während der Schritte entgegengenommen der erzeugt werden bezeichnet man als Dokumente. (5) Eine Abfolge von Schritten kann in einen Teilprozess zusammengefasst werden. Dies ermöglicht eine bessere Strukturierung komplexer Abläufe und die Wiederverwendbarkeit von Teilprozessen, z.B. das Senden einer E-Mail-Benachrichtigung. Nachdem das Modellieren der Prozesse abgeschlossen ist wird automatisiert die Steuerlogik für die einzelnen Schritte erzeugt. Daher verbindet sich der Designer mit dem Integration Server, der die Schritte eines Prozesses ausführt und erzeugt die Laufzeit-Logik für jeden Schritt. Es wird ein neues Package erstellt, das alle Prozessschritte enthält und diese als Services beschreibt.

2.2.3 JavaServerFaces

WebMethods besitzt vielfältige Möglichkeiten die die Umsetzung eines Webinterfaces zu realisieren. In webMethods wird diese Methode als Composite Application Framework (CAF) bezeichnet. Das CAF wird standardmäßig über den internen Web­Browser angezeigt, der Teil des zu Grunde liegenden Eclipse-Frameworks ist. JavaServer Faces (kurz: JSF) ist ein Framework-Standard zur Entwicklung von grafischen Benutzeroberflächen für Webapplikationen. Basierend auf Servlets und JSP-Technik, gehört JSF zu den Webtechnologien der Java Plattform, Enterprise Edition (Java EE). Mit Hilfe von JSF lassen sich auf einfache Art und Weise Komponenten für Benutzerschnittstellen in Webseiten einbinden und die Navigation definieren. Voraussetzungen für die Entwicklung von JSF-Content sind das JDK, ein Servlet-Container und Grundlagenverständnis von HTML, HTTP und der Java- Programmiersprache. Zur Vereinfachung der Entwicklung kann eine Integrierte Entwicklungsumgebung wie z.B. die webMethods Suite verwendet werden.

JavaServer Faces bietet eine einfache Möglichkeit, leistungsfähige Webanwendungen zu schreiben, ohne dass man sich zu viele Gedanken über die Komplexität einer Webanwendung (Zustand über zustandsloses Protokoll, Request, Response, ...) machen muss. Bei der Entwicklung soll es auch einem Programmierer einer Desktopanwendung erleichtert werden, Webanwendungen zu schreiben. Da große Firmen an der Spezifikation mitgearbeitet haben, wird JavaServer Faces faktisch zum Standard.

Prinzipiell eignet sich JavaServer Faces dazu, Rich Client-Anwendungen im ähnlichen Programmierstil wie GUI-Anwendungen im Internet abzubilden. Eine Stärke von JSF ist die dynamische Generierung von Formularen. (6)

2.2.4 Portlet Anwendungen innerhalb CAF

Ein Portlet ist eine server-seitige, Mini-Anwendung, die auf dem webMethods Server ausgeführt wird. Portlets, die mit dem Composite Application Framework erstellt wurden, nutzen JavaServer Faces-Technologie. Die JSF-Komponenten der Benutzeroberfläche sind konfigurierbare und wiederverwendbare Elemente, aus denen sich die gesamte Benutzeroberfläche von JSF-Anwendungen zusammensetzt.

Ein klickbarer Button ist ein Beispiel für eine einfache JSF-Komponente, eine Tabelle dagegen kann aus mehreren Komponenten aufgebaut sein. CAF Portlets bestehen aus View-Dateien, die die einzelnen Seiten (bzw. Ansichten) des Webinterfaces beinhalten. Eine Ansicht ist eine JSF-Seite die aus Elementen der Benutzeroberfläche besteht.

Für jedes Portlet in einer Anwendung existiert eine sogenannte Managed Bean. Eine Managed Bean ist eine Java-Bean, die eine Java-Klasse mit einer Reihe von Eigenschaften darstellt. Managed Beans enthalten Metadaten, die ihren eindeutigen Namen innerhalb einer Portlet-Anwendung definieren, ihren Typ, den Klasse-Typ und den Scope. Der Scope bestimmt die Zeit zu der die Bean ausgeführt und wieder terminiert wird. Die Beans in diesem Projekt werden nur einmal geladen und zur Laufzeit nicht terminiert.

Portlets die in CAF erstellt wurden, sind kompatibel mit dem JavaSpecification Request. Diese Spezifikation ermöglicht Interoperabilität zwischen Portlets und Portalen. (7)

Im Software AG Designer können durch CAF dynamische Webanwendungen mit JavaServer Faces-und AJAX-Framework erstellt werden. Einfache statische Web­Anwendungen sind HTML-Seiten mit Inhalten, die der Benutzer im Wesentlichen nur lesen kann. Eine dynamische Webanwendung Projekt ermöglicht es dem Benutzer, mit der Web-Anwendung zu interagieren.

Ajax (Asynchronous JavaScript and XML) ist eine Technik für die Erstellung interaktiver Web-Anwendungen. In frühen Web-Anwendungen, wurde die gesamte Web-Seite jedes Mal, wenn der Benutzer eine Änderung, wie Eingabe von Suchkriterien in einem Formular, gemacht hat, neu geladen. Die Ajax-Engine dagegen wirkt als Vermittler zwischen dem Benutzer und dem Server. Wenn der Benutzer mit einem Web-Formular interagiert kommuniziert die Webseite asynchron mit dem Server und ermöglicht dem Benutzer, mehrere Änderungen in dem Formular ohne die Seite neu laden zu müssen. Dieses Verhalten ermöglicht eine viel interaktivere Art auf Nutzereingaben in einer Web-Anwendung zu reagieren.

2.3 Railware Controller und Controller-Gateway

Über einen netzwerkgesteuerten Controller lassen sich der Modellzug, der Modell- LKW und der Kran die auf der Anlage steuern. Das folgende Schema zeigt wie er in das Gesamtkonzept eingefügt ist und verdeutlicht den flexiblen und modularen Aufbau einer SOA.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Hierarchie der Transportmittelsteuerung / Quelle: Eigene Darstellung

Die Verbindung von Controller-Gateway zum Railware Controller besteht per Hypertext Transfer Protocol (http). Bei der Verbindung zum Integration Server muss sich der Gateway mit den Standardeinstellungen autorisieren. Die Informationen, die die SOA erhält, beschränken sich auf die verschiedenen Haltepunkte mit ihrem jeweiligen Status. Eine Information könnte zum Beispiel beinhalten, dass der Zug gerade an Haltepunkt 3 eingetroffen ist.

Durch das Gateway lässt sich die Anlage auch ohne aktive SOA steuern. Neben der Initialisierung der Anlage ist es möglich, Zug und LKW zu steuern und dem Kran Befehle zu senden. Nach dem Anschluss an den Strom muss zuerst eine Initialisierung der Anlage sowie der Verbindung von Gateway und Controller durchgeführt werden. Es ist möglich Testbefehle an die Fahrzeuge zu senden.

Der Versand der Nachrichten von der SOA zum Controller funktioniert verbindungslos über das HTTP-Protokoll. SOA und Controller tauschen hierbei über das Netzwerk abwechselnd Request- und Response-Nachrichten aus. Die Nachrichten sind dabei als Zeichenkette, mit dem Komma als Trennzeichen, aufgebaut. Folgende Befehle kann die SOA an den Controller schicken:

Abbildung in dieser Leseprobe nicht enthalten

Der Controller kann in seiner Response-Nachricht folgende Antworten verwenden:

Abbildung in dieser Leseprobe nicht enthalten

Für folgende Ereignisse, die der Controller der SOA melden kann, sind keine Antworten der SOA vorgesehen:

Abbildung in dieser Leseprobe nicht enthalten

2.4 SOA und BPM

Eine SOA ist eine mehrschichtige, verteilte Informationssystem-Architektur, die Teile der Applikationsarchitektur zur vereinfachten Prozessintegration als Dienste kapselt und dabei eine Reihe von Designprinzipien berücksichtigt. Letztere umfassen v.a. Schnittstellenorientierung, Autonomie und Modularität, Interoperabilität und Bedarfsorientierung. (8)

Dienste stellen Funktionalitäten dar, die in Form eines Workflows zusammengefasst (orchestriert) sind. Workflows entsprechen übergeordneten Prozessen die Dienste als Teilschritte nutzen, was eine größtmögliche Wiederverwendbarkeit der Dienste sicherstellt. Die Dienste können über eine Integrationsschicht auf Anwendungen und Hardware zugreifen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: SOA Übersicht /Quelle: Einführung und Etablierung von SOA, Trivadis AG

SOA definiert, wie verschiedene Anwendungen für eine Web-basierte Applikation kombiniert und integriert werden und nutzt mehrere Implementierungs-Plattformen. SOA definiert keine Programmierschnittstelle, sondern Schnittstellen von Protokollen und Funktionalitäten.

Service-Orientierung erfordert lose Kopplung von Diensten mit Betriebssystemen und anderen Technologien, die den Anwendungen zu Grunde liegen. SOA trennt Funktionen in einzelne Einheiten oder Services, die Entwicklern über ein Netzwerk zugänglich machen, damit die Benutzer sie in der Produktion von Anwendungen nutzen können. Diese Services und ihre Nutzer kommunizieren miteinander, indem sie Daten in einem gemeinsamen Format nutzen oder durch Koordinierung von Aktivitäten zwischen mehreren Services. Häufig wird XML das Zusammenwirken mit SOA-Services verwendet.

SOA kann geschichtlich als Teil eines fortlaufenden Entwicklungsprozesses betrachtet werden: Angefangen bei den älteren Konzepten des verteilten Rechnens und der modularen Programmierung, über die SOA, hin zu der heutigen Praxis von Mashups und Cloud Computing. (9)

3 Modell und Prozesse

3.1 Modell des Prototypen

Zur Entwicklung, zum Testen und zur Demonstration des SOA-Systems wurde ein Modell-Prototyp geschaffen, mit dem sich alle relevante Abläufe simulieren lassen. Das Modell beinhaltet ein Schiff zum Einbringen von Containern in das System, sowie ein Terminal mit sieben Containerslots, in dem Container verladen und gelagert werden können. Die Transportabläufe werden über eine Modelleisenbahn und eine LKW-Strecke abgewickelt. Diese führen zu zwei Unternehmen, die das Ziel für die Ladung darstellen.

Im unteren Bild lässt sich am hinteren Ende des Modells das Terminal erkennen. Es besteht aus einem Schiff mit zwei Slots, neben dem die Eisenbahnstrecke und die LKW-Strecke liegen. Die Eisenbahn besitzt drei Slots, der LKW lediglich einen. Verladen werden die Container Grundsätzlich nur vom Schiff und zwar auf die Lagerplätze oder die Transportmittel. Die Verladung übernimmt ein Kran (im Bild gut erkennbar), dessen Aktionsradius alle Slots abdeckt.

Die beiden Unternehmen sind lediglich durch ein grünes bzw. ein blaues Rechteck angedeutet. Hier findet ausschließlich die Entladung der Container statt. Im Terminal findet diese automatisch statt, bei den Unternehmen muss diese manuell geschehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Prototyp im Modell / Quelle: Darmstadt-Präsentation Foto

Insgesamt befinden sich zwölf RFID Lesegräte in dem Modell. An beiden Strecken befinden sich jeweils fünf: Die erste an der Terminalausfahrt, die zweite auf halbem Wege zwischen Terminal und Unternehmen und die dritte im Unternahmen um das Erreichen des Ziels zu registrieren. Die beiden Verbleibenden befinden sich, symmetrisch zu Beschreibung eben, auf halbem Wege zum Terminal und die letzte in der Terminaleinfahrt. Diese Verteilung ist bei beiden Strecken identisch. Parallel zu diesen zehn Geräten befinden sich auch jeweils vier Haltepunkte auf beiden Strecken. Es handelt sich nur um vier Stück, da das Terminal nur einen Haltepunkt benötigt. Angesteuert werden die Punkte über einen Railware Modellbau-Controller. Die beiden Slots auf dem Schiff beinhalten die letzten beiden Lesegeräte um das Ankommen neuer Container im System zu registrieren. Der Zug, der LKW und die Container sind mit RFID-Tags versehen, um auf den Strecken und im Terminal erkannt werden zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Modelle die Zug und LKW simulieren / Quelle: Darmstadt-Präsentation Foto

Gesteuert wird das Modell über Prozesse, die sich folgendermaßen gliedern: Das Eintreffen neuer Container per Schiff wird durch den Schiffs-Prozess überwacht und ihre Verladung durch den Kran-Prozess. Den Transport der Container durch Zug und LKW steuern die sehr ähnlich aufgebauten Zug- und LKW-Prozesse. Zuletzt überwacht ein separater Prozess die Position und den Zustand aller Container im System.

[...]