[jbpm-dev] jBPM4 Design Topics

[Thomas Diesler]

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