[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Webservice Execution Engine
Re: [DotGNU]Webservice Execution Engine
Tue, 3 Dec 2002 22:39:48 -0500 (EST)
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
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.",
> 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
> 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.