1 Introduction

Over the past decade, cloud technologies have been developed at an unprecedented speed, whilst cloud-based applications have increasingly penetrated all areas of industry, e.g., E-commerce [1] and intelligent manufacturing [2]. Cloud services allow companies and individuals to focus on their core business and researches whilst gain the benefits from software resources that are managed by third parties at remote locations. Thus, a service marketplace providing rapid, flexible and trusted outsourcing of computing services is in demand.

Conventional services are developed and deployed in the form of monolithic computation units, in which all the code is interwoven into one large piece [3]. As a result, the monolith hinders the scalability and efficiency of client applications, especially when the number of participant services is increased. To address the issue, Function-as-a-Service (FaaS) is proposed, by means of structuring a serverless architecture that decomposes software applications into fine-grained functions [4]. Such functions are further invoked remotely at runtime. Therefore, our proposed marketplace is FaaS oriented.

On the other hand, most of the cloud services are offered in a centralized manner. Figure 1(a) demonstrates a centralized marketplace, in which off-the-shelf functions are gathered by a service provider, and further remotely invoked by clients. During the transaction process, there is no direct communication between third parties and clients. However, in many cases, customers demand more specific functions with strategic flexibility for ad hoc domains. Furthermore, they want to keep cost transparent and lower the risk of investment. Likewise, sellers also have concerns about the security in the trade, e.g., the privacy of their algorithms and data. Hence, we establish a decentralized market governed by blockchain.

Fig. 1.
figure 1

Main entities and interactions in marketplaces.

Full size image

Blockchain used to be defined as a distributed ledger for recording unalterable transactions of any digital asset [5]. With the integration of smart contract, it has evolved to blockchain 2.0, which refers to a programmable distributed trust infrastructure that enables the decentralization of markets more generally [6]. Undoubtedly, it becomes the most promising technology to create a decentralized service marketplace. Figure 1(b) expresses such a marketplace, which is essentially a peer-to-peer (P2P) network. The interconnected users share resources among each other without the usage of a centralized service provider. The blockchain plays an important role in our marketplace. Its usages include but not limit to (i) identifying every stakeholder in the open market by digital ID; (ii) monitoring supply chains that every service can be traced back to its original owner; (iii) depositing every transaction after the smart contract is executed; and (iv) protecting the copyrights by verification of contents. The details will be discussed below.

In this paper, we integrate a novel service composition model, namely BOX-MAN, with blockchain technology, with the purpose of establishing a decentralized service marketplace. In Sect. 3, we explain the research motivation by an example. In Sect. 4, we introduce BOX-MAN service model, including its structure, semantics and composition mechanism. Then, in Sect. 5, we demonstrate the prototype of our decentralized marketplace in terms of a platform based on the integration of BOX-MAN model and blockchain. Section 7 discusses the advantages of BOX-MAN, along with the proposed decentralized service marketplace. The final section makes a conclusion and looks forward to the future work.

2 Related Work

2.1 Serverless Computing

The concept of serverless computing originally refers to P2P software [7]. In the cloud era, serverless computing refers to an execution model that allows software engineers focus on their core business by developing and deploying code into production without concerning the server. Notably, the serverless solutions are in effect server-hidden, i.e., the physical servers are still adopted, but scaling planning and maintenance operations are hidden from the user [8].

Most of the cloud providers offer databases and underlying storage services for serverless computing. Moreover, many providers establish a platform offering function-as-a-service (FaaS), such as AWS Lambda and Google Cloud Functions [9]. These platforms usually support edge computing, so code segments can be executed closer to the location where they are needed [10].

Serverless computing has several advantages, as listed below [11]:

  • Cost. Comparing to renting or purchasing servers, serverless computing is much cheaper, due to the clients do not need to pay for underutilization or idle time.

  • Scalability. Adding or updating computation resources is no longer relying on developers. Instead, the cloud provider is responsible for scaling the capacity to the demand.

  • Productivity. Traditional software engineering has many concerns, such as multi-threading processes or dependencies between modules. Serverless computing requires less programming knowledge.

2.2 Blockchain

Blockchain is one of the most promising technologies in the future, because it has the abilities of (i) encouraging data sharing, (ii) optimizing business processes, (iii) reducing operating costs, (iv) improving collaboration efficiency and (v) building trustworthy systems. At present, blockchain has been adopted in many industry domains, such as supply chains, intellectual property protection, digital voting, medical recordkeeping and so forth [12].

Blockchain has several advantages, as listed below [13]:

  • Decentralization. Blockchain does not contain a central data hub. Instead, it deposits data across a P2P network. Hence, the blockchain eliminates a number of risks caused by centralized points of vulnerability and failure. For example, if a node in the network is hacked, we can still restore the data through other nodes.

  • Transparency. All data on the blockchain is public, i.e., any user can access any data stored on the blockchain.

  • Traceability. In blockchain, the history of transaction is deposited in the blocks, which are connected one after another. Therefore, every transaction can be traced.

  • Self-governing. Blockchain is organized and managed by every node, since every transaction must be validated and confirmed via consensus. Thus, blockchain upholds a trustworthy system.

Since the second generation of blockchain, users can achieve agreements among parties through smart contracts. Simply put, smart contracts can be considered as electronic contracts that can be partially or fully executed or enforced without human interaction [14]. It is worth noting that a smart contract cannot be modified or withdrew after it is deployed on the blockchain.

2.3 Service Marketplace

At present, there are many cloud service providers (CSPs) on the market, but most of them just peddle their software frameworks as development tools that allow developers to build and launch their own applications, or issue some very common APIs such as map or weather forecast. Simply put, what these CSPs sell are more of commodity products than services [15]. In fact, a service is largely a piece of commodity product, e.g.., a well-trained neural network, which is acquired by customers to fill the placeholder in their own applications. Only a few of CSPs provides vendor-dedicated marketplaces.

Unfortunately, limitations still exist in current vendor-dedicated marketplaces. Because services are more complex to understand than ready-to-go products, CSPs can just label the services and let customers search what they want by a set of keywords. As a consequence, it is inevitable that for every acquisition customers spend a lot of time and effort interacting with the service provider [16]. Moreover, customers are not allowed to systematically compare all available services across different service providers, especially when CSPs want to promote their own services.

It becomes obvious that a decentralized service marketplace is the most promising solution to improve the effectiveness and efficiency of service acquisition.

3 Motivating Example

Deep learning has been increasingly applied in various specialties in medicine [17], such as radiology, imaging and disease diagnosis. A practical intelligent healthcare application usually consists of several well-trained deep learning models, each of which is a multi-layer neural network that processes medical data in a hierarchical fashion. Thereby, it becomes obvious that AI algorithms and datasets are crucially important in intelligent healthcare. However, some medical domains are close enough to share parts of the functional requirement, along with similar (even identical) datasets. Hence, during the development of an intelligent medical application, we can take advantage of reusing AI functions from existing ones. In this section, we use an example to demonstrate our research motivation.

Fig. 2.
figure 2

Two AI applications containing same functions.

Full size image

Figure 2 shows that Alice plans to develop an AI-based application for brain tumor diagnosis, whereas Bob already implemented an Alzheimer’s disease diagnosis application. Both applications require user to upload the brain MRI scans for pre-processing, segmentation and registration, with the aim of obtaining the normalized information for further analysis. Apparently, Alice can save time and computing resource if she reuses some functions of Bob’s software. But, here is the problem: Bob’s post-trained AI model is formed as a monolithic code file, in which the couplings between code segments would hinder the extraction and reuse of required functions. Thus, the first task of our research is to investigate a reuse mechanism for intelligent applications.

Notwithstanding, let us assume the reuse issues are addressed. Now, Alice sends a query about a particular AI function in the network. Four strangers, namely Bob, Charlie, Dave and Eve, respond and claim to have the functions conforming with the requirement. Unfortunately, Alice can only afford one function among them. In order to pick up the most suitable AI function, she need to make a comparison before the trade.

Fig. 3.
figure 3

Sharing strategies in marketplace.

Full size image

As Fig. 3(a) shows, Alice tries to solves the problem by sending the test data to all four strangers. Ideally, she will receive four test results for comparison. However, Fig. 1(a) illustrates the risks possibly happening in the procedure. For example, Charlie’s function is not actually fit, so it returns invalid result; while Dave forges the result to make sure that he can win the contract, and Eve somehow does not respond at all. As a consequence, Alice perhaps choose Charlie or Dave, even though only Bob gives back the valid and honest result.

Now, Alice realizes the flaws in her solution. Therefore, she proposes a workaround with reverse process, i.e., other AI developers send her the AI functions. Subsequently, Alice checks the functions, runs the execution with test data, selects the optimized one and eventually returns the unselected AI functions. Undoubtedly, her initiative is not accepted by others, due to the risk is transferred to them. For example, as depicted in Fig. 3(b), Alice can analyze Bob’s code via reverse engineering, and refactor the function in her own way, which in essence is plagiarism. Moreover, Alice can share Bob’s AI function or her refactored function to others, which severely violates Bob’s intellectual property rights.

The lesson from the previous try-outs is that direct trades between buyers and sellers are not safe. Thus, Alice and Bob decide to introduce centralized management. As Fig. 3(c) shows, Trent plays a role as a trusted third-party, who receives test data from Alice and AI function from Bob, respectively. Then, Trent can perform the testing and return the result to both Alice and Bob. However, this method is not flawless because Trent can be the loophole. He can easily gather tremendous information in the network, and misuse them without supervision.

The blockchain technology gives us a glimmer of hope to address the issues in our motivating example. For instance, every transaction can be recorded in the decentralized database, whereas every trader’s behavior can be constrained by smart contracts. However, keeping using tangling and scattering code within disorganized systems as shown in Fig. 2 does not help. In order to unlock the full potential of blockchain, we need a platform that promotes understanding, communication and negotiation between all stakeholders, captures early decisions about the system designs, and supports large-scale adoption with flexibility and complexity considerations.

4 BOX-MAN

In this section, we put forward a service composition model, called BOX-MAN (Blockchain-Oriented X-MAN), which is inspired by X-MAN component model and its extensions [18,19,20]. In our proposed platform, we adopt BOX-MAN to design and implement systems, as well as to establish the smart contracts. In addition, BOX-MAN can be used for content verification. Figure 4 illustrates the BOX-MAN constructs which we further describe below.

The BOX-MAN model defines two types of services: atomic or composite, and three kinds of connectors: composition, adaptation and parallel connector. An atomic service encapsulates a set of methods in the form of an input-output function with a purpose that different services can access. A composite service consists of sub-services (atomic or composite) composed by exogenous composition connectors, which coordinate control flows between sub-services from the outside. Therefore, services are unaware they are part of a larger piece of behavior.

Fig. 4.
figure 4

BOX-MAN: Service models.

Full size image

Notably, BOX-MAN model defines algebraic service composition [21, 22]. This idea is enlightened by algebra where functions are composed hierarchically into a new function of the same type. Hereby we utilize a composition connector as an operator to hierarchically compose multiple sub-services into a bigger service, while the resulting service can be further composed with other services, yielding a more complex one.

Fig. 5.
figure 5

BOX-MAN: Composition connectors.

Full size image

There are two types of composition connectors: sequencer and selector. The former defines sequencing, while the latte defines branching. For example, in Fig. 5(a)Footnote 1, \(S_0\) is a composite service composed by \(S_1\), \(S_2\) and \(S_3\). The execution order of sub-services is defined by numbers in ascending order. Therefore, when \(S_0\) is invoked, virtually sub-services \(S_1\), \(S_2\) and \(S_3\) are executed one after another. Similarly, in Fig. 5(b), the control flow of \(S_0\) is coordinated by a selector with conditions. So, when \(S_0\) is invoked, only one sub-service should be executed (or none if no condition is satisfied) according to the parameter received by the selector.

Unlike the composition connectors, the adaptation connectors do not compose services. Instead, they are applied to individual services with the aim of adapting the received controls. As Fig. 6(a) and 6(b) show respectively, a guard connector allows control to reach a service only if the condition is satisfied, while a loop connector repeats control to a component a fixed number of times until the condition is no longer fulfilled.

Fig. 6.
figure 6

BOX-MAN: Adaptation connectors.

Full size image

Except for the composition and adaptation connectors, BOX-MAN additionally defines a parallel connector to handle the parallel invocation of sub-services. As shown in Fig. 7, when \(S_0\) is invoked, all its sub-services are executed simultaneously.

Fig. 7.
figure 7

BOX-MAN: Parallel connectors.

Full size image

While the exogenous connectors coordinate the control flows, the data channels coordinate the data flows. After a composite service is structured, we need to add data channels between services in order to define the direction of each data flow. Such a channel links the input and output of services. Figure 4 demonstrates two types of data channels in the composite service: horizontal data routing and vertical data routing [23]. The former is between two individual services, which indicates a service passes the outcome data to another. The latter is data propagation between the services and its sub-services, which illustrates the data received by the composite service is passed to the first invoked sub-service, whereas the outcome data of last invoked sub-service becomes the output of the composite service.

In the next section, we present an example that shows how to use the BOX-MAN composition semantic to construct services on our platform and related smart contracts of the blockchain.

5 The Proposed Platform

We hereby present an example of a blockchain-based platform using BOX-MAN for service trading.

In Sect. 3, we discuss that an intelligent application is usually composed by several AI services, such as Bob’s Alzheimer’s disease diagnosis application in Fig. 2. Because of the algebraic nature of BOX-MAN, such an AI application can be designed and implemented in the form of an algebraic service composition. For example, as depicted in Fig. 8, Eve develops an application with five accessible services, which consists of three atomic services (\(A_1\), \(A_2\) and \(A_3\)) and two composite ones (\(S_E\) and \(S_0\)). Notably, \(S_E\) is a composition of \(A_2\) and \(A_3\), while \(S_0\) is a composition of \(A_1\) and \(S_E\). As a result, Eve can share the five services (or their functional specifications) on the platform without exposing the encapsulated code.

Fig. 8.
figure 8

Eve shares five AI services.

Full size image
Fig. 9.
figure 9

Step 1: Alice asks for the AI services she desires.

Full size image

Now, Alice desires an AI service of image registration for brain MRI, as we mention in Sect. 3. Then, she starts to search the appropriate services, and eventually finds out four potential results: \(S_B\), \(S_C\), \(S_D\) and \(S_E\). As Fig. 9 illustrates, Alice makes requests to Bob, Charlie, Dave and Eve, respectively. Dave rejects her proposal, whereas others approve.

Fig. 10.
figure 10

Step 2: Alice negotiates with others.

Full size image

After that, Alice negotiates conditions with Bob, Charlie and Eve, respectively. For instance, if Alice makes a decision to accept Bob’s AI service, she may pay Bob some credits for it. Such a deal is realized by programming encapsulated in a BOX-MAN service, which is further adopted in the smart contract deployed at the platform layer. In Fig. 10, the negotiation between Alice and Charlie breaks down, but Bob and Eve approve their conditions, i.e., \(C_B\) and \(C_E\) are implemented and deployed at Bob’s and Eve’s nodes, respectively.

The next step is crucial. Alice must establish a fair mechanism in order to choose the optimized service out of Bob’s and Eve’s AI services (\(S_B\) and \(S_E\)). Figure 11 demonstrates a smart contract by means of a distributed BOX-MAN composite service. In this case, Alice sends the same set of test data to \(S_B\) and \(S_E\) simultaneously for execution. Subsequently, two sets of actual results, as well as a set of expected result, are automatically sent to \(S_J\). The main functions of \(S_J\) are (i) respectively investigating how many predictions in the actual results are correct, and (ii) determining the better service according to the accuracies. After that, the decision will be passed to the selector. Finally, if \(S_B\) is the winner, contract \(C_B\) will be executed, and vice versa.

Fig. 11.
figure 11

Step 3: Alice constructs her own AI service.

Full size image

It is worth noting that our smart contracts are distributed systems, whose sub-services are located on different networked nodes. For instance, in Fig. 11, \(S_B\) and \(C_B\) are deployed in Bob’s node, as well as \(S_E\) and \(C_E\) in Eve’s node and \(S_J\) in Alice’s node. The rest of the contract, i.e., the connectors, are deployed in the platform layer. Therefore, our smart contract not only keeps the deal alive, but also protect the stakeholders’ rights, as listed below:

  1. 1.

    For Alice, it reduces the risk of data breach. Only Bob and Eve, who sincerely want to close the deal, get the test data. Notably, neither of them can access the expected result. On the other hand, Alice does not need to worry about being cheated.

  2. 2.

    For other stakeholders, it prevents their AI algorithms and code from falling into the wrong hands all along. The computation unit is encapsulated in an AI service, which is deployed in local node only.

  3. 3.

    For Bob and Eve, they do not concern if Alice violates the contract, because she has no authority to interfere the smart contract in the run-time or modify the negotiated conditions deployed in other nodes.

  4. 4.

    Although the platform coordinate the activities defined in the smart contract, it does not handle any data or code. Simply put, no matter who manages the platform, the administrator knows less than anyone in the deal.

Fig. 12.
figure 12

Step 4: Alice publishes a smart contract.

Full size image

After the smart contract is executed, Alice finally gets her desired AI service from Eve. So, she uses it as a building block to construct her own AI service, as demonstrated in Fig. 12. We hereby present another area where our BOX-MAN model could potentially bring advantages. Blockchain has been widely considered suitable for copyright protection, due to the digitized assets can be stored in a distributed database for good [24]. However, in order to verify content in a large body of data in a efficient and secure manner, blockchain introduces Merkle trees as one of its fundamental parts [25]. As a matter of fact, Our BOX-MAN model is a tree structure of services, which can be converted to an n-ary Merkle tree [26]. Figure 12 also expresses the Merkle tree of Alice’s new AI service. Each of these leaf services (\(S_1\) to \(S_4\), \(S_B\)) is hashed using some hash function. Then each group of nodes and the connector are recursively hashed until reaching the root node, which is a hash of all nodes below it. Eventually, the resulting tree has one Merkle root, three Merkle nodes and five Merkle leaves, as shown in Fig. 13. Notably, this Merkle tree will be verified, if Alice pushes her AI services onto the markets.

Fig. 13.
figure 13

Step 5: Using blockchain to record transactions.

Full size image

It becomes obvious that each smart contract can be converted to an n-ary Merkle tree, due to it is also constructed by BOX-MAN. Hence, we design a multi-chain structure for our platform. As Fig. 13 demonstrates, the multi-chain consists of two blockchains, namely main chain and service chain. In the main chain, each of the blocks contains a unique header, and each such block is identified by its block header hash individually. The Merkle root in the header contains all of the hashed transactions in the form of Merkle leaves, each of which is another Merkle root that represents an executed smart contract. Notably, the services involved in a smart contract are hashed and stored in the leaves. The service chain essentially is a distributed database that stores the information related to every service provided by every stakeholder. Therefore, services scattering across the smart contracts and applications are connected via the identical hash values. As a direct consequence, any user can trace back any service to its original owner.

6 Evaluation

This section provides an evaluation of our algebraic and hierarchical composition model via several quality attributes, i.e., low coupling, testability, scalability, reusability, maintainability and evolvability.

6.1 Low Coupling

In software evaluation, coupling is a term used to measure the degree of connection and the amount of interaction between modules [27]. The higher the coupling, the more likely it is that changes to the inside of a module will effect the original behavior of another one [28]. Thereby, low coupling is one of the ultimate pursuits for software engineering.

There are six levels of coupling, as enumerated in increasing order of malignity [29]: data coupling, stamp coupling, control coupling, common coupling and content coupling. Our BOX-MAN service model only generates the loosest two couplings in a system:

  1. 1.

    In data coupling, the communication between services is limited, i.e., via scalar parameters, in which only simple arguments are allowed to pass directly, e.g., variable and array. The passed data is always used for an invocation or a return of control [30].

  2. 2.

    Likewise, the communication in stamp coupling is also limited. But it passes composite data item, which usually is a entire data structure. Thus, sometimes a data structure may contain pieces of data that are unnecessary to the recipient module [31].

The coupling has a huge impact on testability, scalability, reusability, maintainability and evolvability.

6.2 Testability

Testability refers to the effort and time required to validate the software against its requirement. Thus, a system with better testability can be validated faster and easier [32]. However, perform testing in a serverless environment is never a simple task. An application using FaaS indicates that local code and foreign code are tangling together. It is difficult to run such an application locally, unless the local environment can fully simulate the cloud environment [33].

Although the problem cannot be tackled once for all, we do facilitate the testability of systems build by BOX-MAN service model. Firstly, such a system is completely modularized with low coupling, which means every behavior implemented in the local environment can be examined in isolation by means of unit testing. Secondly, the control flows are coordinated by the exogenous connectors, i.e., outside of the services, which implies we can verify the system behavior through a statechart directly derived by following the control flows, without take the services (local and remote) into account.

6.3 Scalability

Scalability is a term that frequently appears in a variety of computer science domains. Hence, we must explicitly understand the scalability needed to be evaluated in the scope of FaaS. In order to avoid the ambiguity, we hereby define the scalability from two different aspects.

From the perspective of software engineering, scalability is a fundamental quality referring to the impact of code expansion [34]. In other words, the scalability of BOX-MAN denotes the effectiveness of BOX-MAN when used on differently sized problems. As presented in Sect. 4 and 5, BOX-MAN provides outstanding mechanisms for partitioning, composition and visibility control, which result in great scalability [35]. For example, the mammography reading system constructed in Fig. 11 can be regarded as another BOX-MAN service, which can be composed with other services, such as a mammography report generator, to create a breast cancer auxiliary diagnosis application, which can be further composed again for a very large software.

On the other hand, scalability in the context of cloud computing describes the capability of a system to increase its throughput under an increased load, e.g., creating more service instances [36]. As a matter of fact, comparing to the traditional monolithic models, FaaS achieves much better scalability. A monolithic model encapsulates all its functionalities into a single process, and scales by replicating the entire monolith. Contrariwise, current FaaS models put implemented functionalities into separate services, and replicate the desired services for scaling. Apparently, in FaaS, only services with higher demand will be scaled, while the monolithic models anyhow waste resources.

Our BOX-MAN model make a further improvement on scalability. Except the advantages brought by general FaaS models, BOX-MAN also has a superb tailorability, which is another way of assessing scalability [35]. For example, we can directly instantiate the sub-services of a BOX-MAN composite service, and use them for new compositions.

6.4 Evolvability

Evolution of software is inevitable in industry, due to the changing requirements must be satisfied during the life cycle. Thus, the cost of application mainly depends on the evolution in long term.

Apparently, in a BOX-MAN composite service, we can easily replace any sub-service with a new one, or change a connector without touching any sub-service. But, if service owner want to modify a service after it is sold, the service owner must obtain the consent of all buyers, otherwise the evolved service becomes illegitimate, i.e., any buyer has the right to forbid it from being deposited to the blockchain. In that case, the service owner has to create a new one instead.

7 Discussion and Conclusion

In this paper, we discuss a novel decentralized service marketplace from a technical aspect. Simply put, what we focus on is the underlying infrastructure (which is constructed by BOX-MAN service composition model) and the safe exchange mechanism (which is designed on the basis of BOX-MAN model as well), instead of the financial activities occurred in the course of transactions. In fact, the functions of monetary transactions are realized in the form of BOX-MAN services, and embedded in the smart contract, e.g., \(C_B\) and \(C_E\) in Fig. 11.

In order to elaborate our work, we use well-trained AI models in services to exemplify our idea in Sect. 3 and 5. It is worth noting that our platform undoubtedly supports the services of pre-trained AI models as well. For instance, Alice could delegate the training task to Bob and Dave, respectively, and choose the better one. Moreover, to protect her own right, Alice can delegate the training task and verification task to different people, all she needs to do is designing a bit more complex smart contract.

Another potential advantage of the proposed platform is easy-to-use, even for user who knows few about computer science. As we present in Fig. 5, 6 and 7, each kind of connectors has a fixed semantic that can form a statement. Hence, a smart contract can be efficiently drafted if the underlying logic is determined. But, we hope to make it easier to use, by leveraging the power of AI technology. We are working on automated BOX-MAN construction for intelligent contract using natural language inputs.

In the future, we plan to implement an integrated development environment (IDE) for developing our BOX-MAN service and the multi-chain. The subsequent plan is to evaluate our research in an industrial setting. Furthermore, we will keep investigating the convergence of cloud computing and blockchain technology.