Continuously Delivering SOA

DZone 's Guide to

Continuously Delivering SOA

Learn about how to apply Continuous Delivery principles to SOA, when test services aren't adequate, and the mechanics of service virtualization.

· Integration Zone ·
Free Resource

This article is featured in the DZone Guide to Enterprise Integration, 2015 Edition. Get your free copy for more insightful articles, industry statistics, and more.

Continuously Delivering SOA 

How to Test Services when Reality isn’t Good Enough

Two undeniable trends that have emerged within enterprise IT over the past several years are: 1) the componentization of business functionality into self-contained services (first with service-oriented architectures—classical SOA’—and more recently via ‘microservices’) and 2) the drive to ‘continuously deliver’ these services, using techniques such as continuous integration, build pipelines, and continuous deployment. Although these trends have provided undeniable benefits—such as allowing the realization of team-owned services (a la Conway’s Law), encapsulation of state and increased cohesion of functionality, and the enablement of independent application release lifecycles and scalability—we have also seen increased challenges with the collaboration and orchestration of dependent services.

Testing a system composed of independent services is typically more complex, particularly if several of the services are outsourced or managed by external third-parties, and hence have limited or restricted availability; and developing against external APIs that may not be available—or do not allow configuration of state, lifecycle-managed, or failure scenarios—often leads to delays in delivery (as stated by a recent Forrester report).

The issues mentioned above have lead to the creation of a domain of quality assurance (QA) technology classified as ‘lifecycle virtualization,’ which enables parts of a system under development or testing to be ‘virtualized’ or ‘faked’ to varying degrees of complexity and configurability. This allows one or more services or application components to be virtualized, and can remove reliance on the need to access the corresponding ‘real’ services when developing against an application programming interface (API), or running end-to-end functional or performance testing.

A report by Voke Inc., an application lifecycle analyst firm, states that three specific levels of lifecycle virtualization have emerged as commercial and open-source products: service virtualization, where a service interface or API can be virtualized; virtual labs or sandboxes, which offer either a full or partial virtualized test environment that emulates a system or application; and network virtualization, where developers can test an application’s operation within a simulated virtualized networking environment that mimics expected deployment conditions.

This article focuses on the use of service virtualization, as—in our experience—this is more generally applicable across organisations, can provide benefit across an entire IT team, and can add value throughout the complete application development lifecycle. With the recent rise in popularity of small, self-contained microservices, it is not uncommon to find a service that interacts with a variety of external components or services as shown in Figure 1.

Figure 1. Typical service interactions throughout development lifecycle

If these interactions appear familiar, then we believe service virtualization could provide benefit across your test and development lifecycle.

The Mechanics of Service Virtualization

Service virtualization is typically implemented by the use of some form of proxy that either 1) redirects traffic to/from a service being virtualized, or 2) actually performs the virtualization itself. Requests and responses are typically defined using one of three methodologies:

  • Manual creation of service endpoint and associated responses (e.g. WireMock service stubbing)
  • Creating a series of customisable request/response stubs from a service’s descriptor (e.g. WSDL, Thrift IDL descriptor, Swagger resource declaration)
  • Recording of request/response, including the ability to identify non deterministic data, such as timestamps or UUIDs, and customisable responses (e.g. VCR service virtualization cassettes)

Figure 2. Typically implementation of service virtualization

Choosing to invest in the use of a service virtualization tool can brings many benefits, but it is not a decision to be taken lightly, and may not fit every development requirement. Accordingly, Table 1 contains information that highlights the differences in approaches to ‘virtualizing’ services, and aims to allow comparison of the various methodologies and tooling.

Virtual Environment

Virtual Sandbox

Service virtualization

Mocks and Stubs

Level of Virtualization

Entire system environment

Specific applications within environment

Service interface (e.g. remote API), typically coarse-grained

Service or component API, typically fine-grained

Typical Implementation

Virtualized appliance, or SaaS offering

Virtualized appliance, or SaaS offering

Standalone application

Platform-specific code and libraries

Typical ‘Cost’ of Acquisition, Configuration, and Running

Prohibitively high (in the majority of cases)




Team Typically Responsible for Operation

External third-party or operations

External third-party or operations



Maintenance Issues

Prone to unavailability (typically no SLAs), restricted access, and long initialisation times

Prone to unavailability (typically no SLAs), restricted access, and inconsistent versioning of service interfaces

Generally limited issues (if managed properly), with the primary challenge being the synchronization of functionality offered by ‘real’ and ‘virtualized’ service

Mocks and stubs can be brittle, as they typically operate at a level of fine granularity

Target Audience

Entire organisation (often used in pre-sales activities, right through to development)

Business analysts (BA), QA, developers

QA, developers


Reusability Potential

The virtual environment is typically shareable, but access must be coordinated, and test scenarios and data may not be shareable

Sandbox is typically shareable, but test scenarios and data are often difficult to share without manual coordination

The SV application is typically shareable across QA and development teams, as are the virtualized interfaces, test scenarios and data.

Typically limited to the owning development teams

Test Automation Potential

Very low



Implicit in operation

Scenario (and Associated Data) Creation

Typically not available

Typically manual creation (and curation) of sandboxed test data is the only option

Virtualized response code generation (from WSDL, Swagger, etc), manual creation of interactions, automated recording of interactions

Typically manually created, but several tools (VCR, Betamax, SOAP UI) allow recording of interactions

Ease of Operation (for Creating and Running Test Scenarios)

Typically complex and managed by third-party

Often complex and customized to the application

Typically easy, as the target audience is non-technical QA

Difficult, as the target audience consists of technically advanced developers

Table 1. Comparison of ’virtualized’ service methodologies and approaches

Service Virtualization Tooling

There are a variety of open-source and commercial products that seek to offer service virtualization solutions.

Open-source service virtualization applications:

  • Wiremock - a Java-based flexible library with a JSON API that can be used to virtualize, mock, and stub web services
  • Mountebank - JavaScript (Node.js) based tool that provides cross-platform, multi-protocol test doubles ‘over the wire’
  • VCR/Betamax - A Ruby/Java-based application that allows the recording and replaying of HTTP interactions
  • Mirage - A Python-based service virtualization tool that provides capabilities to record and replay TCP/HTTP interactions (Disclaimer: The authors of this article are both employed by companies that have contributed to the creation of this tool)

Commercial service virtualization products include:


The emergence of service-oriented architectures, and more recently microservices, promised to improve the ability to continuously deliver business functionality to end-users, but the increased complexity of collaboration and orchestration between these services has often slowed their development. Services are also frequently developed by external agents, or are consumed using the ‘software as a service’ (SaaS) model, and so may not be reliably available for development or testing against. Service virtualization is one technique that can overcome these problems by allowing the configurable ‘virtualization’ of a service interface or API (and associated scenarios and data), which can then be integrated within the development lifecycle, the automated acceptance, functional and performance testing process, and the continuous delivery quality assurance pipeline.

For more insights on microservices, JVM languages, and more integration trends, get your free copy of the DZone Guide to Enterprise Integration, 2015 Edition!

continous delivery, ei, enterprise integration, integration, soa

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}