First page Back Continue Last page Overview Text

Notes:


Hier sehen Sie nochmal alle Annotationen zur Entwicklung von SOAP-Webservices zusammengefasst. Die Bedeutung von @WebService und @WebMethod haben wir schon geklärt, wobei noch gesagt werden muss, dass die Webservice-Klasse öffentlich (public) sein muss und nicht abstrakt (abstract) sein darf. Zusätzlich muss sie einen Konstruktor besitzen, der sich ohne Parameter aufrufen lässt, damit der Webcontainer überhaupt ein Objekt der Klasse erzeugen kann.

Für die Webservice-Methoden (vor denen @WebMethod steht) gilt, dass sie ebenfalls öffentlich sein müssen und nicht statisch (static) sein dürfen.

Aber was hat es jetzt mit den anderen beiden Annotationen auf sich? Streng genommen brauchen Sie sie gar nicht, der Webservice würde trotzdem funktionieren. Aber er wäre auch nicht sehr schön. Die XML-Elemente, die man für die Methodenparameter an den Server schicken muss, hätten nur sehr allgemeine Bezeichnungen wie <arg0>, <arg1> oder <arg23>. Der Grund hierfür ist, dass beim Kompilieren einer Klasse die Namen der Methodenparameter verloren gehen und der Webcontainer daher nicht weiß, wie er die Parameter sonst nennen soll. Deshalb schreibt man vor jeden Methodenparameter @WebParam(name="..."), um seinem XML-Element wieder einen sprechenden Namen zu geben.

Ähnlich verhält es sich mit @WebResult(name="..."), das man vor eine Methode schreiben kann. Auch diese Annotation dient dazu, das XML (hier das Antwort-XML) etwas schöner zu gestalten. Gibt eine Methode beispielsweise nur einen int zurück, mag es okay sein, wenn dieser als <result>42</result> zurückgeliefert wird. Gibt man aber zum Beispiel eine Liste von Artikeln zurück, wäre es viel schöner, wenn jeder von ihnen als <artikel>...</artikel> an den Client gesendet werden würde. Und genau dafür ist @WebResult da. Man legt damit fest, wie das XML-Element mit den Antwortdaten heißen soll.