Entwicklung eines SOA-basierten Integrationsschicht-Frameworks: Ziele

Vor ein paar Jahren wurde ich von einem unserer Kunden gebeten, ihm dabei zu helfen, seine Integrationsschicht besser zu nutzen. Seitdem haben mein Team und ich an einem Framework gearbeitet, das dies unterstützt. Dies ist der zweite Teil einer Reihe von Blogs über die Entwicklung unseres Frameworks und über die Ziele, die wir erreichen mussten. Im letzten Blog dieser Serie habe ich die geschäftlichen Anforderungen erwähnt, die wir erfüllen mussten:

• Effizienz in Geschäftsprozessen
• Konsistenz in der Datendarstellung
• Flexibilität und Markteinführung durch die IT-Abteilung beschleunigt.

Auf dieser Grundlage wurden die unten beschriebenen Ziele festgelegt.

Ziele

1. Das Framework sollte es ermöglichen, Systeme aus verschiedenen Geschäftsbereichen so schnell wie möglich miteinander zu verbinden. Schnell ist hier natürlich relativ: In der alten Version der Integrationsschicht konnte es bis zu 40 Stunden Arbeit (das ist der gesamte Zeitaufwand) dauern, um einen einfachen Webservice-Proxy bereitzustellen. Bei der Ungeduld der Entwickler bedeutete dies, dass die Integrationsschicht manchmal völlig übersehen wurde, so dass es schwierig war, die verschiedenen Verbraucher eines Dienstes außerhalb der Domäne in den Griff zu bekommen, was auch zu allen möglichen Sicherheitsrisiken führte. 2. Das Framework sollte es einem Verbraucher ermöglichen, Dienste in anderen Domänen immer auf die gleiche Weise aufzurufen. Da es keine wirklichen Regeln für die Gestaltung von Webdiensten gab, war die Dienstelandschaft gelinde gesagt 'uneinheitlich'. Schlimmer noch, an mehreren Stellen wurden keine Standardprotokolle wie SOAP verwendet. Außerdem gab es kein Dienstregister, so dass selbst das Auffinden eines bestimmten Dienstes und das anschließende Herausfinden, wie man ihn aufruft, zeitaufwändig sein konnte. Unser Ziel war es, eine föderierte Endpunktschicht für alle Verbraucher von Diensten außerhalb der Domäne bereitzustellen. 3. Das Framework sollte auf SOA-Prinzipien beruhen. Lange bevor ich dazukam, traf der Kunde die Entscheidung, SOA zu nutzen. Schicke Berichte mit vielen großen Worten wurden geschrieben und dann in eine Schublade gesteckt. Da ich selbst ein SOA-Befürworter bin, habe ich es auf mich genommen, die 8 Prinzipien der Service-Orientierung in einem sinnvollen Umfang zu befolgen. Nicht, weil es auf einer PowerPoint-Folie so gut aussieht, sondern weil Prinzipien wie die lose Kopplung von Diensten und standardisierte Dienstverträge beim Aufbau eines Frameworks für die Integrationsschicht tatsächlich sehr sinnvoll sind.Mit diesem Ziel verbunden ist auch die Tatsache, dass wir so viel wie möglich auf Industriestandards zurückgreifen und nur dann von ihnen abweichen, wenn es absolut notwendig ist. Allerdings haben wir ein paar Tricks aus dem Ärmel gezaubert, auf die ich in einem zukünftigen Blog zurückkommen werde. 4. Das Framework sollte generische Funktionen bereitstellen. Das Witzige an einer Integrationsschicht ist, dass sie zentralisiert ist und nur dann einen Mehrwert bietet, wenn die von ihr bereitgestellten Funktionen für alle Verbraucher von Bedeutung sind, nicht nur für das Projekt, das sie anfordert. Sogar das Projekt, für das wir unsere Stunden gebucht haben, hieß 'generic features integration layer', was Ihnen zeigt, wie wichtig dieses Ziel ist. 5. Das Framework sollte aus wieder zusammensetzbaren Komponenten bestehen. Dies ist eine direkte Folge von Ziel Nr. 1: Um schnelle Verbindungen zwischen verschiedenen Systemen zu ermöglichen, war es notwendig, mehrere generische Framework-Dienste zu entwickeln, die als Teil spezifischer Lösungen zusammengestellt werden können. 6. Das Framework sollte auf verschiedenen Plattformen laufen können. Das ist ein wichtiger Punkt: In dieser Blogserie spreche ich im Grunde über das Konzept des Frameworks und nicht so sehr über die Implementierung (obwohl es auch dafür ziemlich strenge Regeln gab, d.h.: es sollte dieses teure Stück Hardware nutzen, das das Unternehmen gekauft hatte). Das bedeutete, dass wir, um dieses Ziel zu erreichen, sehr vorsichtig sein mussten, um ein Gleichgewicht zwischen dem, was die Integrationsplattform leisten konnte, und dem, was wir eigentlich wollten, zu finden. 7. Das Framework sollte auf agile Weise entwickelt werden. Da sowohl ich als auch ein anderer Xebia-Berater (beide überzeugte Anhänger der agilen Methodik) gerade das erste erfolgreiche Scrum-Projekt bei unserem Kunden gestartet haben und zum ersten Team gehören, das für die neue Integrationsschicht verantwortlich ist, war es kein Wunder, dass auch dieses Ziel gesetzt wurde. Was aber noch wichtiger ist: Es ist ein perfekter Weg, um die wirklich wichtigen Probleme zuerst anzugehen und dem Framework nach und nach neue Funktionen hinzuzufügen.

Fazit

Ich denke, dass wir am Ende eine nahezu perfekte Punktzahl erreicht haben, obwohl es immer Raum für Verbesserungen gibt. Außerdem wird die erste der geschäftlichen Anforderungen überhaupt nicht berücksichtigt: Wir denken darüber nach, dies in der nächsten Version des Frameworks zu tun. Das war's. Das nächste Mal werde ich auf die Herausforderungen eingehen, die wir bewältigen mussten.