Plug Into J2EE-.NET Interoperability (Continued)

The Need to Interoperate
The need to interoperate arises more often than one would think, especially as you look at larger IT shops. Most large companies have standardized technology stacks. But just because the stacks are standardized doesn't mean they won't evolve or grow over time. As a result, different solutions created at different times might use different technologies. Eventually, there is always a business need for these solutions to interoperate.

Furthermore, large companies typically grow by acquiring other smaller companies that have no knowledge of or concern for the technology stack the larger company used. The technology the smaller company uses could be not only different, but even completely incompatible with the larger company's technology.

For example, most large companies I have worked with standardize around J2EE, and most small companies I have seen use Microsoft technologies such as .NET. As before, the business will find a need that forces your J2EE solutions to interoperate with the acquired .NET solutions.

Sometimes, the need to interoperate is mandated by conflicting requirements on the same project. For example, I was involved on a project for a U.S. state where the "technology authority" for that state standardized on J2EE, but the state agency prefers .NET. As a result, the presentation side is based on J2EE (Struts), and the middle tier is in .NET. The back end is a legacy mainframe database. The need to interoperate definitely exists today and will only grow stronger with time.

The Interoperability Standards
A major reason for difficulty with interoperability in the past was a lack of agreed upon and adopted standards for such interoperation. Today two well-defined and mature standards exist that can help alleviate interoperability pains.

The Internet Inter-ORB Protocol (IIOP)
Recognizing the need for interoperability, the Object Management Group (OMG) defined the Common Object Request Broker Architecture (CORBA) in the early 1990s. The OMG is a consortium of more than 700 companies, including Microsoft. As part of the CORBA specification, the OMG defined the protocol requirements formally known as the General Inter-ORB Protocol.

Unfortunately, CORBA implementations from different vendors had difficulty interoperating. A few years later, in an attempt to guarantee interoperability between the different CORBA implementations, the OMG defined IIOP, which is a concrete realization of the GIOP specification. In other words, IIOP is an implementation of the GIOP specification over TCP/IP. All CORBA 2.0-compliant object request brokers (ORBs) must support IIOP, so they are interoperable.

Unfortunately, not all software applications are built using CORBA. Furthermore, even though Microsoft is part of the OMG, it did not base its DCOM solution on IIOP. Instead, it created its own proprietary protocol called Object Remote Procedure Call (ORPC) for DCOM, which is incompatible with IIOP. A few commercial "bridge" products cross the IIOP/ORPC boundary, but such bridges never gained popularity.

The Simple Object Access Protocol (SOAP)
Recognizing the need for a better solution to the interoperability problem, Microsoft, IBM, and DevelopMentor came together in the late 1990s to create the first version of SOAP. These points are noteworthy about SOAP:

• Whereas IIOP, ORPC, and Java Remote Method Protocol (JRMP) are binary protocols, SOAP is a text-based protocol that uses XML. Using XML for data encoding gives SOAP some unique capabilities. For example, debugging applications based on SOAP is much easier because reading XML is easier than reading a binary stream of raw numbers. And because all the information in SOAP is in text form, SOAP is much more firewall-friendly than IIOP, ORPC, or JRMP (used in Java Remote Method Invocation, or RMI).
• Because it is based on a vendor-agnostic technology, namely XML (and HTTP), SOAP appeals to all vendors including Microsoft, Sun, IBM, and others.
• Recognizing the fact that SOAP is text-based and thus by definition verbose, communications using binary protocols such as IIOP will in almost all cases outperform those that use SOAP as the underlying protocol.