[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] CMM Messages

From: Bill Lance
Subject: Re: [Vrs-development] CMM Messages
Date: Tue, 5 Mar 2002 13:35:22 -0800 (PST)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]