Re: [jbpm-dev] jBPM4 Design Topics

Thomas, Thanks for putting your ideas clearly in a document. It helps me to understand some things you've been saying. There are points in the document that deserve discussion.However, I do get the impression that you see the ideal jBPM as a 'standalone service'. ie you signal a process to start and then poll the service until you get a response. This is a valid use case, ie the JBoss server + the enterprise jbpm EJBs come close to this idea (altough the are some flaws, that is true). But I think that you are forgetting that many (or almost every, altough in my experience) use jBPM in an embedded way. Many use cases see a process engine call as an integral part of some business logic unit of work that has to run in the same transaction. For example a save to the database of a domain model (employee for example) is only valid when the enlisting process is started correctly. This is the great strength of jBPM, compared to other products (mostly exposing BPM as a service that can be queried through some (remote) api), that jBPM can easily be embedded in any technology: I've used jBPM with Spring, with EJBs (MDB, statelss SB), as a webservice, etc. Many vendors provide monolithic BPM service products. I think jBPM has become popular with developers because it is exactly the opposite. Please clarify if I'm seeing this all wrong! But the opinion I got when I read your document was not that of an embeddable BPM engine. If I see the level of the dicussion going on nowadays, I'm really looking forward to next week! Regards Joram On Tue, Oct 28, 2008 at 3:21 PM, Tom Baeyens <tbaeyens(a)redhat.com&gt; wrote: