Microsoft Client Applications and Enterprise JavaBeans: Can’t We All Just Get Along?

1. Microsoft Client Applications and Enterprise JavaBeans: Can’t We All Just Get Along? Kurt Christensen Software Engineer Seleriti Corporation kurtc@seleriti.com John Valesano Software Engineer Seleriti Corporation jvalesano@seleriti.com

2. The Agenda • Historical Perspective • Visual Basic EJB Integration Options • 1. Visual J++ COM Proxy • 2. JNI COM Proxy • 3. CORBA COM Proxy • 4. XML-RPC • Code Samples • Visual J++ COM Object • SOAP and XML-RPC

3. The History… Why a middle tier? • Desire for a business logic middle tier • Why? • Web client and internal VB client produced inconsistent (financial) data • Expansion into online trading would only exacerbate the problem • Code maintenance was already a growing concern due to multiple algorithms and mediocre design

4. The History… Why EJBs? • JAVA!!! • Increased productivity and reliability based on pilot project results. • IBM Mainframe shop • Single vendor solution from IBM • Integrated development tool for an end to end solution. • Easier and better designed than MTS

5. The History… Where were we? • Local Brokers • VB >> COM/C++ >> CICS/Mainframe • Remote Brokers • Citrix Server to access the VB app • Web Clients (Customer Account Info) • ASP >> JAVA >> CICS/Mainframe

6. The Project • Build a web based online trading program. • Use EJBs for the business logic middle tier • Use a Java type solution for the front end • Demonstrate the feasibility of integrating the new EJB application with the existing (VB) client broker apps and (ASP) customer apps

7. Step One • We were charged with demonstrating the feasibility of connecting the existing VB broker app with the proposed EJB business object middle tier. • Note: for political reasons this was a very important (crucial) first step.

8. Digressing: VB + EJB??? • The J2EE application program model recommends a thin client tier (JSPs) • The reality: many companies still have client applications based on Microsoft technologies (usually Visual Basic, could also be Visual C++ or Active Server Pages)

9. Why Are We Stuck With VB? • End users may not want to learn a new application • VB apps often have more responsive GUIs • Management may not want to throw away their investment in VB apps • VB programmers may not want to give up their jobs or learn a new language • New technologies might have to be phased in over time

10. VB/EJB: The Issues • Sun BluePrints Design Guidelines for J2EE points out three issues: • Security • Client-managed transactions • Deployment • Issue number zero: What are the communication mechanics between a VB app and an EJB?

11. VB/EJB: Connectivity • Information on COM / EJB integration is not overly abundant • Why? • New technologies make this a new problem • Corporate politics: Sun says “use JSPs!”; Microsoft says, “use MTS!” • VB programmers use VB, Java programmers use Java

12. The Connectivity Pilot Project • Create a simple VB application that communicates with an EJB server. • We know we need some sort of proxy between our client app and the EJB server… but what?

13. The Caveat • Out task was to demonstrate connectivity i.e., that the new EJB objects could be accessed by the existing VB apps • Consequently, we did not have to deal with real-world issues associated with transactions and security.

14. The Attack • Initial try: simple Java client packaged as a COM DLL using Visual J++ • Small problem: this doesn’t work!

15. VJ++ Proxy: What’s Involved • Create the necessary class in Visual J++ • In your Visual J++ project settings, export your class as a COM object, and package your output in a COM DLL • Access your new COM object from VB, just like any other COM object

16. The Retreat • Exactly why can’t we do it the easy way? • The J2EE platform is based on JDK 1.2 • Visual J++ only supports JDK 1.1 • For example, RMI-IIOP is not supported

17. The Attack, Part 2 • Adding a second proxy object achieves the objective: • It may be ugly, but it works… • Note: Visual J++ does not ship with RMI, it must be downloaded from Microsoft

18. Proxy-Proxy: What’s Involved • Save a copy of your Visual J++ code; this is the second proxy that will run on a Sun (or IBM or whatever) JVM • Modify this class to be an RMI server • Modify the original Visual J++ code so that all method calls delegate to the corresponding methods on the second proxy via RMI • Use Visual J++ to package this latter class as a COM DLL • Access your new COM object from VB, just like any other COM object

19. The Proxy-Proxy Solution: What’s Right • It may be ugly, but it’s not as ugly as you think: • Performance compares somewhat favorably to other solutions • Proxy objects are thin and simple; can be automatically generated • Thin + simple = easy to understand

20. The Proxy-Proxy Solution: What’s Wrong • Ok, its ugly… • Configuration can be a pain: • Must set up the MS JVM to use RMI • Multiple VMs from different vendors on each client machine • Microsoft could pull the plug on Java support • Performance may not be acceptable, (multiple) remote calls are expensive

21. VB/JNI/Java Proxy/EJB • Instead of using the MS JVM to present our proxy as a COM object, we can wrap our proxy with a COM DLL using JNI:

22. JNI: What’s Involved • Similar to the first (failed) solution, but adding a JNI wrapper written in C++ that delegates methods calls to the original Java object • Present the JNI wrapper as a COM object (the ATL wizard in Visual C++ can be useful here) • Access your new COM object from VB, just like any other COM object

23. VB/JNI/Java Proxy/EJB : What’s Right • It’s a more elegant solution… • Performance is better than proxy-proxy (a remote call was eliminated; the need for a second VM was eliminated) • Proxy object generation can be very simple (possibly even automated)

24. VB/JNI/Java Proxy/EJB : What’s Wrong • Will Microsoft always support JNI? • It took a court decision to force Microsoft to replace their proprietary native interface with JNI • Perceived/real complexity of JNI could make it difficult to find programmers to develop or maintain the infrastructure • Requires C/C++ programming skills

25. VB/CORBA/EJB • Since EJBs are accessed via RMI-IIOP, we can use a CORBA client:

26. CORBA: What’s Involved (1) • Generate CORBA IDL interfaces that correspond to your EJB interfaces. Either • (a) Write the IDL yourself, or • (b) Use the RMI-IIOP RMIC compiler with the –IDL option to automatically generate IDL files from your EJB interfaces

27. CORBA: What’s Involved (2) • Use your ORB’s IDL compiler to generate stubs and skeletons for each of your IDL files • Note: Your IDL compiler will probably not work if the ORB does not support CORBA 2.3

28. CORBA: What’s Involved (3) • Implement your CORBA client code • Make your CORBA client available as a COM object. Two options: • Do it yourself (the ATL wizard is handy here…) • Use a third-party COM/CORBA bridge (such as OrbixCOMet from Iona) • Access your new COM object from VB, just like any other COM object

29. VB/CORBA/EJB: What’s Right • Performance is relatively good, only one remote method call is required • If developers are familiar with ATL, or a particular COM/CORBA bridge, COM object generation can be very simple (possibly even automated)

30. VB/CORBA/EJB: What’s Wrong • Must have an ORB on the client • Client configuration • Expense? • Perceived/real complexity of CORBA could make it difficult to find programmers to develop or maintain the infrastructure • Management’s reluctance to simultaneously take on two new technologies: EJBs and CORBA.

31. VB/XML over HTTP/EJB • The VB app can exchange data with EJBs via XML over HTTP, using servlets and/or JSPs as the intermediary:

32. VB/XML: What’s Involved • COM proxy object to hide the XML/HTTP details from the VB programmer. • Client side XML parser • Server side XML parser • Protocol to translate an XML document into a method call or return value.

33. VB/XML over HTTP/EJB: What’s Right • Provides the greatest decoupling between client and EJB server: • Uniform layer of abstraction for both internal and external clients • Greater flexibility to migrate to new technologies for the client (proxy object can be made using anything) • Works well over the Internet

34. VB/XML over HTTP/EJB: What’s Wrong • XML parsing increases overhead • XML parsing and message handling add complexity • No remote object references! (At least not without a lot of work…) • Basically a stateless protocol

35. VB/Magic Bullet/EJB • Certain third-party products can solve the problem for you: • For example, IBM’s Component Broker

36. VB/Magic Bullet/EJB: What’s Right • Good products can simplify development • Performance might be better than with some homegrown solutions

37. VB/Magic Bullet/EJB: What’s Wrong • Learning curve can be steep; may not be any simpler than doing it yourself • Vendor lock-in • Can be too costly

38. Performance Considerations • If its not worth measuring, its probably not worth optimizing • How much performance do you need? • Where is the bottleneck? • Database? • EJB server? • Network? • Java VM?

39. Comparing the Alternatives: Performance • VB/MS Proxy/Sun Proxy/EJB • Good enough? • VB/JNI/Java Proxy/EJB • A little better • VB/CORBA/EJB • Better yet • VB/XML over HTTP/EJB • Slower • VB/Magic Bullet/EJB • Varies

40. Comparing the Alternatives: Cost • VB/MS Proxy/Sun Proxy/EJB • Cheap (free!) • VB/JNI/Java Proxy/EJB • Cheap (free!) • VB/CORBA/EJB • Cheap, if ORB client is free • VB/XML over HTTP/EJB • Cheap, except for programming time • VB/Magic Bullet/EJB • Can be very expensive

41. Comparing the Alternatives: Complexity • VB/MS Proxy/Sun Proxy/EJB • Very easy (but ugly!) • VB/JNI/Java Proxy/EJB • Not too bad, IF you know JNI… • VB/CORBA/EJB • Not too bad, IF you know CORBA • Configuration issues, you need a Client ORB • VB/XML over HTTP/EJB • Complicated – many pieces in the puzzle • VB/Magic Bullet/EJB • Potentially complicated – configuration issues

42. Recommendations • VB/MS Proxy/Sun Proxy/EJB • Quick, easy, dirty • VB/JNI/Java Proxy/EJB • If you have the people, you can do it • VB/CORBA/EJB • If you have the people, you can do it • VB/XML over HTTP/EJB • If you need Internet support • VB/Magic Bullet/EJB • If you have the cash, and don’t mind vendor lock-in

43. Conclusion • This issue is disappearing, slowly but surely: • J2EE platform is gaining in popularity • J2EE and CORBA are becoming more friendly • Increasing number of COM/CORBA bridges and COM-friendly app servers • For now, we’re still on our own…

44. Q & A