Service-Laufzeitausnahmebedingungen sind nicht deklarierte Ausnahmebedingungen. Im Allgemeinen stellen sie Fehlerbedingungen dar, die von der Anwendung nicht im Vorfeld vorausgesehen werden.
Mit Service-Laufzeitausnahmebedingungen werden nicht erwartete Zustände oder Bedingungen während der Laufzeit signalisiert.
Komponentenentwickler können folgendermaßen auf Service-Laufzeitausnahmebedingungen reagieren:
Wenn zum Beispiel ein Partner eine Anforderung nicht bedienen kann, kann dies unter Umständen durch einen anderen Partner erfolgen.
Eine Zeitlimitüberschreitung für einen Partner kann beispielsweise eine Business-Ausnahmebedingung zur Folge haben, die angibt, dass die Anforderung zum größten Teil verarbeitet wurde, aber die Bearbeitung eines Teils der Anforderung nicht abgeschlossen wurde und zu einem späteren Zeitpunkt oder mit anderen Parametern wiederholt werden sollte.
Wird eine Ausnahmebedingung nicht abgefangen, so wird sie an diejenige Komponente weitergegeben, von der die aktuelle Komponente aufgerufen wurde. Diese Aufrufkette setzt sich bis zum ursprünglichen aufrufenden Modul in der Kette fort. Angenommen, Modul A ruft Modul B auf und Modul B ruft Modul C auf, das seinerseits eine Ausnahmebedingung auslöst, die von Modul B abgefangen oder nicht abgefangen wird. Wenn Modul B die Ausnahmebedingung nicht abfängt, setzt sich diese rückwärtig zu Modul A fort.
Wenn eine ServiceRuntimeException von einer Komponente ausgelöst wird, wird ein Rollback für die aktuelle Transaktion durchgeführt. Diese Art der Ausnahmebehandlung wird für alle Komponenten in der Kette wiederholt. Beispiel: Wenn eine ServiceRuntimeException von Modul C ausgelöst wird, wird die betreffende Transaktion für ein Rollback markiert. Die Ausnahmebedingung wird anschließend für Modul B ausgelöst. Wird sie dort nicht abgefangen und ist eine andere Transaktion vorhanden, wird für diese Transaktion ebenfalls ein Rollback durchgeführt. Entwickler von Komponenten können mit Hilfe von QoS-Qualifikationsmerkmalen (QoS = Quality of Service, Servicequalität) steuern, ob Aufrufe in der aktuellen Transaktion oder in einer neuen Transaktion erfolgen. Angenommen, Modul A ruft Modul B auf und Modul B ist Teil einer neuen Transaktion. In diesem Fall kann Modul A eine 'ServiceRuntimeException' von Modul B abfangen und die Verarbeitung fortsetzen, ohne ein Rollback für die Transaktion aus Modul A durchzuführen.
Dabei ist zu beachten, dass der Inhalt der Transaktion nach dem Rollback je nach Art der Transaktion variieren kann. Beispielsweise können BPEL-Prozesse mit langer Laufzeit in zahlreiche kleinere Transaktionen aufgeteilt werden. Asynchrone Anforderungs- und Antwortaufrufe werden automatisch aus einer Transaktion herausgelöst (andernfalls muss die aufrufende Anwendung möglicherweise lange auf die Antwort warten).
Ist eine Transaktion in mehrere asynchrone Aufrufe aufgeteilt, wird für die anfängliche Verarbeitung der Transaktion ein Rollback durchgeführt, wenn eine ServiceRuntimeException auftritt. Die Antwort des asynchronen Aufrufs wird jedoch von einer anderen Transaktion übermittelt. Da die Antwort des asynchronen Aufrufs ins Leere laufen würde, wird ein Ereignis im Failed Event Manager (FEM) erstellt.
Die folgende Liste enthält vier derzeitige Unterklassen von ServiceRuntimeException:
Mit dieser Ausnahmebedingung wird angegeben, dass eine asynchrone SCA-Nachricht abgelaufen ist. Die Verfallszeiten können durch Verwendung des Qualifikationsmerkmals 'RequestExpiration' für eine Servicereferenz festgelegt werden.
Mit dieser Ausnahmebedingung wird angegeben, dass die Antwort auf eine asynchrone Anforderung nicht innerhalb der konfigurierten Zeitspanne empfangen wurde. Die Verfallszeiten können durch Verwendung des Qualifikationsmerkmals 'ResponseExpiration' für eine Servicereferenz festgelegt werden.
Mit dieser Ausnahmebedingung wird angegeben, dass beim Aufrufen eines externen Service über einen Import eine Ausnahmebedingung ausgelöst wurde.
Mit dieser Ausnahmebedingung wird angegeben, dass die Servicereferenz auf der Komponente nicht korrekt verbunden ist.