Thoughts on updates to the current server side model

[Paul Fremantle <pz...@hursley.ibm.com>]

Folks,

I've been thinking about the server side model in Axis C/C++ and I've 
put together some proposals. I've attached the HTML file here, but I've 
also put it at:

http://fremantle.org/paul/Web_Services_Server_options_for_Axis_C.html

As I couldn't figure out how to simply package the diagram otherwise!

A few questions from this....

1) Have I correctly characterised the current situation
2) Has anyone used the server side support in "real life" and how stable 
is it?
3) Thoughts about the proposals?

Thanks,

Paul

Re: Thoughts on updates to the current server side model

[Samisa Abeysinghe <sa...@gmail.com>]

Hi Paul,
    This looks really interesting.

    I too think that legacy EXE integration is challenging with the
existing model of the server side.

    As per my understanding, the challenge that we have for approaches
1 to 3 is the serialization/deserialization. At the moment,
serialization/deserialization processes are tightly controlled by the
server module. If we can have an abstraction for this, integration
could become easier.

    It is the fourth model that looks most sensible thing to do.
However, the concern would be how much design changes need to be done
to achieve this.

Thanks,
Samisa...

On Fri, 04 Feb 2005 13:55:21 +0000, Paul Fremantle <pz...@hursley.ibm.com> wrote:
> Folks,
> 
> I've been thinking about the server side model in Axis C/C++ and I've
> put together some proposals. I've attached the HTML file here, but I've
> also put it at:
> 
> http://fremantle.org/paul/Web_Services_Server_options_for_Axis_C.html
> 
> As I couldn't figure out how to simply package the diagram otherwise!
> 
> A few questions from this....
> 
> 1) Have I correctly characterised the current situation
> 2) Has anyone used the server side support in "real life" and how stable
> is it?
> 3) Thoughts about the proposals?
> 
> Thanks,
> 
> Paul
> 
> 
>  
>  
> 
> Web Services Server options for Axis C/C++ 
> 
> The current server architecture for Axis C/C++ has two distinct issues around stability and useability. 
> 
>   
> 
> The first issue is that service implementations are run in the process space of the HTTP server. This means that any bugs or memory leaks in the service implementation or the server dll code will affect all service requesters and the HTTP server as well. 
> 
>   
> 
> The second issue is that a number of customers are looking to expose existing .EXE files as Web Services. For example, old existing code sometimes makes use of globals and is not easily converted to work as a DLL. 
> 
>   
> 
> This paper is an exploration of some approaches that might help with this. 
> 
>   
> 
> Existing model (overview) 
> 
> What happens with a request currently is that it runs on a new thread provided by Apache HTTP server (or SimpleAxisServer). 
> 
>   
> 
> The thread is routed to the mod_axis.dll, which in turn invokes the server.dll. The server.dll identifies which service is required and invokes a generated wrapper. 
> 
>   
> 
> The Wrapper has a single method that gets invoked: 
> 
> int XXServiceXXWrapper::invoke(void *pMsg) 
> 
>   
> 
> This method has a switch statement that identifies which operation, and then this calls a generated method in the wrapper for that operation, e.g. 
> 
> int XXServiceXXWrapper::XXoperationXX(void* pMsg) 
> 
>   
> 
> This method has the generated deserialisation logic to invoke the Skeleton. The skeleton is a simple shell class which is generated with the right signature, and the user fills in with the appropriate method bodies. 
>  
> 
> While the current model is effective, it is proposed that some minor modifications might allow more flexibility in supporting server code. 
> 
>   
> 
> Some ideas in this area are: 
> exposing the generated serialiser/deserialiser code so that it could be used by server side programmers 
> exposing a reusable socket reader/writer 
> generating main programs to support CGI-BIN as an alternative invocation model 
> supporting a simple standard server side WSDL to invoke existing EXE files using command line parameters and stdin/stdout 
> 
>   
> 
> The first approach is to make it simpler for customers to embed the Axis server code into their own EXE file. 
> 
>   
> 
> The idea is to let them handle the transport but to be able to use Axis C/C++ to perform the SOAP serialisation/deserialisation. 
> 
>   
> 
> To do this we could apply the "inversion of control" approach. Instead of our server.dll calling the wrapper we could allow the application to call the wrapper. 
> 
>   
> 
> So now suppose the application has a SOAP message. The app needs to know which service it is destined for (e.g. which URL did it come in on). Then the app calls: 
> 
>   
> 
> void *XXServiceXXWrapper::invoke(void *pMsg, XXServiceXXSkeleton skel) 
> 
>   
> 
> Now it is the application that creates the environment and the thread on which the code is called. The skel will still be called, but now on a thread initiated by the users app, not our middleware. This call will return another SOAP message. 
> 
>   
> 
> To make this work we need to expose to the app writers some way of creating the SOAP message (void *pMsg) from the stream they have. Also they might be getting the message from another model – e.g. a POP mailbox, a MQ or reliable messaging queue, a file, etc 
> 
>   
> 
> The second model might take this further…. we could extend this to actually read the data of a socket and respond. In this model, the application would open the server port (we could provide sample code), and then when a message comes in, the app could set up a thread and environment and call a generated class passing the socket handle. This would help customers embed this inside their EXEs and build standalone EXEs that could support SOAP. 
> 
>   
> 
> The third model would be more like we have today, except that we would wrap the generated code as an EXE file instead of calling in-process. CGI-BIN specifies a calling approach for HTTP requests to invoke EXE files. Although this is "old" technology and has in many ways been replaced by mod_xxxx approaches, the benefit when running C or C++ code is high, because it spawns a new process for each request, giving process boundary protection to code. 
> 
>   
> 
> In this model, the URL would identify a service, and for each service, in addition to the wrapper class we would generate a main class that used the CGI calling structure (http://hoohoo.ncsa.uiuc.edu/cgi/interface.html) which involves passing the headers and HTTP transport information as environment variables and the body of the message as STDIN, with the response available on STDOUT. 
> 
>   
> 
> The fourth model would be to support initiation of existing EXE files using a standard WSDL interface. The interface, in pseudocode, would be: 
> 
>   
> 
> execute { 
> 
>             String[] parameters; 
> 
>             Array of { 
> 
>                         String name; 
> 
>                         String value; 
> 
>             } environment; 
> 
>             base64 stdin; // attachment 
> 
> } 
> 
> returns 
> 
> { 
> 
>             integer return_code; 
> 
>             base64 stdout; // attachment 
> 
>             base64 stderr; // attachment 
> 
> } 
> 
>   
> 
> This could be used to initiate "batch jobs" remotely. In the future WS-Addressing would support asynchnronous sending of the response for long running jobs. 
> 
>   
> 
> The fourth model is the most different. The other three models can simply be seen as a refactoring of the existing code into a slightly more useful model. In fact, the refactoring in the first model could also include refactoring the stubs to separate the serialiser/deserialiser code into something that could be shared across the stub and wrapper. 
> 
>   
> 
> End 
>