Would you use Groovy as an Axis2 service class?

[Hamlet D'Arcy]

Hi everyone,

We're trying to decide whether or not to write Axis2 web service
classes in Groovy. The alternative is Java. I wrote my thoughts up on
my blog. http://hamletdarcy.blogspot.com/2008/05/why-groovy-as-service-layer.html

I'm preparing for the "Architects Meeting" later this week where we
decide whether or not to use Groovy.

What would you say to persuade someone that a Plain Old XML web
service interacting with Java facade objects on the backend should be
written in Groovy?

[Robert Fischer]

> What would you say to persuade someone that a Plain Old XML web
> service interacting with Java facade objects on the backend should be
> written in Groovy?

You're doing XML web services? XmlBuilder + XmlSlurper == sex. From someone who knows: I'm doing
this right now. I'd be more than happy to come do a demonstration, if you think they're getting
tired of hearing your voice.

If you're dealing with massaging "transfer objects" and the like, Groovy is also a nice way to
quickly crank out code. As an example, if you have a lot of "this property goes here" plumbing,
Groovy's metaprogramming is rockstar:
[
name:'fullName',
id:'sourceId'
].each { k, v -> to[v] = from[k] }

~~ Robert.

[Marc Stock]

I'm a little slow and I'm only familiar with Axis 1.x, so bear with me
for a moment. Axis should be doing this kind of heavy lifting for
you. If you use wsdl2java, it will take your WSDL and generate the
appropriate java classes and then at runtime it will map the incoming
soap request into the appropriate java objects, and likewise going
back the other direction. So I don't see where you need an extra
layer to do this if you're already using Axis.

-- Marc

On May 7, 11:20 am, "Hamlet D'Arcy" <Hamlet...@gmail.com> wrote:
> Hi everyone,
>
> We're trying to decide whether or not to write Axis2 web service
> classes in Groovy. The alternative is Java. I wrote my thoughts up on

> my blog.http://hamletdarcy.blogspot.com/2008/05/why-groovy-as-service-layer.html

[Robert Fischer]

Yeah, I should note that I've never worked with Axis. So I was just responding keyed off the words
"web service".

~~ Robert.

[Peter Pascale]

I would characterize this as a type of xml binding. This approach requires a specification for the xml - in this case - provided by the wsdl. I had a question on Hamlet's blog post as to what xml binding alternatives exist, and would he have the specification to make them feasible?

So with wsdl2java - is that available for REST services? On the SOAP side I'm under the impression you can only use that when you are defining rpc-style web services. This option may be unavailable - I think Hamlet is preferring REST over SOAP.

Peter

[Peter Pascale]

Hamlet-

But even if WSDL2JAVA isn't available for binding - how are you proposing the service layer interface be defined? Is the expected XML specified in any form that supports other types of xml binding?

Peter

[Marc Stock]

I haven't used this feature but it appears that Axis 2 allows you to
provide a REST style interface and Axis 2 will convert the request
into a SOAP one. There are some restrictions though. See here for
more: http://ws.apache.org/axis2/1_1/rest-ws.html

On May 8, 9:52 am, "Peter Pascale" <peter.pasc...@gmail.com> wrote:
> I would characterize this as a type of xml binding. This approach requires a
> specification for the xml - in this case - provided by the wsdl. I had a
> question on Hamlet's blog post as to what xml binding alternatives exist,
> and would he have the specification to make them feasible?
>
> So with wsdl2java - is that available for REST services? On the SOAP side
> I'm under the impression you can only use that when you are defining
> rpc-style web services. This option may be unavailable - I think Hamlet is
> preferring REST over SOAP.
>
> Peter
>

[Justin Grammens]

I did a few WebServices for a client some months back and weighed the options of Axis, Axis2 along with REST based approaches (RESTtlet). I definitely prefer the simplicity of REST, but you'll need to decide what is required by the environment you deploy in. In my case there were a number of SOAP authentication headers that were required by the organization, SAML tokens, and in addition the client was in .NET and generation of C# code based on a WSDL is drop dead easy. I found that the REST interface that Axis2 gives you works for simple 'get' and 'post', but didn't seem like there was much there for the other methods. It definitely seemed to be, "hey, everyone else is doing REST, why not make our SOAP based URL's, RESTlike." RESTlet might be something to consider.

[Hamlet D'Arcy]

Thanks for all the replies on this... here is the aftermath:

1. Groovy as a service layer
Groovy has exceeded my expectations as an Axis2 service class. For
those not familiar, your service class is basically a Pojo that gets
invoked by Axis2 to respond to requests. There seem to be two general
options for service classes a) take an XML document as a parameter and
produce an XML document as a result type ("document style"), and b)
take Java reference types as method parameters and return a String
("RPC style"). You can configure it to do anything in between also,
but it seems these are the common scenarios.

Anyway, for the document style service, Groovy clearly is better than
Java for parsing and generating tree structures. It is just a lot less
code when you use Groovy. Plus, it is much easier to unit test. For
the RPC style interface, Groovy helped a lot with moving the Java
reference types (think Integer IDs) into entity objects thru the DAO
layer. It's just less code.

2. Axis2 Tools
wsdl2Java is a great tool to point at a WSDL and generate reams of
framework code and a single "MyService.java" pojo that will be your
service class. At this point, I would take MyService.java and rename
it MyService.groovy and away you go! Nothing about using Groovy has
made any of the Axis2 tools break. Axis2 is instantiating your service
class using reflection, so as long as you produce a class file with
the correct public method, then you're good to go. Scala services
should work just fine too, as well as JRuby (I'm guessing). HOWEVER!
The default "MessageHandlers" in Axis2 invoke your service method
using reflection. This means your sweet metaprogramming "invokeMethod"
tricks will not work. That took me a while to figure out.

3. REST vs. SOAP
Axis2 support for REST is not so good. Under the covers, the REST
endpoint is being converted into a SOAP envelope for you. So your
"MessageReceiver" always sees a SOAP message, even when you're using
REST. Also, as Justin stated, only POST and GET work. After looking
breifly at Grails url mapping and REST support, I would encourage
someone to use Grails instead of Axis2. We don't always have the
authority to make these decisions though.

4. Mixing Groovy and Java classes
I never understood the Groovy Joint Compiler until now... My project
has Groovy classes that reference Java classes and Java classes that
reference Groovy classes. The joint compiler runs through the Groovy
code and generates Java stubs for all your Groovy classes. Then it
compiles the Java classes against the stubs so that Java has something
to link to. Lastly, it compiles the Groovy code into real classes and
replaces the stubs. Nifty.
I felt that Groovy's optional static type system really helped Groovy
classes into a Java codebase. My goal was to write Groovy based
service classes and leave the rest in Java. As my Groovy classes grew,
and code started being refactored into reused components, I started
tightening down the contract of the shared code to make it more
usable. On some classes I even eventually stripped out the Groovy
specific libraries and converted them into pure Java classes. It was
great that I could have the thought, "Oh, I really should have written
this in Java" and then actually convert the thing to Java within a few
minutes. Mixing the two was really easy, and context switching between
the two was trivial. Although, by and large, my more common thought
was, "I wish I could just do this in Groovy" rather than vice versa.
But as I said, we don't always have the authority to make these
decisions.

Thanks for the help everyone!

On May 8, 2:54 pm, "Justin Grammens" <jus...@localtone.com> wrote:
> I did a few WebServices for a client some months back and weighed the
> options of Axis, Axis2 along with REST based approaches (RESTtlet). I
> definitely prefer the simplicity of REST, but you'll need to decide what is
> required by the environment you deploy in. In my case there were a number of
> SOAP authentication headers that were required by the organization, SAML
> tokens, and in addition the client was in .NET and generation of C# code
> based on a WSDL is drop dead easy. I found that the REST interface that
> Axis2 gives you works for simple 'get' and 'post', but didn't seem like
> there was much there for the other methods. It definitely seemed to be,
> "hey, everyone else is doing REST, why not make our SOAP based URL's,
> RESTlike." RESTlet might be something to consider.
>