Re: [Vrs-development] CMM Messages

[Chris Smith]

On Tuesday 05 March 2002 21:35, Bill Lance wrote:
> --- Chris Smith <address@hidden> wrote:

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

At start up.
You define a MIN and a MAX for a server in the config
and GW will boot MIN instances.
If you need more, you can manually boot additional
servers up to the MAX limit.
Anymore and you have to shutdown, reconfigure MAX
and restart.


> Ah.   Now I'm beging to understand

:o)

> *************************************************
>
> > 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.  

Yeah.
The code stub you end up with is the GW Client,
Functions A, B and C are GW Services.

> Is the client minimal, containing
> just enough logic for that function?

Or even just be a client which says 'GO' to one 
GWService in a chain of many.

Your shared resources are deployed as GWServices.
Your client can, at your option, be anything else.
I saw 99% of the LDS being implemented as GWServices
because:

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

Yes, this is *exactly* what you're supposed to do !

Though it's only worth doing this if GWService Y
also needs the functionality in GWService X or you
need GWService X to be invoked in parallel.
(cos a Function/library call is much quicker than
a GWService request!).

<drum roll>

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

<sound of a struck symbol!>
<and the crowd go wild....>


:o)
<grin>

Anything calling a GWService wears the 'I am A Client'
hat for the duration of the call, even if its a
GWService itself.

On the subject of clients, I was thinking:

One GWClient would be the bit of code that Apache
invokes to get a webservice request into the LDS
(A CGI that makes a GWService call....)

There'd probably be another client which is cron'd
to call a GWService periodically to perform timed
tasks (like polling things etc).

A command line GWClient to allow system administration
of the LDS application (though I'm trying to think of
a way that the Goldwater administration tool may be
hooked into to allow application level configuration).

And some sort of client to allow remote LDS's to
subscribe etc (unless this is done through Apache).

So in effect, non-goldwater components are effectively
clients of Goldwater if they make GWService calls.

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

Useful - we could get other developers on board to
help do this.

> > 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).

I think you've got it now.
I'll throw something together anyway, as I need some
sort of documentation of this!

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