I second that notion. For me, workflow can mean any procedural logic that is implemented programmatically. In that sense, isnt any programming language a workflow engine ?
I really want to learn how to automate workflows using something like JBPM but havent been able to understand what it is that JBpm does which good old object oriented code doesnt also do. For example, the JBPM website sais :
-Pluggable architecture
-Extensible and customizable on every level
-Easy programming model
This reminds me of what youre instructor sais when you first take a class in
Java programming and OOP.
Then after they cite these reasons, they mention a whole bunch of other acronyms which are confusing, and if you google those acronyms, you the exact same list of pros (i.e. extensibility, pluggability, modularity, etc etc). It seems like its an endless circle.
When working on large projects, I always look to the relational data model as the "end point" i.e., the place which gives immediate relevance to any software component in the system, but it seems like these WSDL BPM XPDL people only reference databases as secondary services in their frameworks, making it difficult to understand what the non abstract benefits of their workflow based technologies are.
Will somebody please give us a real world example of how JBpm speeds deployment, development, etc. ?
