Home

Arbeitskreis Serviceorientierte Architektur (SOA)
Der Arbeitskreis SOA der Münchner GI-Regionalgruppe ist ein lockerer Zusammenschluss von engagierten SOA-Spezialisten aus der Münchner Region. Der Arbeitskreis ist unabhängig und dient dem Erfahrungsaustausch.

Interessenten können sich per E-Mail an gi-ak-soa-subscribe@yahoogroups.com (Inhalt beliebig) in die Mailingliste eintragen.

Die Gesellschaft für Informatik e.V. (www.gi-ev.de) ist eine gemeinnützige Fachgesellschaft zur Förderung der Informatik in all ihren Aspekten und Belangen. Gegründet im Jahr 1969 ist die GI mit ihren heute rund 24.500 Mitgliedern die größte Vertretung von Informatikerinnen und Informatikern im deutschsprachigen Raum. Die Mitglieder der GI kommen aus Wissenschaft, Wirtschaft, Lehre und Forschung.

Der Arbeitskreis trifft sich wieder am 18.6.2008, u.a. mit einem Vortrag zur SOA Forschung an der LMU.

Sprecher
Ulrich Bode
Sprecher AK SOA
Am Hirthaus 3
82239 Alling
Tel. 0171/8292939
E-Mail mail@ulrich-bode.de

Münchner Arbeitskreis erarbeitet Thesen zum Enterprise Service Bus (ESB)

Der Arbeitskreis Serviceorientierte Architektur (SOA) der GI-Regionalgruppe München hat fünf Thesen zum Enterprise Service Bus (ESB) erarbeitet. Die Thesen im Einzelnen:

1. "Bus" ist der falsche Begriff
"Bus" ist ein topologischer Begriff. Der ESB kann z.B. auch ein Gateway sein, wenn er zwei Unternehmen verbindet. Anstelle der topologischen Sicht sollte eine funktionale Sicht treten.

2. ESB ist eine Sammlung von Services
Besser ist es daher den ESB als Sammlung von Services aus dem Bereich Middleware zu verstehen. Die Service-Sicht passt auch wesentlich besser in das Konzept einer SOA.

3. Vorrang für die Architektur
In einer SOA haben die Businessanforderungen und die SOA-Architektur Vorrang vor dem ESB. Der ESB ist ein nachrangiges, meist technisch bedingtes Thema.

4. ESB bedarfsabhängig auswählen und einsetzen
Ein ESB und die benötigten Services sind bedarfsabhängig auszuwählen. Zum ESB gibt es mehrere Alternativen. Zum einen sollte geprüft werden, ob die Ursache des Bedarfs gelöst werden kann. Aus Zeit- und Kostengründen ist das oft nicht möglich. In einer langfristigen IT-Planung gehören entsprechende Arbeitspakete aber eingestellt. Zum anderen können die notwendigen Services selbst entwickeln oder als Spezialservice eingekauft werden. Dies ist vor allen dann sinnvoll, wenn nur ein kleines Spektrum eines ESBs benötigt wird. Nicht zuletzt kann auch eine bestehende EAI-Lösung (Enterprise Application Integration) ausreichend sein.

5. Super-ESB droht
Zunehmend werden Funktionen auch aus Bereichen wie Monitoring oder Business Auswertungen in den ESB integriert. Hier besteht die Gefahr einer Überfrachtung des ESBs. Ein weiteres Problem ist, dass die ESBse verschiedener Hersteller nicht ausreichend harmonieren. Dies führt dann zur Problematik, dass ein Super-ESB für heterogene ESB-Landschaften etwa nach Unternehmensfusionen erforderlich ist. Dieses Problem besteht schon bei EAI-Implementierungen und sollte durch den ESB eigentlich gelöst werden.