Why Runtime Governance is Critical for Service-based Applications

W H I T E P A P E R

WHY RUNTIME GOVERNANCE IS CRITICAL FOR SERVICE-BASED APPLICATIONS

February 2009

Copyright © 2009. Progress Software Corporation. All rights reserved.

TABLE OF CONTENTS

> 1.0 Executive Summary 1

> 2.0 Runtime Governance—What Is It? 1

> 3.0 Runtime Governance Today 3

> 4.0 What Is Discovery? 4

> 5.0 Service Provider Discovery 6

> 6.0 Service Consumer Discovery 6

> 7.0 Registry Integration 8

> 8.0 Flow Mapping 9

> 9.0 Rogue Service Elimination 11

> 10.0 Summary 12

1Copyright © 2009. Progress Software Corporation. All rights reserved.

1.0 EXECUTIVE SUMMARY

Most architects of a service-oriented architecture (SOA) or other service-based IT initiatives understand the necessity of governance during design and development to control the way services are built and used and promote their reuse. There is also a need for governance in the runtime environment. This paper explains why. It examines:

> What runtime governance is

> The stages of runtime governance

> Fundamental runtime governance functions—discovery, registry integration, and rogue service elimination—and how Progress® Actional® Enterprise provides them

> A developer case showing the value of Actional runtime governance capabilities

2.0 RUNTIME GOVERNANCE—WHAT IS IT?

Interoperability and service reuse are among the major promises of service-oriented architecture (SOA) and distributed, service-based IT initiatives, such as Web 2.0, cloud computing, ESBs, messaging, and business process management (BPM) systems. Interoperability and service reuse are essential to business agility. Service reuse ensures new applications or changes to existing ones can be quickly deployed while service interoperability assures business transactions execute reliably in the new or changed applications.

Yet interoperability and reuse can only be fully realized when everyone is working on the same page. Hence, not surprisingly, services and service-based applications have been a key driver in the increasing emphasis on, and interest in, governance in recent years. Leading the charge for governance have been enterprise architects, who know quite well that for such systems to deliver value, there must be control in areas ranging from service design and deployment processes, to granular items such as schemas and WSDL creation.

Formerly, given the early stage of service-oriented technology and practices, it made sense that organizations implementing such systems focused primarily on these areas, especially since most companies were still in the development and design phase. Today, however, with distributed, service-based applications now in production within many organizations, system architects are realizing that the most critical area for control and governance is now runtime. Data point after data point has demonstrated that many distributed, service-based applications are just not working in production as designed or expected. Problems range from service interruptions to entire business processes failing and security and compliance risks that generate costly delays and lengthy triage cycles. As these problems continue to pile up, runtime governance is, not surprisingly, now taking center stage for companies launching and utilizing all kinds of distributed, service-based applications.

“Service-based applications

are designed for a world…

where every project team is

empowered to immediately

and directly solve its

problems using whatever

tools are appropriate,

but with controls, so that

even though the project

teams think they’re

directly connecting to

other applications, the

infrastructure under the

covers is taking care of

quality of service, security,

and reliability—automatically

and seamlessly.”

Dan FoodyVice President Actional ProductsProgress Software

Copyright © 2009. Progress Software Corporation. All rights reserved.2

The Four Stages

Runtime governance can be divided into four primary areas: process, measurement, enforcement, and feedback. Process comes first because if it is compromised, circumvented, or not adhered to, there can be no effective control.

Process

While a great deal of process is employed in the pre-production side of distributed, service-based applications, active governance kicks in when an application is migrated from development and into production. It is at this point that runtime governance can detect and report if services or consumers in production are adhering to governance guidelines. Experience indicates that violations can result not only from “rogue” service components that have somehow bypassed the development governance process, but also from services that have gone through the proper release process according to the established governance guidelines, yet somehow result in violations when in production.

Measurement

While significant governance work and planning occur in design and development, what is critical to governance is what occurs in the runtime environment and, more to the point, knowing what is going on across your services network during runtime. For example:

> Are all my services in compliance now?

> Is customer data encrypted?

> Does the service have the right security policies in place?

> Are the business rules being enforced?

Enforcement

End-to-end visibility and control over business processes are critical to enforcing business and IT rules, reporting on them, and having the ability to do something about them in real time. Specifically, when governance guidelines are enforced, a runtime system can dynamically react to business opportunities or IT issues to directly impact the bottom line.

Feedback

Systematically tracking governance infractions and tracing their causes facilitate a lifecycle approach in which organizations are able to quickly fix and address breaches upstream. Runtime governance plays a crucial role as the last line of defense and is designed to protect the company and the IT system. By carefully coordinating development governance (i.e., the UDDI registry) and runtime governance, organizations can build a world-class governance initiative with each party doing its part at the proper time.


3.0 RUNTIME GOVERNANCE TODAY

Progress Software Corporation is a leader in the area of runtime governance as a result of our experience with customer deployments and our unique technology capabilities. With the ability to automatically discover services and consumers in production environments, Progress® Actional® Enterprise makes it possible for organizations running service-oriented architectures and service-based applications to immediately and automatically apply governance policies. This capability represents a fundamental shift forward in service governance, not to mention a significant advancement in reducing the risk traditionally associated with service-based implementations. While system architects in the past had no choice but to pursue a strategy of “the services that we’ve tested compliance with are…,” they now can confidently state that “there is no service in production that does not meet the compliance requirements of our governance policy.”

Making this all possible is Actional Enterprise, which is delivering runtime governance for many of the world’s most complex application environments. Actional’s innovative technology applies directly to any basic governance model, including:

> Service provider discovery

> Service consumer discovery

> Out-of-the-box integration with leading registries, such as HP Systinet , Oracle Registry/Repository (formerly BEA ALER), Software AG’s CentraSite Governance Edition, and Fujitsu’s and Software AG’s CentraSite Governance Edition

> Flow mapping and service dependency tracking (both upstream and downstream)

> Rogue service elimination

It goes without saying that a runtime governance strategy for SOA and other distributed, service-based applications is not limited to Web services and HTTP running on J2EE and .NET application servers, but also includes various other protocols and platforms prevalent in real world SOAs such as RMI, EJB, JDBC, etc.


4.0 WHAT IS DISCOVERY?

Like the word “governance” itself, the word “discovery” can be defined a number of ways and, typically, used under a variety of situations. Some developers need a service, so they search (to discover) services that are available. When they find one in the registry, they then can use dynamic binding to “discover” the endpoint (location) of the service at runtime. Think of this as “googling” for a service. So far, so good. But moving forward, things get complicated because there is no way to discover any of the following:

1. What services are in production? Just because a service does not appear in the registry doesn’t mean it isn’t in use.

2. What services are being used? Administrators might see load on a system or an interface, but without Actional there is no way to tell where messages are going.

3. Who are the consumers of a service? Security controls and protects access, but you still have no way of knowing which consumers are using your service without the expense of auditing every transaction/message and grepping log-files (subject to errors and bad performance).

With Actional, this scenario changes completely because Actional allows for true runtime discovery of both service providers and service consumers. Actional brings end-to-end visibility into what today’s complex composite applications are actually doing and maps out each and every dependency. Yet, with Actional, this type of discovery does not require manual configuration and correlation, but constantly updates by observing the flow of real messages. The point of automatic runtime discovery, after all, is to find what you don’t know is going on within your services network.

When searching for services, Actional visually responds by providing a list of available services and other metadata about the service (e.g., policies, security requirements, business metrics, service-level agreements, etc.). With its familiar user interface and icon-based graphic representations, Actional makes discovery a much richer and dynamic experience than with traditional registry products. An Actional-discovered service network is shown in Figure 1 below. Additional drill-down information is just a double-click away as shown in Figure 2.


Notice the operation-level detail provided in Figure 2. One of the challenges faced by organizations as they manage their services’ lifecycle (via versions and revisions) is that typical registry products provide only service-level visibility. The operational-level richness provided by Actional dramatically increases usability.

With Actional, information learned through the governance process can also be easily shared with open registry or repository products for a consolidated approach to service metadata management. Imagine a search being done on a service returning actual performance statistics or current service levels. Developers will have better information, enabling a better decision-making process, increasing returns across the board. Better

Figure 1: An Actional-”discovered” service network

Figure 2: With Actional, you can drill down to obtain application, path, and message-level information in the services network. This information is automatically discovered by the software and can be shared with a registry or repository.


information also aids in planning and operations, primarily in the cost savings associated with reuse. Other benefits include improved morale, lower support costs, and increased use of technology within the organization.

5.0 SERVICE PROVIDER DISCOVERY

Actional manages a services network via a number of agents or points. It monitors operations, i.e., the execution of distributed processes by the underlying IT infrastructure, through points of visibility. It dynamically adjusts or optimizes services’ operational behavior, for example, to meet specific SLAs, by points of control. And it enforces security and compliance policies via points of enforcement. Points of visibility are installed directly on the provider platform, and control points are installed centrally (to service a number of providers) or locally on the same node as the provider. Both points of enforcement and points of control are managed centrally by the Actional server, though policies are enforced in a distributed manner to gain very broad scalability and unparalleled performance.

Without any configuration (other than product installation), services are automatically discovered (by correlating information from the points of visibility), ensuring that services are not implemented outside of the purview of governance protocols and process. To be clear, no a-priori knowledge of services, their location, or implementation is required in order for discovery to occur. And once discovered, consumers (upstream dependencies on the agented platform) and providers (downstream dependencies on the agented platform) are automatically mapped and tracked, even when there is no agent on the upstream or downstream hosts. Service provider discovery is, however, just one piece of the puzzle. Customer experience, which is too often overlooked in services and SOA management circles, shows that service-consumer governance is actually the more difficult problem.

6.0 SERVICE CONSUMER DISCOVERY

Put a service onto the network, and Actional provides the capability to track service usage by consumer (without any software required on the consumer side and without any configuration of the service itself). Since a picture is often worth a thousand words, let’s take a look at an Actional auto-discovered service flow map.


To understand Figure 3 note that:

1. Software was only installed on one machine: Partner Gateway (partnergw).

2. The developer of this application thought there might be a handful of consumers, but didn’t really have any idea. He had shared the WSDL with three or four other development teams.

3. No software at all was installed on the gray hosts, nor was any configuration done to the developer’s application (or to the WSDL used by the consumers).

4. If this developer were consuming other Web services, those service providers would show up just like the service consumers have done here.

5. If the Partner Gateway (partnergw) server shown in the above screenshot were actually an Actional control point (or a supported, hardwared XML firewall like IBM DataPower) installed in a DMZ as an XML security firewall, the visibility Actional delivers would enable customer-specific policy / governance / compliance.

Service-consumer governance is a big challenge because organizations have no way of knowing which consumers are using which services, and what SLAs they are receiving. In other words, organizations know whom they have allowed to use a service, but how do they know if unauthorized users are accessing a service? In the same way, how can they know if all critical business and security policies are being applied if they don’t know if the service or consumer even exists? The problem is the same with SLAs: there is no way to know how the service levels that customers are actually receiving compare to what they’ve been promised. Performing discovery with Actional solves these problems because it provides a way for IT to track and “bill” for those services in use.

Figure 3: Actional auto-discovered flow map of an application with 10 service consumers


In many situations, we’ve discovered development applications using production services (or vice versa). But Actional goes further, providing visibility into a wide range of service management issues:

1. If there are ten consumers of a service, how will the eleventh impact the other consumers?

2. How much service capacity is available for new consumers wishing to access my service?

3. A service response time averages one second (1s). Are my ten service consumers satisfied?

4. I’ve been developing a service, and it has moved to production. I want to move my development server to a new project. Is anyone still using it?

5. I’ve created a new service, but I’m not sure how useful it is. Who in the organization is using it and what are they using it for?

6. I’ve developed a simple service, and it’s being used so much that I have no more capacity. But I don’t have budget to add capacity. How do I track and bill infrastructure and additional development to those using the service in a consistent and fair manner?

Of course, this can be looked at from the consumer perspective as well:

1. I would like to use service X, but I’m not sure what response time it’s been delivering, and response time is critical to me. I know what the service provider says, but is that really the performance I’ll get?

2. I’m using a service from another part of the organization, which wants me to contribute to its budget. I know others are using the service for free, so why should I pay?

3. How well has service provider A delivered on the SLAs that it has promised others? Can I trust its planning abilities?

4. Group G has a less-than-desirable reliability history, and I know it is using service X. How will group G failures affect my performance?

7.0 REGISTRY INTEGRATION

A registry (or repository) is often used as the central index of service artifacts for architectural (design-time) governance. Actional has a fully documented SOAP API, with full security and tiered administration support for extensibility to any open registry product. Actional also supports deeper integration with other specific registries. The general architecture of registry integration follows.


8.0 FLOW MAPPING

There are many obvious artifacts to share with a registry: for example, owner, location, security, and policy requirements. Actional also uniquely shares service interrelationship (dependency) information based on its patented Flow Mapping™ technology. Dependency information is critical on a daily basis for performing root cause analysis, for capacity planning for upgrades, for versioning services, and for scheduling maintenance windows. Flow mapping can even be used to track business processes, and with support for asynchronous messaging, policies can be triggered when things happen (events) or when they fail to happen (non-events).

Developers

Registry

Governance

Browse existing services,deploy new services

and policies.

Share businessservice information

Auto-discoveryAuto-policy

Create & enforceruntime policies

Schemas, descriptions, WSDLs, policies, security,

performance, customer SLAs, metrics, reporting

Define, enforce, and audit design and runtime policies

Architects

Define descriptionsand policies,

guide services

Shared BusinessService Metadata

ActionalEnterprise

Service

RogueServiceClient

Figure 4. Integrating runtime governance with a registry and design-time governance


A flow map is essentially an application topology map that indicates where message traffic is flowing through the network. Service interrelationships are automatically discovered and never need to be configured manually. In addition, notice the gray systems in Figure 5. These never had any Actional software installed, yet Actional can manage one node away from any node with an agent installed. Finally, even traffic lines represent information. In the case above, they show the relative traffic volume. For example, we can see that the path between OrderMgmt and DataCenterGW to logistics is heavily used.

Flow mapping is important because of the way policies are applied. Policies take advantage of the flow mapping capabilities to know when there are downstream problems that relate to service-level commitments upstream. For example, the CSR portal, communicating to the enterprise service bus via the CustomerGW, may have a response time SLA of one second (1s). Although the CustomerGW is functioning fine, perhaps the Logistics system on the backend is not. Actional is aware of the dependency between the two and how the SLA relates to them and can generate an alert to help significantly reduce downtime and service-level violations.

Keep in mind that the SLAs are path- and process-dependent. Think of a service being used by two different consumers. In Figure 5 above, CSR Portal and Domestic Customer each use the Inventory Management service slightly differently. A CSR Portal user’s transaction goes through the CustomerGW, then Order Management, and then to Inventory Management. But a domestic customer’s transaction travels through the CustomerGW and then directly to the Inventory Management service. The average responsiveness of the Inventory Management service is not nearly as important as the

Figure 5: A typical service flow map


responsiveness for each type of user or the exact path traveled, which in this example is not the same. For this exact reason, the flow map and auto-discovery of the path and dependencies are all key for governance and policies based on user or transaction types.

9.0 ROGUE SERVICE ELIMINATION

A rogue service is a service put into the network without any governance visibility. A rogue service adds significant risk to the viability of the services infrastructure. For example:

1. A rogue service could expose sensitive data, thereby putting the company at risk from non-compliance with regulations and laws. Often, compliance with regulations such as HIPAA and Sarbanes-Oxley and privacy laws are explicitly runtime requirements.

2. Rogue services use capacity without any accountability.

3. Rogue services act under the radar of corporate compliance by circumventing the governance system and process.

4. Rogue services decrease motivation for complying with the governance policies because rogue services cannot be policed.

Actional can provide firms with the ability to automatically initiate policy without tying policy to a particular service, eliminating the motivation to evade compliance. Once in place, the policy can be applied broadly, to all services across the network—even those that have not yet been implemented. For example, say a rogue service is discovered. The security policy of “customer data must be encrypted” is immediately and automatically applied to the rogue service, thereby protecting the company and the customer. The power of this is that anyone deploying a service will automatically inherit a base-line governance framework to which it must comply. And compliance will not be an afterthought, but will be present from development, through user acceptance testing, into production.

Example: Developer Use Case

Runtime, of course, is different from simple production. Developers building a service are in a production situation even though they are in development because, from their perspective, their development activities are their product. Also, their development activities must be governed. The following case sets forth two situations at a financial company (an Actional customer) that illustrate these issues and really bring home the requirements for runtime governance:

1. A developer spent a whole day grepping log files for IP addresses to see if anyone was using the development server. Now that the development cycle was complete,


the development server was being rebuilt, and the developer knew people would complain when the server went away.

2. Another developer said, “I think there are about three or four applications using my service… I’ve given the WSDL to a few people, but I think they’ve shared it.” Sure enough, Actional discovered 10 different applications using this WSDL. (See Figure 3 above). They were all using a development server that was a “cubicle-level” project. By the way, this “innocent” application had employee Social Security numbers in a service that was now being used by 10 different processes. In other words, it was a security disaster waiting to happen.

Even in a development environment, it became critical to manage governance in runtime in order to plan capacity properly, measure ROI, and avoid integration catastrophes. Not surprisingly, the reason that Progress Software had been contacted by this customer in the first place was due to the fact that (in the words of the CIO) “integration had become too easy.” In other words, the service-based initiative was gaining so much momentum that enterprise-wide failures were inevitable if the organization didn’t get visibility into its service-integration layer.

10.0 SUMMARY

Runtime governance is a critical piece of the overall governance strategy of any organization, generating the process adherence, measurement, enforcement, and feedback. These are necessary for an effective lifecycle approach that enables seamless interoperability and service reuse and, ultimately, supports successful business transaction processing in future applications for business agility. We’ve discussed some critical examples of where this comes into play, as well as some key benefits that Actional brings to the solution.

In planning a proper deployment of a distributed, service-based initiative it is important to have runtime governance “baked-into” the development cycle early in order to avoid having the last line of defense become the only line of defense. Keep in mind, with rogue service elimination, runtime governance is not just a “nice-to-have” point solution for replacing a manual process. It is a mandatory requirement for proper security and compliance because it helps to eliminate risk associated with non-compliance and invisible interdependencies that can lead to catastrophic failures, missed business opportunities, and potentially devastating violations of government regulations.

Actional has recorded Webinars, presentations, and white papers on the complexities of service lifecycle management at http://www.progress.com/actional. These are recommended reading for companies exploring the full capabilities of runtime governance.

Worldwide HeadquartersProgress Software Corporation, 14 Oak Park, Bedford, MA 01730 USA Tel: +1 781 280-4000 Fax: +1 781 280-4095 www.progress.com

For regional international office locations and contact information, please refer to www.progress.com/worldwide

©2009 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved. Progress and Actional are trademarks or registered trademarks of Progress Software Corporation or one of its affiliates or subsidiaries in the U.S. and other countries. Any other trademarks or service marks contained herein are the property of their respective owners.0000114773

prod. code 8063

Why Runtime Governance is Critical for Service-based Applications

Documents

Transcript of Why Runtime Governance is Critical for Service-based Applications