Well to start off, I don't think I disagree with any of your points per se.
Perhaps it's a matter of scope. Kevin and I seem to agree we want a lightweight standard way of accessing Struts Applications via Axis....not replace Struts User Interfaces, not build a primary Axis back end using Struts (at least not yet). We agree Struts has lots of power though, as you say. If you try to do something with Axis4Struts or any tool for that matter, that it wasn't designed to do, then your bad, eh? If you take the Actor->Request->Process->Response->Actor flow and ignore the details, shouldn't we be able to change Actors and leave everything else the same, reuse everything else? I think so. I don't think Applications as Actors using Axis to access a Struts application need to have as robust a response as a User in a Browser and if the output generator doesn't have to populate lots of navigation widgets and menu widgets and so forth, as would be the case in a SOAP Response, then that reduces the load on the process and simplifies. If all the SOAP Response contains is the xml of the data...just the data requested not all the GUI elements too, then that has value...that I know I can use. 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 7:36 PM To: Struts Developers List Subject: RE: [AXIS4STRUTS] The old In and Out I don't mean to sound overly negative. I think the idea is interesting, and am looking forward to seeing creative solutions to some of these issues. :) I could be missing the point. Most of my comments are from an XML-RPC perspective, where types are more rigid. Document type services may be more flexible. On Fri, 2003-01-24 at 18:51, Mike Oliver wrote: > Ben, > > When I say, "An Actor posts a request to Struts, the data passed in the > request is used to determine what action to take, execute the action and > return a response to the requesting Actor". > > In the above statement am I talking about a User on a Browser or an > Application as the "Actor"? Yes, for a simple, predictable request - response cycle, that is clear. XML-RPC is a good match for that. But Struts provides so much more, multiple forwards, validation, redirect vs. forward etc ... The application logic could easily fall outside of the confines of an XML-RPC call, unless you exposed some of these features of struts back to the client - extending the controller back to the client. > > If as you say Axis doesn't provide a "View" then what does it provide? > It accepts requests for action and returns a response. The business > logic in a web service isn't in the Axis layer, nor should it be, no > more than should the business logic be in the JSPs for Struts > Applications. So I must disagree, all Axis does is provide a View, it > certainly isn't an application's Controller or Model, it is an Interface > and therefore a View. The view is generally referred to as the presentation and UI. Like JSPs, Velocity, etc... You can't click on a SOAP message, enter data into a SOAP message, or change the color or font. The SOAP message would be used by another view technology to create a UI. SOAP exposes an object's interface as XML, and provides a standard communication mechanism. Like HTTP. HTTP isn't a view either, but HTML is, as is JSP, etc.... > > I am afraid I don't understand why you think the use of Axis to provide > another view requires us to "dumb down the server app". Refer to my > paragraph #1 No, I only said if you do not beef up the client. Things like action errors, validation, forwards, etc ... can be handed by the client, but that would require a return type that would encapsulate these things, which could be a rather complex class to pass back from an RPC call. I am sure there will be some tradeoffs. > > 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 3:38 PM > To: Struts Developers List > Subject: RE: [AXIS4STRUTS] The old In and Out > > True. But somehow, to leverage what struts really is, you would need to > communicate some kind of instructions from the server side controller. > > I think the core of what I am saying is that Axis does *not* provide a > view. And therefore you would have controller functions on the other > side of the web service. So you dupliate what Struts does, you would > need to bridge communications between the two controllers. > > That is where I see the problem. Simple XML-RPC of "view/model" objects > with Struts doesn't leverage core Struts features to the client > controller. So you either dumb down the server app, or beef up the > client controller. > > On Fri, 2003-01-24 at 17:31, [EMAIL PROTECTED] wrote: > > > > > > > > > > > ** You may find more utility in creating set of client side proxys > for > > > Struts server side controller contructs. In other words, RPC the > > > selected controller components. ActionForms would be user defined, > but > > > the ActionForward, ActionErrors, etc ... could be proxy objects. > > > > I like this idea - but doesn't this assume that the client is Java? > > > > > > > > > ------------------------------------------------------------------------ > --- > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
