[Vrs-development] Re: [DotGNU]Webservice Execution Engine

[Chris Smith]

On Wednesday 04 December 2002 03:39, David Sugar wrote:

Some good comments!

> 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?  

Not really as that goes against what the DGEE is trying to provide. The DGEE 
is intended to be the common dotGnu service managment and execution 'thing'.

See:
  Re: [DotGNU]The DotGNU System
  Date: Tue, 03 Dec 2002 12:30:44 +0100
  From: Peter Minten <address@hidden>
  To: DotGNU Developers Mailing List <address@hidden>

The webserver is substituted in place of Block A.  Or you could put a Jabber 
server here, or an SMTP based SOAP server.... or just a command line client.
The DGEE 'cloud' spans all the other Blocks in the system diagram - it's just 
a collective term for the components that make up the DotGNU Execution 
Environment.

By altering the functionality of the Service Manager and Resource Managers 
you can turn a single machine DGEE into full SEE or VRS, as they're both 
instances of a DGEE.

Peters diagram is good in that it distictly shows a collection of VM's 
hanging off Block E.

It's a plugable system.

Of course the most efficient way for webservices to be executed would be to 
embedd pnet into say Apache - but that'll give you no more functionality with 
C# than mod_perl can do with perl.  I'm sure this will be extrememly usefull 
anyway, but you loose the concept of distributed services, decentralisation 
and all the funky things of SEE and VRS.

> 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...

Yep, probably, but that's not how the DGEE works - webservices are executed 
by a collection of pre-booted VM's, where there are multiple instances booted 
of each type. It gets arround all the problems people were previously having 
with generating multiple pnet threads :o)
The intention is to have a min and max setting on the number of VM instances 
so more instances may be booted as demand grows (hmm, this is similar to how 
apache manages children isn't it?) it's based on a technique used by BEA 
Tuxedo but theirs required manual intervention, ours will not.

However, as pnet matures it may be advantageous to create multiple pnet 
threads within the same VM process - the trick will be managing the message 
paths (see Peters Diagram and http://www.nfluid.com/dgee/dgee.html)

Cheers
Chris