After scavenging the forums and docs for jbpm 5 over the last week, I have drafted up the attached 'reference architecture' for a scalable jBPM 5 deployment. Would love to get feedback (aka ripped apart :) ).
Here are the key pieces:
1. A shared KnowlegeBase which acts as a repository of processes across the whole deployment (master-slave replicated with writes-to-master and reads-from-slaves etc etc)
2. There are a fixed number of KnowledgeSessions spread across DBs in a DB farm (DB1, DB2)
3. A table contains the mapping between these sessions, the database that they are stored in and the node that is assigned to these sessions. Management of the data in this table is an admin config operation (either automatic or manual).
4. A number of worker nodes which load the KnowledgeSessions that belong to them (as per the table above)
5. Another table that has mapping of processes-to-sessions. This table is updated by the worker nodes when a new process is created.
6. A router or client proxy that routes process instance managment requests as per the following rules:
- For process instance creation requests, round robin to any node
- For requests pertaining to a specific process instance, consult the table in (5) & (6) and route to appropriate node
Now how to scale out:
- If the bottleneck is the CPU/memory of the worker nodes then add more nodes and rebalance the session distribution in table (3)
- If the bottleneck is the DB capacity or disk then add a database, migrate processes/session data to the new database and update table (3)
Of course the resharding above is crude and manual and can probably be more sophisticated but would love to hear thoughts/comments on the basic idea.
Also practically speaking, I hope it is possible to migrate a session and processes to a different DB at all?
Thanks