Software & Infrastruktur

Sinnvolle Modelle und brauchbare Technologien: SOA implementieren mit Open Source

Seite 4 / 5

Zumindest können die Datenstrukturen als Schema (XSD) in allgegenwärtigem XML beschrieben werden. Darüber hinaus ist, gerade zur Klarstellung der Semantik, textuelle Dokumentation – zum Beispiel in Form von Wikis – viel wichtiger als formale Register. Zur Laufzeit wohnen die Komponenten in Service Containern – J2EE Application Server (z. B. JBoss) bieten dazu viel Komfort. Je nach Anwendungsfeld machen auch leichtgewichtigere Alternativen Sinn.

Theoretisch kann das Aufbrechen monolithischer Anwendungen in Komponenten dazu führen, dass die „Make-or-buy Entscheidungen“ nun auf Komponentenebene getroffen werden. So verkündet SAP beispielsweise auf einer letztjährigen JAX Keynote das „versöhnliche Nebeneinander von SAP und Eigenbau dank SOA“. Man darf gespannt sein, wie das in der Praxis aussieht.

Im Konzert

Komplexe Landschaften, zerlegt in Komponenten und Geschäftsprozesse, erfordern wiederum Integration der Bauelemente und die Kommunikation zwischen ihnen. Das ist so gesehen die Kehrseite der Modularisierung und erhöht die Komplexität des Gesamtsystems. Je loser die Kopplung, desto komplizierter gestaltet sich das Zusammenwirken, spätestens dann, wenn nicht nur der Gutfall Betrachtung findet. EAI Lösungen in Form von „Integration Backbones“ mildern das Problem, sollten aber kein Selbstzweck einer SOA Initiative sein. Insbesondere ist es wünschenswert, die Abhängigkeiten Ihrer Services und Komponenten von der Middleware zu minimieren. Dazu gibt es im Wesentlichen zwei Ansätze, so genannte „Invocation Frameworks“ (z. B. WSIF [4] ) und Generatoren, die den Kleber zwischen fachlicher Logik und technischem Kommunikationsmechanismus automatisch erzeugen.

Ein mittlerweile aufgeklärtes Missverständnis ist, dass SOA WebServices, also SOAP über HTTP, erfordere. Das ist nicht so. WebServices ist für Kommunikation über Unternehmensgrenzen hinweg (B2B) meistens die richtige Wahl, innerhalb von Unternehmen in der Regel nicht. Die Firma Danet verwendet dazu drei verschiedene Lösungsmuster: RMI/IIOP für enge Kopplungen zwischen Java Komponenten, XML über JMS für asynchrone, lose Kopplungen und WebServices für externe (B2B) Interfaces. Dabei wurde die Erfahrung gemacht, dass verfügbare Open-Source-Infrastruktur (z. B. Axis, ActiveAQ, JBoss Messaging, Xerces) sehr gut anwendbar ist. Eigenentwicklungen auf dieser Ebene sind für Dienstleister und Lösungshersteller normalerweise nicht sinnvoll. Auf der anderen Seite sind Abhängigkeiten von kommerziellen SOA und EAI Produkten eher hinderlich. In der Praxis wählen große Kunden Integrationsplattformen selbst aus und lassen Dienstleistern kaum Freiraum, während kleinere Kunden die Lizenzkosten kommerzieller Middleware nicht tragen können.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!