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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx