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"? 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. 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 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]>
