Quality of Service beim Messaging

Rebinding

Beschreibt den Umfang des Transparenten Rebindings die im Ablauf bei einem Objektaufruf geschehen kann.

• TRANSPARENT: der ORB kann leise die Objektweiterleitung (forwarding) und notwendige wiederverbindungen während dem Lauf eines Fernaufrufs machen (Entspricht dem bisherigen Standard).
• NO_BEBIND: Es sind wiederverbindungen, aber keine weiterleitungen erlaubt. (mit CORBA::Object::validate_connection kann dann explizet weiterverbinden werden)
• No_RECONNECT: verhindert sowohl Weiterleitungen als auch Wiederverbindungen verboten. (mit CORBA::Object::validate_connection kann dann explizet weiterverbinden werden)

SyncScope

Beschreibt den Synchronisationsumfang im Bezug auf das Target:

• SYNC_NONE: ORB übergibt sofort die Kontrolle an Client zurück, noch bevor er die Nachricht auf den Transport setzt. Grarantiert Nichtb-Bokierend für den Client. Da keine Antwort vom Server kommt, kann keine Weiterleitung an einen anderen ORB gemacht werden. vgl. CORBA oneway-Aufruf.
• SYNC_WITH_TRANSPORT: ORB übergibt die Kontrolle an die Client zurück, wenn der Transport die Nachricht akzeptiert hat.
  Die gegebene Garantie hängt vom Transport ab.
  (vgl. oneway-Aufruf)
  Kein Reply, daher keine Ortsweiterleitung.
• SYNC_WITH_SERVER: Der ORB auf der Serverseite sendt eine Antwort bevor er den Aufruf macht. Wenn NO_EXCEPTION gesendet wird, ist jegliche Ortweiterleitung schon vollzogen. Danach übergibt der Client-ORB die kontrolle wieder an den Aufrufer.

  Bei POA: Antwort nach aufruf von ServantManager, vor Implementierungsaufruf. Anwendung ist dan gut, wenn Verbindungsverfügbarkeit wesentlich geringer als die Serververfügbarkeit ist.
  

• SYNC_WITH_TARGET: wie synchrone, nicht-enweg-Operation in CORBA.

  ORB gibt erst die Kontrolle zurück, wenn das Zielobjekt seinen aufruf vollendet hat.
  Jede LOCATION_FORWARD ist schon vor dem Target-Aufruf gesendet worden. Eine SYSTEM_EXCEPTION kann zu jeder Zeit gesndet werden.
  Transaktionsdienst kann nur mit diesem höchsten Synchronisationsart arbeiten.

Priority

die Prorität wird von Routern berücksichtigt.

Timeout

Lebensdauer eines Requests.
Sowohl für asynchrone als auch für Syncrone Ereignisse.

Starttime-Policy: Startzeit der Operation (Nur von Clientseite überschreibbar).
EndTime-Policy: Zeit, ab der dier Request nicht mahe verarbeitet werden soll. (Nur Cliensteitige überschreibung)
Reply Start Time: Zeit, ab der Client geantwortet wird (Nur clientseitige überschreibung)
Reply EndTime: zeit, ab der die Antwort nicjt mehr vom Client erhalten oder an ihn zurüchgeliefert werden soll
Relative REQ Time-Out Policy: Relative Zeit in der ein Request zugestellt wird.
Relative RT Time Out Policy: (RT:Round Trip: Zeit in der Nachricht beantwortet sein muß.

RoutingType

• ROUTE_NONE: Es wird Synchrone oder aufgeschobene (defferd) Synchrone Zustellung genutzt. Router werden nicht benutzt.
• ROUTE_FORWARD: Asynchrone Zustellung wird benutzt. Der Request wird an einen Router geschickt und nicht direkt an das Ziel.
• ROUTE_STORE_AND_FORWARD: Asynchrone Zustellung, über einen Router, der den Request persistent speichert und dann die Zustellung versucht.

Der POA hat auch eine RoutingPolicy und daher ist sie auch in den Referenzen vorhanden. Der Client kann auch wünsche angeben und es wird ein Durchschnitt genommen.

Max Hops: Es kann angegeben werddn, wieviele Router auf dem Weg liegen dürfen.

Queue Ordering

Reihenfolge, wie die Warteschlange abfeageitet wird:

• QUEUE_ANY
• ORDER_TEMPORAL FIFO, default
• ORDER_PRIORITY
• ORDER_DEADLINE

Politiken wird in IOP mit eingebaut, macht der POA