A bit of background first. I am the technical lead on this so the technical details are my playground. I am required to work within the Architecture guidelines as handed down by the department of the same name. These restrictions will be mentioned below in my replies as I encounter them. I will provide the plans I outlined for clarity 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)
- I wish we were using ESB, but we are not allowed. We use a mix of POJO in jBPM with service calls mixed in (services being pure unreliable SOAP messaging over HTTP) PS. I loved the demo, wish I had the ESB property editor, I have to dig through code (handlers) to see what is going on with service calls in a node.
- Yes, this lack of visibility combined with the extensive java coded logic being processed in some of these transitions bothers me greatly in my situation. I just want future projects to be able to estimate new implementation efforts within this process flow a little easier. Best way is to make everything in the flow a bit more visible.
- An architectural limitation is that this project is part of a longer strategic plan that locks us into the 3.1.4 release. It would be of great interest to me to be able to dynamically select a sub-flow at run time. I was just planning to decision node right before selection of the sub-flow needed.
- No, you are missing something and it is not you! It is a long story and involves a reference project (we try our best!). Due to lack of ESB like solutions for reliable messaging, we are left with a very unreliable HTTP communication for services. On top of this we have asynchronous non-transactional back-end systems. All due to these architectural limitations, we hope to improve process resilience with a proxy between the process node and the service call (treat each call as an external system basically). It will call the service, provide some extra tricks to handle specific problems with back end systems, and signal the state-node with the results (good or bad). Not the classic use of a state node, I know, thoughts?
- Again, I have no option for 3.3. In the above mentioned reference project we did pirate some functionality (migrated some classes over to improve auto par generation), but think that class loaders are a bit harder to hijack back down to 3.1.4 versions. We are just interested in pointing to different service endpoints for different jbpm processes (not within a single process). We have failed on class loading issues when trying to deploy these service jars within the par files for a process. It should be pretty straight forward to use a maven like construction to always look for all process related classes (jars) inside a single directory within the deployed process. At least we think/hope so.
I chatted with Mark Little a bit when he visited here in the Netherlands, but we did not get too deep into jBPM. I do follow your comments extensively on the various jbpm jboss lists (user, developer, forums, issues, commits).
I do like what is coming down the road with jBPM (PVM, GWT console). I would love to setup the new GWT monitor for my older jBPM setup, but I am assuming that would not really be possible.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.