The jPOS TransactionManager context, when it comes to traverse all participants, is quite promiscuous, as promiscuous as the global state of any application. It relies on the participants to do the right thing and don’t step over each other, by mistake, or on purpose.
As applications grow and we move from a handful participants to several dozens, or even hundreds, it becomes very useful to put some constraints on what a participant can or can’t do related to its Context.
On large jPOS applications, created by disparate teams, the TransactionManager configuration file is usually an excellent self-documenting starting point in order to figure out which transactions are supported, which participants are involved and how they are configured.
In addition, it is common for a participant’s implementation, before doing its job, to check for the presence in the Context of its needed input variables. CheckFields for example, needs a
REQUEST object. SendResponse, needs a
To solve this, we’ve introduced a new
required element, verified by the TransactionManager before calling the participant’s prepare method, that looks like this:
In this case, the TM checks for the presence of a REQUEST entry in the Context. If it’s not present, the transaction aborts right away (as if the participant had returned ABORTED).
This is just syntactic sugar, as the participant can check (and actually check) that, but there’s a little twist.
The participant does not receive the whole context, it just receives a clone of it with JUST the entries described in the
<require> element (which BTW, can be a comma separated list).
In addition to the
require element, we support an
optional element. i.e.:
You get the idea, if the optional
TIMEZONE entries are present, they would get copied to the mini Context used to call the participant.
A similar approach is used in order to selectively get the output of a participant. We use the
provides element like this:
The TransactionManager, who has access to both the original Context and the miniContext offered to the participant, merges back ONLY the entries listed in the
This is an experimental preview feature implemented in
jPOS 3.0 (next). It needs to be battle tested in order to see if it makes sense to keep it, or it’s just a useless idea. If we like it, and we continue supporting it, we may choose to enforce it on every participant. In a second phase we can define a TM-level
promiscuousproperty so that if one chooses the old behavior, you need to set it true, either globally at the TM config level, or at the participant level, perhaps with a