=Paper=
{{Paper
|id=Vol-1408/paper12
|storemode=property
|title=Confirmation Engine Design Based on PSI Theory
|pdfUrl=https://ceur-ws.org/Vol-1408/paper5-xoc-bpm.pdf
|volume=Vol-1408
}}
==Confirmation Engine Design Based on PSI Theory
==
https://ceur-ws.org/Vol-1408/paper5-xoc-bpm.pdf
Confirmation Engine Design Based on PSI Theory
Ondřej Dvořák Robert Pergl Petr Kroha
Faculty of Information Technology Faculty of Information Technology Faculty of Information Technology
Czech Technical University Czech Technical University Czech Technical University
Prague, Czech Republic Prague, Czech Republic Prague, Czech Republic
ondrej.dvorak@fit.cvut.cz robert.pergl@fit.cvut.cz kroha@informatik.tu-chemnitz.de
Abstract—Design & Engineering Methodology for Organ- The next important principle of DEMO is an operating
isations (DEMO) is a methodology for (re)designing and principle stating that: “Subjects enter into and comply with
(re)engineering of organisations. Having a strong theoretical commitments regarding the products/services they bring about
background in the PSI theory (Performance in Social Interac-
tions), DEMO deals with communication and interaction between in coordination” [6]. This principle clearly sees enterprises as
subjects (human beings) that play a crucial role within all social systems.
company processes. Advanced information systems are used We believe the confirmations in CoRiMa are essentially
to support processes and communications. In these systems, transactions of DEMO. Users of CoRiMa are mostly human
confirmations are very usual patterns. In this paper, we present beings acting in roles of subjects. They enter into a commit-
a design of a confirmation engine based on the transaction axiom
of the PSI theory. We discuss a theoretical background of this ment regarding certain object affirmation. The affirmation is
engine, our implementation, and how this module fits into the IT a specific outcome of the confirmator’s decision. It may be a
infrastructure. yes/no result or something more complex, like a scale value
or even a free comment.
I. I NTRODUCTION We argue that the confirmation principle can benefit from
During design of a commercial software system CoRiMa the transaction axiom and the quoted operating principle of
developed by COPS GmbH, a requirement for so-called con- the General PSI theory in DEMO. In this paper, we sum up
firmation principle came up. CoRiMa is a multi-user client- the key expectations on the confirmation principle in CoRiMa,
server application and an application platform at once. Several and we map them to the DEMO methodology while outlining
users communicate their demands to a server that cooperates a possible design and a basic implementation.
with a risk-management banking system. CoRiMa contends The remainder of this paper is organised as follows. We be-
with a processing of various operations carrying out necessary gin with an overview of DEMO in section II. Then we describe
information (deals, foreign exchanges, balances, etc.). This what CoRiMa is, and what is the purpose of a confirmation
information is necessary for an underlying risk-management engine in section III. We map the confirmation principle to
system to do proper calculations. Since much of this infor- DEMO and bring a suitable naming of all its fundamentals
mation is critical for risk calculations, it cannot appear in in section IV. On the top of the confirmation principle we
the target risk-management system unapproved by privileged introduce the confirmation engine in section V. We show how
users, so-called confirmators. This integral principle is called it fits the CoRiMa architecture, and we present code snippets
the confirmation principle. of its main components. Finally, we present an example of
DEMO sees organisations as systems of actors that are in a deal confirmation in section VI, we mention the related work
a social interaction. The actors perform so-called coordination in section VII, and we conclude the paper in section VIII.
acts. The transaction axiom of the General PSI theory declares II. DEMO OVERVIEW
that these acts are performed in patterns called transac-
DEMO stands for ,,Design & Engineering Methodology
tions [6]. Within transactions, the commitments of subjects
for Organisations”, and we consider it to be the leading
(human beings) are raised. As Dietz [6] claims: “Carrying
methodology of Enterprise Engineering discipline, as it is
through a transaction is a “game” of entering into and
grounded in theories, mainly in the system ontology of Bunge,
complying with commitments.”.
teleology, and the theory of communicative act of Habermas.
At the same time, its benefits for the practical use has been
Copyright c 2015 for the individual papers by the paper’s authors. Copying proven, as documented e.g. in [8] or [1].
permitted for private and academic purposes. This volume is published and For a brief description of DEMO, we take a help of Op’t
copyrighted by its editors
Land and Dietz [8]:
In: W. Schmidt, A. Fleischmann, L. Heuser, A. Oberweis, F. Schönthaler, “A complete, so-called essential model of an organisation
C. Stary, and G. Vossen (Eds.): Proceedings of the Workshop on Cross- consists of four aspect models: Construction Model (CM),
organizational and Cross-company BPM (XOC-BPM) co-located with the
17th IEEE Conference on Business Informatics (CBI 2015), Lisbon, Portugal, Process Model (PM), Action Model (AM), and State Model
July 13, 2015 (SM). The CM specifies the composition, the environment
and the structure of the organisation. It contains the iden- which is one of the reasons why the models are so compact
tified transaction kinds, the associated actor roles as well – it would need a lot more diagram elements to express the
as the information links between actor roles and transaction transaction pattern of every transaction kind using a flowchart-
banks (the conceptual containers of the process history). The like notation.
PM details each transaction kind according to the complete
transaction pattern. In addition, it shows the structure of the
identified business processes that are trees of transactions. The
AM specifies the imperatively formulated business rules that
serve as guidelines for the actors in dealing with their agenda.
The SM specifies the object classes, the fact types and the
declarative formulations of the business rules.”
For the purpose of this paper, we need to introduce briefly
the Construction Model. It shows a network of identified trans-
action kinds and the corresponding actor roles. For example,
transaction kind T01 (Figure 1) delivers a business service
to actor role A00. A00 is called the initiator (consumer) and
A01 the executor (producer). The executor of a transaction
is marked by a small black diamond on the actor’s role box.
The solid line between A00 and T01 is the initiator link; the
solid line between A01 and T01 is the executor link. Figure 1
also shows that another actor role (A07) needs to have access
to the history of transactions T01 (production facts as well
as coordination facts (e.g., status ,,requested”, ,,promised”,
,,stated”, ,,accepted”)). This is represented by the dashed line
between A07 and T01. However, the diagram notation is not
important for our purpose, we will just utilise the underlying Fig. 2. DEMO Standard Transaction Pattern [2]
concepts.
Fig. 3. Happy flow of a transaction [2]
Fig. 1. Typical constructs of a DEMO Construction Model [8]
However, real situations may become even more compli-
cated. It is addressed by the complete transaction pattern in
The DEMO Process Model reveals details of the transac-
Figure 4. It incorporates the notion of revocation – an actor
tions with the respect to complete transaction pattern. The so-
may want to ,,take back” their act done before1 . If that is
called standard transaction pattern is depicted in Figure 2. The
allowed by the other party, the transaction ,,rolls back” to the
,,happy flow” consisting of request, promise, state and
desired state.
accept, as is depicted in Figure 3, is also called the basic
The PSD (Process Structure Diagram) notation is used to
transaction pattern. Apart from the happy flow, decline
depict the PM. However, we will not present it here, as we do
may happen instead of promise, and reject may happen
not need it for our purpose.
instead of accept. Then, a new attempt may be made, or
quit, resp. stop may end the transaction unsuccessfully. 1 In the DEMO theory, nothing can disappear, so the original fact remains
This logic is automatically included in all DEMO transactions, in the fact bank, however, the transaction flow is changed.
automatically after a given time is elapsed. Some can be
changed by a confirmator, while others cannot. Some in-
struments can even be cancelled and consequently result in
a cancellation of the confirmation. All in all, the demands for
various kinds of confirmations can be custom-built.
The general idea is to design a unit in the CoRiMa frame-
work that would meet expectations regarding the confirmation
principle. It should be clearly defined and easily applicable by
a developer facing a request on confirming a given instrument.
We call this unit confirmation engine, and we elaborate it in the
section V. The basic architecture of our approach is presented
in Figure 5.
IV. DEMO AND THE C ONFIRMATION P RINCIPLE
A range of similarities can be identified when comparing
the confirmation principle and DEMO. Nevertheless, these can
Fig. 4. DEMO Complete Transaction Pattern [3]
only be seen from a certain point of view. In this section,
we analyse these similarities, and we evaluate a possibility of
III. C O R I M A AND THE C ONFIRMATION P RINCIPLE the confirmation principle benefiting from them. We follow
up this section by outlining a DEMO-based design and an
CoRiMa is an application platform for development and
implementation of the confirmation engine as a software unit
execution of financial-oriented applications. It consists of
supporting the confirmation principle.
a runtime and a framework. Runtime is a client-server appli-
cation that can host and execute plugins composed of modules A. Requester, Confirmator, Confirmation Pattern, Confirma-
and features offered by the framework. The plugins themselves tion, and Affirmation
implement a client and a server core that is executable within In DEMO, a transaction is a sequence of acts involving
a corresponding part of the runtime. Each plugin maintains two actor roles, an initiator and an executor. The sequence
certain instruments from a financial market. Its client-core must respect the transaction pattern defining legal acts during
views the instruments, its server-core transfers the instruments a transaction processing. A transaction is started by the initia-
into an underlying risk-management system. For example, tor who performs a request to have a desired product stated.
rates of currencies are displayed in the client-core, whereas the Such an act leads to the status requested. The executor
physical deposition of rates happens within the server-core. reacts by promising the product, and the transaction advances
to the status promised. This act represents a guarantee
that the executor is going to produce the requested product
within an execution phase of the transaction2 . As soon as the
executor finishes the production, it performs the state act,
thus bringing the transaction into the status stated meaning
the product is ready. At this moment, the initiator can accept
the product and thus the transaction ends. However, by reject-
ing the product, the initiator could express its disagreement
with the product, and the transaction goes back to the status
stated. Such a decision would result in a negotiation to
clarify mutual expectations on the product.
In CoRiMa, the confirmation is a sequence of acts, too. It
involves two subjects, a requester and a confirmator. As well
as in DEMO, the sequence must respect a given confirmation
pattern. The sequence is started by a requester performing a re-
quest to create a desired product. However, it is important to
Fig. 5. CoRiMa architecture
realize what the product actually is. The confirmation principle
Various instruments with which the plugins operate must insists on preventing a subject to persist an object that has not
undergo a specific confirmation process before landing in been seen and subsequently confirmed by anybody else. Thus,
the risk-management system. This process must go hand in the object itself is not a product, the sole affirmation pertaining
hand with the so-called confirmation principle. The principle to an object is. In case the confirmator has in mind to analyze
guides the process through predefined mandatory and optional the created object, it can give a promise and proceed to an
steps. The use-cases for confirmations can significantly differ 2 Technically, it may happen that the promise is revoked later by the
among the instruments. Some instruments can be confirmed executor, however, we do not deal with this possibility at this place.
execution phase. The production of an affirmation must result DEMO Confirmation Principle
in a state act performed by a confirmator. Again, it is highly Transaction Pattern Confirmation Pattern
important to realize what the state practically means in a con- Transaction Kind Confirmation Kind
text of the confirmation principle. The confirmator must have Transaction Confirmation
at least an option to express its agreement or disagreement Product Kind Affirmation Kind
with an object, yet there can be much more. Nevertheless, Product Affirmation
this outcome must be a property of the affirmation. As soon Initiator Requester
as the confirmation is brought to the status stated, the Executor Confirmator
TABLE I
initiator can proceed with either accepting or rejecting the M APPING BETWEEN DEMO AND THE CONFIRMATION PRINCIPLE
stated affirmation.
Let us summarize the initial mapping between DEMO
and the confirmation principle. The confirmation principle is
generally a PSI theory of DEMO adopted to the needs of expresses a decision of a confirmator whether the given object
CoRiMa. The notions of initiator and executor in DEMO are is approved or not.
represented by the notions of requester and confirmator in
C. Revocations
the confirmation principle. The transaction pattern and the
confirmation pattern both define appropriate steps of a process In DEMO, revocation is a situation when the initiator or
and relations among them. Transaction resp. confirmation is the executor change their minds after performing a certain
then a walkthrough in the corresponding pattern. Product and act. DEMO defines four different revocation patterns for
affirmation are the interests regarding of which subjects (re- request, promise, state and accept, as can be seen
quester and confirmator) enter into a commitment by initiating in Figure 4. If allowed by the other side, each of them can lead
the transaction (resp. confirmation). to a transaction step in the standard transaction pattern, which
constitutes the complete transaction pattern. It means that not
B. Confirmation Kind and Affirmation Kind all transaction kinds allow to revoke an already performed
act. Revocations may be even technically impossible (e.g.,
In DEMO, the transaction kinds imply a specific flow of
shredding of a document).
allowed acts and the corresponding states of the transaction.
Confirmations in CoRiMa exhibit the same behaviour. For
The same may be applied to a confirmation kind. The
instance, shortly after a requester requests an affirmation of
confirmation kind is based on a specific confirmation pattern.
a given object, it can change its mind and want to take the
The main difference is that within the confirmation engine,
request back. It depends on the confirmation kind if such
the acts are performed explicitly (e.g., by calling a method
a step is allowed, and how the confirmation engine should
request()). One can only define what should be an evi-
react. Since these situations are expectable, we want to support
dence that the act just happened (e.g., sending an email to
them, too. Thus, we have to introduce revocation patterns into
its counterpart)3 . If a certain act is senseless or not allowed
the confirmation principle. To make it work, we have to define
for the given confirmation kind (e.g., if the requester is not
their specification for each confirmation kind individually.
allowed to disagree with a created affirmation), this must
be declared. This is similar to specifying action rules in the D. The Confirmation Principle Summary
Action Model of DEMO.
In this section, we clarified how DEMO and the underlying
A transaction in DEMO (hopefully) results in a product
PSI theory can be mapped to the confirmation principle. We
successfully delivered. Each transaction kind has a specific
identified a mapping between a requester and an initiator,
product kind as its result. Similarly, each confirmation kind
and a mapping between a confirmator and an executor. We
has a specific affirmation kind as its result. An affirmation is
showed that a confirmation kind maps to a transaction kind,
the product of a confirmation. Thus a confirmation (hopefully)
and an affirmation maps to a product in DEMO. DEMO
results in an affirmation successfully produced. The affirmation
models successfully describe the whole enterprise process
itself is a set of properties and their corresponding values. All
logic by transaction kinds derived from the complete trans-
these properties represent the confirmator’s notion regarding
action pattern. Thus, we argue that confirmations based on the
an object which is tasked to approve (e.g., a property called
same complete transaction pattern can handle all necessary
result can transfer an information whether the confirmator is
situations of various confirmation processes. Table I presents
fine with the object or not). Nevertheless, one has to introduce
the overview of the resulting mapping.
all required properties before a confirmation process is started.
This is done by an affirmation kind which defines it. V. T HE C ONFIRMATION E NGINE
To sum up, a transaction kind in DEMO corresponds to
a confirmation kind. The product kind is represented by Let us recall that the confirmation engine is supposed to
an affirmation kind. The product is the affirmation itself. It be a unit in CoRiMa supporting the confirmation principle. It
should be universal, thus independent on objects it is used for.
3 This corresponds to facts in the PSI theory described above, however we It must allow an easy creation of a new confirmation kind for
do not go into such detail here. a given type of an object. In the end, it must be able to integrate
new confirmation kinds and thereby enable the confirmation On the client side, two components must be introduced.
principle for any corresponding object. The first component comes from the requester, the second
In this section, we elaborate a possible design of the con- from the confirmator point of view. Let us call them Re-
firmation engine. We show how it fits the architecture of quester Client and Confirmator Client. These components
CoRiMa. represent actors in DEMO, the initiator and the executor.
Since the implementation itself is out of scope of this They provide methods for performing all valid acts. Tech-
paper, we only present basic code snippets in C# of its most nically, RequesterClient and ConfirmatorClient
interesting parts. We follow a similar scenario as we did are classes that mediate all clients’ demands to the server
while describing the mapping of DEMO to the confirmation (see the C# code snippet below). For a simplicity, access
principle in section IV. We start with an overall architecture by modifiers and the detailed implementation are omitted. The
identifying the key components. We subsequently investigate ConfirmatorClient will be implemented analogously.
these components deeper. We discuss a design of a requester,
class RequesterClient<...>
an executor, and a confirmation service. We show how the
...
notions of the confirmation pattern, a confirmation, and an
void Request(object obj) {
affirmation are embodied in these components. We continue
// Client-server call requesting an
with a confirmation and an affirmation kind, and we explain
// affirmation of an object
how they are integrated in the whole engine. We end up with
};
revocations by determining their proper involvement.
void Quit(object obj) { ... };
A. The Overall Architecture (The Confirmation Clients and void Accept(object obj) { ... };
the Confirmation Service void Reject(object obj) { ... };
CoRiMa is a client-server application platform. Users inter- ...
act only with a CoRiMa client. In a suitable user interface, }
they observe and maintain financial-based data. All the data On the server, a confirmation service component will take
changes are communicated to a server that stores them into a part. It is a component responsible for reacting on acts
an underlying risk-management system. The confirmation is performed on the client. It basically contains two subcom-
a process (a sequence of acts) between two users, the first ponents, Confirmation Provider and a Confirmation Handler.
one in a role of a requester and the second one in a role The Confirmation Provider publishes end points to which the
of a confirmator. The requester performs a data change, and client-server calls are communicated. The calls are directly
a confirmator approves it before leaving it in an underlying forwarded to a Confirmation Handler that maintains the whole
risk-management system. confirmation process. Technically, these subcomponents are
Figure 6 covers the usual confirmation process. A user in implemented by two classes, ConfirmationProvider
a requester role is connected to a CoRiMa client. It performs and ConfirmationHandler. Again, we omit the imple-
a change of a certain data object. The object is sent to a server mentation details and concentrate on the general structure only.
within a request call. The server just publishes a temporary We list the code snippets below.
created object for the corresponding confirmator. The object
is transferred to the CoRiMa client and displayed within an class ConfirmationProvider
user interface designed for making confirmations. ...
A user in a role of a confirmator confirms the given object void OnRequested(
(i.e., it creates the affirmation) and sends it back to a server. ...,
Finally, the confirmed object is saved to the risk-management object obj) {
system by the confirmation service. // Forward of a request to a
Confirmation Handler
};
void OnQuit(...) { ... };
void OnAccepted(...) { ... };
void OnRejected(...) { ...};
void OnPromised(... { ... };
void OnDeclined(...) { ... };
void OnStated(...) { ... };
void OnStopped(...) { ... };
...
Fig. 6. General Confirmation Process
}
It is obvious that a unit supporting such a confirmation class ConfirmationHandler {
process must take a part on both, client, and server side. ...
void Register(...) { } affirmation (being its product). It means that if a Confirmation
Service knows beforehand the affirmation kind, it can persist
void Request( the affirmation appropriately.
..., Now, we are ready to discuss which information is actually
object obj) { needed by a Confirmation Service to serve the acts performed
// Request confirmation of a given id on the client (e.g. request or state). It must at least
}; know the confirmation kind, and the affirmation kind, and the
void Quit(...) { ... }; object being confirmed. To identify this information smoothly,
void Accept(...) { ... }; we introduce a concept of registrations. The confirmation
void Reject(...) { ... }; kind is paired with the corresponding affirmation kind and
void Promise(...) { ... }; registered with a confirmation handler. All client-server calls
void Decline(...) { ... }; use the identifier of a registration to manifest in which
void State(...) { ... }; confirmation kind they are interested in. The methods of
void Stop(...) { ... }; ConfirmationHandler are enhanced as follows:
...
} ...
In this section, we clarified key components of the whole void Register(
confirmation engine architecture. A requester and a confirma- int registrationId,
tor roles, we identified in subsection IV-A, are represented IConfirmationKind ck,
by RequesterClient and ConfirmatorClient. Both IAffirmationKind ak);
mediate demands to the server side. The confirmation princi-
ple itself is realised using ConfirmationProvider and void Request(
ConfirmationHandler. These constitute a Confirmation int registrationId,
Service maintaining the entire confirmation logic. In the next object obj);
section, we describe how the confirmation pattern, a confir- ...
mation, and an affirmation fits into the Confirmation Service. In this section, we outlined that the Confirmation Service
implements the complete transaction pattern from DEMO. It
B. The Confirmation Pattern in the Confirmation Service registers pairs of confirmation kinds and affirmation kinds,
The confirmation in CoRiMa is a sequence of legal acts and it uses these registrations for handling the client-server
(see subsection IV-B). Their legality is given by the current calls. To recognise the registered pair, registrationId is
context of a confirmation (who is executing the act, which placed in each client-server call. In the next section, we show
acts have already passed, and which object is a subject of the purpose of a confirmation kind and an affirmation kind,
the confirmation). Such a sequence must respect a certain and we describe how the Confirmation Service uses them.
confirmation pattern. We already pointed out that we suppose C. The Role of a Confirmation Kind and an Affirmation Kind
the standard transaction pattern in DEMO should satisfy all
needs for confirming various objects. Thus, the valid subse- The primary responsibility of a confirmation kind is to
quences of acts in a confirmation are driven by a standard manage the process flow, namely to:
transaction pattern. • decide if the act is allowed or not,
4
• specify whether the act is tacit or not.
In fact, the Confirmation Service, we built up in the previous
section, is merely an implementation of this pattern. It contains Next, in CoRiMa, it is necessary to support custom actions
a method for each possible act in the standard transaction tied to different acts in different confirmation kinds. For ex-
pattern. It behaves in accordance to that pattern and evaluates ample, sending an email after giving a promise is a custom
if a given act (method call) is legal in the current situation. If action that is applied only for some confirmation kinds. Thus,
so, it moves the confirmation into another state. the second responsibility of a confirmation kind is to specify
Each confirmation in CoRiMa is of a specific kind, a these custom actions.
confirmation kind. The purpose of each confirmation is a Let us consider an interface of a confirmation kind in
creation of an affirmation. Technically, an affirmation is just the code-snippet below. If each method is implemented, the
a set of properties and their values. It is an instance of a class Confirmation Service can take it into account. For instance, if
specifying these properties. Confirmation Service only have to the promise happens, the Confirmation Service can execute
know how to deal with such an instance. When a confirmator PromiseAct defining a custom action (e.g. sending an
performs a state act, a new value of this instance is email).
delivered within a client-server call. In case the Confirmation Another example is a tacit execution. Let us consider
Service persists this value, a proper way of persisting it must a situation when the accept is tacit, and the reject is not
take place. We already explained in subsection IV-B) that 4 A tacit execution of an act means that the act is performed automatically,
an affirmation kind specifies the information contained in an without being explicitly requested.
allowed. If a confirmator performs the state, the Confirma-
tion Service can react by directly moving the confirmation
into the state accepted and execute the custom method
AcceptAct.
interface IConfirmationKind {
Act RequestAct { get; set; }
Act QuitAct { get; set; }
Act AcceptAct { get; set; }
Act RejectAct { get; set; }
Act PromiseAct { get; set; }
Act DeclineAct { get; set; }
Act StateAct { get; set; } Fig. 7. Confirmation engine in the CoRiMa infrastructure
Act StopAct { get; set; }
}
The confirmation engine consists of the following key
class Act { components:
bool IsAllowed { get; } • RequesterClient
bool IsTacit { get; set; } • ConfirmatorClient
Action<...> Execute { get; set; } • ConfirmationProvider
} • ConfirmationHandler
An affirmation kind is implemented as a class having a set of The client plugin dedicated for requesters uses
custom properties characterising the affirmation. The requester RequesterClient to mediate its requests to the server.
and the confirmator operate with those properties while per- The client plugin for confirmators handles its demands via
forming acts (e.g., if the requester is deciding whether the ConfirmatorClient.
stated affirmation is acceptable or not). The server publishes end points using
To sum up, confirmation kinds define the process flow and ConfirmationProvider that forwards all requests
the custom behaviour of the Confirmation Service. Affirmation into ConfirmationHandler. This is a central unit
kinds hold custom properties, whose values constitute the handling the entire confirmation process. Without an extra
affirmation. information, this unit is useless. It must be supplemented by
ConfirmationKind paired with AffirmationKind.
D. Revocations in the Confirmation Service
Both are registered with ConfirmationHandler during
In CoRiMa, a revocation is a situation when a requester the CoRiMa server startup.
or a confirmator change their mind just after performing an
act. If we want to support such situation, we have to enhance VI. A N I LLUSTRATIVE E XAMPLE
the confirmation senrvice.
In DEMO, four revocation patterns exist in the complete Let us demonstrate how the engine can be used to address
transaction pattern (section II). We believe that by extending a concrete problem.
the implementation with revocation patterns, we cover all ex- Let us consider deals and their confirmations. Each creation
ceptional cases within the confirmation principle. The changes of a deal must be confirmed before the deal ends up in the
will affect all the identified components. We do not pursue this risk-management system. It means that the created deal is
topic any further here, let us just show the relevant extension not automatically persisted in the risk-management system.
of RequesterClient: Instead, it stays in a temporary state until a privileged con-
firmator approves it. In case the confirmator is not satisfied
class RequesterClient<...> with the deal, he can deny the creation and drop a comment
... explaining why.
void RevokeRequest(object obj); First, we clarify the whole problem deeper and write down
void RevokeAccept(object obj); rules for deal confirmations. Second, we show how the rules
... influence the implementation. We conclude with a description
} of how the entire integration works.
E. Confirmation Engine Summary A. Rules of the Deal Confirmation Case Study
We conclude our description of the confirmation engine To successfully integrate the confirmation of deals into
with Figure 7 illustrating how the engine fits into the CoRiMa CoRiMa, we have to scrutinize the problem and specify the
infrastructure. rules first.
• Rule (1): The confirmator is not allowed to refuse a in a confirmation handler. We show how the requester and the
request to perform a confirmation. Once he is asked to confirmator undertake the expected deal confirmation process.
confirm a deal, he has to produce a result.
B. Deal Confirmation Process
• Rule (2): No revocations are allowed. Neither the re-
quester, nor the confirmator can change their minds after Let us demonstrate the entire deal confirmation process now.
performing an act. It is depicted in Figure 8.
• Rule (3): As soon as the confirmator approves or denies
the deal, the confirmation is over. The requester cannot
express a disagreement with the confirmator’s decision.
• Rule (4): An email notification is sent to a confirmator
once a request is performed.
• Rule (5): The confirmator does not have other option but
to approve or deny a deal. He can just optionally leave a
comment.
We described that the confirmation engine (respectively
its confirmation handler) does not support any confirmation
process on its own. This knowledge is represented by injected
confirmation kind and an affirmation kind. Both the kinds have
to be implemented and registered in the confirmation handler.
Thus we have to implement the following: Fig. 8. Deal Confirmation Process
• DealConfirmationKind, a class representing a con-
During a CoRiMa server startup, the server-side Deal Con-
firmation kind. The interface IConfirmationKind
firmation plugin is loaded and DealConfirmationKind
must be implemented by this class.
together with DealAffirmationKind are registered in the
• DealAffirmationKind, a class representing an af-
confirmation handler under a specific identifier Id, let us
firmation kind.
assume the number 248. This identifier must be known to
The way the classes are implemented directly depends on both the client and the server-side.
the rules stated before. Let us examine each rule and describe A pair of client-side CoRiMa plugins must be present to
how it is implemented: provide user interfaces for the deal confirmations. One plugin
• Rule (1): The fact that the confirmator cannot refuse aimed for the creation of the deal, the other is dedicated
a confirmation request means that the promise for its approval. Once a requester creates a deal, the deal
act is performed tacitly. The implementation of must be confirmed. It is done by pressing a Request button.
DealConfirmationKind must consider it and set a The command related to this button is implemented as follows:
value of its PromiseAct property to IsTacit=true.
• Rule (2): No revocation is allowed, thus all the properties
OnRequestExecuted(Deal deal) {
regarding the revocations must be set accordingly
var rct = new RequesterClient(248);
(e.g. RevokeRequestAct.IsAllowed=false).
rct.Request(deal);
• Rule (3): Because the requester cannot actually react on
...
a decision done by a confirmator, his accept is tacit5 .
}
That means the property AcceptAct must reflect this.
• Rule (4): Sending of an email is a custom action. It must This method results in a client/server call to the confirmation
follow the request. Thus the method Execute of provider. The provider forwards the call to the confirmation
RequestAct must be implemented to send an email handler asking for a confirmation identified by 248. The con-
to the confirmator. firmation handler searches for the confirmation kind registered
• Rule (5): The options available to a confirmator determine under the number 248. Subsequently, the handler changes the
directly how DealAffirmationKind will look like. status of the confirmation to requested, and it executes the
It must be a class having two properties. One of a method Execute of the corresponding RequestAct. Since
type enum, having two possible values: Approved and RequestAct of the DealAffirmationKind has to send
Denied. The second property representing a comment, an email to the confirmator, it is done consequently. Because
so most probably of a type string. the PromiseAct is tacit, the handler instantly adjusts the
In this part, we described how each of the rules af- status of the confirmation to promised.
fects the implementation of DealConfirmationKind and Now, the whole process waits for the confirmator’s act.
DealAffirmationKind. In the next part, we register them The client-side plugin Deal Approval responsible for making
approvals is designed for this purpose. Its implementation is
5 This means that the result phase will practically lack the accept act, more or less analogical to the previous one, thus we do not
however, formally, it is present, so the transaction axiom is still valid. elaborate it any further.
VII. R ELATED W ORK implementation of simple and self-explaining components to
Formetis is a Dutch commercial company that has devel- speed-up an integration of requests on confirming certain
oped and successfully applied a DEMO Engine (also called objects.
a DEMO Processor) for its customers, as documented in [5] ACKNOWLEDGMENT
and [7]. The Engine enables the construction and execution of
We would like to express a special thanks to mr. Robert
DEMO models. It is also implemented in the .Net platform
Lukas who came up with a concept for a confirmation principle
using the C# language. The engine itself is independent on
in CoRiMa. Indeed, this concept evoked an idea that such
the technological environment. It has been used to implement
a kind of request perfectly fits DEMO methodology. This
desktop workflow applications and an educational application
opens up a space for further mapping of the theoretically
http://demoworld.nl.
grounded DEMO to a commercial software requirements.
The first DEMO Engine application in production is a case
This paper was written with the support of the SGS15 CTU
management system for a company that provides energy and
grant no. 118/OHK3/1T/18.
utility services. The customers – citizens – are active co-
producers of the service by providing information, coordina- R EFERENCES
tion of some tasks, approval of decisions, etc. The contract [1] Céline Décosse, Wolfgang A. Molnar, and Henderik A. Proper. What
covers issues such as type of services provided, costs, costs Does DEMO Do? A Qualitative Analysis about DEMO in Practice:
calculation procedures, conditions for payments, letters, mails, Founders, Modellers and Beneficiaries. In Wil van der Aalst, John
Mylopoulos, Michael Rosemann, Michael J. Shaw, Clemens Szyperski,
instructions for the subcontractors, etc. There is an enforced David Aveiro, José Tribolet, and Duarte Gouveia, editors, Advances
compliance to legal procedures, policies, conditions, approvals in Enterprise Engineering VIII, volume 174, pages 16–30. Springer
etc. International Publishing, Cham, 2014.
[2] Jan L. G. Dietz. Enterprise ontology: theory and methodology. Springer,
Formetis’s solution is currently the leading industrial solu- Berlin; New York, 2006.
tion of a software system based on DEMO and its underlying [3] Jan L.G. Dietz. THE ESSENCE OF ORGANIZATION - AN INTRODUC-
theories. However, its scope is much broader than our con- TION TO ENTERPRISE ENGINEERING. Sapio bv, 2012.
[4] Jan L.G. Dietz. Red garden gnomes don’t exist. Sapio Enterprise
firmation engine. It is a complete general workflow engine, Engineering, 2013.
while our confirmation engine is a rather lightweight, compact [5] Sérgio Guerreiro, Steven J. H. van Kervel, André Vasconcelos, and José
module for CoRiMa fully focused on its specific task. Overall, Tribolet. Executing Enterprise Dynamic Systems Control with the Demo
Processor: The Business Transactions Transition Space Validation. In
technically, it would be perfectly possible to use Formetis’ Wil van der Aalst, John Mylopoulos, Michael Rosemann, Michael J.
DEMO engine as a confirmation engine, however, from the Shaw, Clemens Szyperski, Hakikur Rahman, Anabela Mesquita, Isabel
software engineering point, often lightweight focused solutions Ramos, and Barbara Pernici, editors, Knowledge and Technologies in
Innovative Information Systems, volume 129, pages 97–112. Springer
may be preferred, as is the case of CoRiMa. Berlin Heidelberg, Berlin, Heidelberg, 2012.
Agreement Technologies [9] may seem similar to our [6] Dietz Jan and Hoogervorst Jan. Theories in Enterprise Engineering
approach, however there is a fundamental difference. Our Memorandum - PSI.
[7] Steven JH Van Kervel, John Hintzen, Tycho van Meeuwen, Joost Ver-
approach addresses confirmations of ontological transactions, molen, and Bob Zijlstra. A professional case management system in
which cannot be automated [4], while agreement technologies production, modeled and implemented using DEMO. In Molnar, Wolf-
are focused on automated agents, i.e. the infological level. gang A., Henderik A. Proper, Jelena Zdravkovic, Peri Loucopoulos, Oscar
Pastor, and Sybren de Kinderen, editors, Complementary proceedings
VIII. C ONCLUSION AND F UTURE W ORK of the 8th Workshop on Transformation & Engineering of Enterprises
(TEE 2014), and the 1st International Workshop on Capability-oriented
In this paper, we mapped the PSI theory to the confirmation Business Informatics (CoBI 2014), volume 1182, Geneva, Switzerland,
principle. We designed and outlined an implementation of July 2014. Technical University of Aachen.
[8] Martin Op ’t Land and Jan L. G. Dietz. Benefits of Enterprise Ontology
a confirmation engine, as a unit supporting the confirmation in Governing Complex Enterprise Transformations. In Wil van der
principle in the CoRiMa framework. The described imple- Aalst, John Mylopoulos, Michael Rosemann, Michael J. Shaw, Clemens
mentation has been fully implemented and deployed to a Szyperski, Antonia Albani, David Aveiro, and Joseph Barjis, editors,
Advances in Enterprise Engineering VI, volume 110, pages 77–92.
testing environment of a banking institution. As we do not Springer Berlin Heidelberg, Berlin, Heidelberg, 2012.
have feedback from the operation yet, we cannot perform a [9] Sascha Ossowski. Agreement Technologies. Springer, 2013.
thorough evaluation. However, the validation by the customer
passed successfully. It proves that the concepts were designed
adequately, and the mapping fulfilled its goal.
Due to space limitations, we covered just the essential
aspects of the implementation. The goal of this paper was
to show that utilising the PSI theory for a design of the
confirmation engine in CoRiMa brought considerable benefits.
Mainly, designing the confirmation pattern by mapping the
corresponding concepts from the PSI theory results in a
guarantee that all possible confirmation situations are covered.
Since CoRiMa is a running project, we now want to focus
on improvements of the engine. We want to emphasize the