So, what happens is this: you enter some text in the text area, you click Submit, the text is sent to the web service, which interprets it, and then you use the web service's methods to work with the returned text. For example, the web service has a method called "getSuggestionCount()", which returns the number of suggestions for a wrongly spelled word.
To me, Wicket fits perfectly in the Java EE 5 paradigm. Why? Because Java EE 5 is all about simplification. Take a look at JAX-WS for example (which is nothing more than version 2.0 of JAX-RPC, its predecessor): no entries are needed in deployment descriptors and, instead, you use annotations within the Java code. Also, the implementation that NetBeans generates used to consist of three files—an endpoint interface, an implementation class, and a weird little configuration file. Now, all you get is one file to work with. (Of course, there's a lot of stuff under the surface, but that's exactly where it belongs, not right in your face to confuse and frustrate you.) Similarly, Wicket removes XML files from your development world. Completely. No struts-conig.xml, for example.
Further, Wicket totally separates Java from HTML. When I first started thinking about this blog entry, I was thinking of calling it: "Forget servlets! Wicket rocks!" (That's basically the subtitle of this blog entry, albeit slightly hidden.) Take, for example, a look at the servlet in the tutorial (here). The heart of any servlet is the processRequest method, which spews out an HTML file. When you look at the Wicket version of the SpellChecker client, the first thing you notice is that HTML is found in the HTML files and Java is found in the Java files. Logical, yet oddly unique in the programming world. The only link between the HTML and the Java files is a placeholder tag in the HTML, which has a matching name in the Java file.
As a result, all the formatting is done in the HTML file (which makes perfect sense). This, for example, is the "Report Card" part of the screenshot above (notice that the only parts that are unfamiliar are the <wicket:id> bits, which, despite that, is perfectly well-formed HTML code within the <span> tag):
<span wicket:id = "comments" id="comments">
<p><font color="red"><b>Report Card:</b></font>
Entered text: <font color="red"><span wicket:id = "text">Entered text goes here.</span></font><br>
Number of wrong words: <font color="red"><span wicket:id="no_of_wrong_words">Number of wrong words goes here.</span></font>
(first is "<font color="red"><span wicket:id="one_wrong_word" class="even">One wrong word goes here.</span></font>")<br>
Number of suggested replacements: <font color="red"><span wicket:id="number_of_suggestions">Number of suggestions.</span></font>
(first is "<font color="red"><span wicket:id="one_suggestion">One suggestion goes here.</span></font>")<br>
Finally, would any of this be possible without Glassfish? No. And that's the point. Is there any application server out there, other than Glassfish, that supports JAX-WS? Anyone? Feel free to contradict me. So, by integrating web services into (for example) Wicket applications, you leverage a whole layer of functionality that you yourself don't have to provide. Of course, you better make sure that the functionality you use is reliable and doesn't drop out of the sky in the middle of the night (such as some of the web services I've used in tutorials in the past, aaaargh). But, personally, I would highly recommend CDYNE's web services. They're great and super fast.
So, basically, apart from using EJBs in Wicket applications (see comment at end of yesterday's blog entry for details), you can now also use the highly simplified web service architecture provided by the JAX-WS specification. Which in turn means that you're using... Glassfish.