ChapterPDF Available

Blockchain and Services – Exploring the Links: Keynote Paper

Abstract

Blockchain is a novel distributed ledger technology which has attracted a wide range of interests for building the next generation of applications. The broad range of blockchain applications is made possible by so-called smart contracts, which transform a blockchain system into a general compute platform. As a new paradigm and technology platform in the integration space, this bears the question to which degree there is a connection to services, and in how far lessons learned on services can be applied to Blockchain.
Blockchain and Services – Exploring the Links
Keynote Paper
Ingo Weber
Data61, CSIRO and School of CSE, UNSW
Sydney, Australia
ingo.weber@data61.csiro.au
Abstract. Blockchain is a novel distributed ledger technology which
has attracted a wide range of interests for building the next generation of
applications. The broad range of blockchain applications is made possible
by so-called smart contracts, which transform a blockchain system into a
general compute platform. As a new paradigm and technology platform
in the integration space, this bears the question to which degree there is
a connection to services, and in how far lessons learned on services can
be applied to Blockchain.
In the talk, I explored four different facets of this topic, as follows.
First, application-level service interfaces for interaction with blockchain-
based applications enable easy integration with existing infrastructure.
Second, service composition can be achieved through smart contracts,
and enable different approaches to orchestrations and choreographies.
Third, Blockchain-aaS offerings cover infrastructure operation, but the
idea presents further possibilities. And finally, some principles for de-
signing SOA services and microservices can be applied to smart contract
design.
Keywords: blockchain, smart contracts, software architecture, software engi-
neering, business process management
1 Introduction
Blockchain is a novel distributed ledger technology, which has attracted a wide
range of interests for building the next generation of applications in diverse ar-
eas such as supply chain transparency and safety, accounting, utilities, and the
sharing economy. As a concept, blockchain can be defined as “[an append-only
store of transactions which is distributed across many machines] that is struc-
tured into a linked list of blocks. Each block contains an ordered set of transac-
tions.” [18, Ch. 1] The broad range of applications of blockchain is made possible
by so-called smart contracts, i.e., deterministic “programs deployed as data in
the blockchain ledger and executed in transactions on the blockchain.” [18, Ch. 1]
Smart contracts transform a blockchain system into a general compute platform,
with interesting properties like immutability and neutrality.
2 Ingo Weber
For this new paradigm and technology platform, we investigated its impact
on software architecture and engineering practices. Our starting point for this
investigation was the question what do architects and engineers need to know
about blockchain to make good use of it? In this keynote, I covered the main
insights from this work. As such, the keynote also offered a summary of our
recent book [18] on this topic.
More specifically, the keynote gave an outline on the following topics (with
references to our research on the topics given for the interested reader):
a background on blockchain concepts and technology
the functions blockchain can provide within a software system [18, Ch.5]
the options of blockchain systems and their configurations [19]
trade-offs of non-functional properties, such as cost [10,11], performance [20],
or availability [15]
software design patterns for blockchain-based applications [17].
Blockchain offering a new paradigm and technology platform in the inte-
gration space, this bears the question to which degree there is a connection to
services, and in how far lessons learned on services can be applied to Blockchain.
In the talk, I also explored four different facets of this topic, as follows. First,
application-level service interfaces for interaction with blockchain-based appli-
cations enable easy integration with existing infrastructure, as discussed in Sec-
tion 2. Second, service composition can be achieved through smart contracts,
and enable different approaches to orchestrations and choreographies – see Sec-
tion 3. Third, Blockchain-aaS offerings cover infrastructure operation, but can go
beyond that as discussed in Section 4. And finally, some principles for designing
SOA services and microservices can be applied to smart contract design – see in
Section 5.1
2 Integrating Blockchain-based Applications with
Services
Blockchains operate as closed-world systems, i.e., smart contracts can only ac-
cess (some of the) data that is stored on blockchain. To interact with smart
contracts, a client either needs to operate a node that is directly connected to
the blockchain, or rely on such a node operated by someone else (which might
introduce undesirable levels of risk or dependency). Interaction with smart con-
tracts can, by default, not take the form of typical Web service interactions;
instead, clients often do the following. To write to a smart contract, they create
and broadcast a blockchain transaction for each method call. To read from a
smart contract, they read the contract’s variable values (e.g., through a local
call to a suitable smart contract method) and/or its event logs. To see updates,
clients can monitor these variable values and logs.
1Slides of the talk are available at https://www.slideshare.net/IngoWeber2/
blockchain-and-services-exploring-the-links.
Note that a small subset of this paper has been included in an extended abstract.
Blockchain and Services – Exploring the Links 3
Smart contract
Code
Decentralization
Trigger
App
App
App
Org 1
Trigger
App
App
App
Org 2
Blockchain
Variables Event
log
Fig. 1. Trigger component as a bridge between off-chain applications and blockchain
Off-chain applications largely speak the language of Web services, i.e., REST,
SOAP-WSDL, JSON RPC or similar. Therefore, a recurring problem when
building blockchain applications is how to bridge between the two worlds. A
solution we have employed a number of times is to add a so-called trigger com-
ponent as bridge between applications and smart contracts. This component,
originally introduced in [16], operates in both directions, i.e., reading from and
writing to blockchain. Strictly speaking, the method should apply even when not
using smart contracts; but we here focus on the case where smart contracts are
used.
The operation of triggers is shown in Fig. 1. In the case shown, applications
of two organisations (Org 1 and Org 2 ) use a smart contract on blockchain to
coordinate and interact. One direction of data flow is shown with solid arrows,
the other with dashed arrows. Following the solid arrows: if an application of
Org 1 wants to write to the smart contract, it invokes a Web service interface of
its trigger component, which in turn creates a blockchain transaction to call a
method of the smart contract. In the shown case, the trigger component of Org 2
observes the update from the event log or variable values of the smart contract,
and in turn invokes a Web service exposed by another of Org 2 ’s applications.
This application can respond in a similar fashion, as indicated by the dashed
arrows. It should be noted that there is no need for the two organisations to
coordinate their use of trigger components. The coordination and agreement
needs to be about the smart contract’s data and functionality, and the purpose
of trigger components is to facilitate the integration with other components that
use conventional Web service protocols. Numerous alternatives to triggers exist,
e.g., by adding blockchain capabilities directly to the enterprise applications.
4 Ingo Weber
While the figure shows the interaction of two organisations, it is easy to
generalise from this view to many organisations, and to various communica-
tion patterns. This style of communication certainly incurs additional overhead
in comparison to direct service integration between the applications of organi-
sations: more components, longer latency, potentially limited throughput, and
possibly limited control over the blockchain. However, it also has different prop-
erties, such as easier scaling to more organisations (where each application needs
to integrate only with one blockchain/smart contract, as opposed to integrat-
ing with many other enterprise applications), immutability and non-repudiation
of writes, global observability, and many other possibilities that come with the
use of smart contracts. This includes also composition logic as discussed below,
which is executed on a neutral platform – the blockchain – that is typically not
controlled by a single entity.
3 Service Composition using Smart Contracts
Blockchain and smart contracts also offer a new way to enable collaborative
business processes and implement web services composition across organizations,
by serving as a neutral, independently auditable compute platform [6]. This can
be supported by the technology in a number of ways. Specifically, one method
is to translate composition models to smart contract code [4,16] using tools
such as Caterpillar [5] or Lorikeet [13]. An alternative method is flexible process
tracking [8], using the blockchain as a mechanism to track process control via
tokens. The focus in the latter case is on tracking handover activities between
organisations or individuals, secured by multiple cryptographic signatures.
Web service composition can take the form of an orchestration or a choreogra-
phy. Both styles of composition have been explored in the context of blockchain,
among others in the papers listed above. But blockchain itself stretches the
boundaries of those notions – for instance, by enabling choreographies to con-
tain active code that is not executed at either party, but instead on the neutral
substrate of the blockchain, an option that was not present in choreography
modelling beforehand. These topics deserve further investigation. In a recent re-
search commentary, we broadly discussed the challenges and opportunities for
cross-organizational business process implementation using blockchain [6].
4 Blockchain-as-a-Service
Blockchain is a relatively new technology with steep learning curve. Accord-
ing to a survey by Gartner [9], “23 percent of [relevant surveyed] CIOs said
that blockchain requires the most new skills to implement of any technology
area, while 18 percent said that blockchain skills are the most difficult to find.”
Blockchain-as-a-Service (BaaS) offerings can bootstrap that learning phase to
a degree, through pre-made templates or tools for management, development,
Blockchain and Services – Exploring the Links 5
monitoring, etc. However, it is important not all nodes of a blockchain are run-
ning on machines of the same BaaS provider: blockchain introduces decentrali-
sation, but being entirely reliant on a single provider introduces a form of cen-
tralisation on a different level, and might negatively impact benefits obtained
from using blockchain.
In some currently unpublished research, we investigate the idea of a uni-
fied blockchain as a service (uBaas) platform, which is vendor and technology
platform-agnostic. The main functionalities include deployment as a service,
both for blockchain systems and smart contracts, and design patterns as a ser-
vice. The latter functionality exposes common services for data management
and smart contract design, which allow implementing known design patterns
to better leverage the unique properties of blockchain (i.e., immutability, data
integrity, and transparency) and address the limitations (i.e., privacy and scal-
ability). The patterns are based on the collection presented in [17].
Technology and vendor lock-in might be severe concerns in the future, and
much work needs to be done to facilitate the integration of applications across
blockchains. Significant efforts are spent on protocols and tools that cross these
boundaries. It might be possible to refer to well-known service composition ap-
proaches and paradigms as guides for research in this direction.
5 Service Design Principles and Smart Contracts
Before delving into the details of relating service design principles and smart con-
tracts, it is worthwhile discussing microservices, because their design principles
deviate from traditional SOA services.
While SOA services can be substantial in scope and complexity, the concept
of building smaller services, referred to as microservices, has gained popularity in
recent years. For instance, microservice architecture is a fitting architectural style
for DevOps [1]. Microservice architecture is in wide-spread use now, especially for
new development projects. Each service provides small amount of functionality,
and the total system functionality comes from composing multiple services –
but typically without relying on WS* methods of service composition, which is
rather done in code.
There is some similarity of SOA services and microservices with smart con-
tracts. Smart contract code can be compared to a Java Class, and a deployed
smart contract is similar to Java Object in that its variables have concrete values,
etc. However, a deployed smart contract has some specific properties: it has a de-
fined interface (although it may be unknown); there is a standard way to invoke
it; and it is callable by anyone who can send transactions to the blockchain on
which the contract is deployed. These properties are shared with Web services.
Therefore, some design principles from services could apply to smart contracts.
In Tables 1and 2, I list the service design principles for SOA services and
microservices, and discuss to which degree they might apply to smart contracts.
Table 1 lists the Service-Orientation Design Principles from [3], with summary
explanations from [14]. The principles of microservice design in Table 2 are
6 Ingo Weber
SOA Service Design Principle Fit to SC Rationale
Standardized Service Contract: the public
interfaces of a services make use of con-
tract design standards. (Contract: WSDL in
WS*)
Aspirational Not present as yet, but
would be useful
Service Loose Coupling: to impose low bur-
dens on service consumers (coupling as de-
gree of dependency)
Yes Should be done for smart
contracts as well
Service Abstraction: “to hide as much of the
underlying details of a service as possible”
Yes Abstraction is a fitting de-
sign principle for smart con-
tracts, and the design of
their public interface de-
serves careful attention
Service Reusability: services contain agnos-
tic logic and “can be positioned as reusable
enterprise resources”
Sometimes Might apply to some smart
contracts, but not often a
core concern
Service Autonomy: to provide reliable and
consistent results, a service has to have
strong control over its underlying environ-
ment
Yes Smart contract control is
strong, but limited in scope
Service Statelessness: services should be
“designed to remain stateful only when re-
quired.”
Rarely Typical contracts carry
state, although sometimes
it is useful to push state
out
Service Discoverability: “services are supple-
mented with communicative meta data by
which they can be effectively discovered and
interpreted.”
Aspirational Not present as yet, but
would be useful
Service Composability: “services are effec-
tive composition participants, regardless of
the size and complexity of the composition.”
Sometimes Might apply to some smart
contracts, but not often a
core concern
Fundamental requirement – interoperability
of services: “. . .stating that services must
be interoperable is just about as evident as
stating that services must exist.”
Rarely Enabling smart contracts
to interoperate directly is
rarely a core concern; li-
braries and common ser-
vices are of course excep-
tions
Table 1. Fit of SOA Service Design Principles to smart contracts
Blockchain and Services – Exploring the Links 7
Microservice Design
Principle
Fit to SC Rationale
Small, focused functionality Yes Each smart contract should be focused on
doing few things, but doing those well
Split of responsibility Yes Smart contracts often have limited scope, for
which they are fully responsible
Full-stack Sometimes Depending on the context, full-stack or split
contracts might be the better choice
Independently updatable
without downtime
Sometimes Updates can be independent; but reliance on
the inability of anyone to update without
agreement / governance is one source of trust
in smart contracts
Stateless Rarely Typically contracts carry state (see Table 1)
Table 2. Fit of Microservice Design Principles to smart contracts
mostly derived from [7,12]. In the time between giving the talk and writing
this paper, Daniel and Guida wrote an article that explores a comparable angle,
although their comparison is through the lens of five categories: service/contract
type, interaction style, interaction protocol, data format, and descriptor [2]. They
too come to the conclusion that smart contract design would benefit from reuse
facilities of services, such as discoverability.
Further to the discussion about abstraction in the tables, architects do need
to understand, however, that smart contract (binary) code is visible to other
users on most blockchain platforms. As such, implementation details can only
be “hidden” in the design sense, not in the security sense – malicious users could
re-engineer smart contracts, or attempt attacks (though local calls that are not
broadcast) without the knowledge of anyone in the blockchain network.
As can be seen from the tables, many design principles apply in at least some
of the cases. Some are aspirational, in that current practice does not follow these
principles, but changing the practice would be beneficial in the smart contract
context.
Blockchains and smart contracts could also be used in other, interesting ways.
For instance, stateless (or even serverless) services could use smart contracts on
blockchain as persistence layer. Such an architecture would especially benefit
scenarios with high or highly distributed read and low-frequency write profiles.
6 Summary
Architecting and developing applications on Blockchain is challenging. Our re-
search includes works on Software Architecture for blockchain-based applica-
tions, empirical and formal research on blockchains, and model-driven develop-
ment of smart contracts.
Regarding the links between services and blockchain, this paper and the
keynote discussed four main aspects: First, for the integration of blockchain-
8 Ingo Weber
based applications with off-chain applications, which often use service inter-
faces, we proposed using a trigger component. Second, service composition can
be achieved using smart contracts as neutral mediators, choreography moni-
tors, or other means. Our work in this area often starts with models of cross-
organisational business processes for expressing service compositions. Third,
Blockchain-as-a-Service can be beneficial for bootstrapping blockchain deploy-
ments. And fourth, there are some similarities between smart contracts, and
some of the well-studied design principles for SOA services and microservices
apply.
In this space, there are still many open research questions. This paper pre-
sented some early and some more mature ideas, and I hope these will motivate
researchers to work in this very interesting field.
Acknowledgements
My thanks for feedback and insightful discussions go to the audience at the
symposium, as well as my colleagues Mark Staples, Hugo O’Connor, Hye-young
Paik, Dilum Bandara, and Liming Zhu.
References
1. Bass, L., Weber, I., Zhu, L.: DevOps: A Software Architect’s Perspective. Addison-
Wesley Professional (2015). https://doi.org/10.1007/978-0-134-04984-7
2. Daniel, F., Guida, L.: A service-oriented perspective on blockchain smart contracts.
IEEE Internet Computing (01 2019). https://doi.org/10.1109/MIC.2018.2890624
3. Erl, T.: SOA Principles of Service Design. Prentice Hall (2007), http://
serviceorientation.com/serviceorientation
4. Garc´ıa-Ba˜nuelos, L., Ponomarev, A., Dumas, M., Weber, I.: Optimized execution
of business processes on blockchain. In: BPM’17: International Conference on Busi-
ness Process Management. Barcelona, Spain (Sep 2017)
5. L´opez-Pintado, O., Garc´ıa-Ba˜nuelos, L., Dumas, M., Weber, I.: Caterpillar: A
blockchain-based business process management system. In: BPM’17: International
Conference on Business Process Management, Demo track. Barcelona, Spain (Sep
2017)
6. Mendling, J., Weber, I., Aalst, W.V.D., Brocke, J.v., Cabanillas, C., Daniel, F.,
Debois, S., Ciccio, C.D., Dumas, M., Dustdar, S., Gal, A., Garc´ıa-Ba˜nuelos, L.,
Governatori, G., Hull, R., Rosa, M.L., Leopold, H., Leymann, F., Recker, J., Re-
ichert, M., Reijers, H.A., Rinderle-Ma, S., Solti, A., Rosemann, M., Schulte, S.,
Singh, M.P., Slaats, T., Staples, M., Weber, B., Weidlich, M., Weske, M., Xu, X.,
Zhu, L.: Blockchains for business process management – challenges and oppor-
tunities. ACM Transactions on Management Information Systems (TMIS) 9(1),
4:1–4:16 (Feb 2018). https://doi.org/10.1145/3183367
7. Newman, S.: Building Microservices. O’Reilly Media (2015)
8. Prybila, C., Schulte, S., Hochreiner, C., Weber, I.: Runtime verification for business
processes utilizing the Bitcoin blockchain. Future Generation Computer Systems
(FGCS) (Aug 2017). https://doi.org/10.1016/j.future.2017.08.024
Blockchain and Services – Exploring the Links 9
9. Release, G.P.: Gartner survey reveals the scarcity of current blockchain deploy-
ments (May 2018), https://www.gartner.com/newsroom/id/3873790, accessed: 4
May 2018
10. Rimba, P., Tran, A.B., Weber, I., Staples, M., Ponomarev, A., Xu, X.: Comparing
blockchain and cloud services for business process execution. In: ICSA’17: IEEE
International Conference on Software Architecture, short paper. Gothenburg, Swe-
den (Apr 2017)
11. Rimba, P., Tran, A.B., Weber, I., Staples, M., Ponomarev, A., Xu, X.: Quantifying
the cost of distrust: Comparing blockchain and cloud services for business process
execution. Information Systems Frontiers (2018)
12. Subramanian, S.: Microservices design principles. DZone (Jul 2015), https:
//dzone.com/articles/microservices-design-principles, last accessed: 28
March 2019
13. Tran, A.B., Lu, Q., Weber, I.: Lorikeet: A model-driven engineering tool for
blockchain-based business process execution and asset management. In: BPM’18:
International Conference on Business Process Management, Demo track (Sep 2018)
14. Weber, I.: Semantic Methods for Execution-level Business Process Modeling. Ph.D.
thesis, Universit¨at Karlsruhe (TH) (Nov 2009). https://doi.org/10.1007/978-3-642-
05085-5, springer, LNBIP Vol. 40
15. Weber, I., Gramoli, V., Staples, M., Ponomarev, A., Holz, R., Tran, A., Rimba,
P.: On availability for blockchain-based systems. In: SRDS’17: IEEE International
Symposium on Reliable Distributed Systems. pp. 64–73. Hong Kong, China (Sep
2017)
16. Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomarev, A., Mendling, J.: Un-
trusted business process monitoring and execution using blockchain. In: BPM’16:
International Conference on Business Process Management. Rio de Janeiro, Brazil
(Sep 2016)
17. Xu, X., Pautasso, C., Zhu, L., Lu, Q., Weber, I.: A pattern language for blockchain-
based applications. In: EuroPLoP’18: European Conference on Pattern Languages
of Programs. Kloster Irsee, Germany (Jul 2018)
18. Xu, X., Weber, I., Staples, M.: Architecture for Blockchain Applications. Springer
(2019). https://doi.org/10.1007/978-3-030-03035-3
19. Xu, X., Weber, I., Staples, M., Zhu, L., Bosch, J., Bass, L., Pautasso, C., Rimba,
P.: A taxonomy of blockchain-based systems for architecture design. In: ICSA’17:
IEEE International Conference on Software Architecture. Gothenburg, Sweden
(Apr 2017)
20. Yasaweerasinghelage, R., Staples, M., Weber, I.: Predicting latency of blockchain-
based systems using architectural modelling and simulation. In: ICSA’17: IEEE
International Conference on Software Architecture, short paper. Gothenburg, Swe-
den (Apr 2017)
... In certain cases, the processing of smart contract's function invocations is described as being similar to the FaaS processing model [82]. Moreover, some blockchain-focused papers try designing systems that combine blockchains and FaaS-based architectures to realize blockchain-related operations using more serverlessstyle components [83,84,85,86,87,88]. For example, Kaplunovich et al. [87] use a serverless AWS-based architecture to benchmark blockchains, benefiting from the simplified interaction with the provider-managed offerings such as AWS Lambda and AWS DynamoDB. ...
Preprint
Although historically the term serverless was also used in the context of peer-to-peer systems, it is more frequently associated with the architectural style for developing cloud-native applications. From the developer's perspective, serverless architectures allow reducing management efforts since applications are composed using provider-managed components, e.g., Database-as-a-Service (DBaaS) and Function-as-a-Service (FaaS) offerings. Blockchains are distributed systems designed to enable collaborative scenarios involving multiple untrusted parties. It seems that the decentralized peer-to-peer nature of blockchains makes it interesting to consider them in serverless architectures, since resource allocation and management tasks are not required to be performed by users. Moreover, considering their useful properties of ensuring transaction's immutability and facilitating accountable interactions, blockchains might enhance the overall guarantees and capabilities of serverless architectures. Therefore, in this work, we analyze how the blockchain technology and smart contracts fit into the serverless picture and derive a set of scenarios in which they act as different component types in serverless architectures. Furthermore, we formulate the implementation requirements that have to be fulfilled to successfully use blockchains and smart contracts in these scenarios. Finally, we investigate which existing technologies enable these scenarios, and analyze their readiness and suitability to fulfill the formulated requirements.
Article
Full-text available
Smart contracts turn blockchains into distributed computing platforms. This article studies whether smart contracts as implemented by state-of-the-art blockchain technology may serve as component technology for a computing paradigm like service-oriented computing (SOC) in the blockchain, in order to foster reuse and increase cost-effectiveness.
Article
Full-text available
Blockchain is of rising importance as a technology for engineering applications in cross-organizational settings, avoiding reliance on central trusted third-parties. The use of blockchain, instead of traditional databases or services, is an architectural choice in the development of a software system. Architecture impacts the non-functional qualities of systems, creating design trade-offs between these qualities. The costs of execution and storage are important non-functional qualities, but as yet little is known about them for blockchain-based systems. How expensive is it to use blockchains compared to conventional execution and storage infrastructure? We investigate this question using business process execution as a lens. Specifically, we compare the cost for computation and storage of business process execution on blockchain vs. a popular cloud service. Besides monetary cost, blockchains like Ethereum limit the complexity of new blocks by capping costs through network-defined limits. For applications using such blockchains, the limit per block, thus, translates into an upper bound on throughput scalability. First, we implement and measure the cost of business process execution on blockchain and cloud services for a business process model from a large-scale industrial dataset and an example from literature. We observe two orders of magnitude difference in this cost. Second, we illustrate how cost models can be used to project the impact of different workload assumptions. Finally, we discuss throughput scalability limits as well as trade-offs between cost and other non-functional qualities in the design of blockchain-based systems.
Conference Paper
Full-text available
[This is a pre-publication version of the paper; the content is likely to change for the final publication version.] Blockchain is an emerging technology that enables new forms of decentralized software architectures, where distributed components can reach agreements on shared system states without trusting a central integration point. Blockchain provides a shared infrastructure to execute programs, called smart contracts, and to store data. Since blockchains are at an early stage, there is a lack of a systematic and holistic view on designing software systems that use blockchain. We view blockchain as part of a bigger system, which requires patterns of using blockchain in the design of the bigger systems. In this paper, we collect a list of patterns for blockchain-based applications. The pattern collection is categorized into four types, including interaction with external world patterns, data management patterns, security patterns and contract structural patterns. Some patterns are designed specifically based on real-world blockchain-based applications considering the nature of blockchain.Others are variants of existing design patterns applied in the context of blockchain-based applications and smart contracts.
Article
Full-text available
The usage of process choreographies and decentralized Business Process Management Systems has been named as an alternative to centralized business process orchestration. In choreographies, control over a process instance is shared between independent parties, and no party has full control or knowledge during process runtime. Nevertheless, it is necessary to monitor and verify process instances during runtime for purposes of documentation, accounting, or compensation. To achieve business process runtime verification, this work explores the suitability of the Bitcoin blockchain to create a novel solution for choreographies. The resulting approach is realized in a fully-functional software prototype. This software solution is evaluated in a qualitative comparison. Findings show that our blockchain-based approach enables a seamless execution monitoring and verification of choreographies, while at the same time preserving anonymity and independence of the process participants. Furthermore, the prototype is evaluated in a performance analysis
Article
Full-text available
(Note that we have updated the paper to the accepted version on 23 Jan 2018) Blockchain technology offers a sizable promise to rethink the way inter-organizational business processes are managed because of its potential to realize execution with- out a central party serving as a single point of trust (and failure). To stimulate research on this promise and the limits thereof, in this paper we outline the challenges and opportunities of blockchain for Business Process Management (BPM). We structure our commentary alongside two established frameworks, namely the six BPM core capabilities and the BPM lifecycle, and detail seven research directions for investigating the application of blockchain technology to BPM.
Conference Paper
Full-text available
Blockchain is an emerging technology for sharing transactional data and computation without using a central trusted third party. It is an architectural choice to use a blockchain instead of traditional databases or protocols, and this creates trade-offs between non-functional requirements such as performance, cost, and security. However, little is known about predicting the behaviour of blockchain-based systems. This paper shows the feasibility of using architectural performance modelling and simulation tools to predict the latency of blockchain-based systems. We use established tools and techniques, but explore new blockchain-specific issues such as the configuration of the number of confirmation blocks and inter-block times. We report on a lab-based experimental study using an incident management system, showing predictions of median system level response time with a relative error mostly under 10%. We discuss how the approach can be used to support architectural decision-making, during the design of blockchain-based systems.
Conference Paper
Full-text available
Blockchain is of rising importance as a technology for engineering applications in cross-organizational settings, avoiding reliance on central trusted third-parties. The use of blockchain, instead of traditional databases or services, is an architectural choice in the development of a software system. The costs of execution and storage are important non-functional qualities, but as yet very little has been done to study them for blockchain-based systems. We investigate the cost of using blockchain using business process execution as a lens. Specifically, we compare the cost for computation and storage of business process execution on blockchain vs. a popular cloud service. First, we capture the cost models for both alternatives. Second, we implemented and measured the cost of business process execution on blockchain and cloud services for an example business process model from the literature. We observe two orders of magnitude difference in this cost.
Book
This book addresses what software architects and developers need to know in order to build applications based on blockchain technology, by offering an architectural view of software systems that make beneficial use of blockchains. It provides guidance on assessing the suitability of blockchain, on the roles blockchain can play in an architecture, on designing blockchain applications, and on assessing different architecture designs and tradeoffs. It also serves as a reference on blockchain design patterns and design analysis, and refers to practical examples of blockchain-based applications. The book is divided into four parts: Part I provides a general introduction to the topic and to existing blockchain platforms including Bitcoin, Ethereum, and Hyperledger Fabric, and offers examples of blockchain-based applications. Part II focuses on the functional aspects of software architecture, describing the main roles blockchain can play in an architecture, as well as its potential suitability and design process. It includes a catalogue of 15 design patterns and details how to use model-driven engineering to build blockchain-based applications. Part III covers the non-functional aspects of blockchain applications, which are cross-cutting concerns including cost, performance, security, and availability. Part IV then presents three detailed real-world use cases, offering additional insights from a practical perspective. An epilogue summarizes the book and speculates on the role blockchain and its applications can play in the future. This book focusses on the bigger picture for blockchain, covering the concepts and technical considerations in the design of blockchain-based applications. The use of mathematical formulas is limited to where they are critical. This book is primarily intended for developers, software architects and chief information officers who need to understand the basic technology, tools and methodologies to build blockchain applications. It also provides students and researchers new to this field an introduction to this hot topic.
Conference Paper
This demonstration introduces Caterpillar, an open-source Business Process Management System (BPMS) that runs on top of the Ethereum blockchain. Like any BPMS, Caterpillar supports the creation of instances of a process model (captured in the Business Process Model and Notation – BPMN) and allows users to track the state of process instances and to execute tasks thereof. The specificity of Caterpillar is that the state of each process instance is maintained on the Ethereum blockchain, and the workflow routing is performed by smart contracts generated by a BPMN-to-Solidity compiler. The compiler supports a wide array of BPMN constructs, including user, script and service tasks, parallel and exclusive gateways, subprocesses, multi-instance activities and event handlers. The target audience of this demonstration includes researchers in the area of business process management and blockchain technology.