Grundlegende SOA

Die Softwarehersteller haben ein potenziell nützliches Konzept gekapert, indem sie schwergewichtige, komplexe Tools wie ESBs auf den Markt gebracht haben. Das Ziel dieses Artikels ist es, herauszufinden, welche dieser Tools wir wirklich brauchen, damit wir uns von unnötiger Komplexität fernhalten können. Dazu beschreibe ich die Infrastrukturdienste, die wir wirklich brauchen, und wie diese Dienste auf möglichst einfache Weise implementiert werden können. Software hängt von anderer Software ab, weil wir Systeme nicht von Grund auf neu aufbauen wollen. Jede Software, von der Ihr Code abhängt, kann: - die Adresse oder den Namen, unter dem sie bekannt ist, ändern - die Technologie, in der sie implementiert ist, ändern - nicht verfügbar sein, wenn Sie sie brauchen - auf einem anderen Server oder im selben Prozess leben - über eine Infrastruktur verbunden sein, der man nicht trauen kann - eine andere Sprache sprechen Namen Ein Name ist nicht mehr als eine Abstraktion: Mithilfe eines Algorithmus kann ein Name in etwas Nützliches übersetzt werden. In Netzwerken sind wir bereits an Namen gewöhnt: Niemand tippt IP-Adressen ein, um einen Server im Internet zu finden, wir verwenden einfach einen leicht zu merkenden Namen. Die Zuordnung dieses Namens zu einer physischen Adresse kann sich im Laufe der Zeit ändern, aber die Änderungsrate ist in der Regel viel langsamer als die Änderungsrate der Software, die durch den Namen repräsentiert wird. Im Grunde genommen können wir mit einer DNS-ähnlichen Registrierung auskommen, um Dienstnamen in Informationen zu übersetzen, die es der Software ermöglichen, eine Methode auf einem Server aufzurufen. Ein Message Broker könnte nützlich sein, aber wenn wir nur einen erweiterten Namensdienst brauchen, können wir auch ein Verzeichnis verwenden. Plumbing Software, der Code, der von unserem Geschäftscode zum Aufrufen eines Dienstes verwendet wird, führt eine Suche nach einem Dienst durch und speichert das Ergebnis. Dadurch werden kostspielige Umwege zu einem Broker vermieden. Vergleichen Sie dies mit der Art und Weise, wie ein Browser ein DNS verwendet: Der Name wird in eine IP-Adresse übersetzt und das Ergebnis wird zwischengespeichert, bis ein Fehler auftritt. Wenn ein Fehler auftritt, wird die Suche erneut ausgeführt und das neue Ergebnis wird bis auf weiteres verwendet.Diese Lösung ist einfach, robust, vermeidet einen Single Point of Failure für die meisten Aufrufe, ermöglicht Änderungen usw.Die meiste Software wechselt im Laufe der Zeit den Standort, aber Änderungen treten nur langsam auf. Nachrichten sollten nicht gezwungen sein, jedes Mal eine teure Infrastruktur zu durchlaufen. Betrachten wir als Beispiel die Interaktion zwischen zwei Anwendungen: App1 sendet über eine Firewall eine Nachricht an einen Broker Der Broker sendet über eine Firewall eine Nachricht an App2 App2 sendet die Ergebnisse über Broker und Firewall an App1 Übrigens werden App1 und App2 als zwei EARs in einer einzigen Weblogic-Instanz bereitgestellt. Diese einfache Form der Interaktion sollte nicht durch den oben skizzierten komplexen Prozess implementiert werden. Verwaltung der Nichtverfügbarkeit Die meisten Prozesse erfordern eine Antwort hier und jetzt, aber leider sind einige Systeme während mehrerer Stunden am Tag nicht verfügbar. Sie können Daten entgegennehmen und versprechen, die Anfrage später zu bearbeiten. Um dies sicher zu tun, können Sie entweder Daten in einer Datenbank speichern oder eine Nachricht in eine Warteschlange stellen. Warteschlangen sind ein wichtiger Bestandteil von Middleware, der gut verstanden wird, auf vielen verschiedenen Plattformen (vor allem Mainframes) weit verbreitet ist und so konfiguriert werden kann, dass nie eine Nachricht verloren geht und immer verfügbar ist. Daher halte ich Warteschlangen für einen wesentlichen Bestandteil jeder nicht trivialen Infrastruktur. Sicherheit Die grundlegenden Konzepte der Sicherheit sind Identität und Vertraulichkeit. Innerhalb einer Unternehmensinfrastruktur werden beide durch einfache SSL-Verbindungen gewährleistet. Es gibt noch mehr zur Sicherheit, aber das heben wir uns für später auf. Meine Regel lautet, dass einfache Probleme einfache Lösungen erfordern, also behaupte ich, dass SSL in den meisten Fällen ausreicht. XML Eckige Klammern sind Leistungsfresser. XML ist ineffizient bei der Nutzung der Netzwerkbandbreite und erfordert ein kostspieliges Ein- und Auslagern. Es mag für Entwickler einfach zu verwenden sein, aber die Kosten für die Infrastruktur in Form von Servern und Netzwerken können die Vorteile der Entwicklungseffizienz leicht überwiegen. Ich gehe sogar noch einen Schritt weiter: XML war nie dafür gedacht, zur Laufzeit verwendet zu werden. Mit Konzepten wie XMLSchema haben wir eine leistungsfähige, maschinenlesbare Möglichkeit, Nachrichten zu definieren. Aber bedeutet das, dass wir den ganzen Ballast zwischen spitzen Klammern die ganze Zeit über brauchen? Auch hier würde ich, der Einfachheitsregel folgend, lieber ein Nachrichtenformat wählen, das effizient geparst und transportiert werden kann. Wie im Fall der Sicherheit gibt es zu diesem Thema später noch mehr zu sagen. Batch-Verarbeitung Die Batch-Verarbeitung unterscheidet sich von OLTP. Bei Batches geht es um Hundertstel oder Tausendstel von Nachrichten pro Stunde oder Tag. Wenn Sie jede Nachricht als einzelnes Element behandeln, den Standort des Dienstes suchen, der sie bearbeiten soll, den Inhalt in XML übersetzen, ihn über ein Netzwerk an einen Broker senden, ihn in Esperanto übersetzen, ihn über ein Netzwerk an einen anderen Server senden, ihn in noch mehr XML übersetzen, dann einen Dienst aufrufen und das Ergebnis in umgekehrter Richtung zurücksenden, werden Stapelverarbeitungen Ihre Infrastruktur zum Erliegen bringen, wenn das Volumen zu wachsen beginnt. Für OLTP mögen Sie damit durchkommen, aber bei einer großen Anzahl von Nachrichten wird es kläglich scheitern. Behandeln Sie Batches also mit dem Respekt, den sie verdienen, und entwickeln Sie eine Lösung, die ein Gleichgewicht zwischen Laufzeitleistung und Designzeit-Effizienz herstellt. Die bisherige Liste Was wir für die Infrastruktur benötigen, ist die folgende Liste von Konzepten und Tools: - ein Verzeichnis, das es der Software ermöglicht, andere Software zu finden, auch wenn sich das Ziel bewegt - ein Mechanismus, um die Verarbeitung auf einen späteren Zeitpunkt zu verschieben - eine Lösung, um Vertraulichkeit und Identität zu gewährleisten - ein effizientes Nachrichtenformat - eine Stapelverarbeitungsstrategie, die mit einer großen Anzahl von Nachrichten umgehen kann Das Leben ist nicht immer einfach Möglicherweise müssen Sie einen Dienst aus kleineren Diensten zusammenstellen, um einen einfachen Zugriff zu ermöglichen oder das Wissen über die Verwendung von Diensten zu erfassen. Dienste sprechen möglicherweise nicht dieselbe Sprache. Manchmal sind Sie gezwungen, einen Teil einer Nachricht zu verschlüsseln, weil er als Teil einer größeren Nachricht gesendet wird, die nicht lesbar sein sollte, während sie die Infrastruktur durchläuft. Die oben genannten Punkte sind berechtigte Bedenken, die am Rande der Infrastruktur Ihres Unternehmens oder Ihrer Abteilung wichtig werden: Das Zusammenstellen von Diensten zu einem größeren Dienst speichert Wissen und ist daher ein nützliches Konzept. Es verbessert auch die Effizienz, wenn die Dienste über ein langsames Netzwerk aufgerufen werden. Es ist nützlich, einen gemeinsamen Dialekt zu standardisieren, der im gesamten Unternehmen verwendet wird. Wenn Sie nicht bei Null anfangen können, brauchen Sie etwas, um zwischen den Dialekten zu übersetzen. Außerdem sind Standards für den Datenaustausch mit Geschäftspartnern gut geeignet, aber für die Verwendung im Unternehmen sind sie möglicherweise zu umständlich. Wir brauchen also etwas, das wir an den Grenzen übersetzen können. Vielleicht gibt es ein Standard-XML-Format für den Austausch von Nachrichten in einer Branche. Beim Austausch von Nachrichten zwischen Unternehmen können wir uns einen Maklerdienst vorstellen, der Nachrichten auf der Grundlage von Merkmalen in einem Header-Abschnitt weiterleitet. Der Hauptteil der Nachricht kann höchst vertraulich sein und sollte daher verschlüsselt werden. Hier greift SSL zu kurz und wir brauchen etwas Anspruchsvolleres. Fazit In diesem Artikel habe ich argumentiert, dass wir innerhalb eines Unternehmens selten Broker benötigen und mit einfachen Maßnahmen wie Verzeichnissen und SSL-Verbindungen auskommen können. Wenn das Unternehmen wächst oder Sie anfangen, Informationen mit Geschäftspartnern auszutauschen, benötigen Sie möglicherweise eine anspruchsvollere Infrastruktur. Broker, XML und die ganze Fülle der WS*-Standards passen also gut in Ihre DMZ, sind aber anderswo ein Overkill.