Beide Akteurs-Typen sind Bestandteil jeweils einer Liste. Die Anfragen-Zusteller sind Bestandteil der Liste, in welcher die von den Workflows abgesetzten Anfragen gespeichert sind (pending_requests_list); die Ergebnis-Zusteller sind Bestandteil der Liste, in welcher die Ergebnisse der Anfragen, welche vom Applikation-Server geliefert werden, abgelegt sind. Sobald ein neues Element in diese Liste eingefügt worden ist, holt sich in beiden Fällen der nächste unbeschäftigte Zusteller dieses Ergebnis aus der Liste und versucht nun, es dem entsprechende an den Applikation-Server zu senden bzw. dem richtigen Workflow zuzustellen.
Bei dieser Art der Konstruktion kann eine Anfrage einfach gesendet werden, indem ein Objekt der Klasse wfl_request_information in die Liste eingefügt wird. Durch das Einfügen wird automatisch ein TimerTask-Objekt vom Typ wfl_request_timeout in der Anfrage-liste erfasst, welches dafür sorgt, dass nach Ablauf des Timeouts diese Tatsache dem Workflow mitgeteilt wird.
Auf der anderen Seite muß auch beim Eintreffen eines Ergebnisses einer Anfrage dieses Ergebnis nur der Liste pending_results_list zugefügt werden. Der nächste freie Ergebnis-Zusteller kümmert sich dann um die Zustellung des Ergebnisses an den Workflow.
Dieses System ist durch diesen Aufbau durchschaubarer, skalierbarer, potentiell schneller sowie zuverlässiger.
Durchschaubarer unter anderem deshalb, weil es durch die verschiedenen nebenläufigen Akteure solche Deadlocks in der Art, dass z.B. ein Workflow eine Anfrage absetzt, diese Anfrage sequentiell durch den Applikation-Server abgearbeitet wird und mit einem Ergebnis beantwortet wird, welches aber der Workflow nicht entgegennehmen kann, weil er ja noch wartet, bis die sequentielle Abarbeitung der Anfrage beendet ist, diese aber nicht beendet wird, bevor nicht das Ergebnis angenommen worden ist, vermieden werden. Außerdem vereinfachen klar verteilten Aufgaben System sowieso.
Skalierbarer wird es, weil man die Anzahl der nebenläufig agierenden Zusteller beliebig festlegen kann und so entsprechend viele Anfragen, zukünftig möglicherweise auch an unterschiedliche Applikation-Server, gleichzeitig absetzen kann. Selbiges gilt für die Annahme von Ergebnissen. Diese nebenläufige Kommunikation macht das System auch schneller.
Dadurch, dass wenn etwas bei der Kommunikation schief geht, es nur ein Problem der Zusteller ist, wird das restliche System durch Kommunikationsprobleme erstmal nicht betroffen.
Jan Kechel 2006-04-28