如何保持最小的应用程序服务器依赖性？
构建 Java 应用程序同时尽可能少地依赖部署中使用的实际应用程序服务器的最佳（最简单、最无缝）方法是什么？
例如，假设我想部署在 Apache Geronimo 上，后来想使用 GlassFish，那么过渡会有多困难？抽象每个应用程序服务器的使用的最佳方法是什么？
请原谅我的无知，我对 Java 开发还比较陌生。我想开始一个新项目，但不确定是使用单独的 API 来实现我需要的功能，还是从一开始就在选定的应用程序服务器上进行开发。
谢谢你的帮助，
伊万
What is the best (easiest, most seamless) way to build a Java app while relying as little as possible on the actual application-server used in deployment?
For example, say I want to deploy on Apache Geronimo, and later want to use GlassFish, how difficult would the transition be? What is the best way to abstract the use of each app server?
Excuse my ignorance, I'm relatively new to Java development. I want to start a new project, but am unsure on whether to use separate APIs for the functionality I need or develop on top of a chosen app-server from the start.
Thanks for your help,
Ivan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
无需讨论太多细节，即使您可以编写基本的 Java EE 代码，但其周围的配置也不是很简单。每个应用程序服务器都有自己的一组配置文件和命名约定（例如，IBM WAS 和 JBOSS 中指定 AS 位置的格式不同）。虽然这些对于应用程序开发来说并不是很重要，但是一旦进入部署阶段，这些就会变得很重要。
就库和您的代码而言，只要您坚持 EJB 标准，您将能够在大多数应用程序服务器上运行您的应用程序（我知道 WAS 和 JBoss - 我编写的代码不必这些服务器的变化；不过，配置是不同的！）。
Without getting into too much details, even though you can write bare-bones Java EE code, the configuration around it is not very simple. Each application server has its own set of configuration files and naming conventions (for example, the format for specifying the location of the AS is different in IBM WAS and in JBOSS). Though these are not very important for application development, once you get to the deployment phase, these will become important.
As far as the libraries and your code is concerned as long as you stick to EJB standards you will be able to run your application on majority of the application servers (I know of WAS and JBoss - the code that I wrote didn't have to change for these servers; the configuration though, well that was a different beast !).
尽可能遵循 Java EE 规范，同时尽可能少地遵循服务器规范。
如果我们尝试找出 Java EE 应用服务器之间的共同点（JBoss，WAS...），答案是服务器供应商必须遵循的 Java EE 规范。如果您对 Java EE 问题有 2 个解决方案，您可以检查哪个解决方案更符合 Java EE 规范而不是服务器规范。
Follow Java EE specification as much as possible, while follow server specification least as possible.
If we try to find out what are in common among there Java EE application servers(JBoss, WAS...), answer is Java EE specification which server vendors must follow. If you have 2 solutions on a Java EE problem, you could check which solution comply with Java EE specification better rather than server specification.
根据我使用 Jboss 和 Sun AS 的经验，您应该忘记 AS 独立性。
例如，在 sql 中，您可以在不使用特定于供应商的功能的情况下完成很多工作。嗯，Java EE 中不是这样的。对于 Jboss 和 SAS，即使是“hello world”应用程序也需要不同的配置。随着应用程序的增长，您必须使用更多特定于供应商的功能。
特别是，如果您查看官方 Sun Java EE 教程，您会发现它从一开始就使用 SAS 特定的配置文件（sun-web.xml、sun-ejb-jar.xml 等）。
但以上所有内容仅适用于您使用全部 Java EE 功能（如 EJB、JMS、mbean）的情况。我发现，如果您只将 servlet/jsps 打包在一个 war 存档中，这样的应用程序仍然可以非常方便地移植。
From my experience with Jboss and Sun AS, you should just forget about AS-independency.
In sql, for example, you can do quite a lot without employing vendor-specific features. Well, it's not like that in Java EE. For Jboss and SAS even 'hello world' applications will require different configuration. And more application grows, more vendor-specific features you have to use.
In particular, if you look at official Sun Java EE tutorial, you'll find that it employs SAS-specific configuration files (sun-web.xml, sun-ejb-jar.xml, etc) from the very beginning.
But all above applies only if you use full range of Java EE features (like EJB, JMS, mbeans). I've found that if you just have servlets/jsps packaged in one war-archive, such application can still be very portable.
如果您有资源，请考虑开发和测试多个应用程序服务器，而不仅仅是最初的目标服务器。这将使您从一开始就能够查明需要配置的内容并相应地进行编码。
就我个人而言，我会在这种情况下考虑 Glassfish 3.0.1，因为它是参考实现，因此至少应该可以在不需要任何特殊努力的情况下工作。
If you have the resources then consider developing and testing for several application servers instead of just your initial target one. This will allow you to - from the start - pinpoint things that need to be configurable and code accordingly.
Personally I would consider Glassfish 3.0.1 in such a situation as it is the reference implementation, so things should at least work there without any special efforts.