In its essence, mashups are personalized web services. However, there are distinct differences between mashups and web services, which impose more careful design on mashup platforms. First, a web service is created by a given organization for the use of groups of people interested in that web service, while a mashup is created by an end-user to satisfy the end-user’s own needs. This personalization property of mashups implies that the potential number of mashups hosted by a mashup platform would be higher than the number of web services that exist on a web service portal. Hence, mashup platforms can incur higher request rates than web service portals.

Most of the existing mashup platforms are based on centralized architectures or follow a partially decentralized architecture, which causes a serious bottleneck scalability issue. Also, given the demands of mashup platforms that we just explained, a centralized server architecture would work against those demands. Therefore, a decentralized architecture for mashups is needed.

The existing mashup platforms are based on centralized architectures such as “Pipes.Digital” [4], which is currently a working mashup platform in the industry. Another work is presented in [6], which offers a mashup platform that includes interactions between several data sources, users, and servers. Although their work utilizes several servers, they still rely on the client-server interaction model, which does not represent a fully decentralized architecture, and this, in turn, raises scalability issues. Several works pertaining to mashups can be found in the literature, for example, the works in [7,8] introduce ranking techniques that rank data sources that can be used in mashups and that allow end-users to identify the most valuable data sources. Also, the works in [9,10] discuss the problem of the end-users being overwhelmed by a vast amount of data sources which can be used in mashups, and therefore, the authors propose mechanisms to alleviate this problem and make the end-user’s life easier in choosing appropriate data sources. Privacy aspects of mashups are discussed in [11]. The previous works are examples of the state of the art that we mention in the related work section, and the point we make here is that the previous works rely on centralized architecture, which causes them to be prone to failures.

Another way to search for data employs Large Language Models (LLMs). LLMs rely on artificial intelligence models that are trained on large amounts of data, and this requires an expensive infrastructure. In contrast, mashups do not require any training on data, and they are cheaper to deploy.

Based on that, we found that a decentralized architecture for mashup platforms is needed, and to the best of our knowledge, current mashup platforms are based either on a centralized server or a partially decentralized architecture. Accordingly, in this work, we are trying to answer the following research questions. First, RQ1: Can we build a decentralized architecture for mashups that facilitates mashup hosting and execution in a decentralized manner? RQ2: Is it possible to provide efficient message routing in such an architecture?

In this paper, we aim to overcome the shortcomings of the centralized mashup architectures employed in works such as [4,6] by proposing a decentralized architecture for mashup platforms. The proposed decentralized architecture is based on peer-to-peer architectures. Employing peer-to-peer architectures gets rid of the problems of the ordinary client-server model. However, there are two classes of peer-to-peer architectures, namely, structured and unstructured peer-to-peer architectures. Each of them has its own merits and shortcomings. Therefore, we investigate the use of a hybrid peer-to-peer architecture that combines the best of the structured and unstructured peer-to-peer architectures. To that end, our work embodies the following contributions.

Proposing a decentralized architecture for mashups based on a hybrid model of structured and unstructured peer-to-peer networks.

To the best of our knowledge, a fully decentralized architecture for mashup execution based on both structured and unstructured peer-to-peer networks does not exist, and providing one with the previous contributions is a step toward more scalable mashup platforms.

The rest of the paper is organized as follows. Section 2 discusses related works in the field of mashups. Then, Section 3 proposes our methodology which includes explaining how we represent mashups in our system in Section 3.1, introducing the system architecture in Section 3.2, presenting the structured part of our system in Section 3.3, describing the unstructured part of our system in Section 3.4, exploring how to utilize genetic algorithms to map mashups to the brokers responsible of executing them in Section 3.5, and portraying how message routing is handled in the system in Section 3.6. Then, we discuss security and reliability aspects of our system in Section 4. This is followed by Section 5 that sheds light on system complexity. After that, we evaluate our system in Section 6. Finally, we conclude this work in Section 7.

Several works related to mashups exist in the literature. Authors in [12] utilize ant colony optimization to find the shortest distance between several destinations the end-user wants to visit. Authors build a mashup that constitutes locations and paths on maps. In their work, a mashup is a result generated by a centralized server service, and they never discuss any information delivery scheme in their work. The end-user is overwhelmed by the sheer amount of sources on the Web, and therefore, an approach based on genetic algorithms is proposed in [9] to assist end-users in selecting data sources for their mashups, and the approach achieves this by minimizing the cost of executing mashups. The execution of the utilized genetic algorithm occurs on a centralized entity. The enormous amount of data sources impedes the work of end-users in picking the ones they want to use in their mashups. Accordingly, works such as [3,13,14] offer techniques to solve this problem. So, the work in [14] detects discrete attributes and semantic relationships of data sources and resembles them in a graph, and this graph is annotated with user preferences, which aids in recommending data sources to end-users. In [3], the authors tackle the issue of the lack of presence of domain knowledge for end-users, which hampers their ability to build mashups, and therefore, the authors study the semantics of the contents of data sources and recommend APIs of sources for end-users. In [13], an issue related to the popularity of data sources is discussed, where the popularity of certain data sources creates some kind of bias for end-users to keep using them in their mashups, and that impairs discovering new and possibly valuable data sources. The works in [3,13,14] rely on centralized architectures, which cause a single point of failure problem. Recommendation techniques that can be used to recommend APIs and services for end-users to use in mashups are discussed in a survey in [15]. A point of view of security is introduced in [16] where authors mention that executing mashups requires extracting data from data sources, and if those data sources happen to carry malicious code, then this code would end up being executed on the end-user’s machine, which makes it vulnerable to security attacks. The effect of programming skills and their effect on the ability of end-users to build useful mashups are investigated in [17].

The previous works pertain to the domain of mashups; however, they do not adopt decentralized mashup architectures.

A key player in network technology is peer-to-peer networks, and we mention several works in this domain in the section. The work in [18] employs Honey Bee Optimization to optimize paths between nodes in unstructured peer-to-peer networks. The work also optimizes the throughput of the network; however, it suffers from inefficient routing in unstructured peer-to-peer networks. Authors in [19] propose an approach to maintain the ability of unstructured peer-to-peer networks to expand even in the presence of high rates of churn, but their work also relies only on unstructured peer-to-peer networks. The work in [20] shows how to build unstructured peer-to-peer networks that can function as multi-hubs. Their overlay maintains the use of randomness of joining the network while keeping the shape of a star network, which results in a robust and low-diameter overlay; however, as in the previous works, their work depends solely on unstructured peer-to-peer networks, which causes routing deficiencies. Authors in [21] state that the performance of federated learning models suffers when applied on a centralized server architecture; therefore, they propose building a federated learning model on top of a Chord structured peer-to-peer architecture. Authors also utilize aggregation to mitigate cases where there are a variety of slow and fast nodes. Their work harvests the benefits of structured peer-to-peer networks, but at the same time, relying exclusively on structured peer-to-peer networks adds to system complexity. In [22], authors tackle the problem of inefficient cloud analytics for health care systems that are based on a centralized server and lack context awareness. So, they propose a hybrid architecture based on peer-to-peer networks. The structured part of their architecture is based on an RC structure, which allows their system to establish groups of nodes based on the specific interests of users. This work reaps the strength of combining both structured and unstructured peer-to-peer networks; however, it does not target mashup platforms. The work in [23] proposes a federated learning system for edge computing such that the system utilizes a publish/subscribe architecture built on top of a hybrid peer-to-peer network. The structured part of their work relies on multiple rings built using Chord. Similar to the previous work, this work utilizes both structured and unstructured peer-to-peer topologies, but it does not focus on mashup platforms.

We summarize the features of the existing works in literature and our work in Table 1 such that the columns in the table are interpreted as follows:

Mashup Centric: Indicates if the work targets mashup platforms.

Our work is the only one among the listed works that satisfies the following features. First, being dedicated to mashups. Second, being based on decentralized architecture. Third, relying on a hybrid peer-to-peer architecture. Fourth, utilizing an evolutionary approach, such as genetic algorithms, to optimize mashup execution delays.

Each mashup has a corresponding string representation, which plays an important role later when we map each mashup to a broker in the system. Therefore, it is important to clarify how we build the string representation of a given mashup. For that matter, we look into the mashup depicted in Fig. 2. The mashup is intended to collect information related to the sports and entrepreneurship news of the athlete “Lebron James”. The mashup extracts data from the New York Times ProBasketball sports feed (https://rss.nytimes.com/services/xml/rss/nyt/ProBasketball.xml), then the extracted data is filtered based on “Desc” containing “hall of fame”. In addition, the mashup extracts data from the entrepreneur.com feed (https://www.entrepreneur.com/latest.rss). Then, the extracted data from both data sources is merged and then filtered based on “title contains Lebron James”. After that, the data is sorted in descending order based on publication date and truncated to keep the latest 5 items. In this example, we have used feeds as the type for data sources; however, the concepts in this work are not restricted to a given data source type.

Each mashup operator has an equivalent string representation, and since a mashup consists of several mashup operators, the concatenation of the representation of operators results in the final mashup representation. To further explain this, we look at the string representation of the mashup in Fig. 2, the first filter operator “New York Times ProBasketball sports feed” is represented by 40, which is a chosen ID for the data source. Similarly, the second fetch operator “entrepreneur.com feed” is represented as 42. What comes next is the filter operator “Filter: Desc contains hall of fame” which is represented by the ID of the filter operator (15), followed by the filter predicate, and therefore its basic representation becomes “15:Desc contains hall of fame”. Now, we can represent the filtered data from data source 40 by concatenating the string representations of both operators, using the # symbol as a separator between them. Accordingly, the representation of the filtered data becomes “40#15:Desc contains hall of fame”. This is followed by the join operator, which has a representation that starts with “SU” indicating the start of a join block, and “EU” which refers to the end of the join block, and “MU” which stands in between the two merged sources. Accordingly, the representation of the merge operator becomes “SU:40#15:Desc contains hall of fame: MU:42:EU” which represents joining the filtered result of data source 40 with the fetched data of data source 42. The merged data is then filtered based on title containing Lebron James, and it is represented in a similar way to the first filter operator. However, the data to be filtered is the data resulting from the join operator. Therefore, we follow the same concatenation process to append the filter operator representation to the join operator representation, which leads to the result “SU:40#15:Desc contains hall of fame:MU:42:EU#15:title contains Lebron James”. The sort operator “Sort: pubDate desc” comes next, and it is represented by the ID of the sort operator followed by the attribute upon which data is sorted and the type of the sort operation, so its representation becomes “09:desc on pubDate”. Accordingly, the representation of the mashup until this point is “SU:40#15:Desc contains hall of fame:MU:42:EU#15:title contains Lebron James#09:desc on pubDate”. Finally, the result is truncated such that 5 items are kept from the result, and this is represented with the ID of the truncate operator (17) followed by the required number of items to keep; hence, its representation becomes “17:5”. Consequently, the final representation of the mashup becomes “SU:40#15:Desc contains hall of fame:MU:42:EU#15:title contains Lebron James#09:desc on pubDate#17:5”.

Structured and unstructured peer-to-peer networks are among the popular architectures used for distributed systems. This is due to the lack of central control that usually exists in ordinary client/server models. This makes peer-to-peer architectures excellent for graceful scalability. However, each of these two architectures has its own advantages and disadvantages [24]. On the one hand, structured peer-to-peer architectures impose a certain organization on the way peers are connected to each other, which makes them organized and scalable. In addition, this organized connectivity facilitates efficient search and routing through the structured topology, which is usually performed using distributed hash tables (DHTs). However, the imposed organized connectivity introduces a certain degree of complexity to structured topologies. On the other hand, unstructured peer-to-peer networks do not impose a certain way for peers to be connected to each other, and therefore, one of the main advantages of them is their simplicity and convenience. This also allows them to be more dynamic due to loose constraints on node connectivity. However, this simplicity comes at the expense of poor search efficiency, which causes high delays. To this end, we aim to combine both structured and unstructured topologies in our system architecture, which allows us to harvest the best of the two topologies.

The system architecture and network overlay are depicted in Fig. 3. The network overlay consists of several end-users, brokers, and data sources. End-users design mashups, and this is why they have the component “Mashup Designer”. which normally provides drag-and-drop capabilities to build mashups. They also have a “Mashup Storage” component to store the mashups they design. In addition, they have a “Broker Interface” component, which allows them to request the execution of mashups from brokers in the structured part of the topology.

Brokers form a network, and they exist in both the structured and unstructured parts of our architecture. However, a broker’s role differs based on belonging to the structured or the unstructured parts. A broker in the structured part takes part in several tasks as follows. First, it receives the end-user’s request to execute a given mashup. Second, upon receiving the end-user’s request, the broker would check if the mashup to be executed is a new one in the system or a previously existing one. If it is a previously existing one, then the broker would forward the request to a broker in the unstructured part it governs. However, if the mashup is a new one, this would engage the “Genetic Optimization” component to decide which of the brokers in the unstructured part would be responsible for hosting and executing the mashup. Third, the broker utilizes the “Forming Groups” component to build the unstructured group of brokers that it will moderate. The “Genetic Optimization” component requires accessing mashups and therefore the broker holds a “Mashup Storage” component.

For the brokers in the unstructured part, when a broker receives a mashup execution request, then it executes the mashup via the “Mashup Execution Engine” component and sends the result to the responsible broker in the structured topology, which in turn hands the result to the end-user. The “Mashup Execution Engine” requires the need of the “Mashup Storage” component to host mashups and access them when they need to be executed.

Data sources resemble sources in the Web, such as feeds, and those will be contacted when a given mashup is executed. When data is extracted from these sources, it is usually returned in a standard format such as HTML, XML, or JSON.

Here, we describe the details related to the structured part. For the structured part, we follow the topology of Chord [25], which relies on the concept of consistent hashing and distributed hash tables.

Accordingly, for the structured part, brokers are organized using a virtual ring topology where it is possible to place “n” brokers on a given ring such that “n” is a power of 2. Even when all the “n” places are taken on the ring, the ring can expand to make room for additional brokers. The way a broker is placed on the ring topology is governed by applying a hash function on the broker’s IP address. For that purpose, the SHA-1 hash function is utilized based on Eq. (1). Let us explain that using an example. As shown in Fig. 3, the ring allows for 8 brokers numbered from 0 to 7, and 3 of those 7 places are taken by brokers B0, B2, and B4. So, when a given broker is to be added to the ring, its IP address needs to be translated to one of the available identifiers from 0 to 7. Passing the IP address of the broker to the SHA-1 function results in a hexadecimal number output, then the hexadecimal number is converted to a decimal number. However, the resulting decimal number might not fall within the allowed 8 identifiers (0 to 7). To solve that mathematically, we divide the resulting decimal number by 2m, where m is the number of binary digits needed to represent the “n” possible identifiers. In this case, m = 3 because 23=8, then the remainder of the division becomes the broker identifier on the ring. (1)ID=ToDecimal(SHA1(R))mod2m

In our platform, brokers host mashups, and specifically, we assign this task to the brokers in the unstructured part of the architecture. Therefore, we need to find a way that uses the representation of a given mashup to map it to a broker in the structured part. This paves the way to the unstructured brokers network, which the broker in the structured part is responsible for, and then the mashup would be hosted by one of the brokers in the unstructured part. Hence, the first step for us is to map the mashup representation to a broker in the structured part of the network, and to achieve that, we follow the way employed in Chord. Based on that, the representation of a given mashup is also passed to Eq. (1) and the result would be a decimal number (MashID) such that the broker on the structured part that is mapped to this mashup is successor(MashID) where the successor function is a simple function that returns the broker on the ring topology which has the identifier that is equal to MashID or the closest to MashID clockwise. For example, successor(0) is 0 because there is a broker B0 at position 0 on the ring; however, successor(1) = 2 because there is no broker occupying position 1, and therefore, we look for the next broker clockwise, and that would be broker B2. Let us discuss another example in the context of mashups. Suppose a given mashup results in MashID = 5. Now, looking back at Fig. 3, the broker to which the mashup is mapped is the one resulting from successor(5). We can see that the place with ID 5 is not occupied by a broker yet, so we move clockwise to find the closest broker, which is broker B0 in this case. So, the previous mashup is mapped to broker B0. Now broker B0 would be responsible for finding a broker within the unstructured brokers network it is responsible for and that broker would be the broker on which the mashup will be hosted and therefore it will be responsible for executing that mashup in the future.

One thing to mention here is that searching the ring in this sequential manner is costly and accordingly Chord employs the concept of finger tables which aids in a more efficient process in finding successor brokers and it is also used in routing through the ring topology, and this way a smaller number of steps would be needed to find the broker to which a given mashup is mapped. This is realized using the distributed hash table concept employed in Chord. So, each broker in the structured part keeps a finger table such that each entry of the finger table is of the format <BrokerID, [Interval Start, Interval End), SuccessorBrokerID>, which is interpreted as follows. The broker with “BrokerID” is responsible for keeping mashups that have IDs that fall within the interval that starts with “Interval Start” inclusively and ends with “Interval End” exclusively, and the successor for the broker with “BrokerID” is the broker with “SuccessorBrokerID”. In Fig. 4, we show the structured part of our architecture where each broker in the structured part has its own finger table. Looking at the previous figure, let us assume that broker B2 is trying to find out where the mashup with ID 5 is hosted. The broker searches its finger table for an interval that includes the MashID 5. In this case, the second entry has an interval [4,6), and it includes MashID 5. The corresponding broker ID is 4, and based on the fact that the broker hosting a given MashID should have an ID equal to MashID or the closest broker with ID greater than MashID, broker B4 precedes identifier 5, so we go for successor(4), which is 4 based on the entry in the finger table. Reaching broker B4, the same process is repeated. Identifier 5 is found in the first entry interval [5,6), and the broker ID is 5, and the successor(5) is 0. Here, the process stops because 0 is the successor of 5 going clockwise in the ring. Consequently, broker B2 now would contact broker B0 for any future requests to execute the mashup with MashID 5. For simplicity reasons, we refrain from explaining how finger tables are built since this is Chord-specific information and it is not needed for explaining the concepts in our work; what is required is how the finger tables are utilized for searching and routing, which we already explained.

Out of the brokers set in the system, several of them would join the structured Chord ring, and the rest would join the unstructured topology pertaining to one of the brokers in the structured topology. So, how can we make the distinction of which broker joins the structured or the unstructured parts of the topology? To achieve that, we form groups out of the brokers set such that one member of each group (Group Head) is the representative of that group on the structured Chord ring, and the rest of the brokers in each group belong to the unstructured part, which is under the control of the group head.

The way we form groups is depicted in Algorithm 1 and described as follows. First, the system administrator is responsible for deciding the desired number of groups (“.” number of groups), then the administrator picks one broker (Bs) randomly to be a group head for one of the groups (line 1) and then launches “k-1” random walkers to select the remaining “k-1” group heads (lines 2–6). Each random walker would travel starting from Bs as deep as it can through the network, such that the random walker behaves as follows. The random walker starts from broker Bs and randomly picks a broker from its direct neighbors, and the process is repeated until either an inevitable loop is encountered (line 4) or the random walker has already reached the allowed number of hops to travel through the network (line 5). The second condition is important because it forbids the random walker from traveling too long in the network, so each random walker is given a Time to Live (TTL) value such that the TTL value is decremented each time the random walker moves one hop ahead, and when the TTL value expires (i.e., reaches zero), then the random walker stops. The broker at which the random walker stops is chosen as another group head, regardless of the random walker being stopped due to an unavoidable loop or due to TTL expiration. The way a random walker knows if it hits an inevitable loop is by utilizing a list of previously visited brokers, which it keeps and updates through its way. After all the random walkers finish their work, the result is “k” group heads, and they will join the structured Chord ring using the same approach explained in Section 3.3.

Now, each of the group heads is responsible for forming a group of brokers that are connected in an unstructured peer-to-peer overlay. This is a process that each group head starts independently on its own and therefore makes use of parallel execution. Each group head starts a flooding process that starts from the group head and conditionally spreads through the network (lines 7–24). To execute the flooding process, we utilize a list fList to contain the brokers from which the flooding process continues (line 9), and this list initially contains the group head from which flooding would start (line 10). The flooding process keeps going until the fList is empty, which indicates that there are no more brokers for the flooding process to continue from them (line 11). In each iteration of this loop, we start from the broker sitting on top of the fList, and we call it Bc (lines 12,13), and to reach the direct neighbors of Bc, we employ a list adjList(Bc) (line 14). The broker Bc communicates with its direct neighbors (lines 15–21), and each of the neighbors Nbr (line 16) would join the group that belongs to the group head, supposing that it did not previously belong to another group (lines 17–20). Also, Nbr is added to the fList so that it would be the next broker from which the flooding process continues (line 19). In line 22, Bc is removed from the fList because the flooding process is done with this broker and will move on to other brokers from the list. The same process is repeated, starting from each of the direct neighbors. The process stops when all the contacted direct neighbors belong to another group. When this process is completed, all brokers in the system will be members of the unstructured topology of one of the group heads in the structured topology. We mention here that although the flooding process is known to be a time-consuming operation, in this case, it is not expensive, and this is due to the ability of group heads to work in parallel. It is worth mentioning that during the flooding process, each travelling message keeps a list of previously visited brokers, which is used so that a message can memorize its way back to the group head. This way, when a broker joins the group of a given group head, then the broker can report back to the group head to inform it that it has become part of its group. Another use of this is the fact that a group head now knows the path that should be followed to reach a given broker within its unstructured group.

The previous way of forming groups depends on network flooding, as previously explained. We provide two flavors of the previous algorithm depending on a variation of the type of the flooding process, namely, sequence number flooding and reverse path flooding. Remember that a given group head executes a flooding process so that it finds brokers to join its group. However, the flooding process naturally involves that a given node would be reached several times from different paths. So, the previous two types of flooding determine what happens when a given broker receives a message from two different paths.

Sequence number flooding: In this type of flooding, each message is associated with a sequence number, which is utilized to identify messages originating from the same source. Let us assume a simple scenario to make the concept clear. Suppose a given group head Bc started the flooding process and sent a message to its direct neighbors B1 and B3 such that the two sent messages have the same sequence number. Broker B1 also forwards the message to its neighbor B3. This means that broker B3 would receive two messages from the broker Bc, the first one through the path “Bc -> B3” and the second one through the path “Bc -> B1 -> B3”. Let us assume that the message coming via path “Bc -> B3” is received first, and the cost of that path is 8. Now, broker B3 would report back to Bc that Bc can reach B3 with a cost of 8, and B3 joins the group of Bc. In addition, B3 proceeds with the flooding process by forwarding the first received message to its neighbors. Next, B3 receives the other message coming through the path “Bc -> B1 -> B3” with a cost of 5. Hence, the sequence number of the second received message is identical to the first one, then broker B3 would not forward the second received message as part of the flooding process.

In this Section, we discuss how to choose a broker that is responsible for hosting/executing a given mashup. We explained in Section 3.3 that a mashup representation is translated into a mashup identifier (MashID). Then, the MashID is mapped to one of the group heads in the structured Chord ring. However, the group heads are not responsible for executing mashups; instead, they are responsible for guiding the mashup execution request to one of the brokers in their unstructured groups. Accordingly, when a given group head receives a request to execute a given mashup, it would need to instruct one of the brokers in its unstructured group to host the mashup. Nevertheless, the unstructured group of a given group head contains many brokers, and the decision of which broker of them would host a given mashup has implications that affect the delay in the system. Hence, it is the responsibility of the group head to decide which broker within its group would host a given mashup based on generating minimal delays in the system, and this is known to be an NP-complete problem. Evolutionary techniques can be used to solve this problem, and they rely on randomized search mechanisms. In our work, we adopt genetic algorithms to decide where each mashup is hosted in the unstructured groups.

For a given group head, when it receives a mashup execution request, it would need to map the mashup to a broker in its unstructured group. This is called a solution, and it is called a chromosome in genetic algorithms vocabulary. Therefore, a chromosome looks like what is represented in Table 2, where a binary solution is represented as a one-dimensional array comprising mapping of mashups to brokers in the unstructured group. For example, the figure shows that Mash1 is hosted at broker B1, Mash2 is hosted at broker B3, and Mash3 is hosted at broker B4.

Each solution (chromosome) has a given value (Fitness Value) that resembles the quality of the solution. In our case, the quality is related to generating minimal delays. Accordingly, the fitness value of a given solution can be measured based on Eq. (2), where the delay is measured according to the delay resulting from extracting the data sources involved in mashups. The symbols used in the equation are as follows. Ex(Mashm,Bn) is a simple function that returns 1 if mashup Mashm resides at broker Bn and it return 0 otherwise. Similarly, Ex(Dq,Mashm) return 1 if data source Dq is used in mashup Mashm, otherwise 0 is returned. The size of data extracted from data source Dq is represented as SZ(Dq). BW(Dq,Bn) returns the minimum bandwidth along the path from data source Dq to broker Bn. Accordingly, the optimization goal of the genetic algorithm becomes finding a solution that minimizes the delay. The optimization process needs to respect a constraint that restricts the number of copies of a given mashup to a certain number. This constraint is also stated in Eq. (2), and it is explained as follows. The default value that we use for the number of copies of a given mashup in the network is 1, and since the function Ex(Mashm,Bn) returns 1 if mashup Mashm is hosted at broker Bn, then the total summation of that value for a given mashup on all brokers should be 1. Although we deal with hosting a single copy of each mashup in the system, the constraint can be changed accordingly to allow the genetic algorithm to host more than one copy of a given mashup in the network. (2)D=∑n=1N∑m=1M∑q=1QEx(Mashm,Bn)×Ex(Dq,Mashm)×SZ(Dq)BW(h(Dq),h(Bn))),∋(∑n=1NEx(Mashm,Bn))=1

The genetic algorithm is shown in Algorithm 2, where it starts by creating an initial population of solutions such that each created solution is similar to the one in Table 2. The default population size we use is 100, such that the initial population is initialized using a standard random initialization (line 1). Then, several parameters are set for the genetic algorithm (lines 2–5). The genetic algorithm optimizes solutions by going through several iterations, and the number of iterations is set in line 2 (default is 1000). Also, the type of selection operator is set to tournament selection (line 3), where the default tournament size is 2. This selective pressure is considered moderate because two solutions are chosen at random, which leaves a chance for weaker solutions (with high delays) to be selected, and that helps to maintain the population diversity and prevents premature convergence. In addition, the crossover and mutation operators are set to single-point crossover and bit flip mutation, respectively, where the probability that each operator takes place is determined in lines (4, 5) such that the default probability for both operators is 0.8. What happens in each iteration is illustrated in lines (6–13) such that “T” represents the number of iterations (line 6). In each iteration, tournament selection is used to select a parent list consisting of two parents (line 7), which will undergo a mating process. The mating process is performed using single-point crossover (line 8), where the probability of executing the crossover is previously set at line 4. The result of the crossover is two children, and a bit flip mutation is applied on the two children (line 9) with a probability set at line 5. Next, the delay (fitness value) resulting from each child is evaluated in lines 10 and 11. In line 12, the two children will replace two solutions with the worst fitness value in the population. This process is repeated until the number of iterations expires or the convergence condition is met. The default convergence condition we adopt is when the minimal achieved delay so far never changes for a consecutive 10% of the iterations. At the end of the optimization process, the best solution of the population is used as the result (line 14).

Deciding which brokers should host a given mashup can be achieved using other ways. Here, we consider two approaches, namely, the greedy approach and the random approach.

Greedy Approach: When the group head broker receives a request to host a given mashup, it starts a greedy search to find a broker to host the mashup. The group head sends a request to its direct neighbors, asking them for the cost of hosting the mashup. Each of them computes the cost based on Eq. (2), which we explained before. All the direct neighbors report back the cost to the group head. The group head picks the neighbor that resulted in the lowest cost and sends a request to that neighbor to repeat the same greedy process, starting from that neighbor to find a lower cost than the one currently achieved. The process continues until all of the direct neighbors fail to find a lower cost than the current cost.

In this Section, we review how message routing takes place, starting from requesting mashup execution by an end-user and ending with delivering results to the end-user.

As shown in Fig. 5, when an end-user asks for the execution of a given mashup, the request is received by the broker (Group Head) in the structured part to which the end-user is directly connected. Now, if the group head sees that it did not receive this mashup before, then it starts the mashup hosting process described in Section 3.5 to decide which broker in its unstructured topology will be responsible for hosting/executing the mashup. However, if the mashup already exists in the system, then the group head broker checks its records to find the broker in its unstructured topology that is responsible for executing the mashup. Recall that an outcome of the process of forming groups was that the group head knows the paths that should be followed to reach the brokers in its unstructured group and vice versa. So, the group head forwards the request to the broker, which in turn executes the mashup and delivers its result back to the group head. Then, the group head emits the result to the end-user.