Ben, thanks see Kevins similar responses a little earlier today, and mine below.
Michael Oliver AppsAsPeers LLC 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone:(520)574-1150 Fax:(520)844-1036 -----Original Message----- From: Benjamin Tomasini [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 1:24 PM To: [EMAIL PROTECTED] Subject: RE: [AXIS4STRUTS] The old In and Out I think Axis4Struts is a cool idea, but... there are some viability issues to address, IMO. I just implemented a web services project using access and thought about the MVC model of Struts, and if that could be of benefit for Axis. Web Services have much promise, when applied to the right problem. [Mike Oliver>>] And Axis4Struts is meant only to make it easier and more standardized to access Struts applications in the case where you NEED both a Browser UI and an Axis SOAP/RPC Client to access the same business rules and logic. However, they suffer from the most chronic cause of poor performace: Serialization and Deserialization. Any application designer should try to avoid this. What makes Web Services so flexible also makes them bad design if used where not needed. Given, an ActionForm is already populated by the BeanUtils.populate, which "deserializes" and HTTP request. However, this is hardly the kind of CPU intensive operation that Axis performs when it deserialzies XML into a Java object. [Mike Oliver>>] Well we aren't suggesting that, we are talking about primitive types and arrays of strings spun from the xml in the soap payload into the name value pairs of a POST, hardly much of a load. Then there is the client side, too. So adding an XML-RPC layer into Struts would be a large performance hit. Arguably bad design .... unless ... you can identify a problem that it is solving. [Mike Oliver>>] If we tried to turn Struts into Axis I would agree but I think the consensus now is that the Axis4Struts is just another view into the MVC of a Struts application. Certainly if real time or high performance is needed and you are willing to have multiple paths for the data flows then by all means use a Web Services layer on top of your model, but with Axis4Struts you COULD have some of both and reduce the size and complexity of your solution. So that is the question. Aside from being cool to do, what is the purpose of Axis4Struts? What is the TestCase? the problem that it is solving? Struts has been successful because it was created to get things done. If Axis4Struts can find the same core value, it could be a success. [Mike Oliver>>] I think the test case comes from Application to Application interoperation, where there are multiple accessors and consumers of the application including both users and other applications. If you have just a subset of accessors from other applications and those have no performance criteria, then Axis4Struts might just make that incredibly easy to do. Ben I think Axis for Struts is a cool idea On Fri, 2003-01-24 at 14:54, Hal Deadman wrote: > 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 > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 24, 2003 1:54 PM > > To: Struts Developers List > > Cc: [EMAIL PROTECTED] > > Subject: Re: [AXIS4STRUTS] The old In and Out > > > > > > > > > > Mike - > > > > > If we start with the idea [Kevin's suggestion] that on the > > Axis side we > > > develop a Web Service that accepts SOAP Requests with an > > XML payload and > > > spins that payload into an HTTP POST/GET to a Struts > > Application as if > > > that POST or GET was coming from a Web Browser. Then we > > need not make > > > any changes to Struts to accept the request as Struts may > > not know or > > > need to know it was from Axis/SOAP (leave that to the application > > > developers). > > > > btw - I was thinking that this might just really be the > > easiest way to get > > something started. It may be better in the long run to try to > > 'embed' Axis > > in Struts directly and have Axis invoke the Struts MVC framwork > > programatically. But even so, I think there's value in > > allowing the Axis > > app and the Struts app to be on different servers - so both > > approaches may > > be good to implement. > > > > I think that the HTTP Post interface may be the best place to > > start because > > it looks easier and faster to get going on. > > > > > That presumption then begs some other questions: > > > > > What advantages should this Axis4Struts bring to the table? > > > > Primarily: > > > > - Allowing developers already familiar with Struts to build > > Web Services > > apps without learning a great deal about Axis. > > - Allow developers to build a basic Axis/Struts app and > > extend the web > > service offerings easily by just adding more 'Action's. I > > think this may > > make it easier to maintain/extend Web Service apps than currently. > > - Allowing developers with existing Struts apps to extend > > them to handle > > non-browser clients (.NET, Swing, JMS, etc.) > > > > > What should we do over and above the minimum accepting of > > SOAP Requests > > > and spinning into an HTTP Browser emulated POST to Struts > > to add value? > > > > To begin with I'm thinking not much. After we get something > > built and get > > users on it, I believe this will be easier to answer. > > > > > Do we even bother with GET? > > > > Can't see any value for initial release. > > > > > Since any programmer can use commons-httpclient to form his own java > > > emulation of a browser POST to struts, what advantage can > > we bring with > > > Axis4Struts? > > > > Any programmer with a .NET client (or other non-java client) can't. > > > > Other tools (such as Cold Fusion) now provide built-in > > support for making > > calls to Axis services. This could be leveraged. > > > > Also, this may not be the only web service that the client > > app calls. If > > you have an app that is accessing a variety of web services > > and you want to > > extend it to leverage some existing functionality in a Struts app, why > > force the developer to write http-client posts? > > > > I think there is value in this project. > > > > > What would the WSDL for an Axis4Struts Web Service look like? What > > > messages, what types, etc. > > > > I've put a some thought to this. Here's what I've been thinking: > > > > The HTTP Post to the Struts app requires a few things: > > > > - A server/host and port > > - A servlet context/module > > - The Action ( ".do") URI > > - Name/Value pairs for data (essentially an array of pairs) > > > > The WSDL should allow for these (and only these) I believe to > > begin with. > > This means the Axis app will be "very thin" to begin with. > > All items are of > > type String. > > > > I believe that it would be appropriate to let the first two (server > > host/port and servlet context/module) to be specified at > > deploy time (in > > the Axis wsdd file) to allow for default values. But the > > client code should > > be able to specify them in the SOAP request to over ride the > > defaults and > > allow the Web Service to expose resources from more than one > > Struts app > > through the same Web Service. > > > > > What should we do within the Struts framework to make it easier for > > > developers to have a Forward that returned an XML Payload > > suitable for > > > the Axis4Struts Response? > > > > This I've not got a clear vision of. I'm thinking that > > initially we create > > some sort of utility we can pass a form bean to and have it > > inspect the > > bean to find the properties it exposes. Then it could extract > > the values > > and generate an XML response with them. This is a basic start > > that can be > > extended. > > > > Handling Dynabeans and other beans/objects can be added. > > > > Maybe a new form class that extends ActionForm would be useful. > > > > > Should we use primitive types (Strings, Integers, etc.) only in the > > > Axis4Struts.WSDL or should we include alternatives with Java complex > > > types? (DynaBeans, NVPair[], etc.) > > > > Initially, I'm thinking we simply allow Axis to accept only > > the data types > > that exist in the HTTP POST (i.e., ALL STRING). > > > > .NET support is important so we should ensure we don't use > > types that it > > won't work with. More complex types may be optional, but shouldn't be > > required. > > > > > What and how should be do the discovery? If a single > > interface with a > > > multi-purpose payload for the Form Data is used, how will developers > > > accessing the web service determine what the content of the payload > > > should be? > > > > Interesting question. Not really sure. I think there is value > > in being able > > to inspect to find 1) which services may exist, and/or 2) what > > versions/parameters/etc (essentially metadata) apply for that service. > > > > > What role should other common Struts compatible components > > like Scaffold > > > and JSTL and other Axis compatible components like WSIF play in > > > Axis4Struts? > > > > Haven't thought that far yet! > > > > -------------------------------------------------------------- > > ------------- > > 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]> > -- 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]>
