Runtime Governance of SOA Applications

To facilitate the alignment of IT with business, many organizations are adopting service-oriented approaches to application development and deployment. Service-orientation provides many benefits, but it also creates new challenges across the service lifecycle.

These challenges arise for a number of reasons:

Heterogeneous Composite Applications: SOA initiatives rarely start from a clean slate. Instead, they usually begin with a process of analysis and triage on the applications already deployed, including applications built in-house, acquired as packaged applications, Software as a Service (SaaS) applications, and legacy applications that have supported the organization for decades.

Complex Interrelationships: Architects and developers across various groups may not have a clear understanding of what’s out there, or how those application components are connected. They may be unaware of the runtime relationships between these applications. Unapproved services (so-called "rogue services") may be deployed in the runtime environment. Over time, applications may also be integrated in ways that do not reflect their design, making it difficult to effectively plan for reuse.

Performance Issues: Even in environments with only a few distributed applications and services, it can be difficult to obtain a clear view of performance bottlenecks or to discover the source of faults and errors. The more complex the system, the more difficult it is to proactively address these performance issues.

Service Level Agreements: Service consumers and end-users of services often require contractual commitments to performance and availability—Service Level Agreements (SLAs). This is especially the case when performance degradation or failure might result in financial losses. Service level management is crucial to any organization planning to make production use of enterprise SOA—no matter how far along the adoption path they are.

Security Concerns: SOA applications are sometimes exposed over the open Internet. Unintended reuse can lead to a service being used in ways that the application’s security model did not account for. That’s why all services must be security-aware. However, building security capabilities directly within an application goes against the grain of SOA. The challenge, then, is to offload security from application development, while at the same time providing security at every endpoint in the network.

Abstracting the Management Layer: To date, management and security have either been codified in the logic of the application or service itself or defined within configuration files. However, with SOA, implementing such behavior in code raises issues:

• Consistent implementation is a concern, while the overhead of re-coding applications to modify generic behavior introduces unnecessary overhead and risk. For example, it might be difficult to implement consistent logging behavior—often required by corporate policy or industry regulations—between applications deployed on .NET and J2EE platforms.
• Implementing governance in application code prevents an organization from adapting quickly as corporate policy changes in response to emerging regulations, security threats, or business opportunities. These management requirements should be centrally managed and offloaded from application developers, who need to focus on implementing and optimizing business logic.

Constant Change: In service networks, it is rarely feasible to deploy new versions of all the services at once. More likely, various components of composite applications will be upgraded at different points in the service development lifecycle. Similarly, any given service interface is likely to be enhanced or require changes. In many cases, modifying these interfaces creates incompatibilities with existing service consumers. This means that every time a service interface changes, the service consumer needs to be recompiled, tested, QA’d and deployed in order to deal with changes in the interface. For the provider of the service there is also a growing problem: Multiple versions of an interface and the supporting implementations now have to be supported. The increasing number of services will therefore be further complicated by the number of service interfaces that must be maintained simultaneously.

In light of these challenges, organizations expecting their service-orientation initiatives to deliver the benefits they’ve been promised require solutions designed specifically to manage and secure these evolving, heterogeneous composite applications. AmberPoint is at the vanguard of meeting these challenges, having pioneered the industry-leading capabilities described in the following sections.