Warum ich integrierten Lösungen misstraue

January 29, 2007 at 11:30 am Leave a comment


Ich habe mich in letzter Zeit immer wieder dabei ertappt, dass ich bestimmten Lösungen pauschal misstraue. Dabei spielt es keine Rolle, ob es sich um eine Bibiothek, eine Framework, eine Entwicklungsumgebung oder ein anderes Werkzeug handelt.

Ich fragte mich:

  1. Was ist allen diesen Lösungen gemeinsam?
  2. Ist dieses gemeinsame Merkmal der Grund für mein Misstrauen?
  3. Ist mein pauschales Misstrauen wirklich gerechtfertigt oder bin ich meinen eigenen diffusen Vorurteilen erlegen?

zu 1) Die Gemeinsamkeit der Lösungen liegt in der Integration. Die Lösungen werden damit, besonders gut oder weitgehend integriert zu sein. Das trifft z.B. auf EJBs zu, die verteilte Methodenaufrufe,Transaktionshandling und Security integrieren. Es trifft auf immer mehr Application-Server zu, die sichnicht auf die reine JEE-Technologie beschränken, sondern zusätzlich ESBs (Enterprise-Service-Bus), BPEL, SOAPetc. unterstützen und mit JEE integrieren. Und es trifft auf fast alle kommerziellen Tools zu, die z.B. direkteinen bestimmten Application-Server integrieren.

zu 2) Ja, ich gestehe: Das was die Hersteller als großen Vorteil ihrer Lösung herausstellen, bereitet mirein diffuses Unbehagen.

zu 3) Was also könnte ich – unterbewusst – gegen Integration haben? Integrierte Lösungen nehmen mir dochArbeit ab. Integration hat je nach Geschmacksrichtung unabdingbare die alles andere als wünschenswert sind:Die erste Geschmacksrichtung gibt den monolithischen Lösungen einfach einen neuen Namen, nämlich “integrierteLösung”. Bei der zweiten Geschmacksrichtung besteht die Gesamtlösung aus verschiedenen Teilen, die integriertsind. “integriert” bedeutet, dass es mind. eine Abhängigkeit zwischen den Einzelteilen geben muss.
Integrierte Lösungen beider Geschmacksrichtungen führen dazu, dass man die Lösung mehr oder weniger komplett verwenden muss. Auf jeden Fall ist es schwierig, für einen Aspekt der Gesamtlösung eine alternative Einzellösungeinzusetzen. Das ist für kleine Projekte vielleicht noch akzeptabel, für große Projekte ist es eine Katastrophe:Man bindet sich im Grunde für alle Zeit an die Gesamtlösung und hat keine Chance, von neue Entwicklungen am Marktzu profitieren.
Darf man also keine Lösungen einsetzen, die sich “integriert” nennen? Doch, indem man sie deintegriert! Dazu teiltman ein großes Projekt in einzelne Subsysteme auf, die technologisch lose gekoppelt sind. Lose Kopplung bedeutet hier, dass sich die verwendeten Technologien innerhalb eines Subsystems austauschen lassen, ohne dass Änderungenan anderen Subsystemen notwendig werden.

Konkret kann man eine solche technologisch lose Kopplung leicht durch gängige Kopplungstechnologien wie REST,XML-RPC, JSON-RPC oder SOAP erreichen. Dann spielt es für die Kopplung keine Rolle, ob die einzelnen Subsystemeintern EJBs, Hibernate oder Spring verwenden und ob als Programmiersprache Java, Ruby, Cobol oder sonstwas eingesetzt wird.

Entry filed under: Uncategorized. Tags: .

Für Groovy stimmen! Lisp vs. XML

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: