Hybrid P2P-Based Architecture for Remote Software Utilization

Software as a Service (SaaS) stands out as a modern trend within the cloud computing domain of the information technology sector. This innovative model aims to dissociate software ownership from its usage. By providing software functionality through distributed services that can be configured and bound upon delivery, numerous existing constraints related to software evolution, deployment, and utilization can be effectively addressed. This approach has gained significant momentum in recent years, indicating its success as a new software distribution model [1-5]. Two conflicting scenarios exist in our world. While many individuals experience a shortage of hardware and software resources, others or organizations possess these resources yet they remain underutilized. The SaaS model can be used to address this issue. The aim is to provide these underutilized resources to those who need them the most, without resorting to illegal copying or pirating software. Instead, the owner offers their service by remotely processing data. This approach is feasible due to the SaaS model, where applications are hosted remotely by the provider and delivered as a service upon end-users' requests via the Internet, utilizing a utility pricing model. This results in reduced possession costs, allowing customers to eliminate concerns related to software package licenses, installation, and updates [6, 7].

Both the academic and industrial sectors have devoted considerable attention to Peer-to-Peer (P2P) systems as a promising alternative model. It holds potential to substantially enhance the design of large-scale distributed systems and facilitate the evolution of Internet architectures. These systems collectively accumulate extensive resources, which expand as the demand for them increases. This expansion happens as new nodes, which create additional demand, also contribute fresh resources to the distributed system. This process fosters a mutually beneficial cycle of growth and expansion [8-13]. Currently, the majority of Peer-to-Peer (P2P) systems are primarily used for simple content sharing, such as sharing files. However, this functionality is fundamentally different from service sharing. While numerous projects have aimed to harness the resources within these systems to offer services, the most prevalent P2P solutions are frequently utilized for sharing files that have been restricted due to piracy, including audio and video files, as well as software.

The shift from a Cloud SaaS system to a P2P-based system, which provides resources as SaaS, serves as a strategy to mitigate the absence of Cloud infrastructure. This transition also allows peers to actively contribute to enhancing the system's functionality. In computer network environments, the majority of programmers are usually highly skilled and involved in intricate software development endeavors. Frequently, numerous programmers collaborate actively to create a single system product in a coordinated manner. This collaborative model involves experienced programmers sharing insights and closely collaborating to develop sophisticated software, which stands in stark contrast to the personal computer model, where a lone beginner typically works independently [14]. However, in a Peer-to-Peer (P2P) network, most users are typically beginners with little to no experience or training in software development.

Service-Oriented Architecture (SOA) is a conceptual framework centered on the definition of services and their interactions [15]. The main idea of SOA is to describe all functions as separate and self-contained services, each having a well-defined and callable interface that can be combined in specific sequences to create business processes [16]. Simply, SOA is an architectural style that facilitates the integration of various applications and resources as services through standardized interfaces, enabling the exchange of structured data and coordination among services to respond to changing business requirements [17, 18]. The collaborative process within SOAs can be depicted through Figure 1, which adheres to the find, bind, and invoke paradigm. Within this process, a service customer initiates a search for a fitting service by querying the service registry with specific criteria. Should a service matching the criteria be available, the registry furnishes the customer with the interface contract and endpoint address for that service. Ultimately, the customer invokes the located service at the provider using the request/reply procedure.

1.png

Figure 1. Collaborations SOA

Web services are services that meet certain characteristics, including being self-contained, modular, and loosely coupled, and are accessible over the internet. The standardization of these services is supervised by four organizations: the World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS), the Liberty Alliance, and the Web Service Interoperability Organization (WS-I). Although WS-I does not function as a standardization body, it offers installation-ready packages of Web services known as "profiles," along with tools and guidelines for their implementation.

The initial Web services profile, known as the basic profile, is centered around three primary standards: Simple Object Access Protocol (SOAP), Web Service Description Language (WSDL), and Universal Description Discovery and Integration (UDDI). These standards are respectively defined by W3C and OASIS. SOAP is a decentralized communication protocol that uses XML for exchanging structured information between the requester and the service provider in a distributed environment. WSDL is a description language based on XML grammar that defines network services as a collection of communication endpoints, allowing them to exchange messages. UDDI is a service directory that provides the fundamental infrastructure for discovering and publishing Web services. It adopts a standard approach for service location and invocation, as well as the management of metadata related to these services. By relying on these three standards, services can be defined, discovered, and invoked in terms of their interfaces instead of their implementations [7, 16, 19, 20].

These concepts can be difficult for users who are not experienced in programming. This is especially true in a social P2P network intended for the general public, where users often lack experience in programming. The complexity is further increased when it comes to services, their composition, and invocation.

Certainly, P2P users are typically individuals who may not be familiar with advanced methods for utilizing services. In such instances, a user-friendly system with simple user interfaces can assist these users in easily performing and utilizing the SaaS. Given the assumption that many users of social P2P networks lack programming experience, we propose an HTML hybrid P2P-based solution. A hybrid P2P network incorporates index server (monitor) centrally storing information about resource locations, and it relies on this index server for conducting searches. Based on the SOA paradigm, the service publishing, searching and binding of software offered by peers, are fully automated and managed by the hybrid P2P monitor manager. The solution allows users who are unable to process their data locally due to resources scarceness to search throughout the hybrid-P2P monitor the wanted software and then utilize it remotely by sending its data to be processed by the software’s owner.

In this context, invoking the service entails executing the software with the given data, leading to the generation of a link pointing to an HTML page that displays the outcomes. Similar to WSDL, we employ XML-based automated procedures with HTTP support to facilitate various stages of our solution. Due to the users' limited programming experience, we have designed a comprehensive automated solution that assists them in navigating through distinct phases, including publishing, searching, binding, and invoking. While our proposed solution remains specific, we conform to the three mentioned standards, implementing them with our unique approach.

The following paper is structured as follows: Section 2 provides a review of the related literature. In Section 3, we introduce the architecture and components of our proposed system, along with the automated mechanisms for service publishing, finding, invoking, and request/reply. Section 4 describes the experimental framework and presents the results obtained. Security, profile establishment, and incentive mechanisms are discussed in Section 5. Lastly, Section 6 concludes the paper and outlines future research directions.

Developing a system that enables users to access the hardware and software tools of other users is a viable solution that addresses various issues such as illegality, heterogeneity, limited computing/memory capacity, and software unavailability. Our goal is to create a fully automated system that simplifies interaction and utilization of services provided by the system, requiring minimal effort from users.

To grasp the system, consider the following scenario: a user wishes to process data but lacks the required resources (hardware and/or software). Another user possesses these resources, and they are currently underutilized. In this context, the idea is to bring these users together to collaborate, allowing the first user to leverage the potential resources of the second user. The initial user sends their data to be processed by the second user, who subsequently forwards the resulting output back to the first user. These users form a set of peers that can collaborate between them.

These peers are overseen by a central monitor, which serves as the central node in a centralized peer-to-peer network.

The proposed solution involves building a centralized peer-to-peer (P2P) network and integrating it with a web application that incorporates key concepts such as service supply and publication (software), service research, discovery and request, and client-to-software supplier data exchange. By deploying this solution on the Internet, the system is designed to function through web interfaces that utilize the HTTP protocol, which is universally supported by various operating systems, thus effectively addressing the problem of heterogeneity.

The system's architecture comprises three fundamental entities, depicted in Figure 2, which operate within a minimal infrastructure. These entities are: (1) Software Suppliers, who provide their software as a service for others to use, (2) Software Requesters, who utilize the software to process their data remotely, and (3) Monitors, who serve as system managers and oversee its operations. The system's overall architecture is depicted in Figure 3.

2.png

Figure 2. Solution entities

3.png

Figure 3. Global P2P architecture

3.1 Exchange process description

The following section outlines the various exchanges that occur between the three entities:

3.1.1 Registration and login

Operation 0, as shown in Figure 3, involves user registration and login to the system. The primary objective of this step is to update the @IPs of software suppliers so that requested services can be located. Since users can have different @IPs across sessions, it is essential for the Monitor to maintain accurate information on the addresses of listed services at all times.

3.1.2 Publishing shared software

Operation 1 and 2, as depicted in Figure 3, enable software suppliers to edit and publish their software on the monitor to be shared with others. This process is carried out through a web interface provided by the monitor, which software suppliers can access. The web interface (form) allows suppliers to define the software they wish to share and its location path on the local drive. They can also provide a description of the software's capabilities and specify the parameters and arguments required to run the software. This information is used by the indexing module (system registry), which creates two programs (scripts) to be installed in the software provider. One of the scripts is the web interface used by the client to request the service, while the other is the script that runs the shared software and sends the results back to the client, as shown in Figure 4.

4.png

Figure 4. Publishing step

3.1.3 Searching for software

This step (Operation 3, Figure 3) enables clients to search for desired software by entering a description or browsing a pre-determined list through a web page available on the main site of the monitor. The search result is presented as a web page containing direct links to the web pages created during the publishing of services by the software supplier. When the client clicks on the link, he is redirected to the web page associated with the requested service at the software supplier, resulting in a direct interaction between the client and software supplier, as shown in Figure 5.

5.png

Figure 5. Research step

3.1.4 Service request

During this step (Operation 4 and 5, Figure 3), the client and software supplier establish a direct connection. After the client selects the desired service, he clicks on the link provided by the software supplier, which allows him to download the appropriate web page form automatically created by the monitor during the publishing step. The web page form prompts the client to input the data to be processed and select the required parameters, if any, to run the software. The software supplier defines the possible parameters during the publishing step.

After receiving the data from the client, the second script (which was created by the monitor during the publishing step) is executed. This script launches the software, retrieves the results, and generates a dynamic web page that includes a link to the results. The link is then returned to the client, who can use it to download the results (as illustrated in Figure 6).

6.png

Figure 6. Service request step

3.2 Forms and data

A centralized database at the monitor level consisting of a set of records is used to store information on all shared software. Each record (Figure 7) contains essentially the designation of the software, its category (for easy searching), its description, @ the IP address and port of the software supplier's web server, and the designation of the web page: interface between the client and the software supplier (the link). All this information is collected during the publishing step.

7.png

Figure 7. DB record

There are three main forms:

1) publishing form;

2) research form;

3) service request form.

The first two are part of the web application hosted in the monitor while the latter is dynamically created at the software supplier during the publishing step, and is associated with the shared software (for each shared software, a form is created).

During the publishing phase, the software supplier contacts the monitor by requesting the "Publishing Form" web page. This form asks the software supplier to inform some fields. Then, the script generator (Figure 8) generates automatically with the data extracted from the publishing form, two files (HTML, PHP) which will be saved in the www directory of the software supplier's web server:

1) HTML file (software execution form): interface between the client and the software supplier, the file is saved in the software supplier as a web page.

2) PHP file: which launches the selected software, also registered in the software supplier.

The software supplier must have a web server to run both scripts (PHP and HTML).

The XML file (Figure 9) is an intermediary between the publishing form and the script generator.

8.png

Figure 8. Indexing module details

The XML file’s tags are descripted in Table 1.

Table 1. Script generator XML file's tags

The PHP script's main task:

1) Launch the corresponding software with the settings defined in the XML file. The launch is executed by a line command done by the PHP instruction "string exec (string command [, array & \$ output [, int & \$ return_var]])."

2) Generate dynamic HTML file that allows the client to retrieve the results of treatment.

In such a scenario of software search and invocation, the client contacts the monitor by requesting the "Software Search Form" web page. This form asks the client to define some keywords that will allow the monitor to find the adequate software. Once this is done, the monitor responds with the following web page which consists of a list of possible proposals. The client has only to choose one of the proposed software by clicking on the corresponding link to be redirected to the HTML web page of the software supplier "Software Execution Form". At this moment, the monitor is no longer in Part, the interaction is solely between the client and the software supplier. Once the treatment is finished, the software supplier answers the client via a web page inviting him to download the result of the treatment.

9.png

Figure 9. XML file used by the script generator

3.3 Service composition

Sometimes the treatment requested by a client cannot be provided by a single software supplier. In this case, we need to use multiple servers that will succeed to achieve the desired result. In this case, the monitor makes research by needs. The client makes a request stating what he has as input data and what he wants as output result.

The monitor will establish as far as possible, a sequence of software suppliers that will carry out the treatment.

Indeed, Software is seen as a black box that has data as input and result as output. A sequence is viewed as a succession of software where the outcome of one is the input of the other (Figure 10).

10.png

Figure 10. Succeeded treatment

11.png

Figure 11. A second PHP script created in the software supplier

To allow a client to beneficiate of this kind of process, a new research interface is defined in the monitor web application that will allow the client to do research by "Need". This solution is only possible if the software suppliers publish their software without any parameters except the input and output data parameters and specifying the nature of each parameter. During the publishing step, the monitor provides the software servers the opportunity to participate in a sequential treatment, if this is the case; another script is created in the software suppliers (Figure 11).

This script will allow an involved server in a sequential treatment, to retrieve an XML file transmitted by the previous server for treatment, and then send a modified version of the XML file towards the next server (Figure 12).

The monitor has a module result by which it stores the results obtained after sequential treatment. In fact, the last server cannot communicate with the client for the simple reason that the client has no way of contact. So, the result is transmitted to the monitor who will save it until the client requests it.

Table 2. Sequential Treatment XML file's tags

12.png

Figure 12. Sequential treatment

Sequential treatment process:

When the client chooses to make a need-based request application, he interacts with the monitor by invoking the web page "Software Search Form (Sequential Processing)". This interface provided by the monitor allows the client to declare what he has as input data and what he wants as result data (output). The monitor looks in its database at the opportunity of making this request and establishes various sequential processing scenarios depending on server's profiles (to be examined later). It creates a new interface (form) to ask the client to choose between several solutions that can be classified according to certain criteria (not covered in this study). Once the client has chosen the solution in the search result interface and has provided the data file, the monitor starts sequential processing by creating a structured XML file, as shown in Figure 13, with a "treatment" entries tag (Table 2) for each server visited.

13.png

Figure 13. Sequential treatment XML file

The monitor starts integrating the client data into the first "data" tag and the command to launch the software (software name) into the first command tag, this to be executed by the first server and the address of the next server. It did the same thing for the following servers, except that the data tags are empty. In the last server "treatment" tag, the monitor indicates that the next server is the monitor itself.

At the end of the file, it inserts a treatment for himself where it is stated: the END command (end of treatment) and client ID to associate the data result to the client that made the request.

Each software supplier, when it receives this XML file, look for the first "treatment" tag, it completely removes the tag from the file after pulling data to be processed, the software to run and @IP of the next software supplier. After treatment, it incorporates the results at the first "data" tag. The modified XML file is sent to the next software supplier, the Figure 14 illustrates this process.

14.png

Figure 14. The process of analyze and extraction in a sequential treatment at a software supplier level

The result module (Figure 15) is composed of two units; the first one consists of analyzing and extracting data from the XML file received from the last software supplier involved in the sequential treatment. From this file, the result data and the client ID who did the request are extracted, and then saved in the monitor database until the client reaches them. The second unit consists of an HTML interface that allows the client to reach his results.

15.png

Figure 15. Monitor result module

The client is not notified that the treatment result is ready. He has to do it by himself by invoking the monitor's webpage "Result research (sequential treatment)". This webpage indicates the client while he introduces his ID if the treatment that he requested is completed or not yet. If it is the case, he can download the result by clicking the corresponding link.

5.1 Collaborations incentives

In collaborative systems, efforts are often directed towards implementing mechanisms to enhance collaboration. Several researchers have delved into the study of incentive mechanisms for collaboration. For instance, to establish Grid computing as a feasible business model, investigations have focused on formulating and implementing economic models and algorithms essential for fostering widespread adoption in commerce and industry [31]. Some researchers advocate the incorporation of market mechanisms to determine resource prices [32].

When peer-to-peer systems, are more like social systems, the researchers define simple rules of contribution [31]. Those who are contributing to a common fund may have access to this fund.

In the realm of incentive research, two distinct techniques have emerged: soft incentives and hard incentives. Soft incentives rely on a reputation system where peers receive positive ratings based on their reliability, contribution, effort, etc., resulting in better quality of service and higher priority access to resources. Conversely, newcomers or those with limited interaction receive lower ratings and develop poor reputations [33, 34]. On the other hand, the hard incentive system advocates for the implementation of external billing, individual and collective invoicing, and micro-currency approaches to incentivize resource sharing [35-41].

As we are currently implementing a collaborative P2P system, we recommend the unitization of soft incentives techniques by adopting the reputation system; we consider that it is most suitable for a P2P network.

We can establish at the monitor a reputation's computation module that consists to evaluate the degrees of contribution of the peer. Whenever a software supplier peer agrees to process data of another, his reputation is increased. If it ever happens to him to seek treatment at another peer, the monitor would recommend it to another peer and he will have the priority of being served before others. a peer that does not contribute to the system may face rejection of service or receive lower priority. The recommendation made by the monitor to a peer may be a code that the monitor sends with the link that the client must follow in step search and invocation. The software supplier, upon receipt of this code, may accept or decline the request of the client. A method of evaluation can be integrated into the monitor system to know if the software supplier has indeed done its job.

In this case, according to the peer’s reputation’s evaluation the monitor can block

5.2 Security

In P2P networks, file sharing stands out as the most common operation. However, a significant security concern arises when downloading files from other peers: the uncertainty regarding the authenticity and integrity of the file. While you may believe you are downloading a valuable utility, there's a risk that the downloaded file contains malicious content, such as a Trojan or backdoor, which could grant unauthorized access to your computer. This issue is particularly prevalent when downloading executable files. In our system, this problem is mitigated since the data transferred are non-executable and will never be executed by the software supplier.

Given that the system is entirely automated and peer exchanges involve only data, there is no risk of transmitting malicious data. Even if peers attempt to send malicious data, we can incorporate a detection mechanism, such as an antivirus, to prevent such situations.

The primary security concern revolves around data confidentiality. The key question is whether a peer can access the data he has received for processing. For an inexperienced peer, accessing the received data can be challenging since it is transmitted automatically through the HTTP protocol. However, for an experienced peer, it remains possible to retrieve the data. In such a scenario, we can empower the requesting peer to assess the confidentiality level of their data and decide whether to send it or not.

5.3 Profile use

By profile, we intend to classify peers into categories. Classify clients into a set of categories and software suppliers into another set of categories, and then try to make a correspondence between these two sets. When a client manifests, the monitor is able to recognize his profile (category), which means recognizing his intentions and even deduce the category of software suppliers to whom he corresponds better. This will allow the monitor to restrict his research field and propose solutions that best will satisfy the client's needs. Profiling the peers aims to enhance the system's performance in terms of publishing and retrieving resources, as well as satisfying peer requests. Through the classification of requester peers and supplier peers, we can leverage recommendation systems to suggest specific services to peers and ensure service availability.