.NET/Java Interoperability: Apply the Proper Tool for the Job
As I travel, whether instructing or consulting, the topic of .NET versus Java continues to fuel heated debates: Which framework is better? Which framework is optimal? Which framework will dominate the corporate enterprise?
Well, I'm sure we all have our opinions—and quite valid ones at that—but as I see it, the truth of the matter isn't that .NET is superior to Java, or that Java is superior to .NET. We actually have two fantastic platforms on which we can develop enterprise solutions that drive corporate revenue (or so we hope) and serve to promote the business-computing environment for which we develop software. Pick your platform. They're both awesome and should serve you well.
And in fact, many corporate environments today truly are heterogeneous enterprise-computing environments. Accounting may be running a Java-based business layer that talks to an Oracle database that feeds data to a thick-client application. Human Relations may be using an all-Microsoft solution where the user interface is ASP- or ASP.NET-based with .NET or COM mid-tier business components feeding data to and retrieving data from a SQL Server database. And the marketing department, well, they're quite the interesting bunch. They're using Java beans for the mid-tier, which feed business information to an ASP-based presentation layer.
As I see it, Java and .NET are tools—powerful tools, but tools nonetheless—that we use to build our computational infrastructure in support of our businesses' revenue streams. And as with any tool, some are optimized for certain tasks whereas others are optimized for other tasks. .NET and Java definitely work in the same task space, but you may choose one or the other for some specific reason or set of reasons that are germane to the problem or problems you're currently trying to solve.
So, instead of arguing which is better, this article instead explores some ways in which the two can work together. Let's face it, both Java and .NET are here to stay and both have valid claims for your enterprise computing software work.
When I say work together, I'm specifically talking about interoperability. At its lowest level, interoperability defines how we share data. The typical problem we face, though, is that "data" for one system doesn't map directly into "data" in another. For example, in the Human Relations system I mentioned previously, the .NET CLR does not store the data structures that represent employee data in memory (as binary information) the same way Java would. In fact, those same data structures could be stored differently even between two Windows Server systems, if the servers are running different processor architectures (like a Pentium versus a MIPS processor or an Alpha processor). So, you can't just take the binary information directly from the address space of one system and shove it into another system if the two systems differ significantly. (Even if they don't differ, you typically don't transfer data using literal memory copies.)
Instead, you typically convert the data as it leaves one system into a form that the other system can consume. This data format might not be (and often isn't) in the native format of the second system. However, it will be encoded in a form that can be converted into the second system's native format, such as from XML or an agreed-upon binary protocol. If it weren't, you wouldn't be transferring data in the first place.
Now, just by reading the title of this article you might think I'm talking about .NET objects accessing Java objects on the same computer. While I certainly can't speak for every business solution out there, I do feel confident in saying that the vast majority of systems in play today probably aren't looking to interoperate at the binary level (akin to Microsoft's JDirect from years past, where Java would work directly with external dynamic link libraries). Instead, my travels and experience tell me that people are interested in having systems running Java "talk" with systems running .NET so that they can exploit the features inherent in each platform yet derive benefits where the sum is potentially greater than the single parts alone.
Because we're talking about different computers executing different runtime environments, we're really talking about interoperability between distributed systems. Typically, these are n-tier systems that involve several layers of processing, from database to presentation layer. Figure 1 shows a typical architecture.
Figure 1. Typical N-Tier System
The question of interoperability comes into play when one or more of the tiers in the distributed application is built using differing technologies (.NET versus Java). How can you exploit the strengths of each platform while at the same time giving the consumers the illusion that they're dealing with a single system?