Sinnvolle Modelle und brauchbare Technologien
SOA implementieren mit Open Source

Workflows sind in ihrer Logik speziell für ein Projekt oder einen Kunden zugeschnitten. Die Substanz Ihrer Anwendungen steckt hingegen in den Services. Sie bilden die Quelle für Wiederverwendung. Pflege und Ausbau dieses „Kapitals“ einer IT-Landschaft hat höchsten Stellenwert.

Komponenten der nächsten Generation

Services, die einen fachlichen Zusammenhang haben, werden sinnvollerweise gruppiert. So entstehen Module oder Komponenten. Auch das ist – wie so vieles bei SOA – nichts Neues: Komplexe Aufgabenstellungen werden partitioniert. Beim Schnitt der Komponenten wird auf hohen inneren Zusammenhang (Kohäsion) geachtet und so die Abhängigkeiten zwischen den Bauteilen minimiert.

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 wichtiger Aspekt beim Komponentenbau ist der Fokus auf die Dienste, die sie bereitstellen. Sie stehen im Mittelpunkt und geben einer Komponente erst Ihre Berechtigung. Das ist vielleicht der wesentliche Unterschied zur klassischen Anwendungsentwicklung, wo Schnittstellen oft erst im Nachhinein konzipiert wurden. Konzeption und Dokumentation der Schnittstellen von Komponenten (= Services im engeren Sinne) ist elementar. Wie aber beschreibt man Services? Eindeutig in Signatur und Semantik? Java API (javadoc) ist sprachspezifisch, IDL ist mit Corba aus der Mode gekommen. WSDL (Web Service Definition Language) ist ein pragmatischer Ansatz, wenngleich Experten zu bedenken geben, dass damit nicht alle Aspekte beschrieben werden können.

» weiterlesen

1 2 3 4 5

Beitrag mit anderen teilen:

  • Twitter
  • Facebook
  • FriendFeed
  • t3n Social News
  • del.icio.us
  • MisterWong.DE
  • Digg
  • Identi.ca
  • Technorati
  • RSS
  • E-mail this story to a friend!

Du hast eine Ergänzung oder Frage zum Artikel? Teile sie jetzt mit!