In-Depth

Java & .NET can live together

• By Richard Adhikari
• December 1, 2001

Among the solutions on the market is bridging software to enable Java and .NET applications to communicate. JavaCOM applications can also serve as bridges, but developers can run into various snags while using them. Then there are Web services and the industry-driven Simple Object Access Protocol (SOAP). Proponents say these technologies will link Java and .NET services. But SOAP has its own problems, and skeptics say it will be just another solution instead of the be-all and end-all its supporters claim it will be.

Existing software bridges
One currently available software bridge is the Remote Java ActiveX (R-JAX) Server from Halcyon Software Inc., San Jose, Calif. R-JAX links Microsoft ActiveX, DLL and COM to any Java application, running either remotely or locally, on any Java-enabled platform, whether it is Windows or not. Users can manipulate the available methods and properties and get back results. Users can generate proxy Beans with the R-JAX Bean Generator. This allows users to create JavaBean components, including remote connectivity code, based on the COM or DLL object description. It lets the components created communicate with the R-JAX server, making remote COM components accessible so "as far as you're concerned, you're using a local Java- Bean," explained Naufal Khan, Halcyon's vice president of engineering.

Users with internal human resources applets or other applets with light footprints can use R-JAX's client-level API, noted Khan. This allows them to invoke a method without generating a proxy. R-JAX supports HTTP, Remote Method Invocation (RMI), a key protocol in Java for remote procedure calls, and the Transmission Control Protocol (TCP). Users, including developers, do not need to know how to configure these protocols, said Khan; they just select what they want from a pull-down menu.

R-JAX consists of components that are independent of one another and can be adjusted individually. Components include: Client Bean, a connection point for connecting Java applications to native COM or DLL objects; the Bean Generator; the R-JAX Server, a combination of native and Java binaries that runs on the Windows server where the COM/DLLs reside and which comes with a full-featured, browser-based console applet; and the R-JAX Communication Adapter, which serves as a conduit for RMI, TCP or HTTP between the Java application on the local server and the remote COM/DLL component.

Halcyon is working on a new product tentatively named J-ROM, which will be "R-JAX in the world of .NET," said Khan. This will allow developers to generate Java with Java proxies for .NET Common Language Runtime (CLR) objects, among other things. CLR is the virtual machine that runs the .NET code. Halcyon is also planning to offer capabilities that will let users run .NET applications from within Java or vice versa.

Developing an implementation of Microsoft's CLR in Java will make integration between Java and .NET inherent. "The CLR code will be Java byte code and will run within the JVM, so you'll be able to integrate with CORBA services running within Java and J2EE," explained Bill Conroy, enterprise architect at Extreme Logic, Atlanta. That means users "will get the interoperability for free to a certain extent," he added. Extreme Logic, which builds e-business solutions using Microsoft technologies, has also worked with Java.

However, the problem with this approach is that users are limited to whatever the JVM can do in terms of interoperating with the operating system the application is running on or other services. The fragmentation of the Java market is another drawback. While there is only one CLR, because "CLRs are so complicated to write," there are "probably hundreds of JVMs, and different JVMs have different capabilities, which makes it difficult to have generic interoperability between .NET and Java," said Conroy. Also, direct integration between Microsoft's CLR and a JVM is "the most complicated scenario," he said.

Mike Gilpin, vice president and research leader at Giga Information Group, Cambridge, Mass., said two other companies—Actional Corp., Mountain View, Calif., and Iona Technologies, Waltham, Mass.—offer bridges between Java and .NET. Actional, with its Control Broker product, "has been bridging the Microsoft-Java worlds for some time, and they now have Web services capability," said Gilpin. Merrill Lynch and other companies are "using this as a general-purpose service broker to, in effect, provide a bridging capability between Microsoft and the Java world," he added. Iona takes a Web services approach.

Actional's Control Broker has an "any-to-many" architecture that directly connects front-end e-business systems to back-end ERP and legacy environments. Actional Control Broker for COM enables COM developers to seamlessly access and assemble components and services across middleware, packaged applications and legacy systems. These services appear as native COM components to developers. The Actional Control Broker for J2EE does the same thing for developers working in J2EE, where services appear as Java code or EJBs.

Another alternative is to use JavaCOM applications as bridges, said Extreme Logic's Conroy. JavaCOM applications that call from Java code to COM components and the other way around "can serve as bridges between Java and .NET, because Microsoft is providing a bridge from .NET to COM with the .NET framework," said Conroy. While that means going through two layers—from the source (Java or .NET) to COM, and then to the target (.NET or Java) and vice versa, it will work, he said.

The problem is that applications then go through three different runtimes and there will be some denigration. "The chain of your calls being passed through those three runtimes may lose some of their fidelity because transactions can't be carried through all three runtimes," Conroy explained, adding that this could go "to the point where transactions don't exist."

Content management solutions provider Documentum Inc., Pleasanton, Calif., will not create a bridge between Java and .NET. "No bridging strategy for us," states Whitney Tidmarsh, vice president of product marketing. Documentum will allow for a .NET interface into its API set that is J2EE-compliant so users "can choose between one and the other and interact with our API in the same way." The firm will do this by creating a .NET-compatible version of its Web Development Kit (WDK), which has 53 components written in Java. "We'll take .NET-style classes we can call into our APIs, and we'll either go direct to J2EE calls or we will call direct into C++- or COM-based applications," said Tidmarsh. Documentum will create the .NET-style classes itself.

There are several problems with using bridges between Java and COM, said Ed Anuff, founder and chief strategy officer at Epicentric Inc., San Francisco, which offers a platform-neutral portal architecture. The bridges are complex to use and typically require some proprietary third-party drivers, he noted. Another option is to use the Java Native Interface (JNI) for calling into C++ code and then use that as the mechanism for calling a Microsoft-based service. However, most Java-based developers would rather not do that "because it's fairly fragile and difficult to debug," Anuff said.

While using the SOAP-based RPC mechanism inherent within .NET to bridge between Java and .NET "appears to be not the most effective mechanism," he said, "it's the most straightforward approach. Particularly in terms of being supported strongly from the Microsoft side of the equation, and that's what developers have struggled with most heavily.

"Most of the approaches, like JNI, aren't perceived as being particularly strongly supported or endorsed by either Microsoft or Sun," added Anuff. SOAP holds out more hope because "there seems to be some effort at an industry-wide level of agreement as to what Web calling protocols should look like," he noted.

Web services and SOAP
Many vendors agree with Anuff that SOAP-based Web services will provide the bridge between Java and .NET. "If you have a single standard that uses HTTP as its support, you can access data from different sources without rewriting the underlying code," said Tom Clement, director of emerging technologies at Avinon Inc., San Francisco. "There are tools that let you take older COM-based objects and expose them as a SOAP-based Web service and they are also available for J2EE." SOAP's possibility of creating interoperability between Java and .NET is "more than a promise, but less than reality" because there are no universally accepted standards now, he added. However, the industry and the World Wide Web Consortium (W3C) are working on creating universally accepted standards, said Clement.

David Spicer, CEO and CTO at Flamenco Networks Corp., Alpharetta, Ga., said the emergence of the Web Services Description Language (WSDL) and SOAP have released a pent-up demand to get applications talking. "You can now hook up Pascal programs to Java programs and they're all communicating through Web services," Spicer said, adding that SOAP will create a bridge between Java and .NET.

Flamenco offers a Web services network that corporations can use to integrate their Web services across multiple platforms, protocols and operating systems. Spicer describes the company as "the telephone company for Web services." Flamenco provides the transport, and manages certificates, encryption and compression—"all the stuff you need to get a robust network"—and lets users manage it from a central Flamenco Web site that is a network management system, said Spicer. Transmission is peer-to-peer and Flamenco's technology is implemented in Java as a proxy function.

Iona Technologies offers a Web services infrastructure in its XMLBus 1.2 product, which creates interoperability between .NET, CORBA and J2EE. It supports SOAP with attachments so users can send Extensible Markup Language (XML) documents, binary data and encrypted messages across the Internet; has Secure Socket Layer (SSL) integration so Web services can communicate over HTTPS; enables business services and applications to directly exchange XML documents and RPCs over the Internet without browsers or HTML files; and lets corporations leverage their existing Internet infrastructure.

Problems with SOAP
Standards and interoperability are still lacking right now, which means SOAP is not quite up to scratch yet. For example, WSDL is accepted and defined by Microsoft's Web services but not by some other SOAP implementations, said Extreme Logic's Conroy.

Giga Group's Gilpin agrees that many vendors are implementing SOAP differently. While these differences "are not as significant an issue as some of the differences in Unix, they do mean you can't blindly write your code without thinking [about] where someone's going to call it from," he said.

In fact, the technology around SOAP is a Tower of Babel. "They all have little nuances in their implementation of SOAP, right down to the way they do HTTP," said Adam Greissman, CEO and founder of UDICo Inc., New York, a spin-off of PricewaterhouseCoopers that implements large global response systems at major financial institutions worldwide. UDICo has developed TierBroker, a platform- and database-independent data integration toolkit.

"We tested over 50 SOAP sites and found certain servers do the HTTP transaction differently than others," Greissman said. "If the fun starts there, you can imagine what happens by the time you get to the business side of the transaction like wrapping up the SOAP object." UDICo tests to make sure TierBroker can work with both sides of a system using Web services because "it has to be able to connect the .NET world to the J2EE world," he said.

Greissman's advice to anyone working with SOAP: Test, and test often. "There are lots of SOAP servers and clients now and they're hand-coded so they don't all follow the specs the same way," he noted. "You need tools tested against the key environments so you can be sure they are going to work."

There are also security issues with Web services, Giga Group's Gilpin said. "Web services can leverage Port 80 and make programs look like HTTP traffic; that doesn't mean they are [a] services firewall administrators are going to love," he said. Because firewalls generally do not look inside messages going over the Internet, that could lead to security breaches.

Brian Reed, vice president of strategic planning at Merant Inc., Rockville, Md., said Web services is "just a next silver bullet, not the next silver bullet." Consistent component behavior is crucial, according to Reed. SOAP vendors will probably let users run a .NET component encapsulated like a Bean in the Java platform or EJB in a .NET container, but there should be a set of components that provide consistent behavior across all those steps, said Reed.

"I have a data connectivity component and it ought to represent itself the same way to .NET or J2EE interfaces because it's using those interfaces to talk to legacy systems at the bottom," he explained. "It should look and feel the same, whether it's .NET or J2EE." The Merant DataDirect Division, where Reed works, provides connectivity components for data using Java and .NET.

The biggest debate going on now is over the types of transactions that should be enabled when bridging between Java and .NET using Web services, said Extreme Logic's Conroy. The types of transactions going through in COM and .NET environments will not work well over the Internet because "transactions can lock and hold on to your resources for a long time and that can happen over the Internet easily, so nobody wants to see two-phase commit transactions," said Conroy. That is the kind of transaction that goes through in Microsoft's Distributed Transaction Coordinator (DTC) in the COM and .NET environments. Another problem with DTC is "it works better in a closed network where you handle all the resources and won't work well where resources are not within your control," explained Conroy.

No need for bridges?
Not everyone will need to bridge between Java and .NET, whether they are using Web services or other solutions. "Bridge vendors are trying to position themselves as being something everybody will need, and I don't think that's true," said Giga's Gilpin. Bridges will be most useful in environments with two features, he added: Those with "a lot of heterogeneity" and those that are undergoing rapid change.

Meanwhile, changes in the industry may reduce the need for bridges between Java and .NET. "Sun announced recently that they'd rethought their plans with Web services and are going to make that a bigger part of the Java platform," said Extreme Logic's Conroy. "That will ease interoperability between the two platforms, which means they can potentially work without any third-party bridges or products."

Whether or not bridges are used is not important; what is vital is that communications between applications is made easier.