model \'mäd-l\ n: a pattern of something to be made
Intranet applications are like a corporate application suite. These include word processors, project planners, spreadsheets, and many other useful and productive applications. They encompass all departments and touch many types of data. But unlike the business productivity application suites available today, your intranet applications should all share a common foundation.
Creating a suite of applications from scratch is tedious and boring. Cutting and pasting code is easy, but that goes against all object-oriented programming practices. What is needed is a basic structure from which to build your applications. This foundation should be flexible, stable, and extensible.
This chapter introduces you to four standards that all of our applications share. These standards provide a flexible, stable, and extensible foundation for developing intranet applications. These four standards together produce a prototype or a model application that can be used as a base when developing applications.
A Quick Overview of Intranet Applications
On an intranet, the applications that are built share much of the same functionality. Sure they all do different things but they also do a lot of the same things. These commonalties should become the foundation for your intranet application framework. They are the base and are truly your application standards.
Our primary design goal is to provide a set of standard application features. These features create a familiar atmosphere for all your intranet applications. Familiarity provides users with a sense of comfort because they don't have to learn an entirely new program. Apple capitalized on this idea years ago when it introduced the Macintosh computer. If you learned how to use the Mac, then you knew how to run almost every Macintosh application written. It was the consistency and adherence to set standards that made this possible. Microsoft Windows has since capitalized on the same concept. The design presented here is not quite a Macintosh but what it provides is something similar: consistency.
The following four standard features are what we strive to provide in the model intranet application design:
- Standard configuration file processing Standard logging to screen or disk Standard database connectivity
- Standard look and feel
Let's examine each goal individually, show an example, then point you in the right direction to find more information regarding each particular standard.
Configuration File Processing
Using configuration parameters in programming can be a real hassle unless a stable foundation is in place. Generally you end up coding a new configuration scheme with each application. What we can create is a class that provides a solid method of getting configuration parameters. This method encompasses configuration files on disk and overridden parameters passed in by way of the command line of the application.
Listing 1. A sample configuration file.
# Configuration file for Employee Maintenance
At the start of the application, we read the configuration file into memory. These parameters are merged with any configuration parameters that are passed in by way of the command line. The applications then need a consistent method of retrieving these parameters from the configuration parameter storage area. We should model the retrieval method after the method used in regular Java applets.
Logging to Disk or Screen
For tracking problems during the development cycle and for error logging after your application has been deployed, a log file is just the ticket. A common log file is even better for all of your applications and users. A common log file is easily searched and filtered for errors. This standard logging mechanism is the first standard feature that we need to supply.
To facilitate such a log file, we need to create it on disk. The log file is appended to each time; it is never overwritten. If we overwrite the file, then information from a previous session can be lost. You know how annoying that can be.
But what if the disk log fails to open, or if it can't be written to? Well, we need a backup log. These failed log entries should go to the screen.
This screen logging facility produces the same log information to a window, or using the System.out facility. When an application fails to create a disk log, all log output goes to the screen. Also, this screen log is used automatically if no disk log is specified or if there is an error.
System.out is a Java system object. It is an alias for the console in Windows. In UNIX it is an alias for stdout.
Common Log Entries
The entries in the log file should follow a standard, one that is easy to view and search. This format should be used across all of your intranet applications, and possibly your non-intranet applications as well. This log file format should be simple enough so that other programs might even use it.
You might find in the future that you use a third-party network management tool that can monitor your intranet applications and their log files. These tools can be a lifesaver in a pinch, so why not think about their needs as well?
Therefore, the following log file format is what to go with as the design. It includes all the information needed in an easy-to-use format:
application is the name of the application
user is the user who is running the application
date is the date of the log entry
level indicates the severity of the entry.
Six predefined levels are available: debug, informational, notice, warning, error, and fatal. Each is denoted in the log by the first letter in its name. D for debug, I for information, and so on.
Listing 2. Sample log entries.
Employee|960609|I|Application [Employee] started at Sun Jun 09 22:27:33 1996
Employee|960609|I|Port = 4333
Employee|960609|I|Server = mars.mcs.net
Employee|960609|I|Title = Employee
MaintenanceEmployee|960609|I|Application [Employee] ended at Sun Jun 09 22:28:38 1996
At startup, all of the intranet applications write several things to the log:
- A startup message showing the application and time/date of startup Optionally, the contents of the configuration file
- Optionally, any arguments passed in on the command line
At shutdown, the application writes a corresponding entry to its startup message. This is shown in Listing 2, also.
Connecting to databases with Java is a key point in your intranet application design stage. Various methods are currently available. Some are HTTP server extensions that return data in HTML format. Others are non-portable system-dependent solutions. A more Java-like option is JDBC.
It appears today that JDBC is the strongest supported database standard for Java. Using JDBC allows us to choose from almost any database and provides the flexibility to change databases when coding is complete.
To simplify database connectivity just a bit, we need to create a class that encapsulates the more monotonous aspects of connecting and disconnecting from a database server. This new class provides a connection strategy that is simple to use and easily extensible. This class also encapsulates much of the rudimentary JDBC initialization and cleanup. All we need to do is extend this class for each database we need to connect with.
Listing 3. How you should use your Database Connector Class.
// Make the connection...
if ( myConnector.connect( "munster", "hermy", "tcp-loopback.world" ) )
// Connection successful...
// Connection failed...
As you can see, the connect() method is called with the connection parameters necessary to make the connection. The exception handling is handled for you in the class, returning nothing but a simple true or false. This indicates the connection state as well.
Look and Feel
The final standard about the intranet applications is that they should have a consistent look and feel. This is achieved through the use of standard font, and a consistent layout of components.
Related Online Articles:
No comment yet. Be the first to post a comment.