[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]Webservice Execution Engine
[DotGNU]Webservice Execution Engine
Tue, 3 Dec 2002 23:48:49 +0000
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
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.
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
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.
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk
- [DotGNU]Webservice Execution Engine,
Chris Smith <=