Diskussion:Webservice/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Webservice/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Webservice/Archiv/1#Thema_1

"Vorteil" HTTP ...

Das gehört eher zur Beschreibung denn zur Wertung. Das Firewall-Argument lahmt: auch HTTP kann und wird (standard)port- oder contentgeblockt.

Ein Anbieter muss wissen wie er seine Firewall konfiguriert. Ein Nutzer muss sich auf die Angebote einstellen: absolut exklusive Filter werden deshalb meist nur von Leuten eingesetzt, die sich damit auskennen.

Gerade weil im Nachsatz erwähnt wird, dass WS nicht über HTTP laufen müssen wäre das unter der "Faktenaufzählung" besser aufgehoben.

-- Leonidas 15:56, 19. Apr. 2007 (CEST)

Nachteile

"Die Hauptschwierigkeiten bei der Umsetzung von Web Services dürften Sicherheitsaspekte betreffen." Durch https und die Möglichkeit die selbst Pakete zu verschlüsseln und zu signieren sollte doch ausreichen. Wo gibt es bessere Möglichkeiten die Sicherheit zu gewährleisten? Ist das nicht eher ein Vorteil von Webservices?

• Gehts hier nicht um die UMSETZUNG? Die Konfiguration für z.B. WS-Security ist sehr umfassend und komplex daher ist Umsetzung der Security sehr aufwendig und eine Hauptschwierigkeit. Die Sicherheitsoptionen für Web services sind mehr als ausreichend.

--80.146.178.220 11:06, 20. Mär. 2009 (CET)

Bin zwar kein DAU ...

Aber wenn ich einer wäre, aber könnte ich zumindest mit der Definition am Anfang nicht sonderlich viel Anfangen. Alleine schon die Begriffswahl "Artefakte", "Software-Agenten" könnte mancher überfordert sein. Bei diesen Worten fallen mir zuerst Indiana Jones und 007 ein.

Dann noch generell: Stimmt zwar, dass sie eine Uri haben müssen, das muss aber so ziemlich alles, was übers Web erreichbar sein will. Frage ist also, ob ich den Leser mit so was dann noch zusätzlich verwirren will. Das gleiche Spiel mit "internetbasierte Protokolle". SOAP Nachrichten kann ich im Prinzip über andere Protokolle austauschen. Das es jedoch in der Regel das Web gemeint ist, impliziert ja schon der Name "Web Service".

Was hingegen komplett fehlt, ist der Hinweis, dass sie entwickelt wurden, um über Programmiersprachen- und Systemgrenzen hinweg kommunizieren zu können.

Sehr gute Einwände. Stimme in allen Punkte zu, bis auf die Sache mit dem Protokollen, das sollte schon erwähnt werden. Wurden denn die Änderungen schon durchgeführt? --Ukrueger 11:00, 27. Apr. 2008 (CEST)

ich finde die Einleitung ebenfalls ausbaufähig. Der Link auf Protokolle sollte auf Protokolle(Informatik) verweisen. Das Wort internetbasiert ist schlichtweg falsch, da - wie schon angemerkt wurde- auch andere, beliebige Protokolle zum Transport verwendet werden können;

was haltet ihr von der Abwandlung der Einleitung in "Ein Webservice bzw. Webdienst ist eine Software-Anwendung deren Schnittstellen mittels XML definiert und beschrieben werden. Ein Webservice ist durch einem Uniform Resource Identifier (URI) eindeutig identifizierbar und unterstützt die direkte Interaktion mit Clients durch den Austausch XML- basierter Nachrichten mittels Protokollen, über Grenzen von Betriebssystemen und Programmiersprachen hinweg." Ich bin mir nur nicht sicher, ob dieser Einstieg schon zu viele Informationen enthält. Außerdem frage ich mich, ob man den Bezug von SOA noch herstellen sollte, oder ob das auch schon zu weit vorausgegriffen ist. Ich bitte um ausführliche Kritik. 30. Mai 2008 jnoack (falsch signierter Beitrag von 213.187.75.155 (Diskussion) 14:14, 30. Mai 2008 (CEST))

Internet Protokoll Stack erklären

Würde es nicht Sinn machen, den Internet Protokoll Stack zu erklären? Statt Internet und Protokoll getrennt zu verlinken? OliD 19:57, 17. Mai 2003 (CEST) Ist erledigt...

Webservice vs. Distributed Object Technology

Sind Web-Services wirklich vergleichbar mit Technolgien wie CORBA oder DCOM? Webservices sind meiner Meinung nach (noch) keine verteilten Objekt-Technologien. Viele Aspekte verteilter Objekt-Technolgien stecken in der Webservice-Praxis noch in den Kinderschuhen. In diesem Artikel auf diesen Aspekt eingegangen. Er enthält ausserdem eine - in meinen Augen - gute Definition von Webservices.

Ich habe mich bei der Definition nun sehr an den W3C gehalten. Gefällt Sie Euch? Stern !? 12:58, 10. Mai 2005 (CEST)

Ein Webservice ist ein Dienst, der mit Hilfe von XML auf der Basis von Internet-Netzwerkprotokollen erbracht wird (NICHT ZWINGEND!)

Ist das nicht grundsaetzlich falsch? Er kann und wird in der Regel auf dieser Basis verwendet, ABER: ein WebService ginge auch auf Basis von Brieftauben (mal als abstraktes Beispiel), wenn man woellte.

Beschreibt Webservice nicht vielmehr das/ein Konzept?

Vor allem sollte man darauf abheben dass WebServices nicht zwingend etwas mit dem Web zu tun haben, nur weil der Name dies vermuten liesse.

Ist es nun besser formuliert? Stern !? 12:57, 10. Mai 2005 (CEST)

Die Aussage Web Services haben mit Web zu tun ist grundsätzlich richtig und bezieht sich auf den Industrie Standard wie er heute von den Trägern der Spezifikationen verstanden und erarbeitet wurde. Und dies sind immerhin Konkurrenten die hier gemeinsam agieren. IBM, Microsoft, Oracle, SUN usw. Man bezieht sich hier auf ein Konzept nachdem:

a) eine Erreichbarkeit eines Services in Form einer registrierten URI garantiert wird

b) ein standarisiertes Protokol (in der Regel http basiert) zum Austausch von XML Dokumenten verwendet wird

c) eine Domain Registrierung auf i.d R public über Internet erreichbaren Registrierungs Name Servern für den Zugriff und die Interoperabilität mit Fremd systemen.

d) eine Interoparibilität von miteinander nicht verwandten Systemen über das öffentliche Internet angestrebt ist

mit Brieftauben hat das nichts gemeinsam. Der Service ist in keiner Weise der Transportmechanismus sondern das Portal zur Applikationslogic oder Business Intelligence des Betreibers. . Was nicht richtig ist ist die folgende Aussage: vergleichbare Technologien wie CORBA, DCOM oder auch Java RMI. Hier handelt es sich nicht um vergleichbare Technologien da die Zielsetzung (nämlich remote Prozeduren oder Methoden auszuführen oder aufzurufen also aus einem Client Server Kontext heraus in einem entfernten System Prozesse auf Applikations Ebene durchzuführen) vollkommen anders ist. Diese Technologien sind zwecks anderer Zielsetzung von daher nicht vergleichbar. XML Transaktionen zum Abgleich von unterschiedlichen Kommunikationsstrukturen für die Übernahme von Daten aus Fremdsystemen in die eigene Geschäfts Logic sind eben keine Funktions Aufrufe.

M.Zielke

Zu b) Es werden keine XML-Dokumente ausgetauscht, sondern nur das Format der Dokumente in XML beschrieben. Es können z.B. auch POJOs ausgetauscht werden (siehe auch WSDL). Leider wird das hier nicht herausgearbeitet, sondern gleich im zweiten Satz Falschaussagen getroffen. Ein Web Service kann auch mittels Java-RMI kommunizieren, was sicherlich kein internetbasiertes Protokoll ist. --Xflupp 15:34, 16. Mär 2006 (CET)

zu c) da fehlt ein Verb

zum eigentlichen Thema

Web Services sind unabhängig vom Transportmechanismus zu sehen. Wenn sie auf SOAP aufbauen können unterhalb von SOAP beliebige Transportprotokolle verwendet werden. Web Services stellen einen Dienst hinter einer standardisierten Schnittstelle zur Verfügung. Diese Schnittstelle wird meist durch ein WSDL File beschrieben und ist hinter einer URL oder über eine URI erreichbar. (Wäre sie es nicht, würde niemand den Service nutzen können, welcher ebenfalls über eine URI eindeutig gekennzeichnet sein muss) Andere Beschreibungsformen der Schnittstelle sind möglich, wie SSDL [1]und WADL [2] zeigen. Insofern kann jedes Protokoll, mit dem XML Strukturen übertragen werden können, verwendet werden. Eine wichtige Nebenbedingung zu einem Web Service ist die Kommunikation über XML basierte Nachrichten (z.B. SOAP), was im Falle von REST basierten Web Services allerdings aufgeweicht wird, da zu übertragende Datenstrukturen nicht zwangläufig über XML beschrieben werden müssen.(ein simpler GET Befehl ist keine XML Struktur, löst aber eine XML basierte Nachricht aus)

Web Services wurden entwickelt, um möglichst kompatibel zu verbreiteten Betriebssystemen, Programmiersprachen und Hardware zu sein. Das WS-I Basic Profile zeigt, dass es in Version WSDL 1.x nicht gelungen ist, dieses Ziel vollständig zu erreichen.(Für WSDL 2 existiert noch kein WS-I Profil)

zur Problematik RMI/CORBA

Herrn Zielke muss ich widersprechen: Web Services dienen nicht nur dem Datenaustausch, oder der "Übernahme von Daten aus Fremdsystemen". Ein Web Service kann sehr wohl auch Daten einer Anfrage manipulieren, wie dies eine entfernte Methode tun würde. Der Vergleich zu RMI und CORBA ist daher gerechtfertigt. Nicht zuletzt existieren weitere Gemeinsamkeiten. Bei CORBA werden auszutauschende Strukturen über IDL beschrieben, bei Web Services über z.B. XML Schema(oder Relax NG oder Schematron oder DTD...)

Anhand welchen Schemas die Nachrichten letztendlich validiert oder „ge(un)marshallt“ werden, ist eine Frage der konkreten Umsetzung. Fakt ist nur, dass eine solche Beschreibung, der zu übertragenden Nachrichten existieren muss.

Bei RMI existiert die „Registry“, bei CORBA der ORB, für Web Services existiert z.B. UDDI.

Web Services stehen sozusagen in der "Tradition" von RMI und CORBA, wie man auch beim AXIS(bzw. AXIS2) Framework verfolgen kann, welches zunächst JAX RPC und nun in Version AXIS2 JAX WS implementiert. Die RPC Varianten sind sozusagen die "Ursprünge" der Web Services, die Mittlerweile, und da muss ich Herrn Zielke recht geben, zum Austausch von Dokumenten ("Document/Literal" Kommunikation über SOAP, Anhänge in Nachrichten mittels SAAJ...) verwendet werden

zu Xflupps Kommentar zu b

Java RMI ist kein Protokoll. Somit können Web Services nicht über RMI kommunizieren. Es ist eine "Technologie" für entfernte Methoden(Systeme). Außerdem fehlt bei RMI eine menschenlesbare Beschreibung der Service Schnittstellen und der zu übertragenden Objekte.

Soweit mein Beitrag zur Diskusion jnoack 28. Mai 2008 (falsch signierter Beitrag von 213.187.75.155 (Diskussion) 15:14, 28. Mai 2008 (CEST))

http alleiniges Protokoll?

In Bezug auf die Internet-Netzwerkprotokolle: "Durch die Verwendung des HTTP-Protokolls zur Datenübertragung treten nur selten Probleme mit Firewalls auf [...]". Das ist meiner Meinung nach sogar grob falsch, weil hier der Eindruck entsteht, dass nicht nur grundsätzlich Internet-Netzwerkprotokolle verwendet werden (was sicherlich in den meisten Fällen tatsächlich so ist), sondern, dass stattdessen sogar grundsätzlich http genutzt wird. Ich könnte mir aber auch ftp, smtp oder eigene dinge vorstellen. Sieht das jemand anders? (ansonsten stimme ich mit den obigen Einwänden überein...)

Du hast Recht. Ich habe mich da undeutlich ausgedrückt und werde es ändern. Stern !? 12:56, 10. Mai 2005 (CEST)

So find ich's gut. Kann man so stehenlassen. (nicht signierter Beitrag von 84.134.45.32 (Diskussion) 13:22, 17. Mai 2005 (CEST))

HTTP-Protokoll !? Hypertext Transfer Protokoll-Protokoll? Irgendwie passt dat nicht.

Schreibweise

Ich schlage vor, dass wir im Artikel durchgängig die Schreibweise "Web Service" verwenden. In der mir vorliegenden deutschsprachigen Literatur überwiegt dies vor Schreibungen wie "Webservice" oder "WebService". Einsprüche? Stern !? 21:16, 2. Mai 2005 (CEST)

Anders als im Englischen schreibt man im Deutschen zusammengesetzte Wörter zusammen. Siehe dazu auch den sehr lustigen Artikel "Dem Wahn Sinn eine Lücke" im Zwiebelfisch vom 22. Dezember 2004 (http://www.spiegel.de/kultur/zwiebelfisch/0,1518,333774,00.html). Weder "Web" noch "Service" sind zwar ursprünglich deutsche Wörter, der Duden listet aber beide als Fremdwörter. Bei einer Übername eines Wortes aus einer fremden Sprache werden damit aber nicht die Regeln der fremden Gramatik übernommen. Ich bin daher für die Schreibweise "Webservice" mit dem Hinweis (engl. web service). hauix 10:15, 11. Mai 2005 (CEST)

Ich würde Dir grundsätzlich zustimmen und ich bin auch regelmäßiger Zwiebelfischleser, frage mich aber, ob man "Web Service" hier nicht als Eigenname verstehen muss. Es handelt sich ja um ein vom W3C spezifiziertes Verfahren. Ich hasse diese Leerzeichen, aber hier tendiere ich selbst zu der Schreibweise. Stern !? 22:18, 11. Mai 2005 (CEST)

Je mehr Webservice zu einem Eigennamen wird, dest mehr sind selbst die Englichsprecher bereit, das Wort zusammenzuschreiben. Der Google-Test spricht ganz klar für die Zusammenschreibung: Die Suche nach "webservice" ergibt 10 Mio Treffer, "web service" dagegen nur 6.6 Mio Treffer. Lustigerweise schlägt Google sogar bei der Suche nach "web service" vor, ob man denn nicht "webservice" gemeint hat. http://www.google.de/search?q=%22web+service%22&btnG=Suche hauix 13:48, 17. Mai 2005 (CEST)

Ein Google-Vergleich ist in diesem Fall nicht möglich, weil Google automatisch »Web Service« mit einbezieht, wenn man nach »Webservice« sucht. Kein Wunder, dass »Webservice« mehr Treffer ergibt.

Ich setze jetzt erst einmal überall »Web Service« hin, weil das Lemma so lautet und der Artikel Webservice eine Weiterleitung ist. Wenn jemand anderer Meinung ist - mir ist es wurscht, Hauptsache Lemma und ARtikel stimmen überein und der Artikel ist einheitlich - bitte das Lemma ändern. -- molily 21:24, 14. Jul 2005 (CEST)

Diskussion aus dem [Wikipedia:Review|Review]] (Mai)

Habt Ihr Ergänzungsvorschläge? Mich würde auch mal interessieren, ob der Artikel halbwegs laienverständlich ist. Stern !? 21:38, 2. Mai 2005 (CEST)

Ich habe den Artikel aus dem Blickwinkel des DAUs gelesen; hier meine Kommentare. Schon die Einleitung würde mich bei "Drüberstolpern" abschrecken. Gleich 4 Begriffe, über die ich bestenfalls vage Bescheid weiß (exakte Definition Schnittstelle, Internet-Netzwerkprotokoll und E-Business ist mir nicht bekannt, bei XML weiß ich gar nicht, worum es geht) bedingen das Lesen der Links, um überhaupt zu kapieren, worum es hier geht. Wesentlich verständlicher ist die Grundfunktion hingegen bereits im ersten Satz von "Architektur" erklärt. Diesen Abschnitt empfinde ich als durchweg verständlich formuliert. Das Gleiche gilt für den Abschnitt "Beispiel". Schwieriger wird es schon wieder unter "Vorteile" und "Nachteile", hier wirken die verwendeten Begriffe aber längst nicht so abschreckend wie in der Einleitung und man wird zum Linklesen animiert. Der Textfluß ist durch die vielen Absätze hier allerdings nicht optimal. Abschnitt "Anwendungsgebiete" und "Erweiterungen": wirken unter dem Gesichtspunkt der oben angeführten Bedeutung (Webseiten für Computer) noch etwas dünn. Viele Grüße --Kalumet 21:58, 2. Mai 2005 (CEST)

warum sollte sich ein dau für web services interessieren? begriffe die er nicht kennt, wird er bei echtem interesse schon nachschlagen... --Seenuss 07.07.06 (falsch signierter Beitrag von 217.7.68.91 (Diskussion) 08:03, 7. Juli 2006 (CEST))

Was Web Services nicht sind

Web Services sind nicht MiddleWare.

Warum sind Web Services keine Middleware und warum gibt die Middlewareseite Web Services als Beispiel für Middleware an?

Das sollte vielleicht mal klar gestellt werden.

Ich bin auch der Meinung, dass diese nicht-Definitionen nicht sehr hilfreich und vielleicht sogar falsch sind. Der Web-Service Stack beinhaltet z.B. Transaktionssicherheit (WS-Transaction) und Web Services sind eine ideale Technik für EAI. --PeterGerstbach 13:39, 19. Jan 2006 (CET)

Ich bin auch grad darüber gestolpert eben weil ich mir über die absolute Definition was eine Middleware ist nicht sicher bin. Der Aspekt der Vermittlungskomponente verwundert mich etwas - ist damit gemeint, dass WS stateless sind und keine Verbindung aufrecht erhalten?. Was ist genau damit gemeint? Ich denke, auch eine proprietäre Socket-Selbstimplementierung ließe sich als Middlware definieren, unabhängig von ihrer Struktur, wieso dann nicht auch WebServices? -- (Jochen) (falsch signierter Beitrag von 84.145.243.23 (Diskussion) 17:10, 7. Juli 2006 (CEST))

würde einen Nachteil aus dem Artikel eher als Vorteil sehen

den Punkt mit "den Bezahlmodus bei kostenpflichtigen Angeboten." würde ich nicht als Nachteil sondern eher als Vorteil sehen. Es lassen sich mittels Web Services recht einfach Module zu Verfügung stellen. Abrechnen kann man dann mittels einem Passwort was beim Aufruf übertragen & geprüft wird. Dann kann man ganz leicht nach "Anzahl Abrufen" abrechnen (nicht signierter Beitrag von 84.154.5.86 (Diskussion) 16:21, 26. November 2005 (CET))

Ausserdem ist nicht erkennen, warum dieser Punkt ein Nachteil von Web services sein. Es ist doch wohl eher ein generelles Problem, wenn sich ein Betrieb auf die EDV verlaesst. -- sparti 02:43, 29. Nov 2005 (CET)

Für Laien unverständlich

Also für Laien ist die allgemeine Definition unverständlich. Bin zwar nicht auf der "Nudlsuppn daher gschwommen", was das Programmieren angeht, aber diese Definition ist nichtsaussagend, wenn man diesen Sektor der Computerwelt zum ersten Mal betritt. --MCMoses 11:00, 28. Nov 2005 (CEST)

Bild in diesem Zusammenhang korrekt ???

Ich hätte eine Frage zum Bild Datei:Http://upload.wikimedia.org/wikipedia/de/thumb/9/95/Webservice.png/180px-Webservice.png auf der Seite. Ist im dargestellten Zusammenhang (also Web Services) die Angabe zum Aufruf eines Web Services per XML-RPC korrekt? XML-RPC ist schliesslich ein wesentlich kleiner Standard, der gegenüber SOAP recht eingeschränkt ist (festgelegte Tags, kein Anhang (soap:attachment), etc.). Ist ein Web Service generell in der Lage XML-RPC Aufrufe zu verstehen? (nicht signierter Beitrag von 141.30.119.136 (Diskussion) 15:44, 13. April 2006 (CEST))

Stichwort UDDI

Über Inhalte zu diskutieren ist sicher eine gute Sache, aber man sollte dabei vielleicht doch auf den Stil achten. In der Auseinandersetzung sollten wir uns weder wie unreife Jungs auf dem Schulhof benehmen noch wie jemand der nur gefrustet ist, weil er zuviel Zeit hat.

UDDI scheint sich, zumindest in Europa, nicht wirklich durchgesetzt zu haben. Das gleiche gilt für den von UN/CEFACT und OASIS verabschiedeten Standard ebXML der ein vergleichbares Konzept hat. Gleichwohl erscheint es mir sinnvoll sowohl UDDI hier als Beispiel stehen zu lassen und sogar zusätzlich auch auf ebXML hinzuweisen. Eintragungen in einem Lexikon sollten nicht davon abhängig sein, ob ein einzelner das für "Hirn...." hält oder nicht. Das Ziel muss eine umfassende Information sein. (nicht signierter Beitrag von ASchultzOlpe (Diskussion | Beiträge) 17:18, 10. September 2008 (CEST))

Webservice vs. Webdienst

Benutzer:Wondigoma hat im Artikel Representational State Transfer durchgängig Webservice durch Webdienst ersetzt. Ich habs wieder rückgängig gemacht. Halte "Webdienst" für eine zwanghafte Übersetzung eines bereits durch den englischsprachigen Begriff belegten Wortes. Google findet auch mehr als 10x so viele deutsche Seiten mit "Webservice" als mit "Webdienst". --Sebastian.Dietrich 23:09, 11. Okt. 2009 (CEST)

Einleitung anhand des w3c.org

Ich habe versucht anhand des w3c.org die Einleitung begonnen neu zu entwerfen. Ich behaupte, dass wir anhand des Aufbaus der w3c.org-Seite uns nicht nur inhaltlich sondern auch strukturell orientieren können. -- Tomreplay 11:01, 26. Dez. 2009 (CET)

Die Rolle von Webservices in E-Business

Die Web Services Technologie ermöglicht die Kommunikation zwischen den Anwendungen nicht nur in eigenem Unternehmen sondern über die Unternehmensgrenzen hinaus. Auf dieser Weise können die Informationen innerhalb der gesamten Wertschöpfungskette leichter ausgetauscht werden. „Währen viele E-Shops und E-Marketplaces heute noch Informationsinseln darstellen, über die ein Konsument nur schwer einen Überblick gewinne kann, werden Plattformen des Web 3.0 zu einem wesentlich höheren Grad miteinander vernetzt sein. Eine Basistechnologie stellen dabei sehr wahrscheinlich Web Services dar, wie sie auch im aktuellen Web schon zum interorganisationalen Datenaustausch verwendet werden. So bieten beispielsweise Amazon und Google Web Services- Schnittstellen, über die Kunden- du Partnerplattformen nahezu übergangslos auf die angebotenen Produkte und Dienste zugreifen können.“(E-business: Grundlagen elektronischer Geschäftsprozesse in der net Economy, Tobias Kollmann, S.70)--AgaWI07 14:38, 23. Mai 2010 (CEST)

Totgeburt UDDI

UDDI habe ich noch nirgens gesehen. Gibt es da irgendwas reales? Ist das nicht Hirnwichserei? Wie finde ich über UDDI Fußballergebenisse oder Börsenkurse?

• Da muss ich meinem Vorredner voll zustimmen! UDDI ist/war zwar eine nette Idee, eine nutzvolle reale Umsetzung solch eines Dienstes vermisse ich aber auch schon seit geraumer Zeit. Daher ist mein Fazit noch etwas schärfer: UDDI ist schon tot. --Ukrueger 10:51, 27. Apr. 2008 (CEST) PS: Jemand möge hier das Gegenteil beweisen, ich bin gespannt!
  • Ach ja, noch eine Ergänzung: Warum ist es denn tot? Meines Erachtens ganz klar aus Mangel an realen Web Services. Was soll denn auch eine UDDI-Katalog listen, wenn es nichts aufzulisten gibt. Da beißt sich die Katze in den Schwanz. --Ukrueger 10:56, 27. Apr. 2008 (CEST)
• In der SAP NetWeaver-Welt gibt es durchaus eine UDDI die als Verzeichnisdienst für Services gilt. (nicht signierter Beitrag von 217.111.58.2 (Diskussion | Beiträge) 14:22, 14. Apr. 2009 (CEST))
  • Ok,Ok! Das IBM intern etwas mit UDDI realisiert hat, wurde mir auch schon zugetragen. Verwundert ja nicht weiter. Jedoch kann hier von einem "WWW-Dienst" keine Rede sein, da der Nutzerkreis wohl minimal sein dürfte. Was das Web braucht, ist ein öffentlichen UDDI-Server, nur ohne Web Services wirds den wohl nicht geben. Firmeninterne Speziallösungen nützen der Web-Service-Idee nicht viel. --Ukrueger 19:56, 24. Mai 2009 (CEST)

dot.net

Am elegantesten ist das ganze webservices zeug vielleicht in dot.net gelöst. Andere Meinungen? (falsch signierter Beitrag von 212.186.69.80 (Diskussion) 02:33, 21. September 2007 (CEST))

Ja hier, ich hab mir das einmal angeschaut, von wegen Webservices und C#. So wie ich das verstanden habe, muss man dem Werkzeug erst die Webservicebeschreibung hinwerfen und der kompiliert dann einen sogenannten Proxy, den man verwendet um auf den Webservice zuzugreifen. Vielleicht hab ich da auch was falsches gelesen, aber diese von hinten durch die Brust ins Auge Methode hatte mich auf jeden Fall direkt abgeschreckt, Webservices in .NET zu benutzen. --62.157.47.144 20:40, 18. Mai 2009 (CEST)

Wieso ist das eine "von hinten durch die Brust ins Auge" Methode? Das was du beschreibst ist der Top-Down-Ansatz, und sehr nützlich wenn man einen Webservice verwenden will. Wenn man anderer Meinung ist, hat man Webservices noch nicht verstanden. Bottom-Up ist aber in .NET (bzw genauer, in Visual Studio) auch möglich, dann wird ein Web Service anhand von existierender Funktionalität erstellt. Soll ich zu dieser Thematik mal etwas schreiben? Ich im Zuge einer Seminararbeit die Web Service Technologieunterstützung in .NET und Java untersucht, evtll könnte ich hierbei etwas einbauen. (Ja ich weiß, dass die Antwort von der IP über 2 Jahre alt ist, finde es aber trotzdem noch aktuell) .. Morl99 18:13, 26. Jul. 2011 (CEST)

Überarbeitung

Dieser Artikel

• ist schlecht strukturiert
• muss sprachlich überarbeitet werden
• besteht aus diversen Spekulationen
• und sollte wissenschaftlich fundiert recherchiert werden (Literatur!)

--Benjamin Garn 10:26, 5. Feb. 2009 (CET)

Der Artikel sieht aus als wäre er einfach nur einem machinellen Übersetzer übersetzt worden. Der müsste wirklich dringen mal bearbeitet werden.--Isenherz (Diskussion) 14:09, 8. Nov. 2012 (CET)

Der Artikel beschreibt eigentlich nur einen Webservice basierend auf dem RPC-Architekturstil. Viele Fakten in Bezug auf einen REST WS sind einfach falsch, schon alleine die Einführung ist nicht in Ordnung:

• XML ist nur eine Möglichkeit als Nachrichtenformat, Alternative ist z.B. JSON
• Schnittstelle wird überhaupt nicht beschrieben, da die Methoden immer diesselben sind (GET, POST, ...)

--195.243.27.84 08:28, 9. Mai 2012 (CEST)

Habe hier mal einen Artikel gefunden: IT-Wissen - Webservice--Isenherz (Diskussion) 14:45, 8. Nov. 2012 (CET)

Historische Literatur

• Michael Kuschke, Ludger Wölfel: Web Services kompakt. Spektrum Akadademischer Verlag, Heidelberg, Berlin 2002, ISBN 3-8274-1375-3. 
• Gustavo Alonso, F. Casati, H. Kuno: Web Services. Springer, Berlin 2003, ISBN 3-540-44008-9 (englisch). 

Die hab ich mir erlaubt zu entfernen, findet man wohl nur noch im Antiquariat. --Hamburger (Disk) 18:02, 26. Feb. 2013 (CET)

Im Antiquariat? Naja - dazu passt auch das Foto bei http://www.gi.de/service/informatiklexikon/detailansicht/article/web-services.html von einem gewissen Heinrich Reinermann oder Herinrich Reinermann mit dem Holzregal und den Papierstapeln im Hintergrund. Scheint eher ins Museum zu gehören. --House1630 (Diskussion) 19:45, 2. Jun. 2013 (CEST)

Ich bin für einen kompletten Umbau der Seite

Reale Beispiele

• Google APIS
• Last FM
• openstreetmap
• facebook API
• eventuell xmpp Protocol

Hier werden Dienst öffentlich angeboten und sind über Systemgrenzen hinweg verwendbar. SOAP wird bei diesen Projekten nicht verwendet da es viel zu kompliziert ist. Der Envelop enthält keine Information und kann weggeschmissen werden. RSS und ATOM sind da schon eher im Spiel. (nicht signierter Beitrag von 212.186.69.80 (Diskussion) 02:33, 21. Sep. 2007‎)

Facebook verwendet REST - zumindest sagt Facebook, dass es sich um REST handelt. In Wirklichkeit wird auf einen URL-Encoded POST Request mit einem XML Document geantwortet. PUT, REMOVE, GET wird nicht verwendet. [3] WSDL und UDDI gibt es auch hier nicht.

Das im Moment umfangreichste öffentliche Webservice dürfte Facebook anbieten. Am häufigsten verwendet werden RSS und ATOM - wobei hier definiert werden muss, ob es sich dabei um Webservices handelt. (nicht signierter Beitrag von 212.186.64.225 (Diskussion) 16. Oktober 2008, 07:45 Uhr)

Fast

REST beschränkt NICHT das Format der Response. Es kann durchaus auch XML sein. JSON hat sich zwar eingebürget, ist aber deswegen kein Gesetz. Abgesehen davon ist REST ein Architekturstil. Was hier gemeint ist sind wohl eher RESTful services.

WSDL

Das ist ja ganz nett, wirklich durchgesetzt hat sich das aber auch nicht. Wenn man z.b. das xmpp Protocol per WSDL beschreiben möcht, wird man alt. Für "nicht xml" als Übertragungsformat kann man as WSDL ja einsetzen. Gibt es irgendwo eine Beschreibung von IMAP, POP,...? (nicht signierter Beitrag von 212.186.69.80 (Diskussion) 02:33, 21. Sep. 2007‎)

WSDL

insbesondere als Beschreibung einer SOAP-Schnittstelle ist im industriellen Umfeld sehr wohl verbreitet. Leider, muß man hinzufügen. (nicht signierter Beitrag von 89.246.213.194 (Diskussion) 20:48, 5. Mär. 2017 (CET))