By Frank Zammetti, extracted from StrutsSolutions page.
Please see [url]http://sourceforge.net/projects/strutsws/
for complete details, but in brief...
I decided that, in my case at least, the easiest path "into the application" that could be exposed as a service would actually be the Actions themselves. You may ask, assuming the application was architected properly and the Actions delegated out work to business classes (that IS the case), why not just expose the business classes? The answer is that I wanted to leverage all the form validation and security built in to the app (it was a custom security solution). Because of this, I needed Struts to "do it's thing" leading up to the business class execution.
My solution was to write a custom request processor that could recognize a Web Service request (SOAP over HTTP). It would be able to "unroll" the SOAP request, then let Struts process the request as it usually would, and then render the response. My solution does this.
I don't claim this is THE way to do Web Services. Far from it. What I WILL claim though is that if you have an existing application and you want to expose parts of it as Web Services, this solution can give you a very easy way to do it, with some limitations of course... First, it is Struts 1.1-only at the moment. Second, the incoming request must be "flat", that is, no nested elements are allowed (aside from children of the root element). Third, only strings are supported, so you lose the notion of true data typing that SOAP gives you.
All these details, and plenty more, as well as full source, are available at the linked address above. I welcome any suggestions anyone has. Although I haven't done much on this in a while (because it met my needs as-is), I would love to continue this work if enough people find it useful.