<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Endowing Business Artifacts with a Normative Coordination Layer</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Matteo Baldoni</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Cristina Baroglio</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Federico Capuzzimati</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Roberto Micalizio</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Universit a` degli Studi di Torino - Dipartimento di Informatica c.</institution>
          <addr-line>so Svizzera 185, I-10149 Torino</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
      </contrib-group>
      <fpage>71</fpage>
      <lpage>77</lpage>
      <abstract>
        <p>-We propose to enrich the artifact-centric approach in two ways. First, by relying on the Agent-Oriented Paradigm, the tasks acting on artifacts are organized in agents, seen as autonomous loci of control, whose execution is goal-driven. Second, the business artifact model is complemented by a normative dimension. Norms are used to represent the data lifecycle in a form that is inspectable and that can be reasoned upon by agents. Agents can therefore create expectations about the behaviors of others and hence, leveraging on the norms, agents can act on an artifact so as to entice, or oblige, others to act themselves. The paper discusses the advantages and consequences of this norm-aware enrichment, and outlines a possible realization based on social commitments.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        The artifact-centric approach [5], [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], [8] is recently
emerging as a viable solution for specifying and deploying
business operations by combining both data and processes
as first-class citizens. In particular, the notion of Business
Artifact, initially proposed by Nigam and Caswell [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ],
opened the way to the development of a data-driven
approach to the modeling of business operations. The
datadriven approach counterposes a data-centric vision to the
activity-centric vision, traditionally used when processes
are explicitly modeled in terms of workflows. Artifacts are
concrete, identifiable, self-describing chunks of information,
the basic building blocks by which business models and
operations are described. They are business-relevant objects
that are created and evolve as they pass through business
operations. A business artifact includes an information model
of the data, and a lifecycle model, the latter capturing the
key states through which data evolve together with state
transitions. The lifecycle model is used both at runtime
to track the evolution of artifacts, and at design time to
distribute tasks. The presence of an explicit lifecycle gives
business artifacts a semantics that differentiates them from
other programming abstractions, like objects, active objects,
and artifacts in the sense given to the concept by the A&amp;A
meta-model [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ]. The lack of autonomy differentiates them
from agents.
      </p>
      <p>The work presented in this paper attacks a limit that
business artifacts show: they do not provide the programmer
with any means for designing and modularizing the
coordination of those processes which should operate on them. It
is a fact that business artifacts encapsulate data which are
created and manipulated by many processes. For instance an
order is created by a client who interacts with a seller, and
is manipulated by the operations that make the transaction
between the two proceed. The client, the seller, more in
general the processes that operate on a business artifact need
to agree on who should do what and sometimes even when
to carry out a task of interest – e.g., payment and delivery
must both occur otherwise the purchase transaction will not
reach a happy end, and the two tasks are up to different
parties in the transaction. So, on the one hand, a business
artifact has a lifecycle that describes its evolution from
creation to some state where it is considered as archivable.
On the other hand, along the lines of activity theory –
at the basis of A&amp;A – a business artifact should also be
a medium of coordination and interaction. However, this
latter dimension is not supported by state-of-art literature
on business artifacts. The proposal we present in this paper
aims at overcoming the described lack of business artifacts
with a multiagent systems (MAS) approach. Specifically, we
claim that: (1) services by which it is possible to operate on
business artifacts should be encapsulated and organized into
goal-oriented containers; (2) it is necessary to introduce a
normative layer to capture the behaviors that are expected
of the parties. The paper motivates our research and our
proposal, and illustrates it with the help of a simple purchase
example.</p>
    </sec>
    <sec id="sec-2">
      <title>2. Motivations</title>
      <p>In order to understand how business artifacts are
currently specified and used, we briefly introduce the BALSA
methodology [6] as a significant representative of the current
approaches to business artifacts. The BALSA methodology
specifies a data-centric declarative model of business
operations, and can be summarized in three steps: 1) identify
the relevant business artifacts of the problem at hand and
their lifecycles, 2) develop a detailed specification of the
services (or tasks) that will cause the evolution of the
artifact lifecycles, 3) define a number of ECA-rules
(EventCondition-Action) that create associations between services
and artifacts. ECA-rules are the building blocks to define,
in a declarative way, processes operating on data.</p>
      <p>BALSA (and similar) is extremely interesting, in
particular because it introduces a novel perspective on the
modeling of business processes. However, for what concerns
coordination in presence of more business processes, the
methodology simply refers to choreography languages and
techniques proposed for service-oriented computing, despite
the presence of the business artifacts which could themselves
be natural instruments of coordination.</p>
      <p>We deem the absence of an explicit use of the business
artifacts to the aims of coordination as a significant flaw. In
particular, in inherently destructured settings – like
crossorganizational settings–, the involved actors are all peers,
each of which has its own business goals, and acts in an
autonomous way. Each actor does not know and does not
care about the possible goals of others. Nevertheless, actors
generally need to interact to achieve goals they would not be
able to achieve alone. The interaction is a critical dimension
that need to be explicitly modeled to coordinate the usage of
shared resources. This poses the question of how to scale the
business artifact model to coordinate autonomous entities.
We see in the introduction of a coordination model within
business artifacts the way to achieve this goal, and explain
what we mean with a simple example.</p>
      <p>Let us consider a purchase scenario, involving a
merchant and a client. We claim that in order to coordinate the
interaction between the two agents, it is necessary to add
to the plain message exchange (which standard approaches
to business processes envisage as the only means of
interaction), one further abstraction that explicitly represents the
engagements each player has towards the other. We also
claim that business artifacts should trace such engagements
and their evolution, in order to enable an effective agent
coordination. For example, when offering to sell some goods,
the merchant commits to the client to ship the items the
client will pay for. Such a commitment is stored by the
business artifact involved in the interaction between the two.
Because of his awareness of such a commitment, the client,
having paid for the goods, expects the shipment to occur. If
this does not happen, the commitment progresses into a state
of “violation” and this information, stored in the business
artifact, provides a proof of the merchant’s misbehavior.
From a different perspective, a client is enticed to use
a business artifact by the merchant’s commitment, which
makes explicit the course of interaction the merchant binds
to, and creates a right on the client that such an expected
course of action be respected (i.e., my payment will put an
obligation on the merchant to ship the bought items or the
merchant will violate the commitment). On the other hand,
the merchant uses commitments inside the business artifact
to entice interactions with potential clients – indeed, the
obligation yielded by a commitment is activated only if a
client pays for some goods.</p>
      <p>
        In the example, the commitments that go along with a
business artifact make explicit the behavior the agents are
expected to stick to. They also have a normative flavour, as
diverging behaviors will be considered as violations. This
awareness causes agents to take part to an interaction only if
they are fine with the commitments. As such, commitments
provide a standard to define standards of interaction
mediated by business artifacts. To realize this vision, we claim
that: (1) services should be encapsulated and organized into
goal-oriented containers; (2) it is necessary to introduce a
normative layer. For what concerns (1), the Agent-Oriented
Paradigm is a good candidate. In particular, the Agent
and Artifact meta-model (A&amp;A) [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] has already shown
how artifacts can be used as environment components that
mediate agents’ interactions. However, artifacts in the A&amp;A
model are radically different from the business artifacts
because they do not come with an explicit information
model for data, and they do not exhibit data lifecycles.
Thus, this information cannot be exploited at design time,
nor at runtime, to reason about which actions an agent
should take. Concerning (2), the normative layer would
provide an explicit representation of the business artifacts
lifecycles, and of how coordination is expected to occur.
Such a representation would allow agents to reason about the
use of business artifacts and to create mutual engagements
for driving their activities. Indeed, we envisage engagements
as encoding causal relations between the actions of an agent
and the goals and actions of another, with a normative
power that would allow each agent to have expectations on
the behavior of the others. In the purchase example, it is
easy to see how the introduction of a norm in form of the
commitment whenever a customer pays, the merchant will
ship the goods, would enhance coordination. The customer
now knows that after service pay, the merchant will be
pushed to consider the service ship-goods as one of its
next goals, otherwise it will violate the norm and will be
sanctioned for that. This provides the customer a guarantee
about the achievement of its own goal (or to recoup its
losses). An explicit normative layer plays a central role both
at the design time, to verify whether all the engagements
can converge towards their satisfaction, and at running time
to monitor the execution of a system and determine the
violation of engagements. In this paper we introduce the
notion of normative business artifacts as a means to extend
the artifact-centric approach with a normative layer, where
engagements and norms are expressed in terms of social
commitments [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. The introduction of a normative layer in
the more general setting of business processes is seen as
desirable also in [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ].
      </p>
    </sec>
    <sec id="sec-3">
      <title>3. Coordination via Normative Business Artifacts</title>
      <p>Business artifacts are, by definition, data-aware: they
consider data as a first-class primitive that drives the
construction of process models [5]. Artifacts, however, are not
an end in themselves: they are business relevant entities
that are created, accessed, and manipulated by different
services along a business process. We now show how to
introduce a normative layer so that business artifacts support
coordination.</p>
      <p>
        Destructured business processes call for a
modularization of the control flow. Agent-oriented programming [7],
[
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] is conceived exactly for handling multiple and
concurrent control flows. Two elements are central in
agentoriented programming: the agents and the environment.
Agents, as abstractions of processes, possess their own
control flow, summarized as the cyclic process in which
an agent observes the environment (updating its beliefs),
deliberates which intentions to achieve, plans how to achieve
them, and finally executes the plan [7]. Beliefs concern the
environment. Intentions lead to action [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], meaning that
if an agent has an intention, then the expectation is that it
will make a reasonable attempt to achieve it. In this sense,
intentions play a central role in the selection and the
execution of actions, which represent the innate capabilities agents
have to modify their environment. Among others, (business)
artifacts (see A&amp;A-meta model [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ]) are privileged elements
of an environment. In particular, in contexts where agents
cannot achieve their goals on their own, but need to interact
with other agents to do so, artifacts provide shared resources
that agents will use to mediate their interactions.
      </p>
      <p>We claim that business artifacts should be norm-aware
in two ways. First, the lifecycle of a business artifact should
be made explicit by way of norms that specify how data
evolve. The agents (i.e., the artifact users), will be able
to inspect and reason upon them to decide if and how
to operate on an artifact to obtain some result. Second,
agents need to coordinate and regulate their interaction while
using the business artifacts to achieve their goals. Given
these two bodies of norms, agents will apply reasoning
techniques to plan proper coordination that, possibly without
violating any norm, will lead to goal achievement. This is
possible because norms enable the creation of expectations
and commitments among agents. Moreover, given an explicit
representation of such elements it will be possible to realize
systems of accountability to discourage or to detect and
explain deviant behavior [4].</p>
      <p>
        Even though data-awareness and norm-awareness are by
and large orthogonal to BDI [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] notions, it is natural to
think of agents as BDI agents for a seamless integration
of all the aspects of deliberation, including the awareness
of data and of their lifecycles. For instance, an agent, that
is involved in handling orders, may conclude that, since it
has to pick up three items in the warehouse, since each such
item is to be packed, since all packagings are performed by a
same other agent, and since one of its goals is saving energy,
it is preferable to pick them up altogether, and deliver
them to the other agent only afterwards, instead of picking
and delivering one item at a time. Data-awareness here is
awareness that three items of a same kind are requested.
Norm-awareness that items are picked because each of them
is part of some order, whose lifecycle says that after being
picked they will be packed. Again data-awareness allows
our agent to know that all parcels are to be made by a same
other agent.
      </p>
      <p>
        Relying on agent-oriented programming is promising
also because a the agent-based model allows to naturally
tackle the issue of coordination by introducing the concept
of norm [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]. The deliberative cycle of agents is affected by
the norms and by the obligations these norms generate as
a consequence of the agents’ actions. The limit of current
agent-based approaches is that they provide no holistic
proposal where constitutive norms are used also to specify data
operations, and where regulative norms are used to create
expectations on the overall evolution of the system (agents
behavior and environment evolution).
3.1. Environment/Information
normative business artifacts
systems
based
on
      </p>
      <p>Figure 1 describes the high-level architecture of the
kind of system we imagine: (1) involving business artifacts
and agents (with their goals), and (2) holistically
normaware. Agents interact with each other and with the
environment by creating and modifying data which belong
to an information system and that are reified by business
artifacts. They are goal-driven and capable of coordinating
with other agents by creating and exploiting commitments,
obligations, permissions, and prohibitions. The conceptual
model of the information system is described in terms
of the norms that regulate the evolution of data, that is,
data lifecycles, capturing how data pass from one state to
another as a consequence of actions that are performed
by some agent. Moreover, business artifacts will include
all those normative elements that regulate the coordination
of the agents that interact by way of the artifact. All this
information is available to the interacting agents in a form
that allows agents to reason on it. The agents are aware of
the current state (of the lifecycle) of the data, as well as
of the obligations, prohibitions, commitments, permissions
put on them, and thus they are aware of the tasks expected
of them and of their parties. At any time it is possible to
check the execution, identifying pending tasks and who is
responsible of them, as well as possible violations (e.g. of
obligations or commitments), which may activate procedures
specifically designed to handle the case.</p>
    </sec>
    <sec id="sec-4">
      <title>4. Building</title>
    </sec>
    <sec id="sec-5">
      <title>JaCaMo+</title>
    </sec>
    <sec id="sec-6">
      <title>Normative</title>
    </sec>
    <sec id="sec-7">
      <title>Business</title>
    </sec>
    <sec id="sec-8">
      <title>Artifacts in</title>
      <p>
        In this section we explain how the normative
business artifact we propose can be implemented by relying
on the 2COMM/JaCaMo+ framework [3]. We refer to an
implementation where the BDI agents are implemented in
the Jason agent programming language, and where agents
share artifacts, whose creation and manipulation involves an
explicit creation and manipulation of social commitments
[
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. Social commitments provide the normative layer and
enable the coordination of the goal-driven agents.
      </p>
      <p>We exemplify the implementation in the purchase
scenario. In this scenario each agent has its own goals: the
merchant has the goal of selling goods, while the customer
has the goal of getting some goods. We show how they can
achieve their goals by using a business artifact as the only
means of coordination. To this end we need to present both
sides of the interaction: the normative business artifact, on
the one side, and how the agents use it, on the other side.</p>
      <p>Let us consider first the business artifact. Figure 2 shows
the business artifact representing the transaction occurring
between a merchant and a customer. This artifact follows the
principles of the business artifact proposed in the BALSA
meta-model: a data model is defined to trace relevant pieces
of information; namely, the merchant and customer
identifiers, the item that can be sold by the merchant and the
maximum number of pieces that are available. While this
information is provided at the time the business artifact is
created, three further pieces of information (namely,
quotation, quantity and order) are, instead, the result of the
operations above the artifact performed by the agents using
it. These operations are captured by the business artifact
lifecyle showed here as an automaton: the customer asks
the merchant for a quotation of a given quantity of items it
wants to buy. Once the quotation is provided, the customer
either decides to reject or accept the quotation. In the first
case, the business artifact achieves a final state and can be
archived. In the second case, a new order number is created
to trace the shipping and the payment of the goods. Note
that no ordering between shipping and payment is imposed.</p>
      <p>After the payment, the merchant issues the payment receipt,
and the business artifact can be archived.</p>
      <p>As noted above, such a business artifact is not
sufficiently rich to trace the causal relationships. The customer
may have an expectation about the behavior of the merchant,
raised by its experience in purchasing things, that the
payment of an item will be followed by the merchant giving
the item but this expectation has no normative power. We,
therefore, extend this artifact with a normative layer that, as
anticipated, is expressed in terms of a set of commitments.</p>
      <p>A social commitment C(x, y, s, u) captures that agent x
(debtor) commits to agent y (creditor) to bring about the
consequent condition u when the antecedent condition s
holds (s and u are conjunctions or disjunctions of events).</p>
      <p>Only the debtor of a commitment can create it. When
s is true the commitment is detached and turns into an
obligation on the debtor. When u is true the commitment is
satisfied . A detached commitment that is canceled or whose
consequent becomes f alse is violated.</p>
      <p>To realize a normative business artifact, thus, it is
sufficient to associate each operation on the business artifact
with operations (e.g. create, discharge, etc.) on one (or
more) commitment(s). It follows that a normative business
artifact, besides representing the chunk of information at
hand, maintains also the created commitments, that can be
inspected by the agents. Specifically agents will be notified
of the changes to the business artifact state which include
changes occurred to the commitments. Among other events,
they will be aware of the detachment of commitments of
which they are debtors, and of the satisfaction (violation) of
commitments of which they are creditor.</p>
      <p>commitment ShipGoods merchant t o c u s t o m e r
c r e a t e q u o t e ( q u a n t i t y , c u s t o m e r )
detach a c c e p t ( q u o t a t i o n , q u a n t i t y , c u s t o m e r )
d i s c h a r g e s h i p ( c u s t o m e r )
r e l e a s e r e j e c t ( p r i c e , q u a n t i t y , c u s t o m e r )
commitment E m i t R e c e i p t merchant t o c u s t o m e r
c r e a t e q u o t e ( q u a n t i t y , c u s t o m e r )
detach p a i d ( c u s t o m e r )
d i s c h a r g e e m i t ( c u s t o m e r )
r e l e a s e r e j e c t ( p r i c e , q u a n t i t y , c u s t o m e r )
commitment PayForGoods c u s t o m e r t o merchant
c r e a t e a c c e p t ( q u o t a t i o n , q u a n t i t y , c u s t o m e r )
detach s h i p ( c u s t o m e r )
d i s c h a r g e p a i d ( c u s t o m e r )</p>
      <p>Listing 1. The normative layer in the purchase scenario</p>
      <p>In our example, the normative layer is given by the set
of commitments in Listing 1. For the sake of readability,
the commitments are expressed following the syntax of
the Cupid language [9]. The first commitment, ShipGoods,
is created by the merchant when it executes the quote
operation. That is, besides giving a value to the quotation
information, the quote operation also commits the merchant
towards the customer. Such a commitment is discharged
when the customer accept the quotation, and discharged
when the merchant ships the bought goods to the customer.</p>
      <p>Also the second commitment, EmitReceipt, is created by
the merchant by the execution of the quote operation. In
this case, the commitment is detached when the customer
pays for the goods, and it is discharged when the merchant
emits the receipt towards the customer. Both these two
commitments are released by the customer when it rejects the
quotation provided by the merchant. The last commitment,
PayForGoods, is created by the customer when it accepts the
merchant’s quotation. The commitment is detached when the
merchant has shipped the goods, and discharged when the
customer pays for them.</p>
      <p>Now, let us briefly review the resulting normative
business artifact. As before, the merchant advertises, by creating
the artifact, some item to be sold, and specifies the number
Information model:
merchant customer item
max avail quantity quotation order
order
payed
pay
ship</p>
      <p>emit
accept</p>
      <p>quot.
accepted ship</p>
      <p>order
pay processed
receipt
emitted
start
request</p>
      <p>quote
bus. art.
created
requested
quotation</p>
      <p>sent
quotationreject</p>
      <p>order shipped
quot. rejected
of available units. An interested customer, by inspecting the
artifact, can now see the commitments that the merchant is
willing to take towards the customer. That is, the customer
can create expectations about the merchant’s behavior that
have a normative power. The customer is, thus, enticed to
accept the quotation because the presence of the
commitment, as part of the information provided by the business
artifact, yields that this action will create an obligation on
the merchant to deliver the goods that will make it achieve
his goal. On the other hand, the customer will see also
the commitments it will take in favor of the merchant,
should it join the interaction. So, if the customer starts
an interaction by requesting a quotation for a number of
units, the merchant will provide such a quotation and, at
the same time, it will create a commitment to: 1) ship
the goods, provided that the customer accepts the quotation
(ShipGoods ), and 2) emit a receipt upon the payment for
the goods (EmitReceipt ).</p>
      <p>Note how the operations performed by agents on the
business artifact make the commitments progress. For
instance, the customer’s acceptance of the quotation has
several effects: 1) on the data side, a new order number is
created to trace shipping and payment; 2) the customer
commits towards the merchant to pay for the goods once they
are delivered (PayForGoods ); 3) commitment ShipGoods is
detached, and then the merchant is now asked to ship the
goods. As a final comment about the artifact, note how
the commitments do not impose any ordering about the
payment and shipping. In fact, the customer could pay as
soon as it accepts the quotation, assured by the existence of
commitment ShipGoods that pushes the merchant to actually
ship the goods.</p>
      <p>A natural way to implement normative business artifacts
is to rely on the 2COMM framework [3]. In 2COMM
normative business artifacts are reified as commitment-based
protocol artifacts, that are provided by the framework as
Java classes. Business artifact operations are mapped into
protocol actions, whereas the data dimension is captured
by the notional social state that protocol artifacts maintain.</p>
      <p>Indeed, the social state kept by a protocol artifact traces both
the data required for the interaction, and the commitments,
together with their states, that are created and manipulated
along the interaction.</p>
      <p>Let us now discuss the other side of the interaction,
that is, how the agents use a normative business artifact. To
exemplify the agents, we use here the JaCaMo+ framework,
consisting in the well-known JaCaMo multi-agent platform
enriched with commitment protocols provided by means of
the 2COMM framework. Below, an excerpt of the merchant
agent program. In this rfist plan, the merchant is solicited
to act by the reception of a requestedQuotation event, that
comes from a customer through the business artifact. The
body of the plan consists in the execution of quote, which
sends a quotation to the customer and causes the creation of
the merchant’s commitments ShipGoods and EmitReceipt.</p>
      <p>The second plan captures the detachment of the ShipGoods
commitment. The detach of the commitment is indeed an
event generated by the artifact the merchant is focusing on,
and it is the consequence of the accept operation performed
by the customer. The body of the plan consists in the ship
operation. Finally, the third plan captures the detachment of
the EmitReceipt commitment, also in this case the body of
the plan aims at discharging the commitment.</p>
      <p>
        This example shows how the two agents, merchant and
customer, can interact with each other by using a business
artifact as an interaction medium. The normative layer
assures that each agent will be willing to discharge its own
commitments to avoid their violation. Notably, each agent
achieves the goal it had at the beginning of the interaction;
namely, the merchant gains money by selling goods, and
the customer has the goods it is interested in. These two
goals, however, are not immediately apparent when one
considers the business artifact depicted in Figure 2. The
two final states, in fact, just denote situations in which the
business artifact can be archived, but do not specify any goal
achievement by the involved agents. One further advantage
of adding the normative layer is the possibility of making
explicit some of the goals and services agents make available
to others. This piece of knowledge can be used by the agents
in a practical reasoning step (see [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]) to decide whether to
1 + r e q u e s t e d Q u o t a t i o n ( Q u a n t i t y , C u s t o m e r I d )
2 &lt;− q u o t e ( U n i t P r i c e * Q u a n t i t y , Q u a n t i t y , C u s t o m e r I d ) .
3 + cc ( My Role Id , C u s t o m e r R o l e I d , a c c e p t ( P r i c e , Q u a n t i t y , C u s t o m e r R o l e I d ) ,
4 s h i p ( C u s t o m e r R o l e I d ) , "DETACHED" ) : e n a c t m e n t i d ( My Role Id )
5 &lt;− s h i p ( C u s t o m e r R o l e I d , Q u a n t i t y ) .
6 + cc ( My Role Id , C u s t o m e r R o l e I d , p a i d ( C u s t o m e r R o l e I d ) , e m i t R e c e i p t ( C u s t o m e r R o l e I d ) , "DETACHED" )
7 : e n a c t m e n t i d ( My Role Id )
8 &lt;− e m i t R e c e i p t ( C u s t o m e r R o l e I d ) .
join the artifact.
      </p>
    </sec>
    <sec id="sec-9">
      <title>5. Conclusions</title>
      <p>
        The presented work is strictly related to the problem of
interaction in multiagent systems. In these systems,
interaction is mainly focused on the modeling of communication
patterns (protocols), which are concerned with the sequence
of messages that can be exchanged between two
communicating agents, but disregard the information conveyed by
these messages. Recent approaches such as HAPN [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ] and
BSPL [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] have started to consider also the information
dimension. HAPN is formally based on automata where
nodes represent states of the interaction and transitions
between nodes represent the messages that can be exchanged.
Transitions have a complex structure since for each message
it is possible to define a guard condition on message sending.
A similar approach is BSPL where the information flow
is decomposed in a number of “simple protocols”, each
defining the schema of the messages that can be exchanged
together with their parameters. Parameter are decorated as in
or out (meaning it is received or emitted). BSPL provides a
formal framework in which it is possible to verify properties
such as liveliness and safety of a protocol. Both HAPN
and BSPL, however, show some weaknesses in properly
handling information. In HAPN, for instance, guards, that
enable message sending, may refer to information which is
not carried by the message itself, but rather maintained in
an external information system, which is not an integral part
of the HAPN proposal, and hence the complete verification
of an interaction is not actually achievable. BSPL, on the
other hand, assumes a distributed view of information. Each
participant has its own knowledge base, and the progression
of the interaction makes the local knowledge bases evolve.
The problem, in this case, is that each participant has just
a local view of the information lifecycle. Thus, an agent
cannot create expectations about the behaviors of other
participants as a consequence of the messages it sends. The
approach we propose overcomes these limitations. Business
artifacts abstract an information system, and provide the
environment in which the agents, which are autonomous loci
of control, interact. Both business artifacts and agents are
first-class components. The autonomy and flexibility of the
agents are preserved and supported; moreover, it is possible
to reason both on the evolution of the business artifacts and
on the interaction. This work can be extended along three
main lines of research. First of all, an explicit normative
layer paves the way to formal verification techniques for
cross-organizational business processes. In this respect, the
notion of accountability is rapidly gaining importance since,
when more organizations come into play, it is even more
important to trace back who is responsible for what. First
steps can be found in [4]. Another promising extension is
to understand how agents could plan the use of business
artifacts for reaching their goals. An initial attempt to use
social commitments in planning has been discussed in [2],
but business artifacts are yet to be considered. Finally, the
standardized lifecycle of commitments can be the key for
developing an agent programming methodology, similar to
the one discussed in [1]. The idea is to program agents so
that they can properly tackle part of the events that are
generated in the business artifacts of their interest; specifically, the
state transitions that occur to commitments in which they are
involved. To conclude, we mention RAW-SYS [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], which
enriches the prescriptive process model with data-awareness.
Although RAW-SYS looks similar to a (normative) business
artifact, the objectives of the two models are quite different.
RAW-SYS is essentially a framework for verifying business
processes taking into account both the control- and the
data-flows. A normative business artifact, instead, aims at
coordinating autonomous agents.
      </p>
      <p>Acknowledgements. This work was partially supported by
the Accountable Trustworthy Organizations and Systems
(AThOS) project, funded by Universita` degli Studi di Torino
and Compagnia di San Paolo (CSP 2014).</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <given-names>Matteo</given-names>
            <surname>Baldoni</surname>
          </string-name>
          , Cristina Baroglio, Federico Capuzzimati, and
          <string-name>
            <given-names>Roberto</given-names>
            <surname>Micalizio</surname>
          </string-name>
          .
          <article-title>Empowering agent coordination with social engagement</article-title>
          .
          <source>In AI*IA 2015, Advances in Artificial Intelligence, LNCS 9336</source>
          , pages
          <fpage>89</fpage>
          -
          <lpage>101</lpage>
          ,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>Matteo</given-names>
            <surname>Baldoni</surname>
          </string-name>
          , Cristina Baroglio, Federico Capuzzimati, and
          <string-name>
            <given-names>Roberto</given-names>
            <surname>Micalizio</surname>
          </string-name>
          .
          <article-title>Exploiting social commitments in programming agent interaction</article-title>
          .
          <source>In PRIMA 2015: Principles and Practice of MultiAgent Systems</source>
          , pages
          <fpage>566</fpage>
          -
          <lpage>574</lpage>
          ,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <given-names>Fundamenta</given-names>
            <surname>Informaticae</surname>
          </string-name>
          (to appear),
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <given-names>Matteo</given-names>
            <surname>Baldoni</surname>
          </string-name>
          , Cristina Baroglio, Katherine M. May, Roberto Micalizio, and
          <string-name>
            <given-names>Stefano</given-names>
            <surname>Tedeschi</surname>
          </string-name>
          .
          <article-title>Computational accountability</article-title>
          .
          <source>In Proceedings of the AI*IA Workshop on Deep Understanding and Reasoning</source>
          , pages
          <fpage>56</fpage>
          -
          <lpage>62</lpage>
          ,
          <year>2016</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <string-name>
            <surname>Wu</surname>
          </string-name>
          .
          <article-title>Artifact-centered operational modeling: Lessons from customer engagements</article-title>
          .
          <source>IBM Syst. J.</source>
          ,
          <volume>46</volume>
          (
          <issue>4</issue>
          ):
          <fpage>703</fpage>
          -
          <lpage>721</lpage>
          ,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <string-name>
            <given-names>K.</given-names>
            <surname>Bhattacharya</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Hull</surname>
          </string-name>
          , and
          <string-name>
            <given-names>J.</given-names>
            <surname>Su</surname>
          </string-name>
          .
          <article-title>A data-centric design methodology for businessprocesses</article-title>
          , pages
          <fpage>503</fpage>
          -
          <lpage>531</lpage>
          . Handbook of Research on BusinessProcess Modeling.
          <source>IGI Publishing</source>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <string-name>
            <given-names>Michael E.</given-names>
            <surname>Bratman</surname>
          </string-name>
          . What is intention? In P. Cohen,
          <string-name>
            <given-names>J.</given-names>
            <surname>Morgan</surname>
          </string-name>
          , and M. Pollack, editors,
          <source>Intensions in Communication</source>
          , pages
          <fpage>15</fpage>
          -
          <lpage>31</lpage>
          . MIT Press, Cambridge, MA,
          <year>1990</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <source>In Proceedings of the 32nd ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems</source>
          , PODS, pages
          <fpage>1</fpage>
          -
          <lpage>12</lpage>
          . ACM,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <string-name>
            <surname>Amit</surname>
            <given-names>K.</given-names>
          </string-name>
          <string-name>
            <surname>Chopra</surname>
            and
            <given-names>Munindar P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>Cupid: Commitments in relational algebra</article-title>
          .
          <source>In Blai Bonet and Sven Koenig</source>
          , editors,
          <source>Proceedings of the Twenty-Ninth AAAI Conference on Artificial Intelligence, January 25-30</source>
          ,
          <year>2015</year>
          , Austin, Texas, USA., pages
          <fpage>2052</fpage>
          -
          <lpage>2059</lpage>
          . AAAI Press,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>David</given-names>
            <surname>Cohn</surname>
          </string-name>
          and
          <string-name>
            <given-names>Hull</given-names>
            <surname>Richard</surname>
          </string-name>
          . Business Artifacts:
          <article-title>A Data-centric Approach to Modeling Business Operations and Processes</article-title>
          .
          <source>IEEE Data Eng. Bull.</source>
          ,
          <volume>32</volume>
          (
          <issue>3</issue>
          ):
          <fpage>3</fpage>
          -
          <lpage>9</lpage>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Riccardo De Masellis</surname>
            , Chiara Di Francescomarino, Chiara Ghidini, Marco Montali, and
            <given-names>Sergio</given-names>
          </string-name>
          <string-name>
            <surname>Tessaris</surname>
          </string-name>
          .
          <article-title>Add data into business process verification: Bridging the gap between theory and practice</article-title>
          .
          <source>In Proceedings of the Thirty-First AAAI Conference on Artificial Intelligence, February 4-9</source>
          ,
          <year>2017</year>
          , San Francisco, California, USA., pages
          <fpage>1091</fpage>
          -
          <lpage>1099</lpage>
          ,
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>A.</given-names>
            <surname>Nigam</surname>
          </string-name>
          and
          <string-name>
            <given-names>N.S.</given-names>
            <surname>Caswell</surname>
          </string-name>
          .
          <article-title>Business artifacts: An approach to operational specicfiation</article-title>
          .
          <source>IBM Systems Journal</source>
          ,
          <volume>42</volume>
          (
          <issue>3</issue>
          ):
          <fpage>428</fpage>
          -
          <lpage>445</lpage>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <surname>Andrea</surname>
            <given-names>Omicini</given-names>
          </string-name>
          , Alessandro Ricci, and
          <string-name>
            <given-names>Mirko</given-names>
            <surname>Viroli</surname>
          </string-name>
          .
          <article-title>Artifacts in the A&amp;A meta-model for multi-agent systems</article-title>
          . Autonomous Agents and
          <string-name>
            <surname>Multi-Agent</surname>
            <given-names>Systems</given-names>
          </string-name>
          ,
          <volume>17</volume>
          (
          <issue>3</issue>
          ):
          <fpage>432</fpage>
          -
          <lpage>456</lpage>
          ,
          <year>December 2008</year>
          .
          <article-title>Special Issue on Foundations, Advanced Topics and Industrial Perspectives of Multi-Agent Systems</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <surname>Munindar</surname>
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>An ontology for commitments in multiagent systems</article-title>
          .
          <source>Artif. Intell. Law</source>
          ,
          <volume>7</volume>
          (
          <issue>1</issue>
          ):
          <fpage>97</fpage>
          -
          <lpage>113</lpage>
          ,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <surname>Munindar</surname>
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>Information-driven interaction-oriented programming: BSPL, the blindingly simple protocol language</article-title>
          .
          <source>In 10th International Conference on Autonomous Agents and Multiagent Systems (AAMAS)</source>
          , pages
          <fpage>491</fpage>
          -
          <lpage>498</lpage>
          ,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <surname>Munindar</surname>
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh. NoBPM: Supporting Interaction-Oriented Automation</surname>
          </string-name>
          via Normative Specifications of Processes,
          <year>2015</year>
          . Invited talk, BPM.
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <surname>Pankaj</surname>
            <given-names>R.</given-names>
          </string-name>
          <string-name>
            <surname>Telang</surname>
            ,
            <given-names>Munindar P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh</surname>
          </string-name>
          , and
          <string-name>
            <surname>Neil</surname>
          </string-name>
          Yorke-Smith.
          <article-title>Relating Goal and Commitment Semantics</article-title>
          .
          <source>In Post-proc. of ProMAS</source>
          , volume
          <volume>7217</volume>
          <source>of LNCS</source>
          . Springer,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <surname>Go</surname>
          </string-name>
          <article-title>¨ran Therborn. Back to norms! on the scope and dynamics of norms and normative action</article-title>
          .
          <source>Current Sociology</source>
          ,
          <volume>50</volume>
          :
          <fpage>863</fpage>
          -
          <lpage>880</lpage>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <surname>Michael</surname>
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Wooldridge</surname>
          </string-name>
          .
          <article-title>Introduction to multiagent systems, 2nd edition</article-title>
          . Wiley,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <surname>Nitin</surname>
            <given-names>Yadav</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>Lin</given-names>
            <surname>Padgham</surname>
          </string-name>
          , and
          <string-name>
            <given-names>Michael</given-names>
            <surname>Winikoff</surname>
          </string-name>
          .
          <article-title>A tool for defining agent protocols in HAPN: (demonstration)</article-title>
          .
          <source>In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems</source>
          , AAMAS, pages
          <fpage>1935</fpage>
          -
          <lpage>1936</lpage>
          ,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>