.NET/Java Interoperability: Apply the Proper Tool for the Job, Page 2
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.
This leads to the interoperability model, by which I mean the way you communicate data between layers. I see three primary models that should work well in today's enterprise environment:
- Web services
The assumption with these models is that the Microsoft-based components are running on a Windows platform, whereas the Java components are running on a Unix platform such as Linux. No matter what you do, in this situation you'll have to make off-system calls to integrate your subsystems. You could argue that CORBA or even DCOM could perform this integration, but both CORBA and DCOM suffer from the same troubling issue—both are partially or fully proprietary. Therefore, neither allows for seamless integration. (You could argue that .NET remoting also is proprietary, but I'll get to that in a moment.)
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"). 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 for SOAP version 1.1 and SOAP 1.2, collectively. 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). This allows your Web service consumers to interpret the incoming XML message and react accordingly. Figure 2 shows a slightly revised business logic diagram.
Figure 2. Business Logic Using Web Service Integration
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.
The primary drawback with the XML Web service is simply that the tradeoff for conversion to a common datatype typically takes more time than equivalent binary conversion, resulting in slightly more processing latency for the off-system call. Many applications will find this latency tolerable when contrasted against using Internet standard protocols and simplified administration. (Web services are simply Web applications themselves, easily administered via the Web server software in use.) Other applications may find this latency intolerable. (Systems that make many such interoperable calls when processing a single user request, or perhaps systems that must return information in a more narrowly constrained timeline.)