Addressing the Last Mile of Integration

PDF Download free Adobe Acrobat Reader.

The hardest part of enterprise integration involves developing the point-to-point connections among resources in the data center – what I like to call the "last mile of integration." Just as phone companies wrestle with incompatible circuits, switches, and transmission standards as they bring services into your home, corporate software developers must contend with a plethora of platforms, operating systems, databases, and applications to enable new business services.

Today's packaged integration solutions fail to address the fundamental problem. They include robust tools for building and integrating applications within their "extended families," but developers must resort to manual coding to incorporate information assets that aren't part of the core environment. Typically, these solutions are either aligned around an application server platform (from vendors such as IBM, BEA, or Microsoft) or an application software package (from vendors like Oracle, PeopleSoft and SAP). The application server may not support the same set of data adapters as the portal or integration broker. Hence, the "last mile" of integration is usually bridged by writing a great deal of custom code:

	One type of code to connect portal applications with relational databases
	A second form of connectivity to interact with legacy files, transactions, and packaged applications
	A third form to connect various types of B2B exchanges

This same problem is repeated at the tool level. Typically, the integrated development environment will connect through Java™ Connection Architecture, Java Database Connectivity, or some kind of Web service. Business intelligence and ETL tools will use their own proprietary methods. And integration brokers use Extended Markup Language (XML).

In short, as good as today's application development and integration tools have become, they don't provide universal connectivity to many different information resources. Developers can use them to develop and integrate specific types of applications, but they will reach a roadblock when it comes time to connect them to the enterprise at large.

Building a Reusable Framework

Just as electrical circuits have been standardized to provide universal connectivity for appliances, it is possible to create an enterprise integration architecture that enables applications and tools to adapt to wide-ranging connectivity requirements. The key challenge to architecting these solutions is scope. They must be able to:

	Service all conceivable appliances, including portals, BI tools, IDEs, application servers, integration servers and message brokers utilizing standard technology such as JDBC, ODBC, ASO.Net, JCA, and Web services
	Support virtually every physical means of interconnecting appliances and information resources, including Internet protocols, message-oriented middleware, and legacy transports such as APPC
	Transform the expression of data between the various types of information resources utilized by most business enterprises appropriate to the needs of each appliance
	Allow developers to implement complete enterprise solutions with little or no need to write custom code

iWay supplies a universal adapter framework that standardizes the interaction among IT resources so developers don't have to implement and manage multiple connections. Once you install the iWay adapter framework, the metadata is exposed in a common way across all tools and environments.

Making the Right Connections

For example, suppose you wish to connect a Microsoft .NET environment with a VSAM database on a mainframe computer. If you are using common .NET technologies – such as Web services, a BizTalk Server framework, and a SQL Sever database – you typically will need three different adapters or three different styles of integration code. But with a universal adapter framework such as iWay, you can simultaneously expose the metadata three different ways. To Visual Studio, the VSAM data would look like a Web service. To SQL Server, it would appear as a distributed SQL Server table. In BizTalk Server, it would be an XML service schema.

Once the iWay framework is installed, developers don't have to learn one methodology for Web services, another methodology for XML schemas, and a third methodology for SQL databases. iWay automates the implementation requirements at each level of the technology stack. To the portal, it looks like a Web service. To the ETL tool, it looks like a remote database. To the broker, it looks like an XML service schema. In each case, the data is exposed in a way that is useful to the tool, supplying universal, plug-and-play connectivity.

Without a uniform adapter framework that supplies common connections to all potential information assets – including metadata definitions – developers find themselves creating interfaces to the same information resources, again and again. The last mile of integration is most easily bridged by mature, general-purpose adapter technology.

Java and all Java-based marks are trademarks of Sun Microsystems, Inc. in the U.S. and other countries.