Messaging + Workflow Engine

[tabellar]

Hoi tabellar,

Hoi Christian,

A propos "hoi", kommst Du aus der schweizer Ecke? Wenn ja und dann noch Uni, höre ich da die ETH klingeln ??? Dann wären wir gar nicht so weit voneinander entfernt. Da wo ich bin redet man sich auch mit "Hoi" an... Allerdings spricht das "ß" nicht dafür...

na, das hat natürlich zunächst einmal NICHTS damit zu tun, was Du hier schreibst. Es geht dabei schlicht darum ein Dutzend Standaloneprogramme (größtenteils mit Fortran 77) mit grausigem UI zusammenzufassen, vielleicht neuzuschreiben, ggf. neue Algorithmen zu implementieren und mit einem gescheiten (G)UI zu versehen (im Moment sitze ich an einem Misch aus GUI und commandline interface).
Aber ich hätte auch Lust die Verbindung aus Cluster und Meßrechner besser zu gestalten und aus dem Cluster selbst ebenfalls mehr herauszuholen.

Das hört sich doch schon mal gut an. Das ist ja auch genau mein Thema, standalone Programme in einem Gesamtsystem zusammenfassen (Agenten, verteilte Systeme, etc.). Wie sieht denn das im Moment aus bei dir, die Verbindung zwischen Messrechner und Cluster (Datenauswertung?). Wie sehe in etwa eine bessere Verbindung zwischen Cluster und Messrechner aus?

Je mehr ich aber hier lese, desto mehr zweifele ich, ob ich Dich nicht mißverstanden habe und Du eigentlich an etwas ganz Anderem sitzt ... womit ich in dieselbe Kerbe haue, wie meine Vor-Schreiber hier: Das war vielleicht doch etwas unklar.

Nun, die 4 A-Themen oben scheinen Dich ja angesprochen zu haben. Also sind wir auch nicht allzu weit voneinander entfernt. Bei dem, was ich von Dir lese, "höre" ich raus, dass für Dich die Themen "verteilte Systeme", "Skalierbarkeit", "Agenten", Administration mehrerer Rechner in einem Gesamtsystem wahrscheinlich angesprochen haben.

Wie wäre es Du gibst mal einen Link auf eine Webseite, auf der Du das Projekt vorstellst und auch Code präsentierst? Dann würdest Du erst so richtig für Dich tromeln und man würde Dich und Dein Anliegen womöglich besser verstehen.

Wäre das Projekt schon so weit, hätte ich es im "Showcase" Bereich eingestellt, wie es hier eigentlich so üblich ist. Ich habe es deshalb im "Ideen" Bereich abgelegt, weil es in gewisser Form schon noch in der Theorie "geformt" werden muss. Da hoffe ich natürlich auf Anregungen von Euch. Ist der erste vorzeigbare Code im ganzen verfügbar, kommt das Ding in den Showcase Bereich.

Gruss Tabellar

[querdenker]

Nach einigen Anlaufschwierigkeiten meinerseits jetzt erstmal ein paar Fragen an tabellar:
Du erwähntest, das du schon einige Sachen mehr oder weniger zusammengeschrieben hast.
a) welche Bereiche sind das?
b) mit welchen Komponenten hast du sie realisiert?

Hintergrund der Frage ist natürlich folgender: Wenn Teilbereiche schon stehen und mit Komponente X umgesetzt sind, könnte man sich dort schon mal einarbeiten / - lesen. Und an den Stellen, wo noch nichts geklärt ist, könnte man versuchen sich auf eine Komponente zu einigen, bzw man(als einzelner) kann dann auch von vorneherein sagen das einem der Bereich nicht so passt (bei mir z.B. TK).
Oder, um es einfacher zu sagen: Abgleich der Vorlieben zwecks Kompromissfindung.

mfg, querdenker

[CM]

Hoi

was querdenker vorschlägt ist ein ziemlich guter Kompromiss: So weiß man zumindest worüber man redet und kann auch schauen, wohin die Reise geht. Wenn der Sourcecode einigermaßen dokumentiert ist (*winkmitdemzaunpfahl*), sollte man ja etwas damit anfangen können.

Du wirst im Übrigen lachen, tabellar: Ich sitze tatsächlich an einer schweizerischen Tastatur. Und ich habe mich sehr darüber gewundert, daß man in Teilen der Schweiz auch "Hoi" schreibt, aber in Holland zum Beispiel macht man das auch . Und je nachdem in welcher Sprache ich schreibe, schalte ich die Tastatur um: Bei EMails an Schweizer tatsächlich auch auf "eure" Tastatur, denn sonst kann ich mir das "ß" nicht verkneifen . (Und, nein: Ich sitze in Mainz.)

Gruß,
Christian

[querdenker]

Ääääh, andere Sache -- vorausgesetzt, der Bedarf besteht, beziehungsweise ist schon im Einsatz:
Können wir uns zwecks Gedankenaustausch über grobe Abläufe in der ganzen Geschichte auf eine "Standard"-Software einigen? Ich denke da an so etwas wie Dia oder Freemind, evtl auch OO-Draw mit Zusatz-Gallery.


mfg, querdenker

[tabellar]

Ääääh, andere Sache -- vorausgesetzt, der Bedarf besteht, beziehungsweise ist schon im Einsatz:
Können wir uns zwecks Gedankenaustausch über grobe Abläufe in der ganzen Geschichte auf eine "Standard"-Software einigen? Ich denke da an so etwas wie Dia oder Freemind, evtl auch OO-Draw mit Zusatz-Gallery.

Ja, super Idee. Ich verwende FreeMind seit einiger Zeit. Ist ein wirklich tolles Tool, mit dem man sehr schnell entsprechende Bilder und HTML Seiten erstellen kann. Was mir persönlich natürlich sehr gut an FreeMind gefällt, ist das XML basierte Datenformat und (jetzt kommt das Beste ) der Collaboration Mode in der neuesten Version über das Jabber Protokoll. Freemind wird sozusagen zum Jabber Client und "tauscht" via XML Jabber Protokoll mit einem anderen (Jabber) FreeMind die Ansichtsdaten aus. Ich hab das vor kurzem mit einem Freund über den amessage.de Server getestet und das hat wirklich gut funktioniert Diese "Collaboration" Funktionalität von Freemind über das Jabber Protokoll war unter anderem der Anstoss für die Verwendung im oben genannten Projekt...

Tabellar

[querdenker]

<prollmode=on>
ey wat, datt kanner auch
<prollmode=off>
Muss ich doch gleich mal nachschauen

mfg, querdenker

Edit / Nachtrag:
Ich hab mir mal die sourceforge-Seite von freemind zu Gemüte geführt. Da sind ja auch noch ein paar andere "nette" Sachen dabei.

[querdenker]

Mal zwischendrin - Ich war mal so frei und habe mal via google ein wenig nach python +workflow gesucht.
Die Ergebnisse waren nicht berauschend.
Viele Fundstellen beziehen sich auf Zope/Plone,
einiges ist in Java realisiert, bietet aber eine Schnittstelle zu Python an,
ein paar Treffer beschäftigen sich direkt mit Python und Workflow, allerdings sind diese veraltet, bzw nicht mehr gepflegt.

Die Treffer, die sich mit Zope/Plone beschäfftigen, betrachten Workflow eher aus der Dokumentenebene.

@tabellar: Wie stark hast du dich bisher auf Jabber festgelegt? Und wenn ja, welchen Server setzt du ein?

mfg, querdenker

[tabellar]

Edit / Nachtrag:
Ich hab mir mal die sourceforge-Seite von freemind zu Gemüte geführt. Da sind ja auch noch ein paar andere "nette" Sachen dabei.

Ja, Freemind geht in die richtige Richtung...

Mal zwischendrin - Ich war mal so frei und habe mal via google ein wenig nach python +workflow gesucht.
Die Ergebnisse waren nicht berauschend.
Viele Fundstellen beziehen sich auf Zope/Plone,
einiges ist in Java realisiert, bietet aber eine Schnittstelle zu Python an,
ein paar Treffer beschäftigen sich direkt mit Python und Workflow, allerdings sind diese veraltet, bzw nicht mehr gepflegt.

Die Treffer, die sich mit Zope/Plone beschäfftigen, betrachten Workflow eher aus der Dokumentenebene.

@tabellar: Wie stark hast du dich bisher auf Jabber festgelegt? Und wenn ja, welchen Server setzt du ein?

mfg, querdenker

Das ist genau das, was ich weiter oben schon angesprochen habe. Im Internet/Google gibt es wirklich nicht viel Handgreifliches bzgl Workflows und in Richtung Python erst recht nicht. Da gibt es dann vielleicht so zwei bis drei Projekte, aber sonst nicht viel mehr. Deshalb spreche ich das Thema ja hier auch an . Meistens werden Workflowmanagementsysteme (WFMS) wirklich im Zusammenhang mit Dokumentenmanagement gebracht. Ich sehe WFMS völlig losgelöst von den individuellen Anwendungen. WFMSe sollen meiner Meinung nach lediglich die Funktionalität für Ablaufsteuerungen bieten. Die grosse Schwierigkeit ist dann die Integration mit den ausführenden Objekten und Komponenten.

Auf Jabber hab ich mich noch gar nicht festgelegt. Mir geht es vielmehr um die Technologie und die Architektur, die dahinter steckt. Nachrichtenformat, Komponenten Kommunikation, Kommunikation mit verteilten Clients, Anwendungsszenarien für Jabber Clients, etc. Dies ist eben eine der A-Fragen von oben. Jabber als Tool mitverwenden oder das ganze System z.B. auf einem Jabber Server als weitere Komponente aufsetzen. Im Moment teste ich mit einem privaten jabberd 1.4.2 Server... und dem Server von amessage.de.

Bzgl. Softwarecode und bereits implementierten Komponenten melde ich mich noch seperat...

Tabellar

[tabellar]

Hoi und servus,

so langsam kommen die individuellen Dialekte und Vorlieben ans
Tageslicht .

Nach einigen Anlaufschwierigkeiten meinerseits jetzt erstmal ein paar Fragen an tabellar:
Du erwähntest, das du schon einige Sachen mehr oder weniger zusammengeschrieben hast.
a) welche Bereiche sind das?
b) mit welchen Komponenten hast du sie realisiert?
...

Was läuft schon?
-

Code: Alles auswählen

 EventEngine + db-basiertes EventRouting
- [python] WorkflowManager
- [sqlite] DB basierte Workflowinstanz kann gestartet werden
- [python] Workflowinstanz "läuft automatisch" durch (Ablaufsteuerung) 
- [python] WF-Kontrollknoten: Start, Sleep,Break,OrSplit,OrJoin,End
- [jabberpy] Ein Jabber Client als Jabber Schnittstelle
- [python] ActivityManager lief schon, wird gerade aber generalüberholt.
(alle Komponenten haben Prototypenstatus :roll:)

Einlesen in den Sourcecode ist ja schön und gut, aber anwendbar sollte das
ganze ja auch noch sein. Aus diesem Grunde habe ich mir folgendes überlegt:
Ich bastel ein ganz einfaches WebGUI über die "Geschichte" mit einem integrierten,
einfachen Python WebServer. So können einfache Testanwendungen erstellt und Dokus
zum Anschauen und Drucken genutzt werden. Ein einfaches GUI muss am Anfang da sein,
da sonst alles in der DB direkt gesteuert werden muss (INSERT, UPDATE ect.) :wink:.
Ausserdem möchte ich eine CGI-basierte Nachrichten Schnittstelle haben,
damit die Kommunikation nicht nur über Jabber Clients oder NachrichtenFiles geht.
Prinzipiell hätte ich eh gern ein WebGUI, was aber andere GUIs nicht ausschliesst.

Ich bin gerade dabei das ganze auf SQLite umzuschreiben. Ich möchte
Programmversionen so einfach wie möglich austauschen und auf verschiedenen
Rechnern laufen lassen können. SQLite bedarf keiner Administration und
ist sehr leistungsfähig im Single-User Bereich (Transaktionen, Trigger,
Subselects, etc.). So kann man sich mehr um das Design als um die Administration
des DB-Servers kümmern. Zielserver später wären dann PostgreSQL, Firebird, etc.

Also, im Moment entwickle ich das ganze unter WIN, soll aber in der Endversion
auf Linux Rechner laufen. Das ganze soll im Moment dann so aussehen, dass das "Framework"
komplett in einem Verzeichnis enthalten ist mit MessageEngine, Workflow Modulen,
SQLite DB, WebServer usw. Es muss nur pysqlite2 auf dem Rechner installiert sein.

[code=python]
 workflow instanz
 _____________
|                      |
|      start          |  
|        |             |
|        |             |
|     orSplit        |
|       /\             |
|      /  \            | 
|     /    \           |
|  break activity |  
|     \    /           |
|      \  /            |
|       \/             |
|     orJoin         |
|       |              |
|       |              |
|      end           |
|_____________|    

[/code]

Tabellar

[tabellar]

Hm, gibt es keine Meinungen zu meinem obigen Vorschlag ???

Tabellar

[CM]

Doch, doch, Dein Vorschlag ist ok. Und sowie ich einen Link sehe, werde ich mir die Seite auch mal anschauen. Du hast natürlich recht: Ohne GUI wird der Einstieg sehr kompliziert und so etwas braucht verdammt viel Zeit.

In diesem Sinne werde ich jetzt einfach mal gespannt warten - mehr läßt mein Chef sowieso nicht zu: An der Vielzahl meiner Posts in den letzten Wochen kann man ja sehen, daß ich gut zu tun habe .

Gruß,
Christian

PS Meine favorisierte DB ist MySQL ... aber das sollte Dich in keiner Weise beeinflussen.
PPS Noch ist der Meßrechner mit Windows 95 betrieben, aber sowie ein Praktikum das hier gerade läuft beendet ist, wird auf Linux umgesattelt - der Rechner steht schon daneben und ist eingerichtet ...

[querdenker]

Ich habe zu dem Thema DB ja schon einen Vorschlag gemacht.
Was meiner Ansicht nach stark für Firebird-SQL spricht

• relativ Plattformunabhängig, dieses gilt auch für die Datenbank
• Installationsgröße
• Geschwindigkeit
• Interne Sprache für StoredProcedures
• Trigger für Before/After Insert, Before/After Update, Before/After Delete
• PostEvent, d.h. das DBMS schickt eine Nachricht an einen angemeldeten Client, der daraufhin eine Aktion ausführen kann
• Unterstützung von UserDefinedFunctions (in Delphi/C geschriebene DLLs/Libs)

Ansonsten bin ich gerade dabei, mich ein wenig mit RPC auseinanderzusetzen, da ich das für die Arbeit brauchen werde.
Dabei stoße ich immer wieder auf twisted, meistens in verbindung mit asyncore.
Könnten man ja eventuell auch hier einsetzen.

mfg, querdenker

[tabellar]

Ich habe zu dem Thema DB ja schon einen Vorschlag gemacht.
Was meiner Ansicht nach stark für Firebird-SQL spricht

• relativ Plattformunabhängig, dieses gilt auch für die Datenbank
• Installationsgröße
• Geschwindigkeit
• Interne Sprache für StoredProcedures
• Trigger für Before/After Insert, Before/After Update, Before/After Delete
• PostEvent, d.h. das DBMS schickt eine Nachricht an einen angemeldeten Client, der daraufhin eine Aktion ausführen kann
• Unterstützung von UserDefinedFunctions (in Delphi/C geschriebene DLLs/Libs)

Das mit dem PostEvent ist interessant. Wie muss man sich solch eine Nachricht vorstellen? Wie erhält der Client die Nachricht? In welchem Format? Wie erkennt der Client, dass eine Nachricht eingegangen ist?

Ansonsten bin ich gerade dabei, mich ein wenig mit RPC auseinanderzusetzen, da ich das für die Arbeit brauchen werde.
Dabei stoße ich immer wieder auf twisted, meistens in verbindung mit asyncore.
Könnten man ja eventuell auch hier einsetzen.

mfg, querdenker

Ich verwende im Moment auch einen RPC "ähnlichen" Nachrichten Ansatz, allerdings ohne auf HTTP aufzusetzen (sprich XML-RPC Syntax ohne HTTP). Twisted ist ein grosses Framework, das sehr viele Protokolle unterstützt. Mit ansyncore habe ich auch erste Tests unternommen. Es ist eben auch ein Framework, das letztendlich auf der "Socket" Schnittstelle aufsetzt. Asyncore ist "reaktiv" ausgelegt. D.h. es "reagiert" auf eingehende Nachrichten.

Die EventEngine Komponente muss eben äussere und innere Ereignisse entsprechend verwalten und da ist so eine Socket, Asyncore, Twistet Geschichte der richtige Ansatz.

Tabellar

[querdenker]

hi tabellar,
ich schick dir einfach mal den Link zur doku, bin gerade ein wenig unter wasser(job)
Kinterbasdb-Doku

mfg, querdenker

[tabellar]

hi tabellar,
ich schick dir einfach mal den Link zur doku, bin gerade ein wenig unter wasser(job)
Kinterbasdb-Doku

mfg, querdenker

Danke für den Link. Ich hab das ganze mal schnell überflogen. PostgreSQL kann das auch. Bei PostgreSQL würde ich das dann TriggerNotice nennen. Wenn man den Name "PostEvent/TriggerNotice" mal in technische Wörter auflöst, dann steckt da eine serverseitige DB -Trigger Funktion dahinter, welche NOTICEs an die entsprechenden Clients sendet. Diese Clients "hören" dann über die (Socket) LISTEN Funktion diese NOTICEs ab und können dann entsprechend darauf reagieren.

Ich möchte die Daten(bank)seite eigentlich ganz entkoppelt von der Anwendung sehen. Oder anders herum, die DB darf die Anwendung nicht zu sehr beeinflussen. Sprich, das Ziel muss sein, eine saubere Datenschnittstelle zu haben, wo DBs ausgetauscht oder sogar miteinander verbunden werden. Ich nenne diese Datenschnittstelle DataSwitch Komponente, welche Anwendungen nutzen (importieren) können. Auf diese Art und Weise kann dann leicht auf SQLite, Firebird, MySQL, PostgreSQL DBs zugegriffen werden, ohne dass die Anwendungskomponente etwas davon merkt...

Gruss Tabellar

PS: Im Showcase Bereich beim gui - datenbank (tabelle) Projekt von Rolgal haben wir so was ähnliches umgesetzt...
PS: