SOAP questions

[Alessandro Bottoni]

Alle 12:02, domenica 20 ottobre 2002, Robert Oschler ha scritto:
>
> Emmet,
>
> Let me clarify things a bit.  The app that the user uses to _design_ the
> web page is in Delphi.  But, the Delphi app generates HTML or XML/XSLT or
> Javascript (if I seem fuzzy hear is I'm not sure what will be best yet)
> pages that they will upload to their web server (Apache, etc.).  It is
> those generated pages that will contain the preformatted SOAP requests and
> I'm hoping there is a way they can also deal with the incoming SOAP
> response. That's the part that throws me.  My knowledge of web programming
> isn't nearly good enough yet to understand how a web page can "intercept"
> (?) the returned SOAP response before the browser gets hold of it and
> reformat it into renderable web page using XSLT or whatever.

MS IE and NN, like many other web browsers, do have some kind of scripting 
engine that can access the document (actually the DOM associated with the 
document) before it is displayed to the user. Unfortunately, no SOAP element 
(neither the outcoming call nor the incoming response) is accessible as part 
of the DOM managed by any existing web browser, as long as I know (maybe IE 6 
have this feature: I don not use it and I do not know...). Even the best 
performer (MS IE) is just able to convert (some) XML to HTML via XSLT on the 
client side. It cannot perform any SOAP-related processing (while it can 
perform javascript/DOM processing that interest the underlying HTML or XML 
document).

As a consequence, any SOAP processing must be performed by a server-side 
process. You can add any new plug-in to Apache, MS IIS and many other web 
servers while you cannot add any SOAP-related processing to a browser that 
does not have it built-in from the factory. I fear that even the web browsers 
that can be extended with plug-ins and add-ons, like MS IE and NN, could not 
give you enough access to the document-translation process to allow you to 
develop such a plug-in (that would require months of hard work, in any case).

>
> That is why I fear that I may end up having to have some kind of CGI module
> on the user's web server that handles the SOAP transactions instead and
> serves up the content to a web site visitor.  If I could find a way to pull
> this off completely on the client side, i.e. inside the web visitor's
> browser,  I'd be overjoyed.
>

Server-side processing is mandatory, as long as I know, but old-fashioned CGI 
is not the best way to perform it. You can rely on "embedded" engines that 
performs much better than external CGI scripts. Have a look at mod_perl and 
mod_python for Apache (and the related SOAP modules for these two languages), 
for example.

As an alternative, you could have a look at XML web servers like Cocoon and 
(with some limitations, in your case) Maki. Search "Cocoon "and "Maki" at 
sourceforce and/or freshmeat.

Good luck

---------------------
Alessandro Bottoni