Hi Tomas,
Thank you for you reply.
The part I am not understanding is how handle_request gets called and under
what circumstances.
You wrote:
>>After doing that for every object, the server-script might call
handle_request():
>>soap.server.handle_request(cgilua.POST[1],
cgilua.servervariable("QUERY_STRING"))
Is handle_request registered by CGILua such that the above only gets invoked
when a SOAP request comes in from a client? How did you accomplish that?
Note that the handle_request code does not try to sort out whether a POST
was associated with a SOAP request, so presumably some higher-level
dispatching takes place to only allow SOAP requests to be presented
to handle_request.
Also, would the catalog-building routines (register_service_info and export)
be called once at initialization, or would the catalog be re-built on each
request?
BTW, our interesting application is digital IP cameras, which have a Web
server running in the on board CPU. We would like to use Xavante. SOAP is a
very important future direction for standards-based IP cameras.
On Mon, Dec 21, 2009 at 8:30 PM, Tomas Guisasola Gorham <
[email protected]> wrote:
> Hi Walter
>
> I am sorry for the so late response, but I was very busy
> the last few weeks.
>
>
> I've been looking at server.lua, and of course there are no instances of
>> SOAP server routines, the user has to provide them. But could you outline
>> the steps for adding a service routine?
>>
> I think that code doesn't make much sense to non-CGILua
> developers... I will try to explain how it is supposed to work.
> The script server.lua is a module to help implement a
> script which should work as a server able to dispatch requests to
> a set of objects. Thus, the objects need to be registered in the
> server's catalog via soap.server.export function, which receives
> a description of the service, such as:
>
> -- Untested code !!!
> local matricula2URL_descr = {
> name = "matricula2URL",
> method = matricula2URL,
> message = { name = "matricula2URL",
> { name = "matricula", occurrence = 1, type = "string", },
> },
> response = { name = "matricula2URLResponse",
> { name = "URL", occurrence = 1, type = "string", },
> },
> }
> soap.server.export(matricula2URL_descr)
>
> After doing that for every object, the server-script might
> call handle_request():
>
> soap.server.handle_request(cgilua.POST[1],
> cgilua.servervariable("QUERY_STRING"))
>
> This function will try to dispatch the request to the
> corresponding object.
>
>
> Also, I'm puzzled by your earlier comment that,
>>
>> There is no automatically-generated WSDL.
>>>>
>>>
>> Almost half of the source code seems to be about that, such as the
>> routine:
>>
> Well, the size of the code that builds SOAP means nothing :-(
>
> function generate_wsdl().
>>
> I use this code, but I will not recommend it to anyone,
> since there are no tests. Anyway, if you are interested, I can
> try to explain how it works.
> The function soap.server.register_service_info just registers
> information needed to respond to WSDL and discovery requests (the
> dispatch might be done by handle_request also). A simple example:
>
> -- Untested code !!!
> local server_name = cgilua.servervariable("SERVER_NAME")
> local path = string.format("http://%s/my/URL/";, server_name)
> local script = path.."soap-server-script.lua" -- the name of this script!
>
> local disco = string.format([=[<?xml version="1.0" encoding="iso-8859-1" ?>
> <discovery
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://schemas.xmlsoap.org/disco/";>
> <contractRef
> ref="%s?wsdl"
> docRef="%s"
> xmlns="http://schemas.xmlsoap.org/disco/scl/"; />
> <soap
> address="%s"
> xmlns:q1="Matricula2URLSoapBind"
> binding="q1:Matricula2URLSoapBind"
> xmlns="http://schemas.xmlsoap.org/disco/soap/"; />
> </discovery>]=], script, script, script)
>
> server.register_service_info("matricula2URL", path, script, nil, disco)
>
> The above code should be put before the handle_request call.
> Note that we developed this functions to our needs, but we
> hadn't time to test it properly. I can't even say whether it violates the
> SOAP specification or not, so please, use it at your own risk.
> Anyway, it could be useful.
> Feel free to ask me anything about that.
>
> Regards,
> Tomás
> _______________________________________________
> Kepler-Project mailing list
> [email protected]
> http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
> http://www.keplerproject.org/
>
_______________________________________________
Kepler-Project mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
