[PEAK] Re: Proposal for another Wiki "tutorial"

[John Landahl]

On Thursday 15 July 2004 11:29 am, Paul Moore wrote:
> On Wed, 14 Jul 2004 16:59:20, Phillip J. Eby wrote:
...
> > In the case of your monitoring system, the application domain is the
> > status of systems.
>
> I'm not sure it is. Or maybe the phrase "application domain" is the
> stumbling block. I tend to think procedurally about this - one script is
> "check all the production servers, and report which ones are down", another
> is "query free space on all the servers for customer X and log the results
> in the repository", etc, etc. Very "do it, and do it now".

This is a great example of what Martin Fowler calls the Transaction Script 
architectural pattern.  (If you haven't read his _Patterns of Enterprise 
Application Architecture_, I highly recommend it.  I've found it 
indispensable for understanding a number of important application design 
concepts, each of which have been boiled down into named patterns for easier 
communication.)

Phillip and I are thinking in terms of the Domain Model pattern, which is 
typically used when one is building a complex, medium to large application.  
This is where "problem domain" entities get mapped to "domain objects" which 
(currently) use data managers for storage, etc.

But as you go on to say...

> For background again, our systems monitoring is covered by an existing
> product (Oracle Enterprise Manager, for what it's worth), but for
> non-interesting reasons we have to supplement this with some pretty basic
> query scripts, which are run on a regular basis from the OS scheduler. I
> don't want to reimplement OEM, and nor do I particularly want to build a
> scheduler within the application.

... so we have different goals in mind.  From your idea it occurred to me that 
a PEAK-based OEM-like application (along the lines of Nagios or OpenNMS) 
would be a great way to demonstrate PEAK in action.  The problem is complex 
enough to use most of PEAK's features, and as a network-oriented application 
Twisted can be used to demonstrate PEAK/Twisted integration.

Both goals should produce useful results, of course. :)