Microsoft Client Applications and Enterprise Java Beans Cant

Microsoft Client Applications and Enterprise Java. Beans: 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

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

The History… Why a middle tier? n n Desire for a business logic middle tier Why? n n n 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

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

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

The Project n Build a web based online trading program. n n n 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

Step One n n 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.

Digressing: VB + EJB? ? ? n n The J 2 EE 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)

Why Are We Stuck With VB? n n n 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

VB/EJB: The Issues n Sun Blue. Prints Design Guidelines for J 2 EE points out three issues: n n Security Client-managed transactions Deployment Issue number zero: What are the communication mechanics between a VB app and an EJB?

VB/EJB: Connectivity n n Information on COM / EJB integration is not overly abundant Why? n n n 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

The Connectivity Pilot Project n n 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?

The Caveat n n 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.

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

VJ++ Proxy: What’s Involved n n n 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

The Retreat n Exactly why can’t we do it the easy way? n n The J 2 EE platform is based on JDK 1. 2 Visual J++ only supports JDK 1. 1 n For example, RMI-IIOP is not supported

The Attack, Part 2 n n n 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

Proxy-Proxy: What’s Involved n n n 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

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

The Proxy-Proxy Solution: What’s Wrong n n Ok, its ugly… Configuration can be a pain: n n 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

VB/JNI/Java Proxy/EJB n 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:

JNI: What’s Involved n n n 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

VB/JNI/Java Proxy/EJB : What’s Right n n n 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)

VB/JNI/Java Proxy/EJB : What’s Wrong n Will Microsoft always support JNI? n n 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 n Requires C/C++ programming skills

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

CORBA: What’s Involved (1) n Generate CORBA IDL interfaces that correspond to your EJB interfaces. Either n n (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

CORBA: What’s Involved (2) n n 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

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

VB/CORBA/EJB: What’s Right n n 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)

VB/CORBA/EJB: What’s Wrong n Must have an ORB on the client n n 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.

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

VB/XML: What’s Involved n n 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.

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

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

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

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

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

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

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

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

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

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

Conclusion n This issue is disappearing, slowly but surely: n n J 2 EE platform is gaining in popularity J 2 EE 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…

Q&A