Clienttoepassingen in de middelste laag
In dit onderwerp worden verschillende problemen besproken die specifiek zijn voor clienttoepassingen in de middelste laag die gebruikmaken van WCF (Windows Communication Foundation).
Hogere clientprestaties in de middelste laag
Vergeleken met eerdere communicatietechnologieën, zoals webservices die gebruikmaken van ASP.NET, kan het maken van een WCF-clientexemplaren complexer zijn vanwege de uitgebreide functieset WCF. Wanneer een ChannelFactory<TChannel> object bijvoorbeeld wordt geopend, kan het een beveiligde sessie met de service tot stand brengen, een procedure waarmee de opstarttijd voor het clientexemplaren wordt verhoogd. Deze aanvullende functiemogelijkheden zijn doorgaans niet van invloed op clienttoepassingen, omdat de WCF-client verschillende aanroepen doet en vervolgens wordt gesloten.
Clienttoepassingen in de middelste laag kunnen echter snel veel WCF-clientobjecten maken en daardoor meer initialisatievereisten ervaren. Er zijn twee belangrijke benaderingen voor het verhogen van de prestaties van toepassingen in de middelste laag bij het aanroepen van services:
Sla het WCF-clientobject in de cache op en gebruik het opnieuw voor volgende aanroepen waar mogelijk.
Maak een ChannelFactory<TChannel> object en gebruik dat object vervolgens om nieuwe WCF-clientkanaalobjecten te maken voor elke aanroep.
Problemen waarmee u rekening moet houden bij het gebruik van deze benaderingen zijn onder andere:
Als de service een clientspecifieke status onderhoudt met behulp van een sessie, kunt u de WCF-client in de middelste laag niet opnieuw gebruiken met aanvragen voor meerdere clientlagen omdat de status van de service is gekoppeld aan die van de client in de middelste laag.
Als de service verificatie per client moet uitvoeren, moet u een nieuwe client maken voor elke binnenkomende aanvraag op de middelste laag in plaats van de WCF-client (of wcF-clientkanaalobject) opnieuw te gebruiken omdat de clientreferenties van de middelste laag niet kunnen worden gewijzigd nadat de WCF-client (of ChannelFactory<TChannel>) is gemaakt.
Hoewel kanalen en clients die door de kanalen zijn gemaakt, thread-veilig zijn, bieden ze mogelijk geen ondersteuning voor het gelijktijdig schrijven van meer dan één bericht naar de kabel. Als u grote berichten verzendt, met name als streaming, kan de verzendbewerking blokkeren totdat een andere verzending is voltooid. Dit veroorzaakt twee soorten problemen: een gebrek aan gelijktijdigheid en de mogelijkheid van impasse als de controlestroom terugkeert naar de service die het kanaal hergebruikt (dat wil gezegd, roept de gedeelde client een service aan waarvan het codepad resulteert in een callback naar de gedeelde client). Dit geldt ongeacht het type WCF-client dat u opnieuw gebruikt.
U moet defecte kanalen afhandelen, ongeacht of u het kanaal deelt. Wanneer kanalen opnieuw worden gebruikt, kan een foutkanaal echter meer dan één aanvraag in behandeling of verzenden uitschakelen.
Zie Gegevensbinding in een ASP.NET-client voor een voorbeeld met aanbevolen procedures voor het hergebruiken van een client voor meerdere aanvragen.
Daarnaast kunt u de opstartprestaties verhogen voor clients die gebruikmaken van gegevenstypen die serialiseren met behulp van de XmlSerializer serialisatiecode genereren en compileren voor deze gegevenstypen tijdens runtime, wat kan leiden tot trage opstartprestaties. Het hulpprogramma hulpprogramma voor metagegevens van ServiceModel (Svcutil.exe) kan de opstartprestaties voor deze toepassingen verbeteren door de benodigde serialisatiecode te genereren van de gecompileerde assembly's voor de toepassing. Zie Procedures voor meer informatie: De opstarttijd van WCF-clienttoepassingen verbeteren met behulp van de XmlSerializer.