设计模式 – 实时Web应用程序的体系结构

这将是一个相当理论上的问题.我目前正在研究我的学士论文,其中包括创建一个与 Firebase非常相似的 web-based real-time对象同步框架,但是本地(即不是基于云的).
我需要从实时中区分“常规”Web应用程序(有更好的术语吗？),尤其是在体系结构方面.到目前为止我的想法：

>常规Web应用程序基于客户端 – 服务器模型,即“客户端和服务器以请求 – 响应消息传递模式交换消息：客户端发送请求,服务器返回响应”.
>实时Web应用程序维护客户端和服务器之间的持久连接.两者都可以通过该连接同时并且彼此独立地发送和接收消息(全双工).
>我的顾问(来自应用软件工程主席)表示,上述观点已经证明了Peer-to-Peer架构的申请资格,尽管他不太确定.我还不确信,因为a)同行不是同质的,b)服务器仍然是一个集中系统,c)我们仍然使用术语“服务器”和“客户端”.
>服务器不直接向特定客户端发送消息,而是使用publish-subscribe消息传递模式,即客户端连接到消息通道,并在服务器在相应通道中发布消息时接收消息.因此服务器实际上并不知道它的客户端,尽管他可以知道.
>主要用例如下：客户端向服务器发送消息(例如,当创建新的待办事项项时),服务器处理它(例如将新的待办事项项目写入数据库),最后将消息发送给所有人其他订阅的客户.我想起了mediator pattern,虽然它是一种行为模式,而不是一种建筑模式.
>但还有另一个用例：服务器向订阅的客户端发送自己的消息(例如,它识别超出todo项目的到期日期并删除它).因此,沟通并不总是必须从客户端开始.

对不起,它比预期的要长.简而言之,我看到了基于Web的实时应用程序架构的三种可能性：

>点对点(具有异构对等体)
>具有pub-sub消息传递模式和中介的客户端服务器(如果后者对于体系结构很重要)
>你用完全不同的东西让我感到惊讶;-)

不确定它是否具有重要性,但我使用Rails(基于JMS的消息服务,提供WebSocket支持)在后端和AngularJS在前端.