Continuously Delivering SOA

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.

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:

• CA Service Virtualization
• HP Service Virtualization
• IBM Rational Test Server
• Parasoft Virtualize
• Smartbear ServiceV Pro

Conclusion

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!