Sure it is possible this way (currently developing an app like this myself). But what is 'synchronization' in your case?
I do not intend to send any info to the webtier, the webtier 'queries' the processengine.
this is kind of great - we should keep in touch for that, if you agree of course.
Well, I m quoting you here:
"But what is 'synchronization' in your case? I do not intend to send any info to the webtier, the webtier 'queries' the processengine."
About what information exactly are you talking about here ? There are different kinds of infos exchanged:
Let's denote web-tier with WT, and use BPE for the process engine, PgF for pageflow, PrF for process flow
a) WT triggers BP in BPE --> response from BPE: next activity taking place.
b) WT submits the result of the dialogue with the user to BPE: BPE eventually performs call to service-tier, gets response/fault back, propagates response to WT. Now there are two cases. The WT (we are talking about the simple synchronous case here) is waiting for the following answer:
1st case: A response, along with a spec of what activity is next, or if the process already terminated.
2nd case: A "normal" fault, and here I mean by "normal": something for which a re-submission of the request with some corrections (maybe some semantic validation on the server-side failed) will do. In this case the WT session controller just restarts the activity. The "normal" fault might also include technical exceptions, etc. - in any case the fault's scope is just the current activity, and not the whole process. This means that no next acitivity in the BP can be taken on for now.
3rd case: A "complex" fault - and I leave this out for now: complex faults might trigger compensational business processes, in which case there is another branch to be taken in a correctional/compensational BP perhaps. This would be specified at process engine level.
You see that the WT here queries in fact too. How do you solve this ?