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.
Join the DZone community and get the full member experience.
Join For FreeThis 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) | High | Medium | Low |
Team Typically Responsible for Operation | External third-party or operations | External third-party or operations | Operations | Developers |
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 | 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 | Low | High | 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:
- 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!
Opinions expressed by DZone contributors are their own.
Comments