The more widely service-oriented architectures become incorporated into core business applications and processes, the more critical the ability to easily configure, manage, and monitor the overall infrastructure becomes.

By their very nature, service-oriented architectures, or SOAs, are about enabling heterogenous, componentized, and distributed applications to work together seamlessly. This presents a number of classic service management challenges such as auditing and logging, security, quality of service guarantees, service-level agreements, service life cycle, and service virtualization.

This article examines SOA management features that will become critical as services are widely deployed in mission-critical environments. In addition, I describe the common architectural approaches used to integrate WSM into a service-oriented architecture, as well as emerging standards and their likely impact and utility.

The Purpose of Management

It's also clear that nearly all Web service deployments require a common set of capabilities (such as security and monitoring) in order for them to have true enterprise-quality reliability. These capabilities are often complex and, therefore, prone to error. Thus, Web service developers should not be forced to re-implement them with every new Web service; these capabilities should be provided by the underlying infrastructure.

With this in mind, the aims of Web services management are manyfold. Its goals are to make the structure and performance of Web services applications more visible; mitigate the risks associated with SOAs as they're deployed and as they change over time; and provide a common set of capabilities that let Web service developers focus on implementing business logic as opposed to infrastructure.

Key Features of SOA Management

A Web services management system should provide the following monitoring services:

• Performance monitoring: The ability to record the amount of time required to accomplish various system operations, such as response time. When considering performance monitoring, note the cost or overhead incurred to perform and record the measurement.
• Resource monitoring: The ability to monitor and record the usage of various consumable system resources under load, such as memory use or concurrent request count.
• Availability monitoring: The ability to determine when the application is available for use. Ideally, this monitoring will occur at numerous levels to support root cause diagnosis.
• Fault monitoring: The ability to recognize and notify an operator when an application component has failed during request processing.
• Notification: The ability to alert an operator to a problem that was discovered as a result of monitoring. Notification can be as simple as e-mail or as complex as custom integration with a third-party network management system (NMS).
• Probing: An active management component that initiates synthetic requests to trigger performance and availability monitoring. This lets the system manager discover problems before users encounter or report them.

Root Cause Analysis
One of the primary goals of an SOA management system is to provide the ability to diagnose and correct problems. It's the role of monitoring to determine that there is or soon will be a problem. Beyond that, the management system should offer tools to narrow down the cause of the problem.

The nature of distributed, collaborative, loosely coupled services can make this difficult. Services interact independently of human intervention and such interactions often occur between separate organizational units or companies. To help diagnose problems, the management system must provide some way to represent the dependencies and interactions between Web services. The ability to discover these relationships through passive monitoring can be a plus when relationships between consumers and providers are established dynamically. The result is a repository of metadata that describes these relationships and can be used to correlate and order collections of failures.

Virtualization
Virtualization is an umbrella category of a set of capabilities that are primarily concerned with insulating service consumers from change and providing service providers with implementation and deployment flexibility. Chief among these capabilities are transformation and routing. Transformation lets users adjust for minor changes in a services interface so that older interface versions can be maintained in the virtualization layer. When a request is received with the older format, a transformation is applied to make the request conform with the new interface. In this way, interfaces can be moved forward without requiring clients to upgrade immediately. Routing allows messages to be redirected when a destination service's location changes due to network reorganization or hardware changes.

Security
When dealing with security, the service delivery platform and the management infrastructure must cooperate closely. At times there can almost be no distinction made between which part of the system provides the functionality. It's important that the combination of platform and management system should be able to provide the required security features. It's also critical that security decisions be made as late as possible in the development deployment cycle and that a great deal of flexibility exists when these decisions are made. To this end, the combined platform and management system should provide the following features:

• Auditing: The ability to record in a secure and robust manner any access to deployed services.
• Authentication: The ability to validate the identity of intended service consumers. The service developer should not be responsible for specifying who these entities are and how their credentials will be provided and verified.
• Authorization: The ability to control which services and operations are available to a given entity based on a user-specified security policy. The policy should be able to consider not just identity but also access time, the consumer's network location, and other criteria associated with the request context.
• Confidentiality: The ability to hide request and response data from unauthorized viewers. For XML-based services, confidentiality should be applied at a fine-grain level, allowing encryption of selected portions of the message body as well as the entire message.

Architectural Approaches

One choice to make is whether management functionality should be integrated into the service execution platform or the service network. Management functionality is typically added to the service execution platform by the platform vendor. In this scenario, service interactions are passively monitored by the runtime, and control points are introduced into the infrastructure to facilitate management features. In contrast, integrating management into the service network can be done independently of the platform provider(s). With this approach, a proxy or intermediary is positioned in the network to intercept service requests and responses. Management capabilities are then deployed on the proxy/intermediary, which acts as a monitoring and control point (see Figure 1). Both approaches have their advantages and disadvantages.

A platform-integrated approach will typically incur less of a performance overhead. It can also allow a more comprehensive insight into message processing. Also, since integrated management capabilities are usually offered by the platform vendor, you'll usually see a broader range of control functions as well as greater consistency between the Web services management features and other systems management functions, as depicted in Figure 2. The biggest disadvantage of platform-integrated management is most evident in heterogenous environments where multiple vendors' service execution platforms are used. In these environments, system administrators have to understand multiple management tools to manage the entire network. Administrators typically want to have a consolidated view of the state of the enterprise's systems, but when integration between multiple vendors' service management systems is possible, it's difficult due to the lack of mature standards in this space. Also, some service platforms may not offer intrinsic management capabilities, in which case an add-on product is necessary.

Placing management in the network makes it easy to manage heterogenous networks. Services from multiple platforms can be routed through the management proxy/intermediary, which also facilitates central management and configuration. The proxy/intermediary model can also be introduced into a service topology as an afterthought without requiring potentially costly upgrades to server infrastructure or applications. The proxy/intermediary approach is also particularly well suited to certain types of applications and environments. Virtualization features are typically associated with an intermediary deployment model, and organizations that broker services for third parties will also typically use this approach. The big disadvantage of the proxy approach is the performance cost of adding an additional network hop.

Web Services Management Standards

WSDM will produce two specifications: one focused on Management Using Web Services (MUWS) and the other on Management of Web Services (MOWS). The MOWS specification provides a framework for using Web services to manage general IT resources but does not specify a management information model, leaving this to particular management applications or products. This recognizes that good management models already exist, and allows MUWS to be used in conjunction with existing systems management tools. MOWS, on the other hand, builds on MUWS to provide an information model for Web services, defining the management capabilities and attributes of Web service entities such as ports and endpoints.

The WSDM specifications are currently in draft status, however, leaving developers and architects who need SOA management today to choose from a variety of solutions that offer similar capabilities but are, for the most part, not interoperable. Also, given the velocity at which draft standards become final, and at which final standards are implemented in commercial products, it will probably be a while before we can count on standards-based SOA management being generally available.

The good news is that at this point, the standards are largely orthogonal to the decisions organizations need to make today. When WSDM is available it will define interoperable interfaces, allowing management functionality to be exposed, queried, and controlled by a broad range of tools. However, the management functionality itself will still be a function of product and platform capabilities, and this is how buying decisions should be made. Assuming the vendor you choose is committed to supporting WSDM as it matures, the migration to standards-based interfaces should be transparent to managed resources such as services and applications.

Conclusion
SOA implementations require many features to make them robust. Service monitoring, service-level agreements, virtualization, and security are all important parts of most service implementations. Just as application servers provide a multi-user, transactional infrastructure for applications, Web services management provides the necessary infrastructure to make Web services suitable for mission-critical deployments. Building your SOA architecture with Web services management explicitly addressed will make development time shorter, the services more maintainable, and the system more reliable and robust.