Blog

Entwicklung eines SOA-basierten Integrationsschicht-Frameworks: Einführung

Marit Fränkel

Aktualisiert Oktober 22, 2025
5 Minuten
Vor ein paar Jahren wurde ich von einem unserer Kunden gebeten, ihm zu helfen, seine Integrationsschicht besser zu nutzen. Damals bestand sie aus 2 oder 3 Integrationsplattformen, einer darauf aufbauenden hausgemachten Software und ein paar unbedeutenden Regeln, wie das alles zu nutzen ist. Keiner der Vorteile eines 'echten' ESB wurde erreicht, obwohl das immer die Idee war. Seitdem haben mein Team und ich an einem Framework gearbeitet, das die 'geschäftlichen Anforderungen' erfüllen könnte:
  • Effizienz in Geschäftsprozessen, z.B. durch die automatische Kopplung von Teilprozessen zu einem Ganzen.
  • Konsistenz in der Datendarstellung, wie z.B. die Darstellung eines Kunden in einem CRM-System und in einem Finanzsystem.
  • Flexibilität und Markteinführung durch die IT-Abteilung beschleunigt.
Es wurde beschlossen, dass dieses Framework auf der bereits bestehenden Plattformschicht aufgebaut werden sollte: Normal 0 false false false EN-US X-NONE X-NONE /* Stil-Definitionen */ table.MsoNormalTable {mso-style-name: "Tabelle Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; Zeilenhöhe:115%; mso-pagination:widow-orphan; Schriftgröße:11.0pt; font-family: "Calibri", "sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Abbildung 1: Schichten der Integrationsschicht.

Normal 0 false false false EN-US X-NONE X-NONE /* Stil-Definitionen */ table.MsoNormalTable {mso-style-name: "Tabelle Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; Zeilenhöhe:115%; mso-pagination:widow-orphan; Schriftgröße:11.0pt; font-family: "Calibri", "sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Das Framework wurde so konzipiert, dass es als leichtgewichtiger ESB fungieren kann, obwohl wir versucht haben, das gefürchtete 'E-Wort' so lange wie möglich zu vermeiden, da die Leute etwas nervös werden, wenn man es benutzt.

Im Folgenden finden Sie einige Themen, die wir bei der Entwicklung des Frameworks berücksichtigen mussten. In zukünftigen Blogs werde ich diese näher erläutern. Sobald ein solcher ausführlicherer Blog veröffentlicht wird, werde ich hier einen Link hinzufügen.

Ziele & Herausforderungen

Zum Teil auf der Grundlage der oben genannten geschäftlichen Anforderungen wurden vom Team verschiedene Ziele in Bereichen wie Business Centricity, Föderation und die Anwendung von SOA-Designprinzipien festgelegt. Natürlich ist keine Aufgabe vollständig, wenn sie nicht mit einer Reihe von Herausforderungen verbunden ist. Auch wir hatten damit zu kämpfen, z. B. mit mangelndem Wissen über wichtige Themen und mit Widerstand innerhalb der Organisation. In einem zukünftigen Blog werde ich näher auf diese Probleme und die Art und Weise, wie wir sie gemeistert haben, eingehen.

Bausteine

Wie jedes anständige Framework besteht auch unseres aus Komponenten und Mustern, sowohl konzeptionell als auch physisch. Für mich als Architekt waren die konzeptionellen Dinge am wichtigsten. Da ich in der realen Welt nicht immer das finden konnte, was ich wollte, musste ich mir einige dieser Bausteine selbst ausdenken. Grundlage sowohl für die anderen Bausteine als auch für einige der Produkte, die wir an die Projekte liefern, sind unsere so genannten Framework Services. Die meisten von ihnen sind so konzipiert, dass sie immer wieder verwendet werden können. Einige wenige sind es nicht, sie fungieren lediglich als Proxys für die Anwendungsdienste, die sie aufrufen. Einer der wichtigsten Aspekte des Frameworks ist, dass es generische Funktionen bietet . Systeme, die das Framework für den Transport von Nachrichten an Gegenparteien verwenden, profitieren von Standardfunktionen in den Bereichen Routing, Robustheit, Sicherheit, Persistenz und Transformation. Ein weiterer wichtiger Teil unseres Frameworks sind die Verbindungsmuster, die jeweils eine einzigartige Kombination aus einem Nachrichtenaustauschmuster und einem Funktionssatz bieten.

Produkte zur Integration

Ein schön komponiertes Framework ist schön und gut, aber am Ende geht es um funktionierende Software (und die dazugehörige Dokumentation), oder wie wir es gerne nennen: unsere 'Integrationsprodukte'. Wann immer wir einen neuen Auftrag für eine Anwendung erhalten, die über unser Framework zugänglich gemacht werden soll, beginnen wir mit der Beschreibung von Anwendungsfällen. Schließlich gibt es keine Verbindung ohne einen geschäftlichen Grund. Dafür mussten wir unsere eigene Art von architektonischem Sichtmodell entwickeln. Wahrscheinlich am wichtigsten sind die Verbindungspunkte der Integrationsschicht. Die Beschreibungen dieser Punkte machen deutlich, wie Nachrichten aussehen sollten, um transportiert zu werden, und welche Funktionen ein Verbraucher erwarten kann. Sobald sie implementiert sind und in einer bestimmten Umgebung eingesetzt werden, kann die Anwendung über das Framework der Integrationsschicht erreicht werden.

Fazit

Das Framework läuft nun schon seit geraumer Zeit in der Produktion, ohne dass es irgendwelche Probleme gibt. Immer mehr Anwendungen sind über die von uns bereitgestellte föderierte Endpunktschicht erreichbar, was bedeutet, dass die Verwendung des Frameworks zur Standardmethode geworden ist, um Systeme aus verschiedenen Geschäftsbereichen zu verbinden und unsere Produktdienste der Außenwelt zugänglich zu machen. Die Ziele wurden größtenteils erreicht, obwohl es immer Raum für Verbesserungen gibt. Und das ist auch gut so, denn wir haben noch viel vor, vor allem im Bereich der Funktionen. Und in Bezug auf die Implementierung haben wir viel gelernt, so dass einige der älteren Softwarelösungen für ein Refactoring in Frage kommen. Das Wichtigste ist im Moment jedoch, das Framework besser verwaltbar zu machen: Ein Großteil der Konfiguration wird immer noch von Hand vorgenommen, und da es sich um das Zentrum des Unternehmens handelt, wenn es um den Transport von Nachrichten geht, ist es notwendig, einen besseren Überblick über die Vorgänge zu bekommen. Das war's für diese Einführung; im nächsten Blog werde ich näher auf die oben genannten Ziele eingehen.

Verfasst von

Marit Fränkel

Contact

Let’s discuss how we can support your journey.