Distributed System For Technology Integration
Einleitung
Das Devil Framework ist eine plattformübergreifende (Linux, OS X, Windows), mandantenfähige, mehrschichtige, verteilte Plattform für die Entwicklung von Lösungen zur Prozess- und Technologieintegration: Entwickler können auf einfache Weise alle Informationen, die von heterogenen vernetzten Hardware- und Softwaretechnologien erzeugt und verbraucht werden, sammeln, integrieren, korrelieren, steuern und visualisieren.
Das Projekt begann 1999 als System zur Integration von Daten aus Netzwerksicherheitsanwendungen. Als wir jedoch "entdeckten", dass Sicherheit nur ein weiterer Prozess ist, entwickelte es sich zu einer allgemeineren Infrastruktur für das Prozessmanagement weiter.
Wir nutzen es nun zur Implementierung von Lösungen für die Unternehmens-/Werksintegration für Geschäftsgruppen (Fertigung, Vertrieb usw.) mit Produktions-/Geschäftseinheiten, die über das ganze Land verteilt sind.
Wir sind dabei, es als Open-Source-Produkt mit nicht-kommerziellen und kommerziellen Lizenzen zu veröffentlichen.
Architektur
Das Devil Framework-System besteht aus zwei verschiedenen Anwendungen: den Application Server-Komponenten und der grafischen Konsole IceBridge. Beide sind plattformübergreifende Anwendungen, die vollständig in Python geschrieben sind: Der Server läuft auf Linux- und Windows-Plattformen (und kann leicht auf andere Unix-Systeme portiert werden), der Client läuft auf Linux, Windows und Mac OS X.
Application Server Komponenten
Die Application Server-Komponenten sind das Herzstück der Plattform für Anwendungsentwicklung und Überwachungssteuerung für die Devil Framework-Produktlinie. Sie bieten eine einheitliche Umgebung für Datenerfassung, Datenhistorisierung, Kommunikation, Prozessautomatisierung sowie Anwendungsbereitstellung und -integration.
Architektur der Application Server-Komponente Vergrößern
Eine Komponente ist als Plugin-basiertes System konzipiert. Plugins können zur Laufzeit manuell oder über geplante Richtlinien hinzugefügt, entfernt und aktualisiert werden. Es werden verschiedene Richtlinien unterstützt, sodass eine Komponente ihre Funktionalitäten und Konfigurationen zu geplanten Zeiten ändern kann. Jede Funktionalität einer Komponente wird über Plugins implementiert.
Komponenten sind so konzipiert, dass sie als baumartige vernetzte Struktur funktionieren, mit einem Master-Knoten (MCP), auf dem die gesamte Konfiguration sowie die Installation und Aktualisierung von Plugins durchgeführt werden. Alle anderen Knoten (Sammler und Agenten) erhalten automatisch die richtige Konfiguration und Software-Updates. Neue Knoten können jederzeit hinzugefügt werden, um die Datenverarbeitung zu skalieren, neue geografische Zonen zu erreichen oder neue Geräte anzubinden.
Baumartige verteilte Systemtopologie Vergrößern
Komponenten sind so konzipiert, dass sie auf unsicheren, unzuverlässigen und nicht immer verbundenen Kommunikationskanälen arbeiten. Die gesamte Kommunikation ist verschlüsselt (unter Verwendung des Moduls pycrypto) und authentifiziert über eine interne PKI-Infrastruktur (alle Knoten verfügen über ihre PKI-Zertifikate). Ein Store-and-Forward-Mechanismus wird sowohl für die Konfigurations- und Codepropagationssysteme als auch für die Ereignisübertragung verwendet. Verbindungen können von jeder Komponente initiiert werden: Eltern können Kinder aufrufen, und Kinder können ihre Eltern aufrufen (Verbindungen können zu geplanten Zeiten aktiviert werden, wenn bestimmte Ereignisse auftreten oder wenn spezielle Bedingungen erkannt werden).
Das Application Framework schafft eine verteilte Umgebung, in der alle Knoten, sowohl aus programmiertechnischer als auch aus operativer Sicht, als einziges System mit einer einzigen API betrachtet werden. Operationen können transparent von jedem Elternknoten auf jedem Kindknoten ausgeführt werden.
IceBridge grafische Konsole
Die IceBridge-Konsole ist eine plattformübergreifende Anwendung, die in Python geschrieben ist (unter Verwendung des QT/PyQT Toolkits/Wrappers für die Benutzeroberfläche) und alle benötigten Werkzeuge für Entwicklung, Konfiguration, Verwaltung und interaktive Nutzung des Application Server-Systems bietet.
Ähnlich wie die Komponenten des Application Servers ist die Konsole ein Plugin-basiertes System. Plugins werden bei Bedarf oder wenn neue Versionen verfügbar sind, dynamisch vom Server heruntergeladen. Es ist keine Benutzer- oder Administratorintervention erforderlich. Plugins können jede Konsolenfunktionalität hinzufügen, ändern, erweitern oder ausblenden und so ein vollständig pro Benutzer anpassbares Erlebnis bieten.
Eine vollständige Konfigurations- und visuelle Entwicklungsumgebung ist in die Konsole integriert (einschließlich eines Versionskontrollsystems für Ansichten und einer interaktiven Remote-Python-Shell). Visualisierungs- und Steuerungsformulare (genannt Ansichten) können in Echtzeit hinzugefügt, modifiziert und getestet werden. Neue Ansichtskomponenten (Widgets) können dynamisch durch Plugins verfügbar gemacht werden.
Systemkonfiguration und Interface-Design in Echtzeit mit "Live"-Widgets Vergrößern
Prozessspezifische Widgets, Ansichten, Fenster und Anwendungen können einfach entwickelt und bereitgestellt werden. Das System ist für die Internationalisierung bereit; mehrere Sprachen werden unterstützt und jeder Benutzer kann seine bevorzugte Sprache verwenden. Darüber hinaus sind ein Übersetzungstool (inspiriert vom QT Linguist Tool) und ein WikiWiki-ähnliches Dokumentationsbearbeitungs- und -anzeigetool in das System integriert.
Steuerungsansicht mit einem benutzerdefinierten 3D-Visualisierungs-Widget unter Linux und KDE Vergrößern
Warum Python?
Python war nicht unsere erste Wahl als Hauptprogrammiersprache, es war ein Zufall. Als wir unser Projekt begannen, waren wir sehr erfahren in Perl und völlig unwissend über Python: also wählten wir Perl.
Wir entdeckten Python, als wir beschlossen, dass wir die PerlTK-Benutzeroberfläche durch eine webbasierte ersetzen mussten. Wir fanden Zope und nach einigen Versuchen, Perl mit Zope zu integrieren, wechselten wir zu Python. Um es kurz zu machen, am Ende haben wir Zope aufgegeben, aber weiterhin Python verwendet (und das gesamte Devil Framework damit neu geschrieben).
Ohne diesen glücklichen Wechsel wäre das Devil Framework unserer Meinung nach nicht entwickelbar gewesen, zumindest nicht für ein Team von nur zwei Entwicklern.
Projektstatistiken
Die SLOCCount-Ausgabe sagt alles
Totals grouped by language (dominant language first): python: 233020 (97.72%) ansic: 2480 (1.04%) cpp: 1833 (0.77%) makefile: 571 (0.24%) sh: 560 (0.23%) Total Physical Source Lines of Code (SLOC) = 238,464 Development Effort Estimate, Person-Years (Person-Months) = 62.71 (752.50) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 2.58 (30.98) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 24.29 Total Estimated Cost to Develop = $ 8,471,018 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
Auf der Seite Personenjahre haben wir vier Jahre gebraucht, damit zwei Entwickler die Version 2.0 von Grund auf neu entwickeln (Version 1.x war in Produktion, aber nie veröffentlicht).
Ergebnisse
Wie bereits erwähnt, glauben wir, dass dieses Projekt ohne die Einführung von Python als Hauptentwicklungssprache nicht möglich gewesen wäre, entweder wegen seiner leistungsstarken Funktionen oder weil es maßgeblich zur Einführung von Bibliotheken wie PyQT (nachdem wir versucht hatten, PerlTK, Web, wxPython zu verwenden), pycrypto und anderen zu verwenden, die es uns ermöglichten, in einer relativ kurzen Zeitspanne ein zuverlässiges und portables System aufzubauen.
Produktivität
Python ist unsere "Geheimwaffe". Es ermöglicht uns eine um Größenordnungen höhere Produktivität dank
- Einfache Syntax und klarer Programmierstil: Es hat uns mühelos gezwungen, einen konsistenten und ausdrucksstarken Programmierstil zu verwenden. Jetzt ist es einfach, ein Stück Code anzusehen und auf einen Blick zu verstehen, wie es funktioniert (bei der ersten Perl-Version fast unmöglich).
- Schneller Entwicklungszyklus: Python hat den mühsamen und langen Code/Build/Run/Crash-Entwicklungszyklus eliminiert.
- Es ermöglichte uns, eine der wichtigsten Funktionen unseres Systems zu entwickeln: Wenn wir neuen Code im System aktualisieren oder installieren, aktualisiert er sich dynamisch, sowohl Client als auch Server. Stellen Sie sich vor: Mit einem einfachen Doppelklick installieren Sie ein Plugin auf dem zentralen Server, aktualisieren es (propagieren die Änderungen auf alle Knoten des Systems, die es verwenden), führen es aus, laden seine Client-Daten in die Konsole herunter und machen es aktiv (aktualisieren die GUI dynamisch). Alles ohne Neustart des Servers oder Clients.
- Umfangreiche und vollständige Standardbibliothek und großartige externe Module.
- Und wenn es keine Standardbibliothek oder kein externes Modul gibt, ist es sehr einfach, Wrapper um eine Drittanbieterbibliothek zu erstellen (besonders mit dem ctypes-Modul).
- Einfaches und schnelles Refactoring von Code: Wir haben alten Code, der ständig aktualisiert wird.
Plattformübergreifende Entwicklung
Die Portierung unserer Anwendung auf die verschiedenen unterstützten Plattformen war dank der großen Portabilität von sowohl Python als auch PyQT und den meisten externen Modulen, die wir im Projekt verwendet haben, sehr einfach. Die einzigen wirklichen Probleme, die wir hatten, wurden durch plattformspezifische Module (hauptsächlich unter Windows) und durch die Entwicklung der Installationssysteme (wiederum Windows) verursacht.
GUI-Entwicklung
Die Wahl des PyQT/QT Toolkits war entscheidend für die Entwicklung der Client-Anwendung. Wir haben andere Toolkits (Tk und wxPython) ausgiebig genutzt, bevor wir uns PyQT zuwandten. Kein Toolkit kann mit seiner einfachen Handhabung, Leistung, Stabilität und Portabilität mithalten.
Als Beispiel war der Mac OS X-Port der IceBridge-Konsole in weniger als einer Woche möglich, wobei die meiste Zeit für das Erlernen der korrekten Erstellung der einzelnen Pakete aus dem Quellcode und die Konfiguration des Paketierungssystems aufgewendet wurde.
Die IceBridge-Konsole unter Mac OS X Vergrößern
Geschwindigkeit, Skalierbarkeit und Stabilität
Eines unserer Anliegen war die Geschwindigkeit unseres Systems. Python erwies sich als "schnell genug" für unsere Zwecke, da die rechenintensivsten Aufgaben bereits in C geschrieben sind (GUI-Toolkit, GUID-Generatoren, numerische Manipulationen usw.). Wir mussten nur unser benutzerdefiniertes RPC-Protokoll in Python schreiben, da XML-RPC (und seine Python-Implementierung) sich als zu langsam und rechenintensiv erwies.
Skalierbarkeit war ein Thema, das wir bereits im Design gelöst haben, aber Python ermöglichte es uns, Programmierkonstrukte wie das transparente verteilte RPC-System und das erweiterbare API-System zu erstellen.
In Bezug auf die Stabilität denken wir, dass Pythons großartiger Mechanismus zur Ausnahmebehandlung uns einen enormen Vorteil verschafft hat. Unsere Programmierfehler führen fast nie zum Absturz der Anwendung und sind fast immer behebbar.
Reale Anwendungen
Einige Beispiel-Szenarien, in denen wir das Devil Framework verwendet haben, sind:
- Verwaltung und Steuerung aller Technologiesysteme für große Einzelhändler von den lokalen Filialen und der Unternehmenszentrale aus (Klimaanlagen, Stromverbrauchssteuerung und -reduzierung, Datenanalyse usw.).
- Schnittstelle und Integration von Produktionssystemen und Buchhaltungssystemen für Fertigungsgruppen mit verschiedenen Produktionsanlagen und Geschäftseinheiten in ganz Europa (Echtzeit-Preis Simulation, Analyse und Visualisierung von Produktionsdaten in Echtzeit, automatisierte Anomalieerkennung und -reaktion, Datenkorrelation usw.).
- Verwaltung und Steuerung von entfernten Umweltdatenerfassungseinheiten (GPS-Verbindungen, automatische Aktualisierung und Neukonfiguration der Einheiten, Datenharmonisierung und -analyse usw.)
Besonderheiten
Wir hatten nur geringfügige Besonderheiten mit der Python-Sprache selbst, von denen nur eine einen wirklichen Einfluss auf unsere Projekte hatte:
- Thread-Management. Wir wissen, dass Threads schlecht sind, aber manchmal sind sie unschätzbar wertvoll. Keine Möglichkeit zu haben, sie zu beenden, war etwas Schwerakzeptierbares.
- Inkonsistenz der Gleitkommadarstellung zwischen Windows und dem Rest der Welt. Wir mussten einige üble Tricks anwenden, um diese Inkonsistenz (teilweise) zu umgehen.
Schlussfolgerung
Nach so viel Entwicklungszeit und so vielen Codezeilen können wir ohne zu zögern sagen: "Heil Python, wir glauben an dich!"
Es war und ist immer noch eine Freude, in einer so freundlichen und leistungsfähigen Sprache zu entwickeln.
Über den Autor
Alessandro Iob ist der CEO und Mitbegründer von D-Level s.r.l., den Machern des Devil Framework. Er war ein glühender Verfechter von C, bevor er die Schönheiten von Python entdeckte. Weitere Informationen über ihn und die Entwicklung des Devil Framework finden Sie auf seinem Blog.