The actual persistence in the SQL Server database is executed by the updateBalance private method that receives the speaker's total reimbursement. This method is nothing new for developers who use ADO.NET. What's far more interesting is to see how the application calculates the reimbursement. The sum of the overall expenses is retrieved by means of a simple Iterator on the expenses array of integers, whose elements are cast at Decimal, plus a fixed amount (DollarsForPresent) for each speaker. The number of participants is a little unrealistic, since it amounts to more than 10,000 times the planet's population, but the use of a BigDecimal, a native Java type that requires using the java.math directive, is an excellent way to demonstrate Grasshopper's integration potential at the code level.

To convert generalExpenses from a .NET Decimal to a Java BigDecimal, we'll use PrimitiveTypeUtils.DecimalToBigDecimal, a helper method provided by Grasshopper and available in the vmw.common namespace (subject to using), once we add the J2SE.Helpers.jar classes among the project references through Add Java Reference. This kind of conversion would be quite difficult to achieve if we chose to integrate .NET and Java applications using Web Services.

The number of participants and remuneration per person are retrieved respectively by the TextBox of the Wizard control and by an internal variable, since the BigDecimal builder accepts either a String or an int. At this point, we carry out "simple" arithmetic operations on large numbers via the BigDecimal multiply and add methods, invoke the persistence method in the database, and memorize the values input in the Wizard controls through as many Session variables.

The application's last page, Review.aspx, lets us simply verify the persistence of the remuneration in the database as well as verify that the Session variables have been assigned their values. Having pressed the Finish button of the Wizard control, after the execution of the method associated to the FinishButtonClick event, we're redirected automatically to this page, as long as it's been specified as a value in the FinishDestinationPageUrl property of the Wizard control.

Let's retrieve the speaker's balance on the Page_Load of Review.aspx event as shown in Listing 4 and show it to the user in a Label, as well as retrieve the values in the Session variables code.

The Speaker's Account Report & the GridView Control
Last, we'll use the GridView control to generate the speaker's current account report, in other words the contents of the Accounts table, which will be shown in the BalancesReport.aspx page. Add it to a GridView control, personalize graphical aspect as usual, choose the database Accounts table as a data source for the control using the Data Source wizard, and select the Enable Paging and Enable Sorting checkboxes. There's nothing else to do - the reporting page is ready (see Figure 8).

What's Grasshopper without Linux?
Now that our application is ready, we can deploy it on a Linux machine. First, we need to create the deployment package, which is as easy as switching your configuration from Debug_Java to Release_Java. By default, the deployment method in the Release configuration is set to Full deployment package (WAR) and creates a production-ready WAR deployment package. Our WAR file is created under the bin directory, JDExpenses\bin\JDExpenses.war, and is 22MB big, since it contains all the Grasshopper Framework libraries. When you deploy several applications on the same server, you would probably prefer to move the Framework libraries to the shared classpath.

To run the application on Linux, Tomcat must be installed; in all likelihood we'll also have to make some small changes. By default, almost all Linux distributions use a version of Tomcat featuring JDK 1.4.2; however, we developed the JDTravel class using JDK 1.5.0, and we so need to install it and configure the application server to suit. From the Sun download site (http://java.sun.com), download JDK 1.5.0 for Linux (the version with the .bin extension) and install it on the machine by launching the file. If it's installed in /opt/jdk1.5.0_06, on most Linux installations it will be sufficient to change the JAVA_HOME variable to suit, before launching Tomcat, with:

export JAVA_HOME=/opt/jdk1.5.0_06

To avoid having to carry out this procedure before each run, we have to modify the Tomcat launching script. In the case of Red Hat Linux, the featured Tomcat version offers a simpler and faster method by opening the /usr/share/tomcat5/conf/tomcat5.conf file and modifying the JAVA_HOME row.

Copy the WAR package on the Linux machine - for example, through a Samba share - and deploy it using the Tomcat Manager. To access Tomcat Manager, we have to create a user for the manager role in /usr/share/tomcat5/conf/tomcat-users.xml. Since we'll use the SQL Server, copy the corresponding JDBC driver, sqljdbc.jar, from <Mainsoft_install_dir>\java_refs\jdbc in Windows to /usr/share/tomcat5/common/lib in Linux and restart Tomcat. Launching the application results in JDExpenses running on Linux (see Figure 9), with the report of the speakers' balances populated by SQL Server 2005.

Now that our application has been deployed on Linux, we can use the remote debugging capabilities offered by Grasshopper and track our Linux application runtime from the Visual Studio debugger windows. First, configure the Tomcat instance running on Linux for debugging. To do that, suspend Tomcat, if it's running, and type the following commands in a prompt:

set JAVA_HOME=<jdk_install_dir>
set JPDA_ADDRESS=8019
set JPDA_TRANSPORT=dt_socket
cd <tomcat_install_dir>\bin
catalina.bat jpda start

Back in Visual Studio, right-click the project name in Solution Explorer and choose Properties. A new page will open with several project configurations. Click the Web tab and. As shown in Figure 10, specify:
•  The IP address of the remote machine (select the checkbox in Start action)
•  The debug port number that you specified in the JPDA_ADDRESS value.

The last thing to do is to start the SQL Server Browser service, which is used by the Grasshopper runtime to locate the SQL Server Express database by the IP address you specified in the connection string and connect to it. To make sure that the SQL Server Browser service is running, launch the Computer Management again, expand Services and Applications, and then click Services. In the list of services, double-click SQL Server Browser, and in the SQL Server Browser Properties window, click Start.

Now, we add a breakpoint in the specified page and start the remote application, performing all the steps needed to reach the page with the breakpoint. The Grasshopper debugger will stop the execution at the row you designate (see Figure 11).

Conclusion
Now you know what Java developers learned during JavaDay: Grasshopper 2.0 makes it easy for ASP.NET 2.0 developers to extend .NET development skills to cross-platform development. We can operate inside Visual Studio 2005, use advanced ASP.NET 2.0 controls, and debug on both the local and production machines. Grasshopper produces a deployment package that requires little configuration, and minimal know-how, to deploy on a non-Windows platform. We only had to take care of a few particular aspects (e.g., using SQL Server 2005 from a non-Windows platform) and we added just two lines of code that are different from what we would have for a "traditional" ASP.NET 2.0 project. The Apache Derby-based pure Java database and Grasshopper Site Administration Tool offer a true Visual Studio-like experience that uses advanced features such as role-based Membership. On the other side, integration at the code level offers easy-to-use porting and delivers a level of performance that would be difficult to achieve using "traditional" Web Services.