[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
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/
- [Vrs-development] CMM Messages, Chris Smith, 2002/03/01
- Re: [Vrs-development] CMM Messages, Bill Lance, 2002/03/01
- Re: [Vrs-development] CMM Messages, Chris Smith, 2002/03/01
- Re: [Vrs-development] CMM Messages, Bill Lance, 2002/03/01
- Re: [Vrs-development] CMM Messages, Chris Smith, 2002/03/04
- Re: [Vrs-development] CMM Messages, Bill Lance, 2002/03/04
- Re: [Vrs-development] CMM Messages, Chris Smith, 2002/03/05
- Re: [Vrs-development] CMM Messages, Bill Lance, 2002/03/05
- Re: [Vrs-development] CMM Messages, Chris Smith, 2002/03/05
- Re: [Vrs-development] CMM Messages,
Bill Lance <=
- Re: [Vrs-development] CMM Messages, Chris Smith, 2002/03/06
- Re: [Vrs-development] CMM Messages, Bill Lance, 2002/03/06