LeKuchen: Loose Coupling in SOA

Hallo zusammen,

ich entwickle seit einigen Monaten eine flexible SOA-Anwendung für extrem heterogne IT-Umgebungen (Systeme und Plattformen).

Grundsätzlich bin ich natürlich bestrebt, objektorientiert mit Klassen und Typed Data zu programmieren, aber da bei der Anwendungen die Datenstrukturen geändert werden können sollen, ohne dass der Code der Anwendung angepasst werden muss (!), nutze ich für meine Business Entities pures XML. Die einzelnen Business Objekte sind praktisch über XML und XSD Dateien beschrieben und können über anwendungseigene Tools editiert werden (es gibt allerdings meist feste Grundschemata).

Mir ist natürlich bewußt, das diese Architektur Gefahren birgt. Wie sind Eure Erfahrungen mit loosely coupled Anwendungen? Was ist besonders zu beachten? Hat jemand Tipps oder links zu dem Thema?

Gruß
LeKuchen

  1. Hallo LeKuchen,

    ich halte es nicht aus, es brennt so im Auge....es heisst "lose coupling"! Man kann es in Deutschland auch lose Kopplung nennen.

    Welche "Gefahren" birgt denn deiner Meinung nach diese Architektur?

    Worüber du sprichst sind eigentlich Abstraktionsebenen, Layers oder auch Tiers genannt, aber sie haben sehr viel mit loser Kopplung zu tun. Abstraktionsebenen sind gut. In deinem Fall zum Beispiel kommst du selbst mit einer Änderung der Datenstruktur relativ gut klar, indem du einfach nur die Schicht anpasst, die die XML Daten generiert, sodass sie genau in der selben Form generiert werden, wie auch vorher. Dann braucht man die Anwendung selbst überhaupt nicht anzufassen.

    Der einzige Nachteil den ich dir nennen könnte ist, dass ein Techniker sich mit mehreren Softwarekomponenten auskennen muss, aber der Zeitaufwand dafür ist mikrig im Vergleich zu einer Systemweiten Änderung, die man durchführen musste wenn nicht mit Schichten arbeitet.

    Gruß,
    Cruz

    1. Hallo Cruz,

      ich halte es nicht aus, es brennt so im Auge....es heisst "lose coupling"! Man kann es in Deutschland auch lose Kopplung nennen.

      Ein "o"?
      http://en.wikipedia.org/wiki/Loose_coupling
      Ok, sprechen wir über lose Kopplung.
      http://www.architecturejournal.net/2004/issue2/aj2service.aspx

      Worüber du sprichst sind eigentlich Abstraktionsebenen, Layers oder auch Tiers genannt, aber sie haben sehr viel mit loser Kopplung zu tun. Abstraktionsebenen sind gut. In deinem Fall zum Beispiel kommst du selbst mit einer Änderung der Datenstruktur relativ gut klar, indem du einfach nur die Schicht anpasst, die die XML Daten generiert, sodass sie genau in der selben Form generiert werden, wie auch vorher. Dann braucht man die Anwendung selbst überhaupt nicht anzufassen.

      Natürlich nutze ich eine n-tier Architektur für meine "Basis-"Anwendung. Ich weiß auch was das ist...;)
      Und natürlich weiß ich auch, dass die einzelnen Tiers möglichst lose gekoppelt sein sollen, damit die Vorteile der n-tier Architektur auch zum Tragen kommen.

      In einer normalen Anwendung würde ich Objekte definieren, die dann zwischen den Tiers ausgetauscht werden. Diese werden z.B. im DAL mit Daten aus einem RDBMS gefüllt, im BL passiert irgendwas damit und im PL werden sie rausgerendert - soweit so gut.

      Jetzt habe ich aber praktisch sich dauernd ändernde / anpassende Objekte, die zwar eine gewissen Grundstruktur haben, aber nicht im Code als Klassen inkl. Typen definiert werden sondern als pures XML-Objekt verarbeitet werden. Da können dann Daten und Nodes einfach mal dazukommen, die interne Logik meiner Schichten regelt das über XML-Dictionaries und XSDs. Ich sehe da die Gefahr, das ich ggf. nicht ausreichende Überprüfung der Daten in meinen XML-Objekten habe, da diese (praktisch) nicht typensicher sind (naja, ich kann gegen die XSD validieren).

      Außerdem geht es auch nicht um eine einfache n-Tier Anwendung, sondern wie erwähnt um eine Service-orientierte Architektur. Ich habe also eine noch nicht absehbare Anzahl von Webservices, die Daten an meine Applikation liefern (Plattformen Solaris, Linux, Windows; Oracle Datenbanken, MSSQL-Datenbanken, SAP-Systeme etc.) wobei alle Services eigentlich nur eine Methode haben die ein XML Kommando erhält und XML zurückliefert. (auch über XSD beschrieben).

      Alles, was man zum Einbinden eines neuen Services in die Anwendung machen muss, ist ein Eintrag in einem XML-Dictionary und eine Beschreibung des auszutauschenden XML-Objektes hinterlegen.

      Der einzige Nachteil den ich dir nennen könnte ist, dass ein Techniker sich mit mehreren Softwarekomponenten auskennen muss, aber der Zeitaufwand dafür ist mikrig im Vergleich zu einer Systemweiten Änderung, die man durchführen musste wenn nicht mit Schichten arbeitet.

      Wie gesagt, Schichten sind vorhanden. Es geht hier um viele Systeme, die eigentlich nicht darauf ausgelegt sind jemals verbunden zu werden. Aber ich glaube, ich habe die lose Kopplung zu weit getrieben...;)

      Gruß
      LeKuchen

      1. Hallo LeKuchen,

        Ein "o"?

        Ja tatsächlich, es heisst loose coupling! Da hast du bei mir grad eine Lücke entdeckt und gleich gestopft. :)

        Ansonsten weiss ich nicht was ich noch hinzufügen soll. Über Sinn und Zweck von Tiers sind wir uns offensichtlich einig und über die Details von deinem System kann ich nur sagen: klingt gut was du sagst und für alles weitere müssten wir schon in Sourcecode und Datenreinschauen.

        Cheers,
        Cruz