Re: [jbpm-dev] Proposal for jBPM5 first release

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! 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. 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. 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.) 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. 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