架构决策：用Web客户端取代胖Java客户端

我有一个基于Java的客户机-服务器应用程序，服务器使用Spring

现在，我必须用web客户机替换Java客户机

我有三种不同的achitectur概念来实现Web服务器并将其链接到Appliance服务器。但我不确定该用哪一种。我对web应用程序不是很坚定，但我认为这不是web客户端的纯粹决定。 有人能告诉我不同概念的利弊吗？或者如果我的概念有错误，请告诉我

这些是概念：

在我的应用服务器中使用嵌入式web服务器。 Pro:我不能在web服务器和应用程序服务器之间实现任何会话处理。Web服务器可以使用应用服务器的数据存储进行请求缺点：客户必须决定是否允许应用服务器启动自己的web服务器。我不确定将web ui逻辑与应用程序服务器的业务逻辑混合是否是一种好的风格

将业务逻辑与web ui嵌入到独立web服务器的战争中。 Pro:诸如https之类的基本安全stuf处理将由web服务器完成。对于部署，客户可能更容易接受。我不能在web服务器和应用服务器之间实现任何会话处理。Web服务器可以使用应用服务器的数据存储进行请求。 缺点：应用程序服务器有大量内存和cpu使用。这可能是web服务器的一个问题

将web ui嵌入到web服务器中，并通过套接字连接将其链接到应用程序服务器。Pro:ui和业务逻辑之间的严格分离。不能更改应用程序服务器，因为web服务器和应用程序服务器之间的套接字连接可以使用fat客户端的现有套接字连接缺点：必须处理两次用户会话。首先是web会话，然后是应用服务器会话。此外，web服务器必须为数据设置自己的存储，并且必须使其与应用服务器中的存储保持同步

我的第一个想法是采用第一个概念，因为我在一个应用程序中拥有所有东西。 但是我的第二个想法是使用第三个概念，因为严格的分离和真正的web服务器的好处。但这里我的问题是为每个用户处理两个会话。还是有更好的概念

---

谢谢你给我的意见

你的第三种方法更好。保持应用服务器的独立将更好地服务于不同的客户机，如Java客户机、web客户机等。

---

它将分离两个不同的关注点。如果存在与UI相关的问题，则可以关闭UI服务器并进行修复。但是您的其他Java客户机可以正常工作。此外，从发展的角度来看也会更好。

谢谢您的回答。但是我应该如何处理用户会话呢？我必须为每个用户处理web服务器和应用服务器之间的会话吗？如果是，每个web会话必须有一个到应用服务器的高速套接字会话？如果不是的话，有什么更好的概念来验证和控制对不同功能的访问？将用户会话保持在web应用程序上，并以无状态的方式设计后端应用程序。如果您想在后端维护有状态会话，那么您可以通过EJB公开您的服务。