VisualAge Integration for the 21st Century: Smalltalk, Java, WebSphere

White paper


VisualAge Smalltalk Version 5.0 includes enhancements and new features that facilitate using existing applications in an e-business environment. This article presents several interoperability techniques between Smalltalk and Java™ so that you can publish existing Smalltalk application logic through WebSphere. This allows you to leverage the power of the IBM Framework for e-business.


VisualAge Integration for the 21st Century: Smalltalk, Java, WebSphere

Jeanette Deupree and Mark Weitzel
IBM Corporation

Never before has the world waited with such anticipation and anxiety over the turning of the clock. For several years now, the computer industry has been concerned with what will happen at midnight on December 31, 1999. But what happens after that? Software developers and architects around the globe, with different backgrounds and skills, are focusing their efforts on e-business. After the Y2K transition, the future of computing -- and the future of businesses everywhere -- is e-business.

Beyond the concerns for making sure applications will survive the turning of the clock out of the twentieth century are serious issues for how organizations will conduct business in the twenty-first century. Moving existing enterprise applications to the Web and accessing data that has been developed over years of hard work are major focus areas. VisualAge Smalltalk Version 5.0 gives you the power to achieve these two goals.

VisualAge Smalltalk Version 5.0 includes enhancements and new features that facilitate using existing applications in an e-business environment. This article presents several interoperability techniques between Smalltalk and Java™ so that you can publish existing Smalltalk application logic through WebSphere. This allows you to leverage the power of the IBM Framework for e-business.

Java and Smalltalk Interoperability with WebSphere

The IBM Framework for e-business emphasizes leveraging existing business resources. VisualAge Smalltalk folds into this framework by providing several ways to Web enable new or existing components. The first approach uses a Web Connection servlet to route requests into Smalltalk parts. The second approach uses Java Remote Method Invocation (RMI) to converse between Smalltalk and Java virtual machines.

A core design principle behind each approach is to enable VisualAge Smalltalk users to follow the IBM Framework for e-business development model. Together, Smalltalk's flexible modeling environment and WebSphere's powerful application server facilitate the rapid deployment of existing resources to the Web.

Using Web Connection With WebSphere

A common way for Smalltalk organizations to introduce WebSphere and Java is to use VisualAge Smalltalk's Web Connection feature. Web Connection couples HTML page creation with the VisualAge Smalltalk visual programming model, letting users visually connect Smalltalk model parts to HTML tags. By using this familiar visual development technique, Web Connection users can quickly leverage WebSphere's strengths by simply deploying a servlet that ships with Smalltalk Version 5. This servlet is a 100% pure Java alternative to using the CGI or Web-server-specific interfaces.

More important, existing Web Connection applications can use this interface with little or no re-architechting. Existing applications can use features that are not normally available to them, such as secure sockets. You can route requests through WebSphere into Smalltalk via the Web Connection servlet interface, allowing you to take advantage of the secure socket layer and other capabilities of WebSphere.

Using RMI to Interoperate with Java and Smalltalk

VisualAge Smalltalk Version 4.5 supported Java interoperability through Server Smalltalk using Java RMI, the Java standard for communicating with distributed objects. Version 5.0 includes enhanced RMI support with a wizard that helps generate the Java to Smalltalk mapping definitions.

There are three basic techniques for using RMI to interoperate with Java and Smalltalk:

  • Copying Smalltalk objects to Java
  • Using stubs in Java to represent Smalltalk objects
  • Wrapping a Java stub to create a smart proxy for a Smalltalk object

Each technique has its own advantages and is discussed below. Which one you use depends on the application and the nature of the conversation between Java and Smalltalk.

Copying Smalltalk Objects to Java:

The most direct approach for using Smalltalk objects in Java is to copy the object into the JVM. Smalltalk model objects used this way are passed by value into Java.

From a Smalltalk perspective, this means that you serialize the instance of the object and send it over the network. The JVM then deserializes the byte stream and creates an instance of the corresponding Java class. At this point, you no longer need to keep the instance around in Smalltalk, so it's available for garbage collection. Because an instance of the object now exists in two distinct virtual machines, you may need to maintain state and behavior in both Smalltalk and Java.

One common use of this model is for read-only objects. For example, you create an object in Java and pass it to Smalltalk for validation. No changes are made to the instance in Java, so having a copy of the object is acceptable. However, if you make changes to the instance in Java, you must get the corresponding object reference in Smalltalk and apply the changes to the Smalltalk object.

Creating Java Stubs for Smalltalk Objects

Using RMI, a model object can reside only in Smalltalk with a stub representation in Java. All messages are forwarded through the stub to the object in Smalltalk. This is referred to as passing the object by reference, because it appears to the Java object that it is working directly with a local object reference. In this scenario, all object state is maintained in Smalltalk. Because of the heavy interaction between Java and Smalltalk, this model should be used only when RMI calls are inexpensive and the information being transferred can be marshaled quickly.

Be wary of the "ping-pong" effect, which occurs when a remote message is invoked for every attribute in an object. This results in many remote calls to retrieve individual pieces of an object, rather than one call requesting a bundle of related information that may contain several objects.

One way to avoid the "ping-pong" effect is to create facades. A facade encapsulates an object, accepts one request, and then returns multiple attributes.

Wrapping Java Stubs

Advanced implementations can use a combination of both techniques mentioned above by wrapping the Smalltalk stub in a Java object. These Java objects can do much more than just forward messages. The objects that wrap the stubs to the remote objects are called proxies. Using this model of Smalltalk and Java interoperability with WebSphere provides the greatest amount of flexibility to rapidly Web-enable existing Smalltalk business models.

Proxies provide more flexibility, because you can add behavior that complements your Smalltalk model. A typical use for proxies is to cache values received from a remote call, increasing performance and reducing network traffic. For example, a BankAccount instance could cache its current balance after a transaction for later use by the application.

Other uses of this technique could involve lazy initialization policies where information is obtained via RMI calls only when necessary. In addition, this model lets you perform pre-call and post-call processing. For example, to access existing Smalltalk business models through WebSphere, you can use a servlet as the stub wrapper. The servlet then directs its output to a JavaServer Page (JSP) which provides the dynamic Web content.

Mapping Between Smalltalk and Java

So you've decided to use RMI to communicate between Java and Smalltalk. Now you need to map your Java classes in Smalltalk using the RMI Wizard. The wizard automates the process of creating the required methods in Smalltalk and generates the necessary Java classes and interfaces. The first step in this process is to decide which Smalltalk classes will be made available to Java, and then decide how the object will be used in Java: by value or by reference.

To use objects by value, the underlying marshaling mechanism that Smalltalk RMI supports is Java object serialization. Therefore, all Java objects that will be used by value must implement the interface.

When using the RMI wizard, first map your Smalltalk class to its Java counterpart. Then, specify which Java interfaces your Smalltalk class implements. When you specify that your class implements the java.rmi.Remote interface, you are telling the RMI Wizard that instances of your class use a Java stub to reference a Smalltalk object. Conversely, when you specify that your class implements java.lang.Serializable, you are specifying that instances of this class will be 'copied' into Java by value.

Regardless of how you expose your Smalltalk models, when you are finished, you have a set of 100% pure Java objects that are available to the WebSphere Application Server. Because WebSphere servlets and JSPs manage view-centric logic, this allows users to access existing Smalltalk application logic regardless of the client device.

Using Smalltalk Objects by Value

When passing a Smalltalk object into Java by value, follow four simple steps.
1. Create the class in Java
2. Create the corresponding class in Smalltalk.
3. Use the tools provided with VisualAge Smalltalk to import the Java mapping definition.
4. Confirm that the mapping is correct, and let the tool generate the proper methods in the Application and Smalltalk classes.

By following these steps, you reduce the likelihood of errors, because the Java Serialization UID and public instance variables will be mapped automatically, and all the methods will be generated in the proper place. Below is a sample of the mapping for the ATMCard in the Application instance that contains the Smalltalk class to be passed by value.

(#class 'rbi.rmi.samples.atm.ATMCard' 'java.lang.Object' #ATMCard
-6690088125205169385 ##nil
(('fieldCardNumber' 'Ljava.lang.String;' ##nil ##nil) ('fieldPin' 'Ljava.lang.String;' ##nil ##nil))

Below is a partial listing of the class created in Java. Because the object is passed by value, the instance variables reside inside Java and are returned without an RMI call.

package rbi.rmi.samples.atm;
* This type was created in VisualAge.
public class ATMCard implements Serializable {
protected transient java.beans.PropertyChangeSupportpropertyChange;
private String fieldCardNumber = new String();
private String fieldPin = new String();
* ATMCard constructor comment.
public ATMCard() {
* Gets the cardNumber property (java.lang.String) value.
* @return The cardNumber property value.
* @see #setCardNumber
public String getCardNumber() {
return fieldCardNumber;

Using Smalltalk Objects by Reference

To use a Smalltalk a object by reference, there must be a remote stub in Java. The stub is the local reference in Java to the remote Smalltalk object. The stub must be a subclass of java.rmi.server.RemoteStub and must implement the interface java.rmi.Remote. The stub acts as the proxy for the remote object. When an object invokes behavior on the stub, the message and its parameters are marshaled over the wire to the remote object. In this manner, conversing with a stub is no different from messaging to any other Java object.

When objects are passed by reference, the Smalltalk RMI Wizard must know about methods instead of instance variables. Type information is still critical, and must be specified for the return value and parameters. However, when the mapping definitions are created, two methods are generated, one for the stub and one for the implementation. For example, below is the method that is the map for the BankAccount class. Since this class will be a stub in Java, having a Java class is not technically necessary. However, the class definition must still be mapped so Smalltalk can resolve the types when marshaling the object. The map follows much the same format as the ATMCard, except that methods are mapped instead of instance variables.

(#class 'rbi.rmi.samples.atm.BankAccount' 'java.rmi.server.UnicastRemoteObject' #BankAccount ##nil
('rbi.rmi.samples.atm.BankAccountIf' 'java.rmi.Remote'))
(#accountType 'getAccountType()Ljava.lang.String;' ('java.rmi.RemoteException'))
#getBalance 'getBalance()Ljava.lang.String;' ('java.rmi.RemoteException'))
(#withdraw: 'withdraw(Ljava.lang.String;)V' ('java.rmi.RemoteException'))

The second method maps the Java stub. This corresponds to the class rbi.rmi.sample.atm.BankAccount_Stub.

(#class 'rbi.rmi.samples.atm.BankAccount_Stub' 'java.rmi.server.RemoteStub' #SstRmiGenericStub
-251696126856499754 ##nil
('rbi.rmi.samples.atm.BankAccountIf' 'java.rmi.Remote'))

The Wizard can also generate the actual stub and the remote interface to be imported into Java. Below is the class declaration and an example of an accessor method that makes an RMI call against its remote reference. The class is defined as public final, which conforms with the Java specification for RMI stubs. Information is obtained when a method is invoked.

package rbi.rmi.samples.atm;
// Stub class generated by rmic, do not edit.
// Contents subject to change without notice.
public final class BankAccount_Stub
extends java.rmi.server.RemoteStub
implements rbi.rmi.samples.atm.BankAccountIf, java.rmi.Remote
private static java.rmi.server.Operation[] operations = {
new java.rmi.server.Operation("java.lang.String getAccountType()"),
new java.rmi.server.Operation("java.lang.String getBalance()"),
new java.rmi.server.Operation("void withdraw(java.lang.String)")

private static final long interfaceHash = -199564707227487162L;

// Constructors
public BankAccount_Stub() {
super ();
public BankAccount_Stub(java.rmi.server.RemoteRef rep) {
super (rep);
// Methods from remote interfaces

// Implementation of getAccountType()Ljava.lang.String;
public java.lang.String getAccountType() throws java.rmi.RemoteException {
int opnum = 0;
java.rmi.server.RemoteRef sub = ref;
java.rmi.server.RemoteCall call =
sub.newCall((java.rmi.server.RemoteObject)this, operations, opnum, interfaceHash);
try {
} catch (java.rmi.RemoteException ex) {
throw ex;
} catch (java.lang.Exception ex) {
throw new java.rmi.UnexpectedException("Unexpected exception", ex);
java.lang.String $result;
try { in = call.getInputStream();
$result = (java.lang.String)in.readObject();
} catch ( ex) {
throw new java.rmi.UnmarshalException("Error unmarshaling return", ex);
} catch (java.lang.ClassNotFoundException ex) {
throw new java.rmi.UnmarshalException("Return value class not found", ex);
} catch (Exception ex) {
throw new java.rmi.UnexpectedException("Unexpected exception", ex);
} finally {
return $result;

Mapping Java exceptions and interfaces follows similar steps. Samples of each type can be found in the ATM RMI Example and because of the procedural similarities it is not necessary to demonstrate them here.

Conclusion: Empowering Your Business for the 21st Century

The business landscape is constantly reshaping itself. To keep up with these changes, you need a proven technology and solid development tools. The VisualAge family provides these tools. VisualAge Smalltalk paired with VisualAge for Java provide a strong solution to move your business into the 21st century.

VisualAge Smalltalk remains a premier OO modeling tool for mission critical applications that have rapidly changing business requirements. When VisualAge Smalltalk and VisualAge for Java are combined with WebSphere, you can specialize development resources, quickly leverage existing business assets, and deploy new applications faster. Together, these three products can speed your transition to e-business and give you competitive advantage.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries.

Other company, product, and service names may be trademarks or service marks of others.

IBM copyright and trademark information

Related information

VisualAge Smalltalk Teams with Java and WebSphere to Wi

Rate this page:

(0 users)Average rating

Add comments

Document information

More support for:

VisualAge Smalltalk

Software version:

5.0, 5.0.1

Operating system(s):

AIX, HP-UX, OS/2, Solaris, Windows

Software edition:


Reference #:


Modified date:


Translate my page

Machine Translation

Content navigation