The principles of service-oriented architecture (SOA) have cut across virtually all disciplines of software development...
and deployment. For this reason alone, SOA governance is a primary concern for IT professionals. One aspect of SOA, however, is both a major source of issues and an opportunity for architects to gain better control.
Service discovery is perhaps the largest source of risk source. The service repository/registry is a rich source of application information that can facilitate governance. To make optimal use of SOA repository/registry, start with measuring service dynamism, move to registry-to-governance coupling and on to auditing service use.
Where SOA governance practices fall short
In theory, SOA provides dynamic binding of components to applications through a unique process of service discovery. Based on a user/applications needs profile, SOA allows for browsing for compliant services through registry metadata. The Web Services Description Language (WSDL) contained in a registry allows applications to be bound into workflows at runtime rather than being rigidly assembled. Most SOA deployments will exercise some visibility control on registry services to ensure that they're not used in a way that violates business policy. Lack of consistent practices here is likely the largest source of run-time issues associated with the SOA registry.
Where current practices also frequently fall short is in the run-time governance of registry-driven applications. This process starts with the service repository, the point of registry storage, and moves through application service-level agreements (SLA) to application performance management and monitoring.
Successful SOA run-time governance
Run-time governance of SOA is a feedback loop in action. The service/message bus links the consumer and provider of services through the intermediary of the registry. A service management process is responsible for taking quality of experience (QoE) data from the closed system and converting it into alerts, again with the help of registry data. The result is a combination of remediation processes where automated responses to problems are feasible and a set of escalation alerts to management handles situations outside the automated response window.
Web services, like security and identity management, are coupled in through the service/message bus as well. The combination of service management data and registry policies is the basis for run-time governance of the whole system. One gains control of the governance loop in the application lifecycle project initiation phases, and exercises control through policies (registry and service management) in the deployment phase.
Run-time governance depends on an effective registry taxonomy, the structure of service descriptions that permit the taxonomy to be classified, graded access by individuals and organizations, and links with service delivery performance policies that drive run-time service management processes. Every SOA user will have policies, but most don't contain the full spectrum of run-time data needed.
The only way to get the taxonomy right is to develop it interactively with service management and governance processes to ensure that the needed data is actually included. Most companies with successful SOA run-time governance include a detailed "concept of operations" description to link run-time governance to a service policy.
Important service repository, registry components
The definition of operations policies (performance and access security, logging, etc.) as part of the registry creates an immediate issue with run-time performance since information is likely to be accessed regularly throughout the execution of services. Performance issues will impact repository design (the database where the registry is stored) as well as service/message-bus performance.
Database efficiency is critical for SOA run-time governance, to the point where special measures for storage performance, such as caching or duplicate distribution, may be appropriate. An SOA registry is similar to a redundant online transaction processing (OLTP) database with multi-phase commit for changes.
Generally, SOA registries are not highly dynamic in update terms, but be sure activities don't run on an obsolete copy no matter how infrequent updates are made. A distributed, redundant repository allows elements of an organization to access local registry copies where extended access to a central registry can't be made performance-efficient.
Proper service repository, registry management
The service/message-bus access to the repository is likely the most critical, which means decisions on managing or enhancing repository performance should be made based on exactly how the registry is accessed by the bus. This is particularly problematic when distributed-bus architectures are mandated by the fact that workers/services are scattered over a wide geography. Even the internal performance of the message bus (the overhead associated with service invocation) can be a major issue in meeting application performance standards, so regularly review bus performance and its relationship to service repository implementation.
Service management linkage to registry/repository and bus architecture is the most problematic, particularly where operations policies for services specify tight QoE guidelines and logging activities are required for compliance. Management events will generate registry access to obtain policies. If hits are frequent, the impact of performance management can be significant. It's best to have service QoE analysis generate governance events rather than the lower-level management processes; they should filter out events that don't create a QoE issue before registry access is made.
Additional impacts on SOA governance
Finally, redeployment of services affects governance because it necessitates a registry update. If service access/binding is logged under compliance policies, it may be possible to use these logs to review the performance of applications that involve the service after redeployment. That way, you can ensure changes to the service or the registry haven't had a negative impact on QoE or violated compliance policies.
All IT professionals know that problems are likely caused by a recent change. Starting with changes recorded in service binding logs is a good way to regulate governance issues related to new services.
The registry, properly structured and with a consistent topology, is the most powerful governance tool in SOA because it centralizes decisions. It's also a single point of failure and congestion. Both attributes have to be accommodated in a successful governance practice design.
Tom Nolle asks:
Would you consider SOA governance a primary challenge you face?
0 ResponsesJoin the Discussion