1

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

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

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

  1. 客户端连接到 Web API，为后端应用程序发布凭据
  2. Web API 将这些凭据传递给后端应用程序，后端应用程序使用它们创建为该客户端唯一配置的 RunSpace
  3. Web API 和应用程序“同意”链接session-runspaceID
  4. Web API 要么通知客户端session-runspaceID，要么将其保存在内存中
  5. 客户提出请求：例如"GET http://myapiserver/api/backup-status/"
  6. Web API 将请求传递到后端应用程序功能
  7. 后端应用返回结果：例如“JSON {this is the current status of backup for user/client x}”
  8. Web API 将这些结果传递给远程客户端
  9. 超时或注销请求结束“会话”并释放 RunSpace

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

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

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

问题

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

1 回答 1

1

这感觉就像我打破了无国籍规则。

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

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

如果您需要身份验证。

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

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

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

SOA 没有涉及到这一点。你有一个单一的服务。

于 2013-02-27T00:45:57.793 回答