 |
|
|
|
SOA implementieren mit Open Source
22.03.07
Glaubt man einschlägigen Veröffentlichungen, ist die Frage, ob SOA nötig ist oder nicht, beantwortet. Nun gehe es darum, wie eine SOA am besten zu erreichen sei. Die Diskussionen um den Nutzen ebben derweil ab und es gilt, schnellstmöglich die Anwendungslandschaften zu strukturieren, sodass die versprochenen Früchte des SOA Paradigmas geerntet werden können. Aus Sicht der Tool-Anbieter ist das Vorgehen klar. Anwender und Dienstleister können sich jedoch einer differenzierten Betrachtung nicht entziehen.
[…] Neu ist vielleicht der Aspekt, dass Komponenten (Anwendungen sind zu grob-, einzelne Services zu kleingranular) Ihre Entwicklungseinheiten (Teams, Versionen, Deployments) bestimmen. Eine ordnende Hand – zum Beispiel ein Architektur-Board – stellt dabei sicher, dass der Nutzer der Vision eines flexibel kombinierbaren Baukastens mit Elementen, die aufeinander aufbauen und einander ergänzen, näher kommt. Hier erfordert SOA kein besonderes Tooling und keine spezielle Infrastruktur. Es wird sorgfältig angewendet, was gutes Software Engineering ausmacht. Einheitliche Infrastruktur und Entwicklungswerkzeuge fördern die Homogenität im Baukasten. Der Software-Dienstleister Danet, Arbeitgeber des Autors, setzt hier beispielsweise auf „Mainstream“ und Quasi-Standards im Java-Umfeld (eclipse, cvs, ant, JUnit, J2EE, Hibernate, etc.).
[…] 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.
|
|
