[eoxserver-dev] SOAP-Proxy <-> EOxServer interaction.

[Martin Paces]

Sorry I was distracted from the IRC I did not explained the idea of the 
WSGI middleware.

Also I have to confes I have no personal experience with it but I only 
read the concept from different WSGI docs.


The point is,  as described at 
[http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface]

...

The WSGI has two sides: the "server" or "gateway" side, and the 
"application" or "framework" side. The server side calls the application 
side, providing environment information plus a callback function (for 
the application to use to convey headers to the server side), and 
receiving web content in return.

So-called WSGI middleware implements both sides of the API so that it 
can intermediate between a WSGI server and a WSGI application: the 
middleware acts as an application from some WSGI server's point of view 
and as a server from some WSGI application's point of view. A 
"middleware" component can perform such functions as:

     * Routing a request to different application objects based on the 
target URL, after changing the environment variables accordingly.
     * Allowing multiple applications or frameworks to run side-by-side 
in the same process
     * Load balancing and remote processing, by forwarding requests and 
responses over a network
     * Perform content postprocessing, such as applying XSLT stylesheets

...


I.e. you can put a WSGI middleware between mod_wsgi and the actual 
EOXServer WSGI entry. This middleware can mangle both the WGSI request 
comming from Apache and that to pass it to WOXServ. and the response 
returned from the EOXServer.

You don't need to take care about the processes, sockets, whatever 
low-level stuff.

Now the issue is how to create a (purly Pythonic) WSGI interface for 
your C code. Well, you can wrap your C code as a python module.


Martin





On 06/22/2011 03:12 PM, Novacek, Milan wrote:
>
>     [This thread was: RFC 10 "SOAP Proxy" - starting implementation.]
>
> Hi Dev'ers:
>
>    Here is the issue I'm working on:
>
> Need to find a good way to pass data to EOxServer from the SOAP-Proxy.
>
> The soap_proxy is implemented in C as a mod_axis2 plugin/service in apache2-httpd.
> So when s SOAP request comes in from the web, apache routes it to the active mod_axis2 - so we are now running as a tread in apache2-httpd (i think? is this correct, anyone?)
>
> So, now we have stripped the SOAP envelope, and now we have a nice buffer containing an xml-request, suitable for invoking a mapserver in POST mode.  Or I guess an EOxServer, perhaps?
>
> In fact that is question numero uno: given my xml-string, how do I invoke an EOxServer instance?  is something like a mapserver?  Do we have my documentation on how this is done?
>
> What I did for the prototype was to simply do a fork/exec(mapserver) while setting up pipes to send the data to/from mapserver's stdin/out.
>
> This is not what we want to do to invoke EOxServer.   One alternative is to simply open a url to the apache2-httpd...
> Is there anything more clever we can do?  It also depends on the answer to my question numero uno above.
>
>
>
> Milan Novacek
>
>
> -----Original Message-----
> From: dev-bounces at eoxserver.org on behalf of Stephan Meißl
> Sent: Thu 6/9/2011 5:32 PM
> To: EOxServer Development Discussions
> Subject: Re: [eoxserver-dev] RFC 10 "SOAP Proxy" - starting implementation.
>
> Milan,
>
> adding the functionality to be able to POST the WCS requests to a
> configurable URL is a valuable functionality anyway as it might be used
> with any WCS server.
>
> However, we might want find a more clever solution for the integration
> of the SOAP Proxy and EOxServer to promote performance optimization. I'm
> thinking of a solution where the requests and results are directly
> passed in the memory. Stephan K. once mentioned a maybe possible
> solution but I can't recall it right now.
>
> Anyway, I think I'm trying to say I agree to proceed with the URL
> solution but eventually we might find a better solution for our special
> case.
>
> cu
> Stephan
>
>
> On Mon, 2011-06-06 at 12:36 +0200, Novacek, Milan wrote:
>> Hi All,
>>    I'm planning to put the soap_proxy into the eoxserver/soap_proxy svn this week, as the implementation of RFC 10.
>> Initially I'll just transfer the existing code from the o3s project, but at some point we should discuss further integration with eoxserver.
>> In particular, during the code sprint we raised the question of communication with the 'back-end'.
>> For now, the 'back-end' is mapserver, and it is invoked by means of fork/exec, with data being passed through pipes.
>> The question is should we invoke eoxserver instead - and instead of fork/exec should we just POST the output to a URL?  In practice the URL would in most cases be configured to be a localhost:eoxeserver instance.
>>
>> Milan Novacek
>>
>
>
>
>