> True. But somehow, to leverage what struts really is, you would need to
> communicate some kind of instructions from the server side controller.
The idea is to have the SOAP request contain essentially the same data as
would be in an HTTP post (or get). Then you invoke Struts Actions the same
was as you would from a browser.
> 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.
I don't agree that there need to be controller functions on the other side
of the web service. There aren't controller functions now in the browser.
Currently the browser sends in an HTML post and gets back HTML to display.
What I'm proposing is that (in a similar way) a web service client could
send XML to Axis (which would provide a 'pass thru' to Struts) and then it
would receive XML back from Axis (which is providing a 'pass thru' of the
XML that was returned to it from Struts).
The Axis processing is just a wrapper for the XML being passed between the
Web Service client and Struts.
---------------------------------------------------------------------------
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]>
