Using a service registry that doesn’t suck Part III: Service testing is part of SOA governance

This is the third post of this series intended to highlight some of the principles of modern SOA governance solution. You can read the first two parts here:

• Using a service registry that doesn’t suck part I: UDDI is dead
• Using a service registry that doesn’t suck part II: Dear registry, do you have to be a message broker?

This time I’ve decided to focus on what of the aspects that drives me ABSOLUTELY INSANE about traditional SOA Governance solutions: service testing or I should I say the lack of service testing.

Scenario

SOA infrastructures leverage SOA governance frameworks to model its web services ecosystem. Typically, that ecosystem is based on the services and policies that implement the different functional blocks of various enterprise solutions. As the SOA management arm, the MOST important aspect of a SOA governance framework is to provide accurate and simple to understand information about the runtime behavior of the services available in a given SOA infrastructure. When a SOA governance product fails to enable this ability of understanding the characteristics and behaviors of a service it becomes another archaic data repository in your enterprise infrastructure. Sounds familiar? ;)

Thinking around lines, we can probably agree that modeling rich functional tests is one of the most effective ways to communicate the behavior of a web service. In the era of test driven development (TDD) and continuous delivery, testing (on its different variations) is a key mechanism to help users to understand the functionality of a specific piece of a technology. In the case of SOA governance, functional tests will help developers, architects to effective understand the characteristics of a service, it’s runtime behavior based on the different policies, it’s SLAs and performance profiles among many other key governance aspects.

Arguably, the most important thing about service tests as a SOA governance mechanism is that it provides REAL information about services, policies etc. In that sense, functional service tests are much more effective than static metadata when comes to understand the behavior of a service. Unfortunately, SOA governance products like SOASoftware or HP-Systinet have spent years building products that completely ignore these facts.

The screwed-up traditional solution: “No hablo” service testing

As explained in the previous section, service testing should be seen as one of the fundamental mechanisms of any effective SOA governance strategy. Sadly enough, service testing and SOA governance have evolved on separate paths for the last few years. As a consequence, traditional SOA governance products such as SOASoftware or Systinet DO NOT INCLUDE any support for testing in their current versions. Instead, enterprises need to invest in additional products such as SOAPUI Pro in order to implement any sort of service testing strategy.

The challenge with this approach goes way beyond the hassle of having different product suites for testing and SOA governance. More often than not, organizations that follow this approach end up with separate, unrelated paths for their service testing and SOA governance strategies. This is mostly due to the fact that, based on interoperability limitations, it’s incredibly hard (and expensive) to integrate any sort of testing module into traditional SOA governance products such SOASoftware or HP-Systinet.

Using an analogy, you can think about the SOA governance process as a government agency that is responsible for creating and implementing a series of policies for the internal affairs of a country. Now think about what would happen if that same agency will delegate the monitoring and validation of those internal policies to a foreign country. Sounds crazy? Apparently not crazy enough for products like SOASoftware or HP-Systinet :)

The SO-Aware way

With SO-Aware we are trying to bridge the gap between service testing and SOA governance by bringing the two together in the same lightweight service registry infrastructure. In that sense, service testing has been one of the first class citizens in SO-Aware since its conception. In the current version, developers can model functional tests against a service endpoint and organize those tests into semantically meaningful categories so that they can be followed by other users. The following figures highlight the process of authoring a test on the SO-Aware portal.

After creating a tests, the developers can either execute the test on demand (a la SOAPUI) or schedule it for future execution. SO-Aware will track the execution and results of the different tests and it will enable certain analytics around it as illustrated in the following picture.

That’s great! but I have all these other test tools…..

Even though SO-Aware provides a highly sophisticated service testing infrastructure, we really wanted to empower developers to enable creative testing mechanisms that are the best fit for their SOA solutions. In order to enable that, SO-Aware exposes its entire testing infrastructure using a very simple REST base API that will allow developers to extend SO-Aware with their own testing strategies. Using this API, you can integrate the SO-Aware testing infrastructure with unit testing frameworks like NUnit, build servers like CruiseControl.NET, bug tracking products such as JIRA, among others. A clear example of the simplicity of SO-Aware’s REST API is the fact that we can execute a test by issuing a simple HTTP GET as illustrated in the following figure.

At this stage in the evolution of SOA infrastructures, I believe that investing in a SOA governance strategy that doesn’t include service testing is a recipe for failure. That approach will not only prevent your SOA governance infrastructure from the most effective way to describe the characteristics of a service but it will force your SOA governance and service testing strategies to evolve on separate paths disrupting what should be a keep premise of your SOA governance infrastructure: simplicity.