nterprise Application Integration (EAI) is a collection of architectural principles combined to integrate new and existing applications both within the enterprise and in business to business or partner integration scenarios.
Part 1 of this article series provides a conceptual overview of BizTalk Server 2006 and how it serves to address the problem domain common in the EAI space. Part 2 introduces a business case for implementing an online ordering and fulfillment system and provides a step-by-step example of how to implement a solution that addresses the problem domain.
Over the last 50-plus years, a recurring theme in the advancement of software and hardware technology has been the subtle, yet significant reduction in coupling between both hardware and software itself and its constituent artifacts. From the earliest electro-mechanical machines (with the "code" embedded in the hardware itself) to general-purpose systems and microcomputers, each significant advancement in technology has ushered with it a reduction in interdependencies between dependant parts.
For example, assembly languages moved the industry beyond embedding code within moving sprockets and dials. Procedural languages offered an alternative to programming directly against specific hardware. Object-oriented programming introduced an even brighter future in which composition and behavior of a program could be modularized into reusable building blocks that could be compiled and hosted on any machine provided it was built on the same processor architecture. Decades of use have found even this level of flexibility to be too restrictive because intimate, white-box reuse is required to leverage these objects, in a sense coupling the client to the underlying implementation.
Newer, component-oriented technologies such as COM, COM+ and .NET were introduced to address some of these challenges, bringing the concept of black-box reuse, in which clients are bound to objects almost exclusively via interfaces or contracts. When communicating using a predefined interface or contract, objects take the form of components, which are really just more sophisticated objects. With components, objects can communicate within the same application or across machine or process boundaries. However, even though components can communicate with other objects/components across process boundaries with greatly reduced coupling, the protocols, platforms, and technologies are largely proprietary, requiring that objects communicate within vendor-specific offerings. That said, components are a necessary and important evolution within software engineering and have laid the foundation for more recent developments (i.e., services).
|Today, complex business processes can be exposed via service endpoints so that their service interfaces can be easily leveraged in a location-transparent manner.|
Since the advent of component technologies, the Internet has provided unprecedented levels of interconnectivity between systems and networks, accelerating globalization at an alarming rate. Demands for connectivity require further decoupling from vendor-specific frameworks and pseudo-protocols. Through the standardization of data transfer objects with XML, the concepts of object and component orientation set the foundation for services; the latest generation of which has been popularized by SOAP XML Web services. Using a common, textual way to represent data while providing a vendor-neutral manner of moving this data between memory and wire protocols, components, or services can now not only communicate across processes, but messaging through public (Internet) and private (intranet and extranet) networks worldwide is a reality that is quite tenable today.
SOAP, XML, and Web services are now the mainstays of modern services, and many organizations and vendors are under significant pressure to put this newfound level of connectivity and interoperability to work in an effort to maximize returns on existing and future investments. As such, applications can no longer be thought of as islands unto themselves. Although SOAP Web services solve some problems, using them introduces some new challenges as a result.
Developers today face the daunting task of integrating a myriad of applications using this nascent technology for which standards are continuously emerging. Within many organizations, the demands for integrating new and legacy applications has resulted in integration spaghetti, the unfortunate result of having to deal with older legacy protocols and a lack of experience, design, and architecture for braving this new frontier of application integration.
Not only do organizations need to integrate new and existing applications, but those organizations must consider and address goals above and beyond interoperability such as availability, reliability, scalability, performance, and security (to name a few). Due to the disconnected nature of HTTP, the protocol on which SOAP XML Web services ride, delivering on these design goals is not trivial and introduces a host of new problems facing developers and architects. In addition, organizations have made significant investments in legacy applications (for which it would be too expensive or impractical to implement contemporary interfaces) that rely on tried and true protocols such as FTP and SMTP along with flat-file formats that these same organizations must somehow continue to leverage within new integration scenarios. These protocols and formats are prevalent in many systems, and today, the applications that employ them demand the same levels of interconnectivity as their contemporaries.
Enterprise Application Integration (EAI) is the process and supporting architecture for linking distributed systems (both legacy and new) together within the enterprise and in business to business or partner integration scenarios. By integrating existing investments with new products, organizations can maximize the longevity of their intellectual property and return on investment.
|Editor's Note: This article was first published in the May/June 2007 issue of CoDe Magazine, and is reprinted here by permission.