5
Network commerce has consequences that go far beyond just a business model. [...] Markets are based on mistrust, networks on trust. Markets are based on the pursuit of self-interest, networks on shared interest. Markets are arm’s-length transactions, networks are intimate relationships. Markets are competitive, networks are cooperative.
Jeremy Rifkin ([18], p. 192 f)
The intra- and inter-company work models change from classic, pre-defined, inflexible business processes to agile value creation networks. Human, machines and software collaborate in an integrated and coordinated way to fullfill their objectives. This necessitates a new dimension of agility, speed of transformation and individuality. We strongly believe that we need an open network of self-coordinating, modular components that ofer fully-fledged interoperability to tackle these challenges on the way to autonomous software systems. At the same time such a network will ofer an economic alternative to the classic, centralized platform models and standards of the current IT-industry. These, e.g. BPMN, "fail to guarantee that standard-conforming business process models are interoperable (platform-independent)" ([4]).
Some scientists are already aware of these challenges and laid out fundamental groundwork. Christian Stary proposes "a System-ofSystems specification as a network of cooperating behavior entities" ([19]). These and similar ideas converge on the creation of a new era in systems design.
This whitepaper presents a methodology, a modular concept and the foundation of the Internet o f Actors (IoA). The IoA will reduce complexity, programming eforts and unclear interfaces while creating an Interoperability N etwork. It is going to be an enabler for agile, decentralized, self-coordinating value creation networks, acting as catalyst for the Internet of Things, Digital Transformation and Industry 4.0.
To create such an agile value creation network we first need to focus on the atomic components (= the nodes and their respective relations) the network is comprised of. Smart Actor s (SMA) are the basic building blocks of the IoA. As the IoA is designed as a network, the network nodes need the respective capabilities to deal with challenges like inter-company collaboration in a (self-)coordinated, modular encapsulated manner (mentioned in 1 Introduction). 2.1
The main requirements to the network nodes are similar to the requirements that can be observed with the architectural pattern of microservices (based on [11]), as microservices can also be interpreted as dedicated nodes in network-like applications:
To meet these requirements, we propose the creation of Smart Actor s as nodes and therefore as core building blocks of the peerto-peer agile value creation network.
Therefore, a Smart Actor is able to: (R1) fullfill a well-defined task (R2) "know" the execution-logic needed to fulfill this task, including decision-rules, diferent paths etc. (R3) gather and hold all data needed for the task (R4) ofering a means to extract the essence of the task in a machine-readable way (as an enabler for self-organization) (R5) connect to arbitrary software-interfaces or physical machines in order to exchange data (R6) present its data to human users and ofer possibilities to change these data or take decisions where defined by the SMA (= "frontend"/ UI [30]) (R7) communicate with other SMAs via well-defined protocols to gather information and/ or to propagate its output(s) (R8) has its own release cycle (= being indepently releasable) without being directly afected by the release cycles of others (R9) can be executed in a software system by interpreting or compiling its definition/ source code
The foundation of our Smart Actor s can be found in software design concepts reaching back to the 1970’s. 2.2
In 1994, Albert Fleischmann proposed a concept called "SAPP/ PASS" (Structured Analysis of Parallel Programs in conjunction with Parallel Activities Specification Scheme, [8], pp. 204 f). This 2.2.1 Calculus of Communicating Systems (CCS). Fleischmann describes the CCS as "a theoretically very important technique for describing the behaviour of processes1 explicitly" ([8], p. 130). Paraphrasing [8] (pp. 130-134), the CCS ofers the following: The behaviour of a process2 is described as a rooted, unordered, finite branching tree. The initial state of the process is represented by its root. Branches are labelled and represent actions or transitions to a next state. The CCS distinguishes observable and unobservable actions3. The trees ofer elementary algebraic operations (see figure 1). These operations obey basic algebraic laws (associativity, commutativity and nullity, see figure 2). The trees are called behaviour trees (describing processes). Expressions represent these trees (see ifgure 3): After step a has been executed, steps b (x)or c can be executed next. It is also possible to model agents4 with infinite behaviour in CCS. Figure 4 illustrates agents X and Y , both with
2= its algorithm 3observable or unobservable from outside of the process 4in our terms later: Smar t Actor s potentially finite behaviour 5, and agent Z with a definite infinite behaviour. Albert Fleischmann also focuses on the fact that for each observable action there exists a complementary (or: inverse) action in CCS. It is possible to link multiple agents together. If there exist complementary actions in the diferent behaviour trees, these agents can communicate in synchronous message exchanges6 (see [8], p. 132).
In general, CCS ofers a graph-style 7 approach to model complex behaviours8 and communication between these. 2.2.2 Parallel Activities Specification Scheme (PASS). Based on the CCS9 Albert Fleischmann developed the Parallel Activities Specification Scheme (PASS) in conjunction with a method for Structured Analysis of Parallel Programs (SAPP).
SAPP is a means to decompose complex systems into small, easyto-handle components. These components are able to be executed in parallel and to call each other via clearly defined message channels ("message-types" [8], p. 205). Figure 5 exemplifies such a SAPP specification, where T can send messages of type M3 to P and P can send type M2 to T 10. This type of diagram represents possible communication channels, but has no time, sequence or frequency restrictions.
PASS is used to define a single "process" ([8]) 11. A PASS description contains information about synchronization of messages ("input pool"12), a graph representing the process behaviour (= algorithm/ "intelligence" of the SMA) and process-refinements handling data operations.
The SAPP/ PASS concepts have also been adopted by parts of the 5if transition X (a) or Y (e) is executed 6as opposed to asynchronous message exchange, which we will focus on later 7corresponds to tree-style 8matches in this case the term "algorithms" 9and other methods, [8], p. 201 10for completeness of the example: Q can send M 1 to P , P can send M 1 to R, R can send M 2 to P 11= Smar t Actor in our terms 12Input pools are one of the most important concepts of PASS as they enable messages to be sent either synchronous or asynchronous between components and even ofer possibilities to restrict the number of messages being received at a certain time etc. Without input pools, especially the crucial asynchronous communication would not work. We do not explain the details of this concept, as they are not needed for grasping the general communication of S MAs. Business Process Management (BPM) community ([9]13). In contrast to classic BPM methodologies, PASS is able to focus on actors and/ or agents involved in business processes. These can be humans, software components or machines in mixed setups.
One reason for this adoption by the BPM community, similar to the advantages/ main features of software system development using PASS, is its Turing Completeness ([28]). This has been proven by an interpreter model based on Abstract State Machines (ASM, [12] and [6]), which are based on Finite State Machines. As PASS graphs themselves represent state machines, they can be interpreted like program source code. Therefore it is possible to execute a PASS model instantly without being forced to transform or manually code it. Egon Börger created such an interpreter "for both simulation (testing) and verification (logical analysis of properties of interest) of classes of S-BPM14 processes" ([5]).
The original SAPP/ PASS methodologies unfortunately define that "in the PASS model each system consists of a fixed number of processes15 and each process has a unique name" ([8], p. 205). But to achieve independent releasability it is paramount that SMAs do not have fixed communication channels to other actors and allow agile reconfiguration of the communication network they are part of. 2.3
To tackle the requirement of independently releasable components, we created a concept of well-defined but loose-bound communication channels.
This concept is based on CCS, ASM and PASS. Even if PASS in
13English, enhanced version of the original (German) book: [
Figure 7 shows a graph X that depicts communication with 2 different partners (partner ′ (A) and partner ′′ (B))19. Therefore 2 RBI s can be extracted from this graph. The RBI from X to A, RBI (X , A) 16with asynchronous communication within the system 17see also CCS’s observable actions, section 2.2.1. PASS graphs can also be transformed to CCS behaviour expressions, which aren’t as powerful as some PASS features ([8], p. 259 f), but are therefore suitable to "observe" the communication behaviour 18sending messages or receiving messages 19We intentionally left out information about the types of the graph’s states (send, r eceive, do (internal)) to focus on the RBI explanation. consists of all possible message flows between X and A, their direction and their structural content20. To the relation between X and B applies the same, there is an RBI (X , B).
To every RBI (дraphx , дraphy ) (1) there exists an inverse RBI ′(дraphx , дraphy ) (2).
RBI (дraphx , дraphy )
with дraphx = original Smart Actor and дraphy = potential Communication Partner (1) RBI ′(дraphx , дraphy ) = RBI (дraphz , дraphx ) with дraphx , дraphy , дraphz ∈ SmartActors (2)
This inverse RBI ′ is a tree performing the same message flows like RBI , but does a send where in RBI there is a receive and a receive where there is a send. It is possible to find any SMA Z that has one of its RBI that corresponds to RBI ′ (3).
RBI (Z , Z ′) = RBI ′(X , Z ) (3)
This means that these PASS graph representations of SMAs are able to communicate with each other; in this case, they can be connected (4 - 6):
⇒ Z ′ = X ⇒ RBI (Z , X ) = RBI ′(X , Z ) (4) (5) ⇒ RBI (X , Z ) = RBI ′(Z , X ) (6)
If there are a lot of Smart Actor s known21, there may be more than one Smart Actor that can be found as a potential communication partner. In this case, rules on the communication context 20by structural content we mean data structures (and semantics) transported by a message 21or are being able to be discovered via address books, Smart Actor Name Systems (SMANS) etc. could have been set within the SMAs themselves, further restricting the possible communication partners. Selection strategies (like "bestRated", "nearest ", "f irstComeFirstServe", ...) can apply additionally.
This approach shows that a Smart Actor does not have to be connected with its communication partners before deployment for execution, as the RBI s make it possible to find suitable communication partners even at execution time (see also [20]). This represents also a diference to Agha’s approach ([2]) to software actors, as we do not need direct addressing of other actors, but can use rule based addressing (RBA) via RBIs. 2.4
Keeping the requirements (see 2.1), the foundational concepts CCS (see 2.2.1), ASM, PASS (see 2.2.2) and our thoughts on independent releasability (see 2.3) in mind, we can design a Smart Actor as follows: others. Therefore, a Smart Actor represents a self-contained component (requirement (R8)). (SMA7) Due to its ASM-based, Turing-complete nature, a SMA can be executed by interpreting its behaviour graph (requirement (R9)).
In summary, these Smart Actors fulfill all requirements listed in section 2.1 Requirements. Therefore, SMAs can also be used to execute SmartContracts ([26] and [32] p. 37 f) or act as DApps ([23] and [32] p. 39 f). A possible XML data format for describing SMAs is proposed in [21]. 3
The concept of Smart Actor s allows the creation of a peer -to-peer
aдile value creation network which we call T he Internet o f Actors
(IoA). We want this network to facilitate a clean architecture and
stick to an important principle (known from bitcoin [17], p. 8): "The
network is robust in its unstructured simplicity. Nodes work all at
once with little coordination", whereas ’coordination’ is equivalent
to ’no centralized orchestration’.
(SMA1) The pivotal part is the definition of an internal behaviour
graph22. The behaviour graph consists of states with the 3
basic operations (send, receive, do), transitions between these
states and references to the SMA’s data (see (SMA2)). The
behaviour represents the smartness (or: algorithm), helping 3.1 Definition of the Peer-to-Peer Agile Value
the Smart Actor to Creation Network
(SMAB1) fullfill its task (requirement (R1)), The SMAs represent the main building blocks and are the nodes
(SMAB2) know the execution logic needed (requirement (R2)), within the network. The characteristics of this network are:
(SMAB3) represent decision- and other rules as these are mapped
to behaviour and communication (requirements (R2) andPeer -to-Peer The SMAs can be executed in decentralized environments. If
(R7)) a Smart Actor has the means to find communication partners
(SMAB4) extract the RBI s for defining the communication inter- and message with them (see 3.3), the whole network can be
faces to other SMAs (requirement (R7)) - thus creating built up in a distributed manner without having a centralized
interoperable building blocks structure.
(SMA2) Additionally, a complete data structure can be defined for Aдile Smart Actor s do not employ a tight coupling, but they are
every Smart Actor . This data structure contains everything entirely uncoupled and independent from other SMAs. That
the SMA needs within its behaviour (requirement (R3)). allows the (self-sustaining) configuration of the network
(SMA3) If the Smart Actor is a Service Actor or Physical Actor , mean- to change at any time with the addition, the removal or
ing it connects to microservices or arbitrary software com- the update of new or existing Smart Actor s (see 3.3). Each
ponents or software interfaces, it needs a Service Mappinд network node is part of one or more choreographies25 that
for each of its do-states, defining calls and data exchange to emerge from the communication protocols (= RBI ) and rules
and from these systems (requirement (R5)). set by any SMA.
(SMA4) In case the Smart Actor is intended to support a humVaanlue Creation Objective of every SMA is to create a value (i.e. in terms of
in executing a task23, user interfaces (UI) can be defined by a capability), by transforming any inputs to any outputs26.
mapping to the do-states24 and data structures available, thus Thus, in the network as a whole, there will be a multitude of
creating executable views on the Smart Actor (requirement focal areas (= choreographies) of value creation. Due to the
(R6)). synergy-principle ([27]) the total of value creation will be
(SMA5) Metadata in a structured format are intended to ofer machine- higher than the combined value-deltas of every single SMA
and human-readable data about the SMAs essence, intentions involved.
(see [22]), creators, costs and other useful information (re- N etwork We talk of one single network instead of multiple networks,
quirement (R4)). as - due to its decentralized character - all Smart Actor s
(SMA6) As the extracted RBI s define communication interfaces in- can contribute and will be part of the global network of
stead of a tight coupling to other components, a SMA’s re- collaboration and (therefore) interoperability.
leasability/ deployability is completely independent from
22A Smar t Actor can have more than one behaviour graph for specific applications
like Messaдe Guar ds" (see [
One area of standardization is the Internet o f Actors N otation (IoAN ) which will cover (IoAN1) the complete definition of SMAs (see 2.4 Definition of Smart
Actors), (IoAN2) the notation of the RBI s, (IoAN3) means to show and visualize choreographies of SMAs.
As mentioned before, first concepts regarding (IoAN1) have already been proposed ([21]) and implemented. Furthermore there is a standardization group working on an OWL-definition of an exchange format ([7]). 3.3
The second area of standardization is a Smart Actor Operatinд System (SMAOS). As discussed before (see 2.4 Definition of Smart Actors), Smart Actor s can be executed without any further preparations. For this execution, an operating system is needed, that serves three main purposes. The SMAOS (SMAOS1) can interpret and therefore execute SMAs, (SMAOS2) facilitates communication between Smart Actor s on the same
SMAOS instance and across diferent SMAOS instances, and (SMAOS3) enables the discovery of other SMAs as potential communication partners.
With actnconnect’s Actorsphere ([1]) there exists a first implementation of a SMAOS.
To address the issue of messaging between Smart Actor s (see (SMAOS2)) in regards to transportation layers and formats, we propose the definition of a Smart Actor Communication Protocol (SMACP ). The SMACP could also comprise possibilities to use blockchain technologies (like Hyperledger Fabric ([13] and [32] p. 40 f) or dedicated blockchains) for facilitating distributed storage of messages or even SMA system states.
The discovery of SMAs and/ or SMAOS instances anywhere in the IoA (see (SMAOS3)) requires a Smart Actor N ame System (SMAN S). Techniques like the Satoshi Client Node Discovery ([3]), the Domain Name System ([24]), UDDI ([29]) or similar might be used as an inspiration to define such SMAN S.
Putting all these definitions together, the components of the IoA will be well-defined, executable, communicating and the network can be accessed openly without any discrimination or censorship. 4
The concept of Smart Actors presents a method and implementation of the central building blocks of a peer-to-peer agile value creation network.
From a methodological point of view the SMAs ofer all basic capabilities to build such a network due to their clear and open communication interfaces (RBI s). They enable communication between diferent network nodes regardless of their nature. Therefore the Internet o f Actors can connect humans, machines and software to facilitate their individual contributions to shared and individual objectives. In a technical sense the Smart Actor s are not just "structured" microservices but represent the base components for a new internet, the IoA. Even the very foundations of this network, administrative tools, can be described and implemented by SMAs. The IoA is therefore self-sustaining and self-extending.
Individual value contributions27 can be priced and settled by means of the IoA itself in connection with blockchain-based techniques.
Our further eforts need to go into (ToDo1) the standardization of IoAN and SMAOS, (ToDo2) the creation and facilitation of a growing community of (value) contributors for the IoA, (ToDo3) the detailing of business models within the IoA and (ToDo4) the creation of application examples for the building blocks and the value creation network itself.
The IoA ofers a serious economic alternative to the centralized platform models available today.
The IoA comprises ideal conditions to "go far beyond just a business model", but to build cooperative relationships based on trust to pursue shared interests ([18], p. 192 f).
We want to thank Christian Stary, Albert Fleischmann, Felix Gniza, Anton Friedl, Werner Schmidt, Matthias Lederer and the members of the I2PM community for the fruitful discussions and their support. 27remember: outputs will be sent in form of messages = communication
UDDI Universal Description, Discovery, and Integration