In areas where Web services do not adequately facilitate interoperability today, what are the alternatives? For those concerned with performance and the size of serialized data, one option is to choose a binary interoperability solution. Binary interoperability methods take objects from one platform, serialize them into a binary stream, send them across the network and then de-serialize the same data on the other platform. Because both parties agree on the binary format to use, the serialization ensures that the binary data is successfully mapped to local data types for each platform
One way of achieving this today can be to use .NET Remoting. .NET Remoting is a wire-level protocol, introduced with v1.0 of the Microsoft .NET Framework, and is open to license. As a result, third party options that offer Java implementations of the .NET Remoting protocol have appeared on the marketone of which is JNBridge Pro
Toolkits such as JNBridge let applications wrap compiled Java objects (even EJBs) and expose them to .NET callers using the .NET Remoting protocol. Because the protocol supports a binary channel, it can help reduce the packet size of calls going across the network, which in turn can lead to better performance than an approach using XML serialization. In addition, .NET Remoting can be used for connections that hold state, whereas Web services are typically designed for stateless calls. .NET Remoting is also useful for Inter-Process Communication (IPC), where components on each platform are running simultaneously on the same machine. For example, using IPC, you could have a local Java application using Java SWING talking to another local application written in .NET managed language such as C# or Visual Basic.NET.
The advantages of binary communication do have a price. Applications that use .NET Remoting typically live within the enterpriseand are rarely exposed to other organizations through firewalls or proxy servers (although .NET Remoting does support an HTTP channel and SOAP formatter). This occurs primarily because the data types exposed by a .NET Remoting server are based on the CLR (Common Language Runtime), whereas the WS-I basic profile (and other Web services implementations) rely on more standardized XSD style data.
In addition, using a binary channel tends to enforce tight coupling with interfaces that are exposed, meaning that if the methods of exposed components change when using .NET Remoting, you normally have to re-generate stubs and recompile both the client and the server. In contrast, SOAP is far more extensible; you can include additional data in the message header without having to modify the interface (WSDL document).
In his article, "Calling Java Classes Directly from .NET," Wayne Citrin, the CEO of JNBridge, will discuss more about his company's product and potential solutions in which you might prefer to achieve interoperability with .NET Remoting. In a related article, "Hosting NET Controls in Java," Heath Stewart will talk more about a .NET Client consuming Java classes using a similar approach.
Interoperability Using CORBA
If binary interoperability is a must, but .NET Remoting is not a recognized standard within an organization, another alternative exists for organizations that have standardized on CORBA (Common Object Request Broker Architecture).
The last twelve months have seen the introduction of a number of open source and commercial products that provide .NET clients with the ability to call and invoke remote objects written to the CORBA specificationand that aren't limited to interoperability only with Java-based applications. Typically, these products enable a .NET client to use IIOP (Internet Inter-ORB Protocol) to invoke remote components. One such commercial product is Borland's Janeva.
This approach is most useful for organizations that have deployed CORBA server-side components but who do not wish to make any changes to them. Although using .NET Remoting provides binary interoperability, many toolkits still require some modification to server-side objects before clients can call the server component. Using a toolkit that allows a .NET client to natively reference a CORBA object can overcome this by requiring modifications only to the client.
One disadvantage is that the approach mandates ".NET client to Java server" style architecture. In many applications there are occasions where Java components need to invoke remote .NET objectsa good example of this is where an organization is implementing a Service Oriented Architecture (SOA) and has a combination of services developed using both technologies.
In his article on Borland Janeva, "Connecting CORBA to .NET," Bob Swart will cover this scenario in more detail and look at the types of applications that can benefit from this approach.