If I the project had a motto it would be..."In the end, the Web Service is just another View in the Model-View-Controller architecture. The value of building this is that this "View" allows Struts Model and Controller components to be accessed by a much broader range of clients than currently."
Michael Oliver AppsAsPeers LLC 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone:(520)574-1150 Fax:(520)844-1036 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 2:37 PM To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: RE: [AXIS4STRUTS] The old In and Out *FridayModeOn* > Axis and Struts, like ice cream and sex, are both good things, but I don't > see much benefit to combining them. I think it depends on the flavor of the Ice Cream... ;-) *FridayModeOff* > Is the idea behind Axis for Struts to expose Action classes as Web Services? Yes. > 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. The problem with this is that there is no defined interface for the business-tier methods - they could not easily be exposed in a standard, reuseable way. Plus, the value of the MVC framework would be gone if all you had was the "M". While the Action classes have no logic, they do drive decision making and alter the resulting output. Action classes make decisions about which data sources to access, whether or not to update systems, etc. They are too important to leave behind. > 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. Clearly, not every situation would benefit from combining these two apps. But here are use cases I can envision: - Exposing functionality in an existing Struts application to non-browser-based clients such as .NET, Cold Fusion Server, Flash, Swing, etc. (Yes some of these clients could build their own HTTP requests and POST to Struts on their own. But I believe there is value in allowing these apps to use prebuilt Web Services client code.) - Allowing Struts Action/Model classes to be leveraged by *both* Browser-based clients (classic Struts) and by Web Services based clients. - Allowing a Web Services-based client application (.NET, Cold Fusion Server, Swing, etc) that is accessing a variety of Web Services already to access Struts applications as just another web service. Many Web Services client apps access more than one Web Service for data - this simplifies the process of adding the Struts cunctionality to the application. - Allowing developers who already know Struts to easily build Web Services applications. Otherwise they need to learn Axis as well. I believe the learning curve would go much faster if a Struts developer could build Web Services by "bolting on" axis4struts (as opposed to building Axis apps from the ground up). In the end, the Web Service is just another View in the Model-View-Controller architecture. The value of building this is that this "View" allows Struts Model and Controller components to be accessed by a much broader range of clients than currently. -- Kevin ------------------------------------------------------------------------ --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. ------------------------------------------------------------------------ --- -- 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]>
