使用共享库与完全封装EAR的优缺点

Question

我们的团队构建并拥有一个webservices框架。其他实际构建the服务的团队使用我们的框架来实现一些常见功能。有两个选项可以打包EAR。选项1是将所有框架EAR构建到EAR中。选项2是在应用程序服务器中配置一个共享库，并使所有应用程序都使用该库。我们有可能部署多达100个EARS，这将使用这个框架。这种方法在构建、可管理性和开发方面有哪些优点和缺点。我们使用的是websphere。

Answer 1

基本的权衡是内存消耗与版本管理。

如果您将库打包到EAR中，那么每个应用程序都将创建自己的类实例，消耗一定数量的permgen (或等效物)，并占用堆空间用于静态数据。

如果在应用程序lib目录中存储库，那么每个类将只有一个实例。然而，这意味着使用该库的每个应用程序必须使用相同的版本，并且(除非确保向后兼容)必须同时升级。

考虑到您正在谈论的是100个EAR，版本管理问题可能会很大。除非你的库非常庞大(我假设你在一个64位的服务器上运行，有大量的内存，所以把它做得很大)，或者永远不会改变(不太可能)，我建议用EAR打包。

Answer 2

另一件需要注意的事情是，如果你想在EAR之间共享对象实例，例如使用websphere dynacache，那么这些对象的类将需要从共享库中加载。(否则，即使它们可能是相同的类/版本，它们也将由不同的类加载器加载，并且不兼容)

我通常也会使用普通的“将所有东西打包到耳朵中”的方法，但是对于需要共享的东西，我会做一些例外处理，并将这些类放入一个特殊的共享JAR中。

Answer 3

我也建议用耳朵包装。Ad kdgregory指出，管理成百上千的程序和升级所隐含的测试量变得令人望而生畏；此外，您应该使用版本控制系统来管理供客户端使用的二进制文件的实例。