Last month we began our discussion of the architectural elements of an enterprise service bus (ESB), and how they contribute to building a robust, flexible enterprise service-oriented architecture (SOA). We examined the nature of loose-coupling-the art of minimizing dependencies to maximize flexibility-and how choices for service interface models and the way in which services are brought together drive the degree of flexibility available in an SOA.
This month we will explore service configuration, deployment and monitoring within and across an ESB. To begin, let's discuss the two primary classes of services found in an enterprise SOA: application services and infrastructure services.
Application services represent the business logic made available via each application that participates in the SOA. These services have a number of origins including:
New applications built in J2EE and .NET that provide service interfaces;
New versions of packaged applications that offer service interfaces; or
Custom or commercial adapters that bridge existing business logic to an SOA environment.
It isn't necessary to re-host applications to enable them to participate in the enterprise SOA. In many cases this would be impractical, as the applications are configured and deployed within their own managed environments, such as J2EE application servers (you may have specialized cases in which you would choose to re-host subsets of applications as managed services within the ESB environment, as we will see in a moment). Regardless of whether a service lives "inside" or "outside" the bus, the ESB will treat it as a logical endpoint with a common interface model.
Infrastructure services perform generalized integration and orchestration functions between the connected applications, such as transformation, content-based routing, and logging. Infrastructure services are included with ESBs, but can also be obtained from third parties (such as other vendors and systems integrators), and are also often developed in-house. In addition to service interface descriptions, infrastructure services typically require additional configuration artifacts, such as transformation maps and routing rules.
Within an ESB, infrastructure services benefit from being deployed into a dynamic, managed environment that provides remote configuration and monitoring of services across a distributed network, and can support "hot" configuration and redeployment. This allows you to dynamically configure individual services or sets of services and deploy them across multiple data centers, business units or even multiple retail locations-without disrupting ongoing operations. This means that you can alter the business processes that span SOA applications without re-coding or re-deploying the applications themselves, reinforcing the value of loose coupling. Some ESB implementations, such as Sonic ESB, allow you to easily deploy multiple instances of a configured service on multiple machines-without replicating a full integration broker stack- for load balancing and fault tolerance. Because of these added benefits (single-point management, dynamic re-configuration, load balancing, fault tolerance, etc.) you may choose to host specific functions from new or existing business applications as services to be deployed within the ESB environment itself. For example, a Monte Carlo simulation engine could be deployed as a managed service to achieve scalability.
Enterprise SOAs create interesting monitoring challenges due to their heterogeneous, distributed nature. An ESB provides the infrastructure required for monitoring service usage and service interactions as well as a solid foundation for SOA fault handling and problem analysis. ESBs provide monitoring capabilities for each service deployed across them, whether a given service is deployed as a managed service within the ESB environment or not. They support the collection of metrics such as data inflow and outflow rates, number of queued events, etc., and can monitor flows and processes across any set of services. This data can then be distributed and collected through the ESB infrastructure itself, using messaging techniques such as publish-and-subscribe. ESB consoles allow administrators to establish alerts based on conditions such as metric thresholds. Using event capture and logging across the SOA, architects can accumulate monitoring data and perform correlation analysis, potentially associating abnormal service conditions with business cause or impact.
In the third and final installment of this series, we will discuss a unified architecture for ESBs and why such an architectural model is required to meet the objectives behind an enterprise SOA.