Eclipse-Umgebungen skalieren

Large Scale mit Eclipse

Markus Duft

© Shutterstock.com / White78

Large Scale – was ist das eigentlich? Jeder versteht etwas anderes darunter, beispielsweise Skalierbarkeit der eigenen Anwendung oder Skalierbarkeit der Entwicklungsumgebung. In diesem Artikel möchte ich einen Überblick darüber geben, was Skalierbarkeit für uns bedeutet und wie wir sie mit Technologien aus dem Eclipse-Umfeld erreichen konnten.

Zur Demonstration möglicher Skalierungseffekte Eclipse-basierter Anwendungen soll hier unsere Applikation WAMAS (kurz für „Warehouse Management System“) eingeführt werden. Wir arbeiten an einer Intralogistiklösung, die weltweit im Einsatz ist und den Warenfluss (inklusive Planung und Reporting zurück an übergeordnete Systeme) lagerstandortübergreifend steuert. Das beinhaltet nicht nur die Überwachung und Anleitung manueller Prozesse, wie das Transportieren einer Palette mit einem Gabelstapler von A nach B, sondern auch die Steuerung komplexer, hochautomatisierter Anlagen.

Auf den ersten Blick konnte ich mir als Außenstehender vor knapp acht Jahren nicht vorstellen, dass solch eine Software dermaßen komplex sein kann. Viele der Abläufe in der Software sind extrem vielseitig parametrierbar und müssen daher auf viele Spezialfälle vorbereitet sein. Das bedeutet viel Code. In diesem Zusammenhang finden wir dann auch schon die erste Dimension der Skalierbarkeit: die Größe der Codebasis und die Aufteilung in einzelne Module, Plug-ins etc.

Der Quellcode von WAMAS ist im Zeitraum von 2007 bis 2011 von 500.000 auf 1.800.000 Zeilen angestiegen. Heute sind es schon beinahe 3.000.000 Zeilen, verteilt auf etwa 800 OSGi Bundles. Etwa 150 bis 200 Entwickler brauchen eine leistungsfähige Entwicklungsumgebung, mit der sie effizient WAMAS (weiter)entwickeln und warten können. Hier finden wir die nächsten beiden Dimensionen: die Anzahl der Entwickler, die an einer Software arbeiten, sowie die Skalierbarkeit bzw. Performance der IDE und der Infrastruktur selbst.

Abb. 1: Dimensionen der Skalierbarkeit

Abb. 1: Dimensionen der Skalierbarkeit

Da unsere Software nahezu immer speziell für Kunden angepasst wird, ist der standardisierte Produktkern nur die Basis für eine individuelle Projektentwicklung. Noch mehr Teams und noch mehr Entwickler erweitern und verändern das Produkt, um kundenspezifische Anforderungen erfüllen zu können. Hieraus ergibt sich eine weitere Dimension der Skalierung: die Anzahl der Anlagen im Betrieb, die auf unser Produkt aufsetzen.

Typischerweise besteht eine Kundeninstallation an einem Lagerstandort aus einem WAMAS-Server (der wiederum aus mehreren RCP-Applikationen besteht) und einer variablen Anzahl an verbundenen Clients, wobei die Clients sich wieder in unterschiedliche Typen (Desktop, Mobilgerät und andere) aufteilen. Was uns zur letzten Dimension der Skalierbarkeit bringt: die Anzahl der installierten Anwendungen bzw. laufenden Prozesse pro Anlage (Abb. 1).

Wo ist Skalierbarkeit wichtig?

Wir haben in den letzten Jahren die Erfahrung gemacht, dass Skalierbarkeit in jeder dieser Dimensionen von entscheidender Bedeutung ist. Wenn man es nicht schafft, seine Entwickler mit einer vernünftigen Entwicklungsumgebung zu versorgen, die auch einfach aktuell gehalten werden kann, wird man nicht weit kommen. Dieser Punkt wird umso wichtiger, je mehr Entwickler mitarbeiten. Auch die Qualität der Zusammenarbeit mit Entwicklern, die um die ganze Welt verteilt sind, hängt stark von einer guten IDE ab. Wenn der Code der eigenen Applikation nicht wartbar und erweiterbar ist, werden die Projektteams Erweiterungen nicht effizient entwickeln können – denn auch wir stehen im Wettbewerb mit anderen Softwareanbietern. Kann man die eigenen Applikation nicht den Anforderungen entsprechend skalieren, wird es schwierig, Kundenanforderungen zu erfüllen.

An dieser Stelle kommt Eclipse ins Spiel. Eclipse und RCP bieten eine stabile und performante Basis für unsere Entwicklungsumgebung und unsere Applikationen gleichermaßen. Auf diese Basis und den Einsatz diverser anderer Eclipse-Technologien haben wir uns in den letzten zehn Jahren erfolgreich gestützt. Zudem auf einige selbst entwickelte Erweiterungen, um unsere tägliche Arbeit zu optimieren.

Abgeleitet aus den oben genannten Dimensionen ergeben sich drei wichtige Hauptbereiche, auf die wir unser Augenmerk richten, um Skalierbarkeit in allen Bereichen zu ermöglichen (Abb. 2):

  • die Entwicklungsumgebung
  • die Laufzeitumgebung und Plattform unserer Applikation
  • das Deployment bzw. die Verteilung und Konfiguration der fertigen Applikation
Abb. 2: Drei Hauptbereiche: Entwicklungsumgebung, Plattform, Deployment-Szenario

Abb. 2: Drei Hauptbereiche: Entwicklungsumgebung, Plattform, Deployment-Szenario

Entwicklungsumgebung

Auf die Architektur und Laufzeitumgebung der eigenen Applikation wirft man relativ schnell einen genaueren Blick. Was jedoch bei uns lange Zeit als gegeben angenommen wurde, war die Entwicklungsumgebung. Es hat einige Jahre gedauert, bevor die ersten Verbesserungen daran vorgenommen wurden. Diese hatten dann aber gleich so durchschlagenden Erfolg, dass etliche weitere auf dem Fuße folgten.

Jeder Entwickler beginnt mit dem Aufsetzen eines Workspace für die Applikationsentwicklung. In unserem Set-up müssen auch bestehende Entwickler ein- bis zweimal pro Jahr ein neues Eclipse aufsetzen, da für jede Softwareversion von WAMAS ein dezidiertes Eclipse zu verwenden ist.

Ich kann mich an das Aufsetzen meines ersten Workspace erinnern. Es war die reine Katastrophe: „Welches Eclipse soll ich verwenden?“ – „Nimm einfach eines von eclipse.org“. „Welche Plug-ins muss ich von wo auschecken?“ – „Hier, nimm mein privates Team-Project-Set.“ Eine zentral gepflegte Liste aller Projekte gab es nicht, neue Plug-ins wurden per E-Mail angekündigt. Es hat mich sicherlich mehr als einen Tag gekostet – vollkommen klar, dass Skalierung so nicht möglich ist.

Nebenbei gab es noch Probleme, die zwar immer wieder auftraten, bei denen aber keiner so recht wusste, was man dagegen tun kann. Der Nightly Build verwendete damals Ant und war komplett unabhängig von Eclipse. Jegliche Konfiguration existierte doppelt und hätte auch doppelt gewartet werden müssen – was natürlich kein Entwickler tat. Die Konsequenz war, dass es einem großen Ereignis gleichkam, wenn dann tatsächlich ein Nightly Build durchgelaufen ist.

Vier große Maßnahmen haben uns geholfen, unsere Entwickler wieder auf einen (skalierbaren) Pfad zu bringen:

  • Ein einheitlicher und sauber integrierter Build (IDE, Nightly, Continuous Integration), der ohne zusätzliche Konfiguration auskommt.
  • Die Umstellung auf Git und Gerrit, zusammen mit Werkzeugen, um Projekte und Working Sets automatisiert zu importieren und zu verwalten.
  • Eine zentrale Konfiguration, Verwaltung und das orchestrierte Updaten von Eclipse-Installationen.
  • Das Ersetzen binärer UML-Modelle (inklusive externer Versionsverwaltung) durch Xtext-basierte DSLs.

Generell folgen wir dem Schema, doppelte Konfiguration mit allen Mitteln zu vermeiden, da hier ein riesiger Hebel sitzt, mit dem man alle Entwickler bremsen oder eben auch beschleunigen kann.

Einheitlicher Build

Wir haben eine Eigenentwicklung namens „WAMAS Power Build“ im Einsatz, kurz WPoB. Eigentlich ist WPoB nur eine einfache Applikation, die eine Aneinanderreihung von Tasks ausführen konnte – zum Beispiel „Kompiliere alle Projekte“, oder „Lasse einen bestimmten Generator laufen.“ Diese Applikation kann von der Kommandozeile oder per Knopfdruck innerhalb der IDE gestartet werden.

Unserem modellgetriebenen Ansatz geschuldet haben wir einige Codegeneratoren im Einsatz. Diese Generatoren sind Applikationen in unserem Workspace und greifen auf den gleichen Code zu wie unsere Applikationen zur Laufzeit, um dynamische Modelle zu laden, zu erstellen und in Java-Code zu transformieren. Aus diesem Grund können diese Generatoren auch nicht in die IDE verschoben oder in die IDE eingebunden werden, zumindest nicht, ohne einen wesentlichen Teil unserer Applikationsplattform in die IDE zu kopieren.

Daher, und weil wir generierten Code nicht einchecken, musste jeder Entwickler seinen Workspace in mehreren Schritten kompilieren: Eclipse Autobuild starten, wobei der Workspace danach etliche Fehler aufwies. Den ersten Generator laufen lassen, und wieder warten bis der Eclipse Autobuild die nächsten tausend Fehler beseitigte. Den nächsten Generator laufen lassen, und immer so weiter. Insgesamt zog da schon leicht mal eine Stunde ins Land, bevor die Software halbwegs durch war.

Exzessives Profiling des Eclipse Autobuild hatte uns damals gezeigt, dass dieser relativ leicht auf unsere Bedürfnisse angepasst werden konnte. Unser Problem war der so genannte „Package-Import“ – eine Möglichkeit, um in einem Plug-in zu spezifizieren: „Dieses Java-Package wird gebraucht; woher es kommt ist irrelevant“. Das ist zwar ein toller Mechanismus, wenn man ein Framework entwickelt, von dem man noch nicht weiß, wie die endgültige Laufzeitumgebung aussehen wird. In unserer Software gibt es aber klare Architekturvorgaben und Regeln, wer von welchen Plug-ins abhängig sein darf. Das ist aus unserer Sicht zwingend bei der Größe unserer Software, die etwa 800 OSGi Bundles umfasst. Daher sind bei uns alle Abhängigkeiten unter Plug-ins explizit via „Require-Bundle“ spezifiziert. Bei einer Applikation kann man davon ausgehen, dass man die Laufzeitumgebung kennt, also ist „Package-Import“ wenig sinnvoll.

Wie kann man nun mit obigem Wissen den Build optimieren? Unser Profiling zeigte uns, dass Eclipse sehr viel Zeit damit verbrachte, für den „Package-Import“ relevante Berechnungen anzustellen und versuchte, Plug-in-Build-Reihenfolgen zu errechnen. Also haben wir in WPoB schlicht einen Task eingebaut, um einen Build-Graphen aufgrund von „Require-Bundle“ auszurechnen und „Package-Import“ komplett ignoriert. WPoB macht also das gleiche, wie Eclipse selbst auch: Es ruft die entsprechende Build-Methode auf jedem Plug-in in dem Graphen auf. Ein positiver Nebeneffekt ist, dass WPoB mit ein bisschen Extrawissen nun alle unsere Generatoren an den richtigen Stellen im Graphen platzieren und automatisiert aufrufen kann. Der gesamte Graph kann in weit unter einer Sekunde errechnet werden.

Mit der Einführung von WPoB konnten wir die Zeit für einen sauberen Workspace Build von etwa 50 Minuten auf ungefähr fünf vollautomatisierte Minuten reduzieren. Ganz nebenbei haben wir dann den Ant-basierten Nightly Build verschwinden lassen, da WPoB auch von der Kommandozeile aus funktioniert  – und zwar noch viel schneller als Ant. Auch unsere spätere Umstellung auf Git hat von diesem Schritt profitiert, da das Aufsetzen von Continuous Integration Builds nur noch erfordert, das richtige Eclipse zu installieren und WPoB von einem Jenkins-Task aus aufzurufen.

Umstellung auf Git und Gerrit

Die sehr erfolgreiche Umstellung auf Git und Gerrit ist eine andere Geschichte. Die damit einhergehenden Verbesserungen sind jedoch sehr wichtig gewesen. Wir hatten auch schon davor ein Tool entworfen, um Projekte im Workspace zu organisieren; dieses wurde allerdings mit der Umstellung auf Git rundum erneuert. Es handelt sich um ein relativ einfaches Werkzeug, welches

  • es einem erlaubt, sehr einfach das richtige Repository zu klonen und den richtigen Branch auszuchecken
  • eine spezielle Datei auf dem eben ausgecheckten Branch liest und daraus Informationen zieht, welche Projekte in welche Working Sets in den Workspace importiert werden sollen
  • es einem erlaubt, die gewünschten Working Sets, unter Berücksichtigung von Abhängigkeiten unter Plug-in-Gruppen, auszuwählen
  • bei einem Branch-Wechsel (auch rebase, merge etc.) die Plug-ins und Working Sets im Workspace basierend auf vorheriger Auswahl aktualisiert und synchronisiert

Somit verursachte das Aufsetzen eines Workspace und auch das Aktuellhalten des Inhalts beinahe keinen Aufwand mehr. Am Anfang muss lediglich ausgewählt werden, woran gearbeitet wird. Dadurch hatten alle Entwickler auch einen identisch aufgesetzten Workspace.

Zentrale Verwaltung von Eclipse

Vor einigen Jahren waren wir auf der Suche nach einer Lösung für das Deployment unserer Applikation und entschieden uns dafür, Genuitec SDC („Secure Delivery Center“) einzusetzen. Diese Software, die selbst auf Eclipse basiert, beschäftigt sich damit, angepasste Eclipse-Set-ups zu verwalten, Installations-Wizards dafür zu bauen, die Eclipse-Installationen mit Updates zu versorgen und etwaige Richtlinien zu erzwingen (Abb. 3).

Diese zentrale Verwaltung erlaubt es uns, vorkonfigurierte Eclipse-Installationspakete zur Verfügung zu stellen, die sich ohne Mühe installieren lassen. Bei uns wird Eclipse immer gemeinsam mit dem Softwarerelease eingefroren – und zwar das gesamte Eclipse, inklusive aller externen Bibliotheken und Konfigurationen. Daher gibt es schon eine Menge unterschiedlicher Versionen, aus denen sich die Entwickler die richtige aussuchen können. Beim ersten Launch auf einem leeren Workspace startet jede dieser vorkonfigurierten Eclipse-Varianten automatisch einen Set-up-Prozess, der den Workspace für unsere Bedürfnisse vorbereitet.

Abgesehen von einer einfachen initialen Installation ist es aber auch wichtig, bestehende Installationen aktuell zu halten. Sogar Konfigurationsänderungen können noch im Nachhinein als Update an alle Installationen verteilt werden.

Abb. 3: Secure Delivery Center zur Verwaltung von Eclipse

Abb. 3: Secure Delivery Center zur Verwaltung von Eclipse

Xtext-basierte Modellierung

Ein Thema, das ebenfalls stark in die Laufzeitumgebung hineinspielt, ist die Modellierung und der daraus generierte Code, der auf Teilen der Laufzeitumgebung und unserer eigenen Plattform aufbaut. Der modellgetriebene Ansatz hat bei uns Geschichte; schon unsere C/C++ basierte Vorgängerversion von WAMAS hat diesen Ansatz sehr erfolgreich verfolgt. Daher wurde die Technologie komplett übernommen – nicht nur zu unserem Vorteil. Die Software zur Modellierung war schon etwas veraltet und verlangte noch Java 5, während WAMAS schon Java 8 sprach. Upgraden konnten wir nicht, da diese Version des Tools die letzte war, die noch UML 1 speichern konnte. Außerdem hatten wir nach dem Umstieg auf Git mit konzeptionellen Problemen zu kämpfen. Die binären UML-Modelle (.xml.zip) wurden in einer externen Versionsverwaltung untergebracht. Daher mussten alle Branches gespiegelt und die Modelle kopiert werden – leider ohne eine Möglichkeit, sie wieder zu mergen, was es damals einfach noch nicht gab. Erschwerend kam hinzu, dass die Versionsverwaltung ausschließlich mit Pessimistic Locking arbeitete. Also war gleichzeitiges Bearbeiten eines Modells unmöglich.

Es war zudem niemals klar, zu welchem Zeitpunkt das binäre Modell in die Versionsverwaltung eingecheckt werden sollte. Wenn die dazugehörige Codeänderung auf unseren Gerrit gepusht wurde? Oder wenn die Codeänderung am Gerrit submitted und somit auf den Zielbranch gemerged wurde? Beides hat Vor- und Nachteile, und keine Lösung ist zufriedenstellend.

Abgesehen von diesen Problemen waren unsere Modelle vollgepackt mit Tagged Values (im Prinzip Freitext-Key-Value-Paare, um Metadaten zu hinterlegen) und Stereotypen. Das war nötig, um applikationsspezifische Metadaten unterzubringen, die sich im generierten Code niederschlugen.

Der Plan, unsere UML-Modelle abzulösen, existierte relativ lange, wurde allerdings etwas aufgehalten, weil wir aus den UML-Modellen sehr leicht Modelldokumentationen exportieren konnten. Wir konnten Diagramme automatisiert exportieren, und schon war der HTML-Report fertig. Eine Patentlösung für einen Ersatz bei textbasierten Modellen hatte zu dem Zeitpunkt niemand. Bei unserem Umstieg auf Xtext standen wir deshalb vor folgenden Aufgaben:

  • Textbasierte DSL mit einfach zusammenführbarer Syntax. Jeweils eine eigene DSL für Datenbank- und Prozessmodelle (State Machines).
  • In die Sprache eingebaute Konzepte, um Metadaten ausdrücken zu können, die relevant für Generatoren und Laufzeit sind.
  • Automatisierte Generierung von Modelldokumentation, die eine grafische Repräsentation der Modelle beinhält.

Umgesetzt wurde dies mit einer Kombination aus Xtext/Xtend und GEF/Zest. Die Sprache mit Xtext und Xtend selbst zu entwickeln, hat sich als leichter als gedacht erwiesen. In die Sprache fix eingebaut ist ein kleiner Teil, der es erlaubt, Diagramme auf einfache Weise zu definieren, indem einzelne Nodes (Klassen, Strukturen, Typen) relativ zueinander positioniert werden können. Zest verwenden wir, um diese in die Sprache integrierte Layoutinformation in Diagramme umzusetzen. Für persistente Klassen, die in keinem Diagramm vorkommen, kann sogar ein (sehr einfaches) Diagramm automatisch generiert werden, das die ein- und ausgehenden Assoziationen visualisiert (Abb. 4).

Abb. 4: DSL zum Beschreiben von Datenbank plus DSL zum Spezifizieren von Diagrammen

Abb. 4: DSL zum Beschreiben von Datenbank plus DSL zum Spezifizieren von Diagrammen

Laufzeitumgebung und Plattform

Wir verfolgten für unsere IDE und die RCP-Plattform immer die Strategie, möglichst nahe an Eclipse-Releases zu bleiben. Bis zu einem gewissen Zeitpunkt in der Geschichte von Eclipse hatten wir auch keine eigene Target Platform, sondern verwendeten das laufende Eclipse als Target. Das hat einige Nachteile, die uns bis dahin allerdings nicht besonders getroffen hatten. Mit dem Umstieg auf Eclipse 4.2 hatten wird dann allerdings einige kleine technische Schwierigkeiten.

Welche Probleme dies im Detail waren, ist nicht so wichtig. Viel wichtiger ist, dass wir uns entschieden, als IDE und Target Platform zwei unterschiedliche Eclipse-Versionen zu verwenden. Die IDE wurde Version 4.2, die Target Platform blieb auf 3.x. Somit brauchten wir erstmals eine wirklich sauber definierte Target Platform. Leider ist das Handling von Target-Plattformen in Eclipse nicht immer einfach. Von Problemen im Editor, der leider die Auswahl viel zu häufig vergisst, bis hin zu nicht reproduzierbaren, sporadischen Fehlern beim Auflösen des Targets kam alles vor.

Wesentlich besser wurde die Situation erst vor Kurzem. Mit dem ebenfalls frei verfügbaren „Target Platform Definition DSL and Generator“ können wir heute unsere Targets äußerst komfortabel definieren und auch verwalten. Die Standard-Target-Platform liefern wir heute sogar mit unseren Eclipse-Installationen mit, um unnötige Remotezugriffe und Downloads zu vermeiden.

Der einzige Punkt in unserer Technologielandkarte, der bis vor Kurzem noch nicht ins Bild passte, war unser synchrones RPC-Framework: RMI. Leider passen RMI und OSGi nicht gut zusammen, weswegen wir einige Workarounds brauchten, um RMI zufriedenstellend zum Laufen zu bringen. Übrig blieb noch das Problem, dass man pro Servermaschine eine eigene RMI Registry betreiben muss. Dies passte leider schlecht in unsere Architektur und beeinträchtigte die Skalierbarkeit stark. Statt eines weiteren Workarounds entschieden wir uns dafür, einen Ersatz zu suchen und haben unser RPC-Framework auf Basis von ECF Remote Services neu aufgestellt.

ECF löst für uns beide genannten Probleme und bringt uns sogar noch einige neue Features bzw. leichte Vorteile im Handling gegenüber RMI. Ein kleiner Unterschied zwischen den beiden Technologien besteht in der Konfiguration. Während RMI über die RMI Registry ausschließlich dynamisch konfiguriert wird, wird bei ECF der OSGi-Blueprint-Ansatz favorisiert, d. h. eine Konfiguration über XML-basierte Beschreibungen. Unsere Architektur verlangt nach der Dynamik, die uns RMI zur Verfügung gestellt hatte. Aufbauend auf ECF und unserer bereits bestehenden Infrastruktur haben wir eine „ECF Registry“ für Service Discovery erstellt. Diese ECF Registry erlaubt es uns, unsere Services dynamisch auf Prozesse und jetzt auch über Servergrenzen hinweg auf Maschinen zu verteilen. Somit lässt sich unsere Applikation besser skalieren.

Deployment, Verteilung, Wartung

Wie schon erwähnt, verwenden wir auch für unsere Serverapplikationen Eclipse RCP als Plattform, statt auf einen Enterprise Application Server zu setzen. Um diese Serverapplikationen (und auch die Clientapplikationen) sinnvoll bei einem Kunden in Betrieb nehmen zu können, braucht man natürlich auch eine Deployment-Strategie. Hier hält sich RCP komplett raus. Man kann zwar RCP-Produkte zu .ZIP-Archiven zusammenpacken, aber das ist keine ernstzunehmende Strategie, um hunderte Set-ups durchzuführen und aktuell zu halten – ganz zu schweigen vom Starten/Stoppen und Monitoring der Applikationen.

Um dem Problem Herr zu werden, hatten wir Anfangs einen eigenen „AppServer“. Er war in der Lage, aus losen Plug-ins und Features Serverapplikationen zusammenzusetzen, diese zu konfigurieren, zu starten/stoppen und sehr rudimentär zu überwachen. Einzige Kritikpunkte waren damals die Performance (es dauerte etwa eine Stunde, um einen Server vollständig aufzusetzen) und der Umstand, dass der Desktopclient zum Herunterladen in Form der oben angesprochenen .ZIP-Archive zur Verfügung stand, also keine Verbesserung in Bezug auf die Updatefähigkeit mit sich brachte.

Nach einigem Hin und Her stießen wir auf SDC, das ich schon als Verwaltungsplattform für unsere IDE vorgestellt habe. SDC hat eine auf Eclipse P2 basierte Engine, in die schon sehr viel Arbeit geflossen ist und die dementsprechend zuverlässig funktioniert. Nach etlichen Telefonkonferenzen hatten wir uns mit Genuitec geeinigt, SDC anzupassen und mit einigen Erweiterungen unsererseits zu versehen. Somit war SDC in der Lage, sämtliche Aufgaben unseres alten „AppServers“ zu übernehmen – nur schneller. Statt der bisherigen Stunden brauchte SDC nur noch wenige Minuten für ein komplettes Set-up. Was eigentlich der ursprüngliche Hauptgrund für die Migration war, wurde zum netten „Goodie“: ein Installations-Wizard für unsere Applikationen.

Unsere Erweiterungen für SDC erlauben es uns, eine WAMAS-Installation mit wenigen Mausklicks vorzunehmen und auch sehr tiefgreifende Parametrisierung schnell und einfach einzustellen. Auch das Starten/Stoppen und Überwachen unserer RCP-Server-Applikationen ist möglich (Abb. 5).

Abb. 5: Erweiterung der IDE um Managementfunktionen für produktive Anlagen

Abb. 5: Erweiterung der IDE um Managementfunktionen für produktive Anlagen

Fazit

Eclipse skaliert. Wir können mit Eclipse skalieren. Nicht nur jetzt, sondern auch in Zukunft sind wir zuversichtlich, auf die richtige Plattform gesetzt zu haben. Eine wichtige Erkenntnis war sicherlich, dass es sich sehr auszahlt, in Eclipse (als IDE und Plattform) zu investieren. Denn an Eclipse arbeiten Entwickler, die sich damit beschäftigen, die Welt für alle anderen Entwickler besser zu machen. Leider gibt es keine Allgemeinlösung für sämtliche Programmierer. Ich hoffe dennoch, dass einige der in diesem Artikel vorgestellten Lösungen Sie zu eigenen Skalierungsverbesserungen inspirieren konnten.

Verwandte Themen:

Geschrieben von
Markus Duft
Markus Duft
Markus Duft arbeitet seit über zehn Jahren als Entwickler und Architekt für SSI Schäfer in Österreich an weltweit eingesetzten Intralogistiklösungen. Sein Hauptaufgabenbereich ist die Entwicklungsumgebung, Infrastruktur und Applikationsplattform, wo er täglich mit einem breiten Spektrum an Eclipse-Technologien arbeiten darf.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: