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.
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.
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?
The trick is to decide where each platform is strong and not so strong, by your definition given the solution you're trying to piece together. In this case, I'll limit this discussion to the Web server shown in Figure 1. You can use SQL Server or Oracle for your database at any time, and the user can choose which browser will display the resulting information from your system. The Web server might use ASP.NET for the presentation subsystem, yet use J2EE for the business logic and data-access components. Or, you might use Java Struts to construct the user experience, yet write your transactional logic using .NET and C#. In both cases, you'd need to marry business logic components to the presentation layer.
The most obvious and probably most common integration technique is to use the XML Web service as the data bridge between Java and .NET. This is, in fact, a primary goal of the XML Web service—to enable the integration of heterogeneous platforms. The data is transformed into a standard format (XML in SOAP form in this case), and each side both generates and consumes the SOAP XML packet.
XML Web services are exploding in popularity, and as a result, every major platform has support for them. .NET was designed and built with Web services in mind, and the Unix platform has several choices for venders, including IBM, BEA, and of course open-source solutions such as Apache and Tomcat.
Instead of rolling data into a proprietary format, like DCOM's object format, data is transformed from its binary representation in the source system into XML using XSD-compliant data types ("XSD" in this case refers to the XML Schema, Part II, "Datatypes," found at http://www.w3.org/TR/xmlschema-2/). XSD is capable of describing a great variety of primitive datatypes, such as integers, strings, and floating-point numbers. But XML in general can contain more complex data structures, as described in the SOAP specification (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ for SOAP version 1.1, and for SOAP 1.2 collectively, http://www.w3.org/TR/soap/). You can format your structures according to the SOAP specifications, or you can use a more message-based approach (more free-form) if you "describe" the resulting XML structure using the Web Service Description Language (WSDL, version 1.1, found at http://www.w3.org/TR/wsdl). This allows your Web service consumers to interpret the incoming XML message and react accordingly. Figure 2 shows a slightly revised business logic diagram.
A primary benefit of using the XML Web service for integration is that the Web service is readily available to any and all applications that might make a call to one of its Web methods. The Web service isn't tied to any particular application and it's ready for any application to use, allowing for solid reusability.
Where the situation calls for large datasets to be issued to and from the Web service, or where speed is a concern, .NET remoting might be helpful. Why use .NET remoting when joining .NET and Java? Because the specification that governs .NET remoting was released to ECMA as part of the CLI specification (http://www.ecma-international.org/publications/standards/Ecma-335.htm), resulting in several Java remoting bridge products, including JNBridgePro (http://www.jnbridge.com/jnbpropg.htm) and JA.NET (http://ja.net.intrinsyc.com/). On the surface, a figure representing this situation might not appear that different from the Web service case (as shown in Figure 3).
Figure 4. Shared database connection.
Kenn Scribner is with Wintellect (http://www.wintellect.com/).
Other than Web services, Remoting, and Database, now there is another way for .NET <-> Java interoperability: implementing RMI/IIOP binary protocol.
J-Integra for Espresso is a new product which implements a pure .NET version of the standard RMI/IIOP binary protocol present in all J2EE and J2SE Java environments. Using J-Integra Espresso, Java, CORBA, and .NET applications can seamlessly interact, enabling companies to take advantage of the best available software applications regardless of what technology they are based on and without sacrificing interoperability.
J-Integra for Espresso has been developed entirely as managed code and can therefore be accessed by all .NET languages (C#, ASP.NET, etc...). It's Bi-directional and up to 20x faster than Web services.
J-Integra Espresso provides additional performance, scalability, and security benefits since it uses the Internet Inter-ORB Protocol (IIOP) present in virtually any Java environment along with Secure Socket Layer (SSL) support.
J-Integra for Espresso also includes plugins for Visual Studio.NET 2003 AND Visual Studio.NET 2005, which enables developers to incorporate J-Integra for Espresso into their .NET client applications while working entirely within the Visual Studio environment.