Zum Inhalt springen

Diskussion:Serviceorientierte Architektur

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 9. August 2006 um 19:06 Uhr durch 85.178.106.43 (Diskussion). Sie kann sich erheblich von der aktuellen Version unterscheiden.
  • Man achte bitte auf die korrekte Schreibung von Komposita.

Also: Geschäftsprozess-Anpassungen -> ist ein(!!!) Wort, d.h. kein Bindestrich; dito IT-Unterstützung-Anpassung etc.

  • Die SOA ist doch kein Softwarearchitekturkonzept, sondern

ein Systemarchitekturkonzept, da sie als Nachfolger von C/S-Systemen gilt, die eindeutig Systemarchitektur darstellen.

  • "Service Orientierte Architektur" ist weder deutsch noch englisch, wenn man den Begriff übersetzen wollte, dann müßte man von einer "Dienstorientierten Architektur" sprechen. Ich denke aber, das Übersetzen solcher Fachbegriffe erzeugt mehr babylonische Verwirrung als Nutzen. Ich habe mir erlaubt, wieder den Fachbegriff einzusetzen.
  • Service ist zumindest nach dem Duden ein deutsches Wort (Synonym laut Duden: [Kunden]dienst, Bedienung, Kundenbetreuung), weshalb im deutschen Sprachgebrauch der Fachbegriff "serviceorientierte Architektur" durchaus angemessen ist. Übrigens ist es der Rechtschreibung nach legal "serviceorientierte Architektur" als auch "Service-orientierte Architektur" zu schreiben. Ich habe aus diesem Grund die erste Schreibweise (als die üblicherweise verwendete deutsche Schreibweise für zusammengesetzte Worte) neben den englischen Fachbegriff und vor die Abkürzung hinzugefügt.
  • "...Konzept mit dem die Systemkomponenten aufgrund fachlicher Kriterien lose gekoppelt werden...": Es ist (sicher nicht nur mir) unklar, was mit den "fachlichen Kriterien" gemeint ist.
  • "SOAP, WSDL und UDDI" bilden eine Einheit, das "oder" war hier falsch. --rara 11:46, 24. Nov 2004 (CET)
  • Habe Artikel umformuliert, ein Beispiel spendiert und Links zu Modul und Verteiltes System aufgeführt. Habe ausserdem die optimistische Sicht (bisher nur Vorteile) etwas korrigiert. Ich hoffe, die Grundidee der SOA wird dadurch etwas verständlicher. Exilfranke 00:05, 31. Mär 2005 (CEST)
  • Definition: Die bereitgestellt Definition (in der Version vom 18.05.2005) wurde so von Kollegen und mir an der Universität zu Köln, Lehrstuhl für Wirtschaftsinformatik, Systementwicklung, aufgestellt. Ich habe sie ergänzend hinzugefügt.
  • Ich habe ein Problem damit, dass SOA mit bestimmten Technologien in Verbindung gebracht wird. SOA ist ein Architekturkonzept (eine Architekturphilosphie) und ist damit prinzipiell losgelöst von jeglicher Technologie. CW 10:45, 24. Jun 2005 (CEST)
  • Mich erstaunt zudem der Begriff "dienstbasierte Technologie". Dieser Begriff ist mir vollkommen neu und ich wüsste nicht, welche Technologien ich hier zuordnen sollte. SOA kann mit Webservices umgesetzt werden, genauso gut kann jede andere Technologie verwendet werden (Professionelle SW-Entwickler haben auch schon vor 30 Jahren in Fortran und C Service-orientiert entwickelt!). CW 10:45, 24. Jun 2005 (CEST)
  • Der Hauptgrund für das Aufkommen des Schlagworts "SOA" kommt meiner Meinung nach aus der Managerwelt: Man erkennt langsam, dass man im Unternehmen viele geschäftskritische Anwendungen laufen hat, die alle irgendwie miteinander und untereinander kommunizieren (Request/Response, Batch-Prozesse, Datenbank-Schnittstellen, etc.). Mittlerweile sind diese Kommunikationswege und -arten so eng gekoppelt, dass Erweiterungen in einem System Änderungen in vielen nachgelagerten Systemen zur Folge haben (was man dann an hohen Investitionskosten und "stöhnenden Entwicklern" spürt). Diese Zusammenhänge sind für Nicht-Techniker schwer nachvollziehbar. Mit dem Buzz-Word "SOA" wird nun versucht, Manager zu überzeugen, dass sie zunächst Investitionen in die Bereinigung der System-Abhängigkeiten tätigen müssen, bevor große Neuentwicklungen in Angriff genommen werden können. Da dies meine persönliche Meinung ist und ich nicht weiß, ob und wie ich sie in den Artikel einfließen lassen kann, habe ich sie mal hier dokumentiert :-) CW 10:45, 24. Jun 2005 (CEST)

@rara: Warum glaubst Du C/S Architekturen waeren nicht auch ein Software Konzept? Und was hat ein (Software)Service mit einem System zu tun? Mag sein, dass wir ein unterschiedliches Verständnis von Systemarchitektur haben, aber meiner Ansicht nach sind beides Softwarearchitekturen. Leider fehlt eine Definition von Systemarchitektur in der Wikipedia. Gruss -- 6. Jul 2005 00:25 (CEST)

  • Ich frage mich, wie das "lose gekoppelt" zu verstehen ist. Ein semantischer Zusammenhang zwischen 2 SW-Komponenten (also jetzt 2 Services) kann auch in einer SOA nicht zufriedenstellend gelöst werden. Ein Service muss in der Realität in bestimmten Fällen auf einen bestimmten Service-Consumer hin gut zugeschnitten sein (Datenformat, Performance, etc.)! CW 10:20, 26. Jul 2005 (CEST)
  • "Lose Kopplung" bedeutet, dass zwei Komponenten (Service Requester/Responder) nicht zwangsläufig aufeinander angeweisen sind. Wird z.B. der Responder geupdatet, so hat dies keinen Einfluß auf den Requester. Die beiden Komponenten sind z.B. nicht gemeinsam kompiliert oder befinden sich nicht im gleichen Java Package, oder ähnliches.
  • Eine weitere Frage: Sollen Services sich a) gegenseitig aufrufen dürfen oder werden b) alle Service-Requests von der Service-Orchestrierung vorgenommen? M.E. ist keine der beiden Alternativen optimal: a) besitzt praktisch keinen Unterschied zu bisherigen verteilten Komponenten-Architekturen; b) führt in bestimmten Fällen zu extremen Performance-Problemen (z.B. Join von Daten unterschiedlicher Services - im Brokerage-Bsp.: "Gib mir die Börsenkurse aller Wertpapiere, die mit 'A' beginnen"). Gibt es darauf eine eindeutige Antwort? CW 09:30, 18. Okt 2005 (CEST)

zu a,b) lt. meinen Unterlagen aus Vorlesungen können Services sich sehr wohl gegenseitig aufrufen. Zuviele gegenseitige Aufrufe widersprechen aber dem Konzept der losen Kopplung. Aber es wird zB häufig ein Service gemacht der mehrere kleinere Services aufruft. Wichtig ist hier aber wieder, wenn immer nur der große Service benutzt wird warum mache ich dann auch die kleineren Services was der Grobgranularität (Services so groß wie möglich) widerspricht. wonko79 17:16 08 Jun 2006 (CEST)

klar können sie sich gegenseitig aufrufen. das widerspricht auch nicht der losen Kopplung.--Michael Hüttermann 23:30, 8. Jun 2006 (CEST)

Zu a) Dass, wie du schreibst, kaum ein Unterschied zur herkömmlichen Komponententechnik besteht liegt doch schlicht daran dass es kaum einen Unterschied gibt: Man sieht hier deutlich wie aus Marketinggründen alter Wein (seit Jahrzehnten im Einsatz) in neuen Schläuchen mit dem Label "SOA" verkauft werden soll. Jan-Henner Wurmbach 18:33, 27. Jul 2006 (CEST)