Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Alternative deployment methods, Part 3: The code

Examine the code and techniques used in an alternative deployment tool

By Todd Sundsted, JavaWorld.com, 09/22/00

  • Print
  • Feedback
.

Page 2 of 2

A step is rendered in this general form:

  <step
 type=[type name]>
[parameter]
    .
    .
    .
</step>


A step's type indicates what action the agent completes. A step can have zero or more parameters that exchange data with the step. Parameters come in three flavors:

  • In: used to pass data to the step
  • Out: used to receive data from the step
  • Inout: used to pass data to and receive data from the step


This arrangement should look familiar if you've used CORBA before.

Consider the following step:

  <step
 type="license">
<in>
This software is Copyright (c) 2000, Todd Sundsted.
Use of this software implies agreement with the terms
of this license.  Yada, yada, yada...
</in>
<out name="license_choice"/>
</step>


This step is named "accept_license" and has two parameters. The first, an in parameter, contains the text of the license agreement. The second, an out parameter, contains the user's response to the license agreement. A variable called "license_choice" stores this parameter. Other steps can access this variable.

When an instance of the LocalDirector class is used as a director, the parameters are placed in an array, and the array is passed from the director to the agent. The agent implements and modifies the array's contents. When the method call returns, the director will have access to the changes made by the agent.

When an instance of the RemoteDirector class is used as a director, the parameters are put in an array that is serialized and passed across the RMI connection. This serialization affects a pass-by copy of the entire array. The agent can still implement and modify the array's contents, but the director cannot see the changes without some extra work.

Here is some typical agent code:

  public
void
performAction(String stringName, Object [] rgobjectParameters) {
.
.
rgobjectParameters[0] = "...";
.
}


The modification of the array's contents will not work when RMI is involved. I introduced the nonpublic AgentProxy class, which works behind the scenes to overcome this problem. Its performAction() method wraps the call to an agent's performAction() method and returns the modified array of objects. It looks like this: 

public Object []
performAction(String stringName, Object [] rgobjectParameters) {
  .
  .
  agent.performAction(stringName, rgobjectParameters);
  .
  .
  return rgobjectParameters;
}


The RemoteDirector instance reads the modified values from the returned array, rather than the parameter array. The client never notices a difference.

About the author

Todd Sundsted has been writing programs since computers became available in convenient desktop models. Though originally interested in building distributed applications in C++, Todd moved on to the Java programming language when it became the obvious choice for that sort of thing. In addition to writing, Todd is a Java architect with ComFrame Software Corporation.

Read more about Tools & Methods in JavaWorld's Tools & Methods section.

Conclusion

You should now have an understanding of the benefits and limitations of applets and other traditional deployment methods, as well as a promising alternative. Based on the nearly simultaneous arrival of many similar solutions, I think it's safe to say that these new techniques will play an ever-increasing role in Java application deployment.

  • Print
  • Feedback

Resources