Patroon Circuitonderbreker

Handel fouten af waarvoor een wisselende hoeveelheid tijd nodig is om van te herstellen bij het verbinden met een externe service of resource. Dit kan de stabiliteit en flexibiliteit van een toepassing verbeteren.

Context en probleem

In een gedistribueerde omgeving kunnen aanroepen naar externe resources en services mislukken door tijdelijke fouten, zoals trage netwerkverbindingen, time-outs of resources die overbelast of tijdelijk niet beschikbaar zijn. Na een korte periode corrigeren deze fouten zich doorgaans zelf. Er moet een robuuste cloudtoepassing worden voorbereid om deze met behulp van een strategie, zoals het Patroon Opnieuw proberen, af te handelen.

Er kunnen zich echter ook situaties voordoen waarbij fouten het gevolg zijn van onverwachte gebeurtenissen en die kunnen veel meer tijd kosten om op te lossen. Deze fouten kunnen in ernst variëren, van een gedeeltelijke verbroken verbinding tot het volledig uitvallen van een service. In dergelijke situaties is het voor een toepassing zinloos om voortdurend een bewerking opnieuw te proberen die waarschijnlijk toch niet zal slagen. In plaats daarvan moet de toepassing snel accepteren dat de bewerking is mislukt en deze fout dienovereenkomstig afhandelen.

Als een service bezet is, kan een storing in een deel van het systeem bovendien leiden tot een opeenstapeling van storingen. Een bewerking die een service aanroept kan bijvoorbeeld zo worden geconfigureerd dat deze een time-out implementeert en reageert met een foutbericht als de service niet reageert binnen deze periode. Deze strategie kan er echter toe leiden dat veel gelijktijdige aanvragen voor deze bewerking worden geblokkeerd totdat de time-outperiode is verstreken. Deze geblokkeerde aanvragen kunnen kritische systeemresources bevatten, zoals geheugen, threads, databaseverbindingen enzovoort. Als gevolg daarvan kunnen deze resources uitgeput raken en dat kan leiden tot fouten van andere mogelijk niet-gerelateerde onderdelen van het systeem die dezelfde resources gebruiken. In deze situaties is het beter als de bewerking meteen mislukt en de service alleen aanroept als deze waarschijnlijk met succes wordt uitgevoerd. Dit probleem kan worden opgelost door een kortere time-out in te stellen. De time-out mag echter niet zo kort zijn dat de bewerking in de meeste gevallen mislukt, zelfs als de aanvraag naar de service uiteindelijk slaagt.

Oplossing

Het patroon Circuitonderbreker, gepopulariseerd door Michael Nygard in zijn boek Release It!, kan voorkomen dat een toepassing herhaaldelijk probeert een bewerking uit te voeren die waarschijnlijk zal mislukken. Hierdoor gaat deze verder zonder te wachten tot de fout is hersteld of er CPU-cycli worden verspild terwijl er wordt vastgesteld dat de fout langdurig is. Met het patroon Circuitonderbreker kan een toepassing ook detecteren of de fout is opgelost. Als het probleem lijkt te zijn opgelost, kan de toepassing de bewerking proberen aan te roepen.

Het doel van het patroon Circuitonderbreker verschilt van het patroon Opnieuw proberen. Met het patroon Opnieuw proberen probeert een toepassing een bewerking opnieuw in de verwachting dat deze zal slagen. Met het patroon Circuitonderbreker wordt voorkomen dat een toepassing een bewerking uitvoert die waarschijnlijk zal mislukken. Een toepassing kan deze twee patronen combineren door het patroon Opnieuw proberen te gebruiken om een bewerking aan te roepen via een circuitonderbreker. De pogingslogica moet echter gevoelig zijn voor eventuele uitzonderingen die door de circuitonderbreker worden geretourneerd en moet nieuwe pogingen afbreken als de circuitonderbreker aangeeft dat een fout niet tijdelijk is.

Een circuitonderbreker fungeert als een proxy voor bewerkingen die kunnen mislukken. De proxy moet het aantal recente fouten dat is opgetreden bewaken en deze informatie gebruiken om te bepalen of de bewerking moet doorgaan of dat er onmiddellijk een uitzondering moet worden geretourneerd.

De proxy kan worden geïmplementeerd als een toestandsmachine met de volgende statussen die de functionaliteit van een elektrische circuitonderbreker nabootsen:

• Gesloten: de aanvraag van de toepassing wordt doorgestuurd naar de bewerking. De proxy houdt een telling bij van het aantal recente fouten en als de aanroep naar de bewerking mislukt, verhoogt de proxy dit aantal. Als het aantal recente fouten binnen een bepaalde tijdsperiode een opgegeven drempelwaarde overschrijdt, wordt de proxy in de status Open geplaatst. De proxy start op dat moment een time-outtimer. Wanneer deze timer verloopt, wordt de proxy in de status Halfopen geplaatst.

  Het doel van de time-outtimer is om het systeem tijd te geven om het probleem dat de fout heeft veroorzaakt op te lossen, voordat de toepassing de bewerking opnieuw mag proberen uit te voeren.

• Open: de aanvraag van de toepassing mislukt onmiddellijk en er wordt een uitzondering naar de toepassing geretourneerd.

• Halfopen: een beperkt aantal aanvragen van de toepassing mag worden doorgegeven en de bewerking aanroepen. Als deze aanvragen zijn geslaagd, wordt ervan uitgegaan dat de fout die eerder de storing heeft veroorzaakt, is opgelost en de circuitonderbreker schakelt naar de status Gesloten (de foutenteller wordt opnieuw ingesteld). Als een aanvraag mislukt, gaat de circuitonderbreker ervan uit dat de fout nog steeds aanwezig is, zodat deze teruggaat naar de status Openen en de time-outtimer opnieuw start om het systeem een verdere periode te geven om te herstellen van de fout.

  De status Halfopen is handig om te voorkomen dat een herstellende service plotseling wordt overspoeld met aanvragen. Wanneer een service herstelt, kan deze mogelijk een beperkt aantal aanvragen ondersteunen totdat het herstel is voltooid. Maar wanneer het herstelproces wordt uitgevoerd, kan een grote hoeveelheid werk ertoe leiden dat er opnieuw een time-out van de service optreedt of dat deze nogmaals mislukt.

De foutenteller die in de afbeelding wordt gebruikt door de status Gesloten is gebaseerd op tijd. Deze wordt periodiek automatisch opnieuw ingesteld. Dit helpt te voorkomen dat de circuitonderbreker naar de status Open schakelt als er incidentele fouten optreden. De foutdrempelwaarde waarbij de circuitonderbreker de status Open activeert, wordt alleen bereikt wanneer een opgegeven aantal fouten is opgetreden tijdens een opgegeven interval. De teller die door de status Halfopen wordt gebruikt, legt het aantal geslaagde pogingen om de bewerking aan te roepen vast. De circuitonderbreker keert terug naar de status Gesloten nadat een opgegeven aantal opeenvolgende bewerkingsaanroepen is geslaagd. Als een aanroep is mislukt, schakelt de circuitonderbreker onmiddellijk naar de status Open. De teller voor succes wordt opnieuw ingesteld wanneer er naar de status Halfopen wordt geschakeld.

Hoe het systeem herstelt, wordt extern afgehandeld, bijvoorbeeld door het herstellen of opnieuw starten van een mislukt onderdeel of het herstellen van een netwerkverbinding.

Het patroon Circuitonderbreker biedt stabiliteit terwijl het systeem van een fout herstelt en minimaliseert de gevolgen met betrekking tot prestaties. Het kan helpen om de reactietijd van het systeem te behouden door een aanvraag voor een bewerking die waarschijnlijk gaat mislukken snel te weigeren, in plaats van te wachten totdat er een time-out optreedt of de bewerking nooit terugkeert. Als de circuitonderbreker een gebeurtenis genereert telkens wanneer de status wijzigt, kan deze informatie worden gebruikt om de status van het onderdeel van het systeem dat door de circuitonderbreker wordt beveiligd te bewaken of om een beheerder te waarschuwen wanneer een circuitonderbreker naar de status Open schakelt.

Het patroon kan worden aangepast op basis van het type van de mogelijke fout. U kunt bijvoorbeeld een toenemende time-outtimer toepassen op een circuitonderbreker. U kunt de circuitonderbreker in eerste instantie voor een paar seconden in de status Open plaatsen en als de fout vervolgens niet wordt opgelost, de time-out met een paar minuten verhogen enzovoort. In sommige gevallen kan het handig zijn om een standaardwaarde te retourneren die zinvol is voor de toepassing, in plaats van dat de status Open een fout retourneert en een uitzondering genereert.

Problemen en overwegingen

U moet de volgende punten overwegen wanneer u besluit hoe u dit patroon wilt implementeren:

Afhandeling van uitzonderingen. Een toepassing die een bewerking via een circuitonderbreker aanroept, moet worden voorbereid om de uitzonderingen die optreden af te handelen als de bewerking niet beschikbaar is. De manier waarop uitzonderingen worden afgehandeld, is toepassingsspecifiek. Een toepassing kan bijvoorbeeld de functionaliteit tijdelijk verlagen, een alternatieve bewerking aanroepen om te proberen dezelfde taak uit te voeren of dezelfde gegevens te verkrijgen, of de uitzondering aan de gebruiker rapporteren en vragen het later opnieuw te proberen.

Typen uitzonderingen. Een aanvraag kan om verschillende redenen mislukken. Sommige kunnen duiden op een ernstiger type fout dan andere. Een aanvraag kan bijvoorbeeld mislukken omdat een externe service is vastgelopen en het enkele minuten duurt voordat deze is hersteld of vanwege een time-out doordat de service tijdelijk is overbelast. Een circuitonderbreker kan mogelijk de typen uitzonderingen die optreden onderzoeken en de strategie aanpassen afhankelijk van de aard van deze uitzonderingen. Er zijn bijvoorbeeld meer time-outuitzonderingen nodig om de circuitonderbreker naar de status Open te laten schakelen vergeleken met het aantal fouten dat is veroorzaakt doordat de service helemaal niet beschikbaar is.

Logboekregistratie. Een circuitonderbreker moet alle mislukte aanvragen (en eventuele geslaagde aanvragen) registreren, zodat een beheerder de status van de bewerking kan controleren.

Herstelmogelijkheden. U moet de circuitonderbreker zo configureren dat deze overeenkomt met het waarschijnlijke herstelpatroon van de bewerking die erdoor wordt beveiligd. Als de circuitonderbreker bijvoorbeeld gedurende een lange periode in de status Open blijft, kan deze uitzonderingen genereren, zelfs als de oorzaak van het probleem is opgelost. Op dezelfde manier kan een circuitonderbreker variëren en de reactietijden van toepassingen verkorten als deze te snel van de status Open naar de status Halfopen schakelt.

Mislukte bewerkingen testen. In plaats van in de status Open een timer te gebruiken om te bepalen wanneer er naar de status Halfopen moet worden geschakeld, kan een circuitonderbreker ook periodiek een ping-opdracht naar de externe service of resource verzenden om te bepalen of deze weer beschikbaar is. Deze ping kan de vorm hebben van een poging om een bewerking die eerder is mislukt aan te roepen of deze kan een speciale bewerking gebruiken die specifiek door de externe service wordt geleverd voor het testen van de status van de service, zoals is beschreven in Health Endpoint Monitoring pattern (Patroon Eindpuntstatusbewaking).

Handmatig overschrijven. In een systeem waarbij de hersteltijd voor een mislukte bewerking uiterst variabel is, is het nuttig om een handmatige optie voor opnieuw instellen te bieden waarmee een beheerder een circuitonderbreker kan sluiten (en de foutenteller opnieuw kan instellen). Op dezelfde manier kan een beheerder een circuitonderbreker afdwingen om naar de status Open te schakelen (en de time-outtimer opnieuw te starten) als de bewerking die door de circuitonderbreker wordt beveiligd tijdelijk niet beschikbaar is.

Gelijktijdigheid. Dezelfde circuitonderbreker kan worden geopend door een groot aantal gelijktijdige exemplaren van een toepassing. De implementatie mag gelijktijdige aanvragen niet blokkeren of overmatige overhead toevoegen aan elke aanroep naar een bewerking.

Resourcedifferentiatie. Wees voorzichtig met het gebruik van een enkele circuitonderbreker voor één type resource als er mogelijk meerdere onderliggende onafhankelijke providers zijn. In een gegevensopslag met meerdere shards kan bijvoorbeeld één shard volledig toegankelijk zijn terwijl een andere een tijdelijk probleem ondervindt. Als de foutberichten in deze scenario's worden samengevoegd, kan een toepassing toegang proberen te krijgen tot sommige shards zelfs wanneer dit zeer waarschijnlijk gaat mislukken, terwijl de toegang tot andere shards mogelijk is geblokkeerd zelfs als dit waarschijnlijk met succes wordt uitgevoerd.

Versneld circuits onderbreken. Soms kan een foutantwoord voldoende informatie voor de circuitonderbreker bevatten om onmiddellijk geactiveerd te worden en een minimale periode geactiveerd te blijven. Het foutbericht van een gedeelde resource die is overbelast kan er bijvoorbeeld op duiden dat een directe nieuwe poging niet wordt aanbevolen en dat de toepassing het over enkele minuten opnieuw moet proberen.

Mislukte aanvragen opnieuw afspelen. In plaats van snel mislukken in de status Open kan een circuitonderbreker ook de details van elke aanvraag in een logboek vastleggen en ervoor zorgen dat deze aanvragen opnieuw worden afgespeeld zodra de externe resource of service beschikbaar is.

Ongeschikte time-outs op externe services. Een circuitonderbreker kan mogelijk toepassingen niet volledig beveiligen tegen bewerkingen die mislukken in externe services die zijn geconfigureerd met een langdurige time-outperiode. Als de time-out te lang is, kan een thread die een circuitonderbreker uitvoert gedurende een lange tijd worden geblokkeerd, voordat de circuitonderbreker aangeeft dat de bewerking is mislukt. Gedurende deze tijd kunnen ook veel andere exemplaren van de toepassing de service proberen aan te roepen via de circuitonderbreker en een groot aantal threads bezighouden voordat ze allemaal mislukken.

Wanneer dit patroon gebruiken

U gebruikt dit patroon voor het volgende:

• Als u wilt voorkomen dat een toepassing een externe service probeert aan te roepen of toegang krijgt tot een gedeelde resource als deze bewerking zeer waarschijnlijk zal mislukken.

Dit patroon wordt niet aanbevolen voor het volgende:

• Voor de afhandeling van toegang tot lokale persoonlijke resources in een toepassing, zoals de gegevensstructuur in het geheugen. In deze omgeving voegt het gebruik van een circuitonderbreker overhead toe aan uw systeem.
• Als alternatief voor het afhandelen van uitzonderingen in de bedrijfslogica van uw toepassingen.

Workloadontwerp

Een architect moet evalueren hoe het circuitonderbrekerpatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

In een webtoepassing worden verschillende pagina's ingevuld met gegevens die uit een externe service worden opgehaald. Als het systeem minimale caching implementeert, veroorzaken de meeste treffers naar deze pagina's een retour naar de service. Verbindingen van de webtoepassing naar de service kunnen worden geconfigureerd met een time-outperiode (meestal 60 seconden). Als de service niet binnen deze tijd reageert, gaat de logica in elke webpagina ervan uit dat de service niet beschikbaar is en wordt er een uitzondering gegenereerd.

Als de service echter mislukt en het systeem erg druk is, kunnen gebruikers worden gedwongen om tot 60 seconden te wachten voordat er een uitzondering optreedt. Uiteindelijk kunnen resources, zoals geheugen, verbindingen en threads, zijn uitgeput, waardoor andere gebruikers geen verbinding kunnen maken met het systeem, zelfs als ze de pagina's die gegevens uit de service ophalen niet openen.

Het schalen van het systeem door meer webservers toe te voegen en taakverdeling te implementeren, kan vertraging oplopen wanneer resources uitgeput raken. Dit lost het probleem niet op, omdat er niet op gebruikersaanvragen wordt gereageerd en alle webservers uiteindelijk nog steeds zonder resources kunnen komen te zitten.

Het verpakken van de logica die is verbonden met de service en de gegevens in een circuitonderbreker ophaalt, kan helpen dit probleem op te lossen en de fout in de service beter af te handelen. Gebruikersaanvragen mislukken nog steeds, maar ze mislukken sneller en de resources worden niet geblokkeerd.

De CircuitBreaker-klasse houdt de statusinformatie bij over een circuitonderbreker in een object dat de ICircuitBreakerStateStore-interface implementeert. Deze wordt in de volgende code weergegeven.

interface ICircuitBreakerStateStore
{
  CircuitBreakerStateEnum State { get; }

  Exception LastException { get; }

  DateTime LastStateChangedDateUtc { get; }

  void Trip(Exception ex);

  void Reset();

  void HalfOpen();

  bool IsClosed { get; }
}

De eigenschap State geeft de huidige status van de circuitonderbreker aan. Deze is Open, Halfopen of Gesloten, zoals door de CircuitBreakerStateEnum-opsomming wordt gedefinieerd. De eigenschap IsClosed moet true zijn als de circuitonderbreker is gesloten, maar false als deze open of halfopen is. De methode Trip verandert de status van de circuitonderbreker in de status Open en registreert de uitzondering die de wijziging in de status heeft veroorzaakt, samen met de datum en tijd waarop de uitzondering heeft plaatsgevonden. De eigenschappen LastException en LastStateChangedDateUtc retourneren deze informatie. De methode Reset sluit de circuitonderbreker en de methode HalfOpen stelt de circuitonderbreker in op Halfopen.

De InMemoryCircuitBreakerStateStore-klasse in het voorbeeld bevat een implementatie van de ICircuitBreakerStateStore-interface. De CircuitBreaker-klasse maakt een exemplaar van deze klasse om de status van de circuitonderbreker te behouden.

De ExecuteAction-methode in de CircuitBreaker-klasse verpakt een bewerking, die is opgegeven als een Action-gemachtigde. Als de circuitonderbreker is gesloten, roept ExecuteAction de Action-gemachtigde aan. Als de bewerking is mislukt, roept een uitzonderingshandler TrackException aan die de status van de circuitonderbreker instelt op Open. Het volgende codevoorbeeld licht deze stroom toe.

public class CircuitBreaker
{
  private readonly ICircuitBreakerStateStore stateStore =
    CircuitBreakerStateStoreFactory.GetCircuitBreakerStateStore();

  private readonly object halfOpenSyncObject = new object ();
  ...
  public bool IsClosed { get { return stateStore.IsClosed; } }

  public bool IsOpen { get { return !IsClosed; } }

  public void ExecuteAction(Action action)
  {
    ...
    if (IsOpen)
    {
      // The circuit breaker is Open.
      ... (see code sample below for details)
    }

    // The circuit breaker is Closed, execute the action.
    try
    {
      action();
    }
    catch (Exception ex)
    {
      // If an exception still occurs here, simply
      // retrip the breaker immediately.
      this.TrackException(ex);

      // Throw the exception so that the caller can tell
      // the type of exception that was thrown.
      throw;
    }
  }

  private void TrackException(Exception ex)
  {
    // For simplicity in this example, open the circuit breaker on the first exception.
    // In reality this would be more complex. A certain type of exception, such as one
    // that indicates a service is offline, might trip the circuit breaker immediately.
    // Alternatively it might count exceptions locally or across multiple instances and
    // use this value over time, or the exception/success ratio based on the exception
    // types, to open the circuit breaker.
    this.stateStore.Trip(ex);
  }
}

Het volgende voorbeeld toont de code (die is weggelaten uit het vorige voorbeeld) die wordt uitgevoerd als de circuitonderbreker niet is gesloten. Deze controleert eerst of de circuitonderbreker is geopend voor een langere periode dan de tijd die is opgegeven in het lokale veld OpenToHalfOpenWaitTime in de CircuitBreaker-klasse. Als dit het geval is, stelt de methode ExecuteAction de circuitonderbreker in op Halfopen. Vervolgens probeert deze de bewerking uit te voeren die is opgegeven door de Action-gemachtigde.

Als de bewerking is voltooid, wordt de circuitonderbreker teruggezet naar de status Gesloten. Als de bewerking is mislukt, wordt deze teruggezet naar de status Open en wordt de tijd waarop de uitzondering heeft plaatsgevonden bijgewerkt, zodat de circuitonderbreker nog een periode wacht voordat deze de bewerking opnieuw probeert uit te voeren.

Als de circuitonderbreker alleen voor een korte periode is geopend, korter dan de waarde OpenToHalfOpenWaitTime, genereert de methode ExecuteAction een CircuitBreakerOpenException-uitzondering en retourneert deze de fout die ervoor heeft gezorgd dat de circuitonderbreker naar de status Open schakelde.

Bovendien gebruikt deze een vergrendeling om te voorkomen dat de circuitonderbreker probeert gelijktijdige aanroepen naar de bewerking uit te voeren terwijl deze halfopen is. Een gelijktijdige poging tot het aanroepen van de bewerking wordt afgehandeld alsof de circuitonderbreker geopend was en mislukt met een uitzondering, zoals verderop wordt beschreven.

    ...
    if (IsOpen)
    {
      // The circuit breaker is Open. Check if the Open timeout has expired.
      // If it has, set the state to HalfOpen. Another approach might be to
      // check for the HalfOpen state that had be set by some other operation.
      if (stateStore.LastStateChangedDateUtc + OpenToHalfOpenWaitTime < DateTime.UtcNow)
      {
        // The Open timeout has expired. Allow one operation to execute. Note that, in
        // this example, the circuit breaker is set to HalfOpen after being
        // in the Open state for some period of time. An alternative would be to set
        // this using some other approach such as a timer, test method, manually, and
        // so on, and check the state here to determine how to handle execution
        // of the action.
        // Limit the number of threads to be executed when the breaker is HalfOpen.
        // An alternative would be to use a more complex approach to determine which
        // threads or how many are allowed to execute, or to execute a simple test
        // method instead.
        bool lockTaken = false;
        try
        {
          Monitor.TryEnter(halfOpenSyncObject, ref lockTaken);
          if (lockTaken)
          {
            // Set the circuit breaker state to HalfOpen.
            stateStore.HalfOpen();

            // Attempt the operation.
            action();

            // If this action succeeds, reset the state and allow other operations.
            // In reality, instead of immediately returning to the Closed state, a counter
            // here would record the number of successful operations and return the
            // circuit breaker to the Closed state only after a specified number succeed.
            this.stateStore.Reset();
            return;
          }
        }
        catch (Exception ex)
        {
          // If there's still an exception, trip the breaker again immediately.
          this.stateStore.Trip(ex);

          // Throw the exception so that the caller knows which exception occurred.
          throw;
        }
        finally
        {
          if (lockTaken)
          {
            Monitor.Exit(halfOpenSyncObject);
          }
        }
      }
      // The Open timeout hasn't yet expired. Throw a CircuitBreakerOpen exception to
      // inform the caller that the call was not actually attempted,
      // and return the most recent exception received.
      throw new CircuitBreakerOpenException(stateStore.LastException);
    }
    ...

Als u een CircuitBreaker-object wilt gebruiken om een bewerking te beveiligen, maakt een toepassing een exemplaar van de CircuitBreaker-klasse en roept deze de methode ExecuteAction aan waarbij de bewerking wordt opgegeven die als de parameter moet worden uitgevoerd. De toepassing moet worden voorbereid om de CircuitBreakerOpenException-uitzondering op te vangen als de bewerking mislukt, omdat de circuitonderbreker is geopend. In de volgende code ziet u een voorbeeld:

var breaker = new CircuitBreaker();

try
{
  breaker.ExecuteAction(() =>
  {
    // Operation protected by the circuit breaker.
    ...
  });
}
catch (CircuitBreakerOpenException ex)
{
  // Perform some different action when the breaker is open.
  // Last exception details are in the inner exception.
  ...
}
catch (Exception ex)
{
  ...
}

Verwante resources

De volgende patronen zijn mogelijk ook nuttig bij de implementatie van dit patroon:

• Betrouwbaar web-app-patroon laat zien hoe u het circuitonderbrekerpatroon kunt toepassen op webtoepassingen die in de cloud worden samengevoegd.

• Retry-patroon. Beschrijft hoe een toepassing verwachte, tijdelijke fouten kan afhandelen als er wordt geprobeerd om verbinding te maken met een service of netwerkresource door een bewerking die eerder is mislukt, transparant opnieuw te proberen.

• Patroon Statuseindpuntbewaking. Een circuitonderbreker kan mogelijk de status van een service testen door een aanvraag naar een eindpunt te verzenden die door de service wordt weergegeven. De service moet informatie retourneren die de status aangeeft.