Microsoft Client Applications and

Enterprise JavaBeans:Can’t We All Just Get Along?

Kurt ChristensenSoftware EngineerSeleriti Corporationkurtc@seleriti.com

John ValesanoSoftware EngineerSeleriti Corporationjvalesano@seleriti.com

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

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

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

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

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

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.

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)

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

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?

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

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?

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.

The Attack Initial try: simple Java client

packaged as a COM DLL using Visual J++

Small problem: this doesn’t work!

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

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

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

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

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

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

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:

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

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)

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

VB/CORBA/EJB Since EJBs are accessed via RMI-

IIOP, we can use a CORBA client:

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

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

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

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)

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.

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:

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.

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

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

VB/Magic Bullet/EJB Certain third-party products can solve

the problem for you:

For example, IBM’s Component Broker

VB/Magic Bullet/EJB: What’s Right

Good products can simplify development

Performance might be better than with some homegrown solutions

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

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?

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

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

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

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

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…

Q & A