我们正在开发更多的Java应用程序。非常简单的描述。
- 前端应用- web应用，与用户交互
- 中间件应用-为前端应用提供一些功能
- transport app -与外部系统通信的app。
这些应用程序通过http上的xml传输相互通信。现实生活中的场景看起来像，用户在前端应用程序中创建一些操作，前端应用程序调用中间件应用程序，通常中间件应用程序调用传输应用程序(通常调用其他外部系统)。前端应用也可以直接调用传输应用，这取决于流程和业务逻辑等。就像你看到的，有很多http调用，前端应用创建http调用，调用中间件应用，中间件应用创建HTTP调用和调用传输应用程序，传输请求其他系统并将响应发送回中间件等
我的问题是……这真的是好的建筑吗?我觉得开销太大了。应该有其他更好的解决办法，如何在应用程序之间传输数据，即使它们运行在一个服务器上。数据99%是通过xstream创建的简单xml格式。JMS可能是合适的解决方案吗?
Thank you
我同意你的看法，尽管它肯定会工作得很好，但层之间的http调用方法可能有点笨拙。
如果不同层之间的调用是异步的，并且本质上是触发并忘记(您触发一条消息，并且在目的地接收到您的消息时对目的地必须完成的工作的结果不立即感兴趣)，那么JMS将是一个非常好的匹配。尽管有人使用JMS进行请求-回复，但我认为这不是面向消息系统最自然、最优雅的用法。
如果你正在做的是同步的(你调用后端并等待它响应你的请求)，我会使用正常(无状态)会话bean，这些会话bean的创建和管理在EE6中已经简化了很多。
使用EJB的另一个优点是，您不会招致您所描述的场景中所需的不同XML序列化和反序列化的开销。