Grundlagen zu vermittelten Diensten
Ein vermittelter Dienst ist ein dienst, der über eine IServiceBroker, und als RPC-kompatible Schnittstelle verfügbar gemacht wird, um den Dienst und seinen Client in unterschiedlichen AppDo Standard s, Prozessen oder sogar über Computer hinweg (im Fall von Live-Freigabe) zu existieren. Der brokerierte Dienst kann vom Standard Visual Studio-Prozess oder einigen seiner Hilfsprozesse unterstützt werden und kann von einem dieser Prozesse durch eine Visual Studio-Erweiterung genutzt werden.
Weitere (nicht vermittelte) Visual Studio-Dienste sind über die IServiceProvider Schnittstelle verfügbar, wie unter Verwendung und Bereitstellung von Diensten beschrieben. Solche Dienste sind in der Regel nur im Standard Visual Studio-Prozess verfügbar, stellen jedoch einen größeren Funktionsumfang zur Verfügung als brokerierte Dienste.
Eine Visual Studio-Erweiterung, die auf einem Live Share-Gast ausgeführt wird, kann zusätzliche Funktionen bereitstellen, indem auf eine Teilmenge dieser Dienste zugegriffen wird, die vom Live Share-Host bereitgestellt werden. Autorisierungsprüfungen gelten für Live-Freigabeverbindungen, um das Risiko zu verringern, dass ein Live Share-Gast die Sicherheit des Live Share-Hosts beeinträchtigt. Autoren von brokerierten Diensten, die sich dafür entscheiden, ihre Dienste über Live Share verfügbar zu machen, sollten sich um die Implementierung von Autorisierungsprüfungen kümmern, wie in how to provide a brokered service beschrieben.
Service Broker
Visual Studio verfügt über einen globalen IServiceBroker, analog zu (und aus dem abgerufen werden kann), der GlobalProvider andere Dienste verfügbar macht. Es kann auch über MEF abgerufen werden.
Möglicherweise gibt es andere kontextspezifische Dienstbroker, die von bestimmten Visual Studio-Features unterstützt werden, die das globale Feature mit einem eigenen aggregieren möchten, das zusätzliche Dienste anbietet (oder vielleicht einige unterdrückt).
Es IServiceBroker handelt sich (absichtlich) um ein schwarzes Feld, mit dem ein Client Dienste abrufen kann, die lokal, in einem anderen Prozess oder auf einem anderen Computer vorhanden sein können. Dienstbroker können Aggregate eines oder mehrerer anderer Sein, mit angewendeten Richtlinien.
Basierend auf dem Kontext, in dem sich der Visual Studio-Prozess befindet, ist dieser globale Dienstbroker ein Aggregat eines sich ändernden Satzes anderer Dienstbroker. Kontextänderungen innerhalb des Prozesses können den Satz von brokerierten Diensten ändern, die aktiviert werden können. Wenn z. B. eine Lösung geladen wird, kann ein Dienst speziell im Zusammenhang mit der aktiven Lösung verfügbar werden. Dieser Dienst kann auch in einer Ansicht "Ordner öffnen" verfügbar sein, wenn auch mit einer anderen Sicherungsimplementierung. Die Änderung der Dienstimplementierung wäre für einen Client dieses Diensts transparent, da beide Implementierungen denselben Vertrag erfüllen müssen, aber der Client muss den Dienst in dieser Kontextänderung erneut abfragen (von denen sie über AvailabilityChangedbenachrichtigt werden würden), um die neue Instanz abzurufen.
Der Dienstbroker wird in der Regel verwendet, um einen Proxy für den Dienst abzurufen. Statt einen Verweis auf das Dienstobjekt direkt zu empfangen, empfängt der Client einen Stub, der alle Methodenaufrufe an den Dienst weiterleitet und Ergebnisse oder Ausnahmen an den Client zurückgibt. Es kann auch Ereignisse weiterleiten, die vom Dienst an den Client ausgelöst werden. In einigen Fällen unterstützt oder erfordert ein Dienst, dass der Client ein "Zielobjekt" bietet, für das der Dienst Methoden aufrufen kann, um den Client zurückzurufen.
Brokered Service Container
Dienste müssen in die IBrokeredServiceContainer Kasse gestellt werden, um von der Global IServiceBrokerverfügbar zu sein. Dieser Dienstcontainer ist nicht nur für die Bereitstellung der Dienstfactory für den Servicebroker verantwortlich, sondern auch für die Kontrolle, welche Clients Zugriff auf den Dienst haben und diese Clients benachrichtigen, wenn der Zugriff auf diesen Dienst geändert wird.
Zusammensetzung eines brokerierten Diensts
Ein vermittelter Dienst besteht aus den folgenden Elementen:
- Eine Schnittstelle, die die Funktionalität des Diensts deklariert und als Vertrag zwischen dem Dienst und seinen Clients dient.
- Eine Implementierung dieser Schnittstelle.
- A ServiceMoniker , um dem Dienst einen Namen und eine Version zuzuweisen.
- Eine ServiceRpcDescriptor , die das Verhalten für die ServiceMoniker Behandlung von RPC bei Bedarf kombiniert.
- Code zur Kasse der Dienstfactory
- Dienstregistrierung
Dienstschnittstelle
Dies kann eine .NET-Standardschnittstelle sein (häufig in C#geschrieben). Damit brokerierte Dienstclients und -dienste in unterschiedlichen Prozessen vorhanden sind und über RPC kommunizieren können, muss diese Schnittstelle einschränkungen gemäß den ServiceRpcDescriptor Angaben des Diensts einhalten. Diese Einschränkungen umfassen in der Regel, dass Eigenschaften und Indexer nicht zulässig sind, und die meisten oder alle Methoden geben einen anderen asynchron kompatiblen Rückgabetyp zurück Task .
Brokered Service Moniker und Deskriptoren
Für die Aktivierung eines Dienstes ist es erforderlich, seinen Moniker zu kennen. Da der Moniker in der Beschreibung des Diensts enthalten ist, kann ein Client in der Regel nur mit dem ServiceRpcDescriptor. Ein Deskriptor fügt das Verhalten hinzu, das erforderlich ist, um eine RPC-Verbindung zwischen dem brokerierten Dienst und seinem Client einzurichten, oder wenn dies erforderlich ist, um RPC-Aufrufe in/aus Streamzu serialisieren.
Visual Studio empfiehlt die Verwendung des ServiceJsonRpcDescriptor abgeleiteten Typs für brokerierte Dienste, die die StreamJsonRpc-Bibliothek verwendet, wenn der Client und der Dienst RPC für die Kommunikation benötigen. StreamJsonRpc wendet bestimmte Einschränkungen auf der Dienstschnittstelle an, wie hier beschrieben.
Ein Deskriptor muss selten direkt verwendet werden. Stattdessen wird er in der Regel von VisualStudioServices einer Bibliothek erworben, die den Dienst anbietet, und dann als Argument verwendet GetProxyAsync.
Sowohl die Klassen als ServiceJsonRpcDescriptor auch die ServiceMoniker Klassen sind unveränderlich und somit sicher, als static readonly Felder oder Eigenschaften zu teilen.
Jeder andere ServiceRpcDescriptorabgeleitete Typ sollte unveränderlich sein.
A ServiceMoniker ist serialisierbar. A ServiceJsonRpcDescriptor ist nicht serialisierbar.
Dienstzielgruppe
Jeder brokerierte Dienst wird mit einer Auswahl von Flags von ServiceAudience. Diese Flags steuern, welche Clients und über welche Verbindungen der brokerierte Dienst verfügbar gemacht wird.
Eine typische Auswahl ist ServiceAudience.Local, die den Dienst für jeden lokalen Prozess innerhalb einer Visual Studio-Sitzung verfügbar macht. Bei dieser Einstellung wird der Dienst immer lokal aktiviert, auch wenn eine Live Shared-Sitzung aktiv ist.
Wenn das Flag hinzugefügt wird, erhält ein Live Share-Gast, der ServiceAudience.LiveShareGuest anfordert, dass der brokerierte Dienst einen Proxy für diesen brokerierten Dienst über die Remoteverbindung mit dem Live Share-Host abruft.
Jede Kombination von Kennzeichnungen, die ServiceAudience definiert sind, ist legal. Die LiveShareGuest Kennzeichnung kann festgelegt werden, ohne auch die Local Kennzeichnung festzulegen, z. B. um einen brokerierten Dienst nur für LiveFreigabe-Gäste (von einem LiveFreigabe-Host) verfügbar zu machen und niemals lokal verfügbar zu sein (wo sich Client und Dienst im selben Prozess befinden).
Die RemoteExclusiveClient Kennzeichnungen sind RemoteExclusiveServer veraltet.
Wenn ein Client einen brokerierten Dienst anfordert, muss er nicht wissen, was für diesen ServiceAudience Dienst ist oder wo der Dienst aktiviert wird. Es kann jedoch hilfreich sein, dass ein Dienst diesen Wert dokumentiert, und für einen Entwickler, der den Dienst verwendet, um zu wissen, wo ein Dienst aktiviert werden kann, damit sie die Art von Daten antizipieren können, die in verschiedenen Kontexten von diesem Dienst stammen können und wann ein Dienst verfügbar ist.
Zusammensetzung eines vermittelten Clients
Wenn ein Client einen brokerierten Dienst anfordert, wird null er entweder zurückgesendet, wenn der Dienst nicht verfügbar ist, ein ServiceActivationFailedException Auslösen, wenn der Dienst bei der Aktivierung fehlschlägt, oder er erhält einen Proxy für den Dienst.
Ein Proxy wird verwendet, ob der brokerierte Dienst im selben Prozess wie der Client oder ein anderer aktiviert wird.
Dieser Proxy hilft dabei, Nutzungsmuster in den lokalen und Remotedienstfällen zu harmonisieren, sodass der Client nicht wissen muss, wo sich der Dienst befindet.