Interoperability with Other Technologies

I l @ ve RuBoard

You've seen how Microsoft provides tools that allow you to build applications in J# (and other .NET-supported languages) that can interoperate with components created using other technologies. However, Microsoft has concentrated on defining mechanisms for communicating between components built and running using Microsoft's own infrastructure ”primarily because this is what Microsoft knows best and because so many other technologies are out there that it would be impossible for Microsoft to provide interfaces to them all. This state of affairs also leads to a healthy market for third-party integration tools, so it should be seen as an opportunity rather than a shortcoming on Microsoft's part.

However, at times you'll need to integrate with other systems. In the Java arena, this will primarily involve communicating with J2EE servers running Enterprise JavaBeans (EJBs) and services running under CORBA. Depending on your level of ingenuity and what you're willing to spend on third-party software, a number of solutions are available, including (in no particular order):

• Using a COM/CORBA bridge. The Object Management Group (OMG), recognizing the ubiquitous nature of COM on Windows, has defined a mechanism for COM/CORBA interworking. A number of vendors have produced COM/CORBA bridging middleware based on this mechanism. You can use COM Interop to access bridging components from .NET.

• Using a COM/J2EE bridge. You can use CORBA as a stepping stone to a J2EE server, but method calls have to pass through several layers of software to reach their destination. Internally, J2EE clients and servers communicate using RMI. Although RMI is not directly supported by J#, the specification of the wire protocol is freely available. (See http://www.java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmi-protocol.doc.html.) The protocol is based on HTTP and Java Object Serialization. Commercial products are available that will translate from the protocol used by COM to RMI. Once again, you can access these components from .NET through COM Interop.

• Building a .NET/J2EE bridge. If you're feeling brave, you can implement your own custom serialization mechanism along with your own Remoting protocol to communicate with an RMI server. Remember that the architecture of these two aspects of the .NET Framework are highly customizable for just such situations. This solution is more direct than using COM and should yield better performance.

  Note

  Microsoft itself uses a similar approach for interoperating between .NET and COM+. See Chapter 14 for details.

  
  

• Using an MSMQ connector. J2EE defines its own message queuing infrastructure in the Java Messaging Service (JMS). JMS is an integrated part of the J2EE specification and can be used to communicate with EJBs. The available MSMQ connectors allow you to combine MSMQ and JMS. Or, if you prefer, you can use the JMS service provider for MSMQ.

• Taking advantage of .NET cross-language interoperability. For example, even though no tools are available that implement J# language bindings for CORBA, there are plenty for C++. You can combine managed and unmanaged C++ fairly seamlessly using Visual Studio .NET, and you can create managed C++ components that act as bridges to CORBA and that you can integrate with J#.

• Using a low-level networking solution, such as sockets. Nothing will stop you from building applications in J# that send and receive data using sockets. Indeed, the .NET Framework Class Library provides good coverage of sockets ”see Chapter 8 for details. Most operating systems have intrinsic support for sockets, and it is relatively easy to establish a connection to a process that's listening on an endpoint if you know the address to use and have the appropriate access rights.

The Real Solution: XML Web Services

The list in the previous section was intentionally short on details. These days, if you ask any of the major software and platform vendors about the best way to integrate disparate systems of varying architecture, you'll get the same answer: Use XML Web services.

In the final chapters of this book, we'll cover XML Web services as implemented by the current release of .NET, so we won't go into much detail here. The major computing platform vendors are often at each other's throats, so when they all agree on something it is a significant event. Such is the case with Web services. Based on XML and HTTP, the fundamental Web service architecture is platform neutral and vendor independent. Before we get too carried away, though, be warned that the Web services available now are not the finished article ”they're merely a good starting point. For example, Web services do not provide much support for transactions, security, remote events, and so on. (Some vendors provide implementations of these features, but they are by no means accepted across the board.) The next step is the Global XML Web Services Architecture (GXA). Microsoft, along with other vendors and organizations, is working to define a series of standards that cover the requirement to implement high-performance, distributed, fault-tolerant messaging across heterogeneous networks. If you want more information about GXA, a good starting point is the paper published by Microsoft at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngxa/html/gloxmlws500.asp.

I l @ ve RuBoard