Reordering

For the operators in Table 5.3 where a category 3 (problematic) is indicated, there exists a situation in which the data is needed but not provided:

∃m ∈ I[¬provided(m)].

However, not provided means that in the current structure of the orches-trator that message is not provided. Because by remapping we do not alter the structure of the orchestrator, this does not mean that interoperability can not be maintained. By looking at alternative valid structures, it is still possible to solve incompatibilities. We use two functions to search for alter-natives, either by reordering, discussed in this section, or by recomposition, described in the next section.

In orchestrations where protocols are specified bilateral, an innate flexi-bility exists as there are no direct relations between messages of different ser-vices. This flexibility allows for alternative orchestrators, similarly to what was discussed in the previous chapter. Reordering exploits this flexibility by

removeTrans(sb1,getName,sb5);

Figure 5.2: Change script Merge

removeTrans(sb1,getAccCredib,sb2);

Figure 5.3: Change script Split

addMap(t_b1,/getAccCredib/name,/order/customer/name);

Figure 5.4: Adaptation script Merge

looking whether messages can be shuffled in such a way that incompatibilities can be solved.

To determine whether messages can be reordered, we check whether mes-sages are provided at different points in the business process (protocol).

Therefore we extend the definition of provided given in Section 4.3 of Chap-ter 4.

Definition 44. (Provided_i)

Let < m₁, .., m_n > be a message sequence. With provided_i(m), where i ∈ {1, .., n}, we denote that after the i’th message the data of the message m is provided.

The difference with the definition of provided is that provided_i looks at message sequences without regarding the message’s position. In provided the position of the message is fixed in the sequence, however, when looking if we can change this order, we look whether the data of the message is provided at different positions.

addMap(t_b3,/getName/name,/order/customer/name);

removeMap(t_b1,/getAccCredib/name);

Figure 5.5: Adaptation script Split

Lemma 19. provided_i(m)⇒ providedi+1(m).

The proof for this Lemma follows directly from our non-monotonicity assumption on data. This assumption implies that data values will not change, therefore if something is provided at one point, it will always be provided.

Definition 45. (Can be reordered)

Let m^reo_j ∈ MPr be the message of service P_r that is considered for reordering, then m^reo_j can be reordered if the following properties hold:

(1) ∃x ∈ {1, .., z}∀ < m0, .., m_z >∈ MEX[providedx(m^reo)]

(2) ∀ml ∈ πPr(< mj+1, .., mx>)[provided_x+l(ml)]

(3) ∀ml ∈ πPi(< m_j+1, .., m_x >)[provided_j(m_l)∧ i ̸= r]

Intuitively, the three properties in Definition 45 state that (1) there is a point further on the path such that at that point the message is provided, (2) all the messages in between of the same service can be placed behind that point as well, and (3) for all other messages of other services the messages should be provided earlier.

For creating a script for reordering, we look at the sequence that has to be moved.

Definition 46. (Reorder script)

Let < t₀, .., t_i, .., t_j, .., t_x, .., t_z > be a valid transition sequence of the orches-trator and let ti =< s1, m^reo, s2 > and πPr(< ti, .., tj, .., tx >) =< ti, .., tj >

be the projection of the service on the sequence of messages. Then a script can be created as follows:

α_reo ← αreo∪ removeTransition(s1, m_j+1, s₂) α_reo ← αreo∪ addTrans(s1_ti, m_j+1, s₂)

α_reo ← αreo∪ removeTrans(s1, m_i, s₂) αreo ← αreo∪ addTrans(s2_tx, mi, s2)

αreo ← αreo∪ removeTrans(s1, mx+1, s2) α_reo ← αreo∪ addTrans(s1_ti, m_x+1, s₂).

The first two lines link the messages after the sequence to be reordered to the origin of that sequence. The second two lines put the reorder sequence behind the providing transition t_x and the last two lines link everything behind that transition to the end of the reorder sequence. Note that after transition t_x all messages are still provided as reordering does not remove any messages from the sequence.

Algorithm 5.6 reorder(Business Process BP, Incompatibilities I) solved← ∅

for each m∈ I do

if m can be reordered (Definition 45 ) then α_reo ← see Definition 46

solved← solved ∪ m end if

end for

if I = solved then return αreo

end if

Lemma 20. Adaptation script α_reo is well-formed.

Proof. To prove well-formedness (Definition 5), we prove both BP and BP^′ are well-formed. Well-formedness of the script follows from the well-formedness of the models if the script is applied, thus BP ^α→ BP^{reo ′}. BP is well-formed (Lemma 14). For BP^′ we show that the new sequences created are also valid.

Let < t₀, .., t_i−1, t_i, .., t_j, t_j+1, .., t_x, t_x+1, .., t_z > be a valid sequence, then

< t0, .., ti−1, tj+1, .., tx, ti, .., tj, tx+1, .., tz > is the sequence after reordering.

First, observe that the sequence before t_i, thus t₀, .., t_i−1, remains the same, and is therefore provided. The same holds for the messages after t_x, thus t_x+1.., t_z. That t_i, .., t_j is provided after t_x is guaranteed by Definition 45, Property (1) and (2), and that t_j+1, .., t_x is provided after t_i−1 is guaran-teed by Definition 45 Property (3). Therefore, Lemma 5 from the previous chapter holds for BP^′, thusBP^′ is well-formed.

Lemma 21. Adaptation script α_reo is minimal.

Proof. To prove minimality (Definition 7), we prove that α_reo does not con-tain an identity transformation sequence. An identity transformation can occur in the script for moving a single message or in a script when multiple messages are moved. From Definition 46 we can see that moving a single sequence (message) does not contain any identity transformation sequence.

That a script containing the operators for moving multiple message does not contain a identity transformation sequence, we prove by contradiction.

Assume that adaptation script α does contain a identity transformation se-quence. This means that a message is moved further in a path and then back to its original place. If this message is moved this means that it was not provided at its original position, ¬providedi(m). However, it is then moved back and this implies provided_i(m). Hence, α_reo cannot contain any identity transformation sequence.

When trying to reorder, we are interested in what problems can be solved by shuffling the order of the messages. To analyze this, we look at the set of alternative orchestrators which use the same set of messages. An alternative that uses the same set of messages, we call a message equivalent alternative.

We define the set of message equivalent alternatives as follows:

Definition 47. (Set of message equivalent alternatives)

Let S_red^′ =< (P, M), B, pd, p_c, p₁, .., p_n−1 > be the new composite service in-corporating the changed business protocol with as language M EX_S^′

red. The set of message equivalent alternatives M EX_BP^∗ is defined as:

M EX_BP^∗ ={MEX : ∀ < m1, .., m_z >∈ MEX

∀m ∈< m1, .., m_z > [m∈ M_BP] , M EX ⊆ MEXSred^′ }.

Intuitively, the Definition 47 describes the set of alternative valid orches-trators. Every orchestrator that uses the same set of messages as the current (temporary) orchestrator is considered an alternative.

Theorem 7. Reordering solves all incompatibilities iff

∃MEX ∈ MEX_BP^∗ [d-consistent(BP)].

Proof. The statement “reordering solves all incompatibilities” implies that there exists a non-empty set of incompatibilities I ̸= ∅. This implies not m-complete(BP), and that the reorder operator creates an adaptation script such that after applying it BP ^α→ BP^{reo ′}, that BP^′ is mapping-complete.

Since Theorem 6 shows that remapping can be employed for any data con-sistent business process, it suffices to show that after BP ^α→ BP^{reo ′}, BP^′ is data-consistent.

⇐: Assume ∃MEX ∈ MEX_BP^∗ ′[d-consistent (BP^′)]. We show that reorder-ing will find that M EX. We distreorder-inguish two cases: I = ∅ or I ̸= ∅. First, I = ∅, then d-consistent(BP^′) and the reorder operator returns an empty adaptation script. Second, I ̸= ∅, because there exists a MEX such that d-consistent (BP), it holds ∀m ∈ I[providedi(m)] (property 1 of Definition 45). Since it holds that I ̸= ∅, this implies that ∃m ∈ I[¬provided(m)], however, since d-consistent (BP) holds, there must exist a MEX such that messages are reordered and implying ∀m ∈ I[providedi(m)]. From Lemma 19 it follows that other messages can be moved to the front (Definition 45 property (2)). Definition 45 property (3) is satisfied by Lemma 19, and hence

∀m ∈ I the messages can be reordered.

The reverse “⇒” follows directly from Lemma 20.

Example: Additional Inventory Constraints

Consider the orchestrator for the retailer constructed in Chapter 4 (displayed in Figure 4.8). In this orchestrator, we first check the availability of the products, then request a shipment quote, and last check the credibility of the customer, see Figure 5.9(a). However, imagine that the people behind the inventory service have often prepared products for shipment but in some instances they were not picked up. For this reason, they updated the service with an additional constraint on the checkAvailability message, as illustrated in Figure 5.6. This constraint entails that a shipmentID must be sent along with the request for availability, which is an effort to guarantee that the products are picked up.

The change script for this change only contains one operator, namely the addition of type shipmentID, see Figure 5.7. This change results in an incompatibility which can not be resolved using remapping since the ship-mentID is not provided at the time it is needed. Reordering looks whether this shipmentID is provided at a later point. In this case, it is provided after

Figure 5.6: CheckAvailability message (a) original and (b) with shipmentID

the orchestrator receives the ShipQuote message.

addType(shipmentID,integer,/CheckAvailability);

Figure 5.7: Change script Additional Constraints

The adaptation script for solving this incompatibility is shown in Figure 5.8. In this script, the first two lines connect the shipment messages to the first point after the order is received. The second two lines, connect the communication of the inventory to the last message of the shipper and the third two lines (5 and 6) connect the messages after that to the inventory.

The last line adds the mapping to the shipmentID. The resulting orchestra-tor, after applying this script, is shown in Figure 5.9(b). In this figure the order of messages has been changed such that the availability request to the inventory is placed after the communication with the shipper.

removeTrans(si5, getShipmentQuote, sh2);

addTrans(s4,getShipmentQuote ,sh2);

removeTrans(s4,checkAvailability,si4);

addTrans(sh3,checkAvailability,si4);

removeTrans(sh3,getAccCredib,sb2);

addTrans(si5,getAccCredib,sh2);

addMap(/CheckAvailability/shipmentID,/ShipmentQuote/shipmentID);

Figure 5.8: Adaptation script Additional Constraints

Figure 5.9: Orchestrator (a) before and (b) after adapting