Diskussion:Webservice/Archiv/1

message: 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)
thread_title:  "Vorteil" HTTP ... 

message: "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)
thread_title:  Nachteile 

message: 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)
thread_title:  Internet Protokoll Stack erklären 

message: 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)
thread_title:  Webservice vs. Distributed Object Technology 

message: 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     
: 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)
thread_title:  würde einen Nachteil aus dem Artikel eher als Vorteil sehen 

message: 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)
thread_title:  Für Laien unverständlich 

message: 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)
thread_title:  Webservice vs. Webdienst 

message: 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)
thread_title:  Einleitung anhand des w3c.org 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Die Rolle von Webservices in E-Business 

message: 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)
thread_title:  Totgeburt UDDI 

message: Am elegantesten ist das ganze webservices zeug vielleicht in dot.net gelöst. Andere Meinungen?      
: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)
replies: text:  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)
thread_title:  dot.net 

message: 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)
replies: text: 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)

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

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

message: === 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. 
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. 
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. 
==== 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,...? 
==== 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)
thread_title:  Ich bin für einen kompletten Umbau der Seite

message: 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,...? 
==== 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)
thread_title:  WSDL 

message: 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)
thread_title:  WSDL