Hi Folks, in preparation for the meeting in Antwerp, here a few design considerations http://www.jboss.org/community/docs/DOC-12855 Thanks for your feedback and look forward to meeting you next week. cheers -thomas

Hi Tom, Hi list, I have integrated OFBiz 4.0 with jBPM 3.1.2. The release info is here: http://www.langhua.cn/en/news/ofbiz4.0-jbpm3.1.2.html I plan to upgrad the OpenCms-jBPM and OFBiz-jBPM to a latest version in the early of 2009, will there be a major release of jBPM in early 2009? Regards, Shi Yusen/Beijing Langhua Ltd. _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

(Advertising...) Langhua is a service provider of OFBiz, we're make a living on it, and on jBPM as well :). I contributed an LDAP(CAS) component into OFBiz trunk in this year. I watched the procedure of OFBiz joining Apache and becoming a TLP in 2006. I think the LGPL license of jBPM may be the only problem to merge the OFBiz-jBPM component into OFBiz. Here is a license list of the jars currently included in OFBiz: http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz Is it possible jBPM can use an Apache license (or BSD, or MIT, or ...) besides current one? If yes, I'll make my efforts to make the component merge into OFBiz. Regards, Shi Yusen/Beijing Langhua Ltd. 在 2008-10-29三的 13:58 +0100，Tom Baeyens写道： > Thanks ! > Good to know. > > btw, what is your relationship with http://ofbiz.apache.org/ ? do they consider to > incorporate it ? > > regards, tom. > > > Shi Yusen wrote: >> Hi Tom, >> Hi list, >> >> I have integrated OFBiz 4.0 with jBPM 3.1.2. The release info is here: >> http://www.langhua.cn/en/news/ofbiz4.0-jbpm3.1.2.html >> >> I plan to upgrad the OpenCms-jBPM and OFBiz-jBPM to a latest version in >> the early of 2009, will there be a major release of jBPM in early 2009? >> >> Regards, >> >> Shi Yusen/Beijing Langhua Ltd. >> >> >> _______________________________________________ >> jbpm-dev mailing list >> jbpm-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbpm-dev _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

No need to say sorry. :) Two mountains, we are a valley. 在 2008-10-29三的 14:42 +0100，Tom Baeyens写道： > No apache licensed version, sorry. > Thanks for the info! > > regards, tom. > > > Shi Yusen wrote: >> (Advertising...) Langhua is a service provider of OFBiz, we're make a >> living on it, and on jBPM as well :). I contributed an LDAP(CAS) >> component into OFBiz trunk in this year. >> >> I watched the procedure of OFBiz joining Apache and becoming a TLP in >> 2006. I think the LGPL license of jBPM may be the only problem to merge >> the OFBiz-jBPM component into OFBiz. Here is a license list of the jars >> currently included in OFBiz: >> http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz >> >> Is it possible jBPM can use an Apache license (or BSD, or MIT, or ...) >> besides current one? If yes, I'll make my efforts to make the component >> merge into OFBiz. >> >> Regards, >> >> Shi Yusen/Beijing Langhua Ltd. >> >> >> 在 2008-10-29三的 13:58 +0100，Tom Baeyens写道： >>> Thanks ! >>> Good to know. >>> >>> btw, what is your relationship with http://ofbiz.apache.org/ ? do they consider to >>> incorporate it ? >>> >>> regards, tom. >>> >>> >>> Shi Yusen wrote: >>>> Hi Tom, >>>> Hi list, >>>> >>>> I have integrated OFBiz 4.0 with jBPM 3.1.2. The release info is here: >>>> http://www.langhua.cn/en/news/ofbiz4.0-jbpm3.1.2.html >>>> >>>> I plan to upgrad the OpenCms-jBPM and OFBiz-jBPM to a latest version in >>>> the early of 2009, will there be a major release of jBPM in early 2009? >>>> >>>> Regards, >>>> >>>> Shi Yusen/Beijing Langhua Ltd. >>>> >>>> >>>> _______________________________________________ >>>> jbpm-dev mailing list >>>> jbpm-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbpm-dev >> _______________________________________________ >> jbpm-dev mailing list >> jbpm-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbpm-dev

We now have time boxed releases every 8 weeks. The next major release, which is jbpm-3.3.0.GA, will come out 10-Nov-2008 cheers -thomas Shi Yusen wrote: > Hi Tom, > Hi list, > > I have integrated OFBiz 4.0 with jBPM 3.1.2. The release info is here: > http://www.langhua.cn/en/news/ofbiz4.0-jbpm3.1.2.html > > I plan to upgrad the OpenCms-jBPM and OFBiz-jBPM to a latest version in > the early of 2009, will there be a major release of jBPM in early 2009? > > Regards, > > Shi Yusen/Beijing Langhua Ltd. > > > _______________________________________________ > jbpm-dev mailing list > jbpm-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbpm-dev

ie you signal a process to start and then poll the service

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 <mailto:tbaeyens@redhat.com>> wrote: Thanks ! This preparation will make the discussions a lot more effective/productive. regards, tom. ps. for the third time, please don't involve Kris in this before synchronizing with me. It will be hard enough for our team to synchonize internally. Kris' opinion differs at even completely other aspects. And I didn't see yet the necessary flexibility from him to get him involved. For the time being, I'll deal with that. And I'll get him involved when there is a chance of unification of the two efforts. Thomas Diesler wrote: Hi Folks, in preparation for the meeting in Antwerp, here a few design considerations http://www.jboss.org/community/docs/DOC-12855 Thanks for your feedback and look forward to meeting you next week. cheers -thomas -- regards, tom. _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org <mailto:jbpm-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/jbpm-dev

so i don't see a lot of need for the engine calling the client back.

from the top of my head, the only use case where people want to know the result of process execution is when subsequent tasks want to be presented to the user as a wizard: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185709#... " I'm at the stage where we have a working process and a console that drives several processes. Again, I want to figure out how to create the action or code that would cause the next task queued for the same user to be brought up without having to click in the queue. I created a JSF tag that was like completeTask except it returns the id of the next task IF it is for the same user. I'm trying to figure out how to "redirect" so that a new task gets loaded. " so i don't see a lot of need for the engine calling the client back. we can discuss further on monday regards, tom. Thomas Diesler wrote: > Hi Joram, > > thanks for your feedback. > > > ie you signal a process to start and then poll the service > > Not quite. I claim that the engine should call the client when input > is needed from a threading model that ius controlled by the engine - > no polling. > > Conceptually, the engine would throw Signals > > http://www.jboss.org/community/docs/DOC-12885 > > and send Messages > > http://www.jboss.org/community/docs/DOC-12887 > > On top of the low level messaging API there can be a callback API that > hides the internals of > > * register message listener > * copy token data to outgoing message > * send outgoing message > * receive outgoing message > * extract outgoing message data > * create incoming message with response data > * send incoming message > * copy data from incoming message to token > > A client would simply register a callback handler, consume the token > data and provide the response data. The underlying messaging semantics > is transparent. > > ----------------- > > The above is a suggestion how jBPM could be used in embedded mode > without borrowing the client thread. With the concept of "client > signals the process" it is not clear to me how this would work with an > arbitrary composition of long running automated task and user tasks. > > The API should be as simple as possible, but not simpler. Due to over > simplification there are a few limitations that I would like to hear > addressed and create awareness of whether this is acceptable or not. > > Joram Barrez wrote: >> 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 >> <mailto:tbaeyens@redhat.com>> wrote: >> >> Thanks ! >> This preparation will make the discussions a lot more >> effective/productive. >> >> regards, tom. >> >> ps. for the third time, please don't involve Kris in this before >> synchronizing with me. It will be hard enough for our team to >> synchonize internally. Kris' opinion differs at even completely >> other aspects. And I didn't see yet the necessary flexibility from >> him to get him involved. For the time being, I'll deal with that. >> And I'll get him involved when there is a chance of unification of >> the two efforts. >> >> >> >> Thomas Diesler wrote: >> >> Hi Folks, >> >> in preparation for the meeting in Antwerp, here a few design >> considerations >> >> http://www.jboss.org/community/docs/DOC-12855 >> >> Thanks for your feedback and look forward to meeting you next >> week. >> >> cheers >> -thomas >> >> >> -- regards, tom. >> >> >> _______________________________________________ >> jbpm-dev mailing list >> jbpm-dev(a)lists.jboss.org <mailto:jbpm-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/jbpm-dev >> >> >