【IT168 技术文章】在现实世界中，您不会只部署单个项目并满足既得的成就。现实要复杂得多。您通常部署一个项目，然后两个月之后，部署另一个项目，该项目依赖于第一个项目所提供服务。有时候，您部署一个项目，然后六个月之后，部署该项目的第二个版本，同时让第一个版本并发地运行一段时间。

　　如果您是应用程序服务供应商(Application Service Provider，ASP)，这甚至会更复杂。在这种情况下，您实际上可能要为不同客户多次部署相同的应用程序，只是不同的客户具有不同的 URL 入口点以及不同的静态位图和 Web 页面细节。

　　从前……(一个应用程序开发故事)

　　作为的确存在的复杂类型示例，请考虑这样一个方案。假定由我们 Widgets Inc. 公司构建的第一个 J2EE 应用程序是人力资源部的雇员考勤卡应用程序。我们创建一组 EJB 组件以作为应用程序的一部分，用于处理雇员管理方面的问题。我们有一个 EmployeeManagement 会话 bean，它可检索向特定经理报告的一组雇员，我们还可以从 HR 数据库检索有关特定雇员的信息(姓名、部门、雇用日期和薪金级别等)。

　　不过，接着又产生了一个新的需求。要求我们构建一个新的应用程序，该应用程序允许雇员选择各种公司综合福利，允许他就医疗保险和储蓄计划签约等。对于该应用程序，我们正好需要已经在前一个应用程序中创建的业务逻辑类型。例如，要允许雇员买卖休假日，我们需要知道他的服务年数 ― EmployeeManagement 会话 bean 已经可以为我们检索这些项。

　　那么，我们该做些什么呢?第二次重写逻辑，还是找到重用现有逻辑的方法?重写似乎确实不太可取，所以重用似乎是最有效的选择。但是，如何重用该会话 bean 及其相关类呢?让我们研究几个选项。

　　选项 1：合并组件部署

　　在这种情况下，我们将把新的 Benefits 应用程序打包为现有 Timesheet 企业归档文件(EAR)中的 Web 归档文件(WAR)(或许是一个或两个 EJB-JAR)。如图 1 所示：

        图 1. 合并组件部署

　　我们在这里所做的是将两个应用程序放在同一个 EAR 中，以便 Benefits 应用程序可以访问 Timesheet 应用程序中的类和 EJB 组件。该方法非常容易实现，它解决了我们的当前问题。然而，它有一些缺点，这些缺点使它不能成为吸引人的长期解决方案。

　　让我们考虑一下使用这两个应用程序的方法。Timesheet 应用程序的使用非常频繁，每位时薪雇员每天随时都会使用它。这意味着：我们可以容易地预测最大负载并确定部署该应用程序所需的适当硬件。但 Benefits 应用程序不同。公司中的 每位雇员(不一定是小时工)都可能使用该应用程序，但对于每位雇员，只会在两周福利签约周期内的任何时间使用它一次。所以，运行该应用程序所需的硬件容量与 Timesheet 应用程序差异甚大 ― 如果每个人都等到最后一刻，在登记周期的最后一天签约(虽然我们确信这决不会发生)，那么负载明显会更高。

　　还有就是，应用程序的使用模式不同 ― Timesheet 应用程序在每天的正常工作时间内使用，而晚上停止使用，进行服务器和应用程序维护。然而，Benefits 应用程序应该可以让雇员在晚上通过公司的虚拟专用网(VPN)来使用，以便在他们进行福利选择时让他们的家属一起参与。那么，我们如何来调和不同的需求呢?

　　另外，可用性怎样?在我们的示例中，如果 Benefits 应用程序当机 1 小时左右，这或许还可以接受，但 Timesheet 应用程序不行 ― 它要求在工作时间内 100% 地运行。

　　根据这些需求，我们可以得出结论：不能在同一个 EAR 文件中部署这两个应用程序;这些应用程序是相关的，但不够紧密，所以无法保证共同部署。事实上，对前面几个考虑事项的评估将使您在大多数情况下拒绝将合并组件部署作为部署解决方案，因此我们提出了共享服务部署。