Hal and others, I agree with your analysis, however I think there is still some synergy. First, loading presentation directly from a Web service could be useful
although this could be exposed directly through a custom tag so is really not that helpful. Re-encoding a SOAP request to match the current Struts expectation would be redundant. Allowing SOAP based input to an action could reduce the amount of work necessary to test and build dual input systems. Traditionally, Struts has centered around HTML form based input, but I can see value in things like SOAP or SWT views. One problem is that Struts is still pretty rigid in this area and the view is generally defined through static JSP pages. I believe many are moving in different directions to a more dynamic form of form definition (I know I am and I am seeing questions that lead me to believe other are), which will make alternative views like SOAP and SWT more compelling. David Morris >>> [EMAIL PROTECTED] 01/24/03 12:54PM >>> Is the idea behind Axis for Struts to expose Action classes as Web Services? Ideally Action classes don't have any business logic in them. If that is the case, why not expose the business tier methods as web services directly? I think the EJB 2.1 specification's support for exposing Session bean methods as web services makes a good deal of sense. I am having a hard time seeing the benefits of Axis4Struts (aside from the benefits inherent in web services). It seems like a way to bail out people who mistakenly put valuable business logic in Action classes when the right thing to do would be to move that code out of the Action class. Axis and Struts, like ice cream and sex, are both good things, but I don't see much benefit to combining them. Hal -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
