Planning for Service Management Within a Service-Oriented Computing Infrastructure
A necessary infrastructure for mission-critical deployment
Aug. 3, 2004 12:00 AM
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 ManagementThe more widely Web services are adopted and integrated into the core business of enterprises, the more invisible the structure and performance of these business assets becomes. An enterprise cannot wait until it receives customer complaints or observes decreased revenue before it reacts to problems in its Web service application deployments. In addition, the more granular and distributed the components from which an enterprise's business is derived, the higher the potential risk and cost of any individual component failing or changing. It is management's role to expose and monitor running applications so that problems can be detected as early as possible—and corrected before they become catastrophic.
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 ManagementMonitoring
The classic role of a management system is to monitor. The system collects information about the health and performance of the system and notifies the operator when something is wrong. Web service applications provide a unique opportunity due to their loosely coupled and open nature. They make it possible to add meaningful instrumentation without modifying the application code by intercepting the Web service request and response messages. This interception can help generate a clear picture of system performance at the application level.
A Web services management system should provide the following monitoring services:
A service-level objective (SLO) is a proposed acceptable range of a single verifiable measurement -such as request processing time - that's important to the consumer. A network consumer might indicate that it's never acceptable for the request processing time to exceed 30 milliseconds. These objectives can be specified in complex ways. For example, an SLO might state that request processing time not exceed 30 milliseconds for requests with less than 100 data elements. A service-level agreement (SLA) is a collection of SLOs agreed upon by a service provider and a consumer. SLAs typically protect the consumer but can also protect the service provider. A provider may want to constrain a consumer's access to a service so it can meet other objectives in the agreement. For example, a news content provider may allow a consumer to poll new stories only once a day. This facet of SLAs is inexorably related to the concept of quality of service.
Root Cause Analysis
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.
Architectural ApproachesUsing Web services as the implementation technology for a service-oriented computing infrastructure offers a number of options in how to introduce management functionality.
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 StandardsAlthough there have been a handful of specifications published to address various areas of Web services management, the standards space has been relatively quiet. Currently, the OASIS Web Services Distributed Management Technical Committee (WSDM) is working on two standards that will likely have the most effect on users' perceptions and vendors' products. These specifications are the outgrowth of initial work done by member companies as well as collaboration and interactions with related standards efforts in more specialized forums such as the Globus Grid Forum and the Distributed Management Task Force.
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.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week