When the applications business logic is not placed in a service layer then I would expect that it would be kept as visible and above water as you could make it. The idea being to facilitate maintenance and future development within/upon the process flow. I was wrong. I won't get into the long story about how we got to the point that we can rework this process flow, it is not very interesting and I imagine it is par for the course in most large software development organizations.
All in all, it has provided a very interesting first step in my current project to start working on this problem. I am currently migrating as much logic possible from the transitions back into the process steps or even creating new process steps to bring this functionality into the light. Visibility is the key here. My plans:
- Business logic is being encapsulated into services and pushed down into the SOA layer.
- Transitional actions are being brought up into process steps
- Core process steps are being black-boxed so that you can fill them with any eventual project specific sub-flow definitions as needed.
- Migrating almost all process nodes to state nodes to facilitate a proxy between the process instance node and the service layer (calls)
- Looking to add a custom jBPM class loader with maven like functionality to facilitate multiple projects running with different service versions (why we need this is an infrastructural problem)
Some remarks/questions for your 'plans' (in order)
ReplyDelete# good choice, see http://www.redhat.com/v/webcast/SOAdemo2/SOADemo2.html
# Is GPD visibility (or lack there of of actions on transitions) the reason for this?
# jBPM 3.2.3 has the option to decide a subflow runtime (by name e.g. refering to a processvariable) not a specific version though, would that be of interest?)
# Can you elaborate on this? I miss something, but that is probably me
# jBPM 3.3 has some classloader changes, see the jira for this. Versioning in general is a challenge. Think e.g. of the relation between a process, webapp, rules etc... al with specific versioning things. Process and rules already support this, in combination with specific classes, but how should a versioned webbapp be implemented?
Looking forward to your future steps/problems/...