Java Spring 远程处理选项
一些背景信息：我想将我正在编写的 Java 应用程序分成一个或多或少典型的服务器-客户端模型。我将提供一个负责业务逻辑和持久性的“服务器”，但以非常面向服务的方式编写它。然后，任何前端代码 (GUI) 都会调用服务器以用户友好的方式提供功能。
当我使用 Spring（和 ORM 框架）编写应用程序时，探索公开服务器功能的常见方法是有意义的，通常的方法是 RMI、Spring HTTP、Hessian、Web 服务等（Spring本机支持的选项）。这些在参考文档和此处都有详细记录。
然而，对于实际问题：是否有任何不太明显、更奇特的选项我可以考虑用来公开我的服务器服务？
（一如既往）在易用性（从前端 POV）、性能和可扩展性之间取得适当的平衡非常重要。例如;由于我考虑过以任何方式在服务器中提供 Spring-BlazeDS 集成（对于 Flex/AS3 客户端），我突然意识到 BlazeDS 提供了一个用于调用 AMF 服务的 Java 原生 API。
非常感谢任何指点。
A little context: I would like to separate the Java application I'm writing into a more or less typical server-client model. I would provide a "server" which takes care of business logic and persistence, but write it in a very service oriented fashion. Any front-end code (GUI) would then call upon the server to provide the functionality in a user friendly fashion.
As I'm writing the application using Spring (and an ORM framework), it would make sense to explore the usual suspects to expose the server functionality, with the usual suspects being RMI, Spring HTTP, Hessian, web services, etc (the Spring natively supported options). These are well well documented, both in reference documentation and on here.
However, for the actual question: are there any less obvious, more exotic options I could consider to use for exposing my server services?
It's important (as always) to get the right balance between ease of use (from a front-end POV), performance and scalability. For example; since I've thought about providing the Spring-BlazeDS integration in the server any way (for Flex/AS3 clients), it dawned on me that BlazeDS provides a Java-native API for calling AMF services.
Any pointers are much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您有 Flex 前端，我会推荐 BlazeDS，如果没有，我会推荐 Spring HTTP。两者都消除了由于必须将 XML 转换为对象并再次转换回来而引入的非生产性工作。
Spring HTTP 特别有吸引力，因为您可以像往常一样编写 POJO Spring 服务接口，将通过 HTTP 远程处理公开的选择推迟到最后。这样你就可以保持你的选择余地。如果您以后认为 Spring Web 服务更适合您，您可以继续重复使用相同的 POJO Spring 接口。
I would recommend BlazeDS if you have a Flex front end and Spring HTTP if not. Both eliminate the non-productive work introduced by having to translate XML to objects and back again.
Spring HTTP is especially attractive because you can write POJO Spring service interfaces just as you always do, deferring the choice to expose via HTTP remoting until the end. You keep your options open that way. If you decide that Spring web services work better for you later on, you can keep re-using the same POJO Spring interface.