SOA Governance

Background

Many companies today are moving towards SOA architectures that can be used to leverage existing work and assets. As part of that trend, the company has standardized on web services as the de-facto method for providing services and integrations, particularly those integration built with the middleware or Enterprise Service Bus (ESB) products. While web services do provide a high level of interoperability, and SOA does in fact cut IT cost and effort across the enterprise, these technologies are not without their risks that need to be addressed.

SOA Governance Risks

There are several issues and risks that organizations face as it relates to integrations and Service Oriented Architectures (SOA), particularly in areas that relate to discovery, control and standardization of web services. This group of risks is referred to as SOA Governance Risk.

  • Changes to web services / interfaces over time.
  • Migration of integrations up the production pipeline.
  • Unmonitored services and security concerns.
  • Discovery of existing services.
  • Standardization of services

Changes to Interfaces Over Time

As projects change over time due to scope increases, requirements changes, and bug fixes, changes to the services that provide the desired functionality and integration points to other projects may also change. These changes might be as small as adding an additional piece of data, changing the server location, or changing the port on which the service operates. While these changes may seem minimal, they can have a fairly dramatic impact downstream. Any time that these changes are made, the group making the change may be altering an interface "contract" that they have with the consumers of that service. Those changes will almost always require some type of corresponding change by the service consumers.

The use of ESBs for integrations helps ease this burden on the consumers through the elimination of point to point interfaces. A single change that only affects the connection to the message bus only requires a change to the service requesting information, instead of changes to all of the consuming services. However, if the "brokering" service itself changes, it may affect many consumers (this is not without precedence). If a change is not properly designed, tested, and then communicated, the party at the other end of the interface contract may not know, and composite applications or integrations will cease to work properly.

Migration Through the Production Pipeline

Web services are invoked by making a web request on a defined URL and port, after which a message can be sent. As web services move from the test / development tier, through stage and into production, the URL of the web service changes due to the fact that the machine name changes. Web services consumers are coding their request against this static URL - this causes a problem similar to the one that occurs with interface changes over time, caused by the static binding of web services.

Imagine a scenario where an integration is being developed where both sides of the integration are synchronously moving through the production pipeline, starting in the Test tier. Initially, the web service integration would exist in the Test tier, where each team would test the integration and prove that it works. Once testing has confirmed success, the teams would want to move to the next tier, Stage. Unfortunately, the move to Stage would require that any web service requests be 're-coded to reflect the new URL, which means that a code change is required to move up the stack. This causes inherent risk as anytime a code change is made, no matter how small, it may cause an error to be introduced.

Unmonitored Service Requests and Security Concerns

Web services do not provide any innate security model or ability to determine who is using them and how out of the box. Some of these abilities can be gained by providing business logic in the underlying service that is able to track and deny usage. There is an inherent risk in leaving the security determination to occur that far back into the service - by that time, the requester has already gained access to the service via the web service interface and can potentially exploit it. A far more secure method would be to secure the web service and only provide access to the service to those who pass the proper credentials.

Even this model still can create a maintenance nightmare. Imagine a web service that exposes 4 interfaces, like the following:

MyWebService
- getX
- getY
- setX
- setY

If MyWebService is secured by providing access to the entire web service only to approved services or individuals, then you would have to give all users the ability to not only get values, but also to set values. But, what if there were services / users that you only wanted to be able to use the 'get' methods? You may be forced to write another web service. Then you would have one for services that are allowed to set and get values, and one that is only allowed to view (get):

MyWebService MyWebServiceGet
-getX - getX
-getY - getY
-setX
-setY

This problem becomes exponentially difficult to manage as each service may expose any number of interfaces in any combination. The maintenance and logic that would be required to maintain all of these interfaces and web services would soon become overwhelming and create a significant risk related to the ability to effectively control access and provide accurate and consistent information within the bounds of the security constraints.

Service Discovery

In many organizations, development groups currently track the collection of web services that they have created in any number of ways including spreadsheets, word documents, and collective memory. The teams must not only track of all of the interfaces that have been created, but must also keep documentation synchronized with actual changes and functionality. This is important both internally and externally to the team. Effective use of existing web services will not be achievable if teams are unable to provide this information accurately and communicate it effectively. As the number of web services proliferate, this issue will become more acute. Teams may not be aware of existing services and may create additional duplicate services, causing an even greater proliferation but also creating significant rework and inefficient use of corporate assets.

Web Service Standardization

Web services across organizations may be implemented and delivered in a variety of ways - Many times there is no standardization of web service delivery across the organization. That means that not all web services will be compatible (or have some expected level of compatibility) and that some web services may have detailed description of their functionality while others will have none. This is due to not having a web service standard in place within the organization. Even if there were a collection of web services standards, there may not be an enforcement policy or tool in place that can help make sure that these services follow the guidelines - even manual reviews and inspections will fail occasionally when trying to enforce these policies.

Potential Solutions

The issues noted above can be remediated using a combination of solutions which include:

  • Creating a process and a collection of enforceable standards for creating and using web services
  • Providing the ability to discover web services and their descriptions from an authoritative source
  • Providing granular access to web services
  • Provide a mechanism that allows dynamic binding to web services

Related Topics

Service Oriented Architecture

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.