On Sat, 22 Jan 2005 22:48:13 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> More importantly though, where I think it differs in a material way, is > the fact that my solution gives you the ability to expose services but > still use all the resources of your container, your application and > Struts. For instance, if you have to create a new webapp with Axis and > then put your classes to expose into it, you also will need to set up > whatever resources those classes may need, your JNDI database entries > and such. They already exist for your Struts app, so why go through > that extra effort? 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 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. Both Axis and JAX-RPC, of course, are focused on SOAP style web services. For some applications (such as a JSF component that wants to pull updated data in the background, the way that Google Suggest works), SOAP can be overkill. I just checked in to the Shale framework (my proposal for what Struts 2.x should be based on) some preliminary code for supporting the server side of that kind of application. In addition, the "use cases" application that illustrates the use of Shale shows two kinda interesting approaches to implementing the back ends of these kinds of requests: * 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. * 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. 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: http://svn.apache.org/builds/struts/nightly/struts-shale/ 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. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
