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

Hi Kris. Unfortunately a bit busy these days but let me add one remark on the persistence: Serializing Java Objects for persistence is never a good idea! Independent of what you do. Never! You cannot search for stuff, you cannot index special attributes, you cannot look into it in the Database, your DBA will hate you and as Ed wrote, monitoring or reporting simply ignores API very often. If you think of huge environments - where at least some projects of ours operate - having a proper database schema is absolutely necessary. I am pretty sure otherwise they will kick me out of the door before I finished the word Blob :-) Cheers Bernd -----Ursprüngliche Nachricht----- Von: jbpm-dev-bounces(a)lists.jboss.org [mailto:jbpm-dev-bounces@lists.jboss.org] Im Auftrag von Staub, Edward Gesendet: Mittwoch, 26. Mai 2010 16:16 An: Kris Verlaenen Cc: jbpm-dev(a)lists.jboss.org Betreff: 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. 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.) 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. 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 _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev