This month column is contributed by Gordon Van Huizen, chief technology officer for Sonic Software Corporation, the leader in distributed, standards- based integration. Van Huizen has more than 22 years of experience leading product management and software development teams and was a driving force in bringing the industry's first enterprise service bus (ESB) to market.
Until recently, the presence of integration technology was a statistical rarity within the IT landscape of most companies. Despite the numerous motivators for integration - increased operational efficiency, better collaboration with value chain partners, and consolidation following mergers, to name but a few - the startling fact is that there hasn't been much integration technology deployed. Studies indicate that less than 15 percent of integration projects actually employ integration middleware. And that's of the integration projects that get done at all. But we are entering an era in enterprise computing where integration technology will seemingly be everywhere. The technology shift behind this trend is service-oriented architecture (SOA). SOA is changing the way we think about applications and how they relate to each other and, in doing so, is fundamentally changing the nature of enterprise application integration (EAI).
The first order of business when integrating applications is to make them interoperable. What this generally means is mapping each application's functionality and internal data model to some normalized format. Historically the normalized format used was implicit to the integration broker that an organization purchased, meaning that any interactions with the application would be limited to the capabilities of the broker, greatly restricting the reusability of the interface. With SOAs, it's now possible to express application functionality and data in a more generalized, standards-based way, such as a Web service. Instead of plugging directly into a proprietary integration broker, the application is ready to be invoked by any software that understands its service interface. The SOA approach provides significantly greater reuse and flexibility, as we shall see. There is a growing trend to develop what are called "event-driven" architectures within SOA, where each application responds to incoming asynchronous messages that represent business data and business events. This represents a much looser form of coupling than the usual client/server model, promoting significantly more independence since the primary contract between any set of applications is the message format they share. Each application parses incoming messages and acts upon their contents. Its business logic is typically isolated from the overall event flow between applications, which can be changed at will. It has already become quite easy to create service interfaces for applications built in J2EE and .NET, and new versions of packaged applications are emerging that offer service interfaces. You can also "wrap" existing applications to service enable them using a variety of Web service integration products.
The role of EAI dramatically changes in a world of loosely coupled, collaborating applications. Instead of hosting proprietary transformation maps, business rules and process models, integration middleware's role is to connect a broad range of applications and let the organization decide how they should be logically coupled to automate key business functions. A new form of integration middleware has emerged to support the event-driven SOA integration model: the enterprise service bus (ESB). An ESB provides the logical network that spans applications and hosts integration capabilities, offering a durable, flexible infrastructure through which applications interact, and business processes can be automated and managed.
In an ESB, each application's service interface and logical address are referenced in a global directory. ESBs use enterprise-grade messaging technology to facilitate data movement between services and provide location transparency. But unlike "straight" messaging applications, where messaging behavior is "baked" into the application code, a number of interaction models can be configured between applications on the ESB, including:
- Logical point-to-point connectivity;
- Publishing data across the bus; or
- Intelligent routing based upon rules and message data.
In addition, process engines can be plugged into the ESB to orchestrate and monitor the interaction of services by firing events to the target applications. Unlike traditional integration broker architectures, service-oriented process engines can leverage an entire network of loosely coupled applications, dramatically increasing the reach and range of business process management across the enterprise.
Since each application is event driven, it is none the wiser about how such interactions are accomplished - it simply consumes and emits messages. For example, an architect can initially configure a logical point-to-point connection between two applications, and then later add a publish-and-subscribe mechanism to also collect event data. And perhaps later build a process flow that would invoke the same applications in a more complex interaction pattern. All these changes can be accomplished without altering the underlying applications or their service interfaces.
In a SOA integration environment, integration capabilities - such as transformation, sophisticated process orchestration, enforcement of security policies or auditing - can also be provided as services. These services can be deployed as many times as necessary and in any combination, anywhere within the integration network. This offers organizations the flexibility to deploy precisely the integration capabilities required, to scale those capabilities independently of one another and to incorporate them as processing stages between any set of applications.
Significant strides are being made toward rich interoperability through Web services and other SOA standards. For example, WS-Reliability introduces reliable communication for Web services, while WS-Notification adds a standards-based support for publish-and-subscribe event notifications. At the same time, the Java community is addressing interoperability through the Java Business Integration initiative, JSR-208. These advancements promise to provide richer interoperability, not just between applications, but between integration components as well. The latter capability is particularly intriguing in that organizations will be able to assemble integration infrastructure using best-of-breed offerings from multiple vendors. For example, process flows managed by one vendor's process engine will be able to span policy engines from a second vendor and data management services from yet another vendor.
SOA provides the key to unlocking integration, by providing an enterprise-wide architectural approach to bridging applications and promoting a set of standards for rich interoperability. It's only a matter of time before this flexible way of thinking about applications makes integration technology a natural, fundamental aspect of IT infrastructure.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access