Arun Candadai

Subscribe to Arun Candadai: eMailAlertsEmail Alerts
Get Arun Candadai via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Federated Service Management

A federated approach to managing highly distributed Web services

Service-oriented architecture (SOA) has emerged as a key strategy for IT and line-of-business executives to jointly enhance business performance and agility in today's intense corporate climate. Using the SOA methodology, business applications are built as an assembly of loosely coupled pieces of business functionality, commonly referred to as services. These services are published, consumed, and combined with other applications over a shared services network, which is often highly distributed within and across enterprise boundaries.

Service-oriented development of distributed applications is increasingly common as businesses seek to build and reuse services and service-based processes in new ways to improve performance and gain competitive advantage. Gartner Group has coined the term service-oriented business application (SOBA) to refer to a service-based approach to building distributed applications.

There are two basic entities in the development of SOBAs - service provider and service consumer. The service provider offers services that the consumer uses and composes into a distributed application that solves a particular business problem. Once the distributed application is established, it can in turn be offered as a service for another service consumer to integrate.

When managing services, most businesses expect management functions to be performed at the service endpoints by a provider that controls the platforms on which the services are hosted. Because a SOBA can be composed of highly distributed and heterogeneous services from multiple providers, it is likely that many of the endpoints will be outside the control of the consumer. Yet, service consumers must still apply governance principles to their distributed applications or risk offering an unreliable and underperforming service to their business users.

To provide proper governance, the service consumer needs a way to apply its management policies and logic to the services it consumes, regardless of the endpoints that provide them. Stakeholders across the enterprise need a unified, yet simple, operational approach to service management that provides capabilities such as:

  • Support for large numbers of heterogeneous service interactions among services with diverse characteristics and management policies
  • Separation of business logic from management logic concerns
  • Separation of governance responsibilities between developers and operational administrators
  • Provide a view of service behavior in an end-to-end business context
  • Ability to monitor and control service behavior at run time
The only way to holistically manage autonomous, disparate, and highly distributed services is to employ a federated approach to service management. Within a federated system, the behavioral aspects of services must be virtualized in a unified manner from the standpoint of the applications consuming the services. This approach provides a service consumer with a standardized way of enforcing policies, best practices, and other management logic at the composite business service level, which is fully compatible with existing management logic at the service endpoint.

When properly implemented, federated service management (FSM) provides a unified method for governance among applications, services, and devices across a heterogeneous network, which will enable developers to easily create solutions for complex distributed environments. The end-to-end view provided by FSM allows service consumers and providers alike to understand in real time the performance being delivered, and to take appropriate actions to rectify issues related to service quality and SLA compliance.

The Problem
As businesses seek to expose their business processes as services and integrate them into SOBAs, it is not surprising that service management is not the first thing that comes to mind. The shift to a service-based concept of business processes and applications is fairly significant in and of itself; hence, most businesses are wrapped up in determining the granularity of their services and how to secure them. When they do consider service management issues, it is almost always from the service-provider viewpoint. This limits them to managing only the services that they own and control, which often leads to an incomplete management solution (see Figure 1).

Viewing governance and management as a service-provider issue has led businesses and third-party vendors to develop platform and container-dependent solutions, which may not be adequate for managing increasingly distributed services across multiple provider domains and hosted on different operating platforms. This management approach typically uses static, platform-specific code deployment to manage services, often mandating that businesses install multiple distributed components (usually from multiple vendors) that result in heavy and expensive systems, which are difficult to maintain. It also does very little to address the fact that management logic for the services usually remains fragmented and service-specific at best.

Businesses seeking to improve their service management capabilities and create a unified management solution must recognize and overcome three governance challenges:

  • First, rapidly expanding service networks will be too complex to manage on a point-to-point or ad hoc basis
  • Second, the distributed nature of service development and usage within an enterprise makes it difficult to control quality and apply standards
  • Finally, perpetuation of code-driven service management will render the architecture too rigid to deal with changing business requirements
Challenge 1: Service Network Complexity
To develop robust SOBAs, businesses must grow their service networks, expanding them across divisional and enterprise boundaries. Most businesses rely on a point-to-point management approach that usually involves implementing custom management logic (for security, message logging/auditing, performance and SLA monitoring, etc.) applied differently for each individual service. This approach may seem satisfactory when the number of services is small, but as the number of service consumer-provider interactions grows exponentially, it becomes a serious impediment to scaling up.

Challenge 2: Static, Code-Driven Management Architecture
Business agility can roughly be measured by the cost associated with changing its business processes. When SOBAs are managed by embedding custom management logic within the service code, it forces management changes to be static, thereby driving up the times and costs required to implement changes. Further, such changes make SOBAs brittle and less agile due to cascading effects and implementation-time delays across the service network.

Challenge 3: Fragmented Management Logic
As services are integrated over multiple administrative domains, it becomes very difficult to define, apply, and enforce configurations and policies in a consistent manner. Each provider develops and maintains its services according to its own goals and standards, perhaps using different approaches to solve the same issues. This fragmented approach makes it harder to enforce consistency and integrity of service configurations because administrators are inadvertently shielded from getting a complete view of the management logic embedded in the service.

Consequences of Inadequate Service Management
If the aforementioned service management-related issues are not addressed, they can significantly undermine any value a business may be seeking from developing SOBAs. More important, they can negatively impact the overall business in the following ways:

  • Service/operational administrators confuse effort with results because managing at the service endpoints doesn't provide sufficient information to make management decisions for the composite business applications as a whole. For example, when services are managed at the endpoint, SLA compliance is tracked at the endpoint. This provides a skewed view of service performance because it does not fully account for network or other latencies. In this case, the SLA may be fine from the provider's viewpoint and yet fail to meet the consumer's expectations.
  • Brand image is tarnished by unpredictable service quality resulting from inconsistent development standards, mismatches in performance expectations, and inability to adapt management logic at run time.
  • Business is slower to respond to competitive threats and changes in the marketplace because the higher cost of changing management policies makes it willing to accept greater risk to justify changes.
  • Lack of a unified service management approach leads to redundancies and unnecessary development efforts.
The Solution
What is ultimately needed is a way to enhance SOBAs with unified, end-to-end service management and run-time governance. To meet this need, a solution must enable service consumers to federate the management of services they consume. Federating service management means recognizing and understanding the endpoint-management constraints specific to the services, virtualizing the functional and nonfunctional aspects of the services, and applying overarching policies and standards to govern how the services interact with each other and the application. This unified approach empowers service consumers with control over their business performance and enables them to monitor SOBAs in an end-to-end fashion (see Figure 2).

Business Value Drivers
A well-designed FSM solution must focus on addressing the key business value drivers for the enterprise: visibility, flexibility, and accountability. SOBAs that are built from highly distributed services demand a management solution for services that cuts across divisional and enterprise boundaries in a seamless manner:

  • Visibility represents a business's ability to have real-time answers to the what, when, where, why, and how of various service activities and events that occur. However visibility is about more than a simple registry of WSDL files and some service message logging. Visibility exposes all of the service metadata - the configurations and policies of the services. Real visibility takes this metadata beyond the developer level and design-time environments into the run-time environments of administrators and other operations-level users who need to see and influence all aspects of service behavior.
  • Flexibility represents a business's ability to adapt quickly to changing requirements without being constrained by costly, time-consuming code updates or proprietary standards. Achieving real flexibility means lowering the cost of change in how services are configured to an absolute minimum. The most costly changes are ones that require the service to be redesigned. Much like visibility, real flexibility requires freeing management changes from the design-time environment and enabling them in a run-time environment. This gives administrators and business managers the opportunity to act on the information gained from improved visibility.
  • Accountability represents a business's ability to monitor and control the relevant services - within the overall business context of the composite SOBA - in order to enforce performance standards and to deal with exceptions. When services interact across multiple domains, the diverse combination of "local" standards and development practices makes it important to accurately identify the source of performance problems or exceptions. Real accountability means being able to focus management activities on the individual services within the integrated SOBA and enforce unified standards in an end-to-end context, regardless of how the services are managed at the endpoint.

More Stories By Arun Candadai

Arun Candadai is cofounder and CTO of GridScope (www.gridscope.com), and is responsible for the company's technology strategy and product development. Prior to founding GridScope, he was lead architect at BEA Systems where he pioneered the use of Web services and SOA for its enterprise infrastructure. Prior to BEA, he held senior engineering management roles at companies including Asera, Covad, and Lockheed Martin. He holds three software patents and has helped develop key Web services standards.

More Stories By Robert McKenney

Robert McKenney is cofounder and VP of Product Management of GridScope (www.gridscope.com), and is responsible for the company's marketing strategy and product positioning. Prior to GridScope, he directed the product management at Internet software startups such as Integres and PostX. Prior to that he held senior product and program management roles at AT&T Wireless and the US Department of Defense.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.