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