Re: [DotGNU]Webservice Execution Engine

[David Sugar]

Does this imply that ultimately ilrun or something similar needs to be
embedded in an existing web server to do a complete web service invokation
efficiently?  And in that ilrun is essentially just a wrapper for
libILEngine and related things anyway, it would seem quite plausable to
have the core pnet vm engine able to create a new instance of a vm without
any need to fork, just by having native method binding back to it's own
library...

What made me think about this was the recent exercise I was going through
with embedding pnet into Bayonne....

On Tue, 3 Dec 2002, Chris Smith wrote:

> The point has come where Architecture need to be able to invoke an arbitrary 
> method within an arbitrary .dll.  in essence, invoke a requested webservice.
> 
> I've been chatting with Gopal on irc today about this, so he's already pretty 
> familiar with the scenario - but laying it out here "is a good thing" for 
> comment. :o)
> 
> 
> View from the web developer
> ---------------------------
> I'd like (for the first release of the DGEE core anyway) for the webservices 
> to looklike those in .net (merely because there are many examples of this for 
> reference).  Ie classes derived from the base class WebService, and methods 
> associated with WebMethodAttribute.
> 
> using System;
> using System.Web.Services;
> 
> public class TestWS : WebService
> {
>     [WebMethod(Description="Says Hello, even if you're not the world.",
>        EnableSession=true)]
>     public void SayHello()
>     {
>       Console.WriteLine( "Hello\n" );
>     }
> }
> 
> WebService base class probably won't do very much... just a stub.
> 
> 
> Executing the Webservice - Internals
> ------------------------------------
> Webservices are executed within a VM process.
> This VM process will initially be derived from ilrun or just exec it.
> It receives request messages from the rest of the architecture each time a 
> webservice is required to be executed.  This is an _internal_ architecture 
> message, not to be confused the original webservice request!
> The request message will contain:
> 1. The name of the assembly
> 2. The name of the method
> 3. An array of parameters to pass to the method
> 4. An array of parameter names (required if the parameter array order cannot 
> be assumed to match the expected order of the method)
> 
> Once these four data sets have been identified and extracted from the message 
> they need to be passed to the 'ExecutionEngine'.
> 
> The ExecutionEngine is (presumably) a compiled C# stub which will load the 
> requested assembly, locate and invoke the required method with the provided 
> parameters and receive the results;
> 
> Somewhere between the receiving of the request message by the VM process and 
> the running of the ExecutionEngine we've crossed a boundary from code written 
> in C to C# running under pnet.
> 
> A way to view this would be to imagine the ExecutionEngine is a C# executable.
> The sequence of events would be:
> 
> 1. Receive Message
> 2. Decode Message
> 3. execvp ilrun ExecutionEngine.exe <assembly> <method> <array of params> 
> <array of param names>
> 4. Package result into Message
> 5. Return Message
> 
> 1,2,4,5 are C
> 3 is the launching of a C# prog
> 
> However, there will be lots of fork-exec'ing going on if we do it exactly 
> like this.  So, what I'm looking to do is remove the exec of ilrun by having 
> ilrun embedded directly in the VM process.  In the short term, fork-exec is 
> fine for proof of concept.
> 
> Gopal has offered to have a stab at this ilrun-able ExecutionEngine.
> 
> 
> VM Process - Deeper Details....
> -------------------------------
> [Rhys'll probably have comments about this - hopefully :o)]
> 
> Between decoding the request message and invoking ExecutionEngine.exe the VM 
> Process will get hold of the bytecode for the dll containing the method to be 
> executed.  It will be in memory, not on disk.  The reason for this is that it 
> will come from another architecture component via a message or be cached. 
> Basically there may never be a disc image of the .dll to be loaded by the 
> ExecutionEngine.
> 
> ILEngine doesn't support the execution of memory buffers, or Assembly 
> instantiation from a memory buffer AFAIK.
> 
> 
> ------
> 
> So that describes the pnet VM component of the DGEE.
> The simplest version will probably exec ilrun passing it everything it needs.
> 
> Ultimately, ILEngine embedded within the VM process is required, running 
> bytecode from a memory buffer.  Ideally we don't want to have a stub 
> containing 'main' to bootstrap the ExecutionEngine, but have its 'Go' method 
> invoked directly.
> 
> Standard pnetlib dll's will be available locally of course, though there's 
> nothing stopping us having them preloaded in memory as well I suppose.  It's 
> the webservice dll's that will have to be sourced from memory eventually.
> 
> 
> I'm going to pull the C pnet VM Process together over the next few days, and 
> hopefully when Gopal and I plug together..... :o)
> 
> 
> Comments on a postcard as always.
> 
> Cheers
> Chris
> 
>