Enterprise Application Integration with Microsoft BizTalk Server 2006-Part 1

Enterprise 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. This article (Part 1) will provide a conceptual overview of BizTalk Server 2006 and how it serves to address the problem domain common in the EAI space. In Part 2, I’ll introduce a business case for implementing an online ordering and fulfillment system and provide a step-by-step example of how to implement a solution that addresses the problem domain.

Over the last 50+ 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 re-use 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).

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.

By: Rick Garibay

With over 13 years’ experience delivering solutions on the Microsoft platform across industry sectors such as finance, transportation, hospitality and gaming, Rick is a developer, architect, speaker and author on distributed technologies and is the General Manager of the Connected Systems Development Practice at Neudesic.

Rick specializes in distributed technologies such as Microsoft .NET, Windows Communication Foundation, Workflow Foundation, and Windows Azure to deliver business value and drive revenue while reducing operational costs.

Rick serves as a member of the Microsoft Application Platform Partner Advisory Council and is an advisor to Microsoft in a number of capacities including long-time membership on the Business Platform and Azure Technology Advisors group. As a five-time Microsoft Connected Systems MVP, Rick is an active speaker, writer and passionate community advocate in the national .NET community. Rick is the Co-Founder of the Phoenix Connected Systems User Group, celebrating four years in operation.

Recent presentations include talks at the Microsoft SOA and Business Process Conference in Redmond, WA, Microsoft TechEd, DevConnections, .NET Rocks, Desert Code Camp, and numerous Microsoft events throughout North America. Rick is a frequent contributor to industry publications such as CODE Magazine, and is the co-author of Windows Server AppFabric Cookbook by Packt Press.

When not immersed in the work he loves, Rick enjoys mountain biking and spending time with his wife, Christie and two children, Sarah and Ricky.