seven steps to web services governance

© 2012 by EA-Optimised Limited. All rights reserved www.ea-‐optimised.co.uk

Conclusion

The governance of web services is not a complex task although it does require some degree of planning. Further, the task is made considerably easier with the user of one of the modern governance tools that are available on the market.

This is definitely a case where the simplification of environments and design patterns will yield better results.


Run

Services in a running environment need to be monitored to ensure they are not under too much load, if they are, and this can be ascertained from the non-‐functional requirements, additional instances of a service can be created to horizontally scale the load.

This is also where versioning is important; it is completely legitimate to have several running versions of running services, each supporting multiple versions of the supported interface. The reason for this support of multiple versions is simple. Different components within enterprise solutions mature at different rates, and as such older components may well need to talk to older service interfaces.

Decommission

Decommissioning of a service version should only take place when it can be shown that its end point are not bing consumed by any callers. This can make decommissioning tricky.

The trail of what services are being called and by whom can often be resolved by one of the newer governance tools such as service registry that will register services into the environment and then monitor their usage.

Once a service is no longer required, it can be safely decommissioned. This is a process that requires some signoffs and a clear audit trail.

Archive

The final stage in the services governance cycle is archiving. After the services have been decommissioned, there needs to be a clear code retention policy, since a time may come when the service has to be recreated.

The policy should state;

1. The length of time after decommissioning that code will be kept. 2. Where the code repositories can be found that allow services to be

rebuilt. The code repositories should also hold the build scripts that enable the reconstruction of the environment.

3. The test scripts need to also be maintained in an appropriate archive. In their absence it will be impossible to prove that a service is generating the correct results.


Important feature are the clarity of design around the WSDL and having clear and unambiguous understanding of the required performance characteristics. In particular once the service interface to a web service has been agreed it needs to be seen as immutable.

If for any reason asn interface need alteration, then it should not be changed, rather an additional interface should be added.

This approach can be used to stop the proliferation of services and ensure that callers are able to interact with the appropriate version and interface.

Build

Build is no more difficult than it sounds, however the usual good house keeping and practices should be maintained. In particular it is important to ensure that a good source management tools is in use and that services are always built from scripts; this being the only reliable way of ensuring what defines a particular version of a service.

Test in Environment

I say test in environment since it is assumed there will be many environment and before any service is deployed in a live deployment it will have moved though a whole series of others. Typically, these will include at least;

1. Development 2. Test(s) various 3. UAT 4. Pre-‐Prod 5. Prod

Failing tests at any of these stages means fixing bug and starting the process over.

The importance of ensuring environments are identical cannot be over stated. Again environment should be build from scripts. Any variance in configuration or patching level is likely to undermine the whole test process.

Promote

As this name suggests, this is simply the business of moving services from one environment to another. However, the criteria under which the promotion takes place need to be documented and signed off, providing a clear audit trail.


Seven Steps Web Services Governance

Introduction

Web services form an important part of many enterprise class solutions. However, the necessary velocity with which web services can be created and changes presents many challenges. It its therefore vitally important to ensure that any such environment is well governed. This extends to ensuring that non-‐functional requirements are met as well as and including levels of performance, availability and security.

This document sets out to describe a possible system of governance that can be used to maintain an enterprise class service environment. However, what it does not discuss it the use of UDDI and services registries that may well be deployed to support your governance model.

A Typical Governance cycle for Web Services

Design

Design is as expected, the start of the process, and there is nothing unusual about this particular design activity, with the exception that it should always be possible to obtain the version of a particular instance of a web service.

Design

Build

Test in Environment

Promote Run

Decommission

Architve

seven steps to web services governance

Technology