Technology moves from theory to productivity driver, says Gordon Van Huizen
The service oriented architecture (SOA) represents a summation of technologies that have been refined over the past two decades. The core principle of a uniform means of connecting systems is simple in theory, but has been difficult to achieve in practice. It has taken the software industry several attempts to arrive at an architectural model that is up to the task.
Last year SOAs made the leap from being merely an interesting technology to becoming the cornerstone of leading-edge corporate IT strategies. For example, BAA chose the Sonic ESB (enterprise service bus) to underpin the implementation of a service oriented architecture at Heathrow's Terminal 5 to provide reliable and seamless integration of time-critical events and processes across operational systems.
So why are IT managers with responsibility for mission-critical applications such as supply chains, manufacturing, financial trading and airport operations driving their teams toward an SOA-based future? Because SOA offer the opportunity to achieve broad-scale interoperability and provide the flexibility required to continually adapt technology to business requirements.
One reason for this rapid transition is the availability of commercial, off-the-shelf SOA infrastructure software.
As IT managers develop their SOA plans they often come to the conclusion that infrastructure software is needed to fulfill their objectives for flexibility, robustness and control. The ESB has emerged as the pre-eminent form of SOA infrastructure software.
As little as one year ago, the notion of ESB was hotly debated by industry analysts. An ESB provides a standards-based integration platform that combines messaging, web services, data transformation, and intelligent routing in an event-driven SOA.
ESBs also ensure that SOAs deliver on four key requirements: flexibility, heterogeneity, distributed deployment and management. Now, the major analysts, including Gartner and Forrester, agree that an ESB represents the core of an enterprise SOA implementation by connecting, mediating and controlling services. SOA practitioners have also found that a commercial ESB shortens project development time and provides post-deployment flexibility with operational robustness and control.
It is not necessary to rehost applications to enable them to interact through an ESB. In many cases this would be impractical as the applications are configured and deployed within their own managed environments, such as application servers.
In addition to J2EE and .net applications, ESBs routinely connect packaged applications and data sources, such as relational databases. Mediation services perform generalised functions between connected applications, such as transformation, content-based routing, process orchestration and logging. These services are typically hosted within the ESB itself and are included with commercial ESB products. They may also be obtained from third parties or developed in-house.
The ESB represents each service using a common interface model, regardless of whether a service is hosted "inside" or "outside" the bus, or the nature of the resource that the service is based on. The interaction model - how a service is invoked - is said to be event-driven. Each service is invoked through messages (typically in XML or wrapped with XML metadata), and in turn emits messages to be consumed by other services.
This "loosely coupled" form of interaction provides a great deal of flexibility since services do not need to know details about any "callers", which can range from other applications to ESB orchestration functions or even process management engines.
Within an ESB, services are deployed into a managed environment that can be distributed across a local or wide area network. Configuration is performed through meta data that is maintained in a central repository and "pushed" out to running service instances. This permits the dynamic configuration of individual services or sets of services - and their deployment across multiple datacentres, business units or even multiple retail locations - without disrupting ongoing operations.
Users can also alter the business processes that span applications without recoding or redeploying the applications themselves. Since each service simply responds to incoming messages as events, you can change the flow between services by reconfiguring the message flow or changing routing rules; the services themselves do not need to change.
Some ESB implementations allow the deployment of multiple instances of a service on multiple servers without deploying a full integration broker or application server for load balancing and high availability. Because of the added benefits of ESB hosting you may choose to host specific functions from new or existing business applications as services to be deployed within the ESB itself.
The heterogeneous, distributed nature of enterprise SOAs creates some monitoring challenges. 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 operational metrics such as data inflow and outflow rates, and can monitor flows and processes across any set of services.
The need for reliable communication is inherent in the challenge of connecting mission-critical applications across the enterprise. ESBs employ messaging technology, building on queuing and publish/subscribe mechanisms to route messages between services reliably and securely.
Because of the event-driven model of the ESB, applications attached to the bus do not need to be aware of, or coded to, specific messaging mechanisms as is the case with typical message oriented middleware.
Messaging functionality, such as reliability, security, and routing, is implemented within the ESB itself and configured through metadata. Beyond basic messaging patterns, intelligent routing and process management can be used to co-ordinate service interactions. You are free to mix and match these techniques at will because the services simply consume and emit messages without knowing how they are routed.
Gordon Van Huizen is chief technical officer at Sonic Software
Benefits of SOAs
- Flexibility: ability to change processes, rules, data mapping and relationships between applications with minimal effort and disruption
- Heterogeneity: ability to span new service-enabled applications as well as existing ones, providing a consistent service model
- Scalability: ability to provide the performance expected of enterprise systems and easily accommodate changes in demand
- Resilience: ability to isolate applications from faults caused by server and communication failures
- Distributed deployment: services will be spread across and between organisations
- Visibility and control: the infrastructure must be able to manage and monitor itself, as well as the services deployed within it.