Hal, I started this thread thinking not in terms of a holistic optimal architecture but a simple lightweight generic Axis access method. I completely concur with you and others that if requirements drive a ground up architectural integration of a combination of User Access and Application access that you might want to have a lower level of integration or complete architectural design. In many cases if you want all or most of an application's business logic exposed via Web Services then you should build it that way first and put Struts as your Web User Interface out in front, but then some would argue Cocoon or Velocity alone would handle that...;-)
So what if you have 95% of the access to application logic in an existing Struts application accessed by users with web browsers and 5% interaction with other applications for specific requests as in lookup or update of specific data elements??? Posting of a form should not matter where the name value pairs came from, the Forward should know what format to generate. In some cases a configuration would map that, in others you may need to modify your action to detect the request source and set the Forward accordingly. Then a lightweight, generic, Axis4Struts.WSDL that did little but pass through the name value pairs of a request form data and executed the same Action as a user form input executes, except instead of a web page response we return an XML response through a Generic AxisResponse Forward (or subclassed custom Forward), well then that has value, is good OO and is the aim of Axis4Struts. That won't require significant changes either to struts or the Action classes. No modifications except to configure one Forward for Users response in HTML and another Forward for Application Response in XML. If nothing else it will show Struts/Axis developers one way to do it and allow them to decide if they need more performance or special processing, etc. and need to accomplish it another way. Another benefit is that we will discuss the trade offs of one method vs. another and influence the next generation of Struts. My hope is that the Struts MVC can evolve to be less tightly coupled to HTTP and allow for easy access regardless of transport protocol. Michael Oliver AppsAsPeers LLC 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone:(520)574-1150 Fax:(520)844-1036 -----Original Message----- From: Hal Deadman [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 9:22 AM To: 'Struts Developers List' Subject: RE: [AXIS4STRUTS] The old In and Out I am used to dealing with EJBs so I am probably not as sympathetic as I should have been to people that have written web applications without EJBs. In a sense, the business logic code in those non-EJB web apps is hidden away from other applications that might want to use it, without copying it into the other application's code base. The only way to access that code from another application is to interface with the web application via HTTP. I can see the appeal of exposing the web application's code as web services using Axis. It seems like exposing Action classes directly as web services will be more trouble than it's worth. It would seem better to move the code in the Action class into another class (not tied to Struts/Web) which will be used by the Action class and exposed directly as a web service running inside the same web application. > -----Original Message----- > From: David Morris [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 24, 2003 4:59 PM > To: [EMAIL PROTECTED] > Subject: RE: [AXIS4STRUTS] The old In and Out > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
