I just added a new chapter discussing Groovy and SOAP-based web services to the Manning Early Access Program (MEAP) version of Making Java Groovy. I prepared a decent introduction for the MEAP subscribers, which I thought I would share here:
“Though they’ve fallen out of favor recently, SOAP-based web services provide a perfect opportunity for Java/Groovy integration. The technology is mature, with known use cases and a tool set that has been added to Java’s standard edition. In this chapter, I go over the basics of web services with a focus on the wsimport and wsgen tools that are built into JDK 1.6.
Using Groovy to build a client-side web service application is almost trivial. The wsimport tool generates Java stubs, which Groovy can instantiate and use like any other Java class. I illustrate a case where a publicly-available web service returns XML, rather than objects, which is much easier to process with Groovy than with Java.
To create a web service, I find it much easier to use Groovy if the service implementation bean supports a service endpoint interface, even though that is not strictly required by the specification. The standard interface/implementation split makes mixing Java and Groovy wherever desired quite easy, however. There is a slight complication when dealing with domain classes, but as long as they are annotated to prefer field access rather than properties, everything works just fine.
In general, with SOAP-based web services no XML is exposed on either the client side or the server side. The exception is when using handlers to pre- or post-process the messages. As usual, using Groovy for XML processing is much easier than Java. My proposed solution is to use a Java class to implement the appropriate Handler interface, but to delegate to a Groovy class for the actual XML processing and manipulation.
Finally, I present Gradle tasks to perform the wsimport and wsgen tasks, based on the corresponding Ant tasks.
Though much of the industry is switching from SOAP to REST, SOAP-based web services are going to be a fact of life at many companies for the foreseeable future. This chapter shows how you can use Groovy to make developing them and working with them easier.
Note that this is listed as Chapter 7 in the outline. The code examples do use some technologies covered in the intervening chapters (Spock tests, Gradle builds, and so on), but you don’t need the details to be able to read this chapter.”
These days whenever I discuss web services, I feel obligated to show the Gartner Hype Cycle. In case you haven’t seen it, here’s an image from Wikipedia:
I like the model, though I always suspect that the actual data Gartner periodically adds to the figure is pure hand waving speculation. In my experience, right now REST is rapidly approaching that Peak of Inflated Expectations. I know several people who have been successful with it, but the tools and APIs are still quite immature. I’m working on my REST chapter in Making Java Groovy at the moment, and while I can get everything to work, it’s taking more effort than I expected. Don’t get me wrong — I see the value in REST, but right now getting it to work with Java is a lot more effort than using SOAP, believe it or not.
(Obligatory moderately humorous anecdote: back when I was working at a training company about six or seven years ago, we were partners with the company that produced Crystal Reports for business intelligence reporting. They were eventually bought by a company called Business Objects (who in turn was bought by SAP, but that’s a different story). Anyway, Business Objects preferred the abbreviation BOBJ over that of B.O., for obvious reasons. Of course, we used to joke about teaching a BO class followed by a SOAP class….)
The attitude toward REST may be an overreaction, but that’s nothing compared to the loathing for SOAP-based web services you find in much of the community these days. You would think that SOAP would be safely on the Plateau of Productivity by now, but if you go to any conferences (or talk to any REST advocates) the contempt you see for SOAP is such that it must be deep in the Trough of Disillusionment.
I don’t necessarily agree, but fortunately I don’t have to resolve that argument. As I see it, one of the major tasks Java developers face these days is working with SOAP-based web services, probably as part of a (potentially misguided, but what can you do?) Service Oriented Architecture, and those services aren’t going away any time soon. Those same developers are also going to be working with REST, if not already then soon, and are starting to get used to terms like safe, idempotent, and HATEOAS.
My task is to show Java developers how Groovy can help in both situations. Chapter 7 discusses JAX-WS (the SOAP tool set for Java) and how it works with Groovy. Chapter 8 talks about REST and JAX-RS, with the same goal in mind. Hopefully I’ll be able to provide enough information that you’ll be able to make up your own mind as to whether Groovy is helpful in either case.
—-
On an unrelated note, next weekend (3/5 and 3/6) I’ll be at the No Fluff Just Stuff event in Minneapolis. I’m giving three presentations: one on improving your Java with Groovy, one on testing with Spock, and one on using Gradle for builds. Oh, and leave it to the Gradle people to announce another milestone release four days before I’m supposed to give a presentation on it. 🙂 Sigh. That’s life in the Groovy ecosystem for you. In any case, I’m really looking forward to the event. If you plan to attend, please drop by and say hi, even if you’re just on your way to go see Neal Ford, Tim Berglund, the inimitable Dave Klein, or any of the other great speakers at the conference. I might even have a discount code to give out…