基于Java的应用服务器；自己动手，现有的不错的选择，需要指点
我已经准备好一个大型 API，可以将其划分为应用程序服务器、客户端-服务器架构。
我希望至少有一种可用的、具有开放许可证的、基于 Java 的应用程序服务器系统已经取得了足够的进展，适合我的使用，并且对我来说不会太繁琐而难以处理。
建议的工具集应该：
- 提供连接线程管理。 （也就是说，它应该接收未经请求的入站连接请求，为每个请求提供身份验证，并且应该以优雅的方式管理断开连接。）
- 提供与服务器的持续、有状态的连接 - 实例化我的 API 的新实例基于每个用户连接的基础上是完美的。
- 提供一种身份验证机制，该机制可以完全由该工具提供，并且希望能够为我的 API 提供用户名/密码调用。
由于我的所有代码都是基于 Java 的，因此全 Java 解决方案会很棒。
我认为这就是所需要的。 其他机器越少越好。我不需要很多线程管理/连接管理能力，但没关系。我不需要或不想要与“网络”有关的任何事情。这不是基于网络的应用程序情况。
您能否提出应用程序服务器工具集，并且对于每个工具集：
- 确定在像我这样的情况下使用的步骤 - 专注于耗时和全局步骤就可以了。
- 确定所提议的工具集的主要优点
- 确定所提议的工具集的主要缺点
- 对实施工作量和规模提出任何意见 解决方案的可扩展性。
我的调查让我相信 Glassfish 可能值得我花时间和关注。我自己使用 JBoss 的经验表明这绝对是不可能的......
I've got a large API ready for division into an application server, client-server architecture.
I'm hoping that at least one available Java-based application-server system with open license has progressed sufficiently that it's suitable for my use, and not too onery for me to handle.
The proposed tool-set should:
- Provide for connection thread management. (That is, it should receive unsolicited in-bound connect requests, provide for authentication of each, and should manage dis-connections in a graceful way.)
- Provide for continuing, stateful connection to the server - instantiation of a new instance of my API on a per-user-connection basis is perfect.
- Provide for an authentication mechanism that can either be completely provided by the tool, and, hopefully, have an ability to provide username / password call to my API.
As all my code is Java based, an all-Java solution would be great.
I think this is all that is required. The less of other machinery, the better. I do not require a lot of thread management / connection management capability, but it's OK. What I do not need or want is anything to do with "the web." This is NOT a web-based application situation.
Could you propose Application-Server tool-sets, and for each tool-set:
- Identify steps for use in a situation like mine - focus on time-consuming and big-picture steps is fine.
- Identify key benefits of the proposed tool-set
- Identify key drawbacks of the proposed tool-set
- Give any opinions as to scale of effort of implementation and
scalability of solution.
My investigations have led me to believe that Glassfish may deserve my time and attention. My own experience with JBoss suggests it's absolutely out of the question...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您要求进行逐个功能的比较，恐怕您会失望的。
我认为 WebLogic 是市场上最好的 Java EE 应用服务器；至少在 BEA 担任其管理者时是这样。自从 Oracle 收购之后我就没再用过它了，所以我不知道它今天是什么状态。
Glassfish 与所有 Sun 产品都面临着同样的问题：规格很高，实现却很糟糕。
与 WebLogic 提供的优雅管理控制台相比，我不喜欢 JBoss 笨拙的 XML 管理。但我更喜欢它而不是 Glassfish。
我想知道您是否真的需要 Java EE 应用服务器。我使用部署在Tomcat上的Spring； Java EE 中没有我解决不了的问题。也许您应该考虑将 Spring 作为 Java EE 的替代品。
更新：你说“自己动手”。我不确定我是否同意这个策略，但我记得我应该指出 Netty。它是 JBOSS 的非阻塞 IO 基础。您可能不喜欢他们的应用程序服务器，但您应该了解 Netty。
Spring不会帮助您编写应用程序服务器。我推荐它是因为我相信应用程序服务器问题已经解决。 Spring 将帮助您编写更好的应用程序，您可以将其部署在 Tomcat 或 Spring 自己的应用程序服务器版本上。
If you're asking for a feature-by-feature comparison, I'm afraid you're going to be disappointed.
I think WebLogic is the very best Java EE app server on the market; at least it was when BEA was its steward. I have not used it since Oracle bought them out, so I don't know what state it's in today.
Glassfish suffers from the same problem that all Sun products do: great specifications, lousy implementations.
I don't like JBoss's clumsy XML administration compared to the elegant admin console that WebLogic provides. But I'd prefer it to Glassfish.
I'd wonder if you really need a Java EE app server at all. I use Spring deployed on Tomcat; there's no problem in Java EE that I can't solve. Maybe you should consider Spring as an alternative to Java EE.
UPDATE: You said "roll your own." I'm not sure that I agree with this strategy, but I remembered that I should point out Netty. It's the non-blocking IO foundation for JBOSS. You might not like their app server, but you should know about Netty.
Spring won't help you write an app server. I recommend it because I believe the app server problem has been solved. Spring will help you write better applications that you can deploy on Tomcat or Spring's own version of the app server.