Diskussion:Serviceorientierte Architektur/Archiv/1

message: * Frage: Ein Webservice ist für mich kein Protokoll, ist der Satz
     "Für die Kommunikation zwischen Dienstnutzer und -anbieter können beliebige Netzwerkprotokolle genutzt werden. 
      Häufig werden Webservices, REST oder Message Queueing eingesetzt."
falsch? Er suggeriert mir das ein Webservice ein Protokoll ist obwohl ich dies eher als eine Anwendung ansehe, und diese sich Protokollen wie SOAP bedient zur Kommunikation. Siehe auch: http://de.wikipedia.org/wiki/Webservice
Der entsprechende Artikel sagt etwas anderes: "Die Abkürzung SOAP wird jedoch offiziell seit Version 1.2 nicht mehr als Akronym gebraucht, da es erstens (subjektiv) keineswegs einfach (Simple) ist und da es zweitens nicht (nur) dem Zugriff auf Objekte (Object Access) dient." Solange es keine offizielle Definition gibt, habe ich den Satz geändert. Gruß F. Werner
SOAP steht für Simple Object Access Protocol und nicht etwa wie es im Artikel steht SOA Protokoll!!!!!
* Frage an die Gurus! Im Artikel heisst es "Ein Service ..., die über eine standardisierte Schnittstelle in Anspruch genommen werden kann" Im Buch "Enterprise SOA" heisst es, dass ein Service ein oder meherere Schnittstellen zur Verfügung stellen kann. Ich persönlich versteh darunter eher eine Service Komponente (siehe Komponente aus der UML Spec) die mehrere Services gruppiert und anbietet (Service = eine Schnittstelle, Service Komponente = bietet 1..* Services).
* Ich möchte eine saubere Abgrenzung oder in Relationstellung der Begriffe EAI und SaaS zum Thema vorschlagen, das würde das Thema und die Begriffe deutlicher machen. --Peter86169, 12.02.2008
* 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.
Kleine Korrektur: Im Deutschen schreibt man Komposita tatsächlich zunächst mal in einem Wort. Jedoch ist es korrekt, Bindestriche zu verwenden, wenn mindestens eines der Teilwörter ein Fremdwort oder eine Abkürzung ist. Darüber hinaus ist es auch möglich, Bindestriche zu verwenden, wenn die Lesbarkeit bzw. die Eindeutigkeit leidet (siehe Zusammengesetzte Substantive).
* 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)
replies: text: klar können sie sich gegenseitig aufrufen. das widerspricht auch nicht der losen Kopplung.--Michael Hüttermann 23:30, 8. Jun 2006 (CEST)
thread_title:  Webservices 

message: Aus der Einleitung sollte besser hervorgehen, worum es eigentlich geht, also SOA ist nix zum Essen und keine Kampfsport, sondern soweit ich es verstanden habe, eine Strategie zur Führung in Computerfirmen - oder weshalb wird SOA mit Hilfe von Informatik-Begriffen erklärt? Wie würdet ihr SOA in 2 Sätzen einem Nicht-Informatiker erklären, z.B. euerer Oma? -- Nichtich 18:44, 14. Mai 2007 (CEST)
replies: text: Full ack!! - bin auch kein Informatiker und will's trotzdem wissen. Yotwen 07:36, 15. Mai 2007 (CEST)

text: Full ack!! - dito: Bin seit 8 Jahren in der IT und verstehe hier nur Bahnhof... -. Sorry - aber das liest sich wie eine Babbelfish-übersetzung der englischen Version. dirhoc 10:34, 30. Mai 2007 (CEST)
thread_title:  Worum geht es eigentlich? 

message: Was in dem Artikel nicht zur Sprache kommt aber auch in der Fachliteratur selten behandelt wird ist die Frage, in wie weit SOA dem Zweck dienen kann oder soll, die Industriealisierung der IT, speziell der Systementwicklung, voranzutreiben. In vielen Unternehmen stehen die Anwendungen wie Silos nebeneinander, die kaum voneinander Kenntnis nehmen. Daraus resultiert z.B. die mehrfache Datenhaltung, da verschiedene Anwendungen oft gleiche Stammdaten benötigen. Hier wurde in der Vergangenheit schon reagiert und mit mehr oder weniger überschaubaren Punkt-zu-Punkt-Verbindungen Abhilfe geschaffen. Darunter hat dann aber ggf. die Stabilität der Systeme gelitten, da Abhängigkeiten geschaffen wurden, bzw. durch die Kopplung das Gesamtsystem vergrößert wurde.
Der Aspekt der Industriealisierung im Zusammenhang mit SOA würde aus meiner Sicht bedeuten, dass wir in der IT mit ähnliche Schritten beginnen, wie sie z.B. vor 60 oder 80 Jahren in der Automobilfertigung gegangen wurden. Produkte (Autos) werden nicht mehr komplett in einer Fabrik (Silo) gefertigt, sondern werden aus vorgefertigten Teilen unterschiedlicher Komplexität zusammengebaut. Das können Räder sein, aber auch Motoren oder Navigationssysteme. Daraus hat sich bis heute der gigantische Markt der Zulieferer entwickelt.
So würde ich mir eine Softwareanwendung als ein System vorstellen, dass aus vielen Komponenten (vorgefertigten Teilen) besteht, die aber, je einfacher sie sind, um so mehr auch in anderen Produkten Verwendung finden. Das besondere an SOA ist aber, dass nicht der Code wiederverwendet wird. Vielmehr soll die Wiederverwendung der Software zur Laufzeit des Systems ermöglicht werden. Auf diesem Wege werden sicherlich noch viele Probleme gelöst werden müssen, aber ich denke, dass die IT hier von den reiferen Industriezweigen lernen kann. Wir stehen erst am Anfang!!  -- Hermann530 23:29, 26. Feb. 2009 (CET)
replies: text: Na das Szenario gibts schon seit über 41 Jahren :-)  --Bitsandbytes 08:33, 24. Mär. 2009 (CET)
replies: text: Die IT ist längst industralisiert. Was Sie - und viele vor Ihnen - fordern, ist die Weltformel für die IT. Es werden bereits Bibliotheken, Frameworks, Standards, ... eingesetzt, die einem Alltagsarbeit abnehmen. Die Anbieter dieser Dinge sind alles Zulieferer. Das ist leicht zu übersehen, weil nicht wie in der Automobilfertigung ein ständiger Produktfluß stattfindet. In der Fertigung ist das so, weil ich nicht nur ein Lenkrad kaufen und das in alle Fahrzeuge einbauen kann. In der IT geht das, weil es sich um immaterielle Güter handelt. Wenn Sie konkreter werden und merken Sie, dass es bereits Anbieter gibt oder die Forderung so speziell ist, dass niemand anderes daran interessiert ist. 13:14, 28. Jan. 2011 (CET)
thread_title:  IT-Industrialisierung 

message: Aus der Sicht der Software-Entwicklung steht die SOA ja in einer langen Tradition: die Wiederverwendung von Software-Komponenten ermöglichen/erzwingen. Insofern nix neues, zumal CORBA ein ziemlich ähnlicher Ansatz war und außerdem hat die SOA auch einige offenkundige Nachteile hat (verteiltes System, Redundanz, etc.). Wenn jemand Zeit hat, einen Absatz "Kritik" ausformulieren hier ist Munition: http://www.computerwoche.de/soa-trends/596848/
:Hallo,
:So ganz kann ich die Kritikpunkte nicht nachvollziehen. SOA ist mehr, als ein Schnittstellen/Protokoll-Standard a la CORBA, sondern eher ein erwachsen gewordenes EAI. Der verwiesene Artikel bezieht sich eher auf plakative Marketing-Versprechen einiger Middleware- und Tool-Hersteller.
:Die Frage ist daher eher, wie man die Klarstellung im Artikel plazieren könnte. Vielleicht hat ja jemand eine Idee.
:Viele Grüße, --Peterschrey 22:42, 25. Jan. 2008 (CET)
replies: text: Ich trage hier zwar nichts produktives bei, aber weißt du, wovon du redest? "[..]genügt es schon [..] The Art of Computer Programming verstanden zu haben." - Dazu sagt Bill Gates laut Amazon zum Beispiel: "If you think you're a really good programmer! read [Knuth's] Art of Computer Programming! You should definitely send me a resume if you can read the whole thing.". Aber sind ja nur ein paar tausend Seiten, es genügt "schon", wenn man die verstanden hat (und es sind noch nicht alle Bände geschrieben, falls Knuth das überhaupt in diesem Leben noch schafft). :)--92.201.28.22 00:25, 8. Aug. 2011 (CEST)
thread_title:  Kritik 

message: Dieser Artikel benötigt dringendst wissenschaftlich fundierte (und damit ist empirisch fundierte) Quellen. Es sollte bei der Auswahl der Quellen ausdrücklich darauf geachtet werden, dass diese empirisch fundiert sind und nicht irgendwelche Hersteller zitieren oder Bücher die Marke "eigener Erfahrungsschatz" sind. Beachtet, dass die unter Literatur vorgegebene Literatur diese Vorraussetzungen NICHT erfüllt. Knackapfel 13:36, 26. Aug. 2007 (CEST)
replies: text: Da seit dem Stand von 2007 wahrlich eine Menge geändert wurde, entferne ich den Textbaustein. Übrigens gibt es hierfür die Vorlage  - das ist präziser als die allgemeine Box . Weitere Quellenarbeit darf natürlich trotzdem weiterhin geleistet werden... --Hamburger (Diskussion) 17:33, 12. Mär. 2012 (CET)
thread_title:  Quellen fehlen 

message: HTTP bietet durch seine Verben wesentlich mehr Semantik als das. Das zu ignorieren, ist meiner Meinung nach das Missverständnis, das Ansätze wie SOAP wesentlich komplexer macht als den REST-Architekturstil. Insofern ist es nicht korrekt, unterschiedslos zu sagen, dass REST und SOAP auf das reine Transportprotokoll die komplette Semantik aufsetzen müssen. Für SOAP trifft das zu, REST dagegen nutzt das, was HTTP über die reine Nachrichtenübermittlung bietet. (nicht signierter Beitrag von 91.224.226.196 (Diskussion) 11:25, 5. Sep. 2012 (CEST)
replies: text: Der gesamte Abschnitt "Implementierung einer SOA" enthält ziemlich viele fragwürdige ("HTTP gehört zur Familie der RPC-Protokolle") bzw. schlichtweg falsche Aussagen (z.B. der von dir angesprochene Satz) . Ich habe ihn deshalb markiert. -- 89.12.243.128 21:12, 13. Mai 2013 (CEST)
thread_title:  HTTP ist mehr als ein Protokoll zur Übermittlung beliebiger Nachrichten 

message: Die genannten Beispiele gibt in allen Architekturarten - auch als SOA.
Wenn es SOA-Beispiele sein sollen, dann müßte man doch dazuschreiben: Schnittstelle wurde im xyz-Format publiziert; Dienst wird der abc- und von der def-Applikation genutzt; Messaging zwischen den Diensten nutzt MQS oder was immer etc.
Abgesehen davon: Was soll dieses "von Web-Applikation aufgerufen"? In den Definitionen war nicht davon die Rede, daß nur Web-Services SOA-Dienste sein können. Diesen Satz sollte man streichen.
Einwände? (nicht signierter Beitrag von Ulibaehr (Diskussion | Beiträge) 19:41, 25. Okt. 2006 (CET)
thread_title:  Beispiele sind eher fraglich 

message: Weiß jemand wo der Begriff serviceorientierte Architektur herkommt? Wer hat ihn wann als erstes benutzt? (nicht signierter Beitrag von 212.105.204.101 (Diskussion) 09:09, 4. Jun. 2007 (CET)
thread_title:  Herkunft Begriff 

message: Nur als Hinweis das hier keine Zensur stattfand, neue Beiträge stehen bei Wikipedia immer unten--Ma-Lik  ?  +/- 12:01, 17. Jun. 2008 (CEST)
replies: text: Archivierung dieses Abschnittes wurde gewünscht von: -- (Diskussion) 15:00, 6. Aug. 2014 (CEST)
thread_title:  Verschiebehinweis 

message: * REST ist kein Protokoll sondern ein Architekturstil, der ein Protokoll wie HTTP benutzen kann. (nicht signierter Beitrag von 194.76.29.2 (Diskussion | Beiträge) 09:44, 24. Sep. 2009 (CEST)
replies: text: Archivierung dieses Abschnittes wurde gewünscht von: -- (Diskussion) 15:00, 6. Aug. 2014 (CEST)
thread_title:  Protokoll oder nicht Protokoll