bzw. Konsistenzregeln (constraint rules).

Meiner Ansicht nach bezieht sich 'constraints' auf alle Elemente der Aufzählung. Aus der anderen Perspektive betrachtet bedeutet die Fähigkeit, sicherheitsrelevante oder semantische Einschränkungen definieren zu können, einen großen Vorteil. Es geht ja hier nicht um endbenutzerorientierte Anwendungen, sondern um abteilungsübergreifendes Regelwerk zur Automatisierung höchst komplexer Prozesse.

Kurze Zusammenfassung:

Konzepte des SOA-Referenzmodells
(www.cit.tu-berlin.de/fileadmin/a34331500/vl-soa/SOA_Folien0...
Sichtbarkeit
- Anbieter von Fähigkeiten müssen für Nutzer sichtbar sein
- Typischerweise über Beschreibung der
- funktionalen und technischen Anforderungen
- Richtlinien
- Einschränkungen
- Zugriffs- und Antwortmechanismen
- Beschreibung muss syntaktisch und semantisch offen und verständlich sein

Eine ausführliche Beschreibung bietet z. B.
http://files.hanser.de/hanser/docs/20070601_276191512-97_978...

Die Bedeutung von 'constraints' lässt sich hier ableiten (der folgende Abschnitt stammt nahezu unverändert aus http://files.hanser.de/hanser/docs/20070601_276191512-97_978...

Die Modellierung von Prozessen in einer SOA mittels BPEL unterscheidet sich nicht von den üblichen BPM-Modellierungstechniken. Die Einschränkung von SOA gegenüber BPM erfolgt erst auf der Ebene der Ausführbarkeit. SOA versteht einen Prozess als automatisierbaren Prozess. Die Steuerung der Anwendung erfolgt über den abgebildeten Prozessfluss und dessen einzelne Schritte, Entscheidungspunkte und Verzweigungen.
Damit wird Business Process Modelling zu einem zentralen Element für die Spezifikation einer Anwendung. Diese Spezifikation wird als Geschäftsprozess gestaltet und mit einem BPEL-Modellierungstool als Ablaufdiagramm graphisch dargestellt. Aus dieser graphischen Darstellung des Prozesses wird die Prozessbeschreibung als BPEL
Datei generiert, die generierte Prozessbeschreibung dann in eine BPEL Engine geladen und ausgeführt. Auf diese Weise entsteht aus einem Ablaufdiagramm ein konkreter Workflow, der sich auf jeder BPEL-fähigen Workflow Engine ausführen lässt.

Geschäftsregeln (Business Rules) sind ein integraler Bestandteil des Geschäftsprozessmanagements. Sie steuern das Verhalten von Prozessen. Eine Business Rule ist eine Aussage, die einen Aspekt eines bestimmten Geschäftsfalls definiert oder begrenzt.
Er soll die Struktur des Geschäftsfalles zur Geltung bringen und sein Verhalten beeinflussen oder kontrollieren. Business Rules können mittels Rule Engines umgesetzt werden. Diese unterstützen sowohl die Modellierung als auch die Verwaltung und Kontrolle der
Geschäftsregeln in einer SOA. Sie sind geeignet, Regeln für die Validierung von Daten, für die Steuerung komplexer Aktionen und für die Steuerung des Verhaltens von Prozessen zu modellieren und auszuführen.

Zur genaueren Bedeutung von constraints/constraint rules:
Rule Engines kommen vor allem in drei Bereichen zum Einsatz:
als Mechanismus zur Validierung von Konsistenzregeln,
als Steuerung komplexer Aktionen, basierend auf Fakten, oder
als Steuerung von Reaktionen auf bestimmte Ereignisse.

Konsistenzregeln (Constraint Rules) sind Rahmenbedingungen, innerhalb derer Daten als konsistent oder gültig angesehen werden. Typischerweise werden damit Konsistenzprüfungen für die Eingabe von Werten durch Nutzer eines Systems durchgeführt.

In einem auf SOA basierenden System sind jedoch vor allem Konsistenzprüfungen vor/nach Datenkonvertierungen oder -Transformationen vorzusehen. Kritische Service können mit einem gut formulierten Regelwerk vor inkonsistenten Systemzuständen
geschützt werden.

Die Steuerung komplexer Aktionen, basierend auf Fakten, erfolgt aufgrund so genannter Produktionsregeln (Derivation Rules, Producer Rules oder Inference Rules). Im Gegensatz zur einfachen Berechnung von Werten (Computation) hängt die Berechnung
eines Wertes durch Produktionsregeln vom Kontext der entsprechenden Fakten ab (Inference). Typische Anwendungen solcher Regeln sind die Prüfung für die Kreditwürdigkeit
oder die Erzeugung von Rabattkonditionen.

Die Steuerung von Aktionen als Reaktion auf bestimmte Ereignisse wird mit so genannten Aktionsregeln (Action/Event Rules, Behavior Rules) durchgeführt. So wird das Verhalten eines Prozesses gesteuert. Ein Prozess respektive Teilprozess kann über
Aktionsregeln gestartet, angehalten oder auch abgebrochen werden. Diese Anwendung ist die bei weitem häufigste Anwendung einer Rule Engine im Rahmen einer SOA. Die Kombination einer BPEL Engine mit einer Rule Engine ist aus diesem Grund von den
meisten Herstellern vorgesehen.

...

Gemäß der Business Rules Group können Geschäftsregeln in strukturelle Aussagen (Structural Assertion), Handlungsaussagen (Action Assertion) und abgeleitete Aussagen (Derivation)
unterschieden werden.
- Structural Assertion (Terms and Facts): die Formulierung von Tatsachen, die die Struktur eines Geschäftsfalles beschreiben. Sie beschreiben Beziehungen und Fakten.
- Action Assertion (Constraints): Aussage, die Aktionen eines Geschäfts einschränkt oder sie bestimmten Bedingungen unterwirft. Diese Regeln sind für die operative Steuerung eines Geschäftsfalles wichtig.
- Derivation (Actions): Aussage, die von einer anderen Aussage abgeleitet wird.
Hintergrund dieser Unterscheidung ist der Versuch, das Geschäftswissen als Ressource eines Unternehmens formal zu erfassen, konsistent anzuwenden und so aufzubereiten, dass
ein Computer dieses Wissen möglichst einfach verarbeiten kann.

Die semantischen Einschränkungen beziehen sich meiner Ansicht nach darauf, ob/wie Abläufe in maschinenauswertbare 'Sprache' umgesetzt werden können. Sehr gute Informationen hierzu bietet www.sigs.de/publications/js/2004/02/dostal_JS_02_04.pdf.


--------------------------------------------------
Note added at 1 Tag4 Stunden (2008-04-01 10:33:15 GMT) Post-grading
--------------------------------------------------

Aniello, danke für die drei virtuellen Punkte - die nagele ich direkt neben meiner aufblasbaren Waschmaschine an die Wand ;-).
Die Wahl von 'Einschränkungen' ist auf jeden Fall richtig; *Be*schränkungen wäre hier nicht ganz korrekt gewesen. Es handelt sich aber auf jeden Fall um 'virtuelle' Einschränkungen, nicht um operative Einschränkungen, die die Funktionsfähigkeit des Tools beeinträchtigen (worauf sich Konrad bezieht).