Determining Whether jCOM Is a Good Fit for Your Application

Tying Microsoft and Java platforms together is no small feat by any means. The jCOM runtime engine as bundled with BEA WebLogic Server 8.1 comes as a welcome addition to a platform already rich in connectivity options. When dealing with COM/Java interoperability issues, it should fit nicely into the integration requirements of many applications. It isn't the only option you have at your disposal, though.

Other forms of middleware exist to assist you in your efforts to glue things together. Web Services come quickly to mind, as does the J2EE Connector Architecture (J2EE-CA), which can play a role. Initiatives coming out of .NET could be drawn upon, too. It's beyond the scope of this chapter to go into any of these alternatives in too much detail but they do bear mentioning—especially in the context of determining whether a solution makes sense in relation to all the other things that might be going on in the enterprise. For additional information about Web Services, refer to Chapter 30, "WebLogic Server and Web Services." For J2EE-CA, see Chapter 31, "Legacy Integration with the J2EE Connector Architecture."

It's also worth noting that the J-Integra product as shipped from Intrinsyc has a plug-in available called the J2EE-CA/COM Bridge, which does its bridging via the J2EE Connector Architecture. Using the J2EE Connector Architecture paradigm, you could write your own resource adapters for your EJBs and have them serviced by the J2EE-CA/COM Bridge plug-in sitting on top of the J-Integra runtime engine. The J2EE Connector Architecture promises to add value by not compromising the portability of EJBs across platforms. For example, if you have a mixed application server environment (possibly with WebSphere or Oracle application servers) used in conjunction with WebLogic and need to port EJBs across these platforms, a closer look into a J2EE Connector Architecture–enabled solution might be in order.

Then there is the whole Web Services phenomenon to consider. The rapid adoption of Web Services, based on least common denominator protocols such as XML and HTTP, is quickly becoming as pervasive as the Internet itself. Web Services are implemented via SOAP (Simple Object Access Protocol). This protocol is formulated by Microsoft and is an integral part of its latest product strategy, including the new technologies to supersede COM. So, that makes it all the easier to access Microsoft Web Services–enabled COM legacy applications in this manner. In a nutshell, XML ties together data where DCOM ties objects. If your application is an enterprisewide one or is geographically dispersed, Web Services will make deploying and maintaining the application much easier. However, Web Services will probably be slower than DCOM, given the marshaling of objects to verbose XML on one end, transferring large chunks of data on the network, and having to interpret them through an XML parser on the other. Although Microsoft is clearly behind Web Services and the use of SOAP to expose normal COM calls over the network, it in no way sees SOAP as a general replacement for DCOM. COM components with complex data types may require the creation of wrapper objects and custom mappers to expose these objects. Many DCOM features such as life-management and passing objects by reference, and some COM data types, don't map to the current SOAP specification and by Microsoft's admission probably never will.

Intrinsyc also has a product called Ja.NET that allows clients for Enterprise JavaBeans using .NET-supported languages. Integration with ASP.NET and EJBs is available as well. It is supported under BEA WebLogic Server and can be used if you have .NET-specific dependencies in your application.