[jbpm-dev] jBPM4 Design Topics

[Thomas Diesler]

I think you may have misunderstood.

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

The engine would call the client on every UserTask. If process execution 
is fundamentally decoupled from the client thread (as I claim it should 
be) there is no way to return control to the client.

Instead a messaging semantics or a callback semantics would be used.


Tom Baeyens wrote:
> 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
>>>
>>>
>>
> 

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx