[PEAK] Re: Proposal for another Wiki "tutorial"
john at landahl.org
Fri Jul 16 18:07:51 EDT 2004
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
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. :)
More information about the PEAK