Java 使用Web服务连接前端和后端，这是个好主意吗？

这个项目在一个JVM上运行前端web服务器，在另一个JVM上运行后端web服务器。为了让web在后端调用任何biz逻辑方法，它必须通过web服务（JAX-WS）进行调用

我可以理解，对于需要与其他系统集成的应用程序部分，通过使用webservices分发服务是一个好主意，但我还没有看到一个系统，其中每个业务逻辑调用都作为webservice公开

---

表演？交易？一般来说，这是个好主意？

拆分应用程序的想法并不少见。当您的大多数服务都打算重用时，最好将它们作为单独的应用程序进行部署，并将其解耦，以便其他系统可以轻松访问它们。它无疑会对性能产生一些影响，但从技术上讲，它不应该对事务产生任何影响（除非您需要跨服务调用进行事务处理，以便使用WS-Reliability）

一般来说，如果您的“后端”（我称之为“服务”）打算被其他应用程序重用，那么这种方法是个好主意

---

不过请注意，web服务只是系统之间的实际传输/消息接口。这里还有很多其他选项来处理这两个系统之间的接口——Java RMI、Spring远程处理、REST等。一个设计良好的服务解决方案将不知道您在使用哪种消息传递技术（并且应该能够支持多种消息传递技术）。

我非常喜欢KISS原则（保持简单愚蠢）。需要有一个令人信服的理由在JVM之间拆分应用程序并创建WS-interface层。可能的原因包括需要以不同于业务层的方式扩展表示层。JVM调优差异，例如不同的垃圾收集算法。或者需要一个非军事区

如果不存在令人信服的原因，分离会增加不必要的复杂性，这很可能会导致从开发到操作的麻烦

而且，向其他应用程序公开业务逻辑的需要并不是在JVM之间划分层的一个令人信服的理由。业务逻辑仍然可以通过WS for external apps公开，而表示层物理上驻留在同一JVM中，并通过业务服务的POJO实现直接引用业务层。虽然POJO实现周围会有一个web服务包装器，将业务服务公开为web服务