Re: [Vrs-development] CMM Messages

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> On Tuesday 05 March 2002 16:19, you wrote:

 
> But you've missed something :o)
> What about scalability on a SINGLE machine.
> 
> Imagine you have four GWServers offering services
> A, B C and D.
> 
> A is a GWService that accepts a webservice Request.
> B Decodes this request and extracts all the info.
> C Looks at the Repository for the service required
> D Is actually the C# runtime engine
> 
> When A is called by a client, it invokes B which
> invokes C which invoked D.
> Whilst this is happening, no other client can
> have requests serviced because A is busy.
> 
> If a remote LDS calls out LDS and wants to get
> resource data it calls Service B.  But it can't
> because it is busy in the chain from A->D.
> 
> So to 'scale this up' you boot multiple instances
> of A, B, C and D.
> 

Are these seperate processes all started together at
initiation time or booted on demand by GW?


> Small machines which have limited resources might
> only
> boot three of for instances of each server.
> 
> Beefy machines with lots of memory and CPU cycles
> may
> boot LOTS more.
> 
> Plus you can TUNE the application by booting more of
> C
> than say the others, so requests for data from the
> repository can be done in parallel.
>

Ah.   Now I'm beging to understand

 
> Also, should one of these services be temporarily
> busy, Goldwater will efficiently queue the messgae
> in a FIFO, so the caller need not know that the
> service
> it is requesting is busy at all (unless the request
> times out because it queued too long).
> 
> THIS is the scalability I was talking about. 
> Scaling
> over multiple machines is an extension of this by
> making the message routing/queueing transparently
> span a network instead of just being local machine
> IPC - the application doesn't see or know any
> different.
> 


I need to refer to a cut from your other recent
posting
> 
>
*************************************************
> Say:
> You've got a program that takes a employee name
> and returns their address and salary details.
> 
> You chop it up into:
> A function that takes a name and returns an 
> employee number.
> 
> A function that takes an employee number and
> returns an address,
> 
> A function that takes an employee number and 
> returns salary information.
> 
> 
> Now you write a small code stub that takes
> an emplyee name from the command line and
> passes it to function A (name->number).
> 
> If this succeeeds, it passes the number to
> function B (number->address) and to function C
> (number->salary details).
> 
************************************************

This sound like the top level logic described above is
in the GW client.  Is the client minimal, containing
just enough logic for that function?

Can a GW server B, called by client A, in turn act a
client to call GW server X as a subfunction of it's
own logic?  

If I'm understanding, there is a choosen level of
granularity where a function is implemented as a
GWserver instead of as a subfunction of a single
executable, or a linked library call.






 
> Time is the problem really.
> I've got to rewrite GWDomains to facilitate
> namespacing
> and the features that LDS wants to build on!
> 
I certainly don't wish to distract you!  :)


> 
> You're thinking about converting perl modules to C
> and having them distributed across the cluster on
> each
> LDS, and have a single LDS call these 'modules' on
> remote LDSs to access the data held there.
> You are aren't you?
> 

No, not at all.  I was expecting that the final
implementation will be totaly in C.  The PERL
prototype is only to test the high level logic of the
system.  By 'converting perl to C', I mean
reimplementing the logic in C, once it's been proofed.
 And I was hoping that could be done in stages, with a
hybrid perl/C intermediate working system.  But
finally, any interpretor has to go.

> 
> GWServices can be anything that takes a request and
> returns a response.  In fact, they don't even have
> to
> return responses.  And they don't have to do
> anything
> with the request if they don't want to.
> 
> 
> Its very difficult to assess what you're planning to
> code wrt Goldwater implementation.
> 
> I'll *try* and put together a scenario of Goldwater
> usage - I'll  base it on the system I'm developing
> at the moment (not using Goldwater though :o(  - but
> the architecure is *exaclty* as GW would implement
> it).
> 
> This might tie up the loose ends in both our
> thinking.
> 


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/