Zum vollständigen Presseartikel

Stardust - eine vollstandige BPM-Suite
in Eclipse
Simone Seurer, Herbert Neureiter, Sven Rottstock, Jan Hendrik Scheufen, Marc Gille
Business Process Management-Suiten (BPMS) sind längst Bestandteil von
Unternehmensplattformen. Mit Stardust steht in der Eclipse Kepler-Release eine vollständige und
industrieerprobte BPMS mit Modellierung, Prozessausführung, Simulation, Monitoring und
Reporting eingebettet in Eclipse und unter der Eclipse Public License zur Verfügung.
Markt und Historie
Lange schon gibt es Initiativen um Anwendungsaspekte wie Workflow, Service-Orchestrierung,
Dokumentenverarbeitungen nicht anwendungsspezifisch zu codieren, sondern als generische
Systemkomponente bereitzustellen und über graphische Repräsentation der entsprechenden
Geschäftsprozessmodelle idealerweise durch die Fachabteilung selbst zu konfigurieren. Anfang des
Jahrtausends hat sich für diesen Ansatz der Oberbegriff Business Process Management (BPM)
etabliert. Hersteller wie IBM, ORACLE und SAP liefern schon seit einigen Jahren Business Process
Management-Suiten (BPMS) als Bestandteil ihrer Technologieplattformen Websphere, Fusion und
Netweaver aus. Rudimentäre Workflow-Funktionalität ist über die Microsoft Workflow Foundation
Bestandteil der .NET-Technologie.
Der Markt an Open Source Systemen ist überschaubar: jBPM [jBPM] als Bestandteil des Red
Hat/JBoss-Portfolios existiert bereits längere Zeit, ursprünglich allerdings als reine BPM EngineImplementierung mit Programmierschnittstelle und nur rudimentären Endbenutzer- und
Oberflächenkomponenten. Einer der beiden Hauptentwickler von jBPM, Tom Bayens, hatte JBoss im
Streit um Lizenzfragen verlassen und das Projekt Activiti [Activiti] innerhalb der Alfresco-Organisation
[Alfresco] initiiert. Auch Activiti hat Tom Bayens jüngst wieder verlassen und arbeitet nun an Effektif
[Effektif], einem Cloud-Angebot für BPM. Das Berliner Unternehmen Camunda führt einen eigenen
Branch von Activiti als Camunda Fox weiter [Camunda Fox]. Eine weitere Open Source BPMS steht
mit Bonitasoft [Bonitasoft] zur Verfügung, ist aber nur bedingt in offene Plattformen integriert. All
dies zeigt die Volatilität des Open Source Marktes für BPM und macht es schwer für Unternehmen,
sich auf diese Technologien für einen wesentlichen Bestandteil ihrer IT-Infrastruktur zu verlassen.
Auch wenn die grundsätzliche Haltung zu Open Source-Produkten offen und positiv ist, werden für
Kernkomponenten wie BPMS Wartungsvereinbarungen mit entsprechenden Service Level
Agreements (SLAs) benötigt.
Mit Stardust steht nun eine 13 Jahre alte, industrieerprobte, standardkonforme und vollständige
BPM-Plattform unter der Eclipse Public License (EPL) [EPL] zur Verfügung. Ursprung von Stardust ist
die in Deutschland entwickelte CARNOT Process Engine, die von 2000-2006 von der CARNOT AG,
Frankfurt am Main entwickelt wurde. Die CARNOT AG wurde Ende 2006 von dem amerikanischen
Unternehmen SunGard [SunGard], einem führenden Anbieter für Softwaresysteme und Dienste im
Finanzdienstleistungsbereich, übernommen. Bei SunGard wurde die CARNOT Process Engine zum
Rückgrat von SunGard’s Infrastruktursoftwareplattform Infinity ausgebaut und in Infinity Process
Platform umbenannt. Die Infinity Process Platform wird in über 60 SunGard-Produkten bei weltweit
über 1.600 Kunden eingesetzt. Das Einsatzspektrum reicht von Dokumentenverarbeitungssystemen
mit einigen 100.000 Dokumenten pro Tag, über interaktive Workflows mit Tausenden parallelen
Benutzern bis hin zu skalierbaren Niedriglatenzanwendungen mit Tausenden von Prozessen in der
Sekunde.
SunGard stellt seit 2010 die Codebasis der Infinity Process Platform unter der Eclipse Public License
(EPL) [EPL] quelloffen zur Verfügung. Mit fast 3 Millionen Zeilen Code ist Stardust einer der größten
Codebeiträge in der Geschichte von Eclipse und ein signifikanter Bestandteil der insgesamt 58
Millionen Codezeilen der Kepler-Release.
Anders als für viele andere Open Source-Produkte ist das Ziel der Stardust-Initiative für SunGard
Offenlegung, Verbreitung und Weiterentwicklung der eigenen Basistechnologie. SunGard bietet
Wartungsverträge und Cloud-basierte Laufzeitumgebungen an, nicht aber zusätzliche kommerzielle
Produktkomponenten: Stardust ist die vollständige und aktuelle Codebasis der Infinity Process
Platform.
Stardust ist Teilprojekt des SOA Platform Top Level-Projektes [SOA Platform] in Eclipse; Kollaboration
und Integration mit anderen Teilprojekten wurde z.B. auf der EclipseCon 2013 vorgestellt [SOA
EclipseCon]. Mit dem Kepler-Release von Eclipse hat Stardust den Übergang von Incubation in den
Release-Status vollzogen und wird als Bestandteil von Kepler ausgeliefert.
Architektur
Stardust erlaubt komplette Modellierung und Konfiguration von Geschäftsprozessen mit Aktivitäten,
Kontrollfluss, Daten und Datenfluss, Anwendungsintegration sowie Geschäftsprozess-Teilnehmern
über die BPMN-Notation [BPMN] in einer in Eclipse eingebetteten Modellierungsumgebung. Nichtinteraktive Dienste (z.B. Methoden von Java-Klassen oder Spring Beans, Web/REST Services), Scripts
(z.B. Datentransformation) und interaktive Elemente (z.B. HTML5-Oberflächenbausteine) sowie
Datenstrukturen (z.B. Java-Klassen, XSDs) können in ein und derselben Umgebung definiert und
verwendet werden. Hierbei sind Basismechanismen von Eclipse wie Refactoring, Referenzsuche,
Debugging und automatische Validierung durchgängig integriert.
Diagramm 1: Stardust-Modellierungsumgebung
Die Prozessmodelle werden zur Zeit noch in XPDL [XPDL] abgelegt, eine Umstellung auf BPMN
Serialisierung [BPMN] ist in Arbeit. Zur Anwendungsintegration existieren fertige Konnektorbausteine
(z.B. für Web/REST Services oder Spring Beans). Stardust orientiert sich jedoch immer mehr an
Apache Camel [Camel] als Standard für Konnektivität: Events und Serviceaufrufe können direkt über
im Prozessmodell eingebettete Camel Routes definiert werden. Somit wird zur Systemanbindung
häufig kein weiterer Code benötigt; das Prozessmodell ist das einzige Deployment-Artefakt, was die
Verwaltung des Anwendungslebenszyklus erheblich vereinfacht.
Stardust besitzt eine sehr leistungsfähige Simulationskomponente mit der Vorhersagen über das
Laufzeitverhalten von Prozessen oder Auslastung von Systemen und Mitarbeitern getroffen werden
können. Hierzu werden entweder stochastische Eigenschaften wie Prozessrate über die Zeit oder die
Verteilung der Dauern von Aktivitäten angegeben. Diese Eigenschaften können auch von
bestehenden Laufzeitdaten abgeleitet werden. Die Simulation erfolgt transient im Hauptspeicher und
erlaubt somit die Berechnung von Vorhersagen „über Jahre in Sekunden“. Die Simulationsergebnisse
werden graphisch und tabellarisch angezeigt (Diagramm 2). Ebenso kann die Simulation reale
Laufzeitdaten erzeugen, die dann mit bisherigen Laufzeitdaten und der Reporting-Komponente zu
Soll/Ist-Vergleichen genutzt werden können.
Diagramm 2: Stardust Simulationsumgebung
Die Laufzeitumgebung für Stardust ist ein EJB oder Web Application/Spring-Container (Application
Server) sowie eine relationale Datenbank (Audit Trail Database) und ein Dokumenten-Repository auf
Basis von Apache JackRabbit [JackRabbit]. Stardust integriert sich hierbei in die Mechanismen der
Application Server, so dass Transaktionsmanagement, Clustering und Failover, Ressourcen
Management durchgängig verwendet werden und skalierbare, robuste Konfigurationen möglich sind.
Zur schnellen Entwicklung und Validierung bietet Stardust eine in Eclipse eingebettete
Laufzeitumgebung auf Basis von Apache Tomcat und Derby an, die fertig konfiguriert über eine
Dynamic Web Project Konfiguration zur Verfügung steht. In diese Umgebung können in Eclipse
entwickelte Prozessmodelle direkt deployt und Laufzeitfunktionalität (z.B. Browserportale oder Web
Service/REST-Schnittstellen) aufgerufen werden.
Diagramm 3: Stardust-Architektur
Stardust stellt für den Zugriff auf Modell- und Laufzeitdaten Open Data Access (ODA)-Datenquellen
und dazu Konfigurationsoberflächen zur Verfügung, die sich nahtlos in die Business Intelligence and
Reporting-(BIRT)-Umgebung in Eclipse [BIRT] einbetten lassen. So können in BIRT Reports auf
Prozess- und in Prozessen bearbeitete Daten definiert werden.
Diagramm 4: Stardust Reporting
Einige Eigenschaften der oben aufgeführten Komponenten sind produktionskritisch und nur teilweise
und unzureichend bei anderen Open Source BPMS vorhanden, z.B.





Skalierbare, ausfallsichere Architektur mit clusterfähigen Caching-Funktionen,
Mandantenfähigkeit zur Unterstützung logisch unabhängiger Instanzen in derselben
Application Server und Datenbankinstallation,
Hot Deployment von Modellen für 24 x 7 Betrieb,
Parallele Verwaltung und Deployment verschiedener, ggf. voneinander abhängiger
Prozessmodelle, um verschiedenen Entwicklungs- und Endanwender-Teams unabhängiges
Arbeiten mit einer und derselben Laufzeitumgebung zu ermöglichen, aber dennoch eine
Gesamtübersicht für das Management zu liefern und
Parametrierbarkeit der Laufzeitumgebung, um beim Übergang zwischen Test-, Abnahmeund Produktionsumgebung schnell und ggf. per XML-Konfiguration Aspekte wie Web
Service/REST-Endpunkte oder Mail Server-Adressen umzuschalten zu können
Die ersten Schritte
Stardust ermöglicht es, mit erdenklich wenig Aufwand, die ersten Gehversuche zu wagen und
Ergebnisse zu erzielen, indem sowohl die Modellierungs- als auch eine Laufzeitumgebung als Teil der
Eclipse Plug-Ins zur Verfügung stehen.
Download
Um Stardust auszuprobieren wird lediglich eine Version der Eclipse Kepler IDE benötigt (die beim
Verfassen dieses Artikels verfügbare Version ist RC3), auf deren Basis die Stardust Plug-Ins und
andere Abhängigkeiten direkt von der Kepler Update Site installiert werden können.
Nach dem ersten Start der Eclipse Kepler IDE wird hierzu über den Update Manager (Help  Install
New Software …) die Kepler Update Site im Drop-Down Menü Work With ausgewählt
(http://download.eclipse.org/releases/kepler) und die folgenden Features werden installiert:
-
-
In der Rubrik Business Intelligence, Reporting and Charting sollte zunächst das BIRT
Framework ausgewählt werden. Diese Komponente ist Voraussetzung für die ReportErstellungs-Funktionen in Stardust.
Unter SOA Development finden sich die Features für Eclipse Process Manager ..., die der
Einfachheit halber alle selektiert werden sollten (s. Diagramm ).
Diagramm 5: Installation der Stardust Features
Nach einem Neustart der Eclipse IDE stehen nun alle Stardust Funktionen zur Verfügung.
Siehe auch [Installation] für eine detailliertere Form der hier beschriebenen Installationsschritte.
Setup
Die Stardust Plug-Ins beinhalten eine Integration mit dem WTP (Web Toolkit Project) von Eclipse, die
als Rapid Application Development bezeichnet wird. Diese Variante einer Laufzeitumgebung besteht
aus einer Plattform aus Tomcat Server und Derby Datenbank, die beide innerhalb des Eclipse
Workspace verwaltet werden. Die Stardust Engine und das Web Portal werden über ein Dynamic
Web Application Projekt auf dieser Plattform zum Einsatz gebracht.
Das Einrichten dieser Umgebung ist im Detail in der Dokumentation beschrieben [Stardust
Documentation] und ebenfalls Teil der Stardust Tutorials, die als Cheat Sheets zur Verfügung stehen
(Help -> Cheat Sheets … -> Process Manager -> Process Manager Cheat Sheets (s. Fehler!
Verweisquelle konnte nicht gefunden werden.).
Diagramm 6: Installation der Stardust Features
Tomcat Server Setup
Die Installation eines Tomcat Servers (Version 6.x) erfolgt ganz regulär im Eclipse Servers View oder
per File  New  Other  Server. Lediglich ein wenig Extra-Konfiguration im Properties Editor des
Servers ist hiernach noch notwendig, bevor der Server eingesetzt werden kann.
1. Unter Open Launch Configuration  Arguments sollte dem Server etwas mehr HeapSpeicher und auch PermGenSpace zur Verfügung gestellt werden, z.B. -Xms768m –
XX:MaxPermSize=256m.
Diese Werte stellen eine praxis-erprobte Standard-Konfiguration dar, die den meisten realen
Einsatzszenarien für Stardust genügen sollte.
2. Ebenfalls im Properties Editor des Servers wird von Stardust eine zusätzliche Sektion namens
Audit Trail Datasource hinzugefügt, die das Erzeugen einer eingebetteten Derby DB
ermöglicht, die mit dem Server hochgefahren wird.
Dynamic Web Application Projekt
Durch die bereits erwähnte Integration von Stardust mit dem WTP kann beim Anlegen eines Dynamic
Web Application Projekts in der Konfigurationsauswahl die Option Stardust Portal selektiert werden,
die dem Projekt Stardust-spezifische Facetten beisteuert.
Nach Ausführung dieser Schritte steht im Workspace ein Web Projekt mit allen Stardust-Artefakten
zur Verfügung, dass über das Kontext-Menü des Tomcat Servers per Add and Remove … publiziert
werden kann. Nach Starten des Servers ist die Login-Seite des Stardust Portals unter der URL
http://localhost:8080/stardust-portal zu erreichen.
Beispielprojekt
Um einen Einblick in die Funktionen und Fähigkeiten der Stardust BPMS zu geben, wollen wir in
diesem Artikel ein Beispielprojekt vorstellen, dass sich sehr nah am Support Case Tutorial (s. auch
Cheat Sheets oben) orientiert. Das Ergebnis des Support Case Tutorials kann unter [Support Case]
heruntergeladen werden.
Die folgenden zwei Bereiche sollen vermittelt werden:


Erzeugung eines Prozess Modells mit grundlegenden BPMN Elementen wie
Aktivitäten, Daten-Objekten, Services, Benutzerrollen, etc.
Hochladen eines Prozessmodells in die Laufzeitumgebung und Ausführen von
Prozessinstanzen.
Als ersten Schritt erzeugen wir innerhalb des Web Projekts ein neues Prozessmodell via File  New
 Other  Process Manager Wizards Process Model und nennen es ACME Support Case Model.
Bei Abschluss des Dialogs wird die Datei ACMESupportCaseModel.xpdl angelegt und das Modell
automatisch im Modell Editor geöffnet. Neben dem Model Editor zur grafischen Modellierung ist die
Eclipse Outline View ein entscheidendes Instrument bei der Erstellung des Prozessmodells (s.
Diagramm 9).
Datenmodell
Als nächstes wenden wir uns der Erstellung eines geeigneten Daten-Modells zu: Als Datentyp wurde
der sogenannte Structured Data Type gewählt, der es ermöglicht, im Modell eine DatentypHierarchie aufzubauen. Die Datentyp-Definitionen werden als XML Schema Elemente (Complex
Types) im Modell abgelegt. Auch der Import oder das Referenzieren externer, bereits existierender
XSDs wird unterstützt. All diese Funktionen sind über die Outline View erreichbar (s. Diagramm 7).
Diagramm 7: Outline View mit Prozessmodell
Fehler! Verweisquelle konnte nicht gefunden werden. zeigt das simple Datenmodell, das unserem
Support Case Beispiel zugrunde gelegt wird.
Diagramm 8: Datenstrukturdefinition
Das Prozessdiagramm
Nach der Definition der Datenstrukturen kann innerhalb des Modell Editors der Prozess- und
Datenfluss zusammengesetzt werden. Hierzu werden aus der Palette links im Editor die Elemente
angewählt und durch einen weiteren Klick im Diagramm platziert. Das vielseitige Connect erlaubt es,
sowohl den sequentiellen Fluss zwischen den Aktivitäten, als auch den Datenfluss (Input/Output)
jedes einzelnen Schrittes zu modellieren.
Wir erzeugen und platzieren die folgenden Elemente im Diagramm:

Support Case Data-Datenobjekt (eine Instanz der zuvor definierten Struktur)



Aktivitäten: Enter Data, Analyze To Solve, Deliver Patch und Notify Customer
Rollen: Callcenter Agent, Engineer, ACME Headquarters
Manueller Trigger zum Starten des Prozesses aus dem Portal heraus
Diagramm 8 zeigt das fertige Prozessmodell.
Diagramm 9: Prozessdiagram eines simplen Support Case Prozesses
Der Ablauf des Prozesses ist relativ selbsterklärend. Die folgenden Punkte sollen allerdings
herausgestellt werden:
-
-
Alle Aktivitäten außer Notify Customer sind sogenannte User Tasks, d.h. interaktive Schritte,
in denen ein Benutzer mit der notwendigen Gruppenzugehörigkeit (z.B. Engineer) den Task
über ein (Web-) Formular bearbeitet und abschließt.
Nach der Analyze To Solve Aktivität wird ein XOR Gateway eingesetzt, um über die
Bedingungen an den Transitionen den Weg hin zu Folgeaktivitäten zu steuern.
Das Symbol Customer Email repräsentiert den Aufruf einer Java Klasse, die in Stardust als
POJO Applikation konfiguriert wurde.
Für die interaktiven User Tasks ist ein grafisches User Interface notwendig, damit der Benutzer die
Daten des Prozesses einsehen und bearbeiten kann. Im Falle der manuellen Aktivitäten generiert
Stardust automatisch Formulare mit Feldern und Input Elementen basierend auf den verwendeten
Datentypen und weiteren Metadaten, die das Aussehen des Formulars beeinflussen.
Für Fälle, bei denen die so generierten UIs nicht den Ansprüchen gerecht werden, kann die Manuelle
Aktivität durch eine UI Mashup Aktivität ausgetauscht werden, die es erlaubt, jede Form einer
externen UI als Formular für den User Task einzubinden, z.B. JSF, PHP, ASPX, HTML5, etc.
Diagramm 10 zeigt die automatisch generierte UI für die Enter Data Aktivität.
Diagramm 10: Automatisch generiertes Formular ausgehend von den Prozessdaten
Integration von projektspezifischem Code
Wie bereits erwähnt wird in der Aktivität Notify Customer die Methode einer Java Klasse als Service
aufgerufen und die Kunden-Emailadresse wird als Parameter in den Methodenaufruf hineingegeben.
Zur Konfiguration der Klasse muss der Editor diese auf dem Klassenpfad finden können, den Eclipse
für das umgebende Projekt bereitstellt.
Diagramm 11: Einbindung von Java Code als POJO Applikation
Das Modell wurde zwar innerhalb des Web Projekts gespeichert, dennoch sollte für den Java Code
ein weiteres Projekt als JEE Utility Module angelegt werden, da es auf diese Weise sehr leicht dem
Web Projekt im Properties Panel Deployment Assembly hinzugefügt werden kann. Außerdem
werden hierdurch Stardust-Produktcode und projektspezifischer Code sauber voneinander getrennt.
Einsatz des Prozessmodells
Bei Einsatz eines Rapid Application Web Projekts kann das Prozessmodell direkt aus der Outline View
auf den Server geladen werden (Rechts-Klick auf das Top-Level Element  Deploy Model. Der
Deployment Wizard kennt automatisch die Remoting Adresse des Stardust Portals, solange sich das
Model innerhalb des Web-Projekts befindet.
Prozess Portal
Nachdem das Prozessmodell in der Web Applikation eingespielt wurde, kann man sich als
Administrator anmelden und in der Administrations-Perspektive im Participant Management View
Nutzer anlegen und Rollen zuweisen.
Durch Zuweisung der Rolle Callcenter Agent wird z.B. die Autorisierung erteilt, einen Support Case
Prozess ad-hoc zu starten. (Zur Erinnerung: das Prozessdiagramm enthielt einen manuellen Trigger,
der für diese Rolle konfiguriert ist). Nach Starten eines Prozesses wird die erste Aktivität angesteuert
und da diese ebenfalls von jemandem mit der Rolle Callcenter Agent bearbeitet werden darf, öffnet
das Portal automatisch das Formular mit automatisch generierten Feldern für die Aktivität Enter
Data (s. Diagramm 9).
Ressourcen
Releaseplanung
Das erste Release 1.0 des Projekts Stardust wurde am 26.06.2013 als Teil des Kepler Release Trains
veröffentlicht und unterstützt dementsprechend die aktuellste Version 4.3.0 der Eclipse Plattform
wie auch die aktuellsten Versionen der zur Installation von Stardust benötigten Features und Plugins
wie zum Beispiel EMF 2.6.0, GEF 3.9.0 und BIRT 4.3.0.
Künftig wird das Projekt Stardust neben den jährlichen Hauptreleases auch an den SR1 und SR2
Wartungsreleases im September und im Februar des Folgejahres teilnehmen. So wird sichergestellt,
dass kontinuierlich neue Funktionalitäten und Bug Fixes veröffentlicht werden können und die
Kompatibilität zu den aktuellen Eclipse Versionen gegeben ist. Die Release Planung ist unter
http://projects.eclipse.org/projects/soa.stardust für alle Interessierten verfügbar.
Informationsquellen für Anwender
Neben den Download Servern für Produktreleases und Quellcode (siehe auch Abschnitte zu
Installation und Arbeiten am Quellcode) stehen Anwendern vielfältige Informationsquellen zur
Nutzung von Stardust zur Verfügung, die den Einstieg erleichtern.
Die Eclipse Stardust Projektseite https://projects.eclipse.org/projects/soa.stardust bietet schnellen
Zugriff auf Projektressourcen wie zum Beispiel Download Links, Release Planung, Quellcode,
Statistiken und vieles mehr.
Wer weitergehende Informationen zur Funktionsweise und Benutzung sucht, wird unter
http://wiki.eclipse.org/Stardust fündig:



Der Bereich Knowledge Base enthält zahlreiche Dokumente zu Themen wie Erste Schritte,
Laufzeitumgebungen für unterschiedliche Plattformen, Einbettung in eigene Anwendungen,
und vieles mehr.
Wer sich schon vor der eigentlichen Installation auf einfache Weise einen Eindruck von der
Funktionsweise und den Möglichkeiten des Produkts verschaffen möchte, findet im Bereich
Training Videos kommentierte Videos [Videos] zu vielen Bereichen des Produkts. Wer
anschließend das gesehene vertiefen möchte, findet in der Online Dokumentation
(http://help.eclipse.org/kepler/index.jsp) weitere Informationen.
Falls unvorhergesehene Schwierigkeiten auftauchen sollten empfiehlt sich ein Blick in die
FAQs oder das Forum.
Für Fragen, die sich auf diese Weise nicht beantworten lassen: Das Stardust Team freut sich über
neue Anfragen oder Kommentare im Forum, der Stardust Mailingliste [email protected] oder
über die Facebook Seite https://www.facebook.com/eclipsestardust.
Arbeiten am Quellcode
Stardust hat seinen Quellcode in das Git Repository von Eclipse.org abgelegt, das über
http://git.eclipse.org/c/stardust einsehbar ist. Wer Stardust selbst kompilieren oder anpassen
möchte, kann sich die Quellen mit einem Git Client auf seinen Rechner clonen. Hierfür stehen eine
Reihe von Programmen zur Verfügung, wie z.B. das EGit Eclipse Plugin, TortoiseGit oder msysgit. Da
sich die Quellen über mehrere Git Repositories erstrecken, empfiehlt sich das Skript aus
http://wiki.eclipse.org/Stardust/Source_Code#Downloading_the_Source_Code zu verwenden. Um
anschließend das Projekt kompilieren zu können, muss ein JDK 1.6 und Maven in Version 3.0.3 oder
höher installiert sein. Der Build Prozess ist dann in zwei Schritte aufgeteilt. Im Ersten werden die
Basiskomponenten gebaut und im zweiten Schritt werden mittels Maven/Tycho die Plugins und
schließlich das p2 Repository bereitgestellt. Die jeweiligen Projekte lassen sich auch in Eclipse
einbinden, um direkt aus der IDE heraus zu entwickeln und die Änderungen direkt testen zu können.
Problemlösung und Projektbeiträge
Treten beim Arbeiten mit dem Quellcode Probleme auf, die auch unter Zuhilfenahme der oben
erwähnten Ressourcen nicht gelöst werden können, wäre die Eclipse Bugzilla Instanz
(https://bugs.eclipse.org/bugs/) möglicherweise einen Blick wert. Eine Suchanfrage für das Projekt
SOA/Stardust führt den Benutzer zu einer Liste der gemeldeten Fehlerberichte und
Änderungswünsche. Eventuell ist das beobachtete Verhalten ja bereits bekannt oder die gewünschte
Änderung bereits eingeplant. Falls nein, kann dort ein neuer Fehlerbericht oder Änderungswunsch
eingetragen werden.
Eigene Änderungen am Stardust Code, die längerfristig relevant und erwartungsgemäß von
allgemeinem Interesse sind, sollten möglichst ans Projekt kommuniziert werden, damit sie
gegebenenfalls in den Hauptversionsstrang eingepflegt und so für alle Benutzern verfügbar gemacht
werden können. Dies dient allen Anwendern, vereinfacht längerfristig aber auch die Projektstruktur
des ursprünglichen Autors, da der geänderte Code nicht mehr lokal gebaut werden muss und bei
künftigen Versionswechseln kein Zusatzaufwand mehr entsteht.
Auch dieser Prozess beginnt üblicherweise mit einem neuen Änderungswunsch oder Fehlerbericht in
Bugzilla. Für die eigentliche Übergabe von vorgeschlagenen Änderungen ans Stardust Projekt wird
wie in vielen Projekten das Code Review Werkzeug Gerrit benutzt. Dieses Werkzeug bietet
Unterstützung für den notwendigen Review durch Stardust Committer und speichert automatisch
alle notwendigen Daten. Eine detaillierte Anleitung findet sich unter
http://wiki.eclipse.org/Stardust/Contributing_via_Gerrit.
Zukunft
Stardust folgt dem Trend immer stärkerer Browser-Orientierung („Development on the Web for the
Web“). Der BPMN 2.0 Browser Modeler wird momentan massiv weiterentwickelt und folgt ähnlichen
Konzepten für die Erweiterbarkeit und Integration wie Eclipse (Extension Points). Die Erweiterungen
können in HTML und JavaScript vorgenommen werden. Zur Zeit werden Komponenten zur
Regelverwaltung (Rules Management) und ein Reporting Wizard in die Browser-Oberfläche
integriert. itPearls [itPearls] hilft mit Arbeiten zur BPMN 2.0-Kompatibilität.
Diagramm 12: Stardust BPMN 2.0 Browser Modeler
Parallel zur Weiterentwicklung des Browser Modelers wird eine Homogenisierung der EclipseModellierungsumgebung mit dem BPMN 2.0 Modeler-Projekt [BPMN Modeler] angestrebt.
Zum Aufbau einer kompletten, ggf. verteilten Web-basierten Entwicklungsumgebung wird Stardust
mit Orion [Orion] integriert [Orion EclipseCon]. Entwickler können so mit Orion Web-Oberflächen,
Anwendungslogik, Geschäftsprozessmodelle und Regelsätze erstellen und deployen.
Weiter existiert ein Teilprojekt für eine Endbenutzer-Oberfläche für mobile Endgeräte auf Basis von
jQuery Mobile [jQuery Mobile]. In all diesen Initiativen werden gerne Committer aufgenommen.
Referenzen
Weblinks
[Activiti] http://www.activiti.org/
[Alfresco] http://www.alfresco.com/
[BIRT] http://www.eclipse.org/birt
[Bonitasoft] http://www.bonitasoft.com
[BPMN] http://www.omg.org/spec/BPMN/2.0/
[BPMN Modeler] http://projects.eclipse.org/projects/soa.bpmn2-modeler
[Camel] http://camel.apache.org/
[Camunda Fox] http://www.camunda.com/fox/product/overview/
[Effektif] http://www.column2.com/2013/03/effektif-bpm-in-the-cloud/
[EPL] http://www.eclipse.org/legal/epl-v10.html
[Installation] http://wiki.eclipse.org/Stardust/Project_Plan/Kepler_RC3
[itPearls] www.itpearls.com
[JackRabbit] http://jackrabbit.apache.org
[jBPM] http://www.jboss.org/jbpm/
[jQuery Mobile] http://jquerymobile.com/
[OMG] http://www.omg.org
[Orion]http://www.eclipse.org/orion
[Orion EclipseCon] http://www.slideshare.net/marcgille7/stardust-orion-integration-orion-soasymposium-eclipse-con-2013
[SOA EclipseCon] http://www.slideshare.net/marcgille7/soa-symposium-eclipse-con-2013
[SOA Platform] http://www.eclipse.org/soa/
[SunGard] http://www.sungard.com
[Support Case]
http://help.eclipse.org/kepler/topic/org.eclipse.stardust.docs.dev/html/examples/tutorials/supportcase/support-case.zip
[Stardust Documentation]
http://help.eclipse.org/kepler/topic/org.eclipse.stardust.docs.dev/html/toc.html?cp=32
[XPDL] http://www.xpdl.org/
Videos
[Videos] http://www.eclipse.org/stardust/documentation/training-videos.php
Simone Seurer ist seit 2001 Mitglied des
CARNOT und später Infinity Process Platform
teams. Mittlerweile beschäftigt sie sich als
Configuration und Release Engineer
hauptsächlich mit der Build-Landschaft von
Stardust.
Dr. Herbert Neureiter ist Produktmanager für
Business Process Management bei der Sungard.
Er beschäftigt sich seit 15 Jahren mit den
Themen Produktmanagement,
Projektmanagement und Qualitätssicherung im
Bereich von J2EE Enterprise Software.
Sven Rottstock ist Senior Java Developer und seit
2006 Mitglied des des Infinity Teams bei
SunGard. Er beschäftigt sich hauptsächlich mit
Build- und JEE-Deployment-Aufgaben.
Jan Hendrik Scheufen stieß 2005 zu SunGard und
betreut seit mehreren Jahren als Senior Solution
Architect den Aufbau komplexer EnterpriseLösungen mit dem Fokus auf BPM, Workflow
und EAI.
Dr. Marc Gille ist Mitgründer der CARNOT AG
und Vater der CARNOT Process Engine. Bei
SunGard ist er für die Infinity Process Platform
verantwortlich. Er ist Project Lead für Stardust
und leitet ebenso das SOA Platform Project in
Eclipse.