In theory, you should be able to combine functionality based on Axis
(or the standard JAX-RPC APIs, for that matter) in the same webapp as
a Struts based application that interacts with human users, and
therefore achieve some of the same kinds of reuse that you are after.
That's exactly right, but that requires you to know before-hand that you want to do such a thing. Or, at least design things to that you could do such a thing later. Because the situation where Web Services was tacked on after the fact arose for me and was the catalyst for this concept in the first place, I know the ideal isn't always the case.
That's not to say anything about your proposed solution (I haven't had a chance to look at it yet), which might offer approaches that are easier to use or require less extra work to accomplish the reuse.
That is indeed the main benefit of it... quick and easy. I like that in a solution :)
* Java-based code that programmatically constructs the XML response to a particular query. Because it is running in the same webapp as the human user interaction stuff, it is an illustration of the same sorts of reuse goals that Frank is describing.
That's actually what my first iteration of this did. In fact, the version of this that I have running in one production app does just that. There's a startResponse() and endResponse() methods in a WSHandler class that renders the common parts of the response, then there is a class for each service you want to expose that renders the service-specific portion of the response. Works well, but I realized it wasn't optimal, so...
* JSP-based approach that uses a JSP page as a template for the XML response, JSTL tags to do the iteration through the result data to be rendered, and the Shale ViewController APIs to make it dead easy to reuse existing code (in what Frank describes as a "properly constructed" app :-) to serve both human interactions and back channel REST-style interactions.
...That is in fact what the current version on SF does. What I have is a "simple" response JSP that will basically iterate over all the members of an ActionForm and render it as XML (I didn't realize there were classes to do this for me at the time). You can however provide your own template JSP and configure the service to use it (I introduced a new optional config file for your application that defines Web Service mappings).
If you want to try this stuff out, download the 20050123 (or later) nightly builds of the framework (struts-shale) and the use cases example app (struts-shale-usecases) from:
I'm actually going to wait until there is more of a definitive answer as to what the new direction is. I don't want to put effort in and then find out things aren't going that way.
There is no one right answer to implementing this sort of thing. It's
important that we explore different alternatives, to see which things
make the most overall sense for particular styles of applications. Therefore, I'm quite happy to see experiments like this going on.
That's my feeling to. At first I had a vision of my project becoming THE way to do Web Services, but for various reasons I don't see that as realistic any more, or even desirable. But, I do think it's another tool in the toolbox, something that might be good in some situations, and options are never a bad thing I figure :)
Craig
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
