Verteilte Objekte synchron halten?!

[Rouven]

Hallo,

ich bräuchte mal einen Denkanstoß bzgl. eines Problems in unserer Systemarchitektur.
Ausgangspunkt ist ein Workflow-System, das auf einem Rechner X läuft. Unter laufen wird dabei verstanden, dass das System den Workflow kennt und entsprechend dem Kontrollfluss folgen kann.
Weiterhin gibt es mehrere Clients auf denen Benutzer eine Aufgabenliste finden. Nach Beenden einer Aufgabe teilt der Client dies dem Hauptsystem mit, das daraufhin den entsprechenden Teil des Workflows als erledigt abhakt und weiter läuft.
Daneben gibt es auch noch eine Modellierungsoberfläche auf der man das Workflow-Modell auch zur Laufzeit ändern kann.

Nun ist folgendes:
Wäre alles auf dem selben Rechner hätten wir kein Problem. Ein Status-Modell sorgt dafür, dass sich "arbeiten" und "bearbeiten" nicht in die Quere kommen. Was dafür allerdings erforderlich ist, ist die Kenntnis des EINEN Workflows. Nun haben wir aber das Problem, dass das System sich ja über mehrere Rechner verteilt. An der Kommunikation bin ich nur mittelbar beteiligt, mein aktueller Kenntnisstand ist ein Servlet oder gar direkte Socket-Kommunikation.
Wir überlegen jetzt krampfhaft, welche Daten man wann geschickterweise austauscht.
Bei einer einzigen Anwendung hätte ich gesagt engine.gibMirWorkflowDefinition und hätte als Ergebnis die Referenz auf die Definition gehabt. Damit hätten Modell- und Statusänderung auf der selben Instanz stattgefunden. Aber was nun in Anbetracht der Verteilung? Schicke ich eine Kopie des Workflows durch die Welt habe ich ein Riesenproblem die beiden synchron zu halten, weil Änderungen aus dutzenden Richtungen kommen können.
Hat jemand eine Idee, wir man doch mit allen Anwendungen auf der selben Instanz arbeiten kann? Wäre RMI vielleicht eine Lösung?

MfG
Rouven

[Hans]

Hi Rouven,

hm ich würde sagen:

Auf Server X ist der Workflow.
Client A holt sich die n-te Arbeitsanweisung des Workflows, arbeitet dieses ab und gibt den Returnwert an den Server zurück. Von dem bekommt es in Abhängigkeit des Returncodes die nächste Arbeitsanweisung.

Dadurch weiß der Server, bis wohin welcher Client bisher gearbeitet hat und der Modellierer weiß, ab wann er einen neuen Fluß in den Workflow einbauen kann.

Wie man das realisiert hängt vom Gusto des Programmierers ab (Java-C-Server-Kommunikation, RMI, etc.)

Gruß

Hans

[Rouven]

Hi,

Dadurch weiß der Server, bis wohin welcher Client bisher gearbeitet hat und der Modellierer weiß, ab wann er einen neuen Fluß in den Workflow einbauen kann.

das haben wir auch überlegt, aber wie stellst du auf einer GUI den Gesamtprozess dar und lässt die GUI über die Mittagspause offen? es geht das neben Modellierung auch um ein Monitoring, das ständig den aktuellen Zustand anzeigen soll.

MfG
Rouven

[Hans]

Hi Rouven,

das haben wir auch überlegt, aber wie stellst du auf einer GUI den Gesamtprozess dar und lässt die GUI über die Mittagspause offen? es geht das neben Modellierung auch um ein Monitoring, das ständig den aktuellen Zustand anzeigen soll.

Andere Frage: Woher weiß der Modellierer, auf welchem Client welcher Teil des Workflows mit welchen Parametern abgearbeitet wurde? Sprich, wie wirken sich die Änderungen auf den laufenden Prozess aus?

Gruß

Hans

[Rouven]

Hi,

Andere Frage: Woher weiß der Modellierer, auf welchem Client welcher Teil des Workflows mit welchen Parametern abgearbeitet wurde? Sprich, wie wirken sich die Änderungen auf den laufenden Prozess aus?

das ist die andere Seite des Problems. Auf einem einzigen Rechner wäre das über Listener-Konzept realisiert, d.h. die GUI würde sich als Event-Listener an die Instanz hängen, sämtliche Veränderungen würden entsprechende Events mit Source=Aufgabe ausgelöst. Die GUI muss entsprechend reagieren und die Anzeige dieser Aufgabe ändern, eine darauf folgende Sperrung+Bearbeitung ist seitens des Modells nicht möglich.

MfG
Rouven

[Sven Rautenberg]

Moin!

Wäre alles auf dem selben Rechner hätten wir kein Problem. Ein Status-Modell sorgt dafür, dass sich "arbeiten" und "bearbeiten" nicht in die Quere kommen. Was dafür allerdings erforderlich ist, ist die Kenntnis des EINEN Workflows. Nun haben wir aber das Problem, dass das System sich ja über mehrere Rechner verteilt. An der Kommunikation bin ich nur mittelbar beteiligt, mein aktueller Kenntnisstand ist ein Servlet oder gar direkte Socket-Kommunikation.
Wir überlegen jetzt krampfhaft, welche Daten man wann geschickterweise austauscht.

Wenn ich deine Ausgangslage mal selbst formuliere: Du hast "den Zustand" (des Workflows), welcher bearbeitungslogisch nur eine einzige Instanz sein darf, und daran arbeitend diverse Clients. Und du suchst eine Lösung, mit der dieser "Zustand" auf allen Clients parallel und (mehr oder weniger) synchron angezeigt und verändert (von anderen) wird, damit der Benutzer dieses Clients immer "den Zustand" sieht und ggf. auch selbst Änderungen veranlassen kann.

Ganz offensichtlich bedarf es dabei wohl einer zentralen Instanz, die "den Zustand" verwaltet, und hinreichender Kommunikation zwischen dieser Zentrale und allen Clients, damit Änderungen jedem zeitnah mitgeteilt werden.

Es gibt für solche Dinge schon Beispiele, die funktionierend umgesetzt wurden: Chats. Da ist eine zentrale Instanz, die alle "Änderungen" (Textbeiträge der Clients) verwaltet und auch an alle anderen Cliente weiterleitet, damit diese jeweils ganz genau "den Zustand" darstellen können.

Ein Chat ist sicherlich nicht ganz so "Hi-Tech" in der Anzeige, aber das Prinzip dürfte als Denkanstoß passen: Die Clients "chatten" mit dem Server über alles, was der Benutzer so macht, klickt und tippt, damit der Server sofort diese Änderungen mitgeteilt bekommt. Er wiederum "chattet" alle diese Änderungen an die Clients - oder zumindest an den Teil der Clients, die dadurch ihre Anzeige beeinflussen müssen.

Technisch simpel umgesetzt wäre das tatsächlich durch eine persistente Verbindung (also ganz im Gegensatz zu HTTP), auf der während der gesamten Zeit bidirektional Informationsaustausch betrieben wird.

Dementsprechend erscheint es sinnvoll, nur Delta-Informationen auszutauschen, und nicht immer den kompletten Zustand zu übermitteln.

Hat jemand eine Idee, wir man doch mit allen Anwendungen auf der selben Instanz arbeiten kann? Wäre RMI vielleicht eine Lösung?

Ob Java für solche Probleme was anbietet, kann ich nicht sagen.

- Sven Rautenberg

[Rouven]

Hi Sven,

Dementsprechend erscheint es sinnvoll, nur Delta-Informationen auszutauschen, und nicht immer den kompletten Zustand zu übermitteln.

das ist ein Konzept auf dem wir rumkauen. Ein Problem das sich dabei allerdings ergibt ist die verhältnismäßige Unbekanntheit von Objekten um die es geht. So ist z.b. vorgesehen, dass die Engine auf einer sehr beschränkten Menge von Interfaces arbeitet (nennen wir es mal "WorkflowElement") und den eigentlichen Inhalt dieses Elementes gar nicht kennt (ob das jetzt ein AND-Split, ein XOR-Split o.ä. ist). Wenn ich nun also Kopien dieses Objektes verteile habe ich zwei Probleme:

1. Ich muss die Kopien dem Original zuordnen können, ein Test auf Gleichheit wird ja fehlschlagen, d.h. ich muss künstlich über ein Attribut die Gleichheit mitführen - das geht ja noch
2. Ich müsste ziemlich umfangreiche Compare/Copy/Delete-Mechanismen implementieren um die unbekannte Struktur der Objekte abzugleichen - sei es jetzt Reflections oder eigene Methoden, das ginge in die Richtung "gib mir deine Eigenschaften" mit anschließender Übernahme.

Das ist sicherlich eine mögliche Lösung, aber wir hoffen immer noch um dieses manuelle synchronisieren drumherum zu kommen.

MfG
Rouven