No. 145 
No. 144 
No. 143 
No. 142 
No. 141 
No. 140 
No. 139 by Álvaro M. Aparicio-Morales, Ernesto Pimentel (University of Málaga) and José Garcia-Alonso (Universidad de Extremadura)
Quantum computing is unlikely to operate in isolation. Its practical impact will depend on its integration with existing software ecosystems. This article explores how Service-Oriented Architecture can help expose, compose and manage quantum capabilities as services, and why classical service-oriented principles must be reconsidered in the quantum domain.
Quantum computing promises to provide new computational capabilities for problems that remain challenging for current systems. Its integration into existing software ecosystems is therefore becoming increasingly relevant, giving rise to hybrid quantum-classical systems. However, current quantum computing is largely based on remote access to resources offered by different providers and deployed over heterogeneous infrastructures. In this context, Service-Oriented Architecture (SOA) provides a suitable perspective by promoting the exposure, composition and consumption of quantum capabilities through well-defined interfaces, contracts and access mechanisms. This vision builds on Service-Oriented Computing, where services have enabled interoperable, flexible and reusable distributed systems [1]. Nevertheless, transferring these principles to the quantum domain is not straightforward: provider heterogeneity, hardware dependence, result variability and probabilistic execution introduce new tensions into abstraction, interoperability, service composition and quality-of-service management, which must be reconsidered for hybrid quantum-classical systems [2]. This article explores how SOA principles can be applied and extended to address these challenges in hybrid quantum-classical software systems, as summarised in Figure 1.
Abstraction
In general, reasoning about complex systems requires an adequate level of abstraction. In SOA, this is achieved by representing software capabilities as services that encapsulate business logic behind well-defined interfaces, promoting loose coupling, technological independence, reuse and scalability. Transferring this idea to the quantum domain means enabling applications to consume quantum capabilities without becoming tightly coupled to a provider, SDK or device. As quantum hardware is mostly accessed through cloud-based or managed environments, service-level abstractions are essential for its integration into broader software systems. Achieving this level of abstraction still requires progress in the hardware and software infrastructure needed to offer quantum services with a maturity comparable to that of classical services [1].
Abstraction should also extend to the hardware layer. Today, properties such as the number of qubits, connectivity, native gate sets, noise levels and calibration status remain fundamental when deploying circuits on specific devices [1]. From a service-oriented perspective, however, these characteristics should not be managed directly by the consuming application. Instead, they could be encapsulated in higher-level service descriptions associated with the computational capability offered. Thus, rather than reasoning in terms of individual qubits or provider-specific constraints, an application could express requirements related to feasibility, expected result quality, cost, waiting time or a minimum confidence threshold. The service infrastructure would then select, configure and adapt the most suitable quantum resource.
Interoperability, Composition and Orchestration
Interoperability is another fundamental aspect of SOA. Here, it should not be understood only as the ability to execute the same service across platforms, but as the ability to integrate heterogeneous services through common interfaces, contracts and access mechanisms. This is particularly relevant in quantum computing, where the ecosystem comprises multiple providers, technologies, SDKs, programming models and devices.
At present, important limitations still prevent quantum capabilities from being truly provider-agnostic [2]. Hybrid applications may become coupled to a specific platform due to the programming language, APIs, circuit representation format, native gates or backend constraints. From a service-oriented perspective, the challenge lies in defining mechanisms that allow quantum services to be replaced, combined or reused without redesigning the whole application [3].
Moreover, quantum services will not operate in isolation. Hybrid applications must coordinate classical and quantum services within broader workflows, including data preparation, resource selection, quantum execution, post-processing and validation. Consequently, composition and orchestration become essential to build applications from independent services while transparently managing provider selection, execution changes, resource availability and adaptation to failures [3]. This also invites us to rethink granularity: instead of treating a quantum algorithm as a monolithic circuit, service-oriented solutions may decompose quantum capabilities into smaller, reusable units. Techniques such as circuit cutting may support this vision, although models, tools and middleware are still needed to connect these low-level techniques with service-oriented orchestration.
Quality of Service (QoS) Criteria
Service-oriented applications must satisfy Quality of Service (QoS) requirements, including cost, response time, availability, reliability, scalability and resilience. In many domains, these properties are part of service-level agreements, whose strictness depends on the application context, becoming particularly demanding in critical environments [3].
The integration of quantum resources into service-oriented applications therefore requires QoS to be reconsidered in the hybrid quantum-classical context. Architectural decisions must support the selection of the most suitable execution resource, whether classical, quantum or hybrid, and among alternative services. These decisions may affect deployment, provider selection, execution configuration, the use of simulators or real QPUs, and dynamic adaptation when conditions change.
This problem is intensified by quantum-specific factors. Remote access, execution queues, provider heterogeneity, device noise, result variability and calibration changes introduce uncertainty that must be incorporated into QoS management. Monitoring latency or cost is not sufficient; quantum-specific properties such as expected result quality, execution error or confidence from a given number of shots must also be considered. Therefore, autonomous monitoring, selection and adaptation mechanisms are needed to verify requirements, detect quality degradation and activate strategies such as backend changes, provider selection, parameter adjustment or service redeployment.
Conclusion
Service-Oriented Architecture provides a suitable foundation for integrating quantum computing into current software systems, but this integration cannot be treated as a simple extension of classical models. Provider heterogeneity, hardware dependence, probabilistic behaviour and dynamic resource constraints require abstraction, interoperability, service composition and QoS management to be reconsidered. Progress will require new infrastructures, description models, orchestration mechanisms and adaptation strategies. Achieving practical quantum advantage will depend not only on quantum hardware and algorithms, but also on their effective integration with classical systems through extended service-oriented principles.
References:
[1] J. García-Alonso et al., “Rethinking Services in the Quantum Age: The SOQ Paradigm,” ACM Trans. Softw. Eng. Methodol., 2026, doi: 10.1145/3805807
[2] Á. M. Aparicio-Morales, J. Garcia-Alonso, J. Cámara, and J. M. Murillo, “Architecting Hybrid Quantum-Classical Software Systems: Exploration of the Design Trade-off Space with Quantitative Guarantees,” arXiv preprint arXiv:2606.24260, 2026, doi: 10.48550/arXiv.2606.24260.
[3] J. M. Murillo et al., “Quantum Software Engineering: Roadmap and Challenges Ahead,” ACM Trans. Softw. Eng. Methodol., vol. 34, no. 5, Art. no. 154, pp. 1–48, May 2025, doi: 10.1145/3712002.
Please contact:
Álvaro Manuel Aparicio Morales
ITIS Software, University of Málaga, Spain