|
| PeakFromBasics/LessonOne |
UserPreferences |
| The PEAK Developers' Center | FrontPage | RecentChanges | TitleIndex | WordIndex | SiteNavigation | HelpContents |
Contents
The first thing we need to do when designing an application using PEAK is to think in terms of components. Applications in PEAK are essentially sets of components, linked together by the framework. So let's look at what components make up our sample application.
We are monitoring a number of systems. So the first thing we need is something that lists out the systems we want to monitor. We'll call this component the "Repository". It could be a simple list of systems, or a database containing all of the details of our complete corporate infrastructure. At this point we don't care. From our perspective, the repository is just a "thing" that we can ask for a list of the systems we want to monitor.
OK. So far, so good. Let's see what other components we might need. Well, we'll need something to actually do the checks. Again, we don't really care about the details at the moment. Call this a "tester", and assume we can give it the details of a system and get it to do the necessary test.
And we wanted a report at the end, didn't we? Right, that's a "reporter" component, which takes the results of the tests and produces our report. Again, we don't worry about the details. The report could be a simple printed listing, an e-mail alert of systems which aren't responding, or anything. What the reporter does is something we can think about later.
And finally, we need a "controller", to tie these bits together. It takes the system data from the repository, sets a series of testers running, and passes the results to the reporter at the end. The controller could just run everything in sequence, but I'm looking ahead here and assuming that we will need to scale things up later, and may want the controller to run testers in parallel, using threads, or as separate subprocesses, or whatever. Again, the key here is to defer that decision. All we care about for now is that the controller component encapsulates that detail, for us to consider later.
The descriptions above were a little wordy. A diagram would probably clarify things here. Ideally, this diagram would be in something like UML, capturing the system design. However, as I don't know UML, we'll stick with a simple picture.
