In dieser Session ging es um konkrete Erfahrungen mit SOA aus einem Projekt. Erster Punkt war, dass man den ROI (Return on Investment) nach 12-18 Monaten erreichen soll, was bedeutet dass man schnell zu Ergebnissen kommen muss. Dazu gab es folgende Tipps:
- Klein anfangen
- Opportunistisch sein
- Erst wenig Web Services entwicklen
- Vorhandene Sachen als Web Services exportieren
Kommunikation kann folgende Eigenschaften haben:
- lang-läufige Transaktionen
- asynchron
- zuverlässig
- sicher
- Policy-getrieben
Ein Problem, dass das Projekt nicht gelöst hat, ist Single Sign On. Die bewährten Best Praticeses fangen damit an, dass Schnittstellen in WSDL definiert werden sollten und nicht aus irgendwas generiert werden sollten. Gleiches gilt für die XML Schemata der Dokumente. Das ist eine logische und bewährte Geschichte.
Die Dokumente kann man dann als String oder direkt in der SOAP Message verschicken. Bei Binaries kann man sie durch SOAP mit Attachements verschicken oder im SOAP Body unterbringen.
Ein Problem, dass sich offensichtlich in der Realität tatsächlich ergibt ist Non-Repudiation (Nicht-Abstreitbarkeit). Dabei geht es darum, dass das Senden einer Nachricht nicht abgestritten werden kann, um auf eine eventuelle juristische Auseinandersetzung vorbereitet zu sein. Hier hilft das Signing von XML Security. Bei zuverlässiger Nachrichtenzustellungen gibt es mit WE-Reliability und WS-Reliable Messaging zwei Lösungen. Orchestrierung dann mit WS BPEL.
Die Tipps zum Abschluß waren:
- Das Business muss die Services finden
- XML Dokumente sollten definiert werden statt Objekten
- Asynchrone Kommunikation ist eine gute Sache
SOA ist vielleicht wirklich ein Thema, dass alle 10 Jahre auftaucht, wie gestern einer sagte. Man ist hier doch sehr stark an Mainframe, EDI, MQSeries usw. erinnert. Die Best Practices sind recht logisch und sollten gut etabliert sein. Bei dem ROI sollte man dann wohl gleich anfangen.... ¶ 11:10
