Papel que juega la gestión humana en el proceso de registro y control

Using the components discussed in the previous section, we synthesize an orchestrator. However, not all possible orchestrators constructed with these components will be guaranteed to work without incompatibilities. In order to successfully compose an orchestrator that is guaranteed to be interop-erable, we define in this section a number of properties. These properties provide the means to be able to measure whether an orchestrator is compat-ible. Furthermore, using these properties we can determine whether changes

affect the orchestrator and whether an adaptation script solves emerging in-compatibilities. The following properties indicate whether an orchestrator is internally consistent with respect to type, mappings and business rules.

4.3.1 Type

Before a type can be send, it needs to be received first. For this we define whether a type is provided, see definition below.

Definition 18. (Provided)

A type g ∈ g!mj is provided (denoted by provided(g)) iff:

∀< m0, .., !m_j >∈ MEX^j ∃?mi ∈< m0, .., !m_j >∃g^′ ∈ g?mi [g ≃ g^′] For an ordered sequence,

provided(g₁, .., g_k) = provided(g₁)∧ .. ∧ provided(gk) holds, and for a choice of sequences,

provided(g₁|..|gk) = provided(g₁)∨ .. ∨ provided(gk)

holds. We define a message m to be provided, denoted provided(m), if its type g_m is provided.

Intuitively, Definition 18 means that the type (data) must be available (provided) to the orchestrator before it can be used in a message. For in-stance, the retailer can only send the bank-account information from a cus-tomer to the bank after it has received this information from that cuscus-tomer.

Definition 19. (Data-consistency)

We define a service with business process BP to be data-consistent (denoted by d-consistent(BP)) iff:

∀!m ∈ M [provided(m)].

If for all outgoing messages of the orchestrator the data is available then we call the orchestrator data-consistent.

4.3.2 Mappings

Data (types) received by the orchestrator can either be stored, used for in-ference, or directly used for the input of another service. In the last case, the data from a message is mapped/assigned to the structure of another message. We use data mappings to connect types that are provided to types that are required.

Definition 20. (Mapping-sufficient)

A set of mappings MP is sufficient for a type g{x, y} (denoted by m-sufficient(MP, g{x, y})) iff:

∃(mj, p, g{x, y}) ← (mi, p^′, g^′{k, l}) ∈ MP ∧

¬∃(mj, p, g{x, y}) ← (mx, p^′′, g^′′{k, l}) ∈ MP[mi ̸= mx∧ p ̸= p^′′] For an ordered sequence,

m-sufficient(g₁, .., g_k) = m-sufficient(g₁)∧ .. ∧ m-sufficient(gk) holds, and for a sequences of choices,

m-sufficient(g₁|..|gk) = m-sufficient(g₁)⊗ .. ⊗ m-sufficient(gk),

where⊗ is the boolean xor-operator. We define a message m to be sufficiently mapped (denoted m-sufficient(MP, m)) if its type gm is sufficiently mapped.

Intuitively, a sequence is sufficiently mapped if all parts are sufficiently mapped. For a choice construct, there must be exactly one part that must be sufficiently mapped. The difference with the definition of provided (Def-inition 18) is that provided means that data must be available before it can be used (mapped), whereas mapped-sufficiently specifies exactly what data must be put into the messages. Thus, for instance, an element can be available many times, however, if that element is required only once then it should be mapped only once. How to deal with the situation when a type is provided multiple times is discussed in Section 4.6.

Definition 21. (Mapping-completeness)

We define a service to be mapping-complete (denoted by m-complete(BP, MP)) iff the following property holds:

∀!m ∈ M [provided(m) ∧ m-sufficient(MP, m)]

Intuitively, the definition of mapping-completeness means that we call a service to be mapping-complete if for all outgoing messages the types are available (provided) and adequately mapped. If a service is mapping-complete, then this service is also data-consistent.

Lemma 2. m-complete(BP, MP) ⇒ d-consistent(BP).

The proof for this lemma follows directly from Definition 21 and 19.

Intuitively, this lemma states that if a service is mapping complete (has correct mappings for all outgoing messages) then it must by data consistent (has all data needed for those mappings).

Lemma 3. ¬provided(m) ⇒ ¬m-sufficient(m).

The proof of this lemma follows directly from Lemma 2. Intuitively, this lemma means that if data is not received then it can not be used in a mapping.

Lemma 4. If d-consistent(BP^′) and not m-complete(BP^′,MP), then

∃σ[MP → MP^{σ ′}∧ m-complete(BP^′,MP^′)].

Proof. From the definition of data consistency and mapping completeness it follows that d-consistent(BP^′) but not m-complete(BP^′,MP) means: ∃m ∈ M [provided(m)∧¬m-sufficient(MP, m)]. Hence, an adaptation script σ can be found (using operators as described in Table ) such that after applying, a valid mapping (Definition 14) exists such that:

(m_j, p, e{x, y})← (m^u i, p^′, e^′{k, l}).

This lemma states that if a business process is data consistent then a set of operators can be found to make it’s mapping complete.

4.3.3 Business Rules

Similar as for mappings, for business rules we check whether data (type) is available. For business rules this means checking if enough data is available in order to be able to evaluate the condition(s). Because we work on type level, and not on instance level, we cannot check whether a business rule

returns a “true” or “false”, however based on the types available it is possible to deduce whether a business rule might fire.

I.e., we check whether sufficient information is received to be able to evaluate parts of the condition of the business rule. If enough information has been received such that the business rule could in theory be triggered, then it can be evaluated.

Definition 22. (Can evaluate)

The boolean function eval(exp) is defined on the boolean XPath expressions used for the conditions:

[valid(exp, mi)] if exp is a location path;

eval(exp¹)∧ eval(exp²) if exp = (exp¹ ∧ exp²);

eval(exp¹)∨ eval(exp²) if exp = (exp¹ ∨ exp²);

¬eval(exp¹) if exp =¬exp¹.

f alse otherwise.

We define that a guard ϱ can be evaluated, denoted eval(ϱ), if its conditions (boolean expression) are provided.

To check whether a rule can be evaluated, we only need the data (XPath path expressions) in the conditions. Together with the logical connectors (¬, ∨, ∧) it is possible to deduce whether a rule can be triggered. For exam-ple, the business rule for rejecting an order (discussed in Section 4.2.2) con-tains two or-connectors, this rule can therefore be evaluated after the orches-trator receives either one of these three messages (aval, credib, shipQuote).