设计模式：针对后端应用程序的RPC的ASP.NET API

Question

我正在设计一个API，使远程客户端能够针对远程服务器执行PowerShell脚本。

要有效地执行命令，应用程序需要为远程客户端创建唯一的运行空间（因此它可以使用适当的主机和该客户端的命令集初始化运行空间）。每次客户端发出请求时，API都需要确保请求在正确的运行空间内执行。

流程的（过度简化）视图可能如下所示：

1. 客户端连接到Web API，后端应用程序的POST凭据
2. Web API将这些凭据传递给后端应用程序，该应用程序使用它们创建为该客户端唯一配置的RunSpace
3. Web API和应用“已同意”关联的session-runspace ID
4. Web API通知客户端session-runspace ID或将其保存在内存中
5. 客户提出请求：例如"GET http://myapiserver/api/backup-status/"
6. Web API将请求传递到后端应用程序功能
7. 后端应用返回结果：例如“JSON {这是用户/客户端x的备份的当前状态}”
8. Web API将这些结果传递给远程客户端
9. 超时或注销请求结束'session'并且RunSpace被释放

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

我担心的是，为了为每个远程客户端创建一个独特的RunSpace，我需要为该客户端提供一个唯一的“会话”ID，以便API可以正确地将请求传递给应用程序。这感觉就像我打破了无国籍的统治。

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

问题

1. 我是否应该破解ASP.NET MVC中的身份验证机制来启动RunSpace？
2. 我应该承认失败并且只是破解会话变量吗？
3. 我应该考虑更好的SOA吗？ （Web API对此感觉非常整洁 - 特别是如果我想拥有网络，移动设备和有你的客户）

Answer 1

  

这感觉就像我打破了无国籍的统治。

你的申请是有状态的 - 没办法解决。您必须为每个客户维护流程，并且流程必须在一个框上运行，客户端始终连接到相同的框。所以如果你有一台服务器，没问题。如果您有多个，则必须使用粘性会话，以便客户端始终返回到同一服务器（负载平衡器可以为您执行此操作）。

  

我是否应该破解ASP.NET MVC中的身份验证机制   启动RunSpace？

如果您需要身份验证。

  

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

没有变量，只需使用简单的内存中会话。如果服务器数超过1个，请使用粘性会话，如上所述。

  

我应该考虑更好的SOA吗？ （Web API感觉非常整洁   虽然整洁 - 特别是如果我想要网络，移动   和你有什么客户）

SOA不会涉及到这一点。你有一项服务。