Da fallen mir mal spontan die WebServices von Java 6 ein.
http://java.sun.com/webservices/docs/2.0/tutorial/doc/
das ganze funktioniert aber iirc auch mit der standard java ee 6 installation, ohne ein package herunterzuladen...
lg,
michi
Ja, das hab ich eh gemeint, nur war ich zu faul zum Suchen. 
das ganze funktioniert aber iirc auch mit der standard java ee 6 installation, ohne ein package herunterzuladen...
Ich weiß nicht, ob da alles enthalten ist, aber zumindest einfache Webservices gehen seit Java 6 sogar mit der Standard Edition: http://java.sun.com/javase/6/docs/…ge-summary.html
Sind "Web Services (SOAP, WSDL und co)" eigentlich the next big thing im Internet oder wieder nur so ein IT-Hype alter technologien wie bei ajax?
Sind "Web Services (SOAP, WSDL und co)" eigentlich the next big thing im Internet
Tja wenn wir das wüßten
Sind "Web Services (SOAP, WSDL und co)" eigentlich the next big thing im Internet oder wieder nur so ein IT-Hype alter technologien wie bei ajax?
web services sind im enterprise-bereich zum teil schon jetzt sehr wichtig. dass der end user so viel davon mitbekommt wie von ajax, wage ich zu bezweifeln.
lg,
michi
Sind "Web Services (SOAP, WSDL und co)" eigentlich the next big thing im Internet oder wieder nur so ein IT-Hype alter technologien wie bei ajax?
Webservices sind wenn schon das "last big thing" und wurden in der ersten Haelfte des Jahrzehnts wesentlich mehr gehyped. Heute sind sie (meiner Erfahrung nach zumindest) eher ein häufiger und durchaus üblicher Bestandteil einer Software-Infrastruktur. Der WS-* Stack (SOAP/WSDL/UDDI usw.) setzt sich halt offenbar nicht flächendeckend als Standard Implementierung fuer Webservices durch - Das neue Buzzword derzeit ist die Ressource Orientierte Architektur (ROA) und RESTful Webservices.
Zuerst mal Danke für den sehr hilfreichen Tipp. Aber gleich eine neue Frage: die Applikation/das Webservice soll dann als "Virtuelle Maschine" umgesetzt werden. Ich kann mir leider in diesem Zusammenhang da jetzt nicht viel drunter vorstellen. Eure Ideen / Tipps ?
naja, deine soap-engine (axis,...) kann entweder als servlet in einem servlet-container wie tomcat (und damit in dessen vm) oder "standalone" (also in einer eigenen vm) ausgeführt werden.
lg,
michi
Schaust Du hier
Nein ich meinte eher WebService-Schwachstellen-Sammlung.
.... oder "standalone" (also in einer eigenen vm) ausgeführt werden.
Das ist wahrscheinlich das gesuchte, allerdings habe ich dazu keine konkrete Vorstellung wie man sowas umsetzen könnte. Gibts da "Bausätze" für VMs oder wie ?
lg,
Ewald.
Webservices sind wenn schon das "last big thing" und wurden in der ersten Haelfte des Jahrzehnts wesentlich mehr gehyped. Heute sind sie (meiner Erfahrung nach zumindest) eher ein häufiger und durchaus üblicher Bestandteil einer Software-Infrastruktur. Der WS-* Stack (SOAP/WSDL/UDDI usw.) setzt sich halt offenbar nicht flächendeckend als Standard Implementierung fuer Webservices durch - Das neue Buzzword derzeit ist die Ressource Orientierte Architektur (ROA) und RESTful Webservices.
hab darüber kurz in der wikipedia nachgeschlagen: SOAP war das alte buzzword, REST das neue? SOAP ist eine mächtige XML spezifikation für nachrichtenaustausch, und REST sagt nun: brauchen wir nicht, zurück zu POX?
hab ich das richtig vestanden?
Das ist wahrscheinlich das gesuchte, allerdings habe ich dazu keine konkrete Vorstellung wie man sowas umsetzen könnte. Gibts da "Bausätze" für VMs oder wie ?
wenn du uns ein wenig über deine vorkenntnisse erzählst, können wir dir leichter zweckdienliche hinweise geben. grundsätzlich wird jedesmal, wenn du
java meinprogrammausführst, eine vm gestartet, in der dein vorher zu bytecode (.class-file) kompiliertes java-programm läuft. dein java-programm kann natürlich auch ein web-service anbieten, damit läuft dieses web-service in "deiner" vm, "standalone" genannt.
http://www.google.at/search?hl=de&q…gle-Suche&meta=
im gegensatz dazu kannst du dir zb den tomcat herunterladen und starten, der als java-programm auch in einer vm läuft. wenn du dann dein service in den tomcat lädst, läuft es in "seiner" vm.
lg,
michi
Tja leider sind in puncto Web-Service fast keine Vorkenntnisse vorhanden, darum auch die vielen Fragen.
ich habe eher die grundlagen gemeint. wenn du dich mit java und objektorientierten konzepten halbwegs gut auskennst, brauchst du auch keine angst vor web services zu haben.
Also das ganze soll mehr oder weniger als "Proving ground" für Analyse-Tools dienen. Sozusagen "Wer findet, wie schnell welche Fehler". Die VM soll dazu dienen, eben nicht immer Software runterladen und konfigurieren zu müssen ( So wurde mir das zumindest mitgeteilt ). Da die Deadline heranrückt macht sich bei mir leichte Panik breit, weil ich weder eine anständige Liste von Schwachstellen beisammen hab noch wirklich etwas konkretes zu einer VM.
ich würde versuchen, noch genauer in erfahrung zu bringen, wie das mit der vm gemeint ist. ein herkömmliches java-programm läuft immer in einer vm, aber bei web services gibt es eben wie bereits besprochen 2 möglichkeiten, wo man diese bereitstellt. das mit dem herunterladen und konfigurieren verstehe ich in diesem zusammenhang nicht ganz.
arbeite vielleicht zu beginn ein paar tutorials durch und erstelle ein paar einfache webservices.
das thema ist äußerst komplex, aber mit ein bisschen geduld kommst du rasch zu ergebnissen.
lg,
michi
hab darüber kurz in der wikipedia nachgeschlagen: SOAP war das alte buzzword, REST das neue? SOAP ist eine mächtige XML spezifikation für nachrichtenaustausch, und REST sagt nun: brauchen wir nicht, zurück zu POX?
hab ich das richtig vestanden?
Ja, so in etwa. Es heisst genau genommen nicht "Brauchen wir nicht", sondern "Haben wir schon": Also SOAP ist z.b. ein Protokoll das den Nachrichtenaustausch zwischen Services spezifiziert. Gesendet wird das ganze dann oft ueber HTTP, und zwar in form von HTTP POST requests. HTTP ist aber selbst wieder ein ein Protokoll das den Nachrichtenaustausch zwischen Services spezifiziert. Der WS-* Stack ist eigentlich eine Architektur fuer Webservices, die ueber einer bereits bestehenden Architektur fuer Webservices verwendet wird.
Kurz gesagt: Das ist ein wenig so als wenn jemand das ISO/OSI- oder das IP/TCP/UDP Modell nimmt und dann auf dem Application Layer einen neuen Stack mit Transport/Netzwerk/Application Layer implementiert.
Eigentlich kann man SOAP/WSDL usw. gar nicht wirklich als "Web Service" bezeichnen, weil sie genau genommen nicht viel mit dem Web zu tun haben. Man koennte einen SOAP request auch ueber TCP Sockets verschicken.
Tatsächlich kann man fast jedes Problem, fuer das seit Jahren WS-* empfohlen wird, die Technologien benutzen, die man gemeinsam als "Das Web" bezeichnet. Und dank des World Wide Web wissen wir auch, das solche Web Services auch in extrem grossen verteilten Systemen gut skalieren.
Das heisst aber nicht unbedingt das SOAP jetzt bald eingeht oder das es fuer nichts zu gebrauchen waere. Die Technologien haben guten Toolsupport und es gibt auch Dinge die besser geloest sind als das derzeit mit dem Web der Fall ist. Z.B. Message-basierte security. Aber besonders wenn die Servicekomponenten von vielen verschiedenen Applikationen genutzt werden sollten, ist eine Resource Orientierte Architektur (ROA) extrem effizient. Und ROA ist mit REST sehr leicht zu implementieren.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!