[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Webservice Execution Engine
From: |
David Sugar |
Subject: |
Re: [DotGNU]Webservice Execution Engine |
Date: |
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
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
>
>