[DotGNU]Re: [Vrs-development] Re: SEE and Goldwater integration

[Eric Altendorf]

Long email!!

On Saturday 12 October 2002 17:58, Chris Smith wrote:
>
> Depends on our layering.  Forgetting that for the moment, the basic
> steps to cover are:
>
> 1. network server responsible for handling particular protocol
> receives request
> 2. Request is validated (if appropriate to do so at this time). 
> This request will contain the 'service name' and request data to
> send to the service... 3. The service requested is looked up and
> retrieved from the 'storage' (in the generic sense of course :o) )
> 4. The webservice and the request data are passed to the VM for
> execution 5. result is passed back to the network server and then
> onto the requestor.

Pretty much, yeah.

> So where are the layers in this?
> I suppose the network server is at step 1.  It needs to extract the
> requested service name and the request data from the request
> itself.  After all, it understands the protocol encapsulation it
> supports!
>
> The SM should span 2 (the service name is validated), start of step
> 3 (the service location resolved), end of step 3 (the requested
> service is retrieved from the RM) and step 4 (retrieved webservice
> and request data passed to VM)
>
> The RM is invoked by the 'retrieval of webservice' part at the end
> of step 3.
>
> Yeah, that feels about right.

I agree.  It sounds good to me.  My only response is that (eventually, 
at least), we're going to want to have the webservices loaded into 
the VM permanently, executing in the same process.  Loading the 
webservice code and passing it to the VM every time a request comes 
in is, even with caching, going to be very slow.  The code needs to 
be pre-loaded into the VM (possibly in the same process?  I'm not 
sure how fast IPC is for large blocks of data) or we're going to have 
some performance issues.  Pre-loading allows for partial compilation, 
optimization, etc (eg, Java HotSpot JIT compiler).  Note that we in 
the long run we *definitely* can't start up a new VM process for each 
request.  That'll be CGI-bin inefficient. :-)  For now, sure, we can 
just load the code and start up a VM and run it -- good easy proof of 
concept.


> As the request contains more than one information set it will have
> to be decoded by the component responsible for that info set.  Ie
> the requested 'service name' will be decoded by the SM etc.
> However it is the webservice itself that is responsible for
> decoding the 'request data', after all the request data was
> implicitly meant for this webservice so nothing else can be
> expected to be able to understand it. Thats my current thought
> anyway.

Sounds right to me.


> Don't panic Eric, I'm not writing real VRS code :o)

What, me panic??!  ;-)


> My idea was purely an effort to achieve the following:
>
> 1. Demonstrate the data flow from the network server (seeport) to
> VM and back again.
> 2. Provide a skeleton architecture onto which our project may be
> built (ie onto which the real SM and RM and VM may be plugged).
> 3. Start to define the layers we have identified as tangible
> process groups
>
> ... all within the context of GW's messaging API.

Excellent.

> The SM in this first-effort demonstration would do nothing more
> than take the URL passed to the network server and pass it to the
> 'RM' as a filename of a chunk of compiled C# to get back (the
> webservice).  It would then call the VM passing it the webservice
> and the request data.

OK...

> As you are aware there is far more to the SM that this, the whole
> service management concept for one. But these at least are the
> essential steps in webservice invocation that we consider part of
> the SM.

Right.  Keep it simple for now.  We can add enabling/disabling of 
services and preloading/caching later.


> Oooh yes, that's where I'm going :o)
> The Billy-Basic SM I want to throw into my demo is just a place
> holder that you should replace with the real SM as it develops.  It
> does need to adhere to the same interface as the RM, VM and Network
> Server so this way we start defining the interface up front
>
> Hope that's okay with you guys.

This sounds absolutely great.  I think it's awesome we're going to 
start some actual coding, even if it's just for a prototype.

We need to schedule a meeting.  I'll send a separate message for that.

Eric

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi