Modellierung von Verbindungen

Sequenzen

Eine Sequence ist eine Verbindung zwischen zwei aufeinanderfolgenden Actions innerhalb einer Anwendungskomponente. Eine Sequence wird durch einen vertikalen Pfeil von oben nach unten dargestellt.

• Verwenden Sie eine Sequence dann, wenn die erste Action logische Voraussetzung für die Durchführung der zweiten Action ist.

• Sie können mit einer Sequence aber auch die Reihenfolge der Eingangsverarbeitung bei asynchroner Kommunikation festlegen.

Design synchroner und asynchroner Kommunikationsschritte

Beim Design Ihres Process-Integration-Szenarios müssen Sie dem notwendigen Informationsaustausch zwischen den beteiligten Anwendungskomponenten besondere Aufmerksamkeit widmen.

Beachten Sie Folgendes:

• Identifizieren Sie alle Stellen in Ihrem Process-Integration-Szenario, in denen ein Informationsaustausch (realisiert durch einen Message-Austausch) zwischen den Komponenten notwendig ist. Wir sprechen dabei auch von Kommunikationsschritten.

• Legen Sie fest, ob der Nachrichtenaustausch synchron oder asynchron erfolgen soll.

  • Synchrone Kommunikation bedeutet, dass der Aufrufer auf die Rückmeldung des Empfängers wartet und erst dann mit der Verarbeitung fortfährt.

  • Asynchrone Kommunikation bedeutet, dass der Aufrufer keine sofortige Rückmeldung erwartet und sofort mit der Verarbeitung fortfährt.

    In verteilten Szenarien sollten Sie, wo immer möglich, mit asynchroner Kommunikation arbeiten. Die Process-Integration-Szenarien arbeiten dann robuster und zuverlässiger.

• Abhängig von Ihren Festlegungen identifizieren Sie die benötigten Interfaces für die Kommunikation. Sollten diese noch nicht existieren, müssen Sie sie im Enterprise Services Builder (Designer-Werkzeug) definieren. Achten Sie darauf, dass die Eigenschaften der Interfaces (Outbound/Inbound, synchron/asynchron) Ihrem Design entsprechen.

Abbildung der Kommunikationsschritte im Process-Integration-Szenario

Ihre Designentscheidungen müssen Sie in der Process-Integration-Szenario-Grafik des Enterprise Services Builder entsprechend darstellen.

Beachten Sie dazu die folgenden Aspekte:

• Jeder Message-Austausch wird im Process-Integration-Szenario durch eine Verbindung zwischen den entsprechenden Actions dargestellt.

  Beachten Sie, dass auch hier über die Typ-Ebene gesprochen wird. Wird zum Beispiel ein Kommunikationsschritt mehrfach benötigt, handelt es sich aber um dieselben Actions und dieselben Interfaces, dann wird dies durch nur eine Verbindung dargestellt.

• Definieren Sie entsprechend Ihres Designs synchrone bzw. asynchrone Verbindungen.

  • Eine synchrone Verbindung wird durch einen horizontalen Doppelpfeil dargestellt. Die beiden Actions müssen sich dazu in der Grafik auf der gleichen Ebene befinden.

  • Eine asynchrone Verbindung wird durch einen Pfeil dargestellt, der versetzt nach unten führt. Die Folge-Action muss dazu auf einer tieferen Ebene als die Quell-Action liegen.

    Die Kommunikationsart (synchron/asynchron) einer Verbindung wird von der Process-Integration-Szenario-Designumgebung automatisch festgelegt und richtet sich nach der relativen Position der beiden Actions. Sie müssen die Actions in der Grafik gemäß der obigen Richtlinien korrekt anordnen, damit die gewünschte Kommunikationsart vergeben wird.

• Vervollständigen Sie die Angaben zur Verbindung, indem Sie das Outbound- und das Inbound-Interface auswählen, welche beim Nachrichtenaustausch verwendet werden. Wählen Sie außerdem, sofern relevant, das Mapping aus, welches bei dieser Verbindung durchgeführt werden soll.

• Gibt es für den Nachrichtenaustausch verschiedene Alternativen, welche Interfaces oder Mappings verwendet werden können, dann modellieren Sie jede der Alternativen als eigene Verbindung.

• Werden zwischen zwei Actions mehrere Verbindungen definiert, dann muss es sich um Alternativen handeln. Zur Konfigurationszeit darf nur eine der Verbindungen (pro Sender-Empfänger-Relation) ausgewählt werden.

• Bezüglich der Reihenfolge der Kommunikationsschritte, die von einer Action bearbeitet werden, gelten folgende Regeln:

  • Inbound-Kommunikationsschritte liegen zeitlich immer vor den Outbound- Kommunikationsschritten.

  • Gibt es mehrere Inbound-Kommunikationsschritte, dann ist zwischen diesen keine Reihenfolge definiert.

  • Gibt es mehrere Outbound-Kommunikationsschritte, dann ist zwischen diesen ebenfalls keine Reihenfolge definiert.

  • "Keine Reihenfolge definiert" bedeutet dabei, die Reihenfolge ist nicht bekannt und damit auch nicht relevant.

    Tritt ein Anwendungsfall auf, der mit den oben aufgeführten Regeln nicht vereinbar ist, dann muss anders modelliert werden. Eine Lösung kann darin bestehen, die betroffene Action in zwei (oder mehrere) Actions aufzuteilen.

Start-Actions und Ende-Actions

Zweck von Start- und Ende-Actions ist einerseits, die Lesbarkeit für den Benutzer zu erhöhen, und andererseits, mögliche Punkte für ein ausgewähltes Monitoring anzugeben.

• Als Start-Action können alle die Actions klassifiziert werden, an denen ein Process-Integration-Szenario unabhängig beginnen kann. Es kann mehrere Startpunkte geben.

• Als Ende-Action können alle die Actions klassifiziert werden, an denen das Process-Integration-Szenario ein betriebswirtschaftlich sinnvolles Ende findet. Es kann mehrere Ende-Actions geben.

• Wird eine Action als Start-Action klassifiziert, sollte diese am Anfang ihrer Anwendungskomponente stehen. Analog sollte eine Ende-Action am Ende ihrer Anwendungskomponente stehen.