1 Introduction

Quantum computing is starting to establish itself as a commercial reality (MacQuarrie et al., 2020). Several major computing corporations have already built working quantum computers, there are tens of quantum programming languages and simulators, and real quantum computers can already be used by the general public through the cloud. All this is motivating software development companies to take the first steps by launching their own proposals for the integral development of quantum software (Pérez-Castillo & Piattini, 2020; Wille et al., 2019; Bergholm et al., 2018; Piattini et al., 2021; Pérez-Castillo et al., 2021). All of these signals are an urgent call to software engineers to prepare and enroll to sail the quantum seas.

It is generally assumed that on the way to a new world in which software systems are mostly quantum, there will be a transition time in which classical and quantum systems must not only coexist but collaborate by interacting with each other (Sodhi, 2018). This is what has been called classical-quantum hybrid systems (McCaskey et al., 2018, 2020). The advances provided by software engineering in the last two decades allow us to affirm that a natural way to approach such collaborative coexistence is by following the principles of service engineering and service computing.

Among the reasons for this, two can be highlighted. On the one hand, as hardware technology matures and achieves more affordable costs, it is reasonable to think that companies will be inclined to use quantum infrastructure and quantum software as a service, as they are used to do nowadays with classical computing resources. This has already happened with classical computing services, companies such as Amazon, Microsoft, IBM, and Google that have started approaching the world of quantum computing Digital Journal (2022). And it is not unreasonable to think that these same companies will offer both classical and quantum computing services indiscriminately.

On the other hand, it is reasonable to think that at least initially, quantum systems will be used to solve only those parts of problems that cannot be solved by classical architectures, while those parts of problems that are already efficiently solved by classical architectures will continue to be treated as before. For example, in the field of health, it will be possible to accelerate the discovery of new medicines, perform simulations of molecules for pharmaceuticals, and enable the development of new medicines easier and faster (Zinner et al., 2022); in the financial domain, it could help analyze all possible scenarios and compare risks and optimize a financial portfolio Pistoia et al. (2021); it could also help us decrypt cryptographic security systems, optimize travel routes and logistics, model climate change, etc. (Cheng et al., 2021).

A natural way to achieve these quantum solutions is by consuming quantum services.

Conceptually, the invocation of a quantum program is similar to that of a classical service. A piece of software needs a result to be produced by a quantum system and to do so it consumes a service. For the sake of service engineering principles, such an invocation should even be agnostic of whether the service that will return the result is quantum or not. Technically, however, the invocation of a quantum service is very different from that of classical service and still poses a challenge today. This is due to the inherent nature of quantum computing, meaning that a quantum service differs from classical services in which it includes entanglement and superposition of solutions, and will collapse to a single solution when interacting with the external world, leading to having a probability amplitude associated to the results obtained upon observations of the quantum system.

Servitizing a quantum piece of software, namely converting it into a service endpoint that can be invoked through a standard service request, is possible with the existing technology. However, in the current status of quantum software, it means eliminating most of the advantages that made service-oriented computing a commercial success, especially, those related to software quality like composability, modularity, maintainability, reusability, etc. (Ravichandran & Rai, 2000).

The reasons for this are multiple. First and foremost, the specificity of each architecture makes quantum algorithms and their parameters dependent on the specific quantum hardware in which they will be executed. But also, the return of the result of a quantum process is subject to errors or does not support the intermediate verification of results (due to the system collapse). Thus, different quantum architectures require very different skillsets. For example, circuit-based quantum programming requires developers to know the details of quantum gates (Wille et al., 2019), while quantum annealing programming requires adapting the problem to that specific metaheuristic (Boixo et al., 2013). Consequently, invoking a quantum program in an agnostic way is impossible today and violates all the principles of service engineering. All of the above highlights the need for the development of Quantum Service Engineering (Piattini et al., 2020).

In this paper, we explore the current state of quantum software engineering from a service-oriented point of view. The integer factorization problem (Nielsen & Chuang, 2002; Jiang et al., 2018) is used to illustrate the different problems that arise when a quantum piece of code is tried to be used as a service. Amazon BraketFootnote 1, the quantum computing service offered by Amazon as part of their AWS suite, is used as the services platform. Amazon is globally recognized as the leader company in services technology, and through Braket, they offer access to quantum computers from three different hardware providers. Using this platform as the basis for quantum services development, we identify the problems and limitations of current technology using the lessons learned from service-oriented computing. The paper provides an exploration of the problems to be addressed pointing out different research directions for the development of a future quantum service engineering.

In order to do that the rest of the paper is organized as follows. Section 2 details this work background in both fields of service-oriented computing and quantum software development. Section 3 describes one of the possible ways to implement a classic service following best practices, design patterns, and existing standards. Section 4 addresses the servitization of quantum software using Amazon Braket. Section 5 lists the main limitations found in today technology that limits the benefits of quantum services. And finally, Sect. 6 presents the paper conclusion and future works.

2 Background

Service-oriented computing is a paradigm that utilizes services as the fundamental elements for developing software (Papazoglou, 2003). One of its pillars is service-oriented architecture (SOA) that proposes the implementation of complex software solutions through the use of a set of services that are composed and choreographed (Endrei et al., 2004). The basic composition mechanism is the service call that allows a service to be invoked from another piece of code (potentially another service) agnostically with respect to the place, technology, or architecture of the invoked service. The services can thus be maintained, evolved, replaced, and reused independently without affecting the software that invokes them. It is precisely these properties that make them especially attractive to create quality software. Over the last two decades, service-oriented computing and SOA in general, and web services in particular, have been at the center of intense research (Bouguettaya et al., 2017) leading to monolithic software being gradually replaced by service-based software run in the cloud (Mazlami et al., 2017; Haugeland et al., 2021).

The success of service-oriented computing has been possible, to a great extent, thanks to the development of cloud computing as a paradigm that aims to provide reliable and customized dynamic computing environments (Wang et al., 2010). Some of the main reasons behind the success of the cloud include: the ability for companies to better control their costs since they do not have to buy, upgrade and maintain expensive hardware and only pay for their use; and the flexibility and scalability provided by cloud vendors that allow companies to instantly increase or decrease their hardware capabilities according to their needs. These have made the cloud one of the most successful business models of the last decades. Recent estimations calculate that in the USA only, cloud computing contributed approximately 214 billion dollars in value-added to the GDP and 2.15 million jobs in 2017 Hooton (2019).

Given these numbers are not a surprise that current quantum computers, which are still very expensive hardware to build and operate, are being offered following this model. In its current form, most quantum computers can be accessed through the cloud in a model called by some researchers quantum computing as a service (QCaaS) (Rahaman & Islam, 2015). This model can be compared to the classical Infrastructure as a service (IaaS) model offered in cloud computing. QCaaS allows developers to access some of the world’s existing quantum computers; nevertheless, this access is very dependent on the specific hardware and developers must have great proficiency in Quantum Computing to benefit from its advantages.

To increase the abstraction level of QCaaS, there are multiple ongoing research efforts. From a commercial perspective, platforms like the above-mentioned Amazon Braket provide a development environment for quantum software engineers or, like QPathFootnote 2, an ecosystem that covers a wide range of possible applications by integrating the software classical and quantum worlds in a quantum development and application life cycle platform for high-quality quantum software.

From a more academic perspective, a significant number of works are starting to appear in the field of quantum software engineering (Zhao, 2020; Piattini et al., 2020). These works focus on translating the lessons learned in classical software engineering to improve the quality of quantum software. However, as far as the authors know, very few works focus on the perspective of service engineering for quantum and hybrid software.

However, some works are starting to appear in this domain, like Barzen et al. (2021) where quantum application as a service (QaaS) is proposed to narrow the gap between classical service engineering and quantum software. Works like this reveal the need to focus on a service-oriented approach for the development of quantum services.

3 A good classic service implementation

Before starting to discuss the proposed case study and the limitations found, we will describe one of the possible ways to manage the entire life-cycle of a classic service, starting with the implementation, followed by its deployment and its subsequent monitoring and maintenance. For this purpose, we will follow existing best practices, design patterns, and standards.

Figure 1 shows how a good classical version of the implementation, deployment, and maintenance of a service could look like. We would like to point out that there is no single best way to define a classic service and that it can be developed following different approaches. However, we have tried to follow some of the most accepted best practices, design patterns, and standards that have become very relevant in recent years for the definition and development of classical services. Among them, we followed the models defined by Newman (2021) (one of the early pioneers of microservice architecture), the microservices design patterns of Richardson (2019) (a renowned and well-respected microservices expert), and the guide of Wolff (2019) (a renowned software architect who has written several books on microservices).

Fig. 1
figure 1

A good classic version of a implementation of a service

Full size image

In this regard, Fig. 1 is split vertically in two. On the left side can be seen the service client (which can be a service itself). In the case study, which will be detailed in Sect. 4, this would be the cryptographic decryption service. And on the right side, the invoked service can be seen, in the commented case study, it would be the algorithm for calculating the factorization of integers.

Horizontally, the same Fig. 1 is split into three layers that represent different phases in the service life cycle. On the top, the implementation phase of the service can be seen, where the service is developed. In the middle, the deployment phase of the service can be seen, where it is published so that it can be invoked. And at the bottom, the monitoring phase can be seen where the service is being used. For each of these phases, some of the most relevant standards and best practices in classic services will be discussed.

For the implementation of a classical service, a developer needs to combine two main aspects. The business logic of the service, which is specific to each service and implemented ad hoc, and the service API. For the definition of the service API, the OpenAPIFootnote 3 specification can be used. This specification defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. An OpenAPI definition can then be used by code generation tools like Swagger to generate servers and clients in various programming languages. Using OpenAPI, for our case study, the integer factorization service can be defined with its input and output parameters. From this definition, a code stub can be generated, for example in Python, in which the business logic of the service can be added. By following this approach, the service could be accessed using a REST request and JSON to provide the input parameters.

Once the service is implemented, it must be deployed so clients can access it. For this deployment, in most cases, a cloud computing solution is used in which we deploy our API project in hardware provided by a third party. Depending on the level of control, we require over the hardware, there are several alternatives ranging from IaaS solutions, like Amazon Elastic Cloud Computing (EC2)Footnote 4, where we have complete control over a virtual machine, to the use of containers like DockerFootnote 5 or to serverless approaches like Amazon LambdaFootnote 6, where no control over the underlying infrastructure is provided to the service creators. Independently of the deployment approach followed the proposed service will have some coupling with the operating system in which it is deployed.

At the same level, one of the most used design patterns in the deployment of classical services is the API Gateway. To put it simply, the API Gateway takes all API requests from a client, determines which services are needed, and combines them into a unified, seamless experience for the user. For the proposed case study, the service would invoke the prime number factorization service through the API Gateway of the back-end. The API Gateway would transmit the petition to the appropriate service and provide the response once it has been computed.

Finally, once the service is deployed and is being invoked by users it must be monitored by the DevOps team to ensure that the service can deal with the demand. To address this, usually, a Load Balancer can be used in combination with the API Gateway. Additionally, monitoring rules can be defined in combination with tools like GraphiteFootnote 7 or CloudWatchFootnote 8 to obtain fine-grained information of the service status. This would allow us to control the status of the prime number factorization service, the number of requests, how much are we going to pay for the infrastructure at the end of the month, etc.

As can be seen, even for a “simple” service like the prime number factorization service the development, deployment, and monitoring process are quite complex. It could be thought that most of the components in Fig. 1 are not really necessary for a simple service. However, all of them are there for a reason. Service-oriented computing has adopted these patterns and good practices because all of them contribute to the benefits provided by service orientation. The most relevant of these benefits are:

  • Platform independence. By using a REST API, which in turn is based on HTTP, IP, and the rest of internet protocols, services can be invoked from any platform independently of the language of the service, the language of the client, and the platforms in which both are run. Similarly, by using JSON, data can be transferred between services regardless of the implementation languages. Finally, by using the OpenAPI specification, an independent, well-formed API will be defined that can be easily consumed by any client.

  • Location independence. Classical services are also independent of the location in which they are deployed. This independence can be considered at two levels:

    • Physical independence. This is provided by REST, HTTP, and DNS which allow service developers to use a URL to access a service independent of where it is deployed.

    • Logical independence. Meaning the independence of a given service inside a more complex project is provided by an API Gateway that hides this complexity from the service clients.

  • Decoupling. Three different types of decoupling must be taken into account:

    • Decoupling between services. The decoupling between different services of a single API is provided by the API Gateway which can communicate services without the services knowing each other.

    • Decoupling between services and hardware. The decoupling between services and hardware and operating systems is provided by the platform in which the services are deployed (EC2, Docker, Lambda, etc.).

    • Decoupling between services and programming language. The decoupling between the services and the programming language in which they are written is provided by the OpenAPI Specification and code generation tools that are able to generate the service stub in different programming languages.

  • Scalability. Services are also resilient and developers are able to scale to address changes in the demand. The most common way to provide this scalability, without incurring high economic costs from the cloud provider, is the use of elastic platforms and a load balancer that is able to start and stop new instances of the service as needed.

  • Composability. Services also have to be composable, so a set of simple services can be composed to provide solutions to complex problems. This composability can be provided by the API Gateway that can decompose a single invocation into calls to different services without the services knowledge.

  • Reliability. Services have to be reliable in the broadest sense of the word, including security, maintainability, accountability, and many other X-abilities. To achieve this, a complete set of monitoring and analytic tools are needed that provide all the information needed about the services.

To achieve all these benefits a complex infrastructure, like the one shown in Fig. 1, is needed. However, as far as the authors know, there is no support to obtain the benefits of service-oriented computing if one of the services of an API is implemented as a quantum service.

4 Quantum servitization

There are some problems that cannot be solved efficiently using classical computation, and a clear example is that of factoring prime numbers. This is where quantum computing can offer the greatest benefits. But without forgetting all the knowledge acquired in classical service-oriented computing. Where being able to distribute and servitize a development has offered benefits already known to all.

To address the current state of quantum services, in this paper, we have decided to use Amazon Braket. Amazon defines Braket as a fully managed quantum computing service. Specifically, Braket provides a development environment to build quantum algorithms, test them on quantum circuit simulators, and run them on different quantum hardware technologies.

Given that Amazon is currently the global leader regarding cloud computing and services technologies through AWS, Braket seems a good alternative to develop quantum services. Nevertheless, since the state of quantum software development is roughly the same in the different existing platforms, we expect similar results to the ones presented in this paper if the quantum services were developed on a different platform.

The basic building block of service-oriented computing is a service, defined as a self-describing, platform-agnostic computational element that supports rapid, low-cost composition of distributed applications (Papazoglou, 2003). However, Braket is not directly prepared to offer the developed quantum algorithms as services that can be invoked through an endpoint to compose a more complex application.

This shortcoming can be addressed by wrapping the quantum algorithm in a classical service. This implies including a classical computer to run the classical service that, in turn, invokes the quantum computer. As far as the authors know, there is currently no way of directly invoking a quantum algorithm as a service. Figure 2 shows an example of this approach. One of the simplest and well-known quantum circuits, the one used to create Bell states between two qubits is wrapped by a FlaskFootnote 9 service. This Flask service can be deployed in a classical computer and provides a simple way to include quantum algorithms in a complex service-oriented solution.

Fig. 2
figure 2

Quantum algorithm wrapped by a classical service

Full size image

Next, we present a more complex quantum algorithm used as a case study to identify the problems and limitations of current technology from the perspective of Service-Oriented Computing.

4.1 Integer factorization case study

In order to make the analysis as broad and interdisciplinary as possible, we have decided to select a problem well-known by the scientific community working in quantum computing. At the same time, the selected problem is simple enough to be comprehended by any newcomer. Between the several applications that satisfy both conditions, we have decided to tackle Integer Factorization, more precisely with a particular application of the later denoted Prime Factorization. As we all know, although this fundamental problem in number theory is computationally hard, it is not believed to belong to the NP-hard class of problems (Jiang et al., 2018). Nonetheless, it is a problem that has been used as a basic hardness assumption for cryptographic algorithms, such as the famous RSA algorithm. Thus, integer factorization and identification of new methods to address this task acquire an important role in information security.

There are multiple proposals and algorithms for the solution of this problem, being the most famous Shor’s algorithm Nielsen and Chuang (2002). This algorithm is normally described in terms of quantum gates and circuits, suitable for development and execution on machines such as IBM’s Q computing chip Haring et al. (2011), but when considering other approaches to quantum computing, such as Adiabatic Quantum Computing based on concepts such as quantum annealing, it is not possible to implement Shor’s algorithm directly. Nonetheless, other algorithms have been proposed for prime factors, such as the case of the algorithm proposed by Wang et al. in (2020). Thus, in the studies conducted on this paper, these will be the algorithms proposed for integer factorization: Shor’s algorithms for quantum machines programmed with quantum circuits and gates, such as Rigetti’s Motta et al. (2020) and IonQ’s Kielpinski et al. (2002); and integer factorization based on quantum annealing for adiabatic quantum machines such as D-Wave’s Hu et al. (2019).

These algorithms also serve as an illustration of a problem derived from the relative novelty of quantum computing and its different existing implementations. Namely, the nonexistence of algorithms with do-it-yourself characteristics. This is mainly due to the complex nature of the problems addressed by quantum computing and to the proximity of the algorithms with the underlying hardware used. This context is producing problems similar to those of the 60s software crisis Moguel et al. (2020), where each algorithm was designed for each particular computing hardware, many times having to recreate the algorithms for each new machine or even for each new increment of the problem. A reminiscent of this is found, for example, when having to generate a new circuit in Shor’s algorithm for primes to be factorized. Although this could be done through the use of algorithms to generate these circuits automatically, for the great majority of possible users of quantum computing, the ability to be able to create these types of “meta-algorithms” is beyond their capabilities, complicating the expansion of quantum computing usage out of the specialized field. Thus, it is necessary to offer solutions to non-specialized users for the utilization of quantum computing, such as the case of deployment of quantum services which allow hiding the complexity to users, only providing with entry end-points and returning the results of the execution.

4.2 Integer factorization in Amazon Braket

To illustrate the actual situation of quantum services that can be developed on Amazon Braket, we have translated the above-mentioned integer factorization algorithms to this platform.

At the moment of writing this manuscript, Braket supports three different quantum computer simulators and real quantum computers from three different hardware vendors. Specifically, the supported quantum computers include two vendors whose development is based on quantum circuits, Rigetti and IonQ, and one vendor based on quantum annealing, D-Wave. The integer factorization algorithms have been tested in all supported quantum machines and simulators.

Since the supported simulators are also based on quantum circuits, Shor’s algorithm has been used in both, simulators and quantum circuits hardware. Figure 3 shows a fragment of the quantum period-finding subroutine of Shor’s algorithm implemented using Amazon Braket. The complete circuit for Shor’s algorithm can be executed without changes in the three simulators and the two circuit-based computers supported by Braket. Nevertheless, is interesting to note that the measurement and reinitialization of qubits supported by many other existing simulators, and that can be therefore found in public implementations of Shor’s algorithm, are not supported by Braket. In the figure, this part of the algorithm is left commented as an example. Shor’s algorithm can be adapted to avoid the use of these operations which means additional efforts to adapt one of the most well-known algorithms to the specifics of a given quantum platform.

This difference with other existing solutions causes that the implementation presented here only works on certain occasions. For our study, the result obtained or that the integer factorization algorithm does not work in all executions is not of great relevance because our interest is the study and analysis of the behavior of the quantum algorithm from the point of view of service-oriented computing.

Fig. 3
figure 3

Fragment of the quantum circuit needed to run Shor’s algorithm in Amazon Braket

Full size image

Although the quantum circuit would be the same regardless of the quantum hardware or simulator used, the way in which the algorithm is invoked changes depending on where it will be run. Figure 4 shows the Braket invocation code for the three simulators and the two quantum computers supported. As can be seen in the figure, using the local simulator is the most straightforward invocation. To run the algorithms in the other simulators an s3 (Amazon simple storage system) destination has to be defined, where results will be stored, alongside a timeout for polling these results (if the polling timeout is too short, results may not be returned within the polling time). Finally, for running the algorithm on real quantum computers, a recovery task has to be defined. The quantum algorithm execution is an asynchronous operation and the developer is in charge of consulting the results when ready.

Fig. 4
figure 4

Fragment of the Amazon Braket code to invoke the Shor’s algorithm in different devices

Full size image

Finally, to execute integer factorization on an adiabatic quantum machine, such as D-Wave, one would have to completely rewrite the algorithm, since they are based on the adiabatic theorem closely related to quantum annealing. Thus, the mapping challenge differs from gate-based machines rendering quantum circuits inappropriate. Figure 5 shows the Braket code to factorize the number 21 using a D-Wave quantum machine.

Fig. 5
figure 5

Fragment of the Amazon Braket code to run the integer factorization algorithm in a D-Wave device

Full size image

These examples, although small, are enough to remark the current limitations of quantum software from the point of view of service-oriented computing.

5 Quantum service implementation and its current limitations

After developing the described service, the algorithm was tested to execute on all the defined machines and simulators, and different metrics were used to evaluate its performance and the limitations of including a quantum service in a hybrid system. The following were evaluated: number of qubits, since it is one of the main limitations of current quantum computers, and this directly affects the ability to execute the service; the number of shots, due to the problems that arise from the characteristics of real quantum computers, mainly noise in the state of the qubits, the experiments must be performed several times or “shots” to be statistically consistent; the precision of results, since there is some discrepancy in the results obtained on different machines; the response times, this measure corresponds to the time elapsed between sending the request and receiving the result; and the economic cost of invoking each solution.

To proceed with the evaluation, several HTTP requests were made from the Postman API client toolFootnote 10, which allows making requests to REST APIs and taking the described metrics.

The analysis carried out during and after the experiments allows us to conclude that there is some roughness, limitations, and problems that arise when a quantum piece of software is expected to be provided as a service. The mentioned limitations are not related to the fact that quantum services cannot be built but to the fact that, by implementing quantum services with current service technologies, the potential benefits of Service-Oriented Computing are lost.

For the case study proposed above in Sect. 4, the prime number factorization service, it is not viable to make use of traditional algorithms, but it is possible to take advantage of the benefits offered by quantum computing.

In traditional service-oriented computing, replacing a service with another, even if it is deployed on different hardware architecture, is mostly trivial (at least mostly trivial if all the infrastructure is in place such as the Fig. 1 shows). However, what happens if there is a need to replace a classical service with a quantum service?

Following a similar approach to that described in the definition of classical services, an attempt will be made to replicate the classical architecture by transferring it to the quantum world in order to maintain the quality attributes provided by service-oriented computing. Each aspect of a hybrid classical-quantum architecture will then be analyzed.

Taking into account the early stage of quantum software engineering, as shown in Fig. 6, most of the boxes are empty. Regarding the implementation layer of a quantum service, the service business logic must be implemented, as we did for the classic service. But then, we have no support or standardization mechanism for the definition of APIs for quantum endpoints. Similarly, there are no tools for code generation at the quantum service level.

Fig. 6
figure 6

A hybrid classical-quantum architecture version of a implementation of a service

Full size image

In this layer, following a traditional implementation, services must be platform independent. To achieve this, a REST API (based on HTTP, IP and all other well-known Internet protocols) is used to ensure that the services can talk to each other. Similarly, JSON is used as a way to transfer data between services regardless of implementation languages. The use of the OpenAPI specification also helps achieve this independence by providing a way to define a well-formed API that can be easily consumed. However, for a quantum implementation, no communication protocols have been defined, no formatted ways exist for communicating classical services with quantum services, and no specifications even exist for defining an API to achieve service independence. Although there are already researchers who have begun to consider these issues, such as Cuomo et al. (2020) who give an overview of the main challenges and open problems that arise in the design of a distributed quantum computing ecosystem from the perspective of communications engineering; or Rojo et al. (2021) who address the challenge of giving an implementation in the form of a quantum microservice to a well-known problem such as the traveling salesman problem.

Another important feature of service-oriented computing is decoupling. At the implementation layer, the decoupling must be between the services and the programming language in which they are written. In the development of a classic service, this is provided by the OpenAPI specification and code generation tool such as Swagger that are able to generate the Stub of the service in different programming languages. However, in designing a quantum service there are no specifications and code generation tools to generate the stub structure of an API project. Although some work is found such as Dreher and Ramasami (2019) in which they have developed a prototype container-based system that allows a developer to prototype, test and implement quantum algorithms with greater agility and flexibility.

The situation does not improve in the deployment layer. At the moment, we have some commercial platforms in which we can execute quantum algorithms. For example, Amazon Braket allow us to run quantum algorithms in different simulators or quantum processors. However, Braket does not offer any control over the platform in which the quantum services will be executed (only one quantum task can be placed in the queue of a quantum processor and wait for a response). Similarly, the API Gateway is not prepared to deal with quantum services.

At this layer, it is also important that services are independent of the location where they are deployed. And from a classic service design perspective, this independence can be considered at two levels. At the physical level, location independence is provided by REST, HTTP, and DNS, which allow us to use a URL to access a service regardless of where it is deployed. At the logical level, location independence for a given service within a more complex project is provided by the API gateway that hides this complexity from clients. But from the point of view of a quantum service, there is no concrete definition, although there are already some works that address these aspects, as in Kumara et al. (2021) that present a vision of Quantum Service-Oriented Computing (QSOC), being a model to build hybrid business applications by placing in collaboration developers of classical services and developers of quantum services; or as Garcia-Alonso et al. (2021) that propose a Quantum API Gateway following the traditional API Gateway pattern and adapting it to the quantum world. Moreover, this Quantum API Gateway recommends the best quantum computer to execute a given quantum service at runtime.

Continuing at the deployment layer, another important feature of service-oriented computing is decoupling. From a classical service design perspective, two different types of decoupling are considered. First, decoupling between different services of the same API. This is provided by the API gateway, which can communicate the services without the services being aware of each other. And second, decoupling between services and hardware and operating systems. This is provided by the platform on which the services are deployed (EC2, Docker, Lambda, etc.). But from the point of view of a quantum service, there is no concrete definition on these decoupling aspects, but there is some work starting to work on this path, as in Grossi et al. (2021) who describe an architectural framework that addresses the problems of integrating an API-exposed quantum provider into an existing enterprise architecture and provides a minimum viable product (MVP) solution that actually merges classical quantum computers into a basic scenario with reusable code in a GitHub repository.

Finally, at the monitoring layer, the situation is even worse. In classical service monitoring, there are countless tools, for example Graphite or CloudWatch; however, there is no support in current tools for monitoring quantum services. The development of this type of tools can offer great benefits to obtain detailed information on the state of quantum services.

In essence, services should be resilient and able to scale to address client demand. The most common way to provide this scalability, without incurring high economic costs on the part of the cloud provider, is the use of elastic platforms and a load balancer that is capable of starting and stopping new instances of the service as needed. But the technology to develop this feature in the quantum world does not yet exist. There are incipient works in this line, such as Sete et al. (2016) in which they describe a functional architecture based on a planar lattice of qubits that allows experimental tests of quantum error correction schemes.

Services should also be composable, so that a set of simple services can be composed to provide a solution to a complex problem. In traditional service development, this composability can be provided by the API Gateway, which can decompose a single invocation into a call to different services without the services knowing about it. However, there is no formal definition for the composability of quantum services. Although there are already different works in this line, such as Wild et al. (2020) in which they introduce two deployment modeling styles based on the Topology and Orchestration Specification for Cloud Applications (TOSCA) standard to automate the deployment and orchestration of quantum applications; or such as Barzen et al. (2020) in which they present a collaborative platform for problem solving with quantum computers; or as Cohen et al. (2020) in which they define a platform for designing quantum control protocols for a wide range of quantum hardware and define how to optimize their performance.

In addition, services must also be reliable, including security, maintainability, accountability, and many other capabilities. In classical services, there is a complete set of monitoring and analysis tools that provide us with all the necessary information about the services. However, in quantum services, there is no progress in this aspect. There is a nascent work, in which researcher You (2020) proposes a framework based on quantum computation for reliability assessment of complex systems.

6 Conclusion and future work

In this paper, and based on what we already know about classical service-oriented computing, we have presented an analysis of current quantum software from the point of view of service-oriented computing. We have used Amazon Braket to deploy quantum services by wrapping them on a classical service and used the integer factorization problem to show the differences of running the same service on different quantum hardware, even when doing it under the common umbrella of Braket.

We have presented a possible implementation of a classical service following the best practices, design patterns, and existing standards. Taking this implementation as a reference, we have developed a replica using a quantum services. This has allowed us to clearly present the current limitations, the proposals that are emerging and the possibilities that we have for the development of quantum services. Given the existing limitations, we have argued that intensive research efforts are needed to bring the benefits of service-oriented computing to the quantum world.

Due to the young nature of quantum software engineering, most areas in this discipline, including service-oriented computing, are still giving their first steps. Nevertheless, the paradigm change that underlies quantum computing implies that there cannot be a direct translation of proposals and techniques. Running quantum algorithms as traditional services is not enough to bring the benefit of service-oriented computing to the quantum era. There needs to be an effort to generate new techniques, methodologies, and tools that bring all these benefits, already shown by cloud and service computing, to quantum software and services.