Hjem   |   Kontakt   |   Sitemap
Hvem er vi Hvad kan vi Vores kunder Ledige stillinger Kontakt os Blog

Creating, consuming and testing SOAP webservices on Grails

Published Friday, February 12th, 2010 by AN

We are currently making a backend system, that has its services exposed as webservices. Since making web applications in Grails is pretty nice, we decided to try it for webservices.

Getting up and running was certainly a breeze.


grails create-app ...
grails install-plugin cxf

Grails is a plugin-based framework. And the cxf plugin seems to be the best plugin for webservices right now. Exposing the services was then as simple as adding a

static expose=['cxf']

to the the grails service classes. We wante to allow our service interfaces to operate with complex objects. And to do that best we decided to use the DTO plugin and specify our interfaces in terms of DTOs mostly generated from our domain objects. This was only a semi-good idea, I think, as the conversion to/from complex domain objects was not great out of the box (more on that in another post).

To consume webservices, the most straighforward way is to simply dump the minimal jar of the GroovyWS module in the lib folder of the project. Since we already had all the dependencies included by the cxf plugin the minimal jar is all that is needed.

To test the services, most of our test were simply the usual integration tests of the service classes. But for functional tests we used the functional-tests plugin and the GroovyWS client we already had installed.

class MyServiceFunctionalTests extends functionaltestplugin.FunctionalTestCase {

	def myServicePort

	protected void setUp() {
		super.setUp();

		myServicePort = new WSClient("http://localhost:9091/myservice/services/my?wsdl", this.class.classLoader)
		myServicePort.initialize()
	}

	public void testAMethod(){
		final List resultVals = myServicePort.aMethod();

		assertEquals(4, resultVals.size());
	}
}

It feels a bit wrong to work with old and crufty technology like SOAP with shiny new technology like Groovy on Grails. But with that in mind it works surprisingly well. Points where I found the greatest room for improvement were.

  • Grails has great support for Controllers as entrypoints, with interceptors for logging and authorization. For Services this seems harder if not impossible. I haven’t succeeded in using either groovys invokeMethod or the built-in spring support for aspect-oriented-programing.
  • As mentioned above, the DTO plugin could use a more flexible mapping tool than the one it has.
  • With code that has no immediate GUI feedback, testing is extremely important. But the Grails test run so slow that it is annoying.

Still, would I recommend Grails for a large SOAP project. Yes, I would.

Leave a Reply

Using TDC’s Columbine with modern browsers

Thursday, April 14th, 2011
On columbine.tdc.dk there is a gui with tools for resellers of TDC eBSA products. These ...

Groovy CPE

Thursday, February 3rd, 2011
I've been working quite a lot on a TR069 AutoConfigurationServer. As part of the prototyping ...
 
© 2011 Code3 ApS  |  Kigkurren 8G, 3.TH  |  2300 København S  |  +45 7020 3383  |  kontakt@code3.dk