[Vrs-development] Webservice Execution Engine

[Chris Smith]

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

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk