SOAP questions

[Alessandro Bottoni]

Alle 21:42, venerdì 18 ottobre 2002, Robert Oschler ha scritto:
> This is a bit of a complex question so let me lay out my application for
> you.  I'm working on a GUI IDE tool that allows a user to build web pages
> that have integrated access to a foreign (external) web server that is also
> a provider of SOAP services.  The GUI IDE tool, when the user is done
> working with it, generates HTML/XML pages that can be viewed in an Internet
> browser and are basically the user's "web site".  My original intent was
> that the user could then upload the pages to whatever web server that hosts
> their web site, whether it is Apache, Zope, IIS, or something else.
>
> Now from within the GUI IDE, which is a Delphi application, I can do
> runtime access of the SOAP service _provider_ with some calls to a Python
> script that performs the SOAP XML code generation and submission, and then
> parses the resulting XML document returned from the service provider.  The
> sticking point occurs here: as far as I know the only way I can parse the
> XML document returned from the SOAP call is via some process or CGI script
> that is run by the web server, right?

Yes and no. 
No: you can parse XML with any XML parser you like, as long as your document 
is a valid XML document. There are XML parsers for almost every possible 
platform so you can perform the parsing both server-side (your current 
situation) and client-side (inside your GUI IDE, without your current Python 
connection script). Of course you have to find the XML parser, emebed it 
inside your application (your GUI IDE or your new web server) and write all 
the required code.
Yes: in your current situation the only available XML parser is on the web 
server so you would be forced to use it (via CGI or whatever other mechanism 
you like) for parsing your document. You are currently forced to access you 
web server this way both from your GUI IDE and from any other web server that 
the user would like to use, given that neither one of them have a XML parser 
inside.

NOTE: all of the XML parsing required by XML-RPC and SOAP is usually 
performed (in a transparent way) by the tools provided by the platform (Java 
or Python). You will have to parse XML by yourself only if you are actually 
using XML as a meta-language to be translated (via XSLT) to (X)HTML or any 
other form of structured text, as it seems to be your case.

> A more concrete example.  The user decides to put a search of the SOAP
> provider's product inventory on their web page, and the results are shown
> in a list box on the web page.  I let them build and test this
> functionality from within the GUI IDE, by using the python interface
> script.  Now when I generate the the web page to actual HTML/XML code, I
> know I can include the needed SOAP call packaged up as an embedded XML
> fragment in the web page. The problem is, and I'd love to be wrong here as
> far as my current understanding of SOAP goes, the web server running the
> users web page will have no idea what to do with the XML document returned
> by the SOAP call, correct?

Just your web server can know what to do with this stuff and it can know it 
just as long as you write the required code. Any other web server will not 
know what to do with it.

> My desire is to make the generated pages to be as portable as possible
> across multiple web servers.  But I'm guessing that at least at first, I'll
> have target the biggest web server package, currently Apache, and develop
> some sort of module for it that handles the returned SOAP calls and then
> probably does some HTML template code processing where I fill in variables
> with the SOAP results.  I'm already worried about what kind of collisions
> might occur between my module and any other SOAP modules the host site
> manager might have installed.  Also, I guess I'll have to then create other
> modules for each platform I wish to support (IIS, etc.), correct?

Right. You would have to develop the parsing code by yourself (relying on an 
existing XML parser).
Wrong. No, you do not have to worry about any possible conflict with any 
other SOASP module, as long you do not messy up with someone's else code or 
variables.
Right. You would have to port your parsing application to all the desired 
platforms. Given the multiplatform nature of SOAP and Python, this task could 
be easier than expected but it is usually a long, boring and painful job.

> If anyone has any great ideas on how to do this simpler please let me know.
> Also, anywhere my knowledge is incorrect, again, please let me know.
> Lastly, if XML-RPC would be any easier or better, please tell me what the
> differences might be.  I'm assuming it would have the same incoming XML
> SOAP doc processing problems that SOAP does.
>
> thx

XML-RPC and SOAP are equivalent from this point of view: in both cases, you 
would have to develop the parsing application using an existing XMP parser.
SOAP can be better than XML-RPC in some cases because of its more mature and 
sophisticated features but I doubt you would notice the difference here.

An idea? Take this one: focus on your main web server (Apache or whatever 
else you are using) and develop your application keeping stick to the bare 
minimum complexity required for a correct working. Use standard, 
multi-platform technologies ONLY, like SOAP, XML and Python. If and when you 
will be required to develop the binding for other web servers, ask a lot of 
money to do it and start working hard.
 
---------------------
Alessandro Bottoni