Why add yet another moving part into the service-oriented landscape? Isn't management of service-oriented applications already too complicated? The reasons for introducing an enterprise service bus are the same as those applied when choosing to implement an enterprise application integration strategy some years ago.
In the early stages of an SOA implementation, when the inventory consists of nothing more than a handful or two of project-based services, an ESB seems to be overkill. With any luck, however, the service deployments will accelerate as adoption within the enterprise progresses. A strategy is required to provide on-demand scalability, reliability and adequate performance characteristics. From an architectural perspective it is also a good idea to have an organizing principle to avoid service chaos.
As an enterprise SOA matures, business functionality will be mined and exposed from a variety of sources. These service providers may be legacy applications, third party packages or capabilities offered as hosted solutions. While the ideal would be to have all services using the same technology, the real world has proven that this is unrealistic. Web services standards will most likely be just one of many approaches used.
Advanced SOA functionality, such as service orchestration, automated business processes, event-driven architecture and complex event processing, is dependent on sound enterprise application integration architecture.
With these considerations in mind, the justification for the implementation of a full-featured integration broker with ESB capabilities becomes clear.
Reliability and Availability
Visibility to all the moving parts in distributed software has been a major challenge since the advent of n-tier applications. With the complete separation of concerns in service-oriented development of applications, a prospective consumer of a service must be able to find it and know what to expec...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
t for availability, quality of service and performance characteristics. The ESB works with the service registry as well as helping with the compliance with SLAs -service level agreements. In order to monitor the health of a service, dependencies on other services, as well as the state of the execution platform must be known. When problems are detected, alerts must be raised and notifications sent. Many integration broker vendors provide either built-in monitoring capabilities or, more commonly, hooks to monitoring tools for more complete visibility. Common services for audit trail, logging and exception handling can be hosted by the tool.
Scalability
The bus-based infrastructure provides an abstraction from the actual deployment topology of the services. Capacity can be added to the Web server, application server, third party package, legacy app and database instances that are doing the actual work promised by the service descriptions without impact to the service consumers. In fact, work can be delegated to federated buses, so the ESB itself can be deployed in a manner to make the best use of hardware and network resources.
Security
An implemented service should not bear the burden of managing which consumers and under what conditions they have access. Those rules are likely to change over time. This cross-cutting functionality is externalized from the service in the ESB.
Extensibility and Agility
As business is constantly adapting to changing times and new opportunities, the business processes will be evolving as well. Planning for flexibility is critical for a successful SOA implementation. Transformations should be done as close to the integration endpoints as possible to and from a canonical (common) business information model. This approach will facilitate agile automation of processes, orchestration of composite services and externalizing of process-specific business rules from the business functionality of the service.
In conclusion, a full-featured integration broker will provide core ESB capability as well as all other functionality required in a heterogeneous service topology. This class of technology provides a "simplifying" façade to a great deal of complexity that would otherwise have to be implemented in every application or service.
About the Author
Maja Tibbling is a Lead Enterprise Architect at Con-way Inc., with more than 20 years of IT experience spanning multiple technologies and methodologies. She has had a primary focus on component-based, service-oriented and event-driven architectures for the last 10+ years. She has shared Con-way's SOA success story through trade publications and Gartner, Open Group, SOA Exec Forum and vendor conferences. Con-way IT has received industry recognition for the business value provided by its SOA implementation, through CIO 100 awards for 2002 – 2006 and several InfoWorld 100 awards amongst others.
