SIG-Regelwerk: Regelwerk von Serviceimplementierungsgruppen

Im Folgenden wird das Regelwerk beschrieben, wie Services den zugehörigen Datenkontext finden usw.

• Eine SIG definiert auf welchen Systemstrukturelementen eine Gruppe von Services nutzbar ist.
  • Ein Service, der keiner SIG zugeordnet ist oder ein Service, dessen SIG keinem Systemstrukturelement zugeordnet ist, kann nicht aufgerufen werden.
  • Der Aufruf ist nur erfolgreich, wenn auf dem aktuellen Anmeldeknoten das ggf. erforderliche DB-Schema des zugehörigen Bausteins zugeordnet ist.
  • Bei Zuordnung der SIG zu einem Systemstrukturelement in der Systemstruktur werden die zur SIG gehörenden Services dort aufgerufen.
    • Die Suchstrategie startet für Services (außer Event Services) auf dem aktuellen Anmeldeknoten. Wenn dort die SIG nicht zugeordnet ist, wird im Baum nach oben nach der SIG-Zuordnung gesucht. Der erste Treffer liefert den Datenkontext der Ausführung. Wird kein Treffer gefunden, erhält der Aufrufer einen Fehler.
    • Die Suchstrategie für Event Services (Subscriber) beginnt auf dem aktuellen Anmeldeknoten. Wenn dort die SIG nicht zugeordnet ist, wird im Baum nach unten nach allen SIG-Zuordnungen durchsucht. Für alle Treffer wird der Service für den Knoten ausgeführt.
  • Technischer Hinweis: Der Datenkontext der Ausführung wird über das SessionToken abgebildet.
• SIGs können genutzt werden, um Regelsätze zu definieren, mit deren Hilfe automatisch überprüft werden kann, ob die Zuordnung der SIG zu Systemstrukturelementen den vom Programmierer vorgesehenen Randbedingungen entspricht.
  • Für SIGs können Vorschläge bzgl. der Zuordnung zu Systemstrukturelementen genutzt werden, die den Administrator bei der Konfiguration des Systems unterstützen. Der Administrator entscheidet, ob er dem Vorschlag folgt oder nicht. Unabhängig von seiner Entscheidung kann er die an den SIGs definierten Regelsätze nutzen, um die gewählte Konfiguration auf Gültigkeit zu überprüfen.
• Indirekt wirken sich SIGs auch auf die Zuordnung von DB-Schemata zu Systemstrukturelementen aus, da die Services DB-Schemata für die Persistenz benötigen.

Hierdurch ist es möglich, beispielsweise Services als Katalogdienste zu verwenden. Hiermit lassen sich viele Datenredundanzen und damit verbundene Probleme anderer Architekturlösungen vermeiden!