Chapter 13. Integrating with Unmanaged Components

I l @ ve RuBoard

In an ideal world, you'd be able to combine components in a seamless manner without having to worry about how they were implemented, which languages they were created with, which tools were used to build them, or even the platform they execute on. The Java programming language was designed to be portable and all-pervasive, and even though it has not lived up to the hype of the early days, it is available on almost every common computing platform. Java applications created on one computer will run unchanged on a totally different computer and processor architecture as long as the developer remains within the confines of the standard libraries supplied with the JDK. What's more, Java applications can consume Java components (JavaBeans and Enterprise JavaBeans) that were compiled on any computer and developed using any of the commercially available Java compilers ”as long as they emit standard Java bytecodes. Interoperability between components created using the Java programming language is, by definition, easy.

Microsoft .NET has a similar aim in terms of interoperability, but the common language runtime takes things a step further. You saw in Chapter 2 how components can be written in one .NET-compliant language and consumed by applications written in another. The main requirement for this feat is that both languages be compiled to produce assemblies that are executed by the common language runtime.

While the seamless integration of components and applications is fine for new development, a large base of existing, heritage (legacy) code is still out there. For the foreseeable future, in many enterprise applications you'll be confronted with the challenge of integrating software into your systems that was created using technologies other than .NET. For example, you might have a number of COM components that you've purchased or that you've expended a great deal of effort to produce, and you might not want to discard them. You might need to use heritage library routines implemented as functions in regular DLLs. You might also want to make use of certain specialized services of Microsoft Windows XP, such as the System Restore API or the Background Intelligent Transfer Service. These services do not currently have .NET interfaces available, so you have to use alternative means. In still another scenario, you might find yourself needing to integrate with Java 2 Enterprise Edition (J2EE) applications or even CORBA components.

In this chapter, we'll examine some of the more common options for meeting these challenges. In particular, you'll learn how to invoke functions implemented in DLLs and how to use various techniques for integrating COM components into .NET. (I'll assume that you're already familiar with COM.) We'll also look at how to make .NET components available to COM clients . Finally, we'll consider some ideas for integrating existing J2EE and CORBA objects into a .NET application.

I l @ ve RuBoard