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

[Chris Smith]

On Saturday 12 October 2002 17:31, Eric Altendorf wrote:

So there are two questions:
>
> 1) Who is responsible for decoding the URL to determine which service
> to invoke?  The service manager?

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.

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.


> 2) Who is responsible for decoding the request?  The service manager?
> The individual web service?  (You already asked this question,
> Chris.)  I'd say the web service should do it for now; it will keep
> the design of the service manager simpler.

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.

> > Anyway, if I bung some code together to implement the above, it
> > gives everyone an opportunity to see in practice what it is I've
> > been ranting on about for months, and should help Stephen see where
> > the middleware architecture is coming from and how/if/where it may
> > be of use to him.
>
> Let's talk about this.  I'd already started bunging together some code
> for the service manager, just because actually writing the code helps
> me see missing pieces in the design.

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

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.

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.

Really just covering steps 2, 3 and 4 above.
The RM here is just a process that opens a file and returns the contents.

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.

My demo code is/will be very simple as my goal is just to demonstrate data 
flow.  We also have something that the greater community can download and run 
(even though it won't really do much or mean much to them initially - it'll 
be essential for us though).  Also it's something Stephen can have a look at 
with respect to the SEE.

>  Perhaps we could coordinate so
> that you could get a network port manager running that could talk to
> my service manager...??  That'd be sweet...

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.

Just felt we needed a code-kick-up-the-butt, and that there are so many 
questions and queries posed by people such as Stephen that could be answered 
by examining the execution of an application, however simple.

Oh, and it's a real use of Rhys' work - quite exciting! :o)

Later,
Chris

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