What You Don't Know Can Hurt You

Most organizations now understand that SOA is an ideal means of bringing agility to enterprise business systems. However, with its many benefits SOA also brings new challenges. One of the most pressing issues is making sure that decentralized teams cooperate effectively. How do you coordinate efforts across departments, locations, time zones and priorities? How do you maximize re-use and ensure system-wide compliance with governance policies?

Dynamic discovery has proven to be a crucial capability in solving these issues across the entire SOA lifecycle—from development and QA through production use of the application. A runtime governance system with dynamic discovery mechanisms can find all the services installed in the deployment environment and the dependencies among those services, based on actual use. Dynamic discovery will also uncover "rogue services"—services that are not recorded in a registry/repository. After all, you need to know about a service if you are to reuse it.

Registries and design-time repositories alone do not solve the problem. Even with the best of intentions and the most strongly mandated use, they often end up out of sync with the "real world." There are three reasons why:

1) Human Nature. Developers often don't see the benefit to themselves from keeping the system up to date, so aren't incented to do so.

2) Rogue Services. These come from two sources—accidental and intentional circumvention. Accidental circumventions occur during the heat of the moment during system installs and, even more often, during urgent system repairs and restarts. These last-minute changes to the SOA environment fail to get reflected in the registry or repository. Intentional circumventions are potentially more malicious. It's when people choose to ignore the approval process when deploying or using services.

3) Rogue Users. This is when the intended use of service fails to be recorded anywhere in the system. Most of these problems occur on internal systems behind the firewall, where existence of a useful service may have been communicated between colleagues. These "water cooler dependencies" are coded into applications. Later, when you want to change or remove a service, you can't make an informed decision because you don't know who'd be impacted by the change.

Okay, so those are the issues, but what can you do about them? First and foremost, automate the system. If your runtime governance software dynamically discovers services and users across the system (again, across development, QA and production lifecycles) and automatically adds this information to registries and design-time repositories, you've taken human nature out of the equation. Rogue services and rogue users go away as well, since everything is recorded as it should be.

Highly accurate and timely topology information is critical to the proper operation of the system. Without such information, root cause analysis and impact analysis are quite difficult when faults or performance problems are encountered. This information is particularly critical in SOA systems whose topologies tend to change

What's more, SOA is unique in that the service network may change dynamically after systems are deployed. A service that is not managed by the application system owner may be changed unilaterally or a service may have to be updated or replaced. The runtime governance system can assist in the management of such changes by dynamically re-routing messages to control the risk associated with new or revised services being added to the environment.

For example, if a service is replaced by a new version, the runtime governance system can be used to slowly migrate the user community from the old version to the new version. In addition, the new version of the service may depend on different services than the old version. This is quickly identified by the runtime governance system's discovery mechanisms, allowing the operations staff to quickly understand the new dependencies and establish the expected service levels for the new components of the system. By quickly establishing such constraints the operations team is in a better position to respond pro-actively to potential problems.

We've seen many of our customers experience dramatic improvements as a result of dynamic discovery. One such customer increased the number of registered services from a mere handful to more than 100 in the first couple of months of using AmberPoint. The benefits? Greater reuse, better cooperation across departments, greater business agility and higher ROI. Isn't that what SOA is all about?

Want to learn more? We're hosting a webcast featuring Anne Thomas Manes, Group Vice President and Research Director at Burton Group, to discuss this subject next week. Thursday February 15 at 9 AM Pacific, Noon Eastern. For more information: www.ebizq.net/to/innersoaamberfebc

Caring for SOA Clients

By Andrew Brown, Senior Product Manager, Security

Sometimes lost in the shuffle of implementing and securing an SOA is the humble client application. While it may not be as glamorous as provider applications that expose corporate data as a service, the client is fully half of the SOA puzzle. After all, without clients (or in Web services jargon, 'service consumers'), who is going to make use of the awe-inspiring services you have composed and exposed? If your SOA is successful, you'll find that you have clients clamoring to access your services. Those service consumers may be running in other departments within your enterprise, or on-premise at a remote location, such as at a customer's or business partner's company. Once you've established the importance of client applications to your SOA, you can focus on giving them the care they need and deserve.

Getting these clients online can be a challenge, particularly if they need to perform security processing to pass muster with your security gateway. We call this "first-mile security" because it's all about ramping your clients onto the service network in a secure way. These clients can be beyond your direct control, so you might not be in a position to issue a mandate to implement security features. You still need to secure communication between the client and the service network, however, so what should you do?

First, it's critical to follow the tried-and-true SOA practice of offloading the security implementation from the application. You need to prevent your clients from having to write and maintain the code to perform security processing. Now the work falls to you to create a client-side package (cross-platform if possible!) for your clients to download and deploy along with their applications—ideally with no integration coding required.

Once you have accomplished this task, there remains a problem that's thornier still. Because your endpoints and service-side policies will inevitably change as time goes by and your SOA evolves, how do these clients find out about service changes? How will they change their behavior to stay in synch with your evolving service policies? How do you modify your policies to react to threats and capitalize on opportunities, without worrying that a change might interrupt service to your colleagues, valued business partners and customers?

When in doubt, turn to standards. Is there a standard out there that enables services to communicate security requirements to clients? Thankfully, there are two: WS-MetadataExchange and WS-Policy. While the names may make the standards seem arcane, they're actually quite simple. WS-Policy provides a way for the service to describe its security requirements (among other things). WS-MetadataExchange wraps that policy in a neat package of information that's helpful in accessing a services, such as URLs, WSDL files, and so on. In other words, your clients simply consume a WS-MetadataExchange document, and voila!—a security-enabled client.

But perhaps it's better to leave all this work to AmberPoint and, in the process, roll client-side support into your overall runtime governance solution. AmberPoint approaches this problem in a particularly innovative way. When the AmberPoint SOA Management System generates a policy for your service, it also generates the corresponding policy for the client. Like two sides of a coin, we generate two policies that fit together—the policy to be enforced by the service and the policy to be executed by the client. We then provide a client-side agent capable not only of consuming these client policies, but also of executing the orders they contain. So not only can the client offload the gnarly coding and maintenance involved with implementing security, but it also gets dynamic policy updates for free.

With SOA, it's all about agility. But you can't be agile when you're worried about breaking your service contracts with clients that rely on your services. Perhaps it's best to simply forget about securing the client, since it's too much trouble? Problem is, that's not showing much care for clients that, from a business perspective, need the reassurance of security as much, if not more, than your backend service provider applications. With AmberPoint's first-mile security, you can constantly optimize your security policies to reflect business reality, without the deluge of support phone calls that accompany traditional service updates. And that's something you and your clients will appreciate as your SOA delivers more services to more clients in more places.

Our CTO on SOA

The third in a five-part series from AmberPoint CTO Paul Butterworth

Performance management is an important discipline in the governance of a SOA-based system, as it is for any system. Of course, an early task that must be completed is an analysis of the performance of the as-built services. I have been involved in a several benchmarks recently and it has reminded me of several basic tenets of benchmarking that we all need to keep in mind:

• Accurate results can only be obtained if the benchmark is run in a controlled environment
• The test environment must be well understood before the results can be properly interpreted
• All resources consumed during the benchmark must be accounted for
• Test results must be repeatable

There isn't any great insight to these four items; they're just common sense. Nevertheless, let's look at them in a little more detail.

A controlled environment is essential. If you have to consider the impact of other applications on the machines on which the benchmark is running or the impact of other applications on the network, you're pretty much doomed to produce results you cannot understand. The best bet is to benchmark on an isolated set of machines and network segments that are dedicated to the benchmark. At a minimum this allows us to assume that resources used during the benchmark were used either by the system being tested or the systems being used to drive the test.

A corollary to the need for a controlled environment is the need to completely understand the test environment in which the test is executed. As a simple example, it is essential to know what load is being placed on the system under test and how that load is produced. It is easy to say the test driver will send 100 messages/second to a specific service. However, we need to know the intended distribution of the messages (uniform, normal, random, etc.), the actual distribution the driver produces and how the test driver reacts under heavy load—both in the case where the load is placed on the driver and the case in which the heavy load is placed on the system being tested.

Once the test is run and the results are being reviewed it is essential to account for all resource usage. If we have used 100% of the available CPU time on a machine but more detailed statistics account for only 40% of that time, we have to assume we don't truly understand the system or the results of the test. In such cases we need to take a deeper look at the operation of the system and perhaps record additional resource usage statistics until we have confidence we know where the resources are being used. Many times we see the opposite; we think the system is fully loaded yet we find only a small percentage of the available resources are being used. This case also requires further investigation.

Finally, the test must be repeatable. If the test is run three times in a controlled, well understood environment and the three sets of results do not reflect a similar result, then we don't really have a controlled, well understood environment after all. Time to go back and make sure the environment is dedicated, the test drivers are well understood and all resource usage is accounted for.

Introducing Agentless Policy Enforcement

SOA systems are like snowflakes; no two are the same. Some are internal-running applications, while others consume services from the other side of the corporate firewall. Some are .NET only, others are Java, though most are heterogeneous. That's why we offer a flexible variety of deployment options.

AmberPoint runtime governance agents can be deployed on the same service container as the service or can run as a proxy. Our ultra-lightweight Nano Agents process messages out of band, reducing latency to nearly zero. And recently AmberPoint introduced the industry's first agentless system for SOA runtime governance. With this ground-breaking new architecture, we've decoupled the enforcement of SOA runtime governance policies from the execution of those policies. AmberPoint can now delegate policy execution to existing SOA infrastructure, enabling organizations to better leverage the intrinsic and increasingly sophisticated capabilities of XML appliances, enterprise service buses (ESBs), application servers, operating systems and other SOA infrastructure.

Our new architecture now offers agentless policy enforcement options in addition to existing agent-based mechanisms. AmberPoint SOA Management System delegates runtime policy execution to the SOA infrastructure whenever policy-capable infrastructure is in place, leveraging as much of the native policy execution capabilities of the runtime infrastructure as possible. As a result, enterprises realize greater returns on their investments in SOA platforms and runtime frameworks, while fully utilizing their SOA infrastructure.

With this fundamental enhancement to our architecture in place, we are able to release expanded functionality and support for many additional application servers, appliances, ESBs, and other SOA infrastructure in the months ahead.

• Capability-based Delegation of Runtime Policies: Not all infrastructure and platforms are created equal—their runtime execution capabilities and policy support vary. AmberPoint is flexible enough to easily adapt to the different types of capabilities across varying components.
• Fire-and-Forget Policy Rollout: AmberPoint guarantees the delivery of each policy in an automated fashion by tracking the runtime infrastructure and facilitating management of the SOA system as a whole.
• Transparent Support across Platforms: Recognizing that standards for SOA management are evolving, AmberPoint transparently maps runtime policies onto both platform-specific and standards-based interfaces and protocols.

So what does that mean to you, the customer? Let's look at the advantages of going agentless:

• Greater ROI from SOA Infrastructure: Ensures your runtime governance policies are executed as efficiently as possible by leveraging built-in platform capabilities when it's best to do so.
• Streamlined Administration of Runtime Policies: Instead of administering each policy individually, you can now govern the running SOA environment in an end-to-end fashion.
• Visibility of All Policies System-wide: We give you a single, comprehensive view of all SOA runtime policies across the environment. That means you can see what policies exist, where policies are being executed, which services are using them, the policy status, etc.
• Uninterrupted Runtime Governance: You can seamlessly enforce runtime governance policies regardless of the hardware and software you've chosen. And you can add any infrastructure you like to the system without concern it will disrupt your runtime governance system.

2006 in Review

Much has taken place since the last edition of The Amber Point. 2006 was truly a banner year for us. It was another record-setting year of growth, as we saw a significant increase in the number of new customers as well as the number of deployments of our software. We also closed market-impacting agreements with several leading software companies, including SAP and TIBCO. In the past year, we introduced groundbreaking new capabilities for our SOA runtime governance software and received a number of industry honors for our work with customers.

Growing Roster of Marquee Customers
AmberPoint's market traction continued to grow in 2006 with the addition of new customers across a variety of industries and geographies—most notably insurance, healthcare, financial services, government and telecommunications.

"We put our stamp on 2006, a year in which we saw this market coming into its own," said AmberPoint CEO John Hubinger. "More and more companies are now approaching their IT goals with an SOA mindset and understanding that they need runtime governance early on in order to achieve those goals. Due in large part to our close work with industry and platform partners, we've been able to close the majority of new business opportunities in the runtime governance space. Time and again, we've beaten the competition for revenue opportunities. Our 2006 was a record year in licensing revenue, market traction and industry recognition."

New Partnerships and Global Distribution
AmberPoint continued to work closely with the industry's premier technology companies in 2006, strengthening our partnerships with leading SOA platform vendors, technology providers, systems integrators and resellers.

• A cooperative development agreement with SAP resulted in integration between our leading SOA management solutions and the SAP NetWeaver platform
• A licensing agreement with TIBCO brought AmberPoint's policy-based governance to TIBCO ActiveMatrix
• We expanded our support for BEA AquaLogic and Weblogic
• We grew our partnership with Microsoft, enhancing our integrations with Microsoft Operations Manager (MOM) and Microsoft BizTalk Server and reaping the benefits of global distribution of our software with Microsoft Visual Studio 2005
• We continuted to work closely with IBM and IBM Global Services, with whom we share many customers
• We integrated our solutions with Systinet, IONA, Software AG, iWay, F5 and Reactivity

We also increased our global reach through distribution partnerships around the globe. Furthermore, we appointed Willie Kirkpatrick as our Vice President of EMEA to expand our executive presence in Europe. AmberPoint software is now available in eight languages and used in sixty-six countries spanning six continents.

Product Leadership
In October, we introduced the first agentless SOA runtime governance solution, a game-changing product for the industry. With this capability we've decoupled the enforcement of SOA runtime governance policies from the execution of those policies, allowing policy execution to be delegated to existing SOA infrastructure such as XML appliances, enterprise service buses, application servers and operating systems. (See "Introducing Agentless Policy Enforcement," above)

In August, we enhanced the breadth and depth of management capabilities in our SOA Management System, including two industry firsts: The Service Scorecard and "first-mile" visibility and policy enforcement. Service Scorecards display vital data that allow developers to choose services based on their behavior and help architects to understand service characteristics relative to system performance. "First-mile" visibility and policy enforcement allow the system to automatically enforce policies on the client side and automatically adapt to system changes.

Customer Deployments
As a result of our growing customer base, we deployed our software at a record number of customer sites in 2006, an indication of increasing corporate reliance on SOA-based information systems. In 2006, AmberPoint's Customer Experience Group assisted in more customer deployments using AmberPoint's runtime governance software than the previous three years combined.

Industry Accolades
The industry accolades we received in 2006 included:

• IT Week Top 100 vendor
• InfoWorld 100 Award for the second year in a row (this time honoring Motorola's use of AmberPoint)
• Network World Enterprise All-Star Award for the second year in a row (this time honoring MedicAlert's use of AmberPoint)
• Technology Manager's Forum Best Practice Award (honoring Motorola and AmberPoint and highlighting the use of AmberPoint as a best practice for the industry).

But enough about the past. We're now well on our way to making 2007 an even better year for our company, our customers and our industry partners.

Coming soon to an event near you

AmberPoint is a very active participant at conferences and seminars. Here are some of the places you'll see us in the months ahead:

BEA "SOA Focus" Seminar Series
February 6-15, 2007
Various locations
For more information, click here.

Web Services/SOA on Wall Street
February 14, 2007
Roosevelt Hotel
New York, NY
For more information, click here.

Webcast: "Discover Your Inner SOA"
February 15, 2007
Featuring Anne Thomas Manes, VP and Research Director, Burton Group
For more information, click here.

AFEI / US STRATCOM
February 21-22, 2007
Hilton Alexandria
Alexandria, VA
For more information, click here.

Realizing SOA Benefits in Your Organization
Pragmatic round-table discussion led by Tom Dwyer, Yankee Group
February 27, 2007
Microsoft Corporation
New York, NY
For more information, click here.

SD West
March 19-23, 2007
Santa Clara Convention Center
Santa Clara, CA
For more information, click here.

SAP Sapphire
April 22-25, 2007
Georgia World Congress Center
Atlanta, GA
For more information, click here.