[jbpm-dev] Proposal for jBPM5 first release

[Staub, Edward]

Kris,

I mainly wrote to try to get a rise out of other folks, if any of these
are common concerns, so that the release is a good fit for the most people.
If you don't get a rise out of anyone else, ignore this!

> 1.) Open persistence

I suspect the main value here would be in reporting, monitoring, and extensibility.  
In particular, app-specific tables that contain process data 
can be joined to generic-workflow data.  Most reporting tools
(e.g., BIRT unextended) want to go straight to the database - API's are irrelevant.


> 2.) Isolated or collaborative custom nodes.  

You wrote that "I don't think there's a real difference here." 
- I disagree fairly strongly in principle, though if no one else needs 
the delta between them, it doesn't matter.

a.) In JBPM, interacting with the engine provides means for extending workflow
semantics.  This is a very public, documented, exampled part of the API, 
which it isn't (IMO) in Drools.  Consider, for example, the ForEachActionHandler,
which provided the action of a Drools-Flow "ForEach" block in JBPM3.  This
was just an ordinary contribution that could have been written by "anybody" 
(I exaggerate, of course).

b.) Consider implementers who are trying to facilitate use of JBPM in particular
application spaces.  They aren't writing workflows themselves (much) - they are
trying to make writing workflows easy in the context of their domain.
There are rich domain-specific data-models, API's, and persisted data 
that the implementer wants to make work seamlessly with JBPM.  In this case,
they are likely to want to have use something like Drools-Flow Globals to provide
ubiquitous access to API session handles, etc.  They don't want to require every 
In Drools-Flow WorkItems aren't even allowed access to Globals.


> 3.) Custom Decision Handlers.

> Kris wrote: "The disadvantage of using Java classes for describing decisions like 
that is that you tend to end up with a lot of lower-level decision 
code."

I guess I'm ok as long as the expression language can be easily extended to add 
app-specific methods implemented in Java.  For example,
I'd want to be able to carry around db connection parameters in one variable,
a primary Foo key in another variable, and be able to write a Java 
getFoo(connection-parameters, key) method to get the 
record into either a map or a DTO.  (A connection pool is presumed.)


> 4.) Use of rules for decisions.

> Kris wrote: " The vision is that you should be able to combine processes and rules 
seamlessly...  you shouldn't see 
processes and rules (and event processing for that matter) as completely 
separate technologies but rather different ways of modeling your 
business logic which you can easily combine."

All good - GREAT, in fact.    
 

> 5.) A roadmap for web services.  

Disappointing, though expected.  Riftsaw isn't a viable option for us - our customers
are all on WebLogic or WebSphere, and introducing another appserver wouldn't fly.

I don't have a suggestion here.  I can tell you, though, that the lack of a good 
web-services play is perhaps the most important reason our organization hasn't 
adopted JBPM or Drools-Flow.  It's a huge marketecture issue.

-Ed