[jbpm-dev] jBPM4 Design Topics

[Tom Baeyens]

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#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 at redhat.com 
>> <mailto:tbaeyens at 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 at lists.jboss.org <mailto:jbpm-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/jbpm-dev
>>
>>
> 

-- 
regards, tom.