将 Microsoft 的 Commerce Starter Kit 移植到 Apache Tomcat

引言

如果您熟悉 Visual Studio .NET® 开发环境，那么您可以卷起袖子，在几分钟内使用 Grasshopper —— J2EE™ 的 Visual MainWin® 开发人员版本，创建并调试您的第一个 J2EE 应用程序。

但是，如果要把现有的 .NET 应用程序（例如 Microsoft® 的商业入门套件）移植到 J2EE 呢？

移植到 J2EE 后能否保留原始应用程序的功能？如何在 J2EE 和 .NET 框架应用程序之间管理源代码库？需要多少工作量？Grasshopper 是否能够应对这一挑战？

在您使用 Grasshopper 将 Microsoft 商业入门套件移植到 Apache Tomcat 的过程中，这些问题以及更多问题将得到解答。您将探讨从 .NET 框架应用程序移植到 J2EE 时可能遇到的各种问题。在此过程中，您将了解 Grasshopper 如何解决这些问题，并一窥使其能够实现此类移植的 Grasshopper 模块。

关于商业入门套件应用程序

	图 1. 商业入门套件的 Web 界面。

商业入门套件（以前称为 IBuySpy）被视为展示 ASP.NET 技术特性的参考应用程序，因此它是将实际 ASP.NET 应用程序移植到 J2EE 的一个很好的代表性测试用例。

该应用程序实现了基本的在线购物功能，包括：产品目录、用户身份验证和个性化、购物车以及订单结账。

商业入门套件的设计遵循传统的分布式 Web 应用程序模式，并分为三个逻辑层：

这些是：

• 数据层：通常是一个支持应用程序的关系数据库，封装了事务、记录锁定和用户安全等功能。在本例中，使用了 SQL Server 2000®。
• 中间层：这是检索和丰富数据（包含业务逻辑）的地方，也是处理和准备数据库更新的地方。根据应用程序的不同，它通常是 .NET 框架应用程序、Web 服务、Java Beans™ 或 Enterprise Java Beans (EJBs) 的领域。
• 表示层：这是将数据呈现给屏幕，并封装导航和工作流程的地方。通常使用 ASP.NET Web 窗体或 JSP。

	图 2. 商业入门套件的架构。

您可以在图 2 中看到这些层以及它们在商业入门套件中的应用。

跨越边界进入 J2EE 天地

如果您从未用过 J2EE、Java 或 Tomcat，您可能会感到有些不安，想到那些您的 Java 朋友们经常谈论的 EJB、属性文件和部署描述符的神秘之处！别担心！在使用 Grasshopper 时，您不必担心这些，一旦您完成了这次移植，您将对使用 J2EE 技术拥有出色的第一手经验，并且您将看到它有多么容易。

步骤 1. 通过在线文档准备移植

	图 3. 商业入门套件移植教程。

安装 Grasshopper 后，请查看 Visual Studio .NET 在线帮助，您将找到 Visual MainWin 书籍。打开“教程”书，查找 ASP.NET 商业入门套件教程 [图 3]。

本教程将指导您完成使用 Grasshopper 将商业入门套件移植到 J2EE 所需的逐步过程。教程将向您展示如何操作，而本文档将提供额外的、深入的观察。

步骤 2. 为商业入门套件应用程序生成 J2EE 项目

	图 4. 并排的 J2EE 和 .NET 框架项目。

在安装商业入门套件应用程序并确认它在您的环境中可以在 .NET 框架上构建和运行后，下一步是使用 Grasshopper 的“生成 J2EE 项目”向导为其创建 J2EE 项目。该向导会在您的原始解决方案中，在原始项目旁边创建一个新项目。

花点时间查看 CommerceCSVS.J2EE 项目的引用 [图 4]。有什么有趣的地方吗？

对 'j2ee' 程序集的引用可能让您第一个意识到这不是一个普通的 C# 项目。该程序集暴露了整个 J2EE 运行时类集合，就好像它们只是 .NET 框架的扩展一样！您不会在移植商业入门套件时使用它，但请在心中记下——如果您想直接使用任何 J2EE 类，您可以在这里找到它们。

如果仔细查看，您会注意到新项目包含了 .NET 框架的原始项目中的所有文件。新创建的 J2EE 项目中的所有文件都是原始项目中原始文件的链接。因此，对任一文件的任何修改都会在两个项目中同步更新。该向导会保留原始项目不变，您可以继续使用它来构建 .NET 目标。这样，您就可以维护一个单一的代码库来为两个平台构建您的应用程序！

使用新的 J2EE 项目，您可以执行常规 C# 项目中无法执行的操作，例如从 C# 源代码构建 J2EE 目标、添加 Java 存档 (JAR) 文件引用、调试混合 Java 和 C# 代码，以及直接将应用程序部署到 Tomcat，正如您在移植过程中将看到的。

步骤 3. 构建 J2EE 项目

	图 5. 向导自动创建的 Debug_Java 配置。

构建 J2EE 项目没有什么特别之处，而这正是它的吸引力所在——如果您知道如何在 Visual Studio .NET 中构建 C# 项目，那么您就知道如何构建它的 J2EE 版本。您所要做的就是将活动配置设置为 Debug_Java 配置（该配置由向导自动创建），然后开始构建。构建完成后，您将获得商业入门套件应用程序的 J2EE 版本！您可以在图 5 中使用配置管理器了解如何做到这一点。

但它是如何工作的？点击构建按钮后，后台发生了什么？

要理解这一点，您应该考虑 Grasshopper 如何与 Visual Studio .NET 集成。利用 Visual Studio 可扩展性框架，Grasshopper 会监视您的构建请求。当识别到您希望构建 J2EE 版本时，它会启动其 J2EE 构建代理，该代理会协调 J2EE 构建过程。

首先，您的代码会被编译成标准的 .NET 程序集。在此阶段，编译由 .NET 框架的 C# 编译器执行。如果您的代码能干净地编译为 MSIL，构建将进入下一阶段——生成 Java 字节码。这时有趣的事情就开始发生了。

以“Security.cs”文件为例

using System;
using System.Security.Cryptography;
using System.Text;
using System.Text.RegularExpressions;
 
namespace ASPNET.StarterKit.Commerce.Components
{
   /// 
   /// Summary description for Security.
   /// 
   public class Security
   {
   //*********************************************************************
   //
   // Security.Encrypt() Method
   //
   // The Encrypt method encrypts a clean string into a hashed string
   //
   //*********************************************************************
      public static string Encrypt(string cleanString)
      {
         Byte[] clearBytes = new UnicodeEncoding().GetBytes(cleanString);
         Byte[] hashedBytes =   
   (HashAlgorithm)CryptoConfig.CreateFromName("MD5")).ComputeHash(clearBytes);
                    
         return BitConverter.ToString(hashedBytes);
      }
   }
}  

它所做的只是实现一个非常简单的类——Security，其中包含一个名为 Encrypt 的静态方法。此方法接受一个字符串并返回加密后的字符串。尽管简单，但您可以看出它引发了一些问题。

第一个也是最明显的观察是，这是 C# 代码。它如何变成 Java 字节码？解决这个挑战的关键在于 Grasshopper 的 MSIL 到 Java 二进制编译器。它读取 .NET 框架 C# 编译器创建的 .NET 程序集，并将其代码转换为标准的 Java 字节码——同时保留了移植代码的原始语义！这项正在申请专利的技术使您能够继续用 C# 开发原始应用程序，并在标准的 J2EE 服务器中将其作为纯 Java 应用程序运行！

这解决了 C# 到 Java 的翻译问题，但 .NET 框架类呢？正如您所见，Encrypt 方法创建一个新的 System.Text.UnicodeEncoding 类实例来从输入字符串提取字节，并使用它。然后，它使用 System.Security.Cryptography.HashAlgorithm 类来加密数据，最后使用 System.BitConverter 类将位转换回字符串。这样的代码如何在 J2EE 环境中执行？这些是 .NET 框架类库，不属于您的源代码！

方法如下：利用 Grasshopper 将 C# 代码编译为 Java 字节码的能力，Grasshopper 的 .NET 框架实现基于开源的 Mono™ 类库，并重新托管到 J2EE。结果是，这些类以及更多类都用 Java 实现，并在 J2EE 环境中供您移植的应用程序使用！因此，您的 Java 实现将识别这些类库的 Java 版本，并在 J2EE 环境中执行时使用它们。

此外，在构建过程中，Grasshopper 会解析您的代码，并搜索潜在的移植问题，例如使用 .NET 框架运行时类，这些类在 J2EE 环境中不受支持或仅部分受支持。如果找到任何问题，您将收到包含潜在问题详细信息的警告消息。您可以采取多种方式来处理这些问题。例如，您可以使用条件编译来排除不受支持的代码，不将其包含在 J2EE 构建中（某些功能对 J2EE 版本而言根本不相关），或者您可以重写代码以使用在两个环境中都支持的替代方案。在本例中，商业入门套件的构建成功完成，并带有以下警告：

Compiling Java...
Processing C:\Program Files\ASP.NET Starter Kits\ASP.NET Commerce 
  (CSVS)\CommerceCSVS\bin_Java\ASPNETCommerce.dll...
Validating classes...
Packing files...
C:\Program Files\ASP.NET Starter Kits\ASP.NET Commerce (CSVS)\CommerceCSVS\
     Web.config(16) :warning JC8000: Not Implemented Element 'customErrors'.
C:\Program Files\ASP.NET Starter Kits\ASP.NET Commerce (CSVS)\CommerceCSVS\
     Web.config(10) :warning JC8000: Not Implemented Element 'pages'.
C:\Program Files\ASP.NET Starter Kits\ASP.NET Commerce (CSVS)\CommerceCSVS\
     Web.config(18) :warning JC8000: Not Implemented Element 'sessionState'.
Processing ASP.NET pages...
Converting Global.asax..

这些警告不会影响移植；但是，值得解释一下。所有三个警告都与 Web.config 文件中不受支持的元素有关。在 .NET 环境中，您使用此文件来配置应用程序。在 J2EE 世界中，此类配置是不同的。因为移植的应用程序是一个标准的 J2EE 应用程序，Grasshopper 将 J2EE 应用程序的配置留给管理 J2EE 服务器的人员，使用标准的 J2EE 方法进行配置。

	图 6. Grasshopper 的类库引用

顺便说一句，当使用 Grasshopper 进行移植时，另一个有价值的信息来源是其集成的帮助 [图 6]。

如果您曾使用过 Microsoft Developer Network (MSDN)，您会发现 Grasshopper 类库参考的布局非常熟悉。您可以使用它来快速查找有关您在应用程序中使用的任何 .NET 框架类的 J2EE 实现的所有信息。

完整的 Grasshopper 文档 集也可在 Grasshopper 网站上在线获取。

步骤 4. 将商业入门套件应用程序部署到 Tomcat 服务器。

成功构建 Java 文件后，Grasshopper 将商业入门套件可执行的 J2EE 应用程序打包成 Java Web Archive (WAR) 文件——这是部署应用程序的标准 J2EE 格式，并将其上传到您本地的 Tomcat 实例。

	图 7. 使用解决方案资源管理器查找您的 WAR 文件。

现在，WAR 文件听起来可能是一个复杂、专有的二进制文件，但它只不过是一个具有特定层次结构的 ZIP 文件。如果您想查看它，现在就可以。从 Visual Studio .NET 中，查看解决方案资源管理器，点击“显示所有文件”图标，然后找到“CommerceCSVS.J2EE.war”文件。您可以在 bin_java 文件夹中找到它 [图 7]。

	图 8. 使用 WinZip 探索 WAR 文件。

如果您使用 WinZip 打开此文件，您将看到其内容 [图 8]。

注意到 web.xml 文件了吗？这个文件是 Grasshopper 为您创建的。在 J2EE 世界中，它被称为 **Servlet Deployment Descriptor**。它告诉 Tomcat 服务器有关您应用程序的所有信息。每个标准的 J2EE 应用程序都以这种方式打包，您的应用程序也不例外。

下一步是将 WAR 文件放到您的应用程序服务器上。作为开发人员，您需要在本地应用程序服务器上测试应用程序，并能够反复部署它，直到获得可用于生产的版本。Grasshopper 知道您的项目与哪个应用程序服务器相关联。通过内置的必要知识，Grasshopper 在每次成功完成 WAR 构建时都会使用特定于该服务器的部署方法，从而为您节省所有麻烦！

现在，回到图 1。这是商业入门套件，但它实际上运行在 Tomcat 上，Tomcat 位于 HTTP 端口 8080！您正在 J2EE 中运行您的应用程序！

构建和运行应用程序只是故事的一部分。没有人是完美的编码员，我们的代码中总会有错误。因此，为了制作一个合格的生产应用程序，您还需要在运行时调试和检查代码。在下一节中，您将看到 Grasshopper 如何让您做到这一点。事实上，您可以使用 Visual Studio .NET 调试器在 Java 代码执行时对其进行调试！

从 Visual Studio 调试您的 J2EE 商业入门套件

	图 9. 使用 Visual Studio .NET IDE 调试 Java 应用程序。

现在您拥有了一个真正的 J2EE 应用程序，它被打包并部署在 Tomcat 上。从 Visual Studio .NET 调试器调试它听起来可能不太可能——但实际上很容易！如果您完成了移植教程，很可能您甚至没有停下来仔细思考。您可能只是像往常一样在代码中设置断点并单步执行 [图 9]。

	图 10. 使用 Visual Studio .NET 调试器进行集成的 Java 调试。

工作原理如下：Grasshopper 用其自己的调试器代理替换底层的 .NET 调试器，而 Visual Studio .NET 调试器界面保持不变。

当您在 J2EE 项目的 C# 代码中设置断点时，Grasshopper 调试器代理就会启动。它知道如何将您的断点请求转换为生成的 Java 代码中的正确断点，以及如何“要求”Java 调试器设置断点。此外，由于 Grasshopper 调试器代理使用标准的 Java 调试器线协议 (JDWP) 来驱动 Java 调试器 [图 10]，您甚至可以在 J2EE 应用程序远程运行在不同机器上时对其进行调试！

结果是——您继续使用熟悉的 Visual Studio 调试器界面，而 Grasshopper 则代表您处理与 Java 调试器的交互。这种安排使您能够利用您对 Visual Studio .NET 调试器的了解来直接调试真正的 Java 代码，而无需学习如何使用 Java 调试器！

下一步去哪儿？

由于您使用 Grasshopper 构建的应用程序是标准的 J2EE 应用程序，因此您可以在任何拥有 J2EE 应用程序服务器的地方部署它。借助 Grasshopper，您的目标 J2EE 应用程序服务器甚至可以是 Linux 系统。我们已经看到 Grasshopper 支持远程调试。这意味着您可以在 Visual Studio .NET IDE 中，从您的开发机器上调试正在 Linux 机器上执行的 Grasshopper J2EE 应用程序！

请注意，如果您希望数据库层也在 Linux 上运行，则必须使用在 Linux 上运行的数据库应用程序。因此，如果像商业入门套件应用程序那样，您的数据层位于 Microsoft SQL Server（在 Linux 上不可用）上，您将不得不将数据迁移到不同的数据库，例如 PostgreSQL（为方便起见，它随 Grasshopper 一起提供）。您可以在此处查看商业入门套件如何完成数据库迁移。当然，如果您希望数据库层保留在 Windows 上，而您的数据库访问、丰富逻辑和表示层移动到 Linux 上的 J2EE，您仍然可以使用 Grasshopper 来实现。

结论

在本篇论文中，您采用了 Microsoft 的商业入门套件应用程序，并使用 Grasshopper 将其从 .NET 应用程序移植到了符合 J2EE 规范的应用程序。您无需编写一行自定义 Java 代码即可完成此操作，并且您的 Java 版本的源代码与您的 .NET 版本源代码相同。尽管存在将现有 .NET 框架应用程序移植到 J2EE 环境的挑战，但仍完成了此操作。

其中一些挑战包括：

• C# 和 VB.NET 到 Java 的语言差距——虽然表面上看这些语言在语法上可能相似，但 Java 编译器无法将 C# 或 VB.NET 编译成在 JVM 上运行的 Java 字节码。因此，您会遇到需要翻译的语言差距！
• J2EE 环境中的 .NET 框架依赖项——您的应用程序不仅仅是源代码——它还包括源代码所依赖的项。.NET 应用程序使用 .NET 框架的类。这些在 J2EE 环境中不可用，因此您在这里存在一个需要弥合的重大差距。
• 单一源代码挑战——如果您需要在两个不同的框架上支持您的应用程序——并且您将一种语言和一组依赖项翻译到另一种，您最终将拥有两套源代码，这些源代码需要保持一致的维护。
• 降低学习曲线——理想情况下，您会希望将更多精力投入到开发和移植应用程序的实际工作中，而不是学习如何移植。如果您需要将应用程序移植到另一个环境，能够将学习曲线降到最低将非常有益。

乍一看，面对这些挑战完成任何移植似乎都非常困难且成本高昂。如本示例所示，Grasshopper 能够跨越这些问题，并轻松实现移植，而无需担心语言差距、依赖项或分叉源代码集。