[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vrs-development] Re: SEE and Goldwater integration
From: |
Eric Altendorf |
Subject: |
Re: [Vrs-development] Re: SEE and Goldwater integration |
Date: |
Sun, 13 Oct 2002 11:03:13 -0700 |
User-agent: |
KMail/1.4.1 |
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
- [Vrs-development] SEE and Goldwater integration (was Re: [DotGNU]Network SEE architecture, v2.0.1), Stephen Compall, 2002/10/11
- [Vrs-development] Re: SEE and Goldwater integration, Chris Smith, 2002/10/11
- Re: [Vrs-development] Re: SEE and Goldwater integration, Eric Altendorf, 2002/10/12
- Re: [Vrs-development] Re: SEE and Goldwater integration, Chris Smith, 2002/10/15
- Re: [Vrs-development] Re: SEE and Goldwater integration,
Eric Altendorf <=
- Re: [DotGNU]Re: [Vrs-development] Re: SEE and Goldwater integration, James Michael DuPont, 2002/10/14
- Re: [DotGNU]Re: [Vrs-development] Re: SEE and Goldwater integration, Chris Smith, 2002/10/14
- Re: [DotGNU]Re: [Vrs-development] Re: SEE and Goldwater integration, James Michael DuPont, 2002/10/14
- Re: [DotGNU]Re: [Vrs-development] Re: SEE and Goldwater integration, Eric Altendorf, 2002/10/15
- Re: [DotGNU]Re: [Vrs-development] Re: SEE and Goldwater integration, Eric Altendorf, 2002/10/15
- Re: [DotGNU]Re: [Vrs-development] Re: SEE and Goldwater integration, Chris Smith, 2002/10/14
[Vrs-development] Re: SEE and Goldwater integration (was Re: [DotGNU]Network SEE architecture, v2.0.1), Chris Smith, 2002/10/11