设计模式：针对后端应用

Question

RPC ASP.NET API我设计的API，使远程客户端对远程服务器执行PowerShell脚本。

为了有效地执行这些命令，应用程序需要以产生用于远程客户端的唯一运行空间（因此它可与合适的宿主初始化运行空间和命令该客户端中设置）。每当客户端发出请求时，API都需要确保请求在正确的运行空间内执行。

的（过度简化的）鉴于流动的可能是这样的：

1. 客户端连接到网络API，用于后端应用程序发送凭证
2. 的Web API，可以通过到后端应用程序将这些凭据传递，使用它们来对一个链接session-runspace
ID
3. 网页API或者创建唯一地为该客户端配置
4. 网页API和应用程式运行空间“同意”通知session-runspace ID的客户端或其保持在存储器
5. 客户提出要求：例如"GET http://myapiserver/api/backup-status/"
6. Web API将请求传递到后端应用程序函数
7. 后端应用程序返回结果：例如， “JSON {这是备份用户/客户端x的当前状态}”
8. 网页API通过向远程客户端通过这些结果
9. 要么超时或注销请求端“会话”和运行空间设置

（在现实中，PowerShell的应用程序可能只是在Web API中的自定义控制器/模型，或者它可能是一个IIS管理单元或相似 - 我愿意在这里设计建议...）。

我担心的是，以创造独特的运行空间为每个远程客户端，我需要给该客户端的独特的“会话”的ID，这样的API可以通过对应用程序正确传递请求。这感觉就像我打破了无国籍的规则。

事实上，API仍然是无状态的，只是后端应用程序不是，但它确实需要为每个客户端创建一个会话（RunSpace），然后在超时/结束会话请求后处理RunSpace 。

质询

1. 我应该攻入在ASP.NET MVC的验证机制来加速旋转运行空间？
2. 我应该认输，只是砍了一个会话变量？
3. 是否有更好的SOA，我应该考虑什么？ （网络API感觉非常整洁的这虽然 - 特别是如果我想有网络，移动和什么具备的，你的客户）

Answer 1

这感觉就像我打破了无状态的规则。

您的应用程序是有状态的 - 没有办法解决它。您必须为每个客户端维护一个进程，并且该进程必须在一个盒子上运行，并且客户端始终连接到相同的盒子。所以如果你有一台服务器，没问题。如果你有多个，你必须使用粘性会话，所以客户端总是回到同一个服务器（负载平衡器可以为你做到这一点）。

我应该入侵ASP.NET MVC的认证机制到 spin-up RunSpace？

如果您需要验证。

我是否应该承认失败并且只是破解会话变量？

没有变量，只是使用纯内存会话。如果超过1台服务器，请按照上面的说明使用粘性会话。

有没有更好的SOA我应该考虑？ （网络API感觉很整齐 整洁的这虽然 - 特别是如果我想有网络，移动 什么具备的，你的客户）

SOA不会接触到这一点。你有一个单一的服务。