Indeed the SOAP code relies on an older generation of the apache library.
Going forward, we are looking at writing a client-side implementation of the
SOAP and XMLRPC
protocols in javascript, and thus become independent of the server and the
apache
library.
In Flash 5, the performance of actionscript was not really good enough, but
the
javascript engine in Flash, and DHTML, has gotten much better, as well as
the
performance of XML parsing. The only thing that a server is really required
for now
would be to proxy the XML data fetches in the case that the data is coming
from a third party server that does not have a crossdomain.xml
permissions file. It is also required to proxy XML data requests for DHTML
runtime, since
the security model of XMLHTTPRequest does not permit any third-party data
access by default.
On Wed, Apr 16, 2008 at 4:03 PM, Geoff Crawford <[EMAIL PROTECTED]> wrote:
> At 03:44 PM 4/16/2008, Jesse Norell wrote:
>
> > Hello,
> >
> > I'm new to Openlaszlo, trying to use it as a SOAP client and running
> > into a problem (limitation/something) maybe someone can help identify.
> > I've made a simple WSDL (which works in a wsdl explorer, for what that's
> > worth) and have more or less copied the Amazon RPC example from the
> > developer's guide to try to send a soap message (see attached).
> >
> > The Amazon example works; if I Debug.inspect(amazon.proto) in that
> > example, if I'm reading the output correctly (and I may not be), the
> > prototype is an LzNamespace with the namespace set by the
> > targetNamespace of their wsdl, and there are a lot of array members you
> > can do "stuff" with.
> >
> > In my example WidgetFactory, if I Debug.inspect(WidgetFactory.proto) I
> > have an LzNamespace with an incorrect namespace set (and it actually
> > changed if I put different content in the wsdl <schema>)
> >
>
> You might want to go back in the list archives -
> from my own experiences the existing laszlo implementation
> of SOAP is based on some pretty old Apache code to
> create the message prototypes from the WSDL. It's got
> known issues with it - but at some point in the future
> it is going to be worked on per the Laszlo developers.
> (they just did some work on the XML RPC so it wouldn't
> surprise me if some of the others are next)
>
> My suggestion that worked reasonably well for me was
> to simply use an everyday dataset and just XPATH out
> the SOAP envelope/SOAP body and you get right to the
> XML returned.
>
> All that leaves you to do is build the XML request
> and then use setQueryParam of "lzpostbody" and let
> it go.
>
> Here's a simple example:
>
> var sr = "<soap:Envelope> "
> "<soap:Header/>" +
> "<soap:Body>" + mySoapBody
> "</soap:Body></soap:Envelope>";
>
> datasetname.setHeader("SOAPAction","myAction");
> datasetname.setHeader("Content-Type","text/xml");
> datasetname.setQueryParam("lzpostbody",sr);
> datasetname.setQueryType("POST");
> datasetname.doRequest();
>
>
> In addition, I think in a lot of SOAP camps these days you
> start to look at the time and effort it takes to take WSDL
> and produce a prototype message and that accounts for much
> of the supposed slowness in SOAP. You really don't want to
> be doing that all the time on every call - it really should
> be done once at application start. Something where the WSDL
> is analyzed once, to produce the call prototypes and then
> do some kind of XSLT would be far more useful IMO.
> Many implementations even have to read the WSDL on every
> call - tripple ouch!!
>
>
> Geoff Crawford
> [EMAIL PROTECTED]
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
