1

I'm designing an API to enable remote clients to execute PowerShell scripts against a remote server.

To execute the commands effectively, the application needs to create a unique runspace for the remote client (so it can initialise the runspace with an appropriate host and command set for that client). Every time the client makes a request, the API will need to ensure the request is executed within the correct runspace.

An (over-simplified) view of the flow might look like this:

  1. Client connects to Web API, POSTs credentials for the backend application
  2. Web API passes these credentials through to the backend app, which uses them to create a RunSpace uniquely configured for that client
  3. Web API and app "agree" on a linked session-runspace ID
  4. Web API either informs client of session-runspace ID or holds it in memory
  5. Client makes request: e.g. "GET http://myapiserver/api/backup-status/"
  6. Web API passes request through to backend app function
  7. Backend app returns results: e.g. "JSON {this is the current status of backup for user/client x}"
  8. Web API passes these results through to remote client
  9. Either timeout or logout request ends 'session' and RunSpace is disposed

(In reality, the PowerShell App might just be a custom controller/model within the Web API, or it could be an IIS snap-in or similar - I'm open to design suggestions here...).

My concern is, in order to create a unique RunSpace for each remote client, I need to give that client a unique "session" ID so the API can pass requests through to the app correctly. This feels like I'm breaking the stateless rule.

In truth, the API is still stateless, just the back-end app is not, but it does need to create a session (RunSpace) for each client and then dispose of the RunSpace after a timeout/end-session request.

QUESTIONS

  1. Should I hack into the Authentication mechanism in ASP.NET MVC to spin-up the RunSpace?
  2. Should I admit defeat and just hack up a session variable?
  3. Is there a better SOA that I should consider? (Web API feels very neat and tidy for this though - particularly if I want to have web, mobile and what-have-you clients)
4

1 に答える 1

1

これは、ステートレスのルールを破っているように感じます。

あなたのアプリケーションはステートフルです - それを回避する方法はありません。クライアントごとにプロセスを維持する必要があり、プロセスは 1 つのボックスで実行し、クライアントは常に同じボックスに接続する必要があります。したがって、サーバーが 1 台の場合は問題ありません。複数ある場合は、スティッキー セッションを使用して、クライアントが常に同じサーバーに戻るようにする必要があります (ロード バランサーがそれを行うことができます)。

RunSpace をスピンアップするには、ASP.NET MVC の認証メカニズムをハックする必要がありますか?

認証が必要な場合。

敗北を認めて、セッション変数をハックするだけですか?

変数はありません。単純なメモリ内セッションを使用してください。複数のサーバーの場合は、上記で説明したスティッキー セッションを使用します。

検討すべきより良い SOA はありますか? (ただし、Web API は非常にきちんと整頓されているように感じます。特に、Web、モバイル、および what-have-you クライアントが必要な場合)

SOA はこれには含まれません。単一のサービスがあります。

于 2013-02-27T00:45:57.793 に答える