Hi,

I am evaluating an architecture using my custom Powershell cmdlets as the middle tier (MT) and using a Native NT service as the backend. Via my powershell cmdlets, UI can query/control the backend and the backend should be able to send notification to UI (UI doesn’t use Polling model for receiving notification). The middle tier will communicate with the backend using COM since they are different language interop. The middle tier will communicate with UI through powershell cmdlets. Therefore, the middle tier will be a Powershell cmdlets dll and an interop assembly at the same time. Note that in multi-machine scenario, UI could be on a different machine from where MT and Backend locate.

After reading, I am aware that there may be two ways for the backend to send notification back to UI through cmdlets:

1. Use custom WMI events. The backend creates some custom WMI events, then the UI can subscribe the WMI events and wait for the events.

2. Use custom events created by the middle tier’s cmdlets. That’s, the backend calls a COM-like method (say Notify()) in the cmdlets assembly, then Notify() can create new events in two ways:
2.1 if the COM-like method Notify() is not a cmdlet, Notify() will use a cmdlet inside the cmdlets assembly to create PS Session and generate a new event.
2.2 If the COM-like method Notify() itself is a Powershell cmdlets, it can create PS session and generate new events by itself.

I have more confidence on 1 and less on 2, though 1 sounds more dev costly than 2 due to the overhead of writing a custom WMI event provider. So I am looking at 2 as our preference.

Is 2.1 and/or 2.2 a feasible solution? I am writing prototype to verify and meanwhile very appreciate any insights.

Thanks
Leon