Översikt över WCF-identifiering
Identifierings-API:erna tillhandahåller en enhetlig programmeringsmodell för dynamisk publicering och identifiering av webbtjänster med hjälp av WS-Discovery-protokollet. Dessa API:er gör det möjligt för tjänster att publicera sig själva och klienter för att hitta publicerade tjänster. När en tjänst har upptäckts kan tjänsten skicka meddelanden och lyssna efter och svara på identifieringsbegäranden. Upptäckbara tjänster kan skicka Hello-meddelanden för att meddela sin ankomst till ett nätverk och Bye-meddelanden för att meddela att de lämnar ett nätverk. För att hitta en tjänst skickar klienter en Probe begäran som innehåller specifika kriterier, till exempel tjänstkontraktstyp, nyckelord och omfång i nätverket. Tjänsterna tar emot Probe begäran och avgör om de matchar kriterierna. Om en tjänst matchar svarar den genom att skicka ett ProbeMatch meddelande tillbaka till klienten med den information som krävs för att kontakta tjänsten. Klienter kan också skicka Resolve begäranden som gör att de kan hitta tjänster som kan ha ändrat deras slutpunktsadress. Matchande tjänster svarar på begäranden genom att Resolve skicka ett ResolveMatch meddelande tillbaka till klienten.
Ad hoc- och hanterade lägen
Identifierings-API:et stöder två olika lägen: Managed och Ad-Hoc. I hanterat läge finns det en centraliserad server som kallas för en identifieringsproxy som underhåller information om tillgängliga tjänster. Identifieringsproxyn kan fyllas i med information om tjänster på flera olika sätt. Tjänster kan till exempel skicka meddelanden under starten till identifieringsproxyn eller så kan proxyn läsa data från en databas eller en konfigurationsfil för att avgöra vilka tjänster som är tillgängliga. Hur identifieringsproxyn fylls i är helt upp till utvecklaren. Klienter använder identifieringsproxyn för att hämta information om tillgängliga tjänster. När en klient söker efter en tjänst skickar den ett Probe meddelande till identifieringsproxyn och proxyn avgör om någon av de tjänster som den känner till matchar den tjänst som klienten söker efter. Om det finns matchningar skickar identifieringsproxyn ett ProbeMatch svar tillbaka till klienten. Klienten kan sedan kontakta tjänsten direkt med hjälp av tjänstinformationen som returneras från proxyn. Huvudprincipen bakom hanterat läge är att identifieringsbegäranden skickas på ett unicast-sätt till en utfärdare, identifieringsproxyn. .NET Framework innehåller viktiga komponenter som gör att du kan skapa en egen proxy. Klienter och tjänster kan hitta proxyn med flera metoder:
Proxyn kan svara på ad hoc-meddelanden.
Proxyn kan skicka ett meddelande under starten.
Klienter och tjänster kan skrivas för att söka efter en specifik välkänd slutpunkt.
I ad hoc-läge finns det ingen centraliserad server. Alla identifieringsmeddelanden, till exempel tjänstmeddelanden och klientbegäranden, skickas på ett multicast-sätt. Som standard innehåller .NET Framework stöd för Ad-Hoc-identifiering via UDP-protokollet. Om en tjänst till exempel har konfigurerats för att skicka ut ett Hello-meddelande vid start skickar den ut det via en välkänd multicast-adress med UDP-protokollet. Klienter måste aktivt lyssna efter dessa meddelanden och bearbeta dem därefter. När en klient skickar ett Probe meddelande för en tjänst skickas det via nätverket med hjälp av ett multicast-protokoll. Varje tjänst som tar emot begäran avgör om den matchar kriterierna i Probe meddelandet och svarar direkt på klienten med ett ProbeMatch meddelande om tjänsten matchar de kriterier som anges i Probe meddelandet.
Fördelar med att använda WCF-identifiering
Eftersom WCF Discovery implementeras med hjälp av WS-Discovery-protokollet är det samverkande med andra klienter, tjänster och proxyservrar som även implementerar WS-Discovery. WCF Discovery bygger på befintliga WCF-API:er, vilket gör det enkelt att lägga till identifieringsfunktioner i dina befintliga tjänster och klienter. Tjänstidentifiering kan enkelt läggas till via programkonfigurationsinställningarna. Dessutom har WCF Discovery även stöd för att använda identifieringsprotokollet över andra transporter, till exempel peer net, namngivningsöverlägg och HTTP. WCF Discovery ger stöd för ett hanterat driftsläge där en identifieringsproxy används. Detta kan minska nätverkstrafiken eftersom meddelanden skickas direkt till identifieringsproxyn i stället för att skicka multicast-meddelanden till hela nätverket. WCF Discovery ger också mer flexibilitet när du arbetar med webbtjänster. Du kan till exempel ändra adressen för en tjänst utan att behöva konfigurera om klienten eller tjänsten. När en klient måste komma åt tjänsten kan den utfärda ett Probe meddelande via en Find begäran och förvänta sig att tjänsten svarar med sin aktuella adress. Med WCF Discovery kan en klient söka efter en tjänst baserat på olika kriterier, inklusive kontraktstyper, bindningselement, namnområde, omfång och nyckelord eller versionsnummer. WCF Discovery möjliggör körnings- och designtidsidentifiering. Att lägga till identifiering i ditt program kan användas för att aktivera andra scenarier, till exempel feltolerans och automatisk konfiguration.
Tjänstpublikation
För att en tjänst ska kunna identifieras måste en ServiceDiscoveryBehavior läggas till i tjänstvärden och en identifieringsslutpunkt måste läggas till för att ange var identifieringsmeddelanden ska lyssnas. I följande kodexempel visas hur en lokalt installerad tjänst kan ändras för att göra den identifierbar.
Uri baseAddress = new Uri($"http://{System.Net.Dns.GetHostName()}:8000/discovery/scenarios/calculatorservice/{Guid.NewGuid().ToString()}/");
// Create a ServiceHost for the CalculatorService type.
using (ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService), baseAddress))
{
// Add calculator endpoint
serviceHost.AddServiceEndpoint(typeof(ICalculator), new WSHttpBinding(), string.Empty);
// ** DISCOVERY ** //
// Make the service discoverable by adding the discovery behavior
serviceHost.Description.Behaviors.Add(new ServiceDiscoveryBehavior());
// ** DISCOVERY ** //
// Add the discovery endpoint that specifies where to publish the services
serviceHost.AddServiceEndpoint(new UdpDiscoveryEndpoint());
// Open the ServiceHost to create listeners and start listening for messages.
serviceHost.Open();
// The service can now be accessed.
Console.WriteLine("Press <ENTER> to terminate service.");
Console.ReadLine();
}
En ServiceDiscoveryBehavior instans måste läggas till i en tjänstbeskrivning för att tjänsten ska kunna identifieras. En DiscoveryEndpoint instans måste läggas till i tjänstvärden för att tala om för tjänsten var den ska lyssna efter identifieringsbegäranden. I det här exemplet läggs en UdpDiscoveryEndpoint (som härleds från DiscoveryEndpoint) till för att ange att tjänsten ska lyssna efter identifieringsbegäranden via UDP-multicast-transporten. UdpDiscoveryEndpoint Används för ad hoc-identifiering eftersom alla meddelanden skickas på ett multicast-sätt.
Meddelande
Som standard skickar inte tjänstpublikationen meddelanden. Tjänsten måste konfigureras för att skicka meddelanden. Detta ger ytterligare flexibilitet för tjänstförfattare eftersom de kan meddela tjänsten separat från att lyssna efter identifieringsmeddelanden. Tjänstmeddelande kan också användas som en mekanism för att registrera tjänster med en identifieringsproxy eller andra tjänstregister. Följande kod visar hur du konfigurerar en tjänst för att skicka meddelanden via en UDP-bindning.
Uri baseAddress = new Uri($"http://{System.Net.Dns.GetHostName()}:8000/discovery/scenarios/calculatorservice/{Guid.NewGuid().ToString()}/");
// Create a ServiceHost for the CalculatorService type.
using (ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService), baseAddress))
{
// Add calculator endpoint
serviceHost.AddServiceEndpoint(typeof(ICalculator), new WSHttpBinding(), string.Empty);
// ** DISCOVERY ** //
// Make the service discoverable by adding the discovery behavior
ServiceDiscoveryBehavior discoveryBehavior = new ServiceDiscoveryBehavior();
serviceHost.Description.Behaviors.Add(discoveryBehavior);
// Send announcements on UDP multicast transport
discoveryBehavior.AnnouncementEndpoints.Add(
new UdpAnnouncementEndpoint());
// ** DISCOVERY ** //
// Add the discovery endpoint that specifies where to publish the services
serviceHost.Description.Endpoints.Add(new UdpDiscoveryEndpoint());
// Open the ServiceHost to create listeners and start listening for messages.
serviceHost.Open();
// The service can now be accessed.
Console.WriteLine("Press <ENTER> to terminate service.");
Console.ReadLine();
}
Tjänsteidentifiering
Ett klientprogram kan använda DiscoveryClient klassen för att hitta tjänster. Utvecklaren skapar en instans av DiscoveryClient klassen som skickar in en identifieringsslutpunkt som anger var du ska skicka Probe eller Resolve meddelanden. Klienten anropar Find sedan som anger sökvillkor i en FindCriteria instans. Om matchande tjänster hittas Find returnerar en samling med EndpointDiscoveryMetadata. Följande kod visar hur du anropar Find metoden och sedan ansluter till en identifierad tjänst.
class Client
{
static EndpointAddress serviceAddress;
static void Main()
{
if (FindService())
{
InvokeService();
}
}
// ** DISCOVERY ** //
static bool FindService()
{
Console.WriteLine("\nFinding Calculator Service ..");
DiscoveryClient discoveryClient =
new DiscoveryClient(new UdpDiscoveryEndpoint());
Collection<EndpointDiscoveryMetadata> calculatorServices =
(Collection<EndpointDiscoveryMetadata>)discoveryClient.Find(new FindCriteria(typeof(ICalculator))).Endpoints;
discoveryClient.Close();
if (calculatorServices.Count == 0)
{
Console.WriteLine("\nNo services are found.");
return false;
}
else
{
serviceAddress = calculatorServices[0].Address;
return true;
}
}
static void InvokeService()
{
Console.WriteLine("\nInvoking Calculator Service at {0}\n", serviceAddress);
// Create a client
CalculatorClient client = new CalculatorClient();
client.Endpoint.Address = serviceAddress;
client.Add(10,3);
}
}
Säkerhet på identifierings- och meddelandenivå
När du använder säkerhet på meddelandenivå är det nödvändigt att ange en på tjänstidentifieringsslutpunkten EndpointIdentity och en matchning EndpointIdentity på klientidentifieringsslutpunkten. Mer information om säkerhet på meddelandenivå finns i Meddelandesäkerhet.
Identifierings- och webbvärdtjänster
För att WCF-tjänster ska kunna identifieras måste de köras. WCF-tjänster som finns under IIS eller WAS körs inte förrän IIS/WAS tar emot ett meddelande som är bundet till tjänsten, så de kan inte identifieras som standard. Det finns två alternativ för att göra webbaserade tjänster identifierbara:
Använda funktionen Starta automatiskt i Windows Server AppFabric
Använda en identifieringsproxy för att kommunicera för tjänstens räkning
Windows Server AppFabric har en funktion för automatisk start som gör att en tjänst kan startas innan meddelanden tas emot. Med den här automatiska startuppsättningen kan en IIS/WAS-värdbaserad tjänst konfigureras så att den kan identifieras. Mer information om funktionen Automatisk start finns i Funktionen Starta automatiskt i Windows Server AppFabric. Förutom att aktivera funktionen Starta automatiskt måste du konfigurera tjänsten för identifiering. Mer information finns i How to: Programmatically Add Discoverability to a WCF Service and Client Configuring Discovery in a Configuration File (Gör så här: Lägg till identifiering i en WCF-tjänst och klientkonfigureringsidentifieringi en konfigurationsfil via programmering).
En identifieringsproxy kan användas för att kommunicera för WCF-tjänstens räkning när tjänsten inte körs. Proxyn kan lyssna efter avsökningar eller lösa meddelanden och svara på klienten. Klienten kan sedan skicka meddelanden direkt till tjänsten. När klienten skickar ett meddelande till tjänsten instansieras den för att svara på meddelandet. Mer information om hur du implementerar en identifieringsproxy finns i Implementera en identifieringsproxy.
Kommentar
För att WCF-identifieringen ska fungera korrekt bör alla nätverkskort (nätverksgränssnittskontrollant) endast ha en IP-adress.