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.

		if(argsMap['no-reports']){
			println testRunner.out.toString()
			println testRunner.err.toString()
		}

should do the trick, if you add them to $GRAILS_HOME/script/_GrailsTest.groovy in the “runTests” closure, right after ” def result = testRunner.runTests(testSuite)”

With those lines in place you can run your test like


grails -Dserver.port=9090 test-app -integration -no-reports MyController


Specifying the name of the class to test is important since only the output from the last test class will be printed. So we might as well only run one.