Delivering an Effective Runtime SOA Blueprint
Success at SOA can hinge on a comprehensive and accurate service catalog. Yet sometimes it’s simply too much work to update the system of record--be it a UDDI registry or a CMDB. If that’s the case, the Service Catalog becomes about as much use as half a phonebook.
Bootstrapping Governance through Service Network Discovery
The key challenge is that service-orientation initiatives rarely begin with a clean slate. Instead, a whole range of capabilities and application components already exist. Some groups or projects may be ahead others in the race to loose-coupling. Some legacy applications and capabilities may never change. Packaged applications, such as ERP and CRM solutions, may expose services. The initial challenge doesn’t lie in designing and modeling business services. Instead, it’s a matter of discovering and getting a handle on what is already deployed in the runtime environment—and then collating that information in a useful catalog. Existing components may or may not be service-enabled, and may include Java Messaging Service (JMS) implementations, Enterprise Java Beans, Plain-old Java Objects (POJOs), and ASP.NET applications. By creating an inventory of available capabilities, architects gain greater visibility into what’s available and where gaps may exist. The inventory leads to more effective design, reuse, service composition, and ultimately to more streamlined development and more manageable service networks.
But it’s not enough just to find the applications running in your network. You also need to know how they communicate or, in other words, how the applications are "wired together." Often times, application dependencies in the runtime environment are quite different from the diagrams on the architect’s desk. To gain an understanding of the service network as it truly exists, it’s critical to gain a comprehensive view of the applications as they are actually integrated in the runtime environment.
AmberPoint automatically discovers the application components deployed within an SOA environment, along with the dependencies among those components. It displays these dependencies while providing a view of the service network and its live relationships to help manage the complex dependencies inherent to loosely coupled business systems.
The resulting runtime SOA blueprint enables architects and managers to ensure that only approved application components are deployed within their environments. It also helps them, on an ongoing basis, to identify and weed-out "unapproved" or "rogue services" and submit them to a governance process, while providing the bird’s eye view necessary to develop a strategy for securing and optimizing performance, availability and Quality of Service.
AmberPoint provides a 360-degree view of services by augmenting the registry with information about services that are actively deployed in the runtime. It does away with manual drudgery while ensuring that the registry is up-to-date, accurate and useful.
Leveraging Diverse Data Sources for Rich Service Profiles
The runtime environment is not the only source of information that’s useful for building a service catalog. Just as there are many services that have been deployed, there is also a set of repositories of information designed to describe and help manage the components deployed in support of the service-orientation initiative.
The challenge for service-orientation is to leverage these existing sources of metadata, like CMDBs, and combine them with SOA technologies such as UDDI to build rich, metadata-driven service profiles.
By merging runtime discovery and mapping with metadata, AmberPoint provides ongoing updates to your chosen registry, providing a wealth of information that enables you to centrally manage a complex, distributed service network.
Maintaining Service Catalogs to Promote Reuse
Reuse and service composition can be optimized only when architects and developers know what services are available. But since most environments have evolved over time, the relationships in the runtime environment may differ from what was originally planned in the design phase of a project. Services and transactions may not necessarily reflect the design documents on hand. Redundant applications must be weeded out, monolithic applications decomposed into logical units of work, and requirements defined for new applications that will fill in the gaps.
