SOAP-Client in C++???
-
stimmt
SOAP hat so gesehen riesenvorteile bei der integration
das es allerdings nicht die eierlegende wollmilchsau ist haben viele noch nicht begriffen.
das ist jetzt ein schlagwort und web services sind "IN"
habe selber schon welche entwickeltdas ganze wird sich schon normalisieren und es wird sicher eine sehr nuetzliche und weitverbreitete technologie bleiben
gomberl
-
Ich glaube niemand wird bestreiten dass Standard sehr wichtig sind. Insofern ist SOAP natürlich toll.
Allerdings stört mich (und viele Andere auch) der Aufbau von SOAP - ich habe zwar noch nicht sehr viel damit gemacht, aber besondere Vorteile (ausser dass es ein akzeptierter Standard ist) habe ich noch nicht gefunden.
-
ich finde den aufbau sehr gut
etwas aufgeblaeht aber sonst recht gutund das system mit UDDI und WSDL find ich spitze
dynamische proxy generierungzB
-
Mhm, vielleicht waren meine Projekte auch nur zu klein um SOAP sinnvoll zu verwenden...
Ich werds mir bei zeiten mal wieder näher ansehen.
thx
-
Ich habe noch keinen Vergleichstest zwischen Corba und SOAP gemacht, vielleicht wäre es auch unsinnig. Nur frage ich mich, warum man auf das XML setzt, da es nun wirklich viel Overhead hat. Warum muß die Struktur im klartext "lesbar" sein? OK, zum debugen mag sowas hilfreich sein. Aber da hört der Vorteil auch schon in meinen Augen auf. Irgendwie wird das Arbeiten nicht schneller, obwohl die Hardware-Resourcen leistungsmäßig förmlich alles bisherige wieder sprengen. Dann kommt jemand mit was neuem an, was alles wieder relativiert.
Es gibt noch sehr viele Dinge hier (ich rede von meinem Arbeitsumfeld) die für mich unlogisch und unkonsequent sind. Der fachliche Abteilungsleiter z.B. hört von allen ITlern, wie toll OO doch ist. Wie toll WebServices sind. Und wie toll Java ist usw. Aber die neuen Projekte werden trotzdem noch auf relationalen DBMs aufgesetzt. Warum ist man hier nicht konsequent und setzt OODBMs ein?
Für mich ist SOAP ein Rückschritt. Oder weiß jemand ob OO damit abgebildet werden kann?
-
OO oder OR- DBMS
weil OODBMS faktisch fuer die meisten anwendungen irrelevant sind.
ORDBMS haben vorteile doch fuer die meisten problemfälle bringen sie nicht vielda haette ich ne gute graphik - ich scann sie mal beizeiten ein
es muss nicht xml sein - aber die lesbarkeit ist auch vorteilhaft
und per caching und cached proxy generierung muss man das wsdl file auch nur einmal lesen um den proxy zu generierendie method calls sind allerdings echt viel zu langsam
ich wuerde mir eine standardisierte version wuenschen die das ganze komprimiertgomberl
-
@artchi:
http://www.c-plusplus.net/forum/viewtopic.php?t=22790&postdays=0&postorder=asc&highlight=xml&start=45
http://www.c-plusplus.net/forum/viewtopic.php?t=22220&highlight=xml<klugscheiss>
Prof84 schrieb:
Die Begeisterungsfähigkeit von XML ist Propotional zur Qualifikation und Erfahrung der Mitarbeiter. - QED!
</klugscheiss>
Die Abbildung der OO in SOAP funktioniert normalweise ganz leicht über XML Schema (noch ein Standard den Du Dir ankucken musst :D)
Also ich habe mich bis heute nicht an den Glaubenskriegen beteidigt -
welche Programmiersprache, welches OS, welches DBMS, welche IDE usw.!
Ich verkaufe keine Programmiersprache oder Pradigmen!
Wenn ein Manager etwas haben will, weil er gehört hat wie tool etwas ist, ohne sich über den strategischen Nutzen seines eigenen Geschäftsprozess im klaren zu sein, dann ist das ein fachliches personelles Problem und kein Technisches.@gomberl:
Wieso? Du kannst auch RDBMS <-> OODBMS über XML transformieren. Das klappt sogar primar, wenn man noch dazwischen eine NXD (native XML database), wie z.B. Tamino einsetzt. Perfekt für den Einsatz von Cacheknoten.Ich rechne im Webservice Bereich sogar mit einen Cutting Edge Hype, sobald GXA Lösungen einen bestimmten Marktanteil erreicht haben...
So, jetzt kümmer ich mich erstmal um die T-Wich*****...
-
(ich finde die idee hinter xml, dass man ein einheitsformat hat, mit dem sich jeder auskennt und was man überall mit wenig aufwand bearbeiten kann nicht schlecht. nur verfehlt xml dies total, da das design von xml absoluter humbug ist und sich deswegen genau für die oben genannten ziele als ungeeignet erweist IMHO)
Prof84 schrieb:
seines eigenen Geschäftsprozess im klaren zu sein, dann ist das ein fachliches personelles Problem und kein Technisches.
da spricht der freelancer. im endeffekt muss man natürlich so marketing gerecht denken, wenn man geld kassieren will.
-
kingruedi schrieb:
([...] nur verfehlt xml dies total, da das design von xml absoluter humbug ist und sich deswegen genau für die oben genannten ziele als ungeeignet erweist IMHO)
Well, I disagree! ...
kingruedi schrieb:
[...] da spricht der freelancer. im endeffekt muss man natürlich so marketing gerecht denken, wenn man geld kassieren will.
READ NOW THE TOP SECRET CARRIER HINT:
Als Angestellter auch!!
-
@prof84: mussm mir das einmal ansehen - bevor ich dazu was sagen kann
klingt aber nicht schlechtkingruedi: kannst du mal ein paar fakten nennen warum es dieses ziel nicht erfuellt
gomberl
-
@Prof84
jo als angestellter natürlich auch. aber ich denke mal, dass gerade freelancer immer einem gewissen buzzword-druck unterliegen.@gomberl
1. das format ist absolut parser unfreundlich
2. das format ist viel zu redundant
3. das format ist sehr komplex und es ist nicht leicht für jemand fachfremdes ein XML Dokument zu bearbeiten
4. der XML Standard deckt zu wenige Dinge ab, so dass es hunderte Standards gibt, die sich teilweise überschneidenYAML löst IMHO viele der Probleme von XML, ist aber leider nicht so populär